1 poin oleh GN⁺ 2025-12-24 | 1 komentar | Bagikan ke WhatsApp
  • Paket Lotusbail adalah fork dari pustaka WhatsApp Web API yang sah, Baileys, dan merupakan paket berisi malware yang telah diunduh lebih dari 56 ribu kali di npm selama 6 bulan
  • Sambil menyediakan fungsi API yang bekerja normal, paket ini mencuri kredensial autentikasi WhatsApp, pesan, kontak, dan file media lalu mengirimkannya ke server penyerang
  • Data dikirim setelah melalui beberapa lapisan enkripsi dan obfuskasi seperti RSA, AES, Base-91, LZString, sehingga memungkinkan menghindari pemantauan keamanan
  • Paket ini memasang backdoor yang menghubungkan perangkat penyerang secara permanen ke akun WhatsApp pengguna melalui kode pairing yang di-hardcode
  • Kasus ini menunjukkan semakin canggihnya serangan supply chain dan menekankan pentingnya pemantauan keamanan berbasis perilaku yang tidak bisa digantikan oleh analisis statis saja

Ikhtisar paket Lotusbail

  • lotusbail adalah fork dari @whiskeysockets/baileys yang sah dan menyediakan fungsi WhatsApp Web API apa adanya
    • Fungsi kirim dan terima pesan bekerja normal sehingga pengembang cenderung memasangnya tanpa curiga
    • Paket ini telah terdaftar di npm selama 6 bulan dan saat artikel ditulis masih bisa diunduh
  • Di balik fungsi nyatanya, tersembunyi aktivitas berbahaya seperti pencurian kredensial WhatsApp, penyadapan pesan, pengumpulan kontak, dan pemasangan backdoor

Informasi yang dicuri

  • Termasuk token autentikasi dan kunci sesi, seluruh riwayat pesan, daftar kontak beserta nomor telepon, file media dan dokumen, serta hak akses backdoor yang persisten
  • Semua data dienkripsi sebelum dikirim ke server penyerang

Cara kerja

Fungsi penyamaran yang benar-benar berjalan

  • Sebagian besar paket npm berbahaya mudah dikenali karena tidak berfungsi atau memuat kode mencurigakan, tetapi Lotusbail menyamar sebagai API yang bekerja normal
  • Paket ini berbasis pustaka Baileys yang sah dan fitur kirim-terima pesannya diimplementasikan secara lengkap
  • Karena itu, digunakan teknik social engineering yang membuat pengembang tidak mencurigai perilaku berbahaya pada “kode yang berjalan normal”
Iklan

Pencurian dan pengiriman data

  • Paket ini bekerja dengan membungkus klien WebSocket yang berkomunikasi dengan WhatsApp
    • Saat autentikasi, paket menangkap kredensial, dan saat pesan diterima atau dikirim, seluruh isinya disalin
    • Fungsi normal tetap dipertahankan, hanya saja semua data dikirim ganda ke penyerang
  • Data yang dicuri dikirim setelah dienkripsi dengan implementasi RSA kustom
    • Ini terpisah dari enkripsi end-to-end milik WhatsApp dan digunakan sebagai enkripsi untuk menghindari pemantauan jaringan
  • Alamat server tidak diekspos langsung di dalam kode, melainkan disembunyikan dalam string konfigurasi terenkripsi
    • Diterapkan obfuskasi empat tahap seperti manipulasi variabel Unicode, kompresi LZString, encoding Base-91, dan enkripsi AES
Iklan

Pemasangan backdoor

  • Paket ini menyalahgunakan fitur kode pairing perangkat WhatsApp untuk menghubungkan perangkat penyerang ke akun pengguna
    • Di dalam paket terdapat kode pairing yang di-hardcode dan dienkripsi dengan AES
    • Saat pengguna melakukan autentikasi, perangkat penyerang ikut terhubung secara bersamaan sehingga memperoleh akses akun yang persisten
  • Penyerang dapat melakukan kontrol penuh atas akun, termasuk membaca dan mengirim pesan, mengunduh media, serta mengakses kontak
  • Bahkan jika paket npm dihapus, perangkat penyerang tetap terhubung, dan pemblokiran hanya bisa dilakukan dengan memutus semua perangkat yang tertaut secara manual di pengaturan WhatsApp

Teknik penghindaran analisis

  • Kode ini memuat 27 jebakan infinite loop sehingga eksekusi dihentikan saat alat debugging terdeteksi
    • Paket mendeteksi debugger, argumen proses, lingkungan sandbox, dan lain-lain untuk mengganggu analisis dinamis
    • Ada komentar pada bagian kode berbahaya, yang menunjukkan jejak pengelolaan pengembangan yang sistematis

Kesimpulan dan implikasi keamanan

  • Serangan supply chain semakin canggih, dan kasus yang menyamar sebagai kode yang berfungsi normal terus meningkat
  • Analisis statis dan verifikasi berbasis reputasi saja sulit untuk mendeteksi kasus semacam ini, sehingga diperlukan analisis perilaku saat runtime (behavioral analysis)
  • Kasus Lotusbail menunjukkan bagaimana celah keamanan yang “menganggap kode aman hanya karena berfungsi” dapat dieksploitasi, dan menegaskan pentingnya membangun sistem pemantauan perilaku saat runtime
  • Tim riset Koi Security mengidentifikasi ancaman yang melewati prosedur verifikasi yang ada melalui teknologi deteksi berbasis runtime tersebut

1 komentar

 
GN⁺ 2025-12-24
Opini Hacker News
  • Setiap kali ada insiden malware, menjengkelkan melihat tim keamanan bergerak ke arah mengunci data secara berlebihan
    Kebocoran pesan WhatsApp memang jadi pemicunya, tetapi pada akhirnya mereka pasti akan mencuri hal lain
    Jika aplikasi dibatasi agar hanya tanda tangan tertentu yang bisa membacanya, pencadangan yang sah maupun akses data yang valid juga jadi mustahil
    Bagus kalau keamanan diperkuat, tetapi pertahanan berlebihan yang mengunci semuanya menurut saya menimbulkan masalah lain

    • Setuju. Sebagai catatan, paket ini bukan pembungkus API resmi WhatsApp, melainkan klien WhatsApp Web hasil rekayasa balik
      Pengguna mengaksesnya seperti saat menghubungkan klien lain ke akun WhatsApp, dan akibatnya seluruh data bisa diakses
      Kalau WhatsApp menyediakan API resmi yang layak, kejadian seperti ini mungkin akan lebih jarang
      Dokumentasi terkait: Baileys Wiki
    • Saya rasa OS harus menjadi perantara akses data antar-aplikasi, dan pengguna harus diminta izin akses secara eksplisit
    • Menurut saya WhatsApp membuat pembatasan seperti ini bukan demi keamanan, melainkan untuk membatasi persaingan
    • Mengunci aplikasi pada akhirnya hanyalah cara agar perusahaan memperoleh lebih banyak kendali dan keuntungan
      Dulu malware memang lebih banyak, tetapi kebebasan dan interoperabilitas juga jauh lebih besar
    • Ada komik xkcd yang menyindir situasi ini dengan sangat tepat
  • Serangan seperti ini sekarang tampak sebagai konsekuensi yang bisa diprediksi
    Manajer paket seperti NPM pada dasarnya rentan secara struktural karena mengambil dependensi tepat sebelum proses build
    Masalahnya adalah budaya menerima banyak dependensi tanpa verifikasi, sambil melewati sistem kontrol versi

    • Saya makin sadar bahwa kita sebagai pengembang memang sangat lemah dalam keamanan
      Bukan hanya NPM; Cargo, Docker, CI/CD, dan seluruh ekosistem punya masalah serupa
      Strukturnya hanya “instal berdasarkan nama lalu selesai”, jadi tingkat kepercayaannya terlalu besar
      Tidak ada solusi yang benar-benar memadai — kita tidak bisa berhenti berkolaborasi, tetapi keamanan sempurna juga mustahil
      Pada akhirnya monster itu sudah ada di dalam rumah
    • Setuju, tetapi ini bukan hanya masalah manajer paket
      Bahkan jika URL git ditentukan langsung, hasilnya akan sama
      Pada akhirnya ini adalah masalah struktural dalam pengelolaan dependensi itu sendiri
    • Setiap platform punya terlalu banyak manajer paket
      Terasa perlu ada manajer paket terstandarisasi yang tidak bergantung pada bahasa
      Fitur seperti verifikasi tanda tangan, jaminan asal-usul, dan standardisasi API harus menjadi keharusan
    • Manajer paket sistem seperti apt atau rpm juga tidak sempurna
      Seperti insiden xz, paket yang sudah terinfeksi kadang tetap didistribusikan
      Selain itu, manajer paket sistem lambat dalam mendukung versi terbaru sehingga kurang cocok untuk pengembangan
      Itulah sebabnya alat seperti npm, cargo, dan pip tetap dibutuhkan
    • Ini bukan dependensi yang terinfeksi, melainkan paket berbahaya sejak awal
      Masalahnya bukan pada manajer paketnya, melainkan pada fakta bahwa kodenya memang tidak bisa dipercaya sejak awal
  • Lucu juga bahwa pembuat malware menamai fungsi dengan sangat gamblang seperti exfiltrateCredentials
    Ironisnya, mereka sampai menambahkan deteksi debugger tetapi justru tidak melakukan obfuscation kode

    • Sebenarnya kodenya memang di-obfuscate, dan yang dipublikasikan penulis adalah versi yang sudah dipulihkan untuk demonstrasi
    • Untuk menguji 27 jebakan debugging, mungkin dibutuhkan cakupan pengujian yang lumayan besar
      Kita hidup di zaman ketika pengujian malware pun sudah menjadi salah satu bentuk pengembangan
  • Ungkapan “dependensi yang dipasang pengembang tanpa banyak pikir” terdengar menyeramkan

    • Sebagian besar pengembang memang langsung menjalankan npm install
      Kecuali di organisasi dengan kebijakan keamanan yang ketat, hal ini sulit dicegah secara realistis
      Mungkin pada akhirnya solusinya hanyalah mengurangi penggunaan npm
    • Hal yang sama berlaku untuk image Docker
      Jika ditentukan berdasarkan tag, kapan pun bisa terekspos pada serangan rantai pasok
      Industri ini berjalan di atas kepercayaan buta yang jauh lebih besar daripada yang dibayangkan
      Sistem deployment otomatis bahkan tidak punya waktu untuk “berpikir dua kali”
    • Menakutkan, tetapi bagi kebanyakan pengembang ini memang realitas yang benar
    • Menurut saya ada sedikit hiperbola juga di situ
  • Akan bagus kalau JavaScript juga punya pustaka besar tepercaya seperti Apache Commons
    Pengenalan Apache Commons

    • Namun, sebesar apa pun pustakanya, API WhatsApp kemungkinan tetap tidak akan termasuk di dalamnya
  • Paket lotusbail adalah paket npm berbahaya yang menyamar sebagai WhatsApp Web API
    Paket ini didistribusikan selama 6 bulan dan menjalankan berbagai serangan seperti pencurian kredensial, penyadapan pesan, dan pemasangan backdoor

  • Pengembang yang bergantung pada ekosistem JS secara realistis membutuhkan strategi mitigasi risiko
    Disebutkan cara seperti memanfaatkan Docker atau VM

    • Di tempat kerja sebelumnya saya menangani DevOps dan keamanan
      Semua lingkungan pengembangan dikontainerisasi, dan dependensi dikunci ke versi tetap
      Instalasi global dilarang, pembaruan otomatis dilarang, verifikasi manual diwajibkan
      Untuk proyek sensitif, workstation khusus di-reset secara berkala
      Merepotkan, tetapi itulah keamanan yang realistis
      Atau, bisa juga meninggalkan ekosistem JS
    • Tetapi pada kasus ini, pengguna sengaja memasang paketnya, jadi langkah seperti itu sulit mencegahnya
      Di tingkat OS atau Docker seharusnya ada cara untuk memastikan apakah koneksi jaringan diizinkan
    • Saya memakai Incus OS dan mengembangkan tiap proyek dengan meluncurkan kontainer baru
      Memang berbagi kernel, tetapi itu sudah cukup untuk menahan serangan dari ekosistem JS
      Jika nanti serangan pelarian kontainer muncul di npm, barulah saya akan pindah ke VM
      Awalnya saya mengira ini keamanan yang berlebihan, tetapi sekarang justru cepat dan stabil
    • Kalau paket seperti ini didistribusikan, risikonya menyebar bukan hanya ke pengembang tetapi juga ke semua pengguna
    • Beberapa perusahaan hanya mengizinkan paket npm yang sudah berumur beberapa bulan
      Karena dalam jeda waktu itu, sifat berbahayanya bisa terungkap
  • Paket ini sejak awal sudah merupakan kegagalan keamanan
    Paket ini memakai reimplementasi autentikasi klien alih-alih API resmi, dan rahasia pengguna ditangani pihak ketiga
    Pengguna memang seharusnya lebih berhati-hati, tetapi sulit juga menyalahkan mereka sepenuhnya

    • Faktanya, WhatsApp tidak punya API publik
      Akses API hanya tersedia jika mendaftar ke “WhatsApp Business Platform”
      Kalau ada API sungguhan, kejadian seperti ini mungkin tidak akan terjadi
    • Kalau API resmi kurang fiturnya, reimplementasi itu sendiri bukan masalah
      Tetapi menyerahkan rahasia saat autentikasi kepada pihak ketiga itu berbahaya
      Biasanya orang memasang paket seperti ini untuk mengotomatiskan akun mereka sendiri
  • Belakangan ini makin banyak tulisan blog buatan LLM
    Kualitasnya rendah, tetapi karena biayanya nol, dari sudut pandang pemasar itu efisien
    Penulisan tradisional kini malah terasa seperti warisan lama

    • Lucunya, komentar ini pun terasa seperti ditulis oleh LLM
  • Sepertinya serangan rantai pasok makin meningkat. Bagaimana pengembang harus merespons?

    • Untuk mitigasi, kita harus berhenti memakai paket acak, dan secara fundamental meninggalkan ekosistem seperti npm
    • Paket yang URL server-nya di-obfuscate atau dienkripsi adalah tanda bahaya
      Pola seperti ini perlu dideteksi dengan pemindaian otomatis dan prosedur verifikasinya harus diperketat
    • Kita harus kembali seperti tahun 1999: meninjau dependensi secara langsung dan mem-vendor-nya
    • Sekarang dependensinya terlalu banyak dan tak ada yang benar-benar melihat kodenya
      Kontainerisasi, penguncian dependensi, pemindaian keamanan, dan pembaruan yang ditunda adalah hal wajib
      Instalasi global npm adalah pilihan terburuk
    • Jika memang terpaksa harus dijalankan, maka harus dijalankan di lingkungan yang semaksimal mungkin terisolasi
      Gunakan kontainer seperti rootless podman atau VM untuk meminimalkan risiko