อดีตพนักงาน GitHub อ้างว่าจุดอ่อนใน Node Package Manager (npm) อาจทำให้ใครก็ตามสามารถซ่อนการขึ้นต่อกันและสคริปต์ที่เป็นอันตรายภายในแพ็คเกจของตนได้

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

In โพสต์บล็อกเมื่อวันที่ 27 มิถุนายน, Darcy Clarke อดีตผู้จัดการฝ่ายวิศวกรรมพนักงานของทีมอินเทอร์เฟซบรรทัดคำสั่งของ npm ให้รายละเอียดเกี่ยวกับจุดอ่อนในไซต์ที่เขาตั้งชื่อว่า "ความสับสนอย่างชัดแจ้ง"

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

ความสับสนอย่างชัดแจ้งคืออะไร?

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

เครดิตบางส่วนไม่ได้ตกเป็นของแฮกเกอร์ — ความเสี่ยงด้านความปลอดภัย npm บางอย่างเกิดขึ้นจากวิธีการทำงานของแพลตฟอร์ม เช่นเดียวกับ ความพยายามที่ล่าช้าในการต่อต้านการพิมพ์ผิดและตอนนี้ ทำให้เกิดความสับสนอย่างชัดเจน คลาร์กกล่าว

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

มีเหตุผลที่พวกเขาควรจะตกลงร่วมกัน แต่ผู้เผยแพร่สามารถจัดการรายการของแพ็คเกจได้อย่างง่ายดาย และ npm จะไม่สังเกตเห็น ในกรณีนี้ Clarke ได้สร้างแพ็คเกจ npm ด้วย รายการ เพิกถอนหลักฐานการพึ่งพาใด ๆ ใน package.json ของมัน.

ตามทฤษฎีแล้ว แฮกเกอร์สามารถทำเช่นเดียวกันกับแพ็คเกจของตนเอง เพื่อปกปิดการมีอยู่ของมัลแวร์จากนักพัฒนาซอฟต์แวร์โดยไม่รู้ตัว

เหตุใด npm จึงไม่ตรวจสอบความถูกต้อง

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

แม้กระทั่งทุกวันนี้ “การอ้างอิงต่างๆ ใน ​​docs.npmjs.com [ชี้] ถึงข้อเท็จจริงที่ว่ารีจิสทรีจัดเก็บเนื้อหาของ package.json เป็นข้อมูลเมตา และไม่มีที่ไหนเลยที่กล่าวถึงว่าลูกค้ามีหน้าที่รับผิดชอบในการรับรองความสอดคล้องกัน” Clarke อธิบาย

เหตุใดระบบจึงทำงานในลักษณะนี้ยังไม่ชัดเจน ในขณะที่เผยแพร่ GitHub ไม่ตอบสนองต่อคำร้องขอความคิดเห็นของ Dark Reading

"[ใครจะรู้] เหตุผลที่แท้จริงที่พวกเขาเลือกทำการตรวจสอบฝั่งไคลเอ็นต์กับฝั่งเซิร์ฟเวอร์" Mike Parkin วิศวกรด้านเทคนิคอาวุโสของ Vulcan Cyber ​​กล่าว “ดูเหมือนว่าพวกเขาเลือกที่จะโน้มตัวไปสู่การเติบโตตามธรรมชาติที่ง่ายขึ้น เมื่อเทียบกับเส้นทางที่ให้ความปลอดภัยมากกว่า แต่จะส่งผลกระทบต่อความสะดวกในการใช้งาน”

ไม่มีสัญญาณใดที่แสดงว่าความสับสนจะได้รับการแก้ไขในไม่ช้า

จากข้อมูลของ Clarke GitHub ได้ตระหนักถึงจุดอ่อนของความสับสนอย่างชัดแจ้งตั้งแต่อย่างน้อยวันที่ 4 พฤศจิกายนปีที่แล้ว และ Clarke เองก็ได้ส่งรายงานเกี่ยวกับเรื่องนี้เมื่อวันที่ 9 มีนาคม อย่างไรก็ตาม “GitHub ปิดตั๋วนั้นและกล่าวว่าพวกเขากำลังจัดการกับปัญหา 'ภายใน ' เมื่อวันที่ 21 มีนาคม” เขาคร่ำครวญในการโพสต์ของเขา “ตามความรู้ของฉัน พวกเขาไม่ได้สร้างความก้าวหน้าที่สำคัญใดๆ และไม่ได้เปิดเผยปัญหานี้ต่อสาธารณะ”

แต่ “GitHub อยู่ในจุดที่ยากลำบาก” เขายอมรับ “ความจริงที่ว่า npmjs.com ทำงานในลักษณะนี้มานานกว่าทศวรรษ หมายความว่าสถานะปัจจุบันมีการประมวลผลค่อนข้างมาก”

อาจสังเกตได้ว่าคลาร์กเป็นผู้ก่อตั้ง เว็บไซต์ทางเลือกสำหรับแพ็คเกจ JavaScript, vlt.

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

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

แต่ก็ไม่จำเป็นต้องเป็นเรื่องยาก — ผู้จำหน่ายจำนวนมากได้แก้ไขปัญหานี้มาระยะหนึ่งแล้ว

“มีเครื่องมืออัตโนมัติที่สามารถสแกนโค้ดเพื่อหาคุณสมบัติที่ผิดปกติและการหาช่องโหว่ที่ชัดเจน และเครื่องมือเหล่านั้นจำเป็นต้องเป็นส่วนหนึ่งของชุดเครื่องมือของนักพัฒนา” Parkin กล่าวชี้ไปที่ รายการเครื่องมือวิเคราะห์ซอร์สโค้ดของ OWASP.

“การตรวจสอบความถูกต้องของพัสดุของคุณไม่ควรเป็นขั้นตอนทางเลือก” เขากล่าวสรุป “แต่ควรสร้างไว้ในโปรเจ็กต์การเขียนโค้ดใดๆ ก็ตามที่ต้องอาศัยไลบรารีของบุคคลที่สามแทน หยุดเต็มที่”

• เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
• PlatoData.Network Vertical Generative Ai เพิ่มพลังให้กับตัวเอง เข้าถึงได้ที่นี่.
• เพลโตไอสตรีม. Web3 อัจฉริยะ ขยายความรู้ เข้าถึงได้ที่นี่.
• เพลโตESG. ยานยนต์ / EVs, คาร์บอน, คลีนเทค, พลังงาน, สิ่งแวดล้อม แสงอาทิตย์, การจัดการของเสีย. เข้าถึงได้ที่นี่.
• BlockOffsets การปรับปรุงการเป็นเจ้าของออฟเซ็ตด้านสิ่งแวดล้อมให้ทันสมัย เข้าถึงได้ที่นี่.
• ที่มา: https://www.darkreading.com/application-security/npm-manifest-confusion-malware-hiding-weakness