มัลแวร์โอเพนซอร์ส: ปัญหา

เหตุใดโครงสร้างพื้นฐานจึงเอื้อต่อการโจมตีได้ง่ายเช่นนี้?

ทะเบียนแพ็กเกจ โดยทั่วไปแล้ว GitHub เปิดกว้างและมักต้องการการตรวจสอบตัวตนของผู้เผยแพร่เพียงเล็กน้อย “ใครก็ได้สามารถเผยแพร่ซอฟต์แวร์ของตนที่นี่ได้!” อุปสรรคสำหรับผู้โจมตีนั้นต่ำมาก พวกเขาใช้ที่อยู่อีเมลแบบใช้แล้วทิ้งและบัญชี GitHub แบบใช้แล้วทิ้งเพื่อสร้างแพ็กเกจที่เป็นอันตรายหลายร้อยรายการในแคมเปญสั้นๆ คล้ายกับการหลอกลวงทางอีเมล เฉพาะในกรณีที่เป็นเป้าหมายเฉพาะเท่านั้นที่จำเป็นต้องใช้ความซับซ้อนมากขึ้น: เราพบเห็นแม้กระทั่งการสร้างที่เก็บซอร์สโค้ด GitHub ที่น่าเชื่อถือพร้อมดาวจำนวนมากและ... commitคะแนนจากผู้ร่วมให้ข้อมูลปลอมหลายรายและตัวชี้วัดความนิยมและการบำรุงรักษาอื่นๆ การได้รับ นักดูดาวและชื่อเสียงที่ได้มาจากการบริจาคปลอม การทำให้เป็นระบบอัตโนมัติไม่ใช่เรื่องยาก เราพบเห็นการละเมิดโครงสร้างพื้นฐานซอฟต์แวร์แบบเปิดทุกประเภท ไม่ใช่แค่เพียงมัลแวร์เท่านั้น เช่น เหตุการณ์พิธีชงชา.

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

ความสัมพันธ์ระหว่างส่วนประกอบต่างๆ นั้นซ้อนกันและก่อตัวเป็นกราฟ ในระบบนิเวศบางอย่าง เช่น Node (JavaScript) ความสัมพันธ์เล็กๆ น้อยๆ อาจสะสมกันเป็นร้อยหรือพันๆ รายการ การควบคุมความสัมพันธ์โดยตรงที่ประกาศโดยโครงการซอฟต์แวร์ของฉันอย่างเข้มงวดเป็นเรื่องหนึ่ง แต่... การพึ่งพาแบบส่งต่อ ควบคุมได้ยากกว่า ซอฟต์แวร์โอเพนซอร์สยึดหลัก “เพื่อนของเพื่อนก็คือเพื่อน” ความเป็นพี่น้องเป็นเรื่องปกติในดินแดนตะวันออกไกลที่ป่าเถื่อน! ผู้ก่อภัยคุกคามรู้เรื่องนี้และซ่อนพฤติกรรมที่เป็นอันตรายไว้ในส่วนประกอบที่ซับซ้อนซึ่งมักไม่เป็นที่รู้จัก นี่คือกรณีของ... สตรีมเหตุการณ์ เหตุการณ์ที่มุ่งเป้าไปที่ กระเป๋าเงิน Copay. 

นี่คือวิธีการทำงานของซอฟต์แวร์โอเพนซอร์สมาตั้งแต่เริ่มต้น และมันจะไม่เปลี่ยนแปลงมากนัก บางแหล่งจัดเก็บแพ็กเกจอาจต้องการการยืนยันตัวตนแบบสองขั้นตอนเป็นอย่างดีที่สุด และมักจะใช้เฉพาะกับแพ็กเกจยอดนิยมเท่านั้น บางแหล่งจัดเก็บแพ็กเกจให้สิทธิ์การเข้าถึงแบบขอบเขต (scopes) ซึ่งเป็นเนมสเปซที่องค์กรที่ได้รับการตรวจสอบแล้วเป็นเจ้าของ แต่... อนาถ ส่วนแพลตฟอร์มอื่นๆ ไม่รองรับ (PyPI) หรือกำหนดให้เป็นตัวเลือกเสริม (NPM)  เป็นเรื่องน่าสนใจที่จะสังเกตว่าแม้แต่... แผนการคัดกรองแบบง่าย (โดยอิงจากการควบคุม DNS หรือที่เก็บ/องค์กร GitHub ที่ตรงกับรหัสกลุ่ม) และทำให้ ลายเซ็น PGP เป็นสิ่งที่จำเป็น สำหรับอาร์ติแฟกต์ทั้งหมด ยกเว้นเช็คซัม จะช่วยกำจัด "สิ่งรบกวน" ส่วนใหญ่ เช่น แพ็กเกจที่เป็นอันตรายที่คล้ายกับการปลอมแปลงชื่อโดเมน และจำกัดสิ่งต่างๆ มากมาย ความสับสนในการพึ่งพาการโจมตีที่ซับซ้อนนั้นเป็นไปได้ แต่ยากกว่ามาก โดยมีเพียงไม่กี่กรณีเท่านั้น เช่น... com.github.codingandcoding:maven-compiler-plugin เป็นที่รู้จักกันดีในชื่อ Maven Central และไม่ใช่ว่าทุก Maven registry จะปฏิบัติตามแนวทางเดียวกันทั้งหมด!

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

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

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

“เราให้ความสำคัญกับความปลอดภัยเป็นอย่างยิ่ง”