Catatan respons menit demi menit terhadap serangan rantai pasok LiteLLM

 (futuresearch.ai)
3 poin oleh GN⁺ 24 hari lalu | 1 komentar | Bagikan ke WhatsApp
  • Jurnal respons menit demi menit yang mendeteksi dan menganalisis secara real-time infeksi paket berbahaya LiteLLM 1.82.8 yang didistribusikan melalui PyPI
  • Infeksi terjadi saat pembaruan otomatis Cursor IDE, ketika file litellm_init.pth dijalankan dan menyebabkan pencurian kredensial serta infeksi sistem
  • Kode berbahaya melakukan aksi majemuk seperti mengumpulkan kunci SSH dan kredensial cloud, mencoba penyebaran ke Kubernetes, serta membuat fork bomb
  • Insiden ini segera dilaporkan ke tim keamanan PyPI dan maintainer LiteLLM, yang berujung pada karantina paket dan pendaftaran CVE
  • Alat analisis kode berbasis AI seperti Claude Code memainkan peran kunci dalam mendeteksi serangan, sekaligus menunjukkan perlunya penguatan keamanan rantai pasok ekosistem AI

Catatan respons terhadap serangan rantai pasok LiteLLM

  • Versi LiteLLM 1.82.8 dipastikan sebagai paket berbahaya yang didistribusikan melalui PyPI, dan dokumen ini merupakan jurnal respons menit demi menit dari deteksi infeksi hingga karantina
  • Infeksi terjadi dalam proses pembaruan otomatis Cursor IDE, dan di antara dependensi yang dipasang melalui Claude Code dan manajer paket uv, file litellm_init.pth dijalankan sehingga menyebabkan infeksi sistem
  • Serangan terdiri dari aksi majemuk yang mencakup pencurian kredensial, pemasangan persistensi sistem, upaya penyebaran ke Kubernetes, dan fork bomb
  • Insiden ini segera dilaporkan ke tim keamanan PyPI dan maintainer LiteLLM, yang berujung pada karantina paket dan penerbitan CVE
  • Alat analisis kode berbasis AI memainkan peran penting dalam deteksi dan analisis perilaku berbahaya secara real-time

Deteksi awal dan tanda-tanda anomali sistem

  • Sekitar 11:13 UTC, lebih dari 11.000 proses Python terbentuk di laptop macOS hingga sistem masuk ke kondisi hang
    • Perintah berbentuk exec(base64.b64decode('...')) dijalankan berulang kali dan memenuhi CPU serta memori
    • Setelah dipaksa berhenti dan reboot, tidak ditemukan jejak terkait persistensi
  • Pada awalnya, insiden ini diduga sebagai loop non-malicious akibat loop internal Claude Code atau error skrip uv run
  • Setelah itu, melalui screenshot htop dan log, dipastikan bahwa skrip Python yang dikodekan dengan base64 dieksekusi berulang kali

Mengungkap penyebab infeksi

  • Sekitar 11:40, file litellm_init.pth ditemukan di dalam tool Python yang terpasang dan dipastikan sebagai komponen berbahaya
    • File .pth berjalan otomatis saat Python dimulai dan aktif di semua proses Python
    • File ini mengumpulkan kunci SSH, kredensial cloud, kata sandi database, variabel lingkungan, dan riwayat shell
    • Data yang dikumpulkan dienkripsi dengan RSA lalu dikirim ke https://models.litellm.cloud/
    • Ia mencoba memasang persistensi di ~/.config/sysmon/sysmon.py, tetapi terhenti karena reboot paksa
  • Infeksi terjadi saat pembaruan otomatis Cursor IDE (10:58 UTC)
    • Ekstensi futuresearch-mcp-legacy mengunduh litellm 1.82.8 melalui uvx
    • Versi tersebut hanya ada di PyPI dan tidak memiliki tag rilis GitHub
    • Waktu unggah ke PyPI adalah 10:52 UTC, sehingga dipastikan didistribusikan tepat sebelum infeksi

Struktur kode berbahaya

  • Tahap 1 (litellm_init.pth): berjalan otomatis saat Python dimulai, lalu mendekode dan mengeksekusi payload yang dikodekan dengan base64
  • Tahap 2: berisi kunci publik RSA untuk mengenkripsi data hasil pencurian
  • Tahap 3 (B64_SCRIPT): melakukan pengumpulan dan pengiriman kredensial yang sebenarnya
  • Pemasangan persistensi: mencoba mendaftarkan sysmon.py sebagai layanan systemd
  • Kode penyebaran Kubernetes: mencoba membuat pod privileged di tiap node dengan image alpine:latest
  • Penyebab fork bomb: panggilan subprocess.Popen([sys.executable, "-c", ...]) mengeksekusi ulang .pth di proses anak juga, sehingga memicu loop tak terbatas

Cakupan dampak dan langkah respons

  • Kredensial yang terekspos

    • Kunci SSH, kredensial GCloud dan Kubernetes, API key dalam file .env, serta kata sandi Supabase, ClickHouse, dan Grafana
    • Tindakan segera yang direkomendasikan
    1. Rotasi semua kredensial SSH dan cloud
    2. Terbitkan ulang secret key di .env dan .mcp.json
    3. Hapus cache ~/.cache/uv
    4. Laporkan ke tim keamanan PyPI (security@pypi.org) dan maintainer LiteLLM

  • Hasil pemeriksaan cluster Kubernetes

    • Pod berbahaya (node-setup-*, sysmon) tidak ditemukan
    • Karena berjalan di lingkungan macOS, upaya penyebaran di dalam cluster gagal
    • Namun, karena ada kemungkinan ~/.kube/config terekspos, rotasi kredensial tetap diperlukan

Respons PyPI dan pengungkapan publik

  • Pada 11:58 UTC, setelah mengunduh litellm 1.82.8 dari PyPI di lingkungan Docker yang terisolasi, keberadaan file .pth berbahaya dikonfirmasi kembali
  • Insiden ini segera dilaporkan ke tim keamanan PyPI dan repositori BerriAI/litellm
    • Setelah itu, insiden didaftarkan sebagai PYSEC-2026-2 (CVE)
  • Pada 12:01 UTC, posting publik tentang serangan rantai pasok ditulis dan dipublikasikan di blog FutureSearch
    • Penulisan dan merge PR selesai dalam 3 menit
  • Pada 12:04 UTC, usulan pembagian informasi disebarkan ke komunitas r/Python, r/netsec, r/LocalLLaMA, r/MachineLearning, dan r/devops
    • Langkah ini mendorong respons cepat dari komunitas Python dan keamanan

Makna insiden ini

  • Alat analisis kode berbasis AI Claude Code mengidentifikasi perilaku berbahaya secara real-time dan menghasilkan peringatan sebelum intervensi peneliti keamanan
  • Ini adalah contoh serangan rantai pasok yang secara langsung menargetkan ekosistem developer AI, dan menyoroti perlunya penguatan keamanan akun PyPI serta verifikasi pembaruan otomatis
  • Kasus ini menunjukkan bahwa alat AI dapat digunakan bukan hanya untuk membantu pengembangan, tetapi juga untuk otomatisasi deteksi dan respons terhadap ancaman siber

Bacaan terkait

1 komentar

 
GN⁺ 24 hari lalu
Komentar Hacker News

  • Saya adalah pengembang yang pertama kali menemukan dan melaporkan kerentanan litellm
    Saya membagikan transkrip analisis waktu nyata yang mencatat situasinya apa adanya
    Claude memandu langkah demi langkah tentang siapa yang harus dihubungi dan urutan tindakan yang perlu diambil, jadi ini terasa sebagai pengalaman yang sangat membantu bahkan bagi orang yang bukan pakar keamanan
    Saya penasaran apakah orang nonspesialis menemukan dan melaporkan kerentanan seperti ini membantu komunitas keamanan, atau justru menambah kebingungan

    • Sebagai orang yang bekerja di industri keamanan, saya terkesan karena ini ditemukan dengan bantuan Claude
      Namun, bagian “paket berbahaya langsung berjalan begitu Cursor dibuka lagi” tampak agak berisiko
      Begitu timbul kecurigaan, mengisolasi perangkat dan menghubungi tim keamanan seharusnya menjadi prioritas pertama
    • Saya juga menemukan masalah ini hampir pada waktu yang sama, dengan cara yang sama
      Jika file .pth itu tidak bertindak seperti fork bomb, mungkin penemuannya akan jauh lebih terlambat
      Menanyakan jalur kontak kepada Claude adalah keputusan yang bagus
      Karena saya tidak tahu kontak terkait PyPI, saya mengirim email ke maintainer dan juga mempostingnya di Hacker News
      Saya pikir meskipun bukan bagian dari komunitas keamanan, siapa pun harus bisa melaporkan kerentanan serius seperti ini
    • Saya punya pengalaman mengelola program pengungkapan kerentanan di beberapa perusahaan
      Sebagian besar masalah datang dari orang-orang yang mengejar uang dan mengklaim apa saja sebagai kerentanan
      Tetapi laporan Anda berkualitas tinggi, dan kasus seperti ini akan langsung dinaikkan ke prioritas patch
      Jika bisa diselesaikan tanpa mengganggu bisnis, saya akan segera menanganinya, dan jika serius, saya akan langsung melapor ke CISO atau CTO
    • Tulisan yang bagus. Saya merasa Claude sangat berguna dalam situasi seperti ini
      Berkat laporan Anda, insiden yang lebih besar berhasil dicegah
      Kami juga merangkum hal terkait ini dalam dua posting blog
      Tulisan blog grith.ai
    • Belakangan saya mendengar proyek open source sedang kesulitan karena banjir laporan kerentanan dan PR
      Tetapi saya rasa kasus ini adalah contoh bagus bagaimana bantuan AI membuat analisis akar masalah dan pelaporan jadi jauh lebih cepat

  • Ini pertama kalinya saya melihat tool claude-code-transcripts saya di-embed sebagai data dalam sebuah posting blog
    Biasanya saya membagikannya lewat halaman HTML Gist, jadi penggunaan seperti ini menarik

    • Di perusahaan kami juga dipakai secara aktif
      Kami gagal menyesuaikannya dengan gaya blog, tetapi itu malah mengingatkan saya lagi betapa pentingnya pengalaman dasar
      Claude seperti memindai seluruh komputer saya saat mengais log, jadi saya merasa sistem penyuntingan log otomatis memang dibutuhkan
    • Berbagi informasi antar sesi Claude Code masih menjadi masalah besar
      Ini sangat tidak nyaman terutama saat debugging darurat sambil berkolaborasi dengan tim

  • Permintaan seperti “bisakah isi skrip berbahaya ditampilkan tanpa menjalankannya?” itu berbahaya
    Karena agen LLM tidak punya konsep tanggung jawab, jika tanpa sengaja diberi perintah eksekusi, bisa berujung pada insiden besar
    Saat mengambil file dari PyPI, itu harus dilakukan di lingkungan sandbox

    • Saya juga khawatir soal itu
      Kalau dibilang “jangan lakukan”, justru ada kecenderungan makin terpaku pada hal itu

  • Saya dengar PyPI mendukung digital attestation, jadi saya penasaran apakah paket ini ditandatangani
    Dokumentasi PyPI Trusted Publishers

  • Saya rasa registry paket seperti GitHub, npm, dan PyPI harus menyediakan event stream (firehose) untuk analisis keamanan waktu nyata
    Serangan seperti ini mestinya bisa langsung tertangkap oleh pemindai otomatis

    • PyPI sebenarnya sudah menyediakan fitur seperti itu
      Mitra keamanan dapat memindai paket, lalu melaporkannya melalui API berbasis undangan
      Lihat posting blog PyPI
    • Setelah insiden ini, saya juga menerapkan dependency cooldown
      Tulisan terkait
      Tujuannya memberi waktu bagi pemindai otomatis untuk mendeteksi tanda-tanda aneh seperti file .pth
    • npm menyediakan feed perubahan paket, dan GitHub mengoperasikan firehose event serta dataset publik BigQuery
    • Saya rasa penyediaan infrastruktur seperti ini harus dijadikan kewajiban hukum
      Kerugian ekonominya bisa terlalu besar, dan korban infeksi litellm saja sudah lebih dari 47 ribu orang

  • Bagian “dari menulis posting blog, PR, sampai merge dalam waktu kurang dari 3 menit” adalah yang paling mengejutkan
    Kecepatannya lebih cepat dari waktu membaca, jadi terasa mengkhawatirkan

  • Kalau tidak ada fork bomb 11 ribu proses, serangan ini mungkin akan tersembunyi jauh lebih lama

    • Saya juga sempat menginstal paket itu dan sistem langsung macet, jadi saya terhindar dari infeksi
      Jika kecepatan bomnya diturunkan, dampaknya pasti akan jauh lebih besar
    • Mungkin ini sudah pantas disebut internet worm generasi sekarang

  • Ada dua cara perusahaan besar menjalankan kode open source yang tidak tepercaya

    1. Seperti Google, membangun semuanya langsung dari source
    2. Hanya mengambil dari mirror internal perusahaan, dan memverifikasi tanda tangan semua paket
      Secara realistis, (1) adalah yang paling aman
      Untuk UKM atau individu, dependency pinning dan waktu tunggu yang cukup adalah pertahanan terbaik
      Dengan Bazel, pendekatan (1) bisa ditiru sampai batas tertentu, tetapi kebanyakan orang tetap harus bergantung pada source eksternal

  • PyPI mengarantina paket itu hanya 30 menit setelah laporan masuk, itu benar-benar respons yang cepat

    • Memang banyak kekhawatiran bahwa mereka rentan terhadap serangan rantai pasok, tetapi kali ini saya rasa ini contoh penanganan yang cukup baik

  • Salah satu hal terbaik dari AI/LLM adalah demokratisasi reverse engineering
    Dulu ini keterampilan yang sulit dipelajari dan kurang memberi imbalan, tetapi sekarang AI bisa membantu menunjukkan arah

    • Namun kasus ini bukan reverse engineering, melainkan masalah administrasi sistem dasar
      Pola exec(base64.b64decode(...)) memang sering dipakai tool Python untuk menyampaikan kode, tetapi
      pada dasarnya kode yang berjalan dari /tmp, /var/tmp, atau /dev/shm harus dipandang sangat mencurigakan
      Jika ada tool pemantauan jaringan seperti Lulu atau LittleSnitch, trafik aneh itu mungkin bisa diblokir
      Hanya saja, mengunggah biner ke Claude untuk dianalisis juga merupakan risiko lain
    • Saya juga tertarik setelah menonton video CTF, tetapi dalam pekerjaan nyata, hampir tidak pernah menghadapi hal seperti ini secara langsung