เจาะเหตุการณ์ Grafana ถูกแฮ็ก GitHub Token และการพยายามรีดค่าไถ่ซอร์สโค้ด

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

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

เหตุการณ์นี้สะท้อนแนวโน้มใหม่ของการโจมตีไซเบอร์ที่มุ่งเป้าไปยัง โครงสร้างพื้นฐานสำหรับนักพัฒนา (developer infrastructure) เช่น GitHub, access tokens และระบบ CI/CD

เกิดอะไรขึ้นในการเจาะระบบ Grafana

Grafana Labs ระบุว่าผู้โจมตีสามารถเข้าถึง GitHub access token ซึ่งให้สิทธิ์เข้าถึงบางส่วนของสภาพแวดล้อม GitHub ของบริษัท จากนั้นจึงใช้ token นี้ดาวน์โหลดซอร์สโค้ดจากรีโพซิทอรีส่วนตัวได้สำเร็จ

การสืบสวนภายหลังพบว่าต้นตอของปัญหามาจาก ช่องโหว่ใน GitHub Actions workflow ผู้โจมตีใช้เทคนิค fork repository แล้วแทรกคำสั่งเพื่อดึง environment variables รวมถึง credentials ออกจากสภาพแวดล้อมของ workflow

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

หลังตรวจพบเหตุการณ์ Grafana ได้:

• ยกเลิกและหมุน (revoke/rotate) token ที่ถูกเปิดเผย
• ปิดการทำงานของ workflow ที่มีช่องโหว่
• เพิ่มมาตรการรักษาความปลอดภัยเพิ่มเติมในระบบพัฒนา

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

แฮ็กเกอร์เรียกค่าไถ่ซอร์สโค้ด

หลังจากได้ซอร์สโค้ดไปแล้ว ผู้โจมตีติดต่อ Grafana เพื่อเรียกค่าไถ่ โดยเสนอว่าจะไม่เผยแพร่โค้ดที่ขโมยมา หากบริษัทจ่ายเงินตามที่เรียกร้อง

รูปแบบนี้เรียกว่า "pay‑or‑leak" extortion ซึ่งกำลังแพร่หลายในโลกอาชญากรรมไซเบอร์ แทนที่จะล็อกระบบเหมือน ransomware แบบดั้งเดิม ผู้โจมตีจะขโมยข้อมูลก่อน แล้วใช้การขู่เปิดเผยข้อมูลเป็นแรงกดดัน

Grafana เลือกที่จะ ไม่จ่ายค่าไถ่

ทำไม Grafana ถึงปฏิเสธการจ่ายเงิน

จากผลการตรวจสอบ บริษัทระบุว่า ไม่มีหลักฐานว่าข้อมูลลูกค้า ข้อมูลส่วนบุคคล หรือระบบโปรดักชันได้รับผลกระทบ จากเหตุการณ์นี้

นอกจากนี้ยังไม่พบผลกระทบต่อการดำเนินธุรกิจหรือบริการของลูกค้า ทำให้แรงกดดันจากผู้โจมตีมีจำกัด

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

ใครอาจอยู่เบื้องหลังการโจมตี

จนถึงตอนนี้ยังไม่มีการยืนยันอย่างเป็นทางการว่าใครเป็นผู้ก่อเหตุ การระบุตัวผู้โจมตียังอยู่ในสถานะ ไม่สามารถยืนยันได้แน่ชัด

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

กลุ่มประเภทนี้มักเน้นการ ขโมยข้อมูลแล้วนำไปขายหรือขู่เปิดเผย มากกว่าการเข้ารหัสระบบแบบ ransomware แบบเดิม

ถึงอย่างนั้น ก็ยัง ไม่มีหลักฐานยืนยันว่า ShinyHunters อยู่เบื้องหลังเหตุการณ์ของ Grafana

ผลกระทบต่อผู้ใช้และระบบ

Grafana ยืนยันว่าผลกระทบจากเหตุการณ์นี้มีขอบเขตจำกัด โดยการตรวจสอบภายในระบุว่า

• ไม่มีข้อมูลลูกค้าหรือข้อมูลส่วนบุคคลถูกเข้าถึง
• ระบบโปรดักชันไม่ได้ถูกเจาะ
• การดำเนินธุรกิจและบริการไม่ได้รับผลกระทบ

ผลกระทบที่ยืนยันได้มีเพียง การดาวน์โหลดซอร์สโค้ดจากรีโพซิทอรี GitHub ส่วนตัว เท่านั้น

ทำไมเหตุการณ์นี้สำคัญต่อความปลอดภัยของซัพพลายเชนซอฟต์แวร์

แม้จะไม่มีข้อมูลลูกค้าถูกขโมย แต่ ซอร์สโค้ดของบริษัทก็มีมูลค่าสูงมาก สำหรับผู้โจมตี

รีโพซิทอรีส่วนตัวอาจเผยให้เห็นข้อมูลสำคัญ เช่น

• สถาปัตยกรรมระบบภายใน
• แนวทางด้านความปลอดภัยและการจัดการ credentials
• ฟีเจอร์ที่ยังไม่เปิดตัว
• ช่องโหว่ที่สามารถใช้โจมตีในอนาคต

ด้วยเหตุนี้ โครงสร้างพื้นฐานสำหรับการพัฒนาซอฟต์แวร์ เช่น GitHub repositories, access tokens และ CI/CD pipelines จึงกลายเป็นเป้าหมายที่น่าสนใจมากขึ้นสำหรับผู้โจมตี

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

เมื่อบริษัทจำนวนมากพึ่งพาแพลตฟอร์มพัฒนาแบบคลาวด์มากขึ้น เหตุการณ์ลักษณะนี้จึงเป็นบทเรียนสำคัญว่า การปกป้อง credentials และ pipeline สำหรับนักพัฒนา กลายเป็นส่วนสำคัญของความปลอดภัยในซัพพลายเชนซอฟต์แวร์ยุคใหม่