Bitwarden CLI Terdampak dalam Kampanye Rantai Pasok Checkmarx yang Sedang Berlangsung

 (socket.dev)
1 poin oleh GN⁺ 13 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Paket Bitwarden CLI untuk npm telah disusupi sebagai bagian dari serangan rantai pasok Checkmarx yang sedang berlangsung, dan cakupan dampak yang telah dikonfirmasi saat ini terbatas pada build @bitwarden/cli 2026.4.0
  • Kode berbahaya bw1.js yang disertakan dalam paket menggunakan infrastruktur dan metode obfuscation yang sama seperti audit.checkmarx[.]cx/v1/telemetry, serta selaras dengan indikasi kompromi CI/CD melalui GitHub Action yang telah disusupi
  • Target pengumpulan tidak hanya mencakup token GitHub, tetapi juga kredensial AWS, Azure, GCP, .npmrc, kunci SSH, variabel lingkungan, hingga file konfigurasi Claude/MCP
  • Informasi yang dicuri mengarah pada pembuatan dan commit repositori GitHub publik, penyebaran ulang untuk memperluas infeksi menggunakan token npm, injeksi workflow, serta mencakup fungsi persistensi seperti modifikasi ~/.bashrc dan ~/.zshrc
  • Organisasi yang menggunakan Bitwarden CLI harus menangani insiden ini sebagai paparan kredensial dan kompromi CI/CD, dengan fokus pada peninjauan log CI dan penggantian rahasia yang mungkin terekspos

Ringkasan

  • Paket npm Bitwarden CLI telah disusupi sebagai bagian dari serangan rantai pasok Checkmarx yang sedang berlangsung, dan versi target yang telah dikonfirmasi adalah @bitwarden/cli2026.4.0
    • Kode berbahaya terdapat dalam bw1.js yang disertakan di dalam paket
    • Jalur serangan selaras dengan indikasi penggunaan GitHub Action yang telah disusupi di dalam pipeline CI/CD Bitwarden, dan cocok dengan pola kampanye yang ditemukan di repositori lain
  • Hingga saat ini, cakupan yang telah dikonfirmasi terbatas pada build Bitwarden CLI, dan kompromi ini mengikuti vektor rantai pasok GitHub Actions yang diidentifikasi dalam kampanye Checkmarx
    • Hanya paket CLI untuk npm yang terkait
    • Ekstensi Chrome, server MCP, dan distribusi resmi lainnya belum dikonfirmasi terdampak hingga saat ini
  • Investigasi masih berlangsung, dan analisis teknis lengkap, versi yang terdampak, indikator kompromi, serta panduan respons akan dipublikasikan kemudian
  • Jika Anda menggunakan Bitwarden CLI, diperlukan peninjauan log CI dan penggantian rahasia yang berpotensi terekspos

Analisis teknis

  • Payload berbahaya bw1.js berbagi infrastruktur inti dengan mcpAddon.js milik Checkmarx yang dianalisis sehari sebelumnya
    • Menggunakan endpoint C2 yang sama, yaitu audit.checkmarx[.]cx/v1/telemetry, dan di-obfuscate dengan __decodeScrambled serta seed 0x3039
    • Juga melakukan eksfiltrasi berbasis commit melalui GitHub API serta pencurian token dan redistribusi melalui registry npm
  • Struktur payload tertanam juga berasal dari keluarga yang sama
    • Di dalam struktur gzip+base64 terdapat skrip Python yang mengais memori GitHub Actions Runner.Worker untuk memburu token GitHub
    • Juga disertakan loader setup.mjs untuk paket npm yang didistribusikan ulang, workflow YAML GitHub Actions, kunci publik RSA yang di-hardcode, dan string manifesto ideologis
  • Cakupan pengumpulan kredensial sangat luas
    • Token GitHub dikumpulkan melalui scraping memori Runner.Worker dan variabel lingkungan
    • Kredensial AWS dicari dari file ~/.aws/ dan variabel lingkungan
    • Token Azure dikumpulkan melalui azd, sementara kredensial GCP melalui gcloud config config-helper
    • .npmrc, kunci SSH, variabel lingkungan, dan file konfigurasi Claude/MCP juga termasuk target
  • Metode eksfiltrasi melalui GitHub juga telah dikonfirmasi secara spesifik
    • Membuat repositori publik di bawah akun korban dengan pola nama bertema Dune {word}-{word}-{3digits}
    • Melakukan commit hasil terenkripsi, dan pada pesan commit menyisipkan token bersama marker LongLiveTheResistanceAgainstMachines
  • Bahkan mencakup mekanisme penyebaran rantai pasok
    • Dengan token npm yang dicuri, penyerang mencari paket yang dapat ditulisi lalu mendistribusikannya ulang dengan preinstall hook yang telah disisipkan
    • Workflow GitHub Actions juga disuntikkan untuk mengumpulkan rahasia repositori tambahan
  • Terdapat kill switch locale Rusia
    • Jika locale sistem diawali dengan "ru", malware akan berhenti secara diam-diam
    • Ia memeriksa Intl.DateTimeFormat().resolvedOptions().locale serta variabel lingkungan LC_ALL, LC_MESSAGES, LANGUAGE, LANG
  • Runtime yang digunakan adalah Bun v1.3.13 dan diunduh dari GitHub Releases

Perbedaan dari insiden Checkmarx

  • bw1.js memuat indikator kompromi tambahan yang tidak ada dalam dokumentasi insiden Checkmarx
    • Menggunakan file lock yang di-hardcode /tmp/tmp.987654321.lock untuk mencegah eksekusi bersamaan
    • Menyuntikkan payload ke ~/.bashrc dan ~/.zshrc untuk mendapatkan persistensi profil shell
    • Menggunakan branding eksplisit, seperti menyetel deskripsi repositori menjadi Shai-Hulud: The Third Coming dan menyertakan string debug "Would be executing butlerian jihad!"
  • Meski alat yang dibagikan sangat mengindikasikan keterhubungan dalam ekosistem malware yang sama, tanda tangan operasional justru membuat atribusi lebih sulit
    • Setelah ditemukan, serangan Checkmarx diklaim oleh TeamPCP melalui akun sosial @pcpcats
    • Malware terkait berupaya menyamar dengan deskripsi yang tampak normal
  • Payload kali ini memperlihatkan sikap publik yang berbeda
    • Penanda ideologis seperti nama repositori Shai-Hulud, manifesto "Butlerian Jihad", dan pesan commit yang mengusung perlawanan terhadap mesin langsung tertanam di dalam malware
    • Karena itu, masih terbuka beberapa kemungkinan: operator lain yang memakai infrastruktur yang sama, faksi yang lebih ideologis, atau perubahan sikap publik dalam kampanye ini

Rekomendasi

  • Organisasi yang memasang paket npm Bitwarden berbahaya harus memperlakukan insiden ini sebagai insiden paparan kredensial dan kompromi CI/CD
  • Segera hapus paket yang terdampak dari sistem pengembang dan lingkungan build, lalu ganti semua kredensial yang mungkin terekspos di lingkungan tersebut
    • Termasuk token GitHub, token npm, kredensial cloud, kunci SSH, dan rahasia CI/CD
  • Di GitHub, perlu dilakukan pemeriksaan terhadap pembuatan repositori tidak sah dan workflow yang tidak normal
    • Periksa file tak terduga di bawah .github/workflows/, eksekusi workflow mencurigakan, unduhan artifact, dan repositori publik dengan pola nama bertema Dune {word}-{word}-{3digits}
    • Jika ada potensi dampak, periksa kata kunci berikut di repositori yang baru dipublikasikan
      • atreides
      • cogitor
      • fedaykin
      • fremen
      • futar
      • gesserit
      • ghola
      • harkonnen
      • heighliner
      • kanly
      • kralizec
      • lasgun
      • laza
      • melange
      • mentat
      • navigator
      • ornithopter
      • phibian
      • powindah
      • prana
      • prescient
      • sandworm
      • sardaukar
      • sayyadina
      • sietch
      • siridar
      • slig
      • stillsuit
      • thumper
      • tleilaxu
  • Di npm, audit perlu dilakukan untuk memeriksa apakah ada distribusi tidak sah
    • Periksa publish yang tidak disetujui, perubahan versi, dan hook instalasi yang baru ditambahkan
  • Di lingkungan cloud, log akses harus ditinjau ulang
    • Perlu menelusuri akses rahasia yang tidak biasa, penggunaan token, dan kredensial yang baru diterbitkan
  • Pada endpoint dan runner, perlu ditelusuri jejak infrastruktur eksfiltrasi dan akses file yang teramati
    • Perlu mencari koneksi keluar ke audit[.]checkmarx[.]cx
    • Periksa apakah ada eksekusi Bun di lingkungan yang biasanya tidak menggunakannya
    • Tinjau jejak akses ke .npmrc, .git-credentials, .env, penyimpanan kredensial cloud, gcloud, az, azd
    • Periksa juga keberadaan /tmp/tmp.987654321.lock serta apakah ~/.bashrc dan ~/.zshrc dimodifikasi
  • Di GitHub Actions, tinjau apakah ada workflow yang dibuat tanpa otorisasi
    • Perlu dipastikan apakah workflow dibuat di branch sementara
    • Periksa juga apakah artifact seperti format-results.txt dibuat atau diunduh
  • Dalam jangka panjang, perlu dilakukan pengurangan radius dampak untuk insiden rantai pasok berikutnya
    • Perkecil cakupan izin token dan gunakan kredensial berumur pendek bila memungkinkan
    • Batasi hak untuk membuat dan mendistribusikan paket serta perketat izin GitHub Actions
    • Nonaktifkan akses artifact yang tidak diperlukan, dan pantau repositori publik atau perubahan workflow yang muncul di luar prosedur rilis normal

Indikator kompromi

Bacaan terkait

1 komentar

 
GN⁺ 13 jam lalu
Komentar Hacker News

  • Ingin tahu apakah ada pertahanan yang lebih baik daripada menetapkan masa tunggu rilis minimum
    Bahkan jika hanya menambahkan min-release-age=7 ke .npmrc, tampaknya 334 orang yang menerima @bitwarden/cli 2026.4.0, yang diunggah sekitar 19 jam lalu lalu terbukti berbahaya, bisa terhindar
    Pendekatan ini juga cukup cocok untuk kasus seperti axios, ua-parser-js, dan node-ipc; meski tidak bisa mencegah kasus seperti event-stream yang bersembunyi lama, tampaknya efektif untuk sebagian besar serangan rantai pasok yang sifatnya akut
    Ada contoh konfigurasi untuk menambahkan waktu tunggu di npm/pnpm/bun/uv, dan karena tidak ada alat sekali klik untuk memeriksa dan menerapkannya, saya membuat https://depsguard.com sendiri
    Baru saja saya juga melihat https://cooldowns.dev, yang punya ide serupa

    • Saya menggunakan Aikido safe-chain
      Bukan sekadar menetapkan masa tunggu rilis minimum, tapi sebagai wrapper untuk npm/uv dan semacamnya, ia memeriksa tiap dependensi sebelum instalasi terhadap database kerentanan komersial untuk mendeteksi masalah yang sudah diketahui atau sinyal mencurigakan
    • Ide cooldown ini bagus, tapi saya juga penasaran apakah serangan ini benar-benar akan tertangkap jika tidak ada seorang pun yang langsung memperbarui
      Dalam praktiknya pasti selalu ada seseorang yang update seketika, tetapi proses terungkapnya insiden seperti ini tampaknya memang bergantung pada para pengguna yang cepat memperbarui
    • Menurut saya lebih baik mulai dari tidak menaruh backend atau alat CLI di NPM
    • Untuk instalasi baru mungkin iya, tapi untuk dependensi yang sudah ada, bukankah cukup dengan mem-pin versi patch dan mengunci sha?
    • Serangan seperti ini biasanya tidak sampai masuk ke upstream source, jadi pendekatan build from source seperti https://www.chainguard.dev/libraries bisa mencegah kira-kira 98% kasus
      Jika memang harus menarik biner registry apa adanya, cooldown bisa sedikit menurunkan risiko
      Untuk kasus ekor panjang yang bahkan sudah menembus sisi GitHub, tampaknya perlu kombinasi heuristik commit/maintainer dan analisis perubahan kode berbasis AI, lalu ditinjau manusia jika ada tanda aneh
      Sebagai catatan, saya bekerja di bidang ini

  • Inti insiden kali ini adalah pipeline build dibajak sehingga paket yang terkontaminasi bisa didistribusikan
    Meski begitu, jika Anda menaruh sesuatu yang penting bagi bisnis di npm, saya tetap merasa dependensinya sebaiknya dipin
    Banyak developer menganggap lockfile sudah cukup, tetapi jika rentang ^ masih ada, saat lockfile diperbarui versi baru yang tidak saya pilih secara eksplisit bisa ikut tertarik
    Jika ini sistem yang bisa memengaruhi kelangsungan hidup perusahaan, kerepotan sebesar ini tetap layak dijalani

    • Kalau dipikir sebaliknya, saat kerentanan keamanan diperbaiki di versi yang lebih baru, justru idealnya sistem bisa otomatis menerima dan menerapkannya

  • https://github.com/doy/rbw adalah alternatif Rust untuk Bitwarden CLI
    Ekosistem Rust juga terasa makin menuju pohon dependensi yang besar dan dalam seperti npm, tetapi setidaknya jumlah penulis yang perlu dipercaya masih jauh lebih sedikit dibanding kasus yang umum di JavaScript

    • Jika melihat https://github.com/doy/rbw/blob/main/Cargo.toml#L16, di sini juga dependensinya cukup banyak
      Tapi setidaknya versinya dipin
    • Saya penasaran apakah ada kekurangan memakai pengelola kata sandi bawaan Firefox
    • Orang-orang tampaknya terlalu mudah mengabaikan bahwa walaupun Rust dianggap lebih aman, risiko menarik malware lewat dependensi meningkat cukup besar
    • Kombinasi rbw + vaultwarden bekerja cukup baik sebagai Bitwarden versi Rust yang bisa self-host
    • Karena hal seperti ini, saya rasa makin banyak perangkat lunak bisa beralih ke stack seperti .Net yang bisa menyelesaikan sebagian besar hal tanpa dependensi pihak ketiga
      Atau justru bergerak ke arah memasukkan lebih banyak fungsi ke pustaka standar bahasa

  • Pengalaman saya dengan Bitwarden CLI sangat buruk
    Saya menjalankan bw list, mengira yang akan muncul hanya nama kata sandi, tetapi ternyata yang ditampilkan adalah kata sandi lengkap beserta kode TOTP saat ini
    Yang lebih menyeramkan, ketika saya masuk ke server lewat ssh dan membuka weechat di dalam tmux, seluruh isi perintah bw ternyata bisa diakses dari riwayat input weechat
    Saya benar-benar tidak tahu kenapa, dan itu tetap ada melintasi sesi tmux dan weechat sampai saya harus me-reboot server agar hilang
    Setelah itu saya langsung menghapus CLI bw dan tidak berniat memasangnya lagi
    Sebagai catatan, terminal yang saya pakai adalah ghostty

    • Ini lebih mirip keluhan yang tidak terkait dengan topik utama
    • Saya sempat ingin mencoba CLI-nya, tapi mundur setelah melihat itu berbasis JavaScript
    • Ini benar-benar aneh
      Saya jadi penasaran apakah ada ekstensi bwcli untuk weechat, dan baru kali ini juga saya tahu Bitwarden punya CLI
      Saya sendiri memakai keepass secara lokal

  • Saya tidak memakai CLI, tapi memakai plugin browser-nya
    Kalau ini sampai jebol, benar-benar gawat, dan saya tidak tahu harus melakukan apa untuk mencegahnya
    Saya jadi bertanya-tanya apakah jawabannya adalah terus memakai versi lama yang sudah terverifikasi
    Rasanya aneh menyadari lagi bahwa sebagian besar hidup saya bergantung pada rahasia-rahasia ini tetap rahasia

    • Semakin banyak titik integrasi, semakin besar pula permukaan serangannya
      Karena itu saya sama sekali tidak memakai ekstensi browser untuk pengelola kata sandi
      Setelah dulu melihat produk yang punya masalah keamanan pada integrasi browser, saya sepenuhnya menghindarinya; integrasi iOS relatif lebih saya percaya, tapi tetap saya waspadai
    • Menurut saya cooldown harus menjadi nilai bawaan di mana-mana
      Termasuk package manager untuk development, package manager OS, ekstensi browser, sampai pembaruan otomatis aplikasi mandiri
      Perusahaan seperti Socket perlu diberi waktu untuk menangkap pembaruan berbahaya, tetapi kalau semua orang mengunduhnya beberapa menit setelah dipublikasikan, deteksi seperti itu jadi tidak berarti
    • Aset digital saya yang paling berharga, yaitu email dan akun Bitwarden, selalu dilindungi dengan satu Yubikey yang selalu saya bawa dan satu kunci cadangan di lokasi berbeda
      Saya sangat merekomendasikan konfigurasi seperti ini
      Melihat judulnya saya sempat cukup panik, tetapi saya merasa saya sudah melakukan semua yang wajar tanpa sampai paranoid
    • Alih-alih plugin browser, gunakan aplikasi desktop atau web vault langsung
    • Cara mencegahnya, singkatnya, adalah dua ini
      https://cooldowns.dev
      https://depsguard.com
      Yang kedua saya kelola sendiri, dan kalau saja saya tahu yang pertama lebih dulu, mungkin saya tidak perlu membuatnya
      Keduanya melakukan hal yang hampir sama, hanya saja milik saya sedikit berlebihan karena memakai Rust

  • Hal terpenting di sini adalah fakta bahwa cukup dengan npm install saja
    Jika titik komprominya ada di preinstall, anggapan umum bahwa paket bisa diperiksa setelah dipasang langsung runtuh
    Pada titik itu payload sudah mendapat kesempatan untuk dieksekusi
    Ini jadi lebih menarik dalam lingkungan agent, CI, ephemeral sandbox, karena walau waktu paparan singkat, instalasi yang berulang secara otomatis tetap cukup untuk terkena dampaknya
    Hal lain yang patut diperhatikan adalah payload ini tidak hanya memburu rahasia, tetapi juga menargetkan konfigurasi tooling AI
    Modifikasi profil shell bisa menjadi jalur yang realistis untuk mencemari konteks yang nantinya dibaca coding assistant berikutnya
    Perspektif ini saya tulis lebih panjang bersama pekerjaan AgentSH di https://www.canyonroad.ai/blog/the-install-was-the-attack/

    • Praktis tidak ada orang yang memeriksa paket setelah instalasi, dan menurut saya menjadikan skrip npm install sebagai masalah yang istimewa adalah klaim yang sudah berkali-kali dibantah
      Pada akhirnya Anda tetap akan menjalankan biner aslinya
      Dan kalau mau benar-benar diperdebatkan, paket itu juga bisa diunduh dan diperiksa sebelum dipasang; justru lebih aneh kalau Anda dengan setengah hati mempercayai proses mengunduh dan mengekstrak kode berbahaya tanpa benar-benar memahami jaminan perilaku dan cakupan instalernya

  • Kill switch locale Rusia, terdengar berani sekaligus pengecut

    • Yang lebih buruk, kita bahkan tidak tahu apakah ini benar-benar jejak asli atau hanya false flag
    • Berbagai pepatah seperti Discretion is the better part of valor langsung teringat
      Intinya, ini terlihat seperti sikap tidak melukai diri sendiri
    • Itu sendiri bukan bukti yang menentukan
      Dalam kebocoran Vault7 juga ada isi bahwa NSA dan CIA sengaja meninggalkan jejak seperti ini untuk mengaburkan asal, dan ini sepenuhnya merupakan teknik yang mungkin dipakai aktor negara lain juga
    • Ini juga tampak seperti operasi intimidasi oleh negara lain
    • Siapa yang akan menyetel locale seperti itu dalam job GitHub CI untuk npm publish?
      Terlalu mencolok sebagai jejak pengelabuan, tetapi sekaligus memberi kesan kuat bahwa ada aktor negara yang terlibat

  • Menjadi pengguna KeePass membuat stres seperti ini jauh lebih kecil
    Hanya dalam 5 tahun terakhir, memakai KeePass di infrastruktur lokal sudah membantu saya menghindari beberapa insiden keamanan

    • Kali ini yang bermasalah adalah alat aksesnya, bukan vault-nya sendiri
      Bukan berarti masalah seperti ini mustahil terjadi pada alat akses untuk KeePass, jadi saya kurang paham apa sebenarnya perbedaannya
    • Saya perlu mengakses kata sandi baik dari infrastruktur maupun ponsel, jadi saya penasaran bagaimana KeePass menyelesaikan itu
      Saya selama ini mengira itu tidak mungkin, tapi jujur belum pernah mendalaminya
    • Mungkin cocok bagi orang yang bisa menjalankan infrastrukturnya sendiri, tetapi sulit menerapkan istilah stress free sampai ke pengguna rata-rata
    • Saya paham konsep file tunggalnya, tetapi secara realistis saya penasaran bagaimana sinkronisasi dan penyelesaian konflik ditangani
      Misalnya dua perangkat sama-sama offline lalu masing-masing menambahkan kata sandi, apa yang terjadi saat keduanya kembali online?
    • Hal yang masih belum saya pahami dari KeePass adalah backup cloud
      Jika backup-nya dienkripsi, kata sandinya disimpan di mana, dan lalu kata sandi penyedia cloud-nya sendiri disimpan di mana?

  • Yang sangat mengesankan dari serangan kali ini adalah para penyerang harus menyesuaikannya dengan tepat pada saat GitHub sedang tidak down

  • Karena itu saya sama sekali tidak memakai pengelola kata sandi pihak ketiga
    Soalnya Anda harus terus percaya bahwa mereka akan menangani keamanan, pembaruan, dan backup dengan benar
    Saya membuat sendiri generator kata sandi stateless, sehingga tidak perlu backup atau sinkronisasi data antarperangkat sama sekali
    Caranya dengan memasukkan master password yang sangat panjang dan kuat, nama layanan, serta nama pengguna, lalu menjalankan hash scrypt dengan parameter yang sesuai sehingga brute force secara praktis menjadi mustahil
    Untuk akun penting saya juga memakai 2FA