Security Blog

Tidak Seharusnya Ada yang Bisa Dipanen

#71

October 2, 2026 · By Marketing team

← All posts

Versi Bitwarden CLI yang disusupi memanen kunci SSH, kredensial cloud, dan token npm dari 334 mesin pengembang. Masalah sebenarnya bukan bagaimana malware masuk. Masalahnya adalah setiap rahasia itu tergeletak sebagai berkas biasa, menunggu untuk dibaca.

Kemarin, versi Bitwarden CLI yang disusupi memanen kunci SSH, kredensial AWS, token npm, variabel lingkungan, riwayat shell, dan rahasia Git dari 334 mesin pengembang.

Hari ini giliran Bitwarden. Bulan lalu Axios. Sebelumnya, Checkmarx. Besok bisa jadi ekstensi VS Code, atau Acrobat, atau formula Homebrew, atau image Docker. Vektornya berubah tiap minggu. Hasilnya selalu sama.

Malware mendarat. Ia membaca ~/.ssh/. Ia membaca ~/.aws/credentials. Ia membaca ~/.npmrc. Ia membaca ~/.git-credentials. Ia membaca riwayat shell, variabel lingkungan, penyimpanan kata sandi peramban. Ia membungkus semuanya dan mengirimkannya ke server C2.

Dan itu berhasil. Setiap kali.

Pemanenan

Payload Bitwarden — berkas 10 MB yang disamarkan bernama bw1.js — tidak mencoba memecahkan enkripsi apa pun. Ia tidak perlu. Berikut yang dikumpulkannya, sebagaimana didokumentasikan oleh Socket dan Aikido:

  • Kunci SSH dan sidik jari host
  • Kredensial cloud AWS, GCP, dan Azure
  • Token autentikasi npm
  • Kredensial Git dan URL remote
  • Variabel lingkungan
  • Riwayat shell
  • Autentikasi Claude Code dan konfigurasi MCP

Kemudian ia memakai token npm yang dicuri untuk menerbitkan ulang paket-paket lain yang dikelola korban, menyebarkan dirinya lebih jauh. Korban menjadi vektor.

Semua ini tidak memerlukan pembobolan enkripsi. Setiap rahasia ini adalah berkas pada sistem berkas, yang dapat dibaca oleh proses apa pun yang berjalan sebagai pengguna tersebut.

Ini bukan cerita Bitwarden

Enkripsi brankas Bitwarden tidak dibobol. Arsitektur zero-knowledge mereka bertahan. Malware tidak pernah menyentuh brankas.

Ia tidak perlu.

Brankas melindungi isinya. Tapi kunci SSH tidak pernah ada di dalam brankas. Kredensial AWS tidak pernah ada di dalam brankas. Token npm, kredensial Git, kunci API di berkas .env — semuanya tidak tinggal di pengelola kata sandi. Semuanya tinggal di dotfile, dalam bentuk plaintext, di setiap mesin pengembang.

Penyerang memahami ini. Brankas itu brankas terkunci di sebuah rumah yang semua lacinya terbuka.

Serangan permukaan yang sebenarnya

Buka terminal sekarang juga. Lihat apa yang ada di mesin Anda.

~/.ssh/id_ed25519 — kunci pribadi Anda. Berkas plaintext.

~/.aws/credentials — akses cloud Anda. Berkas plaintext.

~/.npmrc — token publikasi Anda. Berkas plaintext.

~/.git-credentials — akses repositori Anda. Berkas plaintext.

~/.env di selusin direktori proyek — kunci API, kata sandi basis data, rahasia penandatanganan. Semuanya berkas plaintext.

Proses apa pun yang berjalan sebagai pengguna Anda dapat membaca semua ini. Tidak perlu eskalasi hak akses. Tidak perlu eksploit. Cukup cat.

Inilah konfigurasi bawaan pengembang pada tahun 2026. Kita menyimpan kata sandi di brankas terenkripsi dan meninggalkan sisanya terbuka.

Pertanyaan yang salah

Setelah setiap serangan rantai pasokan, industri mengajukan pertanyaan yang sama: bagaimana mencegah malware masuk?

Keamanan CI/CD yang lebih baik. Penandatanganan kode. Pemindaian dependensi. Runtime ter-sandbox. Semua ini bagus. Tidak satu pun yang cukup. Permukaan serangan terlalu luas. Terlalu banyak vektor — pengelola paket, ekstensi peramban, plugin IDE, aplikasi OAuth, alat build yang disusupi. Anda tidak dapat menutup setiap titik masuk.

Pertanyaan yang tepat adalah: ketika malware pasti mendapatkan eksekusi di mesin seorang pengembang, apa yang ia temukan?

Jika jawabannya "ratusan kredensial plaintext di lokasi sistem berkas yang dapat ditebak," sekeras apa pun pengerasan rantai pasokan tidak ada gunanya. Anda bertahan di lapangan yang gawangnya terbuka lebar di belakang Anda.

Tidak seharusnya ada yang bisa dipanen

Perbaikannya bukan deteksi malware yang lebih baik. Perbaikannya bukan sandbox untuk npm install. Perbaikannya bukan waktu respons insiden yang lebih cepat.

Perbaikannya adalah: rahasia tidak seharusnya eksis sebagai berkas di disk.

Kunci SSH yang diturunkan dari perangkat keras pada saat autentikasi — bukan disimpan di ~/.ssh/. Kredensial cloud yang diterbitkan per sesi dari identitas yang terikat perangkat keras — bukan ditulis ke ~/.aws/. Token API yang ber-cakupan sempit, efemeral, dan dijaga perangkat keras — bukan tergeletak di berkas .env.

Ketika sebuah kredensial hanya ada di dalam modul keamanan perangkat keras dan dalam memori proses yang efemeral saat dipakai, tidak ada yang bisa dibaca malware. Tidak ada berkas untuk dieksfiltrasi. Tidak ada dotfile untuk digarap. Proses berjalan, tidak menemukan apa pun, lalu berlanjut.

Ini bukan hal yang teoritis. Kredensial yang terikat perangkat keras sudah ada hari ini. PRF WebAuthn dapat menurunkan kunci kriptografi dari ketukan autentikator fisik — kunci yang tidak pernah menyentuh sistem berkas. Teknologinya sudah ada. Industri hanya belum mengadopsinya sebagai standar bawaan.

Yang harus dilakukan sekarang

Jika Anda terdampak oleh kompromi Bitwarden CLI:

  • Ganti setiap kredensial di mesin tersebut — kunci SSH, token cloud, token npm, kunci API, semua yang ada di dotfile dan variabel env
  • Periksa apakah paket npm yang Anda kelola diterbitkan ulang
  • Audit aktivitas GitHub dan alur kerja CI/CD untuk perubahan yang tidak sah

Jika Anda tidak terdampak, tindakannya sama. Lihat mesin Anda. Hitung jumlah rahasia plaintext. Tanyakan pada diri Anda apa yang terjadi ketika — bukan jika — sesuatu yang berbahaya berjalan sebagai pengguna Anda.

Jawabannya seharusnya: tidak ada. Tidak seharusnya ada yang bisa dipanen.