Peringatan atas Pengambilalihan Proyek Open Source melalui Rekayasa Sosial

OpenJS dan OpenSSF Mengeluarkan Peringatan atas Risiko Serangan Social Engineering terhadap Proyek Open Source

• Upaya backdoor XZ Utils terbaru (CVE-2024-3094) mungkin bukan kejadian yang berdiri sendiri.
• OpenJS Foundation tampaknya telah memblokir upaya takeover berbasis kepercayaan yang serupa, sehingga ini juga mungkin bukan insiden terpisah.
• OpenSSF dan OpenJS Foundation menyerukan agar semua pengelola open source waspada terhadap upaya takeover melalui social engineering, mengenali pola ancaman awal, dan mengambil tindakan untuk melindungi proyek open source.

Upaya Pengambilalihan yang Gagal

• OpenJS Foundation Cross Project Council menerima serangkaian email mencurigakan dengan pesan serupa.
• Penulis email mendesak OpenJS agar mengambil tindakan untuk memperbarui salah satu proyek JavaScript populer "untuk mengatasi kerentanan penting", tanpa menyebutkan detail yang spesifik.
• Penulis email meminta agar dirinya ditunjuk sebagai maintainer baru proyek meskipun sebelumnya hampir tidak pernah terlibat dalam pengkodean.
• Pendekatan ini sangat mirip dengan cara Jia Tan memosisikan dirinya dalam backdoor XZ/liblzma.
• Orang-orang ini tidak diberi akses ke proyek yang dihosting OpenJS.
• Proyek sudah memiliki kebijakan keamanan, termasuk kebijakan yang diuraikan secara garis besar oleh security working group di fondasi.
• Tim OpenJS juga mengidentifikasi pola mencurigakan serupa pada dua proyek JavaScript populer lain yang tidak dihosting oleh fondasi dan segera memberitahukan potensi isu keamanan itu kepada masing-masing pemimpin OpenJS serta CISA (Cybersecurity and Infrastructure Security Agency), lembaga di dalam DHS (Departemen Keamanan Dalam Negeri AS).

Pola Mencurigakan Pengambilalihan melalui Social Engineering

• Pola:
  • Anggota komunitas yang relatif tidak dikenal mengajukan permintaan yang bersahabat tetapi agresif dan berulang-ulang kepada maintainer atau institusi hosting (fondasi atau perusahaan).
  • Meminta orang baru atau yang tidak dikenal untuk dipromosikan ke peran sebagai maintainer.
  • Mendapat dukungan dari anggota komunitas lain yang mungkin memakai identitas palsu (dikenal sebagai "sock puppets").
  • PR dengan blob sebagai artefak.
  • Kode sumber yang sengaja diobfuskasi atau sulit dipahami.
  • Masalah keamanan yang makin memburuk secara bertahap.
  • Kemungkinan menyisipkan payload berbahaya eksternal ke blob, zip, atau artefak biner lain di luar praktik kompilasi, build, dan distribusi proyek yang umum.
  • Terutama ketika maintainer didorong untuk mengurangi ketelitian review karena rasa urgensi atau diminta untuk melewati kontrol.
• Serangan social engineering seperti ini mengeksploitasi rasa tanggung jawab maintainer terhadap proyek dan komunitas untuk memanipulasi mereka.
• Perhatikan nuansa interaksi yang ditimbulkan.
  • Interaksi yang membuat seseorang meragukan diri, merasa tidak pantas, atau merasa tidak berkontribusi cukup pada proyek bisa menjadi bagian dari serangan social engineering.
• Serangan social engineering seperti yang terlihat pada XZ/liblzma berhasil dicegah secara sukses oleh komunitas OpenJS.
• Karena jenis serangan ini mengeksploitasi pelanggaran kepercayaan melalui social engineering, jenis ini sulit dideteksi atau dipertahankan secara programatik.
• Dalam jangka pendek, berbagi aktivitas mencurigakan seperti di atas secara jelas dan transparan akan membantu komunitas lain tetap waspada.
• Memberikan dukungan yang baik kepada maintainer adalah pencegahan utama terhadap serangan social engineering.

Langkah untuk Keamanan Proyek Open Source

• Pertimbangkan mengikuti praktik terbaik keamanan standar industri seperti OpenSSF Guide.
• Gunakan autentikasi yang kuat: 2FA, password manager, simpan recovery code di tempat yang aman, dan jangan gunakan ulang kata sandi/kredensial di layanan yang berbeda.
• Siapkan kebijakan keamanan yang mencakup proses Coordinated disclosure.
• Terapkan praktik terbaik saat menggabungkan kode baru.
  • Aktifkan perlindungan branch dan commit yang ditandatangani.
  • Jika memungkinkan, minta pengembang kedua melakukan review kode sebelum menggabungkan PR, bahkan jika PR itu datang dari maintainer.
  • Terapkan persyaratan keterbacaan agar PR baru tidak diobfuskasi dan minimalkan penggunaan biner yang tidak transparan.
  • Batasi orang yang memiliki izin publish npm.
  • Identifikasi dan tinjau secara berkala para committer dan maintainer. Misalnya, apakah Anda pernah melihat mereka di rapat working group atau bertemu di acara?
• Jika Anda mengoperasikan repositori paket open source, pertimbangkan mengadopsi prinsip untuk Package Repository Security.
• Tinjau panduan CISA mengenai Menghindari Serangan Rekayasa Sosial dan Phishing dan/atau ENISA tentang Apa itu social engineering.

Tindakan Industri dan Pemerintah untuk Keamanan Infrastruktur Open Source Utama

• Menjaga proyek open source tetap stabil dan aman memberi tekanan pada maintainer.
• Diperlukan sumber daya besar melalui kerja sama internasional sektor swasta dan publik.
• Banyak lembaga seperti Open Source Foundations, Sovereign Tech Fund, dan lainnya sudah menjalankan pekerjaan yang sangat baik.
• Untuk menyediakan jaring pengaman bagi proyek open source, dibutuhkan upaya dari organisasi sejenis keluarga Linux Foundation.
• Investasi pemerintah Jerman melalui inisiatif Sovereign Tech Fund ke arah infrastruktur open source yang penting merupakan sinyal yang menggembirakan.
• Kami mendukung lebih banyak investasi publik global untuk inisiatif seperti Sovereign Tech Fund milik Jerman guna memperluas keterlibatan investasi publik global.

Opini GN⁺

• Penyerang secara cerdik mengeksploitasi rasa tanggung jawab maintainer untuk mengganggu para developer. Karena itu, perubahan emosi yang dirasakan maintainer terhadap proyek juga patut diperhatikan.
• Kami setuju bahwa investasi keamanan harus ditingkatkan, tetapi pada akhirnya budaya pengembangan sendiri perlu berubah agar lebih menempatkan keamanan sebagai prioritas. Keamanan harus menyatu secara alami di seluruh proses pengembangan.
• Karena penyerang memanfaatkan kepercayaan komunitas, proyek open source juga harus terus membangun dan memperkuat kepercayaan antaranggota. Bertatap muka dan berkomunikasi langsung bisa menjadi awalnya.
• Lebih banyak proyek seperti Alpha-Omega yang berinvestasi pada perbaikan kerentanan nyata perlu dibangun dan didukung. Hanya dengan itu tingkat keamanan proyek open source bisa meningkat secara nyata.

[GN⁺]

Komentar Hacker News

Ringkasan:

• Sebagai pengelola proyek sumber terbuka, saya menjadi lebih curiga terhadap PR dari kontributor baru
  • Meskipun terlihat baik di permukaan, saya tetap mempertimbangkan kemungkinan ada niat tersembunyi
• Seiring berjalannya waktu, akumulasi fitur membuat perangkat lunak menjadi sangat kompleks
  • Kodenya menjadi sulit dipahami sehingga hanya sedikit orang yang bisa memahaminya
  • Saat para pengembang senior pensiun, banyak bagian akan sulit dipahami
• Dibutuhkan sistem pelaporan perubahan untuk proyek besar
  • Harus disinkronkan dengan npm.js atau paket Debian bersamaan dengan rilis/versi
  • Seperti kasus bank Eropa, harus dapat diawasi oleh lembaga dari berbagai negara
• Harus waspada terhadap pola seperti di game Eve Online, yaitu menjadi kontributor yang berharga lalu berkhianat setelah dipercaya
• 2FA/MFA sebaiknya hanya dipakai pada sistem yang di-host sendiri
  • Pada sistem pihak ketiga, Anda dapat terkunci secara permanen jika kehilangan faktor autentikasi kedua
  • Projek harus di-host sendiri agar tidak kehilangan kontrol
• Debat pelik antara inklusivitas dan keamanan jangka panjang akan terjadi di open source
  • Pengembang dari Iran, Rusia, dan Tiongkok sudah dianggap mencurigakan
  • Melakukan fork dan berkontribusi bersama sekutu mungkin merupakan pilihan yang lebih baik
  • Pihak lawan dapat menggabungkan perubahan ke sumber aslinya tanpa terhalang lisensi atau isu hak cipta
• Setiap proyek harus menetapkan standar sendiri dan segera menghapus dependensi yang tidak lagi dipelihara
  • Juga patut mempertimbangkan evaluasi sensitivitas proyek
• Saya mulai berpikir seberapa sering serangan semacam ini bisa terjadi setelah serangan XZ
  • Open source mungkin lebih rentan dibandingkan perangkat lunak tertutup
  • Karena siapa pun dapat menulis kode dan motivasi jahat itu ada
• Tampaknya sulit untuk meninjau perilaku proyek open source yang ada secara retrospektif
• Sudah lama berargumen bahwa kita sebaiknya fokus pada arsitektur sederhana dan peningkatan standar penulisan kode
  • Tetapi orang-orang terus menambah dependensi tak perlu saat memakai TypeScript, React, dan lain-lain
  • Para penyerang menertawakan kepolosan dan kebodohan kita
  • Seluruh industri, bahkan sistem politik, mungkin sudah dikompromikan
• Orang-orang seharusnya mencari proyek dengan kode dan dependensi minimum
  • Proyek yang bersih kehilangan perhatian dan kesempatan, sementara proyek yang berlebihan tampil ke depan
  • Sekarang mereka menjadi target mudah bagi pelaku jahat
  • Menyembunyikan kerentanan dalam kompleksitas sangatlah mudah