โพรงกระต่ายของแบ็กดอร์ xz sshd ลึกกว่าที่คาดไว้มาก

 (twitter.com/bl4sty)
2 คะแนน โดย GN⁺ 2024-04-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แบ็กดอร์ sshd ของ xz ไม่ได้หยุดแค่ฮุก RSA_public_decrypt ที่เปิดเผยในตอนแรก แต่ยังมี เส้นทางโค้ดเพิ่มเติม ที่เข้าถึงได้ยากกว่าถูกทริกเกอร์แล้วบางส่วน
  • ลำดับการโจมตีคือใช้คำสั่งที่ถูกดัดแปลงเพื่อติดตั้งฮุก mm_answer_keyallowed จากนั้นประกอบบัฟเฟอร์คำสั่งด้วย กุญแจสาธารณะ ssh-rsa ปลอม หลายตัว
  • “magic buffer” นี้บรรจุคำสั่งแบ็กดอร์เพิ่มเติมและ ลายเซ็น ed448 2 ชุด โดยลายเซ็นสะท้อนทั้งค่าไดเจสต์ SHA256 ของ host key และ session_id ของ KEX
  • PoC ปัจจุบันใช้ไลบรารีไคลเอนต์ SSH paramiko ที่ถูกแก้ไขอย่างหนัก และคำสั่ง 0x03 ทำให้สามารถทำ RCE แบบอาศัย system() และตั้งค่า uid/gid ได้
  • ยืนยันแล้วว่าสามารถข้ามการยืนยันตัวตนได้ โดย mm_keyallowed_backdoor cmd 1 สามารถเขียนทับการตอบกลับของ mm_answer_authpassword ทำให้ล็อกอินได้ด้วย รหัสผ่านใดก็ได้

เส้นทางแบ็กดอร์ที่เชื่อมลึกกว่าเดิม

  • แบ็กดอร์ xz sshd มีความสามารถที่ลึกกว่าพฤติกรรมที่เคยทราบในตอนแรก และบางส่วนถูกทริกเกอร์ได้โดยตรงแล้ว
  • จุดเข้าหลักคือฮุก RSA_public_decrypt
    • เมื่อส่งคำสั่งที่สร้างมาอย่างถูกต้อง จะมีการติดตั้งฮุกอีกตัวในฟังก์ชัน mm_answer_keyallowed ของ sshd
    • หลังจากนั้นจะส่งกุญแจสาธารณะ ssh-rsa ปลอมหลายตัวเพื่อแยกและประกอบ “magic buffer” เข้าด้วยกัน
  • “magic buffer” คือบัฟเฟอร์ที่เก็บคำสั่งแบ็กดอร์เพิ่มเติม
    • ภายในยังมี ลายเซ็น ed448 2 ชุด
    • ลายเซ็นเหล่านี้ถูกทำ salt ด้วยค่าไดเจสต์ SHA256 ของ host key เช่นเดียวกับลายเซ็นแบ็กดอร์ฝั่ง RSA_public_decrypt
    • ลายเซ็นสุดท้ายยังสะท้อน session_id ขนาด 0x20 ไบต์ที่ได้มาจากการแลกเปลี่ยนกุญแจเริ่มต้นของ SSH (KEX)

PoC และการข้ามการยืนยันตัวตน

  • PoC ปัจจุบันถูกสร้างด้วยไลบรารีไคลเอนต์ SSH paramiko ที่ถูกแก้ไขอย่างหนัก
  • คำสั่งที่ถูกทริกเกอร์ในตอนนี้คือ 0x03 ของเส้นทางโค้ดนี้
    • ทำให้ RCE พื้นฐานผ่าน system() กลับมาใช้งานได้อีกครั้ง
    • รองรับการตั้งค่า uid/gid ด้วย
  • ยังมีโค้ดอีกส่วนที่ต้องทำความเข้าใจเพิ่มเติม และเนื่องจากหนึ่งในคำสั่งแบ็กดอร์ของ mm_answer_keyallowed จะไปฮุก mm_answer_keyverify ในท้ายที่สุด จึงดูเหมือนว่าสามารถ ข้ามการยืนยันตัวตนทั้งหมด ของเซสชันแบบโต้ตอบได้
  • หลังจากนั้นก็มีการยืนยันการข้ามการยืนยันตัวตนแล้ว
    • mm_keyallowed_backdoor cmd 1 สามารถเขียนทับการตอบกลับของ mm_answer_authpassword ให้เป็นค่าที่กำหนดเองได้
    • หากตั้งค่าการตอบกลับเป็น { u32(9), u8(13), u32(1), u32(0) } ก็จะล็อกอินได้ด้วยรหัสผ่านใดก็ได้

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

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

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

  • https://threadreaderapp.com/thread/1776691497506623562.html

  • เหตุการณ์นี้ในบางแง่ก็ดูเป็นงานระดับมืออาชีพมาก แต่ในอีกแง่ก็เหมือนมือสมัครเล่นพอสมควรจนน่าแปลก
    พวกเขาสร้างตัวตนที่น่าเชื่อถือมานานพอจนได้เป็นผู้ดูแลแพ็กเกจสำคัญ ดำเนินการโจมตีแบบ social engineering ที่เหมือนมีหลายคนเกี่ยวข้อง ไม่เปิดเผยตัวจริงหรือที่มาของการโจมตี และยังทำ obfuscation ได้อย่างแนบเนียน
    แต่ในขณะเดียวกัน การปล่อยให้บั๊กและ performance regression หลุดเข้าไปในเวอร์ชัน production ก็ดูหละหลวม ถ้าเป็นองค์กรที่มีรัฐหนุนหลังและเก่งกาจจริง ก็น่าจะทดสอบกันอย่างหนักแบบปิดก่อนส่งเข้าโปรเจ็กต์สาธารณะ เพื่อกำจัดอาการช้าลงที่อาจทำให้คนสงสัย

    • ดูเหมือนหลายคนจะตั้งความคาดหวังกับคำว่า “มีรัฐหนุนหลัง” ไว้สูงเกินไป องค์กรใหญ่สุดท้ายก็คล้ายองค์กรใหญ่อื่น ๆ คือมีทั้ง ระบบราชการ, เดดไลน์, รอบการปล่อย และปัญหาการสื่อสารระหว่างทีม
      เหตุการณ์ “อาจเป็น backdoor” ล่าสุดของ iOS ก็ชี้เหมือนกันว่า องค์กรที่สะสมช่องโหว่ไว้เยอะไม่ได้ใส่ใจเสมอไปว่าบางส่วนจะถูกเผาทิ้ง
    • ไม่น่าแปลกที่จะเชื่อว่าคนพัฒนาโค้ดไม่ได้รัน Valgrind ไปพร้อมกับดู performance อยู่ตลอด
      เป้าหมายคือเซิร์ฟเวอร์และ appliance แล้วจะมีเซิร์ฟเวอร์หรือ appliance กี่ตัวกันที่รัน Valgrind บน image ตั้งต้น พอย้อนคิดก็ดูเหมือน “ทำไมถึงไม่คิดแบบนั้นนะ” แต่มีโอกาสสูงว่าพวกเขาทดสอบกับ system image ที่เป็นเป้าหมาย ไม่ใช่กับ image ปรับแต่งเองของนักพัฒนาทั่วไป
    • เมื่อ 2024-02-29 มี PR ที่ทำให้ libsystemd ไม่ลิงก์กับ liblzma ถูกส่งขึ้นมา [0]
      Kevin Beaumont คาดว่า “Jia Tan” เห็นสิ่งนี้แล้วเข้าใจทันทีว่า backdoor อาจถูกทำให้ใช้การไม่ได้ จึงรีบเร่งเพื่อไม่ให้งานมหาศาลที่ใส่ลงไปใน exploit นี้สูญเปล่า [1] และฟังดูน่าจะใช่
      แรงกดดันจาก เดดไลน์ นั้นน่าจะเป็นสาเหตุให้เกิด crash ใน 5.6.0 และทำให้ไม่มีเวลาพอจะเก็บงานเพื่อลดหรือกำจัด performance regression ซึ่งเป็นสาเหตุหลักที่ทำให้เรื่องนี้ถูกจับได้
      [0]: https://github.com/systemd/systemd/pull/31550
      [1]: https://doublepulsar.com/inside-the-failed-attempt-to-backdo...
    • ถ้าแม้แต่ Google ยังปล่อย Gemini ออกมาแบบหน้าตาเฉยได้ แล้วจะเชื่อยากตรงไหนที่องค์กรเงาแบบนี้จะพลาดในวิธีที่ละเอียดอ่อนกว่านั้น
      อย่างที่ Patrick McKenzie พูดไว้ที่อื่น องค์กรอาชญากรรมก็ขับเคลื่อนด้วยคณะกรรมการและฉันทามติเหมือนองค์กรที่ไม่ใช่อาชญากรรม มองแบบนั้นแล้ว เรือจะจมเพราะ performance แย่ลงจาก feature bloat ก็ฟังดูสมเหตุสมผล บริษัทที่ฉันเคยทำงานด้วยยังเคยพลาดแบบสมัครเล่นกว่านี้อีก
    • แม้องค์กรที่มีรัฐหนุนหลังและมีความสามารถก็ยังพลาดได้ หน่วยข่าวกรองเองก็ไม่ได้เก่งแบบโหดเหี้ยมอย่างที่คนชอบจินตนาการเสมอไป ความพยายามลอบสังหารของ Kremlin ในอังกฤษหลายครั้งแทบเป็นตลกร้ายแห่งความผิดพลาด [1]
      หรือบางที backdoor ตัวอื่นหรือช่องทางสำรองที่ใช้อยู่ก่อนอาจถูกปิดไปแล้ว เลยต้องการเส้นทางใหม่อย่างเร่งด่วน
      [1] https://en.wikipedia.org/wiki/Poisoning_of_Alexander_Litvine...

  • ความซับซ้อนของเรื่องนี้น่าสนใจมาก เพราะสุดท้ายกลับถูกจับได้จาก performance regression ที่ค่อนข้างสะดุดตา
    มันทำให้นึกถึงคำพูดจากรายการอาชญากรรมจริงประโยคหนึ่งว่า “มีเป็นล้านวิธีที่จะถูกจับได้หลังจากฆ่าคน และถ้าคุณนึกออกได้สักครึ่งหนึ่งก็ถือว่าเป็นอัจฉริยะแล้ว”

    • ถ้าคิดว่ามีทีมอยู่เบื้องหลังแอ็กเคานต์นั้นก็พอเข้าใจได้ บางคนอาจเป็นคนพัฒนาฟีเจอร์ แล้วอีกคนที่ประมาทกว่าหรือประสบการณ์น้อยกว่าก็เป็นคนรวมมันเข้าไป
      และอาจมีอีกคนคอยดูแล บัญชีปลอม ต่าง ๆ และโต้ตอบในคอมเมนต์กับ PR
    • อาจจะมองโลกสวยหรือไว้ใจคนง่ายเกินไป แต่ทุกครั้งที่กังวลว่า backdoor แบบนี้อาจแพร่กระจายอยู่แล้ว ฉันก็มักนึกถึงเรื่องนี้
      ไม่รู้ว่าครั้งนี้แค่โชคร้ายเลยโดนจับได้ หรือจริง ๆ แล้วการทำให้การโจมตีแบบนี้สำเร็จนั้นยากเกินไป หวังว่าอย่างหลังจะจริง แต่เราก็ไม่มีทางรู้
    • ถ้าจำไม่ผิด performance regression จะเกิดขึ้นเฉพาะตอนที่โค้ดถูกคอมไพล์ด้วย -fno-omit-frame-pointer ซึ่งไม่ใช่ค่าปริยาย https://mastodon.social/@AndresFreundTec/112187000944648334
    • ถ้ามีเวลามากพอและทดสอบบนเครื่องตัวเองมากกว่านี้ ก็น่าจะสำเร็จได้
      ฉันค่อนข้างมั่นใจว่าแพตช์ libsystemd ของ @teknoraver ทำให้ เส้นตาย ของพวกเขาเปลี่ยนไป
    • คำว่า “ถ้านึกออกได้สักครึ่งหนึ่ง” นี่ใช้กับฝั่งที่พยายามไขคดีฆาตกรรมด้วยหรือเปล่า?

  • เมื่อมีบทความเชิงเทคนิคที่เจาะรายละเอียดลึก ๆ เกี่ยวกับเหตุการณ์แบบนี้ออกมาเยอะ มักจะสงสัยอยู่บ่อย ๆ ว่าทำไมทุกคนถึงพูดว่า “นี่ต้องมีรัฐหนุนหลังแน่ ๆ”, “ดู timestamp สิ นี่คือหลักฐานที่โต้แย้งไม่ได้”
    เหตุการณ์ xz เป็นการโจมตีที่แนบเนียนและใช้เวลาวางแผนนานก็จริง แต่จำเป็นจริงหรือที่จะต้องมีอะไรบางอย่างที่เกินกว่า บุคคลที่มีความสามารถเพียงคนเดียว? การที่คนทั่วไปบนอินเทอร์เน็ตสามารถวิเคราะห์และทำความเข้าใจมันได้ ก็แปลได้เหมือนกันว่ามันอยู่ในขอบเขตที่คนคนหนึ่งจะเข้าใจได้
    ทำไมความเป็นไปได้ที่เป็นเพียงคนฉลาดแต่ไม่พอใจคนหนึ่งลงมือเพียงลำพังถึงเป็นไปไม่ได้

    • ปัจจัยที่ทำให้นึกถึงผู้กระทำระดับรัฐมากที่สุดคือ ขนาดของผลตอบแทนที่คาดหวังเมื่อเทียบกับเวลาที่ทุ่มไปกับการโจมตีแบบ social engineering
      แผนเพื่อผลกำไรในลักษณะนี้ไม่สมเหตุสมผล ผมไม่ได้ตัดความเป็นไปได้ว่าจะเป็นผู้กระทำที่ไม่มีเหตุผลหรือเป็นบุคคลที่มีแรงจูงใจที่ไม่ใช่เงิน แต่ก็ทำให้ผู้กระทำระดับรัฐดูเป็นผู้ต้องสงสัยที่น่าเชื่อที่สุด
      ถ้าสำเร็จ มูลค่าที่ขายได้คงมหาศาล แต่โอกาสที่จะฝัง exploit ไว้ในโครงสร้างพื้นฐานสำคัญแล้วไม่ถูกจับได้อยู่นานพอจนมีลูกค้ายอมซื้อไปใช้นั้นต่ำมาก รัฐรับความเสี่ยงแบบ moonshot ได้ แต่ถ้าเป็นบุคคลธรรมดาก็น่าจะมองหาเป้าหมายที่มี expected value สูงกว่า
      แน่นอนว่านั่นก็ไม่ได้หมายความว่าต้องเป็นผู้กระทำระดับรัฐที่เก่งมากหรือมีการจัดสรรทรัพยากรจำนวนมาก
    • เห็นด้วย การแฮ็กนี้ต้องใช้ทักษะ ความมุ่งมั่น และเวลามาก
      แต่สิ่งนั้นก็ใช้กับ นักพัฒนาโอเพนซอร์ส จำนวนไม่น้อยไม่ใช่หรือ แรงจูงใจก็ชัดเจน exploit นี้น่าจะมีมูลค่าหลายล้านดอลลาร์ในตลาดมืด
    • ไม่มีอะไรเลย ไม่มีใครรู้ว่าเขาเป็นใคร
    • อยากรู้ว่าคำว่า “หลักฐานที่โต้แย้งไม่ได้” ไปเห็นมาจากไหน
      ผมเห็นการคาดเดาจากคนที่รู้เรื่องดีอยู่เยอะ แต่ไม่เคยเห็นถ้อยคำแบบนั้น

  • มีบทความไหนสรุป การทำ obfuscation ของตัว backdoor เองไหม? หมายถึง backdoor ตัวจริง ไม่ใช่ build script สำหรับติดตั้ง
    ผมเอาไบนารีไปใส่ใน Ghidra แล้วไล่ดูฟังก์ชันที่หาเจอ แต่ไม่คุ้นกับกลไก ifunc ที่ใช้ดักการทำงาน เลยยอมแพ้และปล่อยให้คนอื่นจัดการต่อ
    เพราะมีฟังก์ชันป้องกันการดีบัก ผมเลยคิดว่าโค้ดก็น่าจะถูก obfuscate ด้วย และเพราะมันถูกแจกจ่ายเป็นไบนารีทึบแสง ผมคิดว่าอย่างน้อยบางส่วนของโค้ดน่าจะถูกเข้ารหัสด้วยคีย์ที่เราไม่มี คล้ายกับบางส่วนของ payload ใน STUXNET

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

  • ผมไม่ได้ตามเรื่องนี้แบบละเอียดมาก แต่แปลกมากที่แทบไม่ได้ยินการพูดถึง ผู้ก่อเหตุ ของการแฮ็กเลย

    • “อย่างไรก็ตาม ผมคิดว่าแท้จริงแล้วเขามาจากโซนเวลา UTC+02 ฤดูหนาว/UTC+03 DST ซึ่งก็คือพื้นที่ที่รวมยุโรปตะวันออก (EET) หรืออิสราเอล (IST)”
      https://rheaeve.substack.com/p/xz-backdoor-times-damned-time...
    • มีการคาดเดากันเยอะ น่าจะเป็นหลายคนมากกว่าคนเดียว และดูเป็นไปได้ว่าอาจเป็น กลุ่มแรนซัมแวร์ หรือหน่วยข่าวกรองของรัฐ
    • น่าสนใจถ้าจะ วิเคราะห์เชิงความหมาย การสื่อสารของเพอร์โซนาออนไลน์ที่เกี่ยวข้อง แบบเดียวกับที่เคยใช้วิเคราะห์ Satoshi เพื่อดูแนวโน้มทางวัฒนธรรม
      ถ้าดูว่ามีความต่างด้านสำนวนเกิดขึ้นตามเวลาหรือไม่ ก็อาจพอมองได้ว่ามีหลายคนใช้เพอร์โซนาเดียวกันหรือเปล่า อีกทั้งยังมีโค้ดที่ถูก commit ไว้พอสมควร ก็น่าลองดูความต่างของสไตล์โค้ดเพื่อประเมินว่ามีมากกว่าหนึ่งคนเกี่ยวข้องหรือไม่
    • จะคุยอะไรได้ล่ะ? ยังไม่มีอะไรที่รู้แน่ชัดเลย

  • โชคดีมากที่มันถูกค้นพบก่อนจะแพร่หลาย
    ไม่ใช่แค่เพราะเหตุผลตรงไปตรงมาว่าเราไม่อยากให้ผู้กระทำที่ไม่รู้ว่าเป็นใครมี remote code execution อยู่ในโครงสร้างพื้นฐานของเรา ถ้าคนยังขุดคุ้ยกันต่อไป ในที่สุดก็อาจมีคนสร้าง payload ที่ทำให้ใคร ๆ ก็ใช้ backdoor นี้ได้
    การมีผู้กระทำเพียงรายเดียวที่เข้าถึงได้ก็แย่อยู่แล้ว แต่การที่ใครก็เข้าถึงได้ยิ่งแย่กว่า

    • ถ้า payload เป็น private RSA key แบบนั้นก็คงแทบเป็นไปไม่ได้ไม่ใช่หรือ?

  • ลิงก์ที่ดูได้แทน thereaderapp.com:
    https://nitter.poast.org/bl4sty/status/1776691497506623562

  • น่าประหลาดใจที่ผ่านไปหลายวันแล้วแต่ก็ยังคลี่คลายไม่หมด
    ทั้งที่คนทั่วโลกกำลังจับตาดูอยู่ และชิ้นส่วนสำคัญก็น่าจะเปิดเผยต่อสาธารณะตามทฤษฎีแล้ว การที่มันยังทนได้ขนาดนี้แปลว่า การทำ obfuscation น่าจะทำมาได้ดีมาก

  • สิ่งที่น่ากังวลในเหตุการณ์นี้คือความเป็น เกมระยะยาว
    อย่างแรก พวกเขารอจังหวะอยู่นานเพื่อสร้าง “โครงสร้างพื้นฐาน” สำหรับทำ backdoor อย่างที่สอง หลังจาก exploit แพร่เข้าไปถึงโปรดักชันจริงแล้ว ก็น่าจะมีการเตรียมเกมระยะยาวอีกชั้นไว้แล้ว วิธีที่ถูกต้องในการใช้เงินรางวัลลอตเตอรี่ก็คือการเอาไปลงทุน
    อย่างที่สาม มันทำให้สงสัยว่าตอนนี้ยังมีเกมแบบนี้กำลังดำเนินอยู่หรือเปล่า น่ากลัวมาก