Bug JavaScript banyak sekali di ekosistem Node.js – ditemukan secara otomatis

Berikut makalah menarik dari konferensi USENIX 2022 baru-baru ini: Menambang Kerentanan Node.js melalui Grafik dan Kueri Ketergantungan Objek.

Kami akan sedikit curang di sini dengan tidak menggali dan menjelaskan penelitian inti yang disajikan oleh penulis makalah (beberapa matematika, dan pengetahuan tentang notasi semantik operasional diinginkan saat membacanya), yang merupakan metode untuk statis analisis kode sumber yang mereka sebut ODGEN, kependekan dari Generator Grafik Ketergantungan Objek.

Sebagai gantinya, kami ingin fokus pada implikasi dari apa yang dapat mereka temukan di ekosistem JavaScript Node Package Manager (NPM), sebagian besar secara otomatis, dengan menggunakan alat ODGEN mereka di kehidupan nyata.

Satu fakta penting di sini adalah, seperti yang kami sebutkan di atas, bahwa alat mereka dimaksudkan untuk apa yang dikenal sebagai analisis statis.

Di situlah Anda bertujuan untuk meninjau kode sumber untuk kemungkinan (atau sebenarnya) kesalahan pengkodean dan lubang keamanan tanpa benar-benar menjalankannya sama sekali.

Mengujinya dengan menjalankannya adalah proses yang jauh lebih memakan waktu yang umumnya membutuhkan waktu lebih lama untuk disiapkan, dan lebih lama untuk dilakukan.

Namun, seperti yang dapat Anda bayangkan, apa yang disebut analisis dinamis – benar-benar membangun perangkat lunak sehingga Anda dapat menjalankannya dan mengeksposnya ke data nyata dengan cara yang terkontrol – umumnya memberikan hasil yang jauh lebih menyeluruh, dan jauh lebih mungkin untuk mengekspos bug misterius dan berbahaya daripada sekadar “melihatnya dengan cermat dan mengetahui cara kerjanya ”.

Tetapi analisis dinamis tidak hanya memakan waktu, tetapi juga sulit untuk dilakukan dengan baik.

Dengan ini, kami benar-benar bermaksud mengatakan bahwa pengujian perangkat lunak dinamis adalah sangat mudah dilakukan dengan buruk, bahkan jika Anda menghabiskan waktu lama untuk tugas tersebut, karena mudah untuk berakhir dengan sejumlah tes yang mengesankan yang tidak begitu bervariasi seperti yang Anda pikirkan, dan bahwa perangkat lunak Anda hampir pasti akan lulus, apa pun yang terjadi. Pengujian perangkat lunak dinamis terkadang berakhir seperti seorang guru yang menetapkan soal ujian yang sama dari tahun ke tahun, sehingga siswa yang berkonsentrasi penuh pada latihan "makalah sebelumnya" akhirnya berhasil sebaik siswa yang benar-benar menguasai subjek tersebut.

Jaringan ketergantungan rantai pasokan yang berantakan

Dalam ekosistem kode sumber perangkat lunak besar saat ini, di mana repositori sumber terbuka global seperti NPM, PyPI, PHP Packagist, dan RubyGems adalah contoh yang terkenal, banyak produk perangkat lunak bergantung pada koleksi ekstensif paket orang lain, membentuk web pasokan yang rumit dan tidak beraturan. ketergantungan rantai.

Tersirat dalam dependensi tersebut, seperti yang dapat Anda bayangkan, adalah ketergantungan pada setiap rangkaian pengujian dinamis yang disediakan oleh setiap paket yang mendasarinya – dan pengujian individual tersebut umumnya tidak (memang, tidak dapat) memperhitungkan bagaimana semua paket akan berinteraksi ketika mereka 'digabungkan untuk membentuk aplikasi unik Anda sendiri.

Jadi, meskipun analisis statis itu sendiri tidak benar-benar memadai, ini masih merupakan titik awal yang sangat baik untuk memindai repositori perangkat lunak untuk mencari lubang yang mencolok, paling tidak karena analisis statis dapat dilakukan "offline".

Secara khusus, Anda dapat secara teratur dan rutin memindai semua paket kode sumber yang Anda gunakan, tanpa perlu menyusunnya ke dalam program yang sedang berjalan, dan tanpa perlu membuat skrip pengujian yang dapat dipercaya yang memaksa program tersebut untuk berjalan dalam berbagai cara yang realistis.

Anda bahkan dapat memindai seluruh repositori perangkat lunak, termasuk paket yang mungkin tidak perlu Anda gunakan, untuk menghilangkan kode (atau untuk mengidentifikasi penulis) yang perangkat lunaknya tidak Anda percayai bahkan sebelum mencobanya.

Lebih baik lagi, beberapa jenis analisis statis dapat digunakan untuk mencari bug yang disebabkan oleh kesalahan pemrograman serupa di semua perangkat lunak Anda yang baru saja Anda temukan melalui analisis dinamis (atau yang dilaporkan melalui sistem bug bounty) dalam satu bagian dari satu perangkat lunak produk.

Misalnya, bayangkan laporan bug dunia nyata yang datang dari alam liar berdasarkan satu tempat tertentu dalam kode Anda di mana Anda telah menggunakan gaya pengkodean yang menyebabkan gunakan-setelah-bebas kesalahan memori.

A gunakan-setelah-bebas adalah di mana Anda yakin bahwa Anda telah selesai dengan blok memori tertentu, dan menyerahkannya kembali sehingga dapat digunakan di tempat lain, tetapi kemudian lupakan itu bukan milik Anda lagi dan tetap menggunakannya. Seperti tidak sengaja dalam perjalanan pulang dari kantor ke alamat lama Anda berbulan-bulan setelah Anda pindah, hanya karena kebiasaan, dan bertanya-tanya mengapa ada mobil aneh di jalan masuk.

Jika seseorang telah menyalin dan menempelkan kode buggy itu ke komponen perangkat lunak lain di repositori perusahaan Anda, Anda mungkin dapat menemukannya dengan pencarian teks, dengan asumsi bahwa keseluruhan struktur kode dipertahankan, dan komentar serta nama variabel tidak ' tidak terlalu banyak berubah.

Tetapi jika pemrogram lain hanya mengikuti idiom pengkodean yang sama, bahkan mungkin menulis ulang kode yang salah dalam bahasa pemrograman yang berbeda (dalam jargon, sehingga berbeda secara leksikal) ...

…maka pencarian teks akan hampir tidak berguna.

Bukankah itu berguna?

Bukankah akan berguna jika Anda dapat secara statis mencari seluruh basis kode Anda untuk kesalahan pemrograman yang ada, bukan berdasarkan string teks melainkan pada fitur fungsional seperti aliran kode dan dependensi data?

Nah, dalam makalah USENIX yang sedang kita diskusikan di sini, penulis telah berusaha membangun alat analisis statis yang menggabungkan sejumlah karakteristik kode yang berbeda menjadi representasi yang ringkas yang menunjukkan “bagaimana kode mengubah inputnya menjadi outputnya, dan bagian mana yang lain. kode dapat mempengaruhi hasil”.

Proses ini didasarkan pada grafik ketergantungan objek yang disebutkan di atas.

Sangat disederhanakan, idenya adalah memberi label kode sumber secara statis sehingga Anda dapat mengetahui kombinasi kode-dan-data (objek) mana yang digunakan pada satu titik yang dapat memengaruhi objek yang digunakan nanti.

Kemudian, mungkin untuk mencari perilaku kode yang diketahui-buruk – bau, dalam jargon – tanpa benar-benar perlu menguji perangkat lunak secara langsung, dan tanpa perlu hanya mengandalkan pencocokan teks di sumbernya.

Dengan kata lain, Anda mungkin dapat mendeteksi apakah pembuat kode A telah menghasilkan bug serupa dengan yang baru saja Anda temukan dari pembuat kode B, terlepas dari apakah A benar-benar menyalin kode B, mengikuti saran yang salah dari B, atau hanya memilih kebiasaan buruk di tempat kerja yang sama. sebagai B

Secara longgar, analisis kode statis yang baik, terlepas dari kenyataan bahwa ia tidak pernah melihat perangkat lunak berjalan dalam kehidupan nyata, dapat membantu mengidentifikasi pemrograman yang buruk sejak awal, sebelum Anda menyuntikkan proyek Anda sendiri dengan bug yang mungkin halus (atau jarang) cukup dalam kehidupan nyata bahwa mereka tidak pernah muncul, bahkan di bawah pengujian langsung yang ekstensif dan ketat.

Dan itulah kisah yang ingin kami ceritakan pada Anda di awal.

300,000 paket diproses

Penulis makalah menerapkan sistem ODGEN mereka ke 300,000 paket JavaScript dari repositori NPM untuk memfilter paket yang disarankan sistem mereka mungkin mengandung kerentanan.

Dari jumlah tersebut, mereka menyimpan paket dengan lebih dari 1000 unduhan mingguan (tampaknya mereka tidak punya waktu untuk memproses semua hasil), dan ditentukan dengan pemeriksaan lebih lanjut paket-paket di mana mereka pikir mereka telah menemukan bug yang dapat dieksploitasi.

Di dalamnya, mereka menemukan 180 bug keamanan berbahaya, termasuk 80 kerentanan injeksi perintah (di situlah data yang tidak dipercaya dapat diteruskan ke perintah sistem untuk mencapai hasil yang tidak diinginkan, biasanya termasuk eksekusi kode jarak jauh), dan 14 bug eksekusi kode lebih lanjut.

Dari jumlah tersebut, 27 akhirnya diberi nomor CVE, mengakui mereka sebagai lubang keamanan "resmi".

Sayangnya, semua CVE tersebut bertanggal 2019 dan 2020, karena bagian praktis dari pekerjaan dalam makalah ini dilakukan lebih dari dua tahun yang lalu, tetapi baru ditulis sekarang.

Namun demikian, bahkan jika Anda bekerja di udara yang kurang terselubung daripada yang terlihat oleh akademisi (bagi sebagian besar responden keamanan siber aktif, memerangi penjahat dunia maya saat ini berarti menyelesaikan penelitian apa pun yang telah Anda lakukan sesegera mungkin sehingga Anda dapat segera menggunakannya)…

…jika Anda mencari topik penelitian untuk membantu melawan serangan rantai pasokan di repositori perangkat lunak skala raksasa saat ini, jangan mengabaikan analisis kode statis.

Hidup di anjing tua belum

Analisis statis telah menjadi tidak disukai dalam beberapa tahun terakhir, paling tidak karena bahasa dinamis populer seperti JavaScript membuat pemrosesan statis menjadi sangat sulit.

Misalnya, variabel JavaScript mungkin berupa bilangan bulat pada satu saat, kemudian memiliki string teks "ditambahkan" ke dalamnya dengan sempurna secara legal meskipun salah, sehingga mengubahnya menjadi string teks, dan nantinya mungkin berakhir sebagai tipe objek lain sama sekali.

Dan string teks yang dihasilkan secara dinamis dapat secara ajaib berubah menjadi program JavaScript baru, dikompilasi dan dieksekusi saat runtime, sehingga memperkenalkan perilaku (dan bug) yang bahkan tidak ada saat analisis statis dilakukan.

Namun makalah ini menyarankan bahwa, bahkan untuk bahasa dinamis, analisis statis reguler dari repositori yang Anda andalkan masih dapat sangat membantu Anda.

Alat statis tidak hanya dapat menemukan bug laten dalam kode yang sudah Anda gunakan, bahkan dalam JavaScript, tetapi juga membantu Anda menilai kualitas dasar kode dalam paket apa pun yang ingin Anda adopsi.

---

PELAJARI LEBIH LANJUT TENTANG MENCEGAH SERANGAN RANTAI PASOKAN

Podcast ini menampilkan pakar Sophos Chester Wisniewski, Ilmuwan Riset Utama di Sophos, dan berisi saran yang berguna dan dapat ditindaklanjuti dalam menangani serangan rantai pasokan, berdasarkan pelajaran yang dapat kita pelajari dari serangan raksasa di masa lalu, seperti Kaseya dan SolarWinds.

Jika tidak ada pemutar audio yang muncul di atas, dengarkan langsung di Soundcloud.
Anda juga dapat membaca seluruh podcast sebagai transkrip lengkap.

---