Insiden kompromi paket PyPI LiteLLM 1.82.7 dan 1.82.8

 (github.com/BerriAI)
2 poin oleh GN⁺ 27 hari lalu | 1 komentar | Bagikan ke WhatsApp
  • Dua versi paket PyPI dari pustaka integrasi LLM yang banyak digunakan, LiteLLM (1.82.7, 1.82.8), didistribusikan dengan payload berbahaya yang disisipkan, dan saat dipasang memicu serangan pencurian kredensial sistem
  • Penyebab serangan berasal dari kompromi rantai pasok pada alat pemindaian keamanan CI/CD Trivy, yang membocorkan kredensial CircleCI sehingga token publikasi PyPI dan GitHub PAT ikut dicuri
  • Pengguna image Docker Proxy resmi LiteLLM tidak terdampak karena versi dipatok di requirements.txt, tetapi lingkungan yang melakukan pip install langsung dari PyPI perlu segera diperiksa
  • Thread issue GitHub dibanjiri ratusan komentar spam bot yang mengganggu diskusi nyata, dan ini dikonfirmasi sebagai upaya penyerang untuk sengaja mengacaukan komunikasi respons
  • Banyak proyek yang menggunakan LiteLLM sebagai dependensi, seperti DSPy dan CrewAI, juga terdampak, kembali menyoroti kerentanan mendasar keamanan rantai pasok perangkat lunak

Ringkasan insiden dan kronologi penemuan

  • Saat menyiapkan proyek baru, sistem berjalan tidak normal dengan RAM terkuras dan proses berbentuk fork bomb dieksekusi
  • Hasil investigasi menunjukkan proxy_server.py telah ditambahi blob berbahaya yang dienkode base64, lalu didekode untuk membuat file terpisah dan dieksekusi
  • Versi 1.82.7 memuat payload di litellm/proxy/proxy_server.py dan berjalan saat import litellm.proxy
  • Versi 1.82.8 juga menyertakan file litellm_init.pth, sehingga hanya dengan paket terpasang, malware otomatis berjalan saat Python dimulai
    • File .pth adalah mekanisme yang dijalankan otomatis oleh modul site Python saat startup, dan memungkinkan eksekusi kode arbitrer setelah kata kunci import
    • Mekanisme ini telah ada sejak Python 2.1 dan diperkenalkan tanpa PEP terpisah
  • Tim FutureSearch melaporkan korban pertama: uvx secara otomatis memasang litellm terbaru (tanpa versi dipatok), lalu Cursor memuat server MCP lokal secara otomatis dan infeksi pun terjadi

Jalur serangan dan keterkaitan TeamPCP

  • Serangan ini dipastikan dilakukan oleh pelaku yang sama dengan grup TeamPCP yang baru-baru ini membobol Trivy
  • Jalur kompromi: pembobolan Trivy → kebocoran penuh kredensial CircleCI → pencurian token publikasi PyPI + GitHub PAT → distribusi paket berbahaya
  • Akun GitHub CEO/CTO LiteLLM juga sepenuhnya dibajak; deskripsi repositori pribadi diubah menjadi "teampcp owns BerriAI" dan issue ditutup, di antara aksi lainnya
  • Token PYPI_PUBLISH disimpan sebagai variabel lingkungan pada proyek GitHub, dan bocor melalui Trivy
    • Akun memang telah memakai 2FA, tetapi pencurian token membuat proteksi itu dapat dilewati
  • Penyerang memposting kalimat yang sama berulang kali di issue GitHub menggunakan ratusan akun bot, sehingga diskusi nyata terganggu
    • Di repositori Trivy juga ditemukan pola yang sama dengan lebih dari 700 komentar spam
    • Sebagian akun spam adalah pengguna GitHub yang punya riwayat kontribusi nyata; sejak Februari terdeteksi commit "Update workflow configuration" yang menyisipkan pencuri kredensial ke workflow CI
  • Kompromi Trivy terjadi setidaknya 5 hari sebelumnya, dan pengumuman serangan terbaru baru keluar sehari sebelumnya, sehingga maintainer kemungkinan terdampak sebelum sempat menyadarinya
  • Penyerang juga memakai Internet Computer Protocol(ICP) Canisters untuk pengiriman payload, sehingga pemblokiran DNS saja tidak cukup sebagai pertahanan

Cara kerja payload berbahaya

  • Membuat proses Python di latar belakang lalu mendekode dan menjalankan stage yang disematkan
  • Menjalankan pengumpul kredensial; bila pengumpulan data berhasil, kunci AES dienkripsi dengan RSA public key milik penyerang dan data curian dikirim ke host jarak jauh
  • URL yang ditemukan di malware: checkmarx.zone/raw dan models.litellm.cloud
  • Target utama pencurian adalah kunci SSH di ~/.git-credentials dan informasi dompet kripto
  • Karena menjalankan pekerjaan intensif CPU, sistem justru menjadi sangat terbebani sehingga lebih mudah terdeteksi; ada juga laporan anomali diketahui dari suara kipas
  • Gejala serupa juga muncul saat memasang Harbor: proses grep -r rpcuser\rpcpassword berjalan seperti fork bomb untuk mencoba mencari dompet kripto

Respons tim LiteLLM

  • Versi terdampak (v1.82.7, v1.82.8) telah dihapus dari PyPI
  • Kata sandi semua akun maintainer diganti, dan semua kunci GitHub/Docker/CircleCI/pip dihapus serta diganti
  • Akun maintainer baru diganti menjadi @krrish-berri-2 dan @ishaan-berri
  • Seluruh paket sempat dikarantina sementara di PyPI, lalu dibuka kembali setelah versi terinfeksi dihapus
  • Semua rilis baru dihentikan dan distribusi dibekukan sampai review penuh atas rantai pasok selesai
  • Investigasi dan pemulihan dilakukan bersama tim keamanan Mandiant dari Google
  • Trivy dipatok ke versi aman terakhir, v0.35.0 (diubah dari pematokan awal v0.69.3 setelah menerima masukan komunitas)
  • Ke depan dipertimbangkan penguatan keamanan seperti migrasi ke Trusted Publishing (OIDC berbasis token JWT) dan penggunaan akun PyPI terpisah
  • Waktu publikasi pertama versi berbahaya sekitar UTC 8:30, dan karantina PyPI dilakukan sekitar UTC 11:25

Cakupan dampak dan proyek downstream

  • LiteLLM adalah satu-satunya pustaka pemanggil provider LLM di DSPy, dan juga dipakai sebagai fallback oleh CrewAI
  • Airflow, Dagster, Unsloth.ai, Polar, nanobot dan lainnya juga bergantung pada LiteLLM
  • Berdasarkan pencarian GitHub, ada lebih dari 628 proyek yang mencantumkan LiteLLM di requirements.txt tanpa mematok versi
  • Pengguna jalur distribusi Docker Proxy resmi tidak terdampak karena requirements.txt mereka mematok versi
  • Pada distribusi Docker, akses ke filesystem host dan variabel lingkungan relatif lebih terbatas sehingga lebih aman, tetapi kredensial yang di-mount tetap berisiko
    • Sasaran utama penyerang adalah kunci SSH pribadi; akses ke kunci LLM bersifat sekunder
  • Pengguna alat yang secara otomatis memasang LiteLLM sebagai dependensi, seperti Harbor dan browser-use, juga melaporkan dampak tidak langsung
  • CrewAI telah mematok litellm ke 1.82.6 (versi aman terakhir), tetapi pesan commit tidak menyebut insiden kompromi
  • DSPy sedang merespons dengan membuat issue secara terbuka
  • LangChain memiliki lapisan pemanggil provider LLM sendiri, sehingga tidak terdampak langsung oleh kompromi rantai pasok ini (kecuali bila memakai paket opsional langchain-litellm)

Diskusi komunitas: keamanan rantai pasok dan sandboxing

  • Dependensi dan lingkungan pengembangan tidak bisa lagi dipercaya sepenuhnya, sehingga diperlukan defense in depth seperti isolasi VM + primitive container + allowlist + filter egress + seccomp + gVisor
  • Situasi ini dipandang sebagai kembalinya kompromi demi kemudahan keamanan selama 50 tahun terakhir, dan menuntut desain ulang model keamanan secara menyeluruh
  • Ada pendapat bahwa sandboxing perlu hadir di level bahasa pemrograman per modul
    • Java pernah memiliki kemampuan ini sejak v1.2 pada 1990-an, tetapi akhirnya ditinggalkan karena masalah kegunaan
    • Ada pula pandangan bahwa sekarang saatnya mengembangkan bahasa berbasis capability
    • Runtime workerd milik Cloudflare disebut sebagai solusi yang sudah ada untuk isolasi modul
  • Di level OS, alat isolasi seperti pledge/unveil milik OpenBSD, chroot/namespace/cgroup di Linux, dan Capsicum di FreeBSD sudah tersedia
  • Guix dapat membuat container terisolasi dalam hitungan detik sehingga dependensi bisa dipasang tanpa mengakses $HOME
  • Alat isolasi user space seperti Firejail dan bwrap perlu dimanfaatkan lebih aktif
  • Sandboxing + model izin (Intents) pada aplikasi mobile sebenarnya sudah ada, tetapi lingkungan desktop cenderung menolak pembatasan komputasi umum
    • Sebagai tanggapan, dikatakan bahwa sifat tertutup app store milik Apple/Meta dan sandboxing keamanan adalah dua isu yang berbeda; alat masih bisa dibangun untuk menjaga kontrol di tangan pengguna sambil tetap aman
  • Alat canary/honeypot untuk macOS juga diperkenalkan (github.com/dweinstein/canary): memasang secret palsu ke WebDAV/NFS untuk mendeteksi akses abnormal
  • Ada pendapat bahwa harus ada tembok antara penerbitan paket dan repositori publik: menjadikan repositori publik langsung sebagai Trusted Publisher memperluas permukaan serangan
    • Argumen tandingnya, tujuan awal Trusted Publishing adalah menyediakan keterkaitan yang bisa diaudit antara source dan artefak publikasi, sehingga lewat repositori privat justru langkah mundur

Rekomendasi keamanan praktis

  • Dependensi wajib dipatok versinya bersama checksum SHA256
  • Jalankan mirror paket internal agar tidak langsung memakai versi terbaru
  • Gunakan artefak build dan hindari bergantung pada instalasi spontan saat deploy seperti uv run
    • Ini juga menghilangkan risiko struktural ketika PyPI mengalami gangguan dan sistem berhenti
    • Keunggulan artefak yang siap deploy: mudah diaudit, rollback lebih cepat, dan endpoint jaringan keluar yang berisiko dapat diblokir
  • Dengan pengaturan exclude-newer milik uv, paket baru dalam periode tertentu bisa dikecualikan
    • Di pyproject.toml bisa disetel [tool.uv] exclude-newer = "5 days"
  • Dalam CI/CD, solusi mendasar untuk token publikasi adalah berpindah ke workflow berbasis OIDC agar token permanen dihapus
    • GitHub dan PyPI sama-sama mendukung OIDC: bila hanya pekerjaan publish yang diberi izin mengakses endpoint OIDC, maka pekerjaan Trivy tidak punya token yang bisa dicuri
  • Alat pemindaian keamanan seperti Trivy harus dijalankan di worker terpisah tanpa hak publikasi
  • Pengelolaan lockfile dan pembaruan mingguan disarankan agar tidak langsung mengadopsi versi terbaru
  • File .pth Python dapat mengeksekusi kode otomatis; opsi -S bisa menonaktifkan import site, tetapi ada masalah kompatibilitas
  • Disarankan melakukan pemindaian seluruh dependensi proyek dengan alat seperti osv-scanner
  • Perintah untuk memeriksa infeksi:
    • find / -name "litellm_init.pth" -type f 2>/dev/null
    • find / -path '*/litellm-1.82.*.dist-info/METADATA' -exec grep -l 'Version: 1.82.[78]' {} \; 2>/dev/null
  • Muncul juga seruan agar dilakukan rotasi kredensial massal di seluruh ekosistem package manager

Audit SOC2 dan masalah keandalan

  • Disorot bahwa vendor audit SOC2 LiteLLM adalah Delve, yang belakangan menjadi kontroversial
  • SOC2 hanya memeriksa apakah "proses yang terdokumentasi benar-benar dijalankan", dan tidak menjamin tingkat keamanan itu sendiri
  • Bahkan SOC2 yang dijalankan dengan baik pun belum tentu bisa mencegah serangan rantai pasok seperti ini

Proyek alternatif LiteLLM

  • Bifrost (github.com/maximhq/bifrost): alternatif berbasis Rust, memungkinkan pengaturan virtual key bahkan di instance open source gratis
  • Portkey (portkey.ai): layanan proxy, menyediakan paket gratis, dinilai lebih cepat daripada LiteLLM
  • pydantic-ai: alternatif berbasis Python
  • any-llm (github.com/mozilla-ai/any-llm): proyek Mozilla
  • LLM Gateway (llmgateway.io): menyediakan panduan migrasi dari LiteLLM
  • InferXgate (github.com/jasmedia/InferXgate): proyek baru dengan dukungan provider yang masih terbatas
  • Sebagian pengembang berpendapat bahwa API provider LLM pada praktiknya hanya OpenAI dan Anthropic, sehingga memanggil langsung via requests.post() lebih aman
    • Sebagai bantahan, API kompatibel OpenAI dari Anthropic tidak direkomendasikan sebagai solusi jangka panjang/produksi, dan API native tiap vendor punya fitur unik yang tidak bisa dipetakan ke API OpenAI

Bacaan terkait

1 komentar

 
GN⁺ 27 hari lalu
Komentar Hacker News

  • Saya adalah maintainer LiteLLM. Situasi saat ini masih diselidiki, tetapi sejauh ini yang diketahui adalah sebagai berikut

    1. Masalahnya tampaknya berasal dari trivy yang digunakan di CI/CD (tautan pencarian terkait, tulisan analisis)
    2. Jika menggunakan proxy docker, tidak terdampak. Karena versinya dipatok di requirements.txt
    3. Paket terkait telah dikarantina di PyPI sehingga unduhannya diblokir
      Saat ini kami sedang meninjau analisis akar penyebab dan langkah penguatan keamanan, dan mohon maaf atas ketidaknyamanan ini
    • Versi yang terdampak (v1.82.7, v1.82.8) telah dihapus dari PyPI. Semua akun maintainer dan key (GitHub, Docker, CircleCI, pip) telah diganti. Kami masih memindai seluruh proyek, dan bantuan dari pakar keamanan sangat kami sambut (kontak: krrish@berri.ai)
    • Seseorang mengatakan akun GitHub pribadi saya juga tampaknya telah dikompromikan. Katanya ada jejak terkait di hasil pencarian
    • Terima kasih sudah mengatakan bahwa ungkapan “maaf” saya terasa manusiawi. Umpan balik bahwa respons yang tulus lebih baik daripada permintaan maaf formal memberi saya semangat
    • Ada pertanyaan mengapa rotasi kredensial tidak segera dilakukan. Sepertinya saya perlu menjelaskan mengapa hal itu tidak disadari dalam waktu singkat
    • Seseorang membuat dan membagikan skrip sederhana untuk mencari versi litellm yang terpasang di sistemnya (tautan skrip). Katanya memang tidak sempurna, tetapi bisa dengan cepat memindai conda, .venv, uv, dan lingkungan sistem

  • Kita masih belum bisa mempercayai dependensi dan lingkungan pengembangan. Dev container kurang terisolasi dan kegunaannya juga terbatas. Sekarang saatnya beralih ke lingkungan pengembangan berbasis sandbox. Diperlukan lingkungan dengan isolasi setingkat VM, filter egress, seccomp, dan lapisan pertahanan seperti gVisor. Dalam lingkungan seperti ini, meskipun terjadi kompromi, container bisa langsung dihentikan dan masalahnya mudah diidentifikasi

    • Sepertinya kebiasaan jalan pintas keamanan selama 50 tahun terakhir akhirnya berbalik menghantam kita. Budaya pengembangan berbasis kepercayaan kini mulai berakhir. Bukan cuma sandboxing sederhana, kita perlu mendesain ulang model keamanan itu sendiri
    • Sekarang ungkapan “seperti dulu” sudah tidak berlaku. Keamanan yang dapat diverifikasi secara kriptografis adalah keharusan. Kita perlu bergerak ke arah seperti DISA STIG milik Red Hat yang melarang penggunaan repositori eksternal
    • Meminta pendapat tentang proyek saya yang memisahkan kredensial dari container (tightbeam, airlock)
    • Saya sedang mengembangkan proyek open source bernama smolvm (tautan). Ini adalah teknologi yang menggabungkan isolasi setingkat VM dengan dukungan container, dengan tujuan deployment per virtual machine yang sepenuhnya utuh. Saya sedang mencari orang untuk berkolaborasi
    • Muncul pertanyaan apakah benar ada kasus pelarian dari dev container dalam serangan rantai pasok belakangan ini

  • Memperkenalkan alat canary untuk macOS yang saya buat (tautan). Ini adalah biner Go sederhana yang mendeteksi file yang tidak seharusnya diakses oleh paket. Ia mengekspos rahasia palsu melalui WebDAV atau NFS, lalu mengirim notifikasi saat ada akses. Dengan pendekatan honeypot, perilaku aneh bisa dideteksi

  • Ini terkait insiden yang berhubungan dengan aktivitas TeamPCP dalam beberapa minggu terakhir. Linimasa yang saya susun sepertinya akan membantu

    • Ada umpan balik bahwa rangkumannya sangat bagus. Meski begitu, ada juga candaan bahwa “playlist”-nya yang paling berkesan
    • Ada tanggapan bahwa nama TeamPCP sudah pernah terlihat di berbagai tempat, tetapi ini pertama kalinya semuanya dirangkum dengan jelas dalam satu tampilan
    • Ada pertanyaan bagaimana bisa menjaga pembaruan seperti ini tetap secepat itu

  • Ada kritik bahwa sistem deteksi spam GitHub terlalu lemah. Katanya ada lebih dari 170 komentar spam di issue litellm

    • Hal yang sama juga terjadi beberapa hari lalu di repositori trivy. Setelah diskusi soal peretasan ditutup, lebih dari 700 komentar spam bermunculan. Beberapa di antaranya berasal dari akun yang punya riwayat aktivitas nyata. Tampaknya serangan pencurian kredensial telah menyebar luas. Pada banyak akun ada jejak commit credential stealer di CI dengan pesan “Update workflow configuration” pada bulan Februari
    • Ada keluhan bahwa untuk melaporkan spam di GitHub harus melalui banyak langkah sehingga tidak efisien
    • Disebut juga bahwa sebagian mungkin hanya akun bot biasa

  • Saya sudah menduga hal seperti ini akan terjadi suatu hari nanti. Saya mencoba bertahan dengan mematok versi dependensi, tetapi itu pun tidak sempurna. Karena kompleksitas rantai pasok open source, mustahil memverifikasi semua kode. Berkat LLM, risiko penyebaran malware dalam skala besar meningkat 100 kali lipat

    • Ada pendapat bahwa ekosistem Rust sulit diverifikasi karena pohon dependensinya terlalu dalam. Rust, Node, dan Python sama-sama menghadapi masalah serupa. Sebaliknya, C/C++ relatif lebih aman karena menggunakan system package manager sehingga biaya menambah dependensi lebih tinggi

  • Jika kode yang ditulis AI berhasil menyusup ke LLVM atau Linux, kita benar-benar akan menghadapi masalah “trusting trust”

    • Masalah “Trusting Trust” sebenarnya sudah pernah diajukan solusinya melalui pendekatan Diverse Double-Compiling. Tetapi serangan rantai pasok tetap merupakan tantangan yang sulit. AI hanyalah alat untuk memperbesar skala serangan
    • Sekarang semuanya terasa mengkhawatirkan. Mungkin hanya lingkungan airgap yang aman. Tetapi sebagian besar data ada di cloud, dan kita bahkan tidak mengendalikan cadangannya
    • Ada upaya untuk membuat perangkat lunak yang sepenuhnya dapat diverifikasi melalui rantai build deterministik. Sebanyak 93% paket Debian memiliki build yang reproducible. Namun masih banyak pengembang yang santai menjalankan “curl | bash”. Insiden backdoor XZ adalah contoh yang menyadarkan kita akan kenyataan ini
    • Ada juga pendapat bahwa satu-satunya pertahanan adalah sering mengubah API internal agar LLM tidak bisa mempelajari kode kernel
    • Jika serangan seperti ini menjadi nyata, server pemerintah atau infrastruktur cloud bisa mengalami kerusakan besar-besaran. Terutama jika digabungkan dengan peretasan tingkat negara, skala kerugiannya bisa mencapai triliunan dolar. Meski begitu, saya pikir Linux relatif lebih aman

  • Disebutkan bahwa lembaga audit SOC2 LiteLLM adalah Delve.

    • Tetapi ada keraguan apakah sertifikasi SOC2 bisa mencegah serangan seperti ini. Dibagikan juga pengalaman bahwa SOC2 pada praktiknya tidak menjadi perisai yang sepenuhnya andal

  • Setelah memasang Harbor, CPU melonjak ke 100% dan sistem macet. Proses grep -r rpcuser\rpcpassword tampaknya mencoba mencari dompet kripto. Untungnya backdoor tidak terpasang

    • Ada orang yang mengatakan mengalami hal serupa di browser-use. litellm terpasang sebagai dependensi dan sistemnya macet. Dia sudah menonaktifkan token GitHub dan HuggingFace, tetapi bertanya apakah perlu memasang ulang OS
    • Ada pertanyaan, “bagaimana Anda bisa memeriksa prosesnya secepat itu?” Katanya penasaran apakah Activity Monitor selalu dibiarkan terbuka
    • Muncul juga pertanyaan “apa itu Harness”

  • Insiden kali ini tampaknya ulah kelompok penyerang yang sama, yaitu TeamPCP yang meretas Trivy. Membanjirnya issue dengan komentar bot juga menunjukkan pola yang sama. Sangat mungkin ini adalah serangan otomatis dengan memanfaatkan LLM

    • Ada pertanyaan mengapa penyerang membanjiri issue dengan komentar bot. Kemungkinan tujuannya adalah menimbulkan kekacauan dan memperlambat respons