Insiden Peretasan pada Paket npm debug dan chalk

• 8 September, terdeteksi adanya penyisipan malware pada paket-paket npm populer
• Total ada 18 paket yang terdampak, dengan lebih dari 2 miliar unduhan per minggu secara global
• Penyerang menyisipkan kode yang diam-diam mencegat aktivitas kripto dan Web3 di browser pengunjung situs, serta mengalihkan persetujuan dompet dan aliran dana ke akun milik penyerang
• Dipastikan bahwa kode JavaScript yang diobfuscasi telah ditambahkan ke file paket utama (index.js)
• Rangkaian insiden ini dimulai bersamaan dengan pembaruan paket yang menjadi target, dan saat ini komunitas sedang menanganinya

---

Ringkasan Insiden

• Per 8 September pukul 13:16 UTC, feed pemantauan keamanan Aikido menangkap fenomena diunggahnya beberapa paket yang mengandung malware ke npm
• Paket-paket ini sangat populer di npm, dengan lebih dari 2 miliar unduhan dalam seminggu

Metode dan Isi Serangan

• Setelah pembaruan berbahaya dirilis, terkonfirmasi adanya struktur yang menjalankan malware JavaScript secara diam-diam di browser pengunjung situs yang menggunakan paket tersebut
  • Tujuan kode ini adalah memantau aktivitas kripto dan Web3, memanipulasi interaksi dompet, serta mengubah alamat tujuan pembayaran tanpa izin
  • Tanpa perubahan khusus yang terlihat di layar, dana dan otorisasi pengguna dapat dikirim ke alamat kripto yang ditentukan penyerang

Analisis Detail Kode Berbahaya

• Sebagai contoh, pada is-arrayish dan paket lain, file index.js dimodifikasi dan disisipi JavaScript kompleks yang diobfuscasi
• Di dalam kode, antarmuka window.ethereum digunakan untuk memeriksa informasi akun dompet dan melalui prosedur verifikasi kondisi pemicu eksekusi kode serangan
• Secara internal terdapat banyak alamat kripto (Bitcoin, Ethereum, dan lainnya) serta logika fungsi, dengan implementasi yang mengganti alamat dompet dan detail transaksi ke alamat milik penyerang
• Hal ini menimbulkan risiko aset kripto pengguna nyata bocor dan dipindahkan tanpa izin tanpa disadari

Situasi Saat Ini dan Respons Komunitas

• Versi paket berbahaya yang bermasalah sedang segera dihapus dari repositori utama npm
• Komunitas IT/open source secara aktif menjalankan panduan penghentian penggunaan dan upgrade paket terkait, serta kegiatan deteksi dan penanganan infeksi tambahan
• Insiden peretasan ini menjadi momentum yang sangat meningkatkan kewaspadaan terhadap keamanan rantai pasok paket, deteksi obfuscation kode, dan perlindungan ekstensi browser Web3

[crawler]

8 September 2023,

Tanggalnya muncul salah karena halusinasi. Ini bukan cerita tahun 2023, melainkan kejadian sekarang.
Sepertinya cukup sering terdengar kabar npm diretas. Ini tampaknya bermasalah.

[GN⁺]

Opini Hacker News

• Ya, saya yang kena hack. Benar-benar memalukan dan saya minta maaf kepada semua orang. Untuk detailnya, silakan lihat di sini dan di sini. Saya sudah mengunggah daftar paket yang terdampak. Serangan ini tampaknya merupakan serangan yang ditargetkan. Saya akan terus memperbarui sampai waktu edit komentar habis. Paket Chalk sudah saya pulihkan, tetapi yang lain masih dibajak (8 Sep 17:50 CEST). NPM masih belum memberi kabar apa pun. Akun NPM saya masih tidak bisa diakses, dan fitur pemulihan kata sandi juga tidak berfungsi. Sekarang satu-satunya yang bisa saya lakukan adalah menunggu. Email dukungan datang dari npmjs dot help, dan tampilannya sangat meyakinkan. Ini bukan alasan, tapi saat itu pagi yang melelahkan, dan karena ingin cepat menyelesaikan satu hal, saya tanpa sadar mengklik tautan alih-alih seperti biasa langsung membuka situs resmi sendiri—mungkin karena saya sedang di ponsel. Serangan ini hanya memengaruhi NPM, dan saya akan terus memberi pembaruan di /debug-js. Sekali lagi, saya benar-benar minta maaf

  • Cara menanganinya cepat dan transparan di situasi yang penuh tekanan seperti ini benar-benar patut dicontoh. Rasanya sekarang saya tidak akan tertipu phishing, tetapi kalau boleh menambahkan beberapa tips: 1) jangan pernah login lewat tautan di email. Email phishing dan email asli terlalu sulit dibedakan, jadi satu-satunya cara agar tidak tertipu adalah tidak pernah mencobanya sama sekali. 2) Jika memakai security key U2F/Webauthn sebagai autentikasi dua faktor, perlindungannya nyaris sempurna terhadap phishing. TOTP tidak seperti itu. Pada akhirnya manusia selalu bisa membuat kesalahan saat lelah atau sibuk. Kali ini kebetulan dia yang menjadi targetnya. Sekali lagi, salut karena menanganinya dengan sangat baik

  • Atas arahan sindresorhus, Anda bisa memeriksa apakah ada malware di dependency tree Anda dengan perintah berikut: rg -u --max-columns=80 _0x112fa8 (butuh ripgrep, instal dengan brew install rg). Lihat juga komentar asli

  • Dulu waktu kuliah saya pernah kena phishing saat mabuk (meski itu sudah lama sekali). Siapa pun bisa menjadi korban. Tapi saya cukup terkejut karena respons NPM sangat lambat. Rasanya itu justru akan lebih menguntungkan penyerang

  • Socket langsung mendeteksi insiden ini. Mereka juga membahasnya di blog terkait. Kejadian ini memang disayangkan, tapi saya menghargai bahwa ekosistem open source merespons dengan sangat cepat. Kasus seperti ini kembali menunjukkan kenapa pemindaian paket itu penting

  • Terima kasih sudah cepat memberi peringatan. Saya sudah mengirim email ke porkbun untuk meminta domain itu diblokir

• Ada bagian licik dalam payload malware ini yang belum cukup mendapat perhatian. Ia tidak sekadar mengganti alamat dompet secara acak, tetapi menghitung jarak Levenshtein antara alamat yang benar dan masing-masing alamat dalam daftar miliknya, lalu memilih dompet penyerang yang paling mirip. Jadi ini dirancang untuk menembus kebiasaan keamanan umum di mana orang hanya memeriksa sekilas bagian awal dan akhir alamat. Ada tulisan yang merinci keseluruhan payload ini sampai tahap deobfuscation, termasuk fitur unik tersebut. Tetap hati-hati semuanya

  • Ada satu bagian di tulisannya yang membuat saya bingung. Setahu saya, package-lock.json memang “mengunci” versi tertentu secara tepat. package.json bisa mendefinisikan "versi x atau lebih tinggi", tetapi lockfile secara langsung mencantumkan versi yang dipilih dan URL tarball untuk tiap dependency. Jika lockfile ada, mestinya paket tidak diperbarui otomatis di lingkungan CI. Jadi saya penasaran apakah saya salah memahami cara kerja lockfile npm/yarn/pnpm. Silakan lihat juga kutipan dokumentasi npm

  • Saya rasa kalau nilai hash ditampilkan dengan warna berbeda untuk tiap karakter (warna depan/latar memakai skema warna yang ditentukan oleh hash dan indeksnya), akan jauh lebih mudah membedakan hash yang ditiru agar terlihat mirip secara visual

  • Saya penasaran apakah ada informasi yang menunjukkan teknik ini terkait dengan kelompok peretas tertentu

  • Kode serangan ini memang cerdik, tapi sebenarnya web sudah puluhan tahun melawan serangan alamat mirip seperti ini, dan ini hanya versi yang lebih dinamis. Saya tidak setuju kalau hal ini terlalu dibesar-besarkan seolah luar biasa. Jujur saja, keseluruhan tulisan analisis itu malah terasa seperti ditulis AI, jadi tidak terlihat seperti analisis yang benar-benar cermat

• Dua belas hari lalu saat Nx kena hal yang sama, saya meninggalkan komentar serupa. Ini bukan kegagalan satu orang, melainkan kegagalan seluruh industri. Serangan supply chain berdampak sangat besar, dan menurut saya sebenarnya ini masalah yang sudah bisa diselesaikan. Karena kita pengembang software, seharusnya ini bisa dicegah jika langkah keamanan standar seperti code signing, artifact signing, deteksi perilaku akun yang tidak biasa, 2FA, dan sejenisnya diterapkan secara menyeluruh. Fakta bahwa semua platform packaging masih belum melakukannya bukan karena keterbatasan teknis, tetapi karena tidak ada yang memaksa. Dengan perkembangan AI dan keberhasilan serangan nyata yang terus berulang, ini akan makin parah ke depan. Sudah saatnya standar keamanan yang kuat diwajibkan

  • Langkah-langkah keamanan seperti ini memang punya trade-off. Misalnya, jika menerapkan mekanisme berbasis heuristik atau proof, cukup banyak sistem otomatis atau pengguna biasa yang bisa tersisih. 2FA berbasis SMS lemah secara keamanan, dan email juga berisiko phishing. TOTP hanya berarti kalau dipakai sebagai open standard, dan tetap saja tidak sepenuhnya mencegah phishing. Hanya autentikasi berbasis hardware yang benar-benar efektif, tetapi itu punya keterbatasan karena sulit diterapkan secara realistis di platform berskala besar

  • Ini tidak sesederhana mengatakan “kalau standar keamanan dipatuhi, semuanya bisa dicegah”. Sehebat apa pun langkah keamanannya, kalau manusia membuat kesalahan, seluruh sistem tetap rentan. Sistem yang sepenuhnya aman itu tidak ada. Dengan perkembangan AI, email phishing makin sulit dibedakan dari yang asli, tetapi sebaliknya AI juga bisa dipakai untuk mendeteksi serangan seperti ini dengan lebih baik. Pada akhirnya kita juga harus bertahan dengan AI

  • Dulu banyak peretasan yang menargetkan Windows, sekarang jumlah pengembang JavaScript dan Python jauh lebih besar. Serangan seperti ini akan makin parah ke depan

• Saya rasa NPM juga punya tanggung jawab tertentu. Berbagai vendor keamanan eksternal atau startup bisa cepat menyadari aktivitas berbahaya seperti ini, jadi sulit dimengerti kenapa NPM—yang bisa melihat semua paket dan event keamanan secara real time—berulang kali tampak tidak berdaya. Rasanya hampir seperti sengaja berpura-pura tidak tahu

  • NPM sekarang milik GitHub, yang berarti milik Microsoft. Sepertinya mereka sibuk menjejalkan AI generatif seperti Copilot ke segala macam aplikasi

  • Untuk paket yang dikelola banyak orang, setidaknya harus ada opsi agar distribusi hanya bisa dilakukan setelah admin lain menyetujui publish tersebut

  • Penyerang yang sama menyuntikkan payload terobfuscasi—dan sangat mencurigakan—ke lebih dari 22 paket yang sudah lama tidak aktif, lalu merilis semuanya sekaligus. Menurut saya hampir mustahil meminta NPM menangkap itu. Sebagai orang yang pernah merilis aplikasi/ekstensi di platform software lain, menunggu berhari-hari atau berminggu-minggu itu hal biasa. Yang justru mengejutkan adalah NPM, meski MS dan GitHub menjual bermacam solusi keamanan, tampaknya tidak menunjukkan tanda-tanda investasi yang memadai pada layanannya

  • Saya juga tidak yakin NPM punya alasan kuat untuk berubah. Sudah lebih dari 10 tahun menjadi sumber distribusi malware, tapi tidak ada yang berhenti menggunakannya, jadi tidak ada dampak bisnis juga

  • Salah satu penyebabnya adalah penyebaran package manager yang berlebihan. Dari awal saya memang tidak suka ketergantungan pada paket untuk hal-hal sepele seperti ini. Saya juga sangat tidak suka ketika versi terbaru ditarik secara acak lalu lingkungan jadi rusak. Bukan cuma npm yang saya benci; package manager secara umum juga sama menjengkelkannya

• Pada titik ini, kalau seseorang memasukkan kata sandi langsung ke situs web yang domain resminya tidak cocok, tanpa password manager, saya rasa dia memang tidak layak melakukan hal penting di internet

  • Password manager/autofill browser seharusnya akan memperingatkan soal domain palsu seperti ini, dan juga mencegah ketidaksesuaian seperti npmjs.help versus domain resmi pada phishing NPM kali ini

  • Itu memang benar, tetapi saya juga cukup sering mengalami aplikasi resmi dan situs web resmi justru memakai domain yang benar-benar berbeda. Kasus terburuk adalah ketika aplikasi mobile dan web memakai domain yang sama sekali berbeda. Entah siapa yang merancang seperti itu

• Setiap kali kejadian seperti ini berulang, saya tidak mengerti kenapa package registry tidak mewajibkan semua paket ditandatangani secara kriptografis. Memang benar, jika CI/CD menandatangani secara otomatis dan lingkungan itu juga dibajak, pertahanan itu tetap bisa ditembus, tetapi mayoritas masalah bisa dicegah. Konsekuensinya, pengembang harus melalui langkah tambahan secara manual seperti mengunduh artifact, menandatangani, lalu mengunggahnya

  • Registry sungguhan sudah melakukannya, seperti Debian. npm terasa amatir, sehingga di lingkungan perusahaan besar sering dilarang dipakai

  • Pendekatan yang saya suka adalah verifikasi setelah fakta. Setelah upload otomatis lewat CI/CD, rilis baru benar-benar terjadi kalau ada orang yang masuk ke web dan menekan satu klik lagi. Dengan begitu friksi di proses rilis tetap rendah, tapi tetap ada satu langkah persetujuan manusia tambahan

  • Tapi tetap ada masalah sulit: “kunci tanda tangan mana yang harus dipercaya?” Siapa pun yang berhasil mengambil alih 2FA bisa mengunggah kunci baru untuk menandatangani, jadi tampaknya diperlukan hal seperti penundaan pendaftaran kunci tanda tangan baru ketika terdeteksi aktivitas akun yang mencurigakan

• Saya sampai pada kesimpulan bahwa jauh lebih menguntungkan untuk menghindari npm registry. Menurut saya lebih baik mengambil paket langsung dari repositori (git). npm registry adalah jalur utama serangan supply chain, dan juga punya masalah karena source code dan kode yang didistribusikan sepenuhnya terpisah. npm publish bisa langsung mengunggah kode apa pun dari lokal, jadi pengguna jahat bisa dengan mudah menyisipkan kode berbahaya

  • Ada fitur verifikasi keaslian saat deploy dari GitHub builds ke npm, tetapi saya tetap tidak sepenuhnya paham karena tampaknya publish masih bisa dilakukan dari lingkungan lain

  • Sebagai pengembang C, rasanya sangat aneh melihat bahwa dulu pendekatan seperti meminimalkan dependency, memakai library single-header, dan vendoring dianggap cara lama, lalu sekarang semua orang baru menyadari itu memang diperlukan

  • Fitur provenance terbaru npm menyelesaikan masalah ini. Pengaturannya juga cukup mudah, dan akan membantu mencegah serangan seperti ini. Senang melihat paket-paket besar mulai mengadopsinya satu per satu

  • Saya penasaran apakah cara ini juga dipakai di lingkungan CI. Maksud saya, apakah yang biasanya dilakukan dengan npm install di server diganti menjadi git clone

  • “Mengambil paket langsung dari repositori git” terdengar bagus secara teori, tetapi dalam praktiknya npm penuh bug dan ada banyak masalah yang memengaruhi instalasi dependency berbasis git. Seperti yang saya tulis di issue, sampai 2020 ini bahkan tidak berfungsi benar karena masalah build step, dan masih bermasalah ketika npm install dilakukan secara global. Bahkan jika skrip prepack memang disebut di dokumentasi npm, kenyataannya itu tidak berfungsi pada dependency berbasis git. Tim compiler TypeScript juga terpaksa memakai workaround aneh karena bug ini, dan ada kode untuk mengatasinya serta bug terkait. Fakta bahwa kegagalan prepack tidak meneruskan exit code sehingga npm install berakhir dalam keadaan rusak juga merupakan masalah. Melihat hal-hal seperti ini, saya rasa npm sangat butuh pengawasan operasional yang layak, atau bahkan perlu diganti sepenuhnya dengan package manager baru

• Dari sudut pandang orang luar ekosistem npm, saya heran kenapa begitu banyak paket ini dipakai untuk hal-hal yang sangat sepele

  • Alasannya karena standard library-nya terlalu miskin, dan bahkan fungsi dasar pun sering harus memakai paket eksternal. Kalau membuat sendiri, implementasi kecil pun jadi sangat banyak

  • Berdasarkan 15 tahun pengalaman pengembangan, saya bisa bilang banyak pengembang JavaScript profesional sebenarnya nyaris tidak bisa coding dengan baik. Ini bukan soal kemampuan intelektual, tetapi soal pendidikan dan budaya. Ada ketakutan yang sangat besar untuk menulis kode sendiri, sehingga akhirnya untuk hal sepele pun mereka selalu bergantung pada dependency eksternal. Pengembang proyek hobi justru sering tidak punya masalah itu, dan kodenya kadang lebih kokoh. Kalau tertarik, suruh saja rekan satu tim di kantor membangun sesuatu tanpa framework besar, dan Anda akan langsung tahu

  • Mengambil dalam unit modul kecil yang trivial bertujuan agar kode yang tidak perlu tidak ikut dibawa ke klien. Library komprehensif memang memberi DX yang lebih bersih, tetapi juga membawa kode yang tidak diinginkan (meskipun ada tree-shaking, itu bukan solusi ajaib)

  • Sejak insiden leftpad, perdebatan seperti ini terus ada. Mungkin memang karena standard library JS terlalu kecil

  • Dari sudut pandang reviewer, mengimpor satu modul yang terlihat “trusted” lewat PR perubahan kode akan terasa jauh lebih mudah daripada meninjau perubahan kode besar. Itu tidak benar-benar lebih aman, tetapi saat lelah memang terasa lebih meyakinkan

• Saat insiden nx sebelumnya saya juga berpendapat sama: package manager perlu punya “grace period” yang selalu melewati paket baru selama jangka waktu tertentu, misalnya 24 jam. Sebagian besar serangan seperti ini terdeteksi dan diblokir dengan cepat tak lama setelah rilis, jadi jika pengguna tidak otomatis memasang versi terbaru selama periode itu, dampak riilnya bisa dikurangi

• Saya bisa membayangkan rasa sakit dan stres yang dialami penulisnya. Harus terus menjelaskan hanya karena satu kesalahan pasti sangat berat. Ini juga menunjukkan bahwa ekosistem open source pada praktiknya sangat bergantung pada paket yang dimiliki satu orang. Kita harus mengakui bahwa siapa pun bisa diretas karena kesalahan. Dari sisi teknis, ketika AI sudah dipakai begitu luas, sepertinya perlu ada perubahan budaya seperti warning di deno/node/bun untuk kode mencurigakan, distribusi model @verified berbasis otentikasi ala Debian agar kepercayaan meningkat, dan memakai versi yang sudah terverifikasi alih-alih yang paling baru. Penulisnya juga manusia, dan kita semua harus bersikap baik. Setelah situasinya reda, saya juga ingin melihat analisis teknis yang lebih rinci atau postmortem