การโจมตี Megalodon บุก 5,561 รีโพซิทอรี GitHub ภายในหกชั่วโมง

การโจมตีซัพพลายเชน CI/CD บน GitHub ที่มีชื่อว่า Megalodon ได้สร้างมาตรฐานใหม่สำหรับการโจมตีรีโพซิทอรีขนาดใหญ่แบบอัตโนมัติ ในช่วงเวลาเพียงหกชั่วโมง ผู้โจมตีได้ผลักดันการอัปเดตโค้ดที่เป็นอันตรายถึง 5,718 ครั้ง ครอบคลุม 5,561 รีโพซิทอรีบน GitHub โดยใช้ตัวตนปลอมในการแทรกไฟล์ workflow ที่ออกแบบมาเพื่อดูดข้อมูล cloud credentials, SSH keys และความลับในซอร์สโค้ดอย่างเงียบๆ ความเร็วและปริมาณของแคมเปญนี้บ่งชี้ถึงการเปลี่ยนแปลงไปสู่การโจมตี pipeline แบบอุตสาหกรรมที่เกินความสามารถของทีมส่วนใหญ่ในการตรวจจับหรือตอบสนองแบบเรียลไทม์

วิธีการทำงานของการโจมตี Megalodon: ตัวตนปลอมและการแทรก Workflow อัตโนมัติ

ผู้โจมตีเบื้องหลัง Megalodon ไม่ได้พึ่งพาช่องโหว่ zero-day หรือมัลแวร์ที่ซับซ้อนที่ส่งถึงเครื่องของผู้ใช้ปลายทาง แต่กลับใช้ประโยชน์จากความน่าเชื่อถือของโครงสร้างพื้นฐาน CI/CD ของ GitHub เอง ด้วยการสร้างตัวตนผู้มีส่วนร่วมปลอม พวกเขาส่ง pull request หรือแก้ไขไฟล์การตั้งค่า workflow โดยตรง โดยเฉพาะไฟล์ YAML ที่ GitHub Actions ใช้กำหนด pipeline การ build และ deployment อัตโนมัติ

เมื่อไฟล์ workflow ที่เป็นอันตรายเข้าไปในรีโพซิทอรีแล้ว มันจะทำงานโดยอัตโนมัติทุกครั้งที่ pipeline ถูกเรียกใช้งาน โดยทั่วไปคือเมื่อมีเหตุการณ์ push หรือการ merge pull request การทำงานนั้นเกิดขึ้นภายในสภาพแวดล้อม runner ของ GitHub เอง ซึ่งมักมีสิทธิ์เข้าถึง repository secrets, environment variables และ token ที่ผูกกับ cloud provider Megalodon ใช้ช่วงเวลาการเข้าถึงนั้นในการส่งข้อมูลออกไปภายนอก ซึ่งน่าจะไปยังโครงสร้างพื้นฐานที่อยู่ภายใต้การควบคุมของผู้โจมตี ก่อนที่ผู้ดูแลรีโพซิทอรีใดจะมีเหตุผลที่จะตรวจสอบการเปลี่ยนแปลง

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

ข้อมูลรับรองใดถูกขโมยและเหตุใดจึงสำคัญสำหรับนักพัฒนา

payload ของแต่ละ workflow ที่เป็นอันตรายคือการเก็บเกี่ยวข้อมูลรับรอง เป้าหมายรวมถึง cloud provider credentials โดยส่วนใหญ่คือ AWS, GCP และ Azure access keys ที่เก็บเป็น GitHub Secrets หรืออ้างอิงภายใน workflow environment variables นอกจากนี้ยังมี SSH private keys ที่ใช้สำหรับการเข้าถึงเซิร์ฟเวอร์หรือการตรวจสอบตัวตนระหว่างบริการ รวมถึงความลับ plaintext ที่ฝังอยู่ในซอร์สโค้ดหรือไฟล์การตั้งค่า

ประเภทของข้อมูลรับรองเหล่านั้นมีความเสี่ยงที่เป็นห่วงโซ่ AWS access key ที่ถูกขโมยซึ่งผูกกับ IAM role ที่มีสิทธิ์กว้างขวางสามารถอนุญาตให้ผู้โจมตีสร้างโครงสร้างพื้นฐาน ดึงข้อมูลออกจาก data store หรือเคลื่อนย้ายตัวเองไปยังบริการที่เชื่อมต่อได้ภายในไม่กี่นาที SSH keys สามารถให้การเข้าถึง production server อย่างต่อเนื่องนานหลังจากที่ตรวจพบการละเมิดครั้งแรกและรีโพซิทอรี GitHub ได้รับการทำความสะอาดแล้ว มูลค่าของข้อมูลนี้ขยายออกไปไกลเกินกว่าตัวรีโพซิทอรีเอง

นี่ไม่ใช่รูปแบบความเสี่ยงสมมุติ ในช่วงต้นปีนี้ ผู้รับเหมา CISA เปิดเผย AWS keys และรหัสผ่าน plaintext บน GitHub สาธารณะ ซึ่งแสดงให้เห็นว่าการจัดการ credentials ผิดพลาดในสภาพแวดล้อมการพัฒนาส่งผลกระทบแม้แต่กับองค์กรที่มีคำสั่งด้านความปลอดภัยโดยเฉพาะ Megalodon เพียงแค่ทำให้เส้นทาง exploit เดียวกันที่ข้อผิดพลาดของมนุษย์แต่ละคนแสดงให้เห็นซ้ำแล้วซ้ำเล่ากลายเป็นอุตสาหกรรม

นอกจากนี้ยังควรสังเกตว่าเครื่องมือและ pipeline การขโมยข้อมูลรับรองเองก็เป็นเป้าหมาย การโจมตีซัพพลายเชน Bitwarden CLI ล่าสุดแสดงให้เห็นว่าแม้แต่เครื่องมือที่นักพัฒนาใช้จัดการความลับก็สามารถถูกโจมตีได้จากต้นน้ำ ซึ่งหมายความว่าห่วงโซ่ความน่าเชื่อถือขยายออกไปเกินกว่ารีโพซิทอรีหรือการตั้งค่า pipeline ใดๆ

การป้องกันเชิงลึกสำหรับทีมพัฒนา: การจัดการ Secrets, การสื่อสารที่เข้ารหัส และการควบคุมการเข้าถึง

Megalodon ใช้ประโยชน์จากจุดอ่อนหลายประการที่พบได้ทั่วไปทั้งในรีโพซิทอรี open source และรีโพซิทอรีส่วนตัว การแก้ไขจุดเหล่านั้นต้องใช้วิธีการแบบหลายชั้นแทนที่จะเป็นการควบคุมเดียว

ประการแรก ความลับไม่ควรเก็บเป็น plaintext ภายในไฟล์ workflow, ไฟล์การตั้งค่า environment หรือซอร์สโค้ด ฟีเจอร์ Secrets ที่เข้ารหัสของ GitHub ให้พื้นฐาน แต่ความลับเหล่านั้นควรปฏิบัติตามหลักการของสิทธิ์น้อยที่สุดด้วย Workflow ที่ deploy ไปยังสภาพแวดล้อม staging ไม่จำเป็นต้องมี production database credentials การจำกัดขอบเขตของความลับอย่างเคร่งครัดจะลดรัศมีความเสียหายเมื่อ workflow ถูกโจมตี

ประการที่สอง กฎการป้องกัน branch และ reviewer ที่จำเป็นสำหรับการเปลี่ยนแปลงไฟล์ workflow สร้างจุดตรวจสอบโดยมนุษย์ที่การโจมตีอัตโนมัติต้องหลีกเลี่ยง การกำหนดให้มีการอนุมัติอย่างน้อยหนึ่งครั้งก่อนการแก้ไขใดๆ ต่อไฟล์ .github/workflows/ สามารถชะลอหรือบล็อกการแทรกอัตโนมัติอย่างรวดเร็วที่ Megalodon พึ่งพา

ประการที่สาม การ pin third-party GitHub Actions ไว้กับ commit SHA เฉพาะแทนที่จะเป็น floating tag จะป้องกัน attack vector ที่แยกออกมาแต่เกี่ยวข้องกัน ซึ่ง action publisher ที่ถูกโจมตีอัปเดต tag อย่างเงียบๆ เพื่อชี้ไปที่โค้ดที่เป็นอันตราย นี่เป็นกลไกในเหตุการณ์ซัพพลายเชน GitHub Actions หลายครั้งล่าสุด

สุดท้าย การบันทึก audit และการตรวจจับความผิดปกติบน workflow run สามารถเปิดเผยการเชื่อมต่อเครือข่ายขาออกที่ไม่คาดคิดหรือรูปแบบการเข้าถึง secret ที่ผิดปกติ GitHub audit log API และเครื่องมือความปลอดภัย CI/CD ของบุคคลที่สามสามารถช่วยแสดงสัญญาณเหล่านี้

วิธีตรวจสอบรีโพซิทอรี GitHub และ CI/CD Pipeline ของคุณในตอนนี้

หากองค์กรของคุณดูแลรีโพซิทอรี GitHub ที่มี CI/CD pipeline ที่ใช้งานอยู่ มีขั้นตอนเร่งด่วนบางอย่างที่ควรให้ความสำคัญ

ตรวจสอบไฟล์ทั้งหมดภายใต้ .github/workflows/ สำหรับรายการที่เพิ่มหรือแก้ไขเมื่อไม่นานมานี้ โดยเฉพาะอย่างยิ่งที่เพิ่มโดยผู้มีส่วนร่วมที่คุณไม่รู้จัก ตรวจสอบประวัติ commit สำหรับไฟล์ workflow โดยเฉพาะ ไม่ใช่แค่มุมมอง default branch

หมุนเวียนความลับใดๆ ที่ใช้งานอยู่ในช่วงเวลาของการโจมตีหรือที่คุณไม่สามารถยืนยันได้อย่างมั่นใจว่าไม่ได้ถูกเปิดเผย สำหรับ cloud credentials ให้ตรวจสอบ access log ฝั่ง provider สำหรับการเรียก API ที่ผิดปกติในช่วงเวลาเดียวกัน

ตรวจสอบว่า repository contributor และแอปพลิเคชันใดมีสิทธิ์เขียน การโจมตีด้วยตัวตนปลอมขึ้นอยู่กับความสามารถในการผลัก code ดังนั้นการเพิ่มความเข้มงวดของสิทธิ์ผู้มีส่วนร่วมและเปิดใช้งาน required reviews สำหรับการเปลี่ยนแปลง workflow จะลบจุดเข้าหลัก

สุดท้าย พิจารณาใช้เครื่องมือสแกน secrets เฉพาะทางที่ทำงานบนทุก commit เพื่อดักจับข้อมูลรับรองก่อนที่จะถูก commit ไปยังรีโพซิทอรี ตัวเลือก open source และเชิงพาณิชย์หลายตัวสามารถรวมเข้ากับ GitHub ได้โดยตรง

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

แคมเปญ Megalodon เป็นตัวอย่างที่ชัดเจนของเหตุผลที่ CI/CD pipeline ได้กลายเป็นพื้นที่การโจมตีหลัก นักพัฒนาและทีมความปลอดภัยที่ปฏิบัติต่อความปลอดภัยของ pipeline เป็นรองความปลอดภัยของแอปพลิเคชันกำลังเปิดทางกว้างไปสู่ข้อมูลรับรองที่ละเอียดอ่อนที่สุดของพวกเขา

เริ่มต้นด้วยการตรวจสอบ secrets ในสัปดาห์นี้ ตรวจสอบว่าใครสามารถแก้ไขไฟล์ workflow ของคุณ หมุนเวียนข้อมูลรับรองที่คุณไม่สามารถยืนยันว่าปลอดภัย และเปิดใช้งานการป้องกัน branch บน default branch ของคุณหากยังไม่ได้ทำ ความเร็วของการโจมตี Megalodon หมายความว่าเมื่อถึงเวลาที่การแจ้งเตือนส่งสัญญาณ การดูดข้อมูลอาจเสร็จสิ้นไปแล้ว การป้องกันและการจำกัดขอบเขตการเข้าถึงเป็นการป้องกันที่เชื่อถือได้เพียงอย่างเดียว