โครงการ Arch Linux ประกาศระงับกลไกการรับช่วงดูแลแพ็กเกจ (Package Adoption) บน Arch User Repository (AUR) เป็นการชั่วคราว หลังตรวจพบการเข้ายึดแพ็กเกจเดิมโดยผู้ไม่ประสงค์ดีเพิ่มขึ้นอย่างต่อเนื่อง พร้อมมีการแก้ไขแพ็กเกจเพื่อฝังมัลแวร์ ซึ่งขณะนี้แคมเปญดังกล่าวขยายผลกระทบไปแล้วกว่า 200 แพ็กเกจ
ที่มาของมาตรการ
ผู้ดูแลโครงการ Robin Candau ประกาศมาตรการนี้ผ่าน Mailing List ของ Arch Linux โดยระบุว่าเป็นมาตรการชั่วคราวจนกว่าทีมงานจะสามารถจัดการกับปัญหาและกำหนดแนวทางป้องกันที่เหมาะสมได้ พร้อมขอความร่วมมือจากผู้ใช้งานให้ช่วยรายงานแพ็กเกจหรือ Commit ที่มีพฤติกรรมน่าสงสัย
กลไกการโจมตี: การใช้ประโยชน์จาก Package Adoption
ใน AUR แพ็กเกจที่ผู้ดูแลเดิมเลิกดูแลแล้วสามารถถูกทำเครื่องหมายเป็น Orphaned (แพ็กเกจถูกทิ้งร้าง) ซึ่งผู้ใช้งานที่ลงทะเบียนคนอื่นสามารถ "Adopt" หรือรับช่วงดูแลแพ็กเกจนั้นต่อได้ กลไกนี้ออกแบบมาเพื่อช่วยให้แพ็กเกจที่ถูกทิ้งร้างยังคงมีผู้ดูแลและได้รับการอัปเดตต่อไป
อย่างไรก็ตาม ผู้โจมตีใช้ประโยชน์จากกลไกนี้เพื่อเข้าควบคุมชื่อแพ็กเกจที่มีความน่าเชื่อถืออยู่แล้วในหมู่ผู้ใช้งาน จากนั้นแก้ไข Build Instruction ให้ดาวน์โหลดและติดตั้งมัลแวร์ระหว่างกระบวนการ Build แคมเปญนี้เกิดขึ้นทั้งจากการ Adopt แพ็กเกจที่ถูกทิ้งร้าง และการเข้าควบคุมบัญชีผู้ดูแลเดิมที่ถูกบุกรุกโดยตรง
ขนาดของแคมเปญ
จากการติดตามของผู้ใช้งาน แคมเปญนี้ขยายผลกระทบไปแล้วกว่า 200 แพ็กเกจ บน AUR ครอบคลุมแพ็กเกจยอดนิยมหลายรายการ ได้แก่:
- boringssl-git
- icloudpd
- windscribe-cli-v2-bin
- stirling-pdf-desktop-bin
- openconnect-sso
- arduino-language-server-noclang-bin
- pgadmin4-server
มาตรการที่ Arch Linux ดำเนินการ
Arch Linux ระงับเฉพาะกลไก Package Adoption เท่านั้น ไม่ได้ปิด AUR ทั้งระบบเป็น Read-only ผู้ดูแลแพ็กเกจเดิมยังสามารถทำงานและอัปเดตแพ็กเกจของตนได้ตามปกติ ส่วนผู้ใช้งานที่ต้องการ Adopt แพ็กเกจที่ถูกทิ้งร้างจะต้องรอจนกว่ามาตรการนี้จะถูกยกเลิก
ผลกระทบที่อาจเกิดขึ้น
- ผู้ใช้งานที่ติดตั้งหรืออัปเดตแพ็กเกจจาก AUR ในช่วงที่ผ่านมา อาจได้รับมัลแวร์โดยไม่รู้ตัว โดยเฉพาะแพ็กเกจในรายชื่อที่ได้รับผลกระทบ
- แพ็กเกจที่ถูกยึดครองมักเป็นแพ็กเกจยอดนิยมที่มีผู้ใช้งานจำนวนมาก ทำให้ผลกระทบขยายวงกว้างได้อย่างรวดเร็วก่อนถูกตรวจพบ
- กลไก Package Adoption ที่ออกแบบมาเพื่อประโยชน์ของ Community ถูกพลิกกลับมาเป็นช่องทางโจมตี สะท้อนความท้าทายด้านความปลอดภัยของ Community-driven Repository ในภาพรวม
- ผู้ใช้งานทั่วไปที่ไม่ตรวจสอบ Build Script ก่อนติดตั้งมีความเสี่ยงสูงที่สุด เนื่องจาก AUR เป็น Repository ที่ไม่มีการตรวจสอบเนื้อหาอย่างเป็นทางการเหมือน Repository หลักของ Arch Linux
สิ่งที่องค์กรควรทำ
- ตรวจสอบว่าระบบที่ใช้งานมีการติดตั้งแพ็กเกจจาก AUR หรือไม่ โดยเฉพาะแพ็กเกจในรายชื่อที่ได้รับผลกระทบที่ระบุไว้ข้างต้น
- ตรวจสอบ Build Script (PKGBUILD) ก่อนติดตั้งหรืออัปเดตแพ็กเกจจาก AUR ทุกครั้ง ไม่ควรติดตั้งโดยไม่ตรวจสอบเนื้อหา แม้จะเป็นแพ็กเกจที่เคยใช้งานมาก่อนก็ตาม
- หลีกเลี่ยงการติดตั้งแพ็กเกจ AUR ที่เพิ่งเปลี่ยนผู้ดูแลหรือมีการแก้ไข Build Instruction ผิดปกติในช่วงที่ผ่านมา ตรวจสอบประวัติการเปลี่ยนแปลงก่อนอัปเดตเสมอ
- ช่วยรายงานแพ็กเกจหรือ Commit ที่มีพฤติกรรมน่าสงสัยให้ทีมงาน Arch Linux ทราบ ตามที่ได้ร้องขอผ่าน Mailing List
แนวทางลดความเสี่ยงระยะยาว
1. จำกัดการใช้งาน AUR เฉพาะในระบบที่ไม่ใช่ Production หรือระบบที่มีความเสี่ยงสูงต่อธุรกิจ
เนื่องจาก AUR เป็น Repository ที่ดูแลโดย Community ไม่ได้ผ่านการตรวจสอบอย่างเป็นทางการเหมือน Repository หลัก
2. ใช้เครื่องมือตรวจสอบ Build Script อัตโนมัติก่อนติดตั้งแพ็กเกจจาก AUR
เพื่อลดภาระการตรวจสอบด้วยมือ และช่วยตรวจจับพฤติกรรมผิดปกติในขั้นตอน Build ได้เร็วขึ้น
3. ติดตามประกาศจากทีมงาน Arch Linux อย่างสม่ำเสมอ
โดยเฉพาะรายชื่อแพ็กเกจที่ได้รับผลกระทบเพิ่มเติม เนื่องจากแคมเปญนี้ยังอยู่ระหว่างการตรวจสอบและอาจขยายวงกว้างขึ้นได้
4. พิจารณาใช้ Package Manager หรือ Repository ที่มีกระบวนการตรวจสอบเข้มงวดกว่าสำหรับซอฟต์แวร์ที่สำคัญต่อการดำเนินงาน
แทนการพึ่งพา Community Repository อย่าง AUR สำหรับ Software ที่มีความสำคัญสูงต่อระบบงานหลัก
วิเคราะห์ในมุมมองจาก TXEC
เหตุการณ์นี้เป็นอีกหนึ่งตัวอย่างของความเสี่ยงในระบบนิเวศ Open Source ที่พึ่งพากลไก Community-driven ในการดูแลรักษาแพ็กเกจ กลไก Package Adoption ที่ออกแบบมาเพื่อประโยชน์ของผู้ใช้งาน กลับกลายเป็นช่องทางที่ผู้โจมตีใช้เข้าควบคุมชื่อแพ็กเกจที่มีความน่าเชื่อถือสะสมมานาน ซึ่งเป็นรูปแบบการโจมตี Supply Chain ที่พบเห็นมากขึ้นเรื่อยๆ ในระบบนิเวศ Package Repository ต่างๆ ไม่จำกัดเฉพาะ AUR
TXEC มองว่าการตัดสินใจของ Arch Linux ที่ระงับเฉพาะกลไก Adoption แทนการปิด AUR ทั้งระบบ เป็นแนวทางที่สมดุลระหว่างความปลอดภัยและการใช้งานต่อเนื่อง แต่สำหรับองค์กรที่ใช้ Arch Linux หรือ Distribution ที่พึ่งพา AUR ในระบบงาน ควรพิจารณาอย่างรอบคอบว่าแพ็กเกจใดที่จำเป็นต้องใช้จาก Community Repository จริงๆ และควรมีกระบวนการตรวจสอบเพิ่มเติมก่อนนำไปใช้งานในระบบที่สำคัญ
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: BleepingComputer, Phoronix, XDA Developers, Linuxiac, CyberSecurityNews ]