การโจมตี supply chain ล่าสุดที่มุ่งเป้าไปที่แพ็กเกจยอดนิยม @ctrl/tinycolor ได้จุดประกายการถกเถียงอย่างรุนแรงเกี่ยวกับความปลอดภัยของระบบเผยแพร่อัตโนมัติในระบบนิเวศ JavaScript การเหตุการณ์นี้ซึ่งส่งผลกระทบต่อ 20 แพ็กเกจ รวมถึงหนึ่งแพ็กเกจที่มีการดาวน์โหลด 2 ล้านครั้งต่อสัปดาห์ ได้เผยให้เห็นจุดอ่อนพื้นฐานในวิธีที่นักพัฒนาจัดการข้อมูลประจำตัวสำหรับการเผยแพร่ในที่เก็บข้อมูลที่ใช้ร่วมกัน
ไทม์ไลน์การโจมตีและผลกระทบ
- วันที่: 15 กันยายน 2024
- แพ็กเกจที่ได้รับผลกระทบ: รวม 20 แพ็กเกจ
- แพ็กเกจที่มีผลกระทบสูง:
@ctrl/tinycolor(ดาวน์โหลด 2 ล้านครั้งต่อสัปดาห์) - วิธีการโจมตี: เวิร์กโฟลว์ GitHub Actions ที่เป็นอันตรายในที่เก็บข้อมูลที่ใช้ร่วมกัน
- เวลาตอบสนอง: ทีมรักษาความปลอดภัยของ GitHub/NPM ตรวจพบและลบออกในวันเดียวกัน
อันตรายที่ซ่อนเร้นของ Token ในที่เก็บข้อมูลที่ใช้ร่วมกัน
การโจมตีนี้ไม่ได้มุ่งเป้าไปที่ที่เก็บแพ็กเกจหลักโดยตรง แต่กลับใช้ประโยชน์จาก NPM token ที่ถูกลืมไว้ในที่เก็บข้อมูล GitHub ที่ใช้ร่วมกันชื่อ angulartics2 ซึ่งนักพัฒนาหลายคนมีสิทธิ์ admin มีการส่ง workflow ที่เป็นอันตรายไปยังที่เก็บข้อมูลนี้ ซึ่งขโมย token ทันทีและใช้มันในการเผยแพร่เวอร์ชันที่ถูกบุกรุกของแพ็กเกจอื่นๆ ที่ไม่เกี่ยวข้อง สิ่งนี้เน้นย้ำถึงการมองข้ามที่สำคัญในวิธีที่นักพัฒนาจัดการข้อมูลประจำตัวในโครงการที่ทำงานร่วมกัน
การตอบสนองของชุมชนเป็นไปอย่างรวดเร็วแต่แบ่งแยกในเรื่องของแนวทางแก้ไข นักพัฒนาหลายคนกำลังตั้งคำถามว่าความสะดวกสบายของการเผยแพร่อัตโนมัตินั้นคุ้มค่ากับความเสี่ยงด้านความปลอดภัยที่เกิดขึ้นหรือไม่
การถกเถียงเรื่องระบบอัตโนมัติครั้งใหญ่
เหตุการณ์นี้ได้จุดประกายการอภิปรายใหม่เกี่ยวกับว่าการเผยแพร่อัตโนมัติควรเป็นแนวทางเริ่มต้นสำหรับการจัดการแพ็กเกจหรือไม่ สมาชิกชุมชนบางคนโต้แย้งว่าการเผยแพร่ด้วยตนเองพร้อมการยืนยันตัวตนสองขั้นตอนจะสามารถป้องกันการโจมตีนี้ได้อย่างสมบูรณ์ เหตุผลนั้นง่ายๆ คือ แพ็กเกจ NPM ส่วนใหญ่ไม่ได้อัปเดตบ่อยพอที่จะสมเหตุสมผลกับความเสี่ยงด้านความปลอดภัยของระบบอัตโนมัติ
อย่างไรก็ตาม คนอื่นๆ ชี้ไปที่ประโยชน์เชิงปฏิบัติของระบบอัตโนมัติ รวมถึงการสร้างที่สม่ำเสมอและการลดข้อผิดพลาดจากมนุษย์ ความท้าทายอยู่ที่การหาจุดสมดุลที่รักษาความปลอดภัยโดยไม่เสียสละความน่าเชื่อถือที่ระบบอัตโนมัติให้
 |
|---|
| การถกเถียงที่ยังคงดำเนินต่อไปเกี่ยวกับการเผยแพร่แบบอัตโนมัติเทียบกับกระบวนการใช้คนสำหรับการจัดการแพ็กเกจทำให้เกิดคำถามด้านความปลอดภัยที่สำคัญ |
การปรับปรุงความปลอดภัยที่เสนอ
แนวทางแก้ไขทางเทคนิคหลายอย่างได้เกิดขึ้นจากการอภิปรายของชุมชน แนวทางที่มีแนวโน้มดีที่สุดเกี่ยวข้องกับการแยกการอัปโหลดแพ็กเกจออกจากการเผยแพร่ - อนุญาตให้ระบบอัตโนมัติสร้างและอัปโหลดแพ็กเกจในขณะที่ต้องการการอนุมัติจากมนุษย์สำหรับการเผยแพร่ขั้นสุดท้าย แนวทางสองขั้นตอนนี้จะรักษาประโยชน์ของระบบอัตโนมัติในขณะที่เพิ่มจุดตรวจสอบจากมนุษย์ที่สำคัญ
การเผยแพร่แพ็กเกจที่อัปโหลดแล้วควรต้องให้มนุษย์เข้าสู่เว็บไซต์ npmjs และเผยแพร่แพ็กเกจด้วยตนเองและผ่าน MFA
การปรับปรุงที่เสนออีกอย่างหนึ่งเกี่ยวข้องกับการใช้การหน่วงเวลาหรือการต้องการผู้อนุมัติหลายคนสำหรับการดำเนินการที่มีความละเอียดอ่อน คล้ายกับแนวปฏิบัติด้านความปลอดภัยที่ใช้ในระบบโครงสร้างพื้นฐานที่สำคัญ
การปรับปรุงความปลอดภัยที่เสนอ
- การเผยแพร่แบบสองขั้นตอน: แยกการอัปโหลดอัตโนมัติออกจากการอนุมัติการเผยแพร่แบบแมนนวล
- การอนุมัติจากหลายคน: กำหนดให้ผู้ดูแลหลายคนต้องอนุมัติการเผยแพร่
- การหน่วงเวลาแบบ Time-Lock: ใช้ระยะเวลารอระหว่างการสร้างและการเผยแพร่
- การรวม MFA ที่ปรับปรุงแล้ว: การรวม 2FA เข้ากับเวิร์กโฟลว์ CI/CD ที่ดีขึ้น
- คำเตือนสำหรับ Postinstall Script: ตัวบ่งชี้ที่เห็นได้ชัดเจนมากขึ้นสำหรับแพ็กเกจที่มี postinstall scripts
ปัญหา Token และแนวทางแก้ไข OIDC
การโจมตีได้เน้นย้ำปัญหาพื้นฐานกับ authentication token ที่มีอายุยาว token เหล่านี้ทำหน้าที่เป็นรหัสผ่านถาวรที่สามารถถูกขโมยและใช้ในทางที่ผิดได้ ชุมชนกำลังผลักดันให้มีการนำ Trusted Publishing โดยใช้ OpenID Connect ( OIDC ) มาใช้อย่างกว้างขวาง ซึ่งสร้าง token ที่มีอายุสั้นที่ใช้ได้เพียง 15 นาที
แม้ว่าการสนับสนุน OIDC จะมีอยู่สำหรับ NPM แต่การรวมเข้ากับเครื่องมือยอดนิยมอย่าง semantic-release ยังคงไม่สมบูรณ์ ช่องว่างระหว่างแนวปฏิบัติด้านความปลอดภัยที่ดีที่สุดและเครื่องมือเชิงปฏิบัตินี้ยังคงทำให้นักพัฒนาเสี่ยงต่อการโจมตีที่คล้ายกัน
เทคโนโลยีความปลอดภัยที่กล่าวถึง
- Trusted Publishing (OIDC): สร้างโทเค็นชั่วคราว 15 นาทีแทนการใช้ข้อมูลประจำตัวที่ใช้งานได้นาน
- NPM Provenance: ให้การรับรองว่าแพ็กเกจถูกสร้างขึ้นอย่างไร
- Two-Factor Authentication: การยืนยันตัวตนแบบสองขั้นตอนสำหรับการเผยแพร่
- GitHub Environments: การป้องกันเวิร์กโฟลว์ (ต้องมีการสมัครสมาชิก Pro)
- Semantic-release: เครื่องมือระบบอัตโนมัติยอดนิยมที่กำลังรอการรวม OIDC
บทเรียนสำหรับระบบนิเวศในวงกว้าง
เหตุการณ์นี้ทำหน้าที่เป็นสัญญาณเตือนสำหรับระบบนิเวศ JavaScript ทั้งหมด การโจมตีประสบความสำเร็จไม่ใช่ผ่านการแฮ็กที่ซับซ้อน แต่โดยการใช้ประโยชน์จากการมองข้ามความปลอดภัยพื้นฐาน - token ที่ถูกลืมในที่เก็บข้อมูลที่ใช้ร่วมกันและการควบคุมการเข้าถึงที่หลวมเกินไป มันแสดงให้เห็นว่าการตัดสินใจในการทำงานร่วมกันในอดีตสามารถสร้างช่องทางการโจมตีที่ไม่คาดคิดได้หลายปีต่อมา
การตอบสนองอย่างรวดเร็วจากทีมความปลอดภัย GitHub และ NPM ที่ระบุและลบแพ็กเกจที่เป็นอันตรายได้อย่างรวดเร็ว แสดงให้เห็นว่าระบบการตรวจจับและการตอบสนองกำลังดีขึ้น อย่างไรก็ตาม ความท้าทายพื้นฐานยังคงอยู่ คือ การป้องกันการโจมตีเหล่านี้ไม่ให้ประสบความสำเร็จตั้งแต่แรก
เหตุการณ์นี้เน้นย้ำถึงความจำเป็นในการมีค่าเริ่มต้นด้านความปลอดภัยที่ดีกว่าในระบบจัดการแพ็กเกจ คำแนะนำที่ชัดเจนกว่าเกี่ยวกับการจัดการข้อมูลประจำตัว และเครื่องมือที่ทำให้แนวปฏิบัติที่ปลอดภัยสะดวกเท่ากับแนวปฏิบัติที่ไม่ปลอดภัยในปัจจุบัน จนกว่าการปรับปรุงเหล่านี้จะถูกนำมาใช้ การโจมตีที่คล้ายกันน่าจะยังคงเป็นปัญหาต่อระบบนิเวศ JavaScript ต่อไป