แบ็กดอร์ XZ: “ไม่ใช่การข้ามการยืนยันตัวตน แต่เป็น RCE มีการกั้นเงื่อนไขและไม่สามารถรีเพลย์ได้”

 (bsky.app)
1 คะแนน โดย GN⁺ 2024-03-31 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • จากการวิเคราะห์ย้อนกลับเบื้องต้นของแบ็กดอร์ xz ระบุว่า พฤติกรรมนี้ไม่ใช่แค่ การข้ามการยืนยันตัวตน แต่ใกล้เคียงกับการรันโค้ดจากระยะไกล (RCE)
  • แกนสำคัญคือ RSA_public_decrypt ที่ถูก hook ซึ่งตรวจสอบลายเซ็นของ host key ของเซิร์ฟเวอร์ด้วยคีย์ Ed448 แบบตายตัว
  • หากการตรวจสอบลายเซ็นผ่าน payload อาจถูกส่งต่อไปยัง system() เพื่อรันได้
  • การวิเคราะห์นี้เป็น ผลลัพธ์เบื้องต้น ที่ได้รับอนุญาตให้เผยแพร่ และโพสต์บน Bluesky มีโพสต์อ้างอิงหรือคอนเทนต์แบบฝังรวมอยู่ด้วย
  • แบ็กดอร์นี้ถูกสรุปว่าเป็นรูปแบบที่ มีการกั้นเงื่อนไขและไม่สามารถรีเพลย์ได้ จึงควรมองต่างจากการโจมตีที่นำอินพุตเดิมกลับมาใช้ซ้ำแบบง่าย ๆ

ลำดับการทำงานของแบ็กดอร์ xz

  • การวิเคราะห์เบื้องต้น จากการทำวิศวกรรมย้อนกลับที่ได้รับอนุญาตให้เผยแพร่ มุ่งเน้นไปที่ RSA_public_decrypt ที่ถูก hook
    • ตรวจสอบลายเซ็นของ host key ของเซิร์ฟเวอร์ด้วยคีย์ Ed448 แบบตายตัว
    • หลังการตรวจสอบ จะส่ง payload ไปยัง system()

การจัดประเภทและข้อจำกัด

  • พฤติกรรมนี้ถูกจัดเป็น การรันโค้ดจากระยะไกล (RCE) ไม่ใช่การข้ามการยืนยันตัวตน
  • แบ็กดอร์นี้ถูกสรุปว่ามีคุณสมบัติ gated/unreplayable
  • โพสต์ต้นฉบับบน Bluesky มีโพสต์อ้างอิงหรือคอนเทนต์แบบฝังอื่น ๆ รวมอยู่ด้วย

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

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

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

  • มีผลจาก การทำรีเวิร์สเอนจิเนียริงเพิ่มเติม เกี่ยวกับประเด็นนี้ โดยมีข้อมูลการรีแมปสัญลักษณ์ที่ดึงออกมาจาก prefix trie ที่แบ็กดอร์ใช้ซ่อนสตริง และดูเหมือนว่ามันพยายามซ่อนตัวจากการรีเวิร์สเอนจิเนียริง/การวิเคราะห์เองด้วย
    https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9...
    รายการสตริงที่ถอดรหัสแล้วทั้งหมดอยู่ที่นี่
    https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01
    จากมุมมองของคนที่ไม่ค่อยรู้รายละเอียดภายในของ OpenSSL ค่า N ดูเหมือนจะถูกดึงมาจากฟิลด์ n ของ rsa_st
    https://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
    ค่านี้เป็น BIGNUM และดูเหมือนเป็นชนิดข้อมูลความยาวแปรผัน
    https://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
    แบ็กดอร์จะดึงค่านี้จากใบรับรองที่ได้รับจากผู้โจมตีระยะไกล แล้วพยายามถอดรหัสด้วย ChaCha20 หากสำเร็จก็ส่งต่อให้ system() โดย system() ใกล้เคียงกับ wrapper แบบง่าย ๆ ที่รันเชลล์สคริปต์หนึ่งบรรทัดด้วยสิทธิ์ของผู้ใช้ที่โปรเซสปัจจุบันกำลังทำงานอยู่
    ถ้าผมเข้าใจถูกต้อง เรื่องนี้แย่กว่าการข้ามการตรวจสอบกุญแจสาธารณะเสียอีก ถ้าเป็นการข้ามกุญแจสาธารณะ ตามทฤษฎีแล้วจะได้แค่สิทธิ์ของผู้ใช้ที่พยายามล็อกอิน และในการตั้งค่า SSH ที่เข้มงวดก็น่าจะปิดการล็อกอินเป็น root ไว้
    แต่นี่คือ การรันโค้ดจากระยะไกล ในบริบทของโปรเซส sshd เอง ดังนั้นถ้า sshd กำลังรันเป็น root เพย์โหลดก็อาจถูกรันเป็น root ได้ สำหรับการรันโค้ดจากระยะไกลที่แพร่กระจายกว้าง นี่แทบจะใกล้เคียงสถานการณ์เลวร้ายที่สุดในทางปฏิบัติ

    • หากมีการทำ sandboxing ที่เหมาะสม, SELinux และมาตรการลดผลกระทบต่าง ๆ ก็อาจหยุดไม่ให้ผู้โจมตีทำบางอย่างด้วยสิทธิ์ root ได้ อย่างไรก็ตาม การใช้ sandbox กับ SSH daemon ให้ได้ผลจริงเป็นเรื่องยากมาก
    • มหาศาลจริง ๆ นึกไม่ออกเลยว่าจะตัดสินใจอย่างไรว่าจะทำอะไรด้วยสิทธิ์ของ คอมพิวเตอร์หนึ่งพันล้านเครื่อง

  • ผมสงสัยว่าถ้าแบ็กดอร์นี้ไม่ถูกพบเพราะปัญหาด้านประสิทธิภาพ โอกาสที่จะถูกพบในภายหลังจะมีมากแค่ไหน ผมเข้าใจว่าปัญหาประสิทธิภาพเป็นความผิดพลาดในโค้ด/ข้อบกพร่องที่แก้ได้ และประเด็นสำคัญอีกอย่างคือมีเครื่องมือที่จะตรวจจับสิ่งนี้ได้หรือไม่
    คำถามแบบนี้เกี่ยวข้องอย่างมากกับการทำความเข้าใจว่าแบ็กดอร์ลักษณะนี้เป็นครั้งแรกจริง ๆ หรือแค่เป็นครั้งแรกที่ถูกเปิดเผยเท่านั้น

    • จากมุมมองของคนที่เคยทำงานราวหนึ่งปีในสภาพแวดล้อมที่มีผู้กระทำการด้าน IT ที่มุ่งร้ายอยู่มาก ผมคิดว่าโอกาสถูกค้นพบนั้นค่อนข้างสูงเสมอ การรักษาความลับ ต้องใช้พลังงานมากในระดับที่จินตนาการได้ยาก และการรักษาความสอดคล้องของความจริงก็เช่นกัน
      ความผิดพลาดเล็ก ๆ เพียงครั้งเดียวอาจทำให้ทุกอย่างพังลงได้ และบางครั้งแค่ประโยคเดียวก็เริ่มปฏิกิริยาลูกโซ่ที่เผยให้เห็นแผนการที่วางไว้อย่างประณีต
      การสืบสวนคดีอาชญากรรมเกิดขึ้นแบบนั้นทุกวัน งานตำรวจมีข้อจำกัดด้านทรัพยากร แต่ซอฟต์แวร์ถูกตรวจดูทุกวันโดยคนที่วิเคราะห์เป็นงานอดิเรก ผู้เชี่ยวชาญที่วิเคราะห์ต่อเนื่องเหมือนงานอดิเรก และผู้เชี่ยวชาญที่วิเคราะห์เป็นอาชีพ
      ท้ายที่สุดแล้ว มีความเป็นไปได้สูงว่าสักวันหนึ่งมันจะถูกค้นพบ
      การโจมตี XZ ถูกดำเนินการได้ดีมาก และแทบจะเป็นผลงานชิ้นเอกเลยทีเดียว จะไม่แปลกใจหากมีหน่วยงานรัฐเกี่ยวข้อง แต่ในเวลาเดียวกันก็โชคดีอย่างเหลือเชื่อด้วย หากมีการพบสิ่งใดสิ่งหนึ่งที่ตอนนี้ถูกระบุว่าเป็นปัญหา ไม่ใช่แค่ผม แต่เพื่อนร่วมงานหลายคนคงเริ่มการติดตามสืบค้นระยะยาวไปแล้ว
      ข้อสรุปหนึ่งที่ได้คือ ถ้า xz/liblzma ไม่ใช่โอเพนซอร์ส การค้นหาปัญหาแบบนี้คงเป็นไปไม่ได้ แน่นอนว่าการเป็นโอเพนซอร์สก็ทำให้เรื่องนี้เกิดขึ้นได้ตั้งแต่แรกด้วย แต่ลองจินตนาการดูว่าถ้ามันอยู่ใน Windows หรือ MacOS จะเป็นอย่างไร
    • หากไม่มีการใช้ exploit โอกาสที่จะถูกพบคงค่อนข้างต่ำ พวกเขาเลือกตำแหน่งซ่อนได้ดีมาก โดยแทบจะอยู่นอก codebase ในจุดที่ผู้ตรวจสอบไม่ดู
      แต่ถ้าไม่ใช้ ก็ไม่บรรลุเป้าหมาย ยิ่งใช้มากเท่าไร โอกาสที่จะถูกตรวจจับในภายหลังก็ยิ่งสูงขึ้น เปรียบได้กับ SolarWinds
    • ผมคิดว่าในอีกไม่กี่เดือนข้างหน้า ผู้คนจำนวนมากจะครุ่นคิดเรื่องนี้กันอย่างหนัก ว่าควรเป็นการรีวิวโค้ด หรือเป็น การวิเคราะห์พฤติกรรม บางประเภท
      โดยส่วนตัวแล้ว การเรียก system() ดูค่อนข้างหยาบ และสแกนเนอร์ฟังก์ชันของไบนารีอาจมีโอกาสพบเส้นทางนั้นได้
    • เรื่องนี้น่าจะจับได้ยาก แพตช์ของ sshd เกิดขึ้นในขั้นตอนที่ยอมรับได้คือ ตอนลิงก์ และถ้าการวิเคราะห์นี้ถูกต้อง มันก็ไม่ใช่แบ็กดอร์แบบ master key จึงไม่มีร่องรอยการ audit การล็อกอินทั่วไป และการที่ sshd เริ่มโปรเซสอื่นก็อาจเป็นสิ่งที่อนุญาตได้อยู่แล้ว
      นโยบาย SELinux ที่รัดกุมมาก ๆ อาจจับได้ว่า sshd กำลังรันอะไรบางอย่างที่ไม่ใช่เชลล์ แต่การ hardening ระดับนั้นน่าจะพบได้ยากมาก
      ประเด็นการตรวจพบจากภายนอกเป้าหมายก็เหมือนได้ทดลองกันแล้ว หลายคนดูเพย์โหลดด้วย valgrind และเครื่องมืออื่น ๆ แต่ก็ไม่เห็นอะไร มันถูกป้องกันค่อนข้างดีไม่ให้ถูกพบในสภาพแวดล้อมการดีบัก เพราะโครงสร้างพื้นฐานที่เปิดเผยอยู่ใต้เพย์โหลดนั้นไม่เข้ากันกับเครื่องมืออย่าง ASan
      แม้จะถูกลิงก์เข้ามา โค้ดก็รันก่อน main() ไปไกลมาก ดังนั้นแม้จะไล่ดูแถว ๆ liblzma ด้วยดีบักเกอร์ ปกติก็จะไม่เห็นช่วงที่มันรัน
      ถ้าเป็น strace จะเห็น system call ทั้งหมดหลังจากสร้างโปรเซสและการทำงานของ linker ได้ แต่เท่าที่ทราบจนถึงตอนนี้ เพย์โหลดไม่ได้ใช้ system call เพื่อกำหนดว่าจะเปิดใช้งานหรือไม่ในขั้นนั้น แต่ดูเหมือนจะดู argv และ environ เป็นต้น
    • ประเด็นต่อเนื่องที่น่าสนใจคือ ทำให้นึกได้ว่า การโจมตีของ Ken Thompson ก็ถูกพบเพราะบั๊กด้านประสิทธิภาพของหน่วยความจำใน PWB เช่นกัน
      [0] https://en.wikipedia.org/wiki/PWB/UNIX
      [1] https://news.ycombinator.com/item?id=38020792

  • ดูเหมือนจะมีสตริงที่ถูกเข้ารหัสอยู่ในเพย์โหลดไบนารี
    https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01...
    สตริงนี้ทำหน้าที่เป็น kill switch
    https://piaille.fr/@zeno/112185928685603910
    ถ้าเป็นเช่นนั้นจริง มาตรการบรรเทาอย่างหนึ่งอาจเป็นดังนี้

    echo "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" | sudo tee -a /etc/environment
    • ต้องใส่ -a ด้วยเสมอ ไม่อย่างนั้นอาจทำให้ไฟล์ environment หายไปได้ และโดยทั่วไปควรอัปเกรดเป็นเวอร์ชันที่ไม่มีโค้ดอันตรายแล้วรีสตาร์ต
    • แปลกมาก มีกลิ่นของ ผู้กระทำระดับรัฐ ที่อยากทิ้งวิธีป้องกันระบบของตัวเองไว้ชัดเจน

  • ช่วยอธิบายสั้น ๆ ได้ไหมว่า backdoor นี้ทำอะไรกันแน่? ตอนนี้รู้แล้วหรือยัง? ดูเหมือนตัว backdoor เองจะไม่ใช่เพย์โหลด เลยสงสัยว่าจำเป็นต้องมีไฟล์บีบอัดอันตรายหรือไม่ หรือมัน hook เข้าไปในโปรเซส sshd เพื่อฟังแพ็กเก็ตอันตรายจากผู้โจมตีระยะไกลกันแน่
    ต้นฉบับฟังดูเหมือนผู้โจมตีสามารถส่งเพย์โหลดอันตรายในขั้นตอนก่อนยืนยันตัวตนของเซสชัน SSH ได้ แต่ก็ไม่เข้าใจว่าทำไมถึงบอกว่า exploit อาจไม่มีวันถูกปล่อยออกมา ถ้า reverse engineer โค้ดได้ ก็น่าจะเขียน proof of concept ได้ไม่ใช่หรือ?
    สุดท้ายแล้วผู้โจมตีควบคุมเครื่องที่มี backdoor นี้ได้อย่างไร?

    • ให้นึกถึงประตูที่ถ้าเคาะให้ถูกแบบก็จะเปิด สำหรับคนที่ไม่รู้จังหวะเคาะลับ มันจะดูเหมือนกำแพงและทำตัวเหมือนกำแพง ถ้าไม่มีการเคาะลับ อาจถึงขั้นไม่มีทางพิสูจน์ได้ด้วยซ้ำว่ามันเปิดได้
      สถานการณ์นี้ก็คล้ายกัน xz จะพยายามถอดรหัสข้อมูลบางอย่างก่อนทำสิ่งที่น่าสงสัย เป็นแบบ asymmetric ดังนั้นจึงตรวจสอบการถอดรหัสได้โดยไม่ต้องให้คีย์เข้ารหัสลับ เพราะมีคีย์สาธารณะที่สอดคล้องกันอยู่
      การหา secret key แทบเป็นไปไม่ได้ในทางปฏิบัติ และถ้าถอดรหัสเพย์โหลดไม่สำเร็จ มันก็จะไม่แสดงพฤติกรรมที่แตกต่างอย่างเห็นได้ชัด ดังนั้นโค้ด exploit อาจไม่มีวันถูกเปิดเผย วิธีเดียวที่จะสร้างโค้ด exploit ได้คือ secret key ถูกค้นพบด้วยวิธีใดวิธีหนึ่ง ซึ่งในทางปฏิบัติก็แทบมีแค่กรณีที่ผู้พัฒนา backdoor ปล่อยหลุดออกมาเอง
    • จากสิ่งที่อ่านมา ผมมองว่า attack vector เป็นแบบนี้ sshd เริ่มทำงานและโหลด libsystemd ซึ่งโหลดไลบรารี XZ ที่มีโค้ดแฮ็กอยู่
      ไลบรารี XZ inject เวอร์ชันของตัวเองแทนฟังก์ชัน OpenSSL ที่ตรวจสอบลายเซ็น RSA
      เมื่อมีคนล็อกอินผ่าน SSH และยื่นใบรับรอง SSH ที่ลงลายเซ็นสำหรับการยืนยันตัวตน ฟังก์ชันที่ถูกดัดแปลงเหล่านั้นจะถูกเรียก
      ในใบรับรองอาจมี assertion information เช่นชื่อผู้ใช้หรือบทบาทอยู่ในขั้นตอนล็อกอินปกติ และข้อมูลนี้ใช้ตัดสินว่าใบรับรองนั้นใช้ล็อกอินเป็นผู้ใช้รายใดได้หรือไม่ แต่ถ้าฟังก์ชันที่ถูกดัดแปลงตรวจพบใบรับรองที่ลงลายเซ็นด้วยคีย์ของผู้โจมตีที่กำหนด มันจะดึงบาง subfield ของใบรับรองออกมาแล้วรันเป็นคำสั่งระบบ บริบทการรันคือ sshd หรือก็คือผู้ใช้ root
      น่าเสียดายที่เราไม่รู้คีย์สำหรับลงลายเซ็นของผู้โจมตี รู้แค่ public key ที่โค้ดแฮ็กใช้ตรวจสอบ โดยพื้นฐานแล้วผู้โจมตีสามารถ รันคำสั่งใดก็ได้ในฐานะ root บนระบบที่ติดเชื้อ และร่องรอยก็คงมีอย่างมากแค่ความพยายามล็อกอินที่ล้มเหลว สำหรับระบบที่เปิดสู่ internet ความพยายามแบบนี้มีเข้ามามากอยู่แล้ว
    • ดูเหมือนว่ายังไม่รู้แน่ชัดว่ามันทำอะไร ส่วนที่ว่า “replay ไม่ได้” ผมเข้าใจแบบนี้: ถ้าเพย์โหลดผิด หรือ ลายเซ็นของคีย์ผู้โจมตี ตรวจสอบไม่ผ่าน backdoor ก็จะกลับไปทำงานตามปกติ
      จุดสำคัญคือต้องมีลายเซ็นจากคีย์ของผู้โจมตี ตราบใดที่คีย์นั้นไม่รั่ว หรืออัลกอริทึม RSA ไม่ถูกทำลาย นักวิจัยคนอื่นหรือบุคคลที่สามก็ไม่สามารถใช้ backdoor นี้ในทางที่ผิดได้ หาก RSA ถูกทำลาย ปัญหาที่เกิดขึ้นจะใหญ่กว่านี้มาก
    • ถ้า public-key cryptography ถูกใช้อย่างถูกต้องและไม่มีบั๊กที่ใช้โจมตีได้ ต่อให้ reverse engineer ก็สร้าง proof of concept ไม่ได้
    • exploit ที่ถูกแจกจ่ายมาเป็นไบนารี ไม่ใช่ซอร์ส และถูกซ่อนไว้อย่างแนบเนียนในข้อมูลทดสอบ อีกทั้งยังตรวจสอบเพย์โหลดด้วย private key ที่ไม่ได้เปิดเผย
      ณ ตอนนี้มีแค่ผู้โจมตีเท่านั้นที่รัน exploit ได้ จึงสแกนหาไม่ได้เช่นกัน นอกจากผลข้างเคียงชั้นรองอย่างประสิทธิภาพที่ลดลงแล้ว ก็ตรวจจับได้ยาก และในความเป็นจริงมันก็ถูกค้นพบด้วยวิธีนั้น

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

    • คนจะคัดค้านไลเซนส์แบบนั้นอย่างหนัก กระแสต่อต้านใหญ่เรื่อง “มันไม่ฟรีอีกต่อไป” จะเริ่มขึ้น แล้วหน่วยงานนั้นก็จะถูก cancel
    • สงสัยว่ามันขาดเงินทุนจริง ๆ หรือเป็น burnout กันแน่
    • Cyber Resilience Act ของ EU ที่ถูกเสนออยู่ประกาศตัวว่าเป็นทางออก พูดสั้น ๆ คือไม่ว่าจะเป็นไฟร์วอลล์หรือเครื่องปิ้งขนมปัง vendor ต้องรับผิดชอบต่อช่องโหว่ตลอดอายุผลิตภัณฑ์
      ดังนั้น vendor จะมีแรงจูงใจให้รักษาโอเพนซอร์สให้ปลอดภัย เช่น จ่ายเงินให้ maintainer, จ้าง audit โค้ด หรือจ้างพนักงานประจำให้มาช่วย contribute
    • ความสำคัญกับความจำเป็นไม่เหมือนกัน แพ็กเกจนี้เป็นแพ็กเกจที่ จำเป็น มากกว่าจะสำคัญ
    • เข้าใจยากว่าทำไมต้องมีสิ่งที่ซับซ้อนอย่าง xz ด้วย โค้ดของ bzip2 เล็ก และน่าจะดูแลได้ด้วยเวลาเพียงเศษเสี้ยวเล็ก ๆ ของคนคนเดียว

  • ตอนนี้ถ้าเข้าไปที่ repository ของ xz จะเห็นว่าถูกปิดใช้งานเพราะละเมิดข้อกำหนดการใช้งานของ GitHub การปิดใช้งานนั้นเป็นเรื่องสมเหตุสมผล แต่ก็อยากให้ GitHub เก็บโค้ดและ history ไว้ แสดงแบนเนอร์ และปิดเฉพาะฟีเจอร์ที่อาจถูกนำไปใช้ในทางที่ผิด
    แบบนั้นนักวิจัยและคนอื่น ๆ จะได้เรียนรู้จาก exploit ได้ ในสถานการณ์ที่เล็กน้อยกว่านี้ ถ้าไลบรารีโฮสต์โค้ดอันตรายแล้ว repository ถูกถอดลง ผู้คนอาจมองข้ามไปว่าไม่ใช่เรื่องใหญ่

    • คงไม่อยากให้เครื่องมืออัตโนมัติดาวน์โหลดไป
    • สามารถดู GitHub events ของ repository นั้นเป็น CSV ได้ที่นี่: https://github.com/emirkmo/xz-backdoor-github
      ถ้าสนใจซอร์สโค้ดก็หาได้ง่าย โค้ดนี้และ Git repository เชื่อมโยงกับ Git repository หลายแห่งทั่วโลก และใน release ก็มีซอร์สถูก bundle ไว้หลายครั้ง
    • xz มี Git mirror ของตัวเอง จึงดู commit ทั้งหมดได้

  • ในฐานะผู้ดูแลโดยพฤตินัยของเกมโอเพนซอร์สที่ไม่ค่อยเป็นที่รู้จัก ผมเห็นนักพัฒนาแวะเวียนเข้ามาแล้วก็จากไป การมีส่วนร่วมที่มีคุณค่าก็รวมเข้าไปทั้งหมด
    ผู้ร่วมงานบางคนลงลึกกับฟีเจอร์ต่าง ๆ พอสมควร ในสภาพที่ C กับ C++ ปนกันด้วยสไตล์การเขียนโค้ดหลากหลายแบบ ผมไม่ได้เข้าใจรายละเอียดการ implement ทั้งหมดเสมอไป แต่ลึก ๆ ก็มีความคิดอยู่ว่า ถ้ามีใครใส่แบ็กดอร์ที่เลวร้ายจริง ๆ เข้ามา โปรเจกต์คงพัง
    โชคดีที่เกมนี้ obscure มาก และ attack surface ก็เล็กมาก ถึงอย่างนั้นก็ทำให้ผมหยุดความยั่วยวนที่จะลองเซ็นไบนารี Windows ด้วยเจตนาดีได้
    แบ็กดอร์ xz นี้เป็นฝันร้ายมหึมาจริง ๆ และผมรู้สึกเสียใจกับผู้พัฒนาดั้งเดิมและทุกคนที่ถูกลากเข้ามาเกี่ยวข้อง

    • แน่นอนว่านั่นถูกต้อง แต่ไม่ใช่ปัญหาเฉพาะของซอฟต์แวร์เท่านั้น จริง ๆ แล้วผมยังไม่แน่ใจด้วยซ้ำว่าในมุมมองที่มีความหมาย เราเรียกมันว่า “ปัญหา” ได้ไหม
      เวลาคุณเดินอยู่บนทางในป่า รถที่ผ่านไปมาอาจพุ่งชนคุณแล้วไปเลยก็ได้ คนขับมีโอกาสสูงที่จะไม่ถูกจับ ไม่มีวิธีป้องกัน และตำรวจก็ไม่ได้อยู่ข้าง ๆ สถานการณ์นี้น่ากลัวกว่าแบ็กดอร์ซอฟต์แวร์มาก แต่จริง ๆ แล้วเป็นความเสี่ยงขั้นต่ำที่เราต้องยอมรับเพื่อจะใช้ชีวิตทำอะไรสักอย่าง และเหตุการณ์แบบนั้นก็เกิดขึ้นจริง
      แต่ท้ายที่สุด คนส่วนใหญ่ไม่ได้พยายามทำร้ายผู้อื่นอย่างจริงจัง ทุกสิ่งที่มนุษย์ทำวางอยู่บนสมมติฐานนี้มาโดยตลอด และตอนนี้ก็ยังเป็นเช่นนั้น
      ภาพลวงตาว่าการทำ code review ให้เข้มงวดขึ้นอีกนิด ใช้ linter กับ CI และ pattern matching มากขึ้น ทำให้ code signing แพร่หลายขึ้น และตรวจสอบตัวตนของผู้คนแล้วจะป้องกันเรื่องแบบนี้ได้ ต่างหากที่เป็นปัญหาจริง ๆ มันเป็นอาการของ ความหลงผิดแบบ Silicon Valley ที่เชื่อว่าเราสามารถและควรจัดการควบคุมโลกได้ในทุกรายละเอียด “วิธีรักษา” แบบนั้นอาจเลวร้ายยิ่งกว่าโรคใด ๆ ที่มันพยายามป้องกันเสียอีก
    • Pieter Hintjens ผู้ล่วงลับแห่ง ZeroMQ เคยสนับสนุนแนวปฏิบัติที่เรียกว่า Optimistic Merging คือการ merge การมีส่วนร่วมทันทีโดยไม่รอ code review หรือผล CI แนวทางที่ใช้เกณฑ์การ merge แบบผ่อนคลายไม่ได้หลุดโลกไปเสียทีเดียว
      [1]: http://hintjens.com/blog:106
      ผมเข้าใจข้อดีของการสร้างชุมชนที่ผู้ร่วมพัฒนาสนุกกับการเข้าร่วมโปรเจกต์ แต่รู้สึกว่ามันเป็นวิธีที่ทำให้โปรเจกต์โตขึ้นโดยไม่มีวิสัยทัศน์หรือทิศทางที่ชัดเจน และสุดท้ายก็โยนภาระหนักเกินไปให้ผู้ดูแล เพื่อปรับการมีส่วนร่วมของคนอื่นให้เข้ากับมาตรฐานร่วมกัน
      code review จริง ๆ ถูกเลื่อนไปยังเวลาในอนาคตที่ไม่รู้แน่ชัด และถึงตอนนั้นก็ไม่รู้ว่า review จะละเอียดหรือไม่ ใครจะรับผิดชอบทำ หรือใครจะแก้ปัญหา สุดท้ายมันฟังดูเหมือนสูตรสำเร็จของความโกลาหลที่ไม่สามารถควบคุมได้ว่าอะไรถูกส่งไปถึงผู้ใช้
      ยังมีปัญหาเรื่องการเผยแพร่โค้ดอันตรายด้วย ประเด็นนี้ก็ถูกยกขึ้นมาในคอมเมนต์ของบล็อกโพสต์นั้น และ Pieter อธิบายสถานการณ์ที่เหมือนกรณี xz เป๊ะ
      “สมมติว่า Mallory อดทน หลอกลวง และแสร้งทำตัวเป็นผู้ร่วมพัฒนาที่มีคุณค่านานพอจนได้อำนาจควบคุมโปรเจกต์ จากนั้นค่อย ๆ ฝังแบ็กดอร์ลงไป ถ้าเป็นเช่นนั้น code review ที่รอบคอบก็ช่วยไม่ได้ Mallory เพียงต้องได้รับความไว้วางใจมากพอที่จะเป็นผู้ดูแล และนั่นไม่ใช่คำถามว่าทำได้หรือไม่ แต่เป็นคำถามว่าทำอย่างไร”
      เขาสรุปว่า “การป้องกันที่ดีที่สุดคือขนาดและความหลากหลายของชุมชน”
      แต่ผมคิดว่า code review ที่รอบคอบสามารถลดโอกาสที่เรื่องแบบนี้จะเกิดขึ้นได้จริง หาก review ทุกการมีส่วนร่วมอย่างละเอียด ไม่ว่าจะมาจากผู้ร่วมพัฒนาที่ไว้ใจได้หรือคนนอก ก็มีโอกาสมากขึ้นที่จะพบพฤติกรรมแปลก ๆ หรือ commit ที่บอกว่า “ทำ A” แต่จริง ๆ แล้วทำ B ได้ตั้งแต่เนิ่น ๆ
      การที่ Optimistic Merging จะนำไปสู่ชุมชนที่ใหญ่และหลากหลายกว่าหรือไม่ก็ยังถกเถียงกันได้ มีหลายโปรเจกต์ที่มีชุมชนคึกคักแม้จะมี contribution guideline ที่เข้มงวด และมันก็ไม่ได้ตอบว่าจะจับแพตช์อันตรายได้เมื่อไรและอย่างไร
      ปัญหาของ xz ไม่ใช่ชุมชนเล็ก แต่คือ ไม่มีชุมชนเลย ผู้ไม่หวังดีคนเดียวได้อำนาจควบคุมโปรเจกต์ และแทบไม่มีการกำกับดูแลจากใครอื่นเลย contribution guideline ไม่ใช่ปัจจัยเรื่องขนาดชุมชน และไม่ว่าจะใช้ Optimistic Merging หรือไม่ เรื่องแบบนี้ก็คงเกิดขึ้นอยู่ดี
      [2]: http://hintjens.com/blog:106/comments/show#post-2409627
    • ผมประหลาดใจเสมอที่บริษัทต่าง ๆ ทุ่มเทมหาศาลกับการรักษาความปลอดภัยขอบเขตเครือข่าย แต่ในองค์กรพัฒนา กลับติดตั้ง brew install cask หรือส่วนขยาย vi/emacs/vscode กันเป็นเรื่องปกติ
      Rust อาจเรียกได้ว่าเป็นภาษา/ชุมชนการเขียนโปรแกรมที่มีค่าเริ่มต้นปลอดภัยที่สุด และมีการออกแบบที่ให้ความสำคัญกับความปลอดภัยจนแทบไม่เปิดช่องให้เล่นกลกับพอยน์เตอร์ แต่เส้นทางติดตั้งที่พบบ่อยที่สุดและถูกแนะนำกลับเป็นแบบนี้ และผมเองก็เป็นคนหน้าไหว้หลังหลอกเต็มตัว เพราะก็ทำแบบนี้บ่อย ๆ
      https://www.rust-lang.org/tools/install
      นี่เป็นแค่ตัวอย่างหนึ่งเท่านั้น นิสัยที่เปิด remote code execution ให้ตัวเองด้วยการบอกว่า “ให้ curl สิ่งนี้แล้ว pipe เข้า sh” ขณะเดียวกันก็ถกเถียงกันเรื่องบล็อก unsafe ของใครสักคน กลายเป็น muscle memory ของคนจำนวนมากไปแล้ว
    • พูดตรง ๆ มันเป็นเพียงเรื่องของเวลาก่อนที่เราจะตระหนักว่าความหวังดีของเราถูกนำไปใช้ในทางที่ผิด พฤติกรรมอย่าง “รีบทำให้พังแล้วรีบแก้” หรือ “ใครอยากรับสิทธิ์ความเป็นเจ้าของโปรเจกต์ของผมไหม?” ก็เหมือนเชื้อเชิญปัญหา แต่ตราบใดที่โอเพนซอร์สยังเป็นแรงงานรักการเขียนโค้ดที่ไม่ได้รับค่าตอบแทน ก็ยากจะจินตนาการว่าจะอยู่โดยไม่มีสิ่งเหล่านั้นได้
      น่าเสียดายที่เรื่องแบบนี้เกิดขึ้น แต่ก็ไม่น่าแปลกใจ หวังว่าจะมีเครื่องมือที่ดีกว่าสำหรับรับมือกับผู้ไม่หวังดีแบบนี้ และหวังว่าจะเป็นโอเพนซอร์สด้วย

  • มีคำถามหลายอย่างที่แบ็กดอร์นี้โยนไว้ให้เรา มีแบ็กดอร์อื่นใดอีกที่ทีมเดียวกันหรือทีมคล้าย ๆ กันฝังเอาไว้? ทีมแบบนี้กำลังปฏิบัติการอยู่มากแค่ไหน? มี dependency มากเพียงใดที่เปราะบางต่อ การโจมตีแบบแทรกซึม เช่นนี้? พื้นผิวการโจมตีที่เป็นเป้าหมายของปฏิบัติการลับแบบนี้ในอุตสาหกรรมของเรามีขนาดแค่ไหน?
    การสร้างกราฟของบริการเครือข่ายหลัก ๆ อย่าง apache httpd, postgres, mysql, nginx, openssh, dropbear ssh, haproxy, varnish, caddy, squid, postfix พร้อม dependency ทั้งหมดของบริการเหล่านั้น และกราฟ committer ทั้งหมดของ dependency เหล่านั้น อาจเป็นก้าวแรกในการดูว่าจุดไหนมีมูลค่าสูงที่สุดและถูกจับตามองน้อยที่สุด
    นี่ไม่น่าจะเป็นครั้งแรกที่มีใครพยายามทำเรื่องแบบนี้ มันเป็นเพียงครั้งแรกที่ล้มเหลวแล้วถูกเปิดโปง เรารู้จักแบ็กดอร์ที่พยายามใส่ในเคอร์เนล Linux แล้วถูกพบ แต่กรณีนี้เป็นการโจมตีระยะไกลและมีลักษณะแตกต่างกันโดยสิ้นเชิง

    • ทำไมถึงเลือกสร้างแบ็กดอร์ แทนที่จะใช้ zero-day เหมือนที่ทุกคนทำ?
      ทำไมถึงไม่ปล่อยสิ่งที่ดูไม่เป็นอันตรายและอาจดูเหมือนบั๊กแม้ถูกตรวจพบ แต่กลับ implement แบ็กดอร์เต็มรูปแบบและพยายามซ่อนแม้กระทั่งวิธีการเผยแพร่?
      เรื่องแบบนี้น่าจะเป็นการตัดสินใจอย่างมีสติ เหตุผลอาจให้เบาะแสได้ว่าเป้าหมายคืออะไร
    • Debian ก็ควรถูกตั้งคำถามด้วยว่าทำไมถึงแพตช์ให้บริการที่รันเป็น root และรับการเชื่อมต่อจากอินเทอร์เน็ตโหลดไลบรารีที่ไม่จำเป็น

  • นี่ดูเหมือนหมายความว่า หากจะสแกน exploit จากระยะไกล เราต้องมี private key ของผู้โจมตี ซึ่งเราไม่มี ทางเลือกอื่นก็มีแค่รันสคริปต์ตรวจจับแบบโลคัลเท่านั้น

    • วิธีที่เลวร้ายสุด ๆ ซึ่งสแกนเนอร์บางตัวอาจเลือกใช้ คือถ้าเซิร์ฟเวอร์รองรับการยืนยันตัวตนด้วย RSA ก็ทำเครื่องหมายว่า “อาจมีช่องโหว่” เซิร์ฟเวอร์ SSH ส่วนใหญ่รองรับการยืนยันตัวตนด้วย RSA และจริง ๆ แล้ว SecSH RFC ก็ระบุว่าเป็นสิ่งที่ต้อง implement ด้วยซ้ำ แบบนั้นอาจผลักดันให้ผู้คนกลับไปใช้การยืนยันตัวตนด้วยรหัสผ่าน
      เว้นแต่ว่าจะพบว่าปัญหานี้แพร่กระจายอย่างกว้างขวางในระบบจริง วิธีแบบนั้นดูจะแย่ยิ่งกว่าสมัยที่ “ผู้เชี่ยวชาญ” คล้าย ๆ กันเรียกร้องให้เปลี่ยนรหัสผ่านทุกปี จนทำให้ความปลอดภัยจริงลดลง แต่ความปลอดภัยบนเอกสารดูดีขึ้น
    • ดูเหมือนว่าโค้ดตรวจสอบลายเซ็นจะทำงานเฉพาะเมื่อ public key ของไคลเอนต์ตรงกับ fingerprint เฉพาะบางค่า ดังนั้นอาจตรวจจับได้ด้วย ข้อมูลด้านเวลา
      การตรวจสอบลายเซ็นของแบ็กดอร์น่าจะใช้เวลาราว 100µs ดังนั้นคีย์ที่ fingerprint ตรงควรใช้เวลาในการประมวลผลนานกว่าคีย์ที่ไม่ตรงประมาณนั้น ความต่างของเวลานี้น่าจะตรวจจับได้จริงอย่างน้อยบน LAN และอาจทำได้ผ่านอินเทอร์เน็ตด้วย หากสแกนเนอร์รันอยู่ในตำแหน่งที่ใกล้กับเป้าหมาย
      ระบบที่บล็อก IP ของไคลเอนต์หลังการยืนยันตัวตนล้มเหลวซ้ำ ๆ จะทำให้การสแกนยากขึ้น
      (https://bench.cr.yp.to/results-sign.html ระบุว่าการตรวจสอบ Ed448 ใช้ประมาณ 400,000 cycle ซึ่งเท่ากับ 100µs ที่ 4GHz)
    • ในทวีตบอกว่า “เล่นซ้ำไม่ได้” สงสัยว่าทำไมถึงเล่นซ้ำไม่ได้ โครงสร้างเป็นแบบที่ sshd ที่มีแบ็กดอร์ส่ง challenge บางอย่างมา แล้วผู้โจมตีต้องเซ็นมันหรือเปล่า?

  • อาจเป็นความเห็นที่ไม่เป็นที่นิยม แต่ผมอดทึ่งกับปฏิบัติการทั้งหมดไม่ได้ แน่นอนว่าขอประณาม แต่ก็ยังอดชื่นชมไม่ได้ ตั้งแต่แนวคิดจนถึงการลงมือ มันเหมือน งานศิลปะ จริง ๆ และการที่ถูกจับได้เร็วขนาดนี้ถือว่าโชคดีมาก

    • ถ้า payload ไม่ได้ทำให้การล็อกอิน SSH หยุดแบบสุ่ม 0.5 วินาที ก็คงไม่ถูกพบไปอีกนาน
      ครั้งหน้า ผู้โจมตีมีแนวโน้มจะสร้าง payload ที่ไม่ทำให้เกิด latency spike แปลก ๆ ในงานที่มีมนุษย์รออยู่
      ทำให้นึกถึงเรื่องที่ Kim Dotcom รู้ว่าตัวเองเป็นเป้าหมายของการดักฟังผิดกฎหมาย เพราะอยู่ ๆ ค่า ping ใน MW3 ก็พุ่งสูงมาก เมื่อตรวจสอบก็พบว่าเฉพาะแพ็กเก็ตของเขาถูก route ผ่านสำนักงาน GCSB ที่อยู่ไกลมากทางกายภาพ GCSB ไม่มีอำนาจดักฟังผู้พำนักถาวรของนิวซีแลนด์ สุดท้ายเขาได้รับคำขอโทษเป็นการส่วนตัวจากนายกรัฐมนตรีนิวซีแลนด์
    • “ไม่ว่ายังไง คนที่ไม่ควรถูก merge คนนั้นก็ทำเรื่องยิ่งใหญ่ไว้ มันน่ากลัว แต่ก็ยิ่งใหญ่”
      ผมคิดว่าส่วนที่เฉียบแหลมที่สุดคือ การเลือกโปรเจกต์ ที่จะแทรกซึม เมื่อกลับไปอ่านการสนทนา pull request เรื่อง IFUNC ของ “Hans” ย้อนหลังแล้วก็รู้สึกปวดใจ แต่มันแสดงให้เห็นชัดมากว่าทำไมโปรเจกต์นี้จึงถูกเลือก
      อยากรู้ว่าข้างหลัง “Jia” และ “Hans” มีคนอยู่กี่คน และพวกเขาวิเคราะห์กับวางกลยุทธ์เรื่องการสื่อสารและการ contribute โค้ดอย่างไร บางแง่มุม เช่น persona ที่สามใน mailing list ที่ทำทีเป็นกดดัน ดูเหมือนทำขึ้นค่อนข้างหยาบ
      ดังนั้นยังมีความเป็นไปได้ว่าเป็นทีมเล็กที่ประณีต หรือแม้กระทั่งคนคนเดียวทำก็ได้ ถ้าเป็นรัฐ ผมคิดว่าน่าจะมีคนที่คอยสร้างและดูแล persona ปลอมทั้งวันเพื่อปฏิบัติการแบบนี้
      ถ้ามีใครคิดว่า “ผู้ใช้สามคนนี้ผลักดันแบบหยาบคายแปลก ๆ นะ เป็นใครกัน? บัญชีทั้งหมดถูกสร้างช่วงเวลาเดียวกันเลย น่าสงสัย ทำไมถึงมีใครใช้บัญชีปลอมมากดดันเรื่องนี้แรงขนาดนี้? ควรตรวจสอบดู” ก็คงยุ่งยากแล้ว เมื่อเทียบกับความพยายามทั้งหมดที่ลงไป ส่วนนั้นถือว่าสะเพร่า วางแผนไม่ดี หรือมีงบไม่พอ
    • เห็นด้วย แต่ส่วนของ social engineering รู้สึกโหดร้ายเป็นพิเศษ
    • ผมว่าไม่น่าจะเป็นความเห็นที่ไม่เป็นที่นิยมขนาดนั้น ในหลายแง่มุม นี่เป็นการโจมตีที่น่าประทับใจมาก มันแนบเนียน ถูกสร้างขึ้นตลอดหลายปี และถ้าผู้โจมตีไม่พลาดจนเกิดประสิทธิภาพตกแปลก ๆ ที่นำไปสู่การตรวจสอบ เราอาจไม่มีทางรู้
      ถ้าจะเติมสมมติฐานแบบดราม่าเข้าไป ผู้โจมตีอาจตกใจกับระเบิดนิวเคลียร์ทางข้อมูลที่ตัวเองกำลังจะจุดชนวน แล้วจงใจทำให้พังเองก็ได้
      เราสามารถรังเกียจผลลัพธ์สุดท้ายได้พร้อมกับยอมรับความซับซ้อนของการโจมตี
    • ไม่แน่ใจว่า “ชื่นชม” เป็นคำที่ถูกไหม แต่ก็เป็นปฏิบัติการที่ค่อนข้างน่าประทับใจจริง ๆ