ในตอนที่แล้ว มัลแวร์โอเพนซอร์ส: ปัญหาเราได้หารือกันว่าทำไมผู้ก่อภัยคุกคามจึงกระทำเช่นนั้น มีความกระตือรือร้นในการเผยแพร่ส่วนประกอบที่เป็นอันตรายใหม่ๆ หรือแทรกมัลแวร์ในเวอร์ชันล่าสุดของส่วนประกอบที่มีอยู่: โครงสร้างพื้นฐานแบบโอเพนซอร์สทำให้ทุกคนทุกแห่งสามารถสร้างบัญชีชั่วคราวได้ ในระบบจัดเก็บส่วนประกอบ (เช่น NPM, PyPI, Docker Hub หรือ Visual Studio Marketplace) หรือแพลตฟอร์มการพัฒนาร่วมกัน (เช่น GitHub) ไม่มีค่าใช้จ่าย และมีโอกาสมากมายในการใช้ประโยชน์จากความไว้วางใจที่ทีมพัฒนาซอฟต์แวร์มักมีต่อส่วนประกอบของบุคคลที่สาม
ความไม่สมดุลระหว่างความง่ายในการที่ผู้โจมตีจะเผยแพร่ซอฟต์แวร์ที่เป็นอันตรายโดยใช้โครงสร้างพื้นฐานที่มีอยู่สำหรับโอเพนซอร์ส กับความยากลำบากสำหรับองค์กรที่พัฒนาซอฟต์แวร์ (ทุกคน?) ในการหลีกเลี่ยงการติดซอฟต์แวร์ที่เป็นอันตราย (และในการส่งซอฟต์แวร์ที่เป็นอันตรายไปพร้อมกับซอฟต์แวร์ที่พวกเขาแจกจ่ายให้ผู้อื่น) ส่งผลให้จำนวนแพ็กเกจที่เป็นอันตรายเกือบถึง 250,000 รายการเมื่อปีที่แล้ว
นี่เป็นปัญหาที่มีขนาดใหญ่มากจนไม่มีองค์กรใดองค์กรเดียวสามารถแก้ไขได้ และชุมชนกำลังอยู่ในกระบวนการปรับเปลี่ยนกรอบกระบวนการโอเพนซอร์สเกี่ยวกับความไว้วางใจ หลักการรักษาความปลอดภัยโดยค่าเริ่มต้นและการรักษาความปลอดภัยโดยการออกแบบ และวงจรชีวิตของส่วนประกอบต่างๆ เราจะมาดูแนวคิดเหล่านี้ในตอนต่อไป การป้องกันมัลแวร์โอเพนซอร์ส: อะไรได้ผล (และอะไรไม่ได้ผล).
โปรดจำไว้ว่าเรากำลังพูดถึงส่วนประกอบซอฟต์แวร์ ซึ่งส่วนใหญ่แล้วจะสอดคล้องกับ แพคเกจซอฟต์แวร์: ส่วนประกอบที่นำกลับมาใช้ใหม่ได้ ซึ่งถูกบรรจุไว้เพื่อให้สามารถอ้างอิงเป็นส่วนประกอบที่จำเป็นในไฟล์ manifest ของซอฟต์แวร์ และติดตั้งได้ด้วยตัวจัดการแพ็กเกจหรือเครื่องมือสร้างโปรแกรม โปรดทราบว่ากรณีนี้สามารถขยายไปรวมถึงส่วนประกอบสาธารณะได้ ภาพคอนเทนเนอร์ (ใช้โดยรันไทม์คอนเทนเนอร์และแพลตฟอร์มการจัดการ เช่น Kubernetes) และ ส่วนเสริมสำหรับเครื่องมือซอฟต์แวร์ (สำหรับการสร้าง การทำงานอัตโนมัติ และการใช้งาน)
ในที่นี้เราจะวิเคราะห์ว่าสิ่งนี้เป็นอย่างไร กลยุทธ์การโจมตีที่อิงตามส่วนประกอบที่เป็นอันตราย จากตัวอย่างในอดีตและสิ่งที่เราได้เห็นในแพลตฟอร์มการแจ้งเตือนมัลแวร์ล่วงหน้าของเรา พบว่าใช้งานได้ผล (MEW) เราจะวิเคราะห์ส่วนประกอบที่เป็นอันตรายในมิติต่างๆ:
(1) วิธีการที่เลือกสำหรับการแจกจ่าย (ใช้รีจิสทรีในส่วนประกอบใหม่หรือที่มีอยู่ และเทคนิคที่ใช้ในการแพร่เชื้อเวอร์ชันส่วนประกอบที่เผยแพร่)2) วิธีการเปิดใช้งานหรือกระตุ้นมัลแวร์ (3) พฤติกรรมที่เป็นอันตราย เช่น การกระทำที่เป็นอันตรายที่สังเกตได้และแรงจูงใจของผู้โจมตี (4) เทคนิคที่ใช้กันทั่วไปสำหรับการปกปิด การซ่อนตัวเพื่อไม่ให้ถูกสังเกต การเคลื่อนที่ด้านข้าง การสื่อสารกับโฮสต์คำสั่งและควบคุม (C2) เป็นต้น และ (5) เทคนิคในการสร้างความนิยมและความไว้วางใจให้มากพอจนเหยื่อติดตั้งส่วนประกอบนั้นในที่สุด
กลไกการกระจายที่เลือกใช้
เราสังเกตเห็น “เสียงพื้นหลัง“แพ็กเกจที่เป็นอันตรายแบบไม่ซับซ้อนใช้กลโกง typosquatting เพื่อหลอกลวงนักพัฒนาที่ไม่ระมัดระวังด้วยการใส่คำผิดในชื่อแพ็กเกจของส่วนประกอบที่จำเป็น แพ็กเกจยอดนิยมจำนวนมากได้รับแพ็กเกจที่มีชื่อคล้ายกันแต่มีคำผิดจำนวนมาก โดยคาดหวังว่าจะหลอกลวงนักพัฒนาที่ไม่ระมัดระวังบางราย”
พวกเขาใช้บัญชีชั่วคราว เผยแพร่แพ็กเกจ typosquat กลุ่มหนึ่ง สร้างอีกกลุ่มหนึ่ง แล้วเผยแพร่อีกกลุ่มหนึ่ง… โดยใช้ระบบอัตโนมัติและความชาญฉลาด พวกเขาสามารถสร้างความซับซ้อนได้บ้าง แต่โดยทั่วไปแล้วค่อนข้างเรียบง่าย ภายในเราเรียกพวกเขาว่า “ปลาแองโชวี่เป้าหมายหลักคือการขโมยข้อมูลประจำตัว แต่บางครั้งเราก็พบว่าสปายแวร์สามารถขโมยซอร์สโค้ดหรือข้อมูลสำคัญ เช่น ข้อมูลส่วนบุคคล (PII) บันทึกข้อมูลในคลิปบอร์ด และสิ่งที่ไม่พึงประสงค์อื่นๆ ได้
จู่ๆ เราก็เห็นส่วนประกอบที่เป็นอันตรายที่ซับซ้อนมากขึ้น หรือที่เรียกว่า “ฉลาม” ส่วนน้อยจะมุ่งเป้าไปที่กลุ่มหรือองค์กรเฉพาะ โดยมักจะเป็นโปรแกรมดูดคริปโตหรือโปรแกรมขโมยข้อมูลเว็บไซต์ที่ทำงานตามเงื่อนไขบางอย่าง อาจจะใช้วิธีการเดียวกับที่เห็นในกรณีอื่นๆ เหตุการณ์สตรีมเหตุการณ์ โดยจะถอดรหัสเพย์โหลดการโจมตีก็ต่อเมื่อมีการอ้างอิงแพ็กเกจนั้นจากแพ็กเกจเป้าหมายเท่านั้น
กลไกการกระจายตัวได้รับการวิเคราะห์ในบทความที่ยอดเยี่ยมและเป็นที่ยอมรับในปัจจุบันเรื่อง “ชุดมีดของคนทรยศ: บทวิจารณ์การโจมตีห่วงโซ่อุปทานซอฟต์แวร์โอเพนซอร์สซึ่งเป็นสิ่งที่ควรค่าแก่การอ่านอย่างยิ่ง คุณคงเคยเห็นแผนภูมิที่สวยงามนี้มาก่อนแล้ว:
มีการสำรวจทุกช่องทาง รวมถึงแพ็กเกจใหม่และที่มีอยู่เดิม การโจมตีที่ส่งผลกระทบต่อซอร์สโค้ด ระบบการสร้าง หรือส่วนประกอบที่บรรจุอยู่ในแพ็กเกจเอง การใช้ข้อมูลประจำตัวที่ถูกขโมยหรือการหลอกลวงทางสังคม การยึดบัญชีและที่เก็บข้อมูลที่ถูกทิ้งร้าง หรือการปนเปื้อนบัญชีและที่เก็บข้อมูลที่ได้รับการดูแลรักษา การโจมตีบางอย่างได้รับชื่อ (การพิมพ์ดีด, ความสับสนในการพึ่งพา, ความสับสนที่ปรากฏชัด, การยึดทรัพย์(เป็นต้น) และได้มีการกล่าวถึงไปแล้วในที่อื่น
แล้วฐานข้อมูลที่เลือกไว้ล่ะ?
NPM ยังคงเป็นผู้นำในจำนวนแพ็กเกจที่เป็นอันตรายโดยรวม แต่เราพบว่ามีจำนวนเพิ่มขึ้นอย่างมากใน PyPI ตั้งแต่ปีนี้เป็นต้นไป Python เป็นระบบนิเวศยอดนิยมสำหรับวิทยาศาสตร์ข้อมูลและการเรียนรู้ของเครื่อง อันที่จริง ความหนาแน่นของมัลแวร์ใน PyPI สูงกว่าใน NPM แล้ว
มัลแวร์ถูกกระตุ้นให้ทำงานได้อย่างไร
ในกรณีการติดตั้ง แพ็กเกจที่เป็นอันตรายจะถูกเรียกใช้งานเพียง 4 ใน 10 ครั้งเท่านั้น (ในช่วงไม่กี่ปีมานี้ใกล้เคียงกับ 6 ใน 10 ครั้ง) ส่วนที่เหลือจะทำงานผิดปกติในระหว่างการทำงานจริง โดย 1 ใน 100 ครั้งจะถูกเรียกใช้งานในระหว่างการทดสอบ ดูเหมือนว่าผู้โจมตีจะรู้ว่าการเรียกใช้งานสคริปต์การติดตั้งโดยไม่ได้รับการควบคุมนั้นถูกปิดใช้งานในหลาย ๆ ที่แล้ว
พวกตัวร้ายได้อะไรบ้าง?
เราจะแสดงรายการประเภทของพฤติกรรมที่เป็นอันตราย โดยเริ่มจากประเภทที่พบได้บ่อยที่สุดก่อน โปรดทราบว่าผลกระทบอาจแตกต่างกันอย่างมาก: ก. เครื่องเช็ด การโจมตีแบบนี้สร้างความเสียหายอย่างร้ายแรง แต่ก็ไม่พบเห็นบ่อยนัก และมักพบเห็นเพียงไม่กี่กรณีที่เกี่ยวข้องกับการโจมตีทางไซเบอร์แบบเจาะจงเป้าหมาย หรือการแฮ็กเพื่อการเคลื่อนไหวทางการเมืองอย่างโหดเหี้ยม ประเภทที่พบเห็นได้บ่อยมีดังต่อไปนี้:
- InfoSealer / Credentials Drainerการโจมตีที่ไม่ซับซ้อนส่วนใหญ่กว่า 90% เป็นการโจมตีแบบขโมยข้อมูลอย่างง่าย ซึ่งส่วนใหญ่จะมุ่งเป้าไปที่ข้อมูลประจำตัว เช่น รหัสผ่าน โทเค็นการเข้าถึง คีย์ API และคีย์ส่วนตัว (สำหรับ SSH และอื่นๆ) การโจมตีประเภทนี้เขียนได้ง่ายที่สุด (เช่นเดียวกับการโจมตีแบบลบข้อมูล?) มันจะตรวจสอบไฟล์/ไดเร็กทอรีที่รู้จักและแหล่งข้อมูลอื่นๆ (เช่น คีย์รีจิสทรี) บรรจุเนื้อหา และส่งไปยังเซิร์ฟเวอร์ C2 แนวคิดนั้นง่ายมาก: “ฉันสร้างโปรแกรมขโมยข้อมูลประจำตัวเพื่อใช้ในการฟิชชิ่ง เพื่อที่ฉันจะได้ใช้ข้อมูลประจำตัวเหล่านั้นในการโจมตีเป้าหมายในภายหลัง”
เครือข่าย C2 ที่พบเห็นโดยทั่วไปมักเป็นแบบราคาถูกและไม่ประณีต เช่น ช่องทาง Telegram หรือ เครื่องมือขุดอุโมงค์คล้ายเอ็นโกรก (มักอยู่ในรูปแบบของพร็อกซีแบบย้อนกลับที่เปิดเผยผ่าน IP ขาออกของ VPN) มีความเป็นไปได้นับร้อย (!) แบบ โดยมีโปรเจกต์มากมายบน GitHub ภายใต้ชื่อดังกล่าว หัวข้อผู้ขโมยรหัสผ่านการทำงานเฉพาะทาง เช่น โปรแกรมดักจับการกดแป้นพิมพ์ (keylogger) นั้นพบได้น้อยในแพ็กเกจมัลแวร์และอิมเมจคอนเทนเนอร์ แต่จะพบได้บ่อยกว่าในส่วนขยายของเครื่องมือ ซึ่งคาดว่าจะมีการโต้ตอบกับผู้ใช้
- โปรแกรมปล่อยไฟล์ / ดาวน์โหลดเป็นรูปแบบที่ได้รับความนิยมเป็นอันดับสอง โดยมักจะมาเป็นอันดับแรกในการโจมตีแบบหลายขั้นตอน มากกว่าหนึ่งในสามของส่วนประกอบที่เป็นอันตรายจะมีตัวปล่อย (หากเพย์โหลดที่เป็นอันตรายรวมอยู่ในแพ็กเกจ) หรือตัวดาวน์โหลด (เพย์โหลดจะถูกดาวน์โหลดจากปลายทางที่อยู่ภายใต้การควบคุมของผู้โจมตี) เพย์โหลดมักจะเป็นมัลแวร์ไบนารีที่รู้จักกันดี และจะถูกเรียกใช้งานและบางครั้งก็คงอยู่ เพื่อติดตั้งแบ็กดอร์ สปายแวร์ ตัวดูดคริปโต และกรณีการใช้งานอื่นๆ เพย์โหลดที่ดาวน์โหลดหรือติดตั้งจะเริ่มการโจมตีเฟสที่สองด้วยพลังทั้งหมดที่ได้รับจากไบนารีมัลแวร์ที่มีอยู่ ไบนารีเหล่านี้สามารถกระจายอยู่ภายในแพ็กเกจ โดยมักจะปลอมแปลงเป็นรูปภาพหรือไฟล์ประเภทที่ดูเหมือนไม่มีพิษภัย เพื่อหลีกเลี่ยงการตรวจจับขณะเชื่อมต่อกับเว็บไซต์ที่ไม่คาดคิด
- ผู้ขโมย/ผู้ขุดคริปโตเคอร์เรนซีศัตรูที่มุ่งหวังผลกำไรทางการเงินยินดีที่จะใช้สินทรัพย์บนคลาวด์ของคุณเพื่อรันโปรแกรมขุดคริปโต (พวกเขายังตรวจจับได้ด้วยซ้ำว่าโปรแกรมเหล่านั้นกำลังทำงานอยู่ใน VM บนคลาวด์หรือไม่) พวกเขาไม่สนใจเรื่องอื่นใดเลย อัตราส่วนกำไรต่ำ โดยจะได้รับค่าชดเชย 1 ดอลลาร์สำหรับทุกๆ 53 ดอลลาร์ที่เรียกเก็บจากเหยื่อสำหรับโครงสร้างพื้นฐานคลาวด์ที่ถูกขโมยไป เหยื่ออาจไม่ทราบเรื่องนี้จนกว่าจะได้รับบิลที่ไม่คาดคิด โชคดีที่เรื่องนี้เกิดขึ้นและหายไปเป็นระยะ Cryptojacking แคมเปญหลอกลวงในรูปแบบแพ็กเกจที่เป็นอันตรายมักปรากฏขึ้นแล้วก็หายไป โดยมีเป้าหมายเพื่อหลอกลวงผู้ใช้กระเป๋าเงินดิจิทัล หรือในที่สุดก็มุ่งเป้าไปที่ผู้ให้บริการกระเป๋าเงินดิจิทัล ดังเช่นในกรณีต่อไปนี้ การโจมตีบัญชีแยกประเภท.
พฤติกรรมอื่นๆ เช่น การใช้งาน ประตูหลัง การเรียกใช้โค้ดจากระยะไกลโดยการเปิดรีเวิร์สเชลล์นั้นเกิดขึ้นน้อยลงกว่าในอดีต ตัวอย่างเช่น 123rf_contributor_web แพ็กเกจ (ซึ่งถูกลบออกจากรีจิสทรีแล้ว) เปิดขึ้นมาโดยไม่มีการปกปิดใดๆ เป็นรีเวิร์สเชลล์ที่คัดลอกและวางจาก คู่มือโกง Reverse Shell:
นอกเหนือจากส่วนประกอบที่ถูกต้องตามกฎหมายและส่วนประกอบที่เป็นอันตรายแล้ว เรายังพบการละเมิดหลายประการ รวมถึง:
พัสดุสแปม
มีแพ็กเกจขนาดเล็กหลายพันแพ็กเกจ ส่วนใหญ่อยู่ใน NPM ซึ่งไม่มีมัลแวร์ แต่สัญญาว่าจะสร้างรายได้ง่ายๆ โฆษณาขายยาหลอกลวง ลิงก์ไปยังผลิตภัณฑ์ไวอากร้า และอื่นๆ อีกมากมาย ผู้ใช้บางรายเผยแพร่สแปมเหล่านี้และใช้แบนด์วิดท์จากรีจิสทรีเป็นจำนวนมาก นอกจากนี้ยังมีผู้กระทำการอื่นๆ ที่อาจมาจากอินโดนีเซีย พยายามฉวยโอกาสจากเรื่องนี้ การใช้ teaRank ในทางที่ผิด มีจุดประสงค์เพื่อชดเชยค่าตอบแทนให้กับนักพัฒนาโอเพนซอร์ส โดยการสร้างแพ็กเกจ NPM ที่เชื่อมโยงกันหลายหมื่นรายการ พร้อมด้วยที่เก็บข้อมูลจำลองบน GitHub ซึ่งเป็นการละเมิดข้อกำหนดการใช้งานอย่างชัดเจน
การหลอกลวงเกี่ยวกับการล่ารางวัลบั๊กและการวิจัยด้านความปลอดภัย
เมื่อแพ็กเกจอธิบายตัวเองว่าดึงข้อมูลออกมาเพื่อจุดประสงค์ที่ดี เช่น การตรวจหาช่องโหว่ด้านความปลอดภัยสำหรับโปรแกรมล่ารางวัลบั๊ก หรือการวิจัยบางแง่มุมของระบบนิเวศ เราพบเห็นแพ็กเกจในหมวดหมู่นี้มาแล้วหลายพันรายการ ซึ่งดึงข้อมูลระบุตัวตนแต่ไม่ใช่ข้อมูลที่ละเอียดอ่อนมากนักไปยังที่อยู่ Burp Collaborator จาก PortSwigger (เช่น โฮสต์ในโดเมน oastify.com) เราสังเกตเห็นการลอกเลียนแบบบ่อยครั้ง ความสับสนในการพึ่งพา การพิสูจน์แนวคิดโดย Alex Birsan เช่นเดียวกับ ออโรร่า-เว็บเมล-โปร แพ็คเกจ (ที่ถูกลบออกจากรีจิสทรี) ซึ่งเพียงแค่เรียกใช้โค้ดที่ไม่พึงประสงค์นี้ในสคริปต์ก่อนการติดตั้ง:
และยังรวมถึง “นี่คือตัวอย่างการพิสูจน์แนวคิดการโจมตีแบบสับสนด้านการพึ่งพาอย่างง่ายคำอธิบายข้อจำกัดความรับผิดชอบใน package.jsonนี่เป็นการละเมิดข้อกำหนดในการให้บริการอย่างชัดเจน แม้ว่าจะไม่ได้มีเจตนาร้ายก็ตาม
ข่าวดีก็คือ เรายังไม่พบการโจมตีด้วยแรนซัมแวร์ที่ส่งผ่านส่วนประกอบที่เป็นอันตราย (ในขณะนี้) ด้วยเหตุผลที่ไม่ทราบแน่ชัด ดูเหมือนว่าอาชญากรไซเบอร์จะนิยมใช้กลไกการโจมตีแบบดั้งเดิมมากกว่า เช่น การหลอกลวงทางอีเมล การโจมตีผ่าน RDP และการดาวน์โหลดโดยไม่ได้รับอนุญาต
เทคนิคเพิ่มเติมที่สังเกตได้
มีการใช้เทคนิคหลายอย่างเพื่อการคงอยู่ในพื้นที่ปฏิบัติการ การหลบเลี่ยงการป้องกัน การรวบรวมข้อมูล การสื่อสารกับโฮสต์ควบคุมและสั่งการ และการถอนกำลังออกจากพื้นที่
การติดตา ในส่วนประกอบที่เป็นอันตรายนั้น พฤติกรรมดังกล่าวเกิดขึ้นจากการใช้คุณสมบัติการคงอยู่ของมัลแวร์ไบนารีขั้นที่สอง แต่บางครั้งพฤติกรรมนั้นก็อยู่ในโค้ดของแพ็กเกจ โดยการทำงานตามกำหนดเวลาและการเปลี่ยนแปลงในรีจิสทรีของ Windows เป็นสิ่งที่พบได้บ่อยที่สุด
obfuscation เป็นเรื่องปกติ แต่ไม่ซับซ้อน แพ็กเกจที่ใช้เทคนิค typosquatting ส่วนใหญ่ (จำคำว่า “ ได้ไหมปลาแองโชวี่”?) ไม่ได้ใช้การเข้ารหัสแบบปกปิดเลย หลายคนใช้การเข้ารหัสแบบง่ายๆ (เช่น การเข้ารหัส base64/hex หรือการเข้ารหัสแบบแทนที่ เช่น rot13) หรือใช้โปรแกรมปกปิดโค้ดและการย่อขนาดโค้ดที่มีอยู่ ซึ่งสามารถถอดรหัสได้ง่ายด้วยเครื่องมือที่เหมาะสม มีเพียง “ผู้เชี่ยวชาญ” เท่านั้นที่ใช้การเข้ารหัสแบบปกปิดที่แท้จริงและยากต่อการถอดรหัส
การเข้ารหัสลับอาจช่วยซ่อนการโจมตีได้ แต่ทำไมโค้ดในส่วนประกอบโอเพนซอร์สจึงต้องเข้ารหัสลับด้วย? มีหลักฐานอะไรที่บ่งชี้ว่าจำเป็นต้องซ่อนบางสิ่งบางอย่างจากสายตาคนทั่วไป? เราพบหลายกรณีของแพ็กเกจที่ไม่เป็นอันตรายซึ่งใช้การเข้ารหัสลับเพื่อปกป้องทรัพย์สินทางปัญญา ซึ่งขัดแย้งกับหลักการของ “โอเพนซอร์ส” การเข้ารหัสลับสามารถใช้เป็นหลักฐานของมัลแวร์ได้ แต่ก็ไม่ใช่ข้อสรุปที่แน่ชัด นอกจากนี้ การถอดรหัสลับก็ทำได้ยากด้วย
การหลีกเลี่ยง ระบบควบคุมการป้องกันใช้เทคนิคที่เรียบง่าย โค้ดที่เป็นอันตรายมักได้รับการปกป้องใน ลอง…จับ ระบบจะบล็อกการทำงานโดยไม่สนใจข้อยกเว้นใดๆ ดังนั้นกิจกรรมที่ผิดปกติจึงไม่ปรากฏในบันทึก การตรวจสอบสภาพแวดล้อม (การทำงานใน VM หรือคอนเทนเนอร์) นั้นเกิดขึ้นไม่บ่อยนัก เว้นแต่จะเป็นกรณีมัลแวร์ที่มุ่งเป้าไปที่องค์กรหรือสภาพแวดล้อมใดโดยเฉพาะ
การปลอมแปลงข้อมูลไบนารีในภาพและไฟล์ PDF (คล้ายกับสเตกาโนกราฟี) เป็นอีกเทคนิคหนึ่งที่พบว่าสามารถหลีกเลี่ยงการตรวจจับได้
เนื่องจากส่วนประกอบที่เป็นอันตรายที่พบได้บ่อยที่สุดคือโปรแกรมขโมยข้อมูล การเก็บรวบรวมข้อมูล การรักษาความปลอดภัยข้อมูลเป็นสิ่งสำคัญ ข้อมูลลับ (รหัสผ่าน โทเค็นการเข้าถึง คีย์ API คีย์เข้ารหัส) มักถูกสแกนในไฟล์บันทึก ตัวแปรสภาพแวดล้อม และแม้แต่ในคลิปบอร์ด (พบเห็นได้ในมัลแวร์ประเภทโทรจันที่โจมตีธนาคารและขโมยข้อมูลเข้ารหัส) การขโมยซอร์สโค้ดก็เป็นเรื่องปกติเช่นกัน เนื่องจากการติดตั้งแพ็กเกจมักทำในโหนดพัฒนา ซึ่งอาจมีการโคลนที่เก็บ Git ภายใน เราพบว่าแพ็กเกจบางตัวทำการสำรวจไดเร็กทอรีเพื่อค้นหาที่เก็บ Git การค้นหาตำแหน่งเช่น .env, private.pem, settings.py, app.js หรือ application.properties เป็นเรื่องที่พบได้บ่อย
การดึงข้อมูลออกเป็นอีกหนึ่งวิธีการที่ใช้กันอย่างแพร่หลาย มีเพียงส่วนน้อยของมัลแวร์เท่านั้นที่พยายามซ่อนปลายทางของข้อมูลที่ถูกดึงออกมา ช่องทาง Telegram และ อุโมงค์คล้ายเอ็นโกรก มักถูกนำมาใช้ และมีมากมาย โดยทั่วไปแล้ว โดเมนที่ได้รับอนุญาตจะถูกใช้สำหรับการขโมยข้อมูล.
เทคนิคอื่นๆ เช่น การยกระดับสิทธิ์ หรือการเคลื่อนย้ายตำแหน่งในแนวนอน พบได้น้อยกว่า
การได้รับความนิยมและความไว้วางใจ
ลองนึกภาพอาชญากรไซเบอร์ที่มีเครื่องมือทำลายล้างสำเร็จรูปอยู่แล้วกำลังสงสัยว่า “ฉันจะทำให้ไอ้ของห่วยๆ นี่ดูน่าเชื่อถือสำหรับพวกคนโง่ที่ไม่รู้เรื่องได้ยังไง?”
นั่นหมายความว่า จะสร้างรายการสำหรับส่วนประกอบที่เป็นอันตรายอย่างไรให้แสดงจำนวนดาว/การแยกสาขา (เพื่อความนิยม) รวมถึงเวอร์ชัน/ปัญหาต่างๆ และอื่นๆ pull requests (สำหรับกิจกรรม) แนวคิดคือการสร้างความนิยม (ดารา) และผู้ติดตามที่ไม่เป็นความจริง รวมถึงภาพลักษณ์ที่น่าเชื่อถือเกี่ยวกับความสำคัญและการดำรงอยู่
ระบบลงทะเบียนไม่ได้ตรวจสอบว่าเนื้อหาในโปรเจ็กต์ GitHub และเนื้อหาในแพ็กเกจตรงกันหรือไม่นี่เป็นปัญหาที่รู้จักกันดีในห่วงโซ่อุปทานซอฟต์แวร์ ทะเบียนสาธารณะเปรียบเสมือนหลุมดำขนาดใหญ่ที่กลืนกินทุกสิ่งทุกอย่างที่ถูกโยนลงไป คุณสามารถเชื่อมโยงไปยังที่เก็บข้อมูลใดก็ได้
หากแพ็กเกจที่เป็นอันตรายใช้ชื่อโดเมนปลอมกับแพ็กเกจยอดนิยม ก็แก้ไขได้ง่ายๆ เพียงแค่ระบุที่อยู่ GitHub repository ที่มีอยู่แล้วในไฟล์ manifest ของ dependency ที่ใช้ในการสร้างแพ็กเกจและเผยแพร่ลงใน registry แต่สำหรับแพ็กเกจใหม่ใน GitHub repository ปลอม อาจต้องใช้ความชาญฉลาดมากกว่านั้น เช่น การสร้าง repository ปลอมขึ้นมา การดูดาว/การแยก สร้างบัญชี GitHub ผ่านการเขียนสคริปต์
และหากเนื้อหาในแพ็กเกจของคุณคล้ายคลึงกับ repository ต้นฉบับพอสมควร ให้ลองแทรกการเปลี่ยนแปลงที่ออกแบบมาอย่างดีสักสองสามอย่างลงไป... คุณสามารถแทรกมัลแวร์ของคุณเข้าไปในแพ็กเกจใหม่ที่คล้ายกับแพ็กเกจยอดนิยมที่อ้างอิงถึง repository เดิม แล้วรอให้เกิดข้อผิดพลาดในการพิมพ์ หากใครกล้าเปรียบเทียบเนื้อหาของไฟล์ tarball กับเนื้อหาจาก repository บน GitHub ความแตกต่าง ณ จุดที่แทรกมัลแวร์อาจถูกมองข้ามไปได้ง่าย เราเคยเห็นวิธีการนี้มาหลายครั้งแล้ว
กลไกที่ทำให้ส่วนประกอบสามารถระบุที่มา วิธีการผลิต แหล่งที่มา และผู้ผลิตได้อย่างป้องกันการปลอมแปลง จะเป็นสิ่งที่น่ายินดี แต่เรื่องนั้นเป็นอีกเรื่องหนึ่ง
ส่วนประกอบ X เป็นมัลแวร์หรือไม่?
มีฐานข้อมูลแพ็กเกจที่เป็นอันตราย (แบบครอบคลุม) หรือไม่? ไม่มีครับ ช่องโหว่แบบโอเพนซอร์สจะมีรหัส CVE กำหนดไว้ แต่มีเพียงแพ็กเกจที่เป็นอันตรายไม่กี่ตัว (โดยเฉพาะตัวที่ตกเป็นข่าวใหญ่) เท่านั้นที่จะได้รับรหัสนี้ รหัส CWE สำหรับแพ็กเกจที่เป็นอันตรายคือ ซีดับบลิว-506 (ฝังโค้ดที่เป็นอันตราย)
เครื่องมือตรวจจับมัลแวร์ทั่วไป (VirusTotal, MalwareBazaar, SOREL-20M…) ไม่ได้จัดเตรียมการตรวจจับส่วนประกอบที่เป็นอันตรายโดยเฉพาะ ซึ่งนับว่าเป็นเรื่องดี!
มีฐานข้อมูลตัวอย่างสำหรับการวิจัยและชุดข้อมูลสำหรับการวิเคราะห์ (เราใช้บางส่วน) แต่ข้อมูลจะได้รับการอัปเดตก็ต่อเมื่อทราบถึงแพ็กเกจที่เป็นอันตรายแล้ว ซึ่งมักจะสายเกินไป หากคุณสนใจ OpenSSF แพ็กเกจที่เป็นอันตราย นับเป็นการเริ่มต้นที่ดี
ในโพสต์ถัดไป เราจะพูดถึงวิธีการตรวจสอบว่าแพ็กเกจใดเป็นอันตรายหรือไม่ สปอยล์: ใช่แล้ว มีวิธีตรวจสอบส่วนประกอบที่เป็นอันตรายได้ตั้งแต่เนิ่นๆ ในช่วงเวลาที่แพ็กเกจนั้นยังไม่ถูกเปิดเผย ก่อนที่รีจิสทรีจะลบส่วนประกอบที่เป็นอันตรายที่รู้จักออกไป
อ่านเพิ่มเติม
ในตอนต่อไป “การป้องกันมัลแวร์โอเพนซอร์ส: อะไรได้ผล (และอะไรไม่ได้ผล)" เราจะมาพูดคุยกันถึงข้อควรปฏิบัติและข้อห้ามสำหรับการรักษาความปลอดภัยของซอฟต์แวร์โอเพนซอร์ส ผู้เชี่ยวชาญด้านความปลอดภัยส่วนใหญ่มีสัญชาตญาณในการรับมือกับภัยคุกคามนี้ แต่ก็ยังมีความเข้าใจผิดอยู่มากมาย
เราจะมาทบทวนว่าเหตุใดแนวคิดเหล่านี้จึงผิดพลาด และความเข้าใจผิดดังกล่าวมีส่วนทำให้กลไกการโจมตีนี้ได้รับความนิยมอย่างไร และทำให้องค์กรต่างๆ เผชิญกับความเสี่ยงอย่างมหาศาลได้อย่างไร จากนั้นเราจะกล่าวถึงสิ่งที่ได้ผล และความพยายามและทรัพยากรที่เกี่ยวข้อง
นอกจากนี้ เราจะโพสต์เกี่ยวกับวิวัฒนาการของมัลแวร์ในแง่ของเจตนา กลไกการแทรกซึม และเทคนิคการโจมตีด้วย
คอยติดตาม!
