คำอธิบายการทำ Obfuscation ในขั้น Bash
- พบแบ็กดอร์ใน xz/liblzma ซึ่งส่งผลต่อเซิร์ฟเวอร์ OpenSSH
- แทนที่จะโฟกัสที่ไบนารีซึ่งมีแบ็กดอร์รวมอยู่ บทความนี้ให้ความสนใจกับส่วน bash ช่วงต้นและวิธี obfuscation ที่เรียบง่ายแต่ชาญฉลาดที่ถูกใช้
- บทความนี้อธิบายว่าขั้น bash ถูกทำ obfuscation และถูกสกัดออกมาอย่างไร
ก่อนเริ่ม
- xz/liblzma สองเวอร์ชันที่ได้รับผลกระทบคือ 5.6.0 และ 5.6.1 โดยมีความแตกต่างเล็กน้อย
- ส่วน bash แบ่งเป็นสามขั้นตอน (หรือสี่ขั้นตอน?) และเรียกแต่ละขั้นว่า Stage 0 ถึง Stage 2
- จะมีการกล่าวถึง "Stage 3" ด้วย แต่ก็อาจยังไม่ได้ถูกทำให้สมบูรณ์ทั้งหมด
- ขั้นที่ถูก obfuscate/เข้ารหัสและไบนารีแบ็กดอร์ในภายหลังถูกซ่อนไว้ในไฟล์ทดสอบสองไฟล์
Stage 0
- เริ่มจากไฟล์ m4/build-to-host.m4 โค้ดนี้จะถูกรันที่จุดใดจุดหนึ่งระหว่างกระบวนการ build เพื่อสกัดสคริปต์ Stage 1 ออกมา
- อ่านไบต์จากไฟล์ทดสอบ ส่งต่อไปยัง standard output และใช้คำสั่ง
tr เพื่อแมปอักขระเป็นอักขระอื่น
Stage 1
- เป็นไฟล์ bash ที่เริ่มต้นด้วย "####Hello####" และถูกทำให้รันได้เฉพาะบน Linux เท่านั้น
- มีการใช้
eval เพื่อดึง srcdir จาก config.status และมีสายคำสั่ง head ที่ซับซ้อนสำหรับข้ามไบต์บางส่วนแล้วพิมพ์ผลลัพธ์ออกมา
- ใช้คำสั่ง
tr เพื่อทำ simple substitution cipher จากนั้นคลายบีบอัดด้วยคำสั่ง xz แล้วรัน
Stage 2
- Stage 2 เป็นสคริปต์ bash ที่แก้ไขกระบวนการคอมไพล์จริง
- ดูเหมือนจะมีระบบ "extension/patch" อยู่ ทำให้สามารถรันสคริปต์ใหม่ได้โดยไม่ต้องแก้ไขไฟล์ทดสอบซ้ำต่อเนื่อง
- มีโค้ดสำหรับสกัดไฟล์
.o และรวมเข้าไปในกระบวนการคอมไพล์/ลิงก์
สรุป
- กระบวนการนี้ถูกซ่อนไว้อย่างมาก และถูกประกอบขึ้นอย่างซับซ้อนโดยใช้เพียงเครื่องมือบรรทัดคำสั่งมาตรฐาน
- ผ่านการทำงานแบบสามขั้นและระบบ "extension" ทำให้รองรับอนาคตได้ และถูกออกแบบมาเพื่อไม่จำเป็นต้องแก้ไขไฟล์ทดสอบแบบไบนารีอีกครั้ง
- ความจริงที่ว่าการโจมตีลักษณะนี้ถูกค้นพบโดยบังเอิญ ทิ้งคำถามไว้มากมายให้กับชุมชนความปลอดภัย
ความเห็นจาก GN⁺
- บทความนี้เน้นย้ำความสำคัญของความปลอดภัยซอฟต์แวร์และการโจมตีห่วงโซ่อุปทาน ควรตระหนักถึงช่องโหว่ที่อาจเกิดขึ้นในกระบวนการ build ซอฟต์แวร์ และตอกย้ำความสำคัญของการรีวิวโค้ดและการตรวจสอบความปลอดภัย
- เทคนิค obfuscation และวิธีโจมตีแบบหลายสเตจแสดงให้เห็นว่าผู้โจมตีสามารถเจาะระบบได้อย่างซับซ้อนเพียงใด เทคนิคเหล่านี้ยังมีคุณค่าด้านการเรียนรู้สำหรับผู้เชี่ยวชาญด้านความปลอดภัยด้วย
- เครื่องมือหรือโครงการด้านความปลอดภัยอื่นที่มีความสามารถคล้ายกัน ได้แก่ Dependency-Check ของ OWASP และ Nexus Platform ของ Sonatype ซึ่งช่วยระบุช่องโหว่ด้านความปลอดภัยใน dependency ของซอฟต์แวร์
- เมื่อนำแนวคิดนี้ไปใช้ ควรเสริมความปลอดภัยในทุกขั้นของห่วงโซ่อุปทานซอฟต์แวร์ ข้อดีคือช่วยเพิ่มความปลอดภัยของระบบ ส่วนข้อเสียคือหากผู้โจมตีใช้วิธีนี้ การตรวจจับอาจทำได้ยาก
- เหตุการณ์นี้เผยให้เห็นทั้งจุดแข็งและจุดอ่อนของชุมชนโอเพนซอร์ส การตรวจสอบและการมีส่วนร่วมจากชุมชนมีความสำคัญต่อการเติบโตและความปลอดภัยของโครงการ แต่ในขณะเดียวกันก็มีความเสี่ยงจากผู้มีส่วนร่วมที่ประสงค์ร้ายด้วย
ยังไม่มีความคิดเห็น