1 คะแนน โดย GN⁺ 2024-03-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

พบบัญชีเก็บโค้ดที่ติดมัลแวร์มากกว่า 100,000 แห่งบน GitHub

  • ทีมวิจัยด้านความปลอดภัยและวิทยาศาสตร์ข้อมูลตรวจพบว่ามีการกลับมาของแคมเปญ repo confusion ที่เป็นอันตรายในวงกว้าง ซึ่งเริ่มต้นมาตั้งแต่ช่วงกลางปีที่แล้ว
  • การโจมตีนี้ส่งผลต่อบัญชีเก็บโค้ดบน GitHub มากกว่า 100,000 แห่ง (และคาดว่าอาจมีถึงหลายล้านแห่ง) เมื่อเหล่านักพัฒนาใช้งานรีโพซิทอรีที่ดูคล้ายกับรีโพซิทอรีที่เชื่อถือได้และเป็นที่รู้จัก แต่แท้จริงแล้วมีโค้ดอันตรายแฝงอยู่

การโจมตีแบบ repo confusion เกิดขึ้นได้อย่างไร?

  • การโจมตีแบบ repo confusion คล้ายกับการโจมตีแบบ dependency confusion โดยผู้ไม่หวังดีทำให้เป้าหมายดาวน์โหลดเวอร์ชันอันตรายแทนเวอร์ชันจริง
  • ขณะที่การโจมตีแบบ dependency confusion อาศัยวิธีการทำงานของ package manager การโจมตีแบบ repo confusion กลับอาศัยการที่ผู้คนเผลอเลือกเวอร์ชันอันตรายแทนเวอร์ชันจริง และบางครั้งก็ใช้เทคนิค social engineering ด้วย

เมื่อมีการใช้งานรีโพซิทอรีอันตรายจะเกิดอะไรขึ้น

  • เมื่อนักพัฒนาใช้งานรีโพซิทอรีอันตรายโดยไม่สงสัย payload ที่ซ่อนอยู่จะคลายชั้นการ obfuscation 7 ขั้น แล้วดึงโค้ด Python อันตรายและต่อด้วยไฟล์ปฏิบัติการแบบไบนารี
  • มัลแวร์จะรวบรวมข้อมูลรับรองการเข้าสู่ระบบของแอปต่าง ๆ รหัสผ่านและคุกกี้ของเบราว์เซอร์ รวมถึงข้อมูลลับอื่น ๆ แล้วส่งไปยังเซิร์ฟเวอร์ C&C ของผู้ไม่หวังดี พร้อมดำเนินกิจกรรมอันตรายเพิ่มเติม

ผลกระทบของระบบอัตโนมัติบน GitHub

  • รีโพซิทอรีที่ถูก fork ส่วนใหญ่จะถูก GitHub ลบออกอย่างรวดเร็ว แต่การตรวจจับแบบอัตโนมัติยังพลาดหลายรีโพซิทอรี และรีโพซิทอรีที่อัปโหลดด้วยตนเองยังคงรอดอยู่
  • เนื่องจากห่วงโซ่การโจมตีทั้งหมดส่วนใหญ่ถูกทำให้เป็นอัตโนมัติในระดับใหญ่ แม้เพียง 1% ที่รอดอยู่ก็ยังหมายถึงรีโพซิทอรีอันตรายนับพันแห่ง

แคมเปญนี้เริ่มขึ้นเมื่อใด

  • พฤษภาคม 2023: ตามรายงานแรกของ Phylum มีการอัปโหลดแพ็กเกจอันตรายหลายรายการไปยัง PyPI โดยมีส่วนต้นของ payload ปัจจุบันรวมอยู่ด้วย
  • กรกฎาคม - สิงหาคม 2023: หลังจาก PyPI ลบแพ็กเกจอันตรายออกและชุมชนด้านความปลอดภัยให้ความสนใจกับเรื่องนี้มากขึ้น ก็มีการอัปโหลดรีโพซิทอรีอันตรายหลายแห่งไปยัง GitHub โดยเปลี่ยนจากการดึงแพ็กเกจจาก PyPI มาเป็นส่ง payload โดยตรงแทน
  • พฤศจิกายน 2023 - ปัจจุบัน: ตรวจพบรีโพซิทอรีมากกว่า 100,000 แห่งที่มี payload อันตรายในลักษณะคล้ายกัน และจำนวนยังคงเพิ่มขึ้นอย่างต่อเนื่อง

การย้ายของมัลแวร์จาก package manager ไปยัง source code management (SCM)

  • จากหลายเหตุการณ์ที่พบทั้งบน package manager และแพลตฟอร์ม SCM ดูเหมือนว่าการที่แคมเปญนี้เปลี่ยนจากแพ็กเกจอันตรายใน PyPI ไปเป็นรีโพซิทอรีอันตรายใน GitHub สะท้อนแนวโน้มโดยรวมที่กำลังเกิดขึ้น

วิธีป้องกันตัวเองจาก repo confusion

  • แม้จะมีการแจ้ง GitHub แล้วและรีโพซิทอรีอันตรายส่วนใหญ่ถูกลบออกไป แต่แคมเปญนี้ยังดำเนินต่อไป และการโจมตีที่พยายามฝังโค้ดอันตรายลงในซัพพลายเชนก็ยิ่งพบได้บ่อยขึ้น
  • Apiiro ได้สร้างระบบตรวจจับมัลแวร์ที่คอยเฝ้าติดตาม codebase ที่เชื่อมต่ออยู่
  • ระบบนี้ใช้เทคนิคขั้นสูงหลากหลายในการตรวจจับการโจมตี ซึ่งรวมถึงการวิเคราะห์โค้ดด้วย LLM การแยกโค้ดออกเป็น execution flow graph แบบสมบูรณ์ heuristic engine ขั้นสูง การถอดรหัสแบบไดนามิก การถอดรหัสลับ และการคลายการ obfuscation เป็นต้น

ความเห็นของ GN⁺

  • บทความนี้ให้ข้อมูลสำคัญเพื่อเตือนนักพัฒนาเกี่ยวกับภัยคุกคามด้านความปลอดภัยที่ต้องระวังเมื่อใช้งานรีโพซิทอรีบน GitHub
  • การเข้าใจวิธีที่มัลแวร์แทรกซึมเข้าสู่ซอฟต์แวร์ซัพพลายเชน จะช่วยให้นักพัฒนาและผู้เชี่ยวชาญด้านความปลอดภัยสร้างกลไกป้องกันที่แข็งแกร่งยิ่งขึ้นได้
  • การโจมตีลักษณะนี้ยังตอกย้ำว่าผู้พัฒนาต้องพึ่งพาทั้งความสามารถในการเลือกรีโพซิทอรีที่เชื่อถือได้ ความถูกต้องของการตั้งค่า CI/CD และความปลอดภัยของโค้ดจากบุคคลที่สาม
  • หากมองอย่างวิพากษ์ การโจมตีนี้แสดงให้เห็นว่าระบบอัตโนมัติของแพลตฟอร์มอย่าง GitHub และการมีอยู่ของรีโพซิทอรีจำนวนมหาศาลนั้นอาจเป็นดาบสองคมได้
  • เครื่องมือด้านความปลอดภัยที่มีความสามารถใกล้เคียงกัน ได้แก่ SonarQube, Snyk และ WhiteSource ซึ่งสามารถช่วยตรวจจับช่องโหว่ในโค้ดและเสริมความปลอดภัยได้
  • ก่อนนำเทคโนโลยีนี้มาใช้ ควรพิจารณานโยบายความปลอดภัยขององค์กร ความเข้ากันได้ ต้นทุนการนำไปใช้ และความสามารถทางเทคนิคของสมาชิกในทีม
  • ประโยชน์ของการเลือกใช้เทคโนโลยีนี้คือการยกระดับความปลอดภัยและลดความเสี่ยง แต่ข้อเสียที่อาจเกิดขึ้นคือช่วงการเรียนรู้ของระบบใหม่และความซับซ้อนในการดูแลจัดการ

1 ความคิดเห็น

 
GN⁺ 2024-03-01
ความคิดเห็นบน Hacker News
  • ควรระมัดระวังเมื่อดึงโค้ดจากรีโพสาธารณะ และการตรวจสอบ dependency tree เป็นสิ่งสำคัญ เรื่องนี้ยังตั้งคำถามว่ามัลแวร์ในรีโพสาธารณะจะส่งผลต่อเครื่องมืออัตโนมัติอย่างโมเดลภาษา (Large Language Models, LLMs) อย่างไร ตัวอย่างเช่น เครื่องมืออย่าง GitHub Copilot อาจเผลอรวมมัลแวร์ไว้ในคำตอบสำหรับคำถามด้านการเขียนโค้ดได้
  • มีการชี้ว่า GitHub กำลังล้มเหลวในแบบเดียวกับที่ Usenet เคยล้มเหลว ใครก็สร้างรีโพบน GitHub ได้ และไม่มีวิธีแยกแยะระหว่างรีโพทางการกับรีโพของสแปมเมอร์ได้ชัดเจน เมื่อ Amazon ตั้งเป้าเป็น "ร้านที่ขายทุกอย่าง" ก็ต้องเผชิญปัญหาว่าสินค้าส่วนใหญ่เป็นขยะ GitHub จำเป็นต้องกำหนดตัวตนให้ชัดว่าเป็น "รีโพสำหรับทุกคน" หรือเป็นที่ที่ตอบคำถามว่า "โค้ดนี้เชื่อถือได้หรือไม่"
  • มีการบ่นว่าปัญหา supply chain ร้ายแรงมาก แม้จะไม่ได้เล็งเป้าไปที่ npm release แต่ก็ใช้ socket.dev เพื่อติดตามโครงการ โปรเจ็กต์ BrowserBox ใช้ dependency ราว 800 ตัว โดย 19 ตัวเป็น top-level dependency และกำลังพิจารณาวิธี snapshot dependency ทั้งหมดไว้ในเนมสเปซ @browserbox ของ npm เพื่อติดตามช่องโหว่และออกแพตช์
  • เน้นว่านักพัฒนาควรแยกอย่างน้อยสามสภาพแวดล้อมสำหรับงาน งานอดิเรก และการใช้งานส่วนตัว แม้แต่รีโพและเจ้าของที่เชื่อถือได้ ก็ควรรันโค้ดใน sandbox virtual machine เพื่อความรอบคอบ
  • หากกำลังพัฒนา SDK ในทีมเล็ก ๆ ที่มีจำนวนดาวน์โหลดต่อสัปดาห์สูง ก็กำลังประเมินโซลูชันอย่าง snyk, aikido.dev และโซลูชันที่อิงกับ renovate อยู่ แต่ยังไม่ชัดว่าเครื่องมือเหล่านี้จะช่วยแก้ปัญหาได้จริงหรือไม่ และการต้องรับมือกับ false positive จำนวนมากอย่างที่เคยเจอใน snyk ก็เป็นเรื่องยาก
  • มีการตั้งคำถามว่าวิธีติดตั้งผ่านเชลล์สคริปต์ด้วย curl และ sudo ใกล้ถึงจุดจบหรือไม่ วิธีนี้เกี่ยวข้องอย่างใกล้ชิดกับซอฟต์แวร์ติดเชื้อที่กล่าวถึงในบทความ
  • บน npm สามารถใช้ตัวเลือก --ignore-scripts เพื่อป้องกันการรันมัลแวร์ได้
  • มีการกล่าวถึงว่าภายในเวลาไม่ถึง 1 ปี เคยมีรีโพที่แฝงไวรัสโทรจันอยู่
  • มีการวิจารณ์ว่าข้อความล่าสุดเกี่ยวกับปัญหาความปลอดภัยกลับพาไปสู่โฆษณาให้ระดมทุนแก่สตาร์ตอัป LLM ทั้งที่สตาร์ตอัปเหล่านี้แก้ได้เพียงบางส่วนของช่องว่างด้านความปลอดภัย และการทำสัญญากับสตาร์ตอัปจำนวนมากก็อาจก่อให้เกิดปัญหาเรื่องต้นทุนและการรวมระบบ
  • จากรายงานด้านความปลอดภัยที่ออกมาอย่างต่อเนื่อง จึงค่อย ๆ ปรับปรุงความปลอดภัยของสภาพแวดล้อมการพัฒนา เช่น ลองใช้ VSCode dev container, GitHub Codespaces, อ่านแนวทางของ OWASP และรีวิวแพ็กเกจ npm/Python ด้วย socket.dev