ภัยคุกคามเงียบในห่วงโซ่อุปทาน: วิกฤตการขโมยข้อมูลรับรองของ npm

เกิดอะไรขึ้น

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

ผลกระทบเกิดขึ้นทันทีและแพร่หลาย ร้านอาหาร QSR รายใหญ่ที่พึ่งพาแพ็กเกจที่ถูกบุกรุกดังกล่าวสำหรับแอปพลิเคชันบนมือถือที่ลูกค้าใช้งาน พบว่าโทเค็น API ภายในของตนถูกดูดออกไป ในทำนองเดียวกัน ผู้ค้าปลีก Fortune 500 ประสบปัญหาการเข้าถึงสภาพแวดล้อมการจัดเตรียมโดยไม่ได้รับอนุญาตเนื่องจากข้อมูลรับรอง CI/CD ที่ถูกบุกรุกซึ่งเปิดเผยผ่านการอัปเดตการพึ่งพา

การโจมตีเหล่านี้ไม่ใช่ zero-days ที่ใช้ประโยชน์จากช่องโหว่ใหม่ใน Node.js หรือ npm เอง แต่เป็นการใช้ประโยชน์จากการหลอกลวงทางสังคม การยืนยันตัวตนที่อ่อนแอ หรือภัยคุกคามจากภายในต่อผู้ดูแลแพ็กเกจ เพย์โหลดที่เป็นอันตรายมักถูกทำให้สับสน ทำให้การตรวจจับทำได้ยากหากไม่มีการวิเคราะห์โค้ดเชิงลึกหรือการตรวจสอบพฤติกรรมในขณะรันไทม์

ทำไมรูปแบบนี้จึงเกิดขึ้นซ้ำๆ

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

ความเร็วในการพัฒนาและแรงกดดันในการส่งมอบฟีเจอร์มักให้ความสำคัญกับฟังก์ชันการทำงานมากกว่าการตรวจสอบความปลอดภัยอย่างละเอียดของการอัปเดตการพึ่งพาทุกครั้ง นักพัฒนามักจะรัน npm update หรือ yarn upgrade โดยไม่ได้ตรวจสอบโค้ดทุกบรรทัดในรุ่นแพตช์อย่างละเอียด โดยสันนิษฐานว่าการเพิ่มเวอร์ชันย่อยนั้นปลอดภัย รูปแบบความไว้วางใจนี้สามารถถูกใช้ประโยชน์ได้โดยธรรมชาติ

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

กลยุทธ์ของผู้โจมตีทีละขั้นตอน

ขั้นตอนที่ 1: การระบุเป้าหมายและการสอดแนม

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

ขั้นตอนที่ 2: การบุกรุกบัญชีผู้ดูแล

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

ขั้นตอนที่ 3: การฉีดโค้ดที่เป็นอันตราย

เมื่อเข้าควบคุมได้แล้ว ผู้โจมตีจะฉีดโค้ดที่ถูกทำให้สับสนเข้าไปในแพ็กเกจ โค้ดนี้มักถูกออกแบบมาให้ดูไม่เป็นอันตราย อาจเป็นฟังก์ชันยูทิลิตีเล็กๆ น้อยๆ หรือข้อความบันทึก วัตถุประสงค์หลักคือเพื่อรวบรวมตัวแปรสภาพแวดล้อม (เช่น process.env), คีย์ API, ข้อมูลรับรองคลาวด์ หรือข้อมูลลับอื่นๆ ที่แอปพลิเคชันที่กำลังทำงานเข้าถึงได้

ขั้นตอนที่ 4: การเผยแพร่แพตช์และการแพร่กระจาย

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

ขั้นตอนที่ 5: การดึงข้อมูลและการใช้ประโยชน์

โค้ดที่ถูกฉีดจะทำงานเมื่อมีการใช้แพ็กเกจที่ถูกบุกรุก มันรวบรวมข้อมูลที่ละเอียดอ่อนและส่งออกไปยังปลายทางที่ผู้โจมตีควบคุม ซึ่งมักจะปลอมตัวเป็นทราฟฟิกที่ถูกต้องตามกฎหมาย (เช่น ปลายทางวิเคราะห์ปลอม) ด้วยข้อมูลรับรองที่ถูกขโมยเหล่านี้ ผู้โจมตีจะเข้าถึงสภาพแวดล้อมคลาวด์ API ภายใน ฐานข้อมูล หรือไปป์ไลน์ CI/CD ซึ่งนำไปสู่การละเมิดหรือการขโมยข้อมูลเพิ่มเติม

สิ่งที่ผู้ป้องกันพลาดไป

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

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

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

รายการตรวจสอบการป้องกันเชิงปฏิบัติ

• ใช้การตรึงการพึ่งพาอย่างเข้มงวด: หลีกเลี่ยงช่วงเวอร์ชันกว้าง (^, ~) ใน package.json ตรึงเวอร์ชันที่แน่นอนหรือใช้ไฟล์ล็อก (package-lock.json, yarn.lock) อย่างเคร่งครัดและคอมมิตไปยังการควบคุมแหล่งที่มา ตรวจสอบและอัปเดตการพึ่งพาอย่างสม่ำเสมอผ่านกระบวนการที่มีการควบคุม
• บังคับใช้การยืนยันตัวตนแบบหลายปัจจัย (MFA) สำหรับผู้ดูแล: กำหนดให้มีการใช้ MFA ที่แข็งแกร่งสำหรับบัญชี npm, GitHub และแพลตฟอร์มการพัฒนาอื่นๆ ทั้งหมดที่ผู้ดูแลแพ็กเกจใช้ นี่คือแนวป้องกันแรกต่อการบุกรุกบัญชี
• ตรวจสอบการพึ่งพาแบบอัตโนมัติ: ผสานรวมเครื่องมือที่ทำการวิเคราะห์โค้ดเชิงลึกในการอัปเดตการพึ่งพา โดยแจ้งเตือนการเปลี่ยนแปลงที่แนะนำการเรียกเครือข่ายใหม่ การเข้าถึงระบบไฟล์ หรือโค้ดที่ถูกทำให้สับสน มองหาการเปลี่ยนแปลงพฤติกรรม ไม่ใช่แค่ลายเซ็นที่ทราบ
• การป้องกันตัวเองของแอปพลิเคชันในขณะรันไทม์ (RASP): ปรับใช้โซลูชัน RASP ที่ตรวจสอบพฤติกรรมของแอปพลิเคชันแบบเรียลไทม์และบล็อกการกระทำที่น่าสงสัย เช่น ความพยายามในการเข้าถึงตัวแปรสภาพแวดล้อมหรือการดึงข้อมูลไปยังปลายทางที่ไม่รู้จัก
• สิทธิ์ที่น้อยที่สุดสำหรับสภาพแวดล้อมการสร้าง: ตรวจสอบให้แน่ใจว่าไปป์ไลน์ CI/CD และเอเจนต์การสร้างทำงานด้วยสิทธิ์ที่จำเป็นขั้นต่ำที่สุด สภาพแวดล้อมการสร้างที่ถูกบุกรุกไม่ควรมีการเข้าถึงข้อมูลรับรองการผลิตอย่างกว้างขวาง
• เครื่องมือรักษาความปลอดภัยห่วงโซ่อุปทาน: ใช้ประโยชน์จากแพลตฟอร์มรักษาความปลอดภัยห่วงโซ่อุปทานที่เชี่ยวชาญซึ่งติดตามแหล่งที่มา ตรวจสอบความสมบูรณ์ และดำเนินการตรวจสอบส่วนประกอบโอเพนซอร์สอย่างต่อเนื่องสำหรับกิจกรรมที่น่าสงสัยหรือการเปลี่ยนแปลงผู้ดูแล
• การตรวจสอบการพึ่งพาที่สำคัญอย่างสม่ำเสมอ: สำหรับการพึ่งพาที่สำคัญที่สุดของคุณ ให้ทำการตรวจสอบโค้ดด้วยตนเองเป็นระยะ หรือจ้างนักวิจัยความปลอดภัยจากบุคคลที่สามเพื่อตรวจสอบโค้ดเบสของพวกเขาเพื่อหา backdoor หรือช่องโหว่

การทดสอบการโจมตีสมัยใหม่จะตรวจจับสิ่งนี้ได้อย่างไร

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

เมื่อตรวจพบการเผยแพร่แพตช์ที่น่าสงสัย แพลตฟอร์มดังกล่าวจะสร้าง Proof-of-Concept (PoC) ที่สามารถเรียกใช้ได้โดยอัตโนมัติ ซึ่งแสดงให้เห็นว่าโค้ดที่เป็นอันตรายสามารถดึงตัวแปรสภาพแวดล้อมเฉพาะหรือคีย์ API จากรันไทม์ของแอปพลิเคชันได้อย่างไร ข้อมูลเชิงลึกที่ดำเนินการได้ทันทีนี้ พร้อมด้วยขั้นตอนการทำซ้ำ จะแจ้งเตือนทีมรักษาความปลอดภัยก่อนที่โค้ดที่มีช่องโหว่จะถึงการผลิต ซึ่งเปลี่ยนการละเมิดที่อาจเกิดขึ้นให้กลายเป็นเหตุการณ์ที่ป้องกันได้สำเร็จ

สิ่งที่ต้องจับตาดูต่อไป

ความซับซ้อนของการโจมตีห่วงโซ่อุปทานจะยังคงเพิ่มขึ้นอย่างต่อเนื่อง คาดว่าจะมีการโจมตีที่กำหนดเป้าหมายมากขึ้นต่อแพ็กเกจโครงสร้างพื้นฐานที่เฉพาะเจาะจงแต่มีความสำคัญ การย้ายไปสู่ WebAssembly (Wasm) และสภาพแวดล้อมการดำเนินการแบบ sandboxed อื่นๆ อาจช่วยบรรเทาได้บ้าง แต่ผู้โจมตีจะปรับตัว โดยหาวิธีใหม่ๆ ในการหลุดพ้นหรือใช้ประโยชน์จาก sandbox เอง

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