แคมเปญที่รายงานโดยอ้างอิงจากโทเคน GitHub ที่ถูกขโมยและ WFX stealer กำลังทำให้รีพозиทอรีราว 66,000 แห่งตกอยู่ในความเสี่ยง ตามรายงานของ Cybernews ผู้โจมตีถูกกล่าวหาว่าใช้โทเคนการเข้าถึงที่ถูกขโมยเพื่อฝังไฟล์ workflow ที่เป็นอันตราย เปลี่ยนเส้นทางการพัฒนาให้กลายเป็นช่องทางเก็บรวบรวมความลับ รายงานที่มีอยู่นั้นสั้น ดังนั้นโพสต์นี้จึงยึดตามสิ่งที่ระบุไว้และมุ่งเน้นไปที่ขั้นตอนปฏิบัติที่นักพัฒนาสามารถทำได้ทันที

โทเคนที่ถูกขโมยเปิดทางให้การโจมตี GitHub workflow ได้อย่างไร

ตามรายงาน แคมเปญนี้ใช้โทเคนที่ถูกขโมยเพื่อเพิ่ม workflow "WFX stealer" ลงในรีพозиทอรี GitHub ประมาณ 66,000 แห่ง โทเคนคือข้อมูลรับรองที่อนุญาตให้บุคคลหรือแอปพลิเคชันดำเนินการในบัญชีโดยไม่ต้องพิมพ์รหัสผ่าน หากผู้โจมตีถือโทเคนที่ถูกต้องซึ่งมีสิทธิ์เพียงพอ GitHub จะถือว่าการกระทำของพวกเขาเป็น legitimate

นั่นคือสิ่งที่ทำให้ workflow เป็นเป้าหมายที่น่าสนใจ GitHub Actions workflow คือไฟล์ที่จัดเก็บไว้ในรีพозиทอรีซึ่งทำงานโดยอัตโนมัติ มักเข้าถึงความลับที่โปรเจกต์ใช้สำหรับการ build ทดสอบ และ deploy โค้ด workflow ที่เป็นอันตรายไม่จำเป็นต้องใช้ช่องโหว่ของซอฟต์แวร์ เพียงแค่ต้องถูก commit โดยคนที่ GitHub เชื่อว่าได้รับอนุญาต จากนั้นมันก็ทำงานภายใน pipeline

บทสรุปจากแหล่งข่าวไม่ได้ให้รายละเอียดว่าโทเคนถูกขโมยมาได้อย่างไรในตอนแรก และเราาจะไม่คาดเดา สิ่งที่สำคัญสำหรับผู้อ่านคือรูปแบบ: pipeline เองกลายเป็นกลไกในการส่งpayload และข้อมูลรับรองที่ใช้ปลดล็อกมันคือรางวัลที่แท้จริง

WFX stealer สามารถเปิดเผยอะไรได้บ้างจากบัญชีนักพัฒนา

รายงานอธิบายว่า workflow เหล่านี้เป็นตัวขโมยความลับ และมุมมองที่แนะนำระบุว่า CI/CD pipeline สามารถกลายเป็นเส้นทางสู่ความลับและบัญชีส่วนตัวของนักพัฒนาได้ ในทางปฏิบัติ stealer ที่ทำงานใน pipeline อาจอยู่ในตำแหน่งที่เข้าถึงสิ่งที่ pipeline นั้นเข้าถึงได้ ตัวอย่างทั่วไปของข้อมูลดังกล่าวรวมถึง:

  • API key และข้อมูลรับรอง cloud ที่จัดเก็บเป็น repository secret
  • Deployment token และข้อมูลรับรอง package registry
  • โทเคน GitHub อื่นๆ ที่ workflow เข้าถึงได้

ข้อมูลที่แน่ชัดที่ WFX stealer เก็บรวบรวมยังไม่ได้รับการยืนยันในข้อมูลที่เรามี ดังนั้นโปรดถือว่ารายการข้างต้นเป็นหมวดหมู่ของความเสี่ยงทั่วไปสำหรับ pipeline secret ไม่ใช่ข้อค้นพบที่ยืนยันแล้วเกี่ยวกับแคมเปญนี้ ความกังวลที่กว้างกว่าคือโทเคนที่ถูกขโมยหนึ่งตัวสามารถนำไปสู่โทเคนที่ถูกขโมยเพิ่มเติมได้ ความลับที่เก็บเกี่ยวจากรีพозиทอรีหนึ่งอาจปลดล็อกบริการอื่นๆ ซึ่งเป็นวิธีที่การ compromise รีพозиทอรีสามารถแพร่กระจายไปสู่บัญชีส่วนตัวและบัญชีขององค์กรได้

สิ่งนี้สอดคล้องกับธีมที่กว้างกว่าที่เราเคยรายงานมาก่อน: ระบบที่ผู้คนควรจะไว้วางใจกลับถูกใช้ต่อต้านพวกเขา บทวิเคราะห์ของเราเกี่ยวกับช่องโหว่ zero-click ของ Pixel และการโจมตี ScreenConnect ต่อ MSP ที่แบ่งปันด้ายอันไม่สบายใจเดียวกันนี้แสดงให้เห็นว่าเครื่องมือที่trusted มักเป็นจุดอ่อนบ่อยเพียงใด

วิธีตรวจสอบว่ารีพозиทอรีของคุณได้รับผลกระทบหรือไม่

เราไม่สามารถบอกคุณได้ว่ารีพозиทอรีเฉพาะแห่งอยู่ในรายการที่ได้รับผลกระทบหรือไม่ และรายงานที่มีอยู่ไม่ได้เผยแพร่รายการดังกล่าว คุณยังสามารถมองหาสัญญาณของการถูกแก้ไขได้ด้วยตนเอง:

  1. ตรวจสอบไฟล์ workflow เปิดโฟลเดอร์ .github/workflows ในแต่ละรีพозиทอรีและมองหาไฟล์ที่คุณไม่รู้จัก หรือการแก้ไขที่คุณไม่ได้ทำ
  2. ตรวจสอบประวัติ commit และ pull request มองหา commit หรือ branch ล่าสุดที่แตะต้อง workflow โดยเฉพาะจากบัญชีที่ไม่คุ้นเคยหรือในเวลาที่ผิดปกติ
  3. ตรวจสอบ log การทำงานของ Actions การทำงานที่ไม่คาดคิด trigger ใหม่ หรือขั้นตอนที่สร้างคำขอเครือข่ายออกภายนอกสมควรได้รับการตรวจสอบอย่างใกล้ชิด
  4. ตรวจสอบ security log และแอปที่ได้รับอนุญาต ในการตั้งค่า GitHub ตรวจสอบว่า personal access token, OAuth app และ GitHub App ใดบ้างที่มีการเข้าถึง และลบสิ่งที่คุณไม่ได้ใช้ออก
  5. ถือว่าถูกเปิดเผยหากคุณพบสิ่งใด ปฏิบัติต่อทุกความลับที่ workflow นั้นสามารถอ่านได้ว่าถูก compromise และเปลี่ยนใหม่

การเสริมความแข็งแกร่งให้ GitHub: โทเคน MFA และ Actions ของบุคคลที่สาม

ไม่มีขั้นตอนใดในเหล่านี้ที่แปลกใหม่ แต่เมื่อรวมกันแล้วจะลดสิ่งที่โทเคนที่ถูกขโมยสามารถทำได้

หมุนเวียนและลดขอบเขตโทเคน เพิกถอน personal access token เก่าและออกใหม่ด้วยขอบเขตที่แคบที่สุดและอายุสั้นที่สุดที่ใช้งานได้ โทเคนแบบ fine-grained ที่จำกัดเฉพาะรีพозиทอรีที่ระบุนั้นปลอดภัยกว่าโทเคนแบบกว้าง

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

จำกัดสิทธิ์ของ workflow ตั้งค่าโทเคน workflow เริ่มต้นเป็นแบบอ่านอย่างเดียว และให้สิทธิ์เขียนเฉพาะгдеงานจำเป็นต้องใช้จริง กำหนดให้ต้องมีการตรวจสอบก่อนที่การเปลี่ยนแปลงไฟล์ workflow จะถูก merge ตัวอย่างเช่น ผ่าน branch protection และ code owners

ตรวจสอบ Actions ของบุคคลที่สาม ปักหมุด Actions ไปยัง commit ที่เฉพาะเจาะจงแทนที่จะเป็น tag ที่เปลี่ยนแปลงได้ และเลือกใช้จากผู้ดูแลที่คุณไว้วางใจ เก็บความลับออกจากงานที่ไม่ต้องการ

สิ่งนี้หมายความว่าอย่างไรสำหรับคุณ

หากคุณดูแลโปรเจกต์แม้เพียงเล็กน้อยบน GitHub ไฟล์ workflow ของคุณเป็นส่วนหนึ่งของพื้นที่โจมตีของคุณ โทเคนที่ถูกขโมยสามารถทำให้ใครบางคนเพิ่ม workflow ที่อ่านความลับของคุณอย่างเงียบๆ และคุณอาจไม่เห็นการแจ้งเตือนเลย นักพัฒนารายบุคคล ผู้ดูแลโอเพนซอร์ส และบริษัทที่มีการ deploy อัตโนมัติล้วนอยู่ในขอบเขต

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

ข้อปฏิบัติที่นำไปใช้ได้

  • หมุนเวียนโทเคน GitHub ของคุณวันนี้และลบโทเคนที่คุณไม่ได้ใช้อีกต่อไป
  • เปิดใช้ MFA ในทุกบัญชีที่มีสิทธิ์เข้าถึงรีพозиทอรี
  • ตรวจสอบไฟล์ .github/workflows ของคุณสำหรับการเปลี่ยนแปลงที่คุณไม่ได้ทำ
  • ตั้งค่าสิทธิ์ workflow เป็นแบบอ่านอย่างเดียวโดยค่าเริ่มต้นและปักหมุด Actions ของบุคคลที่สาม
  • หากคุณพบสิ่งที่น่าสงสัย ให้เปลี่ยนทุกความลับที่ workflow นั้นสามารถเข้าถึงได้

รายงานเกี่ยวกับโทเคน GitHub ที่ถูกขโมยและ WFX stealer ยังอยู่ในระหว่างการพัฒนา และรายละเอียดอาจเปลี่ยนแปลงได้ อย่ารอการยืนยันเพื่อจัดระเบียบการตั้งค่าของคุณเอง: หมุนเวียนโทเคน เปิดใช้ MFA และตรวจสอบ workflow ของคุณวันนี้