กลยุทธ์ซัพพลายเชนซอฟต์แวร์เพื่อปัดป้องการโจมตีที่สับสนจากการพึ่งพา

กลยุทธ์ซัพพลายเชนซอฟต์แวร์เพื่อปัดป้องการโจมตีที่สับสนจากการพึ่งพา

Software Supply Chain Strategies to Parry Dependency Confusion Attacks PlatoBlockchain Data Intelligence. Vertical Search. Ai.

“What’s in a name? That which we call a rose By any other name would smell as sweet.” When Shakespeare wrote these words (Romeo and Juliet, Act 2, Scene 2) in 1596, he was saying that a name is just a convention. It has no intrinsic meaning. Juliet loves Romeo for who he is, not for his name.

But without knowing it, Shakespeare was also describing dependency confusion attacks.

ความสับสนในการพึ่งพาเกิดขึ้นเมื่อแพ็คเกจที่คุณใช้ในโค้ดไม่ใช่ของคุณ พวกเขามีชื่อเดียวกัน แต่ไม่ใช่รหัสของคุณที่ใช้งานจริง ชื่อเดียวกัน แต่ห่อหนึ่งมีกลิ่นคล้ายดอกกุหลาบ ส่วนอีกห่อหนึ่ง…มีกลิ่นเหม็น

Recent research reports estimate that 41% to 49% of organizations are at risk for dependency confusion attacks. New research from OX Security shows that when an organization is at risk for a dependency confusion attack, 73% of its assets are vulnerable. The research focused on midsize and large organizations (1K+, 8K+, 80K+ employees) across a wide range of sectors — finance, gaming, technology, and media — and found the risk in every sector across organizations of all sizes. The research also found that almost all applications with more than 1 billion users are using dependencies that are vulnerable to dependency confusion.

บทความนี้มีวัตถุประสงค์เพื่อช่วยให้คุณเข้าใจความสับสนในการขึ้นต่อกันและวิธีป้องกัน

ดับเบิ้ล,ดับเบิ้ล

Dependencies (also called packages) are the building blocks of your software. Typically these pieces of software, whether developed by entire communities or within a company, perform a common and necessary task.

Package managers are frequently used to install dependencies and keep them updated. They scan public and private registries for the name of the package and, all other things being equal, select the highest version number. Attackers take advantage of this by placing a “dummy” package on the public registry with the same name but higher version.

When a package manager comes across two identical packages, one in a public registry and one in a private registry, it causes confusion — hence the name “dependency confusion.” Since the two packages are identical, the manager will automatically choose to install the one with a higher version - in this case, the attacker’s malicious package.

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

งานหนักและปัญหา

มีหลายวิธีในการโจมตีแบบสับสนในการพึ่งพา

  • การเว้นวรรค โดยการอัปโหลดไลบรารีซอฟต์แวร์ที่เป็นอันตรายไปยังรีจิสทรีสาธารณะ เช่น Python Package Index (PyPI) หรือ JavaScript รีจิสทรี npm - นั่นคือ มีชื่อคล้ายกัน ไปยังไลบรารี่ที่ใช้ภายในที่เชื่อถือได้ ระบบที่ละเว้นการตรวจสอบเนมสเปซ/URL หรือไม่บังคับให้ดึงข้อมูลจากรีจิสทรีส่วนตัวอาจดึงโค้ดที่เป็นอันตรายเข้ามาโดยไม่ได้ตั้งใจ ที่ เหตุการณ์ความสับสนในการพึ่งพา PyTorch ล่าสุด เป็นตัวอย่างหนึ่งดังกล่าว
  • การปลอมแปลง DNS ด้วยการใช้เทคนิค เช่น การปลอมแปลง DNS ระบบสามารถถูกสั่งให้ดึงการขึ้นต่อกันจากที่เก็บข้อมูลที่เป็นอันตราย ขณะเดียวกันก็แสดงสิ่งที่ดูเหมือน URL/เส้นทางภายในที่ถูกต้องตามกฎหมาย
  • การเขียนสคริปต์ By modifying build/install scripts or continuous integration/continuous delivery (CI/CD) pipeline configurations, systems can be tricked into downloading software dependencies from a malicious source rather than a local repository.

Things Done Well and With a Care

เพื่อป้องกันความสับสนในการพึ่งพา ให้จัดทำแนวทางปฏิบัติเหล่านี้

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

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

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

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

สิ่งสำคัญคือต้องทราบว่าการลงทะเบียนแพ็กเกจบางรายการไม่อนุญาตให้ผู้ใช้จองชื่อแพ็กเกจ ดังนั้น ตรวจสอบให้แน่ใจว่าคุณพบชื่อที่จองได้

ทางออก ไล่ตามโดยหมี

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

Shakespeare’s roses may have presaged the risk of dependency confusion attacks by hundreds of years, but another quote from the Bard may hold some wisdom for protecting against them: “Let every eye negotiate for itself and trust no agent.” (Much Ado About Nothing, Act 2, Scene 1)

ประทับเวลา:

เพิ่มเติมจาก การอ่านที่มืด