GitLab menemukan serangan rantai pasok NPM berskala luas

 (about.gitlab.com)
1 poin oleh GN⁺ 2025-11-29 | 1 komentar | Bagikan ke WhatsApp
  • Ekosistem npm secara luas sedang disusupi varian malware destruktif, dan tim keamanan GitLab telah mendeteksinya
  • Malware ini merupakan bentuk evolusi dari Shai-Hulud, dengan mekanisme penyebaran seperti worm yang otomatis menginfeksi paket lain milik pengembang yang terinfeksi
  • Setelah mencuri kredensial dari GitHub, AWS, GCP, Azure, dan lainnya, data kemudian diekfiltrasi ke repositori GitHub yang dikendalikan penyerang
  • Tertanam ‘dead man’s switch’ yang segera menghapus data pengguna jika akses ke GitHub dan npm diblokir secara bersamaan
  • GitLab telah memastikan sistem internalnya tidak terinfeksi, serta menyediakan panduan deteksi dan respons melalui Dependency Scanning dan GitLab Duo Chat

Ringkasan serangan

  • Tim Vulnerability Research GitLab mendeteksi serangan rantai pasok berskala besar di ekosistem npm
    • Sistem pemantauan internal menemukan beberapa paket yang terinfeksi
    • Malware tersebut diidentifikasi sebagai varian dari Shai-Hulud
  • Malware menyebar dengan propagasi seperti worm, sehingga otomatis menginfeksi paket lain milik pengembang yang sudah terkompromi
  • GitLab mengonfirmasi bahwa mereka tidak menggunakan paket berbahaya tersebut di lingkungan internalnya dan telah membagikan informasi kepada komunitas keamanan

Struktur internal serangan

  • Paket npm berbahaya yang dideteksi sistem pemantauan internal menjalankan fungsi berikut
    • Mengumpulkan kredensial dari GitHub, npm, AWS, GCP, dan Azure
    • Mengirim data curian ke repositori GitHub yang dikendalikan penyerang
    • Secara otomatis menginfeksi paket lain milik korban
    • Menjalankan payload destruktif jika akses ke infrastruktur diblokir
  • Beberapa paket terinfeksi telah dikonfirmasi, dan investigasi masih berlangsung

Analisis teknis: cara serangan berjalan

Vektor infeksi awal

  • Malware menyusup ke sistem melalui proses pemuatan multistage
    • Skrip setup_bun.js ditambahkan ke package.json dari paket yang terinfeksi
    • Sekilas disamarkan sebagai installer runtime JavaScript Bun
    • Namun pada kenyataannya mengeksekusi bun_environment.js (payload terobfusikasi berukuran 10MB)
    Iklan
  • Terdiri dari file loader kecil dan payload besar yang terobfusikasi untuk menghindari deteksi

Pengumpulan kredensial

  • Segera setelah dijalankan, malware mengumpulkan token dan rahasia dari berbagai sumber
    • Token GitHub(ghp_, gho_)
    • Kredensial AWS, GCP, Azure
    • Token npm (.npmrc dan variabel lingkungan)
    • Menggunakan alat Trufflehog untuk memindai seluruh home directory guna mencari API key, kata sandi, dan riwayat Git

Jaringan eksfiltrasi data

  • Dengan token GitHub yang dicuri, malware membuat repositori publik dengan deskripsi “Sha1-Hulud: The Second Coming.”
    • Repositori tersebut berperan sebagai dropbox data
    • GitHub Actions runner dipasang untuk mempertahankan persistensi
  • Jika izin tidak mencukupi, malware mencari repositori lain dengan penanda yang sama untuk mendaur ulang token dari sistem lain
    • Dengan cara ini terbentuk jaringan berbagi token terdistribusi
    Iklan

Penyebaran melalui rantai pasok

  • Dengan memanfaatkan token npm yang dicuri, malware menginfeksi semua paket milik korban
    1. Mengunduh paket asli
    2. Menyisipkan setup_bun.js sebagai skrip preinstall
    3. Menambahkan payload bun_environment.js
    4. Menaikkan nomor versi
    5. Mempublikasikan ulang paket yang terinfeksi ke npm

Dead man’s switch

  • Malware terus memantau akses ke GitHub (untuk eksfiltrasi data) dan npm (untuk penyebaran)
    • Jika kedua kanal sama-sama diblokir, malware segera menjalankan penghancuran data
  • Windows: menghapus file pengguna dan menimpa sektor disk
  • Keluarga Unix: menimpa file dengan perintah shred lalu menghapusnya
  • Jika terjadi penghapusan massal repositori GitHub atau pencabutan massal token npm, ada risiko sistem yang terinfeksi melakukan penghapusan data secara bersamaan

Indikator kompromi (IoC)

  • Indikator deteksi utama
    • File: bun_environment.js (skrip post-install berbahaya)
    • Direktori: .truffler-cache/, .truffler-cache/extract/
    • Proses: del /F /Q /S "%USERPROFILE%*", shred -uvz -n 1, cipher /W:%USERPROFILE%
    • Perintah: curl -fsSL https://bun.sh/install | bash, powershell -c "irm bun.sh/install.ps1|iex"
    Iklan

Dukungan deteksi dan respons dari GitLab

  • Pengguna GitLab Ultimate dapat segera memeriksa apakah mereka terdampak melalui fitur keamanan bawaan
    • Saat Dependency Scanning diaktifkan, paket terinfeksi dalam package-lock.json atau yarn.lock akan terdeteksi otomatis
    • Jika merge request memuat paket terinfeksi, peringatan akan ditampilkan
  • Dapat dipadukan dengan GitLab Duo Chat untuk deteksi cepat berbasis kueri
    • Contoh: “Apakah ada dependensi yang terdampak kampanye Shai-Hulud v2?”
    • Security Analyst Agent akan memeriksa data kerentanan proyek dan langsung memberikan jawaban
  • Tim yang mengelola banyak repositori disarankan menggabungkan deteksi otomatis berbasis CI/CD dengan respons cepat berbasis agen

Prospek ke depan

  • Serangan ini dinilai sebagai bentuk baru serangan rantai pasok yang menggunakan penghancuran data korban untuk melindungi infrastruktur penyerang
  • GitLab sedang bekerja sama dengan komunitas untuk mengembangkan strategi pemulihan yang aman, sambil terus memantau varian baru melalui sistem deteksi otomatis
  • Tujuannya adalah mencegah kerugian sekunder akibat dead man’s switch melalui berbagi informasi sejak dini

Bacaan terkait

1 komentar

 
GN⁺ 2025-11-29
Komentar Hacker News

  • Sekitar sebulan lalu aku perlu mengerjakan tugas yang merepotkan, jadi aku mencari paket NPM
    Saat menjalankan brew install npm, yang muncul justru air terjun dependensi; aku berhenti sejenak, menimbang risiko dan manfaatnya, lalu akhirnya membatalkannya dengan brew uninstall npm
    Sebagai gantinya, aku menyelesaikannya dengan pipeline utilitas Unix lawas dan awk, dan kalau kupikir-pikir sekarang itu adalah keputusan terbaik

    • Pelajarannya jelas — jangan gunakan teknologi web untuk scripting lokal
      NPM adalah alat yang dibuat untuk mengatasi masalah kompatibilitas browser, jadi di lingkungan tanpa browser ia hanya menambah kompleksitas yang tidak perlu
    • Inilah alasan mengapa containerisasi atau virtualisasi diperlukan
      Jika menjalankan kode dari ekosistem dengan banyak dependensi seperti Node atau Python langsung di sistem utama, risikonya besar untuk terpapar serangan supply chain
      Karena itu aku sama sekali tidak memasang interpreter Python atau JS di sistem utama
    • Dulu aku juga hanya menjalankan npm di dalam container Docker, tapi sering jadi bahan ejekan di forum
      Pada akhirnya aku menyerah, tapi sekarang rasanya pendekatan itu memang benar
    • Aku juga punya pengalaman serupa. Begitu melihat jumlah dependensi yang ingin ditarik oleh artillery, aku langsung mengurungkan niat
    • Ironisnya, para developer selalu bilang “akal sehat adalah keamanan terbaik”, tapi tetap memasang begitu banyak paket yang tidak terverifikasi hanya dengan satu baris perintah

  • Ada yang bilang, “kalau GitHub menghapus massal repositori berbahaya, ribuan sistem bisa sekaligus merusak data pengguna,”
    Rasanya seperti situasi penyanderaan — sampai muncul lelucon “tembak sandera”

    • Tapi sandera (pengguna) sebenarnya masuk ke risiko itu atas kemauan sendiri, jadi pada akhirnya ini konsekuensi dari pilihan mereka sendiri

  • Aku juga korban serangan npm kali ini
    Aku kaget mengetahui bahwa GitHub CLI menyimpan token OAuth dalam teks biasa di direktori HOME
    Jika penyerang bisa mengaksesnya, mereka nyaris bisa melakukan apa saja atas namaku

    • Sebenarnya GitHub CLI hanya menyimpan token dalam teks biasa saat keyring tidak tersedia
      Di macOS, token disimpan dengan aman di keychain OS — diskusi terkait
    • Benar, tapi file cookie browser juga punya masalah serupa
      Chrome memakai perlindungan OS, tetapi Firefox masih belum
      Pada akhirnya kontrol akses berbasis sandbox adalah solusi yang lebih mendasar
    • Semua token seharusnya ada di keychain yang terlindungi
      Tapi belum ada solusi yang konsisten lintas platform, dan bahkan di macOS pun tidak ada cara yang sempurna
    • Aku juga korban. Setelah memasang Backstage, sistemku terinfeksi
      Direktori ~/.dev-env muncul dan laptopku berubah menjadi GitHub runner
      Mungkin kerusakannya berkurang berkat filesystem read-only milik Bluefin Linux

  • Semua orang hanya menyalahkan npm, tapi GitHub juga punya tanggung jawab
    Mereka gagal mendeteksi repositori berbahaya dengan cepat, padahal masalah repositori malware sudah cukup serius

    • Tetap saja, justru karena diunggah ke GitHub, ada orang yang bisa cepat menyadari dampaknya
      Kalau diam-diam dikirim ke server eksternal, situasinya pasti jauh lebih buruk
    • Microsoft tidak mungkin memfilter semuanya
      Yang dibutuhkan adalah alat dan praktik di tingkat komunitas
    • Karena GitHub dimiliki Microsoft, ia juga terhubung dengan repositori paket GoLang
      Jika nanti muncul regulasi komersial atau pembatasan workflow build, dampaknya bisa jadi besar
    • Sulit membantah bahwa kedua perusahaan itu sama-sama punya tingkat keamanan yang biasa-biasa saja
    • Malware ini membuat repositori dengan pola yang sama, jadi seharusnya ia bisa dideteksi bahkan dengan aturan sederhana

  • Aku penasaran kenapa hanya NPM yang jadi sasaran serangan
    Python dan Java juga populer, tapi belakangan relatif sepi

    • NPM memungkinkan eksekusi perintah arbitrer lewat post-install hook, dan
      budaya dependensi dengan rentang versi membuat infeksi menyebar cepat
      Di Java, penguncian ke versi tertentu lebih umum sehingga kejadian seperti ini lebih jarang
    • Node punya standard library yang kecil dan ketergantungan tinggi pada komunitas
      Karena itu satu paket bisa menarik puluhan subdependensi
    • JS adalah bahasa paling populer di GitHub, jadi permukaan serangannya luas, dan
      banyak developer yang pengalamannya masih minim sehingga keamanan lebih lemah
    • Komunitas JS punya semacam “obsesi pada versi terbaru”
      Ekosistem bahasa lain biasanya memperbarui setelah verifikasi, tapi JS sering langsung upgrade
    • NPM punya batas keamanan yang lemah
      Saat instalasi, skrip bisa dijalankan dengan bebas, sementara JVM atau Python tidak seperti itu

  • Dengan menambahkan ke .npmrc

    ignore-scripts=true

    vektor serangan bisa dikurangi
    Tulisan terkait

    • Aku penasaran apakah ada cara untuk memeriksa lebih dulu paket yang punya preinstall/postinstall hook sebelum instalasi
    • Jika “ignore scripts” memang lebih aman, lalu kenapa itu hanya opsi,
      dan apakah menonaktifkannya bisa berisiko merusak dependensi
    • Tapi pada akhirnya, jika menjalankan JS di lingkungan Node, akses ke variabel lingkungan atau file tetap tidak bisa dicegah
    • Atau ya cukup pakai pnpm saja

  • Hal yang paling mengkhawatirkan dari serangan kali ini adalah pencurian kredensial
    Jika memasang paket yang terinfeksi, variabel lingkungan atau token .npmrc bisa saja bocor
    Token dan API key harus segera dirotasi
    Rotasi berkala bukan respons setelah insiden, melainkan langkah pencegahan sebelumnya

    • Jika developer menggunakan ulang kata sandi, itu benar-benar masalah serius
      Kredensial jangan disimpan di variabel lingkungan atau file; gunakan security key atau file terenkripsi
    • Jika belum tahu apakah sistem terinfeksi, urutannya harus deteksi infeksi → pembersihan → rotasi token
    • Serangan ini bukan sekadar infeksi biasa, melainkan menyandera seluruh ekosistem, jadi jauh lebih berbahaya
      Rasanya seperti menyisipkan transaksi berbahaya ke ledger terdistribusi
    • Rahasia wajib disimpan di penyimpanan rahasia (secret locker)
      Masalahnya, masih banyak layanan yang menjadikan penyimpanan teks biasa sebagai default
    • Dan malware ini bahkan mencoba merusak data ketika penyebarannya berhenti

  • Serangan seperti ini terus berulang, jadi aku heran kenapa sistem deteksi berbasis AI tidak bekerja
    Microsoft sering sekali menonjolkan AI, tapi tampaknya itu tidak dipakai untuk keamanan GitHub

    • Tapi ucapan “AI mendeteksi serangan” sekarang sudah jadi klise pemasaran keamanan
      Maknanya memudar seperti dulu saat semua hal yang diblokir firewall disebut serangan
    • Perusahaan kami memakai SonaType Lifecycle, dan katanya itu bisa mencegah serangan seperti ini dengan AI
      Secara internal hal itu didukung oleh SonaType IQ Server
    • “AI” saat ini adalah model generatif, jadi fokusnya lebih pada menghasilkan daripada mengevaluasi
      Bahkan proyek curl pernah mengalami kasus spam laporan keamanan buatan AI

  • Aku penasaran apakah masih ada alasan untuk terus mengizinkan skrip postinstall
    Bukankah lebih baik pengguna ditanya dulu apakah ingin menjalankannya

    • Tapi kebanyakan pengguna akan menekan “ya”, dan
      server CI membutuhkan instalasi non-interaktif, jadi secara realistis itu sulit dilakukan

  • Tulisan itu sangat berwawasan, tapi sayang sekali di bagian akhir malah ditutup dengan promosi fitur keamanan GitLab

    • Mungkin tetap berguna bagi pengguna GitLab
    • Meski begitu, itu tidak mengurangi wawasan dari tulisannya sendiri