คำเตือนภัยการยึดครองโครงการโอเพนซอร์สผ่านวิศวกรรมสังคม

 (openssf.org)
3 คะแนน โดย GN⁺ 2024-05-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

OpenJS และ OpenSSF ออกประกาศเตือนภัยเรื่องความเสี่ยงการโจมตีแบบ Social Engineering ต่อโครงการโอเพนซอร์ส

  • ความพยายามแทรกซึมแบบ backdoor ใน XZ Utils (CVE-2024-3094) เมื่อเร็ว ๆ นี้อาจไม่ใช่เหตุการณ์ที่เกิดขึ้นอย่างโดดเดี่ยว
  • จากข้อมูลที่ OpenJS Foundation ดูเหมือนจะปิดกั้นความพยายามยึดครองที่มีลักษณะน่าเชื่อถือและคล้ายกัน จึงอาจไม่ใช่เหตุการณ์ที่แยกตัวเดี่ยว
  • OpenSSF และ OpenJS Foundation เรียกร้องให้ผู้ดูแลโครงการโอเพนซอร์สทุกคนเฝ้าระวังความพยายามยึดครองแบบ Social Engineering สังเกตรูปแบบภัยคุกคามตั้งแต่ต้น และลงมือปกป้องโครงการโอเพนซอร์สของตน

ความพยายามยึดครองที่ล้มเหลว

  • คณะกรรมการ Cross Project Council ของ OpenJS Foundation ได้รับชุดอีเมลที่น่าสงสัยซึ่งมีข้อความคล้ายกัน
  • ผู้เขียนอีเมลกดดันให้ OpenJS ดำเนินการอัปเดตโครงการ JavaScript ยอดนิยมหนึ่งตัวเพื่อ “แก้ไขช่องโหว่ที่สำคัญ” แต่ไม่ระบุรายละเอียด
  • ผู้เขียนอีเมลขอให้ตนเองได้รับการแต่งตั้งเป็นผู้ดูแลใหม่ของโครงการ แม้ว่าก่อนหน้านี้แทบไม่มีส่วนร่วมกับโค้ด
  • แนวทางนี้คล้ายกับวิธีที่ "Jia Tan" จัดวางตัวเองในการเข้ายึด XZ/liblzma
  • OpenJS ไม่ได้ให้สิทธิ์เข้าถึงสำหรับบุคคลเหล่านี้กับโครงการที่ OpenJS โฮสต์
  • โครงการที่ OpenJS โฮสต์มีนโยบายความปลอดภัยอยู่แล้ว รวมถึงสิ่งที่คณะทำงานความปลอดภัยของมูลนิธิอธิบายเป็นแนวโน้มหลักไว้
  • ทีม OpenJS ยังกังวลต่อรูปแบบน่าสงสัยที่คล้ายกันในอีกสองโครงการ JavaScript ยอดนิยมที่ไม่อยู่ภายใต้การโฮสต์ของมูลนิธิ และได้แจ้งต่อผู้บริหาร OpenJS และ CISA ของสำนักงานความมั่นคงโครงสร้างพื้นฐานและความปลอดภัยทางไซเบอร์ (CISA) ใน DHS ทันทีเมื่อพบปัญหาความมั่นคงที่อาจเกิดขึ้น

แบบแผนที่น่าสงสัยของการยึดครองแบบ Social Engineering

  • แบบแผน
    • ผู้มีส่วนร่วมในชุมชนที่ค่อนข้างไม่คุ้นเคยทำการขอร้องต่อผู้ดูแลหรือองค์กรผู้โฮสต์ (มูลนิธิหรือบริษัท) อย่างเป็นมิตรแต่กดดันและดื้อรั้น
    • ขอให้ผู้คนที่ใหม่มากหรือไม่คุ้นเคยได้รับการแต่งตั้งเป็นผู้ดูแล
    • ได้รับการสนับสนุนจากสมาชิกชุมชนคนอื่นที่อาจใช้ตัวตนปลอม (หรือที่เรียกว่า "sock puppets")
    • PR ที่มี Blob อยู่ใน artifact
    • โค้ดต้นฉบับที่ทำให้เข้าใจยากหรือทำให้เข้าใจยากโดยเจตนา
    • ปัญหาความปลอดภัยค่อย ๆ รุนแรงขึ้น
    • เสี่ยงต่อการแทรก payload อันตรายภายนอกเข้าไปใน Blob, Zip หรือ artifact binary อื่น ๆ ซึ่งอยู่นอกแนวปฏิบัติทั่วไปของการคอมไพล์ build และกระจายโปรเจกต์
    • โดยเฉพาะในกรณีที่ผู้ดูแลถูกเร่งรัดให้เร่งรีบจนลดความละเอียดในการตรวจสอบหรือถูกชักจูงให้หลีกเลี่ยงการควบคุม
  • การโจมตี Social Engineering เหล่านี้ใช้ความภักดี/ความผูกพันของผู้ดูแลต่อโครงการและชุมชนเป็นเครื่องมือบงการ
  • สังเกตความรู้สึกที่เกิดขึ้นจากการปฏิสัมพันธ์
    • ความรู้สึกที่ทำให้เกิดความสงสัยในตัวเอง ความอับอาย หรือความรู้สึกว่าตัวเองไม่สามารถมีส่วนร่วมในโครงการได้มากพอ อาจเป็นส่วนหนึ่งของการโจมตี Social Engineering
  • การโจมตี Social Engineering ลักษณะเดียวกับใน XZ/liblzma ถูกป้องกันโดยชุมชน OpenJS อย่างมีประสิทธิภาพ
  • ลักษณะการโจมตีเช่นนี้ตรวจจับหรือป้องกันเชิงโปรแกรมได้ยาก เนื่องจากอาศัยการละเมิดความไว้วางใจผ่าน Social Engineering
  • ในระยะสั้น การแชร์กิจกรรมที่น่าสงสัยที่กล่าวถึงด้านบนอย่างชัดเจนและโปร่งใสจะช่วยให้ชุมชนอื่นคงความตื่นตัวไว้ได้
  • การดูแลผู้ดูแลอย่างเหมาะสมเป็นมาตรการยับยั้งสำคัญต่อการโจมตีแบบ Social Engineering

ขั้นตอนสำหรับความปลอดภัยโครงการโอเพนซอร์ส

  • พิจารณาใช้แนวปฏิบัติด้านความปลอดภัยที่เป็นมาตรฐานของอุตสาหกรรม เช่น OpenSSF Guide
  • ใช้การยืนยันตัวตนที่แข็งแกร่ง: 2FA, ตัวจัดการรหัสผ่าน, เก็บ recovery code ในที่ปลอดภัย และอย่าใช้รหัสผ่าน/ข้อมูลรับรองซ้ำกันข้ามบริการ
  • จัดเตรียมนโยบายความปลอดภัยที่รวมกระบวนการ coordinated disclosure
  • ใช้แนวปฏิบัติที่ดีที่สุดเมื่อรวมโค้ดใหม่
    • เปิดใช้งานการป้องกันสาขาและ commit ที่มีการเซ็นชื่อ
    • โดยเฉพาะหากเป็นไปได้ ให้มีนักพัฒนาคนที่สองตรวจสอบ PR ก่อนผสาน แม้ PR จะมาจากผู้ดูแลก็ตาม
    • ใช้ข้อกำหนดด้านความอ่านง่ายให้ PR ใหม่ไม่ถูกทำให้ซับซ้อน และลดการใช้ binary ที่ไม่โปร่งใสให้น้อยที่สุด
    • จำกัดผู้ที่ได้รับสิทธิ์การเผยแพร่ผ่าน npm
    • ระบุผู้ส่งโค้ดและผู้ดูแลและทำการทบทวนเป็นระยะ ตัวอย่างเช่น เคยเห็นพวกเขาในที่ประชุมกลุ่มงานหรือพบเจอในงานอีเวนต์หรือไม่
  • หากคุณดำเนินการจัดการ repository ของแพ็กเกจโอเพนซอร์ส ควรพิจารณาใช้หลักการสำหรับ Package Repository Security
  • ทบทวนบทความของ CISA เรื่อง "การหลีกเลี่ยงการโจมตี Social Engineering และ phishing" และ/หรือของ ENISA เรื่อง "Social Engineering คืออะไร"

มาตรการร่วมของอุตสาหกรรมและรัฐบาลเพื่อความปลอดภัยของโครงสร้างพื้นฐานโอเพนซอร์สที่สำคัญ

  • แรงกดดันในการรักษาโครงการโอเพนซอร์สให้คงเสถียรและปลอดภัยสร้างแรงกดดันต่อผู้ดูแลเช่นกัน
  • ความร่วมมือระดับนานาชาติระหว่างภาครัฐและเอกชนจำเป็นเพื่อจัดสรรทรัพยากรขนาดใหญ่
  • มูลนิธิและสถาบันอย่าง Open Source Foundations, Sovereign Tech Fund และหน่วยงานอื่น ๆ หลายแห่งกำลังทำงานได้ดีอยู่แล้ว
  • จำเป็นต้องมีความพยายามขององค์กรลักษณะคล้ายมูลนิธิในตระกูล Linux Foundation ในการสร้าง safety net ให้กับโครงการโอเพนซอร์ส
  • การลงทุนของรัฐบาลเยอรมนีผ่าน Sovereign Tech Fund ในโครงสร้างพื้นฐานโอเพนซอร์สที่สำคัญเป็นสัญญาณที่ให้ความหวัง
  • สนับสนุนให้มีการเพิ่มการลงทุนสาธารณะในวงกว้างทั่วโลกต่อ initiative แบบ Sovereign Tech Fund ของเยอรมนีมากขึ้น

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

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

บทความที่เกี่ยวข้อง

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

 
GN⁺ 2024-05-06
ความคิดเห็นบน Hacker News

สรุป:

  • ในฐานะผู้ดูแลโครงการโอเพนซอร์ส ฉันจึงรู้สึกระแวดระวัง PR จากผู้สมทบรายใหม่มากขึ้น
    • แม้ดูเหมือนดีภายนอก แต่ควรคาดไว้เสมอว่ามีอาจมีเจตนาแอบแฝง
  • ซอฟต์แวร์มีความซับซ้อนเพิ่มขึ้นตามกาลเวลาเมื่อเพิ่มฟีเจอร์มาอย่างต่อเนื่อง
    • โค้ดยากต่อความเข้าใจมากขึ้นจนคนเพียงไม่กี่คนเท่านั้นที่เข้าใจได้
    • เมื่อผู้พัฒนาที่มีประสบการณ์เกษียณตัวไป ส่วนสำคัญของโปรเจกต์ก็อาจเหลือเพียงคนไม่กี่คนที่เข้าใจได้
  • โครงการขนาดใหญ่ต้องการระบบรายงานการเปลี่ยนแปลงของผู้ดูแล
    • ควรถูกซิงก์ร่วมกับเวอร์ชัน/รีลีส และแพ็กเกจอย่าง npm.js หรือแพ็กเกจ Debian
    • เช่นกรณีของธนาคารในยุโรป หน่วยงานในหลายประเทศควรมีสิทธิ์เฝ้าตรวจสอบได้
  • ต้องระวังแบบเดียวกับเกม Eve Online ที่เป็นผู้สมทบที่มีคุณค่าแล้วได้รับความไว้วางใจ ก่อนจะหักหลังในภายหลัง
  • ควรใช้ 2FA/MFA เฉพาะในระบบที่โฮสต์เองเท่านั้น
    • หากใช้กับระบบ third-party และเสียช่องทางยืนยันตัวตนรอบที่สอง อาจถูกล็อกออกอย่างถาวร
    • การโฮสต์โปรเจกต์เองช่วยให้ไม่สูญเสียการควบคุม
  • ในโอเพนซอร์สจะมีการถกเถียงที่ลำบากระหว่างความครอบคลุมและความปลอดภัยระยะยาว
    • นักพัฒนาบางส่วนจากอิหร่าน รัสเซีย และจีนถูกตั้งข้อสงสัยอยู่แล้ว
    • การ fork และร่วมสมทบกับประเทศพันธมิตรอาจเป็นทางเลือกที่ดีกว่า
    • ฝ่ายตรงข้ามสามารถผสานการเปลี่ยนแปลงกับโค้ดต้นฉบับได้โดยไม่ต้องกังวลเรื่อง license หรือ copyright
  • แต่ละโปรเจกต์ควรตั้งเกณฑ์ของตัวเอง และตัด dependency ที่ไม่ได้รับการบำรุงรักษาออกอย่างรวดเร็ว
    • การประเมินความอ่อนไหวของโปรเจกต์ก็เป็นเรื่องที่ควรพิจารณา
  • หลังเหตุการณ์โจมตี XZ ก็ทำให้คิดถึงว่ามีแนวโน้มเกิดการโจมตีแบบนี้บ่อยแค่ไหน
    • โอเพนซอร์สอาจเปราะบางมากกว่าซอฟต์แวร์ปิดซอร์ส
    • เพราะทุกคนสามารถเขียนโค้ดได้ และอาจมีแรงจูงใจที่ไม่ดี
  • การทบทวนพฤติกรรมของโปรเจกต์โอเพนซอร์สเดิมๆ ดูเหมือนว่าค่อนข้างยาก
  • รณรงค์มานานว่าควรเน้นสถาปัตยกรรมแบบเรียบง่ายและปรับปรุงมาตรฐานการเขียนโค้ด
    • แต่ผู้คนกลับใช้ TypeScript, React ฯลฯ แล้วเพิ่ม dependency ที่ไม่จำเป็นมากขึ้นเรื่อยๆ
    • ศัตรูเย้ยหยันความไม่รู้และความไร้เดียงสาของเรา
    • ทั้งอุตสาหกรรมทั้งหมด รวมถึงระบบการเมือง อาจถูก compromise แล้ว
  • คนควรเลือกโปรเจกต์ที่มีโค้ดและ dependency น้อยที่สุด
    • โปรเจกต์ที่สะอาดถูกพรากโอกาสและความสนใจ ขณะที่โปรเจกต์ที่ออกแบบเกินจำเป็นกลับพุ่งเข้าหน้า
    • ตอนนี้พวกเขากลายเป็นเป้าหมายที่ง่ายของผู้กระทำความร้ายแล้ว
    • ซ่อนช่องโหว่ไว้ในความซับซ้อนนั้นทำได้ง่ายเกินไป