สรุปสั้น

GitHub Actions ของ actions-cool สองตัว ได้แก่ actions-cool/issues-helper และ actions-cool/maintain-one-comment ถูกปิดการใช้งานเป็นครั้งที่สอง หลังจาก repository ทั้งคู่กลับมาเข้าถึงได้อีกเมื่อสัปดาห์ก่อน ทั้งที่ผ่านมาหลายเดือนนับจากถูกเจาะในแคมเปญ Mini Shai-Hulud เมื่อเดือนพฤษภาคม 2569 ตอนนี้เมื่อเข้าไปที่ repository ทั้งสองจะพบข้อความว่า GitHub Staff ปิดการเข้าถึงเนื่องจากละเมิดข้อกำหนดการให้บริการ ประเด็นสำคัญคือโค้ดมุ่งร้ายยังคงฝังอยู่ในโค้ดเบสและไม่เคยถูกล้างออก สิ่งเดียวที่ทำให้ภัยกลับมาทำงานคือการที่ repository ถูกเปิดให้ดาวน์โหลดได้อีกครั้ง

นาย Karlo Zanki นักวิจัยจาก Socket ระบุว่า เมื่อวันที่ 16 กันยายน 2569 repository ทั้งสองกลับมาเข้าถึงได้ โดย release tag ไม่ได้ถูกล้างก่อน มันยังชี้ไปยังเนื้อหามุ่งร้ายที่ถูกใส่เข้ามาตั้งแต่วันที่ 18 พฤษภาคม ดังนั้น workflow ใด ๆ ที่อ้าง action ทั้งสองด้วย version tag จึงกลับมาดาวน์โหลดและรัน payload อีกครั้งในการรันรอบถัดไป เนื่องจากยังมี workflow จำนวนมากที่เรียกใช้ action ทั้งสองตัวนี้ การเปิดกลับมาจึงอาจนำไปสู่ความเสี่ยงด้านความมั่นคงของ software supply chain อย่างร้ายแรง โดยที่ผู้โจมตีไม่ต้องใช้ช่องโหว่ใหม่หรือตั้งโครงสร้างพื้นฐานใหม่เลย

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 25 กันยายน 2569 ว่า GitHub Actions ของ actions-cool ทั้งสองตัวถูกปิดอีกครั้ง หลังจากกลับมาออนไลน์และรันมัลแวร์ในกลุ่มกิจกรรม Mini Shai-Hulud ต่อทันที ทั้งสอง workflow ถูกเจาะครั้งแรกเมื่อวันที่ 18 พฤษภาคม 2569 เพื่อรันโค้ดมุ่งร้ายที่เก็บเกี่ยว credential สำคัญจากไปป์ไลน์ CI/CD ที่รันมัน แล้วส่งข้อมูลออกไปยังเซิร์ฟเวอร์ที่ผู้โจมตีควบคุม กิจกรรมนี้ต่อมาถูกเชื่อมโยงเข้ากับคลัสเตอร์กิจกรรม Mini Shai-Hulud จากการที่โดเมน exfiltration (t.m-kosche[.]com) ที่ใช้ใน GitHub Actions workflow ทับซ้อนกับแพ็กเกจ npm จากระบบนิเวศ @antv

นาย Philipp Burckhardt หัวหน้าฝ่าย threat intelligence ของ Socket เคยบอกกับ The Hacker News ในตอนนั้นว่า จุดทับซ้อนนี้ชี้ไปยังคลัสเตอร์กิจกรรม Mini Shai-Hulud เดียวกัน ไม่ใช่เหตุการณ์ที่จำกัดอยู่แค่ npm แยกต่างหาก repository ถูกเปิดกลับมาอีกครั้งในวันที่ 16 กันยายน 2569 ช่วงเวลาระหว่าง 11:09 น. ถึง 18:16 น. ตามเวลา GMT+2 โดยยังไม่ทราบสาเหตุว่าเหตุใดจึงเกิดขึ้น แต่พัฒนาการล่าสุดชี้ให้เห็นปัญหาอีกด้าน นั่นคือโค้ดมุ่งร้ายยังคงอยู่ในโค้ดเบสที่ได้รับผลกระทบและไม่เคยถูกล้างออกเลย

Socket ระบุว่า action ทั้งสองทำหน้าที่จัดการ issue และคอมเมนต์แบบอัตโนมัติ เช่น ปิด issue ที่ไม่มีการเคลื่อนไหว ตรวจ issue ที่เพิ่งเปิด หรือคงคอมเมนต์ของบอตให้เป็นปัจจุบัน workflow ที่เรียกใช้มันมักรันตามตารางรายวันหรือทุกครั้งที่มีคนเปิด issue หรือ pull request ในทางปฏิบัติ repository ที่ได้รับผลกระทบส่วนใหญ่จึงน่าจะรัน payload ภายในหนึ่งวันหลังการเปิดกลับมา โดยผู้โจมตีไม่ต้องลงมือทำอะไรเพิ่มอีก

Compromised actions-cool GitHub Actions came back online and resumed executing Mini Shai-Hulud malware

วิธีการโจมตี

หัวใจของเหตุการณ์นี้อยู่ที่ mutable tag ปัญหาไม่กระทบ workflow ที่ pin action ทั้งสองไว้ที่ commit SHA แบบเต็มของเวอร์ชันก่อนวันที่ 18 พฤษภาคม 2569 แต่กระทบ workflow ที่อ้างด้วย version tag เช่น actions-cool/issues-helper@v2.2.1 เพราะ tag เหล่านั้นยังชี้ไปยังโค้ดมุ่งร้ายที่ฝังไว้ เมื่อ repository กลับมาดาวน์โหลดได้ การรันรอบถัดไปก็ดึงและรัน payload ทันที นาย Karlo Zanki อธิบายว่าเหตุการณ์ supply chain ส่วนใหญ่มักมีอะไรใหม่เข้ามาเสมอ ไม่ว่าจะเป็นเวอร์ชันมุ่งร้ายที่เพิ่งเผยแพร่ บัญชีที่เพิ่งถูกยึด หรือ workflow ที่เพิ่งถูก inject เข้ามา แต่ครั้งนี้ไม่มีเลย ไม่มีการเผยแพร่โค้ดใหม่และไม่มีการเปลี่ยน configuration ใด ๆ

เขาย้ำว่าเหตุการณ์นี้แสดงให้เห็นว่า mutable tag สามารถถูกเจาะ ถูกควบคุม แล้วถูกเปิดกลับมาทำงานได้อีก โดยไม่ต้องมีการเปลี่ยนแปลงใด ๆ ในไฟล์ workflow ของเราเอง การ pin ด้วย SHA จึงช่วยตัดการพึ่งพาสถานะของ repository ต้นทางออกไป

ผลกระทบ

องค์กรและนักพัฒนาที่ใช้ actions-cool/issues-helper หรือ actions-cool/maintain-one-comment ผ่าน version tag ในไปป์ไลน์ CI/CD คือกลุ่มเสี่ยงโดยตรง เพราะ payload ที่เก็บเกี่ยว credential กลับมาทำงานได้เองทันทีเมื่อ repository ถูกเปิด โดยไม่ต้องรอผู้โจมตีลงมือ ความเสียหายจึงพุ่งไปที่ secret ในไปป์ไลน์ เช่น โทเคน, กุญแจ cloud และ credential ต่าง ๆ ที่อาจถูกส่งออกไปยังเซิร์ฟเวอร์ของผู้โจมตี กรณีนี้ยังสะท้อนบทเรียนเชิงโครงสร้างว่า การพึ่งพา mutable tag ในการอ้าง third-party action ทำให้ความปลอดภัยของไปป์ไลน์ขึ้นอยู่กับสถานะของ repository ภายนอกที่เราควบคุมไม่ได้

คำแนะนำ

นักพัฒนาควรค้นหาทุกจุดที่อ้างถึง action ที่ได้รับผลกระทบ และให้ถือว่า actions-cool/issues-helper@v2.2.1 เป็นเวอร์ชันที่ได้รับผลกระทบ จากนั้นให้นำ action ออกแล้ว pin ใหม่ไปยัง SHA ที่ทราบว่าสะอาดและเป็นเวอร์ชันก่อนวันที่ 18 พฤษภาคม 2569 พร้อมทั้งหมุนเวียน secret ที่อาจรั่วไหลทั้งหมด นอกจากนี้ควรตรวจสอบประวัติการรัน workflow ว่ามีการรันที่สำเร็จขึ้นใหม่หลังจากช่วงที่ขั้นตอน Set up job ล้มเหลวมานานหรือไม่ และตรวจสอบประวัติ repository ว่ามี commit ที่ไม่คาดคิดหลังวันที่ 16 กันยายน 2569 หรือไม่ โดยหลักปฏิบัติที่ยั่งยืนที่สุดคือการ pin third-party action ด้วย commit SHA แบบเต็มเสมอ

แหล่งอ้างอิง