Paket berbahaya yang diunduh lebih dari 86 ribu kali disebarkan secara massal di NPM

• Di repositori NPM, terkonfirmasi bahwa lebih dari 100 paket berbahaya pencuri kredensial diunggah tanpa terdeteksi sejak Agustus, dan total telah diunduh lebih dari 8.6000 kali
• Perusahaan keamanan Koi melaporkan bahwa kampanye serangan yang dinamai PhantomRaven mendistribusikan 126 paket berbahaya dengan menyalahgunakan fitur Remote Dynamic Dependencies (RDD) milik NPM
• RDD adalah struktur yang memungkinkan paket mengunduh kode dependensi secara dinamis dari domain yang tidak tepercaya, sehingga tidak terdeteksi oleh alat analisis statis
• Penyerang memanfaatkan fitur ini untuk mengunduh kode berbahaya melalui koneksi HTTP, sementara metadata paket menampilkan “0 Dependencies” sehingga pengembang dan pemindai keamanan tidak menyadarinya
• Kerentanan struktural ini menyoroti batas pengelolaan keamanan ekosistem NPM dan risiko mekanisme instalasi otomatis

---

Penyebaran paket berbahaya di repositori NPM

• Penyerang mengunggah lebih dari 100 paket pencuri kredensial sejak Agustus dengan memanfaatkan kelemahan struktural pada repositori kode NPM
  • Sebagian besar paket didistribusikan tanpa terdeteksi, dengan total unduhan kumulatif lebih dari 86.000 kali
• Perusahaan keamanan Koi menamai serangan ini sebagai kampanye PhantomRaven dan menganalisis bahwa fitur tertentu di NPM telah disalahgunakan
  • Menurut Koi, dari 126 paket berbahaya, sekitar 80 di antaranya masih tetap ada di NPM saat artikel ditulis

Struktur rentan pada Remote Dynamic Dependencies (RDD)

• RDD adalah fitur yang memungkinkan paket mengunduh kode dependensi secara dinamis dari situs web eksternal
  • Biasanya dependensi diunduh dari infrastruktur tepercaya milik NPM, tetapi RDD juga mengizinkan pengunduhan melalui koneksi yang tidak terenkripsi seperti HTTP
• Penyerang PhantomRaven memanfaatkan fitur ini dengan mengatur paket agar mengunduh kode dari URL berbahaya, misalnya http://packages.storeartifact.com/npm/unused-imports
  • Dependensi semacam ini tidak terlihat oleh pengembang maupun pemindai keamanan, dan pada informasi paket ditampilkan sebagai “0 Dependencies”
• Karena fitur instalasi otomatis NPM, kode dependensi yang ‘tak terlihat’ ini otomatis dijalankan

Batas kemampuan deteksi alat keamanan

• Oren Yomtov dari Koi menyebut, “PhantomRaven adalah contoh yang secara cermat mengeksploitasi titik buta alat keamanan yang ada”
  • RDD tidak terdeteksi oleh alat analisis statis
• Akibatnya, penyerang dapat melewati verifikasi keamanan dan menyebarkan kode berbahaya

Faktor kerentanan tambahan

• Koi menjelaskan bahwa dependensi yang diunduh melalui RDD diunduh ulang dari server penyerang pada setiap instalasi
  • Karena tidak ada cache atau pengelolaan versi, bahkan untuk paket yang sama pun ada kemungkinan kode berbahaya berbeda disuntikkan pada setiap waktu instalasi
• Struktur unduhan dinamis semacam ini menyulitkan verifikasi integritas paket

Struktur dan latar belakang NPM

• NPM adalah manajer paket untuk JavaScript yang dikelola oleh anak perusahaan GitHub, npm, Inc.
  • Ini adalah manajer paket bawaan untuk Node.js, dan terdiri dari klien baris perintah serta npm registry
  • Registry menyimpan paket publik dan paket privat berbayar, dan dapat ditelusuri melalui situs web
• Insiden ini disebut sebagai contoh bagaimana struktur pengelolaan dependensi otomatis NPM dapat disalahgunakan dalam serangan

Penyebutan lain

• Di bagian akhir artikel, disebutkan pendapat bahwa eksekusi JavaScript yang tidak perlu harus diblokir
  • Namun, serangan kali ini juga disebut sebagai kasus penyalahgunaan bahkan terhadap kode JavaScript yang esensial

[developerjhp]

Saya sudah membuat skrip pemindai real-time.

Di path repositori yang dicurigai,
jalankan npx sha1-hulud-scanner
lalu tekan Enter.

Kode sumber: https://github.com/developerjhp/sha1-hulud-scanner

[GN⁺]

Komentar Hacker News

• Akhir-akhir ini saya memasang alias agar perintah npm dijalankan di dalam kontainer Docker
  Dengan begitu, variabel lingkungan saya tidak terekspos, tidak bisa mengakses file di luar direktori saat ini, dan juga tidak bisa mengakses file konfigurasi seperti .bashrc
  Referensi: Run tools inside Docker

  • Itu terasa seperti sandboxing yang terlalu berlebihan. Toh npm tetap mengunduh kode arbitrer yang akan langsung dijalankan
    Sebagai gantinya saya merekomendasikan pnpm. Secara bawaan ia tidak menjalankan lifecycle script, dan skrip yang diizinkan bisa ditentukan dengan whitelist
  • Menjadikan skrip post-install sebagai kambing hitam hanya memberi ilusi keamanan yang keliru
    Kalau benar-benar ingin perlindungan, bukan hanya instalasinya, tetapi seluruh proses eksekusi harus dijalankan di dalam sandbox
    Memblokir hanya post-install seperti sekarang hanyalah setengah solusi. Serangan rantai pasok makin berbahaya
  • Vektor serangannya terlalu banyak. Kalau niatnya jahat, cukup lakukan typosquatting pada nama plugin atau LSP yang populer agar kode dijalankan otomatis saat editor dibuka
    Jika neovim atau vscode terinfeksi, itu sudah cukup berbahaya hanya dengan hak akses pengguna biasa
  • Saya menggunakan sandbox-run
    Alias sederhana memang cocok untuk node/npm, tetapi sulit diterapkan ke program lain. Soalnya resource yang dibutuhkan harus di-mount ke kontainer
  • Tapi bukankah pada akhirnya Anda tetap bisa mengunduh paket berbahaya? Dependensinya sendiri juga bisa saja sudah terinfeksi

• Saya sudah lama penasaran. Kenapa orang-orang santai saja menjalankan npm langsung di sistem
  Dari sudut pandang yang terbiasa dengan build yang dapat direproduksi seperti make, saya kaget melihat npm selalu mengunduh hal berbeda dan menghasilkan hasil berbeda
  Bahkan mengikat pembuatan CSS ke dependensi npm terasa aneh. Jadi saya pernah mencoba membekukan (freeze) seluruh lingkungan npm di dalam Docker, tetapi rasanya seperti perang yang tak mungkin dimenangkan

  • Sekarang hampir semua package manager bekerja seperti itu. maven, nuget, pip, npm, semuanya sama
    Kalau masih bergantung pada package manager distribusi seperti dulu, ekosistem yang bergerak cepat seperti sekarang mungkin tidak akan ada
    Meski begitu, package manager baru dengan keamanan yang lebih kuat mulai bermunculan. Tidak tepat menyalahkan sarana tanpa memahami alasannya
  • Pengembangan frontend terasa seperti wild west versi “trust me bro”. Karena evolusi browser, kesannya memang seperti ditempel-tempel dengan duct tape
  • Kalau Anda membekukan npm di Docker, saya ingin tahu apakah lingkungan itu diverifikasi setiap kali dependensi diperbarui
    Sebenarnya npm dan pnpm sudah membekukan dependensi secara default lewat file lock
  • Ini masalah karena “npm install thing” terlalu mudah dan murah
    Banyak open source dipenuhi kode untuk CV ketimbang kualitas, lalu akhirnya dipakai untuk membuat hal-hal seperti pelacak iklan perusahaan raksasa atau aplikasi dompet

• npm install bukan sekadar mengunduh paket, tetapi juga menjalankan kode
  Hook preinstall, install, dan postinstall di package.json benar-benar dieksekusi
  Apa alasan sah untuk perlu menjalankan perintah arbitrer saat proses instalasi?
  Laporan terkait: PhantomRaven npm malware
  Contoh lain: blog Socket.dev

  • Sebenarnya struktur seperti ini sudah lama ada di package manager lama seperti DEB dan RPM
    Misalnya, paket kernel Linux menjalankan skrip post-install untuk membangun ulang initramfs, memperbarui GRUB, dan sebagainya
    Kebanyakan paket DEB/RPM memang menyertakan skrip seperti ini. Jadi ini masalah desain itu sendiri
  • Masalahnya, di npm siapa pun bisa mengunggah paket
    Distribusi Linux punya sistem maintainer yang tepercaya, bahkan ada yang membangun root of trust berbasis PGP sendiri
    Sementara npm, pip, rubygems, cargo, dan lainnya pada dasarnya hanya versi mewah dari “curl | bash”
  • Misalnya proyek Mediasoup adalah pustaka streaming yang ditulis dalam C++, dan saat instalasi ia mengompilasi source code secara langsung
    Build post-install seperti ini dibutuhkan untuk mengurangi beban pemeliharaan
  • Swift Package Manager juga benar-benar mengeksekusi file Package.swift
    Hanya saja saya dengar ia di-sandbox dengan ketat, jadi sulit disalahgunakan
    Referensi: dokumentasi SwiftPM, PackageDescription
  • Sebagai referensi, pnpm v10 secara default menonaktifkan semua lifecycle script, dan pengguna harus mengizinkannya secara manual
    Diskusi terkait

• Melihat serangan npm belakangan ini, saya jadi bertanya-tanya apakah mengembangkan dengan npm masih aman
  Setiap kali memulai proyek React, ratusan paket terpasang, dan saya bahkan tidak tahu apa yang mereka lakukan
  Di backend, biasanya hanya paket yang benar-benar dibutuhkan yang dipasang secara eksplisit, tetapi frontend terasa seperti kotak Pandora kerentanan

  • Sebenarnya semua ekosistem bahasa kurang lebih mirip. Hanya saja npm yang paling besar dan paling sering masuk berita
  • Saya memasang jj di Rust dan terpasang 470 paket, sedangkan wan2gp di Python memasang 211 paket. Kurang lebih sama saja
  • Ekosistem JavaScript secara struktural rentan terhadap serangan
    Seperti insiden xz, setiap dependensi bergantung pada orang acak di internet, dan kita harus percaya mereka tidak akan terkena rekayasa sosial
  • Semakin sedikit dependensi semakin baik. 0 dependensi adalah yang sempurna. Itulah kemenangan sesungguhnya
  • Sebagai catatan, PyPI juga tidak aman. Ada kasus paket sah disisipi kode berbahaya lewat peretasan GitHub Actions

• Setiap kali mengembangkan dengan framework seperti Angular atau Vue, saya merasa cemas
  Melihat ribuan dependensi di node_modules terasa seperti pertanda bencana
  Kalau satu pengembang open source kena phishing, semuanya bisa langsung terinfeksi
  Ekosistem JavaScript rusak secara mendasar. Satu salah ketik saja bisa membuka jalan bagi serangan rantai pasok
  Di NuGet atau Maven itu juga mungkin, tetapi di sana standard library lebih besar sehingga dependensinya lebih sedikit dan ada rasa kontrol

  • Go memakai URL repo alih-alih nama paket, sehingga mengurangi typosquatting
    Memang tidak sempurna, tetapi setidaknya selangkah lebih baik
  • Deno menyelesaikan masalah seperti ini. Ini adalah masalah struktural Node.js / npm

• Dari 86.000 unduhan, kemungkinan besar sebagian besar bukan pengguna nyata melainkan scanner otomatis atau bot
  Kalau merilis versi baru, dalam satu-dua hari bisa diunduh ratusan kali, tetapi mungkin bukan manusia sungguhan
  Artinya, bisa jadi hampir tidak ada pengguna yang benar-benar terinfeksi

  • Saya juga pernah mengunggah pustaka, dan pada awalnya ada sekitar 300 unduhan per minggu, lalu sekitar 100 setelahnya
    Ada juga banyak serangan yang menargetkan nama paket yang dihalusinasi oleh chatbot AI. Jadi ini lebih dari sekadar statistik sederhana
  • Atau mungkin ada CI zombie milik seseorang yang terus-menerus mengunduhnya
  • Tetapi kalau serangannya menargetkan nama paket palsu yang dihasilkan LLM, bisa jadi banyak pengembang benar-benar terinfeksi

• Untuk penjelasan serangan yang lebih rinci, lihat artikel BleepingComputer

• Saya penasaran apakah ada cara untuk mendeteksi atau memfilter paket yang menggunakan dependensi URL HTTP saat npm install
  Karena payload bisa dikirim berbeda untuk tiap peminta, deteksinya sulit dilakukan dengan scanner biasa

• Sebagai pengembang hobi, saya memikirkan bagaimana seharusnya bersiap menghadapi serangan rantai pasok seperti ini
  Saat mengikuti tutorial populer dan memasang dependensi, lama-lama kita jadi tidak peka terhadap keamanan
  Saya juga menjalankan berbagai layanan di homelab, dan khawatir bot bisa menyusup. Harus mulai dari mana?

  • Menjalankan layanan secara terpisah di dalam kontainer atau VM bisa mengisolasi dampaknya
    Memang bukan jaminan sempurna, tetapi jauh lebih baik daripada seluruh server dibobol
  • Anggap semua dependensi sebagai risiko keamanan potensial, dan gunakan hanya jika benar-benar perlu
    Menyalin langsung kode yang dibutuhkan untuk dipakai sendiri juga bisa jadi cara belajar yang baik sekaligus lebih aman
  • Menggunakan rilis yang populer dan sudah berumur lebih dari 1 tahun lebih aman. Kalau ada masalah, kemungkinan besar sudah ditemukan
  • Ada juga OS seperti FreeBSD yang memakai package manager sistem
    Dengan struktur seperti itu, keandalan bisa dijamin di tingkat distribusi tanpa setiap pengguna harus memverifikasi semuanya sendiri
  • Saya lebih memilih paket dengan unduhan mingguan di atas 1 juta dan tanpa dependensi
    Contohnya: Hono, Zod
    Saya belakangan beralih ke Bun, karena driver DB, klien S3, dan hal-hal semacam itu sudah bawaan sehingga unduhan tambahan berkurang

• Struktur yang mengambil dependensi dari lifecycle hook bisa menjadi titik balik serangan kapan saja
  Hari ini mungkin masih normal, tetapi nanti pemiliknya bisa diretas atau berubah pikiran lalu menjadikannya berbahaya
  Hook instalasi seperti ini pada akhirnya adalah desain yang tidak berkelanjutan