Malware bertema Shai-Hulud ditemukan di pustaka pelatihan AI PyTorch Lightning

• Versi 2.6.2 dan 2.6.3 dari framework deep learning lightning disalahgunakan dalam serangan rantai pasok — cukup menjalankan pip install lightning, payload JavaScript terobfusikasi di direktori _runtime yang tersembunyi akan dieksekusi otomatis
• Karena framework ini banyak dipakai untuk membangun pengklasifikasi gambar, fine-tuning LLM, model difusi, prediksi deret waktu, dan lain-lain, besar kemungkinan framework ini sudah termasuk dalam dependency tree banyak tim AI/ML
• Saat malware berjalan, ia memindai lebih dari 80 path di filesystem lokal untuk mencuri token GitHub (ghp_, gho_), token npm (npm_), environment variable, dan secret cloud, dengan pemrosesan hingga 5MB per file
• Untuk AWS (file kredensial, IMDSv2, ECS, Secrets Manager, SSM), Azure (Key Vault), dan GCP (Secret Manager), malware ini mengenumerasi dan mengambil secret di ketiga penyedia cloud utama
• Di lingkungan GitHub Actions, malware ini memakai Python bawaan untuk membuang memori proses Runner.Worker lalu mengekstrak semua secret yang ditandai "isSecret":true beserta informasi repositori dan workflow
• Titik masuknya adalah PyPI (Python), tetapi penyebaran worm meluas melalui npm (JavaScript) — dengan token npm yang dicuri, malware menyuntikkan dropper (setup.mjs) dan malware (router_runtime.js) ke semua paket yang dapat dipublikasikan, menaikkan patch version lalu menerbitkannya ulang, sehingga memicu infeksi berantai hingga ke mesin pengembang turunan yang memasang paket tersebut
• Eksfiltrasi data menggunakan 4 kanal paralel sekaligus agar tidak bisa dihentikan hanya dengan memblokir satu jalur: ① kirim ke server C2 via HTTPS POST, ② dead drop memakai GitHub Commit Search API (token yang dienkode Base64 ganda dimasukkan ke pesan commit), ③ commit sebagai results-<timestamp>.json ke repositori GitHub publik bernama dari semesta Dune, ④ push langsung ke repositori korban
• Setelah menyusup ke repositori, malware ini menanam hook persistensi pada alat pengembang untuk memastikan reinfeksi — menulis hook SessionStart ke .claude/settings.json milik Claude Code agar berjalan otomatis saat sesi dimulai, dan menanam task runOn: folderOpen ke .vscode/tasks.json milik VS Code agar berjalan setiap kali folder dibuka
  • Kedua hook memanggil dropper mandiri setup.mjs, dan jika runtime Bun tidak ada, ia akan mengunduhnya diam-diam dari GitHub lalu menjalankan payload router_runtime.js berukuran 14.8MB
• Jika memperoleh token GitHub dengan izin tulis, malware ini akan mendorong workflow yang disamarkan sebagai Formatter ke repositori korban — pada setiap push, workflow itu membuang secret repositori dengan ${{ toJSON(secrets) }} lalu mengunggahnya sebagai artefak Actions
• Semua mesin yang memasang versi tersebut selama periode terdampak harus dianggap telah sepenuhnya dikompromikan, dan token GitHub, kredensial cloud, serta API key harus segera diganti; direktori .claude/ dan .vscode/ juga perlu diaudit untuk memastikan tidak ada file tak terduga
• Indikator serangan: prefiks EveryBoiWeBuildIsAWormyBoi pada pesan commit, "A Mini Shai-Hulud has Appeared" pada deskripsi repositori, serta keberadaan direktori _runtime/ di dalam repositori — semuanya bisa diperiksa langsung lewat pencarian GitHub

[picopress]

Sekarang sepertinya tidak boleh update dulu...

[GN⁺]

Komentar Hacker News

• Mungkin ini cuma ilusi frekuensi, tapi belakangan ini memang terlihat cukup banyak serangan rantai pasok terkenal pada paket-paket besar
  Bahkan di beberapa halaman teratas HN saat ini ada beberapa tulisan yang membahas kasus berbeda
  Kalau melihat kembali left-pad 10 tahun lalu, rasanya serangan yang berhasil sekarang memang lebih banyak daripada dulu, dan mungkin memang begitu
  Nilai dari serangan yang berhasil juga pasti makin besar, tapi saya penasaran apakah kemampuan untuk mendeteksinya sebelum rilis paket benar-benar membaik secara komunitas secara keseluruhan
  Perusahaan perangkat lunak komersial seharusnya bisa berbuat lebih baik, tetapi tampaknya masih kurang alat yang universal dan mudah dipakai untuk kasus ketika sesuatu bermula dari kode hobi/amatir lalu menjadi dependensi bagi banyak proyek
  Saya juga memposting komentar yang sama di thread serangan rantai pasok SAP saat ini: https://news.ycombinator.com/item?id=47964003

  • Ini memang fenomena nyata. Per awal April, ada 7 kasus dalam 12 bulan terakhir, sedangkan selama 20 tahun sebelumnya ada 9: https://www.jefftk.com/p/more-and-more-extensive-supply-chai...
  • Orang-orang mendorong kode ke mana-mana dalam jumlah besar tanpa benar-benar meninjaunya dengan baik, jadi wajar kalau serangan rantai pasok ikut meningkat
  • Penyebabnya adalah pembaruan otomatis dan alat CI sudah mencapai tingkat adopsi kritis sehingga dipakai semua orang
    Dulu lebih sering orang menjalankan npm install secara manual, dan kemungkinan hanya saat build rusak atau sesekali saja
    Serangan rantai pasok bergantung pada orang, atau lebih tepatnya pipeline, yang mengautoupdate paket tanpa pikir panjang begitu rilis baru keluar
  • Secara historis, penanganan artefak dengan pemeriksaan keamanan tambahan adalah opsi enterprise berbayar, sedangkan pilihan yang kurang aman menjadi default karena jauh lebih praktis
    Saya tidak tahu apakah ini model bisnis yang bagus, dan kemungkinan besar tidak juga
  • left-pad bukan serangan, melainkan bug di NPM
    Seharusnya tidak boleh menghapus versi paket yang sudah dipakai paket publik lain, dan sebaliknya seharusnya boleh menghapus versi paket baru yang belum dipakai siapa pun
    Ketika pembuat left-pad berusaha menghapus semua datanya dengan niat meninggalkan layanan, NPM seharusnya mengembalikan kode error
    Menurut Wikipedia, ketika Koçulu kecewa dengan keputusan npm, Inc. dan tidak ingin tetap menjadi bagian dari platform itu, Schlueter selaku pembuat NPM memberikan perintah untuk menghapus 273 modul yang didaftarkannya

• Hal yang aneh adalah ada 4 isu keamanan yang diajukan, dan semuanya otomatis dikomentari lalu ditutup oleh bot bernama pl-ghost [1][2][3][4]
  Pada akhirnya hanya [4] yang ditangani dengan benar, dan semua komentar bot itu dihapus
  Di laporan lain [5], komentar bot itu masih bisa dilihat, dan memberi informasi lebih banyak daripada sumber aslinya
  [1] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [2] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [3] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [4] https://github.com/Lightning-AI/pytorch-lightning/issues/216...
  [5] https://socket.dev/blog/lightning-pypi-package-compromised

  • Saya Andy dari Lightning. Benar, kredensial PyPI dicuri melalui akun bot pl-ghost yang telah dikompromikan
    Penyerang membuat workflow Actions baru dengan akun itu, lalu dari workflow yang berjalan mereka mem-parsing dan mengekstrak secret PyPI
    Setelah merilis paket, mereka juga meninggalkan komentar dengan akun itu sambil sedikit mengejek kami

• Semoga hari ketika tidak ada dependensi sama sekali cepat datang
  Sebagai contoh ekstrem, belakangan saat membuat aplikasi edukasi interaktif untuk putri saya, saya menyuruh Opus hanya memakai JavaScript dan HTML murni
  Dari pendulum ganda sampai simulasi fluida, semuanya berjalan baik sekaligus, dan dulu hal seperti ini akan melibatkan ratusan dependensi
  Jika kodenya berlisensi MIT, saya bisa menyuruh Opus mengekstrak hanya bagian yang benar-benar diperlukan lalu memodifikasi dan menyertakannya sesuai kebutuhan saya
  Untuk proyek hobi sejauh ini hasilnya bagus, dan ke depan saya berharap perangkat lunak produksi juga bisa tanpa dependensi

  • Kalau begitu Anda harus mengelola sendiri setiap perubahan dan banyak sekali pengecualian
    Kalau Chrome mengubah bentuk suatu API, Anda harus mencari dan memperbaikinya sendiri; kalau Maroko mengubah waktu mulai daylight saving, kode penanganan tanggal/waktu juga harus Anda update sendiri
    Hal-hal seperti itu selama ini terasa wajar karena pustaka yang mengurusnya untuk kita
    Untuk simulator pendulum ganda yang minggu depan mungkin sudah tidak menarik lagi bagi putri Anda, itu bukan masalah besar, tetapi bagi perusahaan yang membuat sesuatu yang harus terus berjalan tanpa batas, itu jadi masalah
  • Sekarang Anda justru terekspos ke dependensi yang benar-benar nyata, yaitu browser
  • Tentu Anda akan meninjau dengan teliti setiap baris kode yang dihasilkan Opus, seteliti standar yang Anda harapkan dari maintainer open source, kan? Kan?
    Mungkin saya harus merilis satu kode akses jarak jauh berlisensi MIT supaya masuk ke data pelatihan Opus
  • Saya lebih suka Rust daripada Go, jadi ini membuat saya galau. Bahkan dari sudut pandang LLM, Rust terasa lebih baik, tetapi filosofi dependensi Rust pada dasarnya seperti lubang hitam keamanan, dan Go jauh lebih baik
  • Ada repo atau forge yang bisa dibagikan? Saya punya game mengeja nama hewan ternak dan ingin memperluas pustaka saya serta mencari ide lain

• Saat mengikuti kursus deep learning Fast.AI, saya kaget melihat banyaknya dependensi Python yang dibawa proyek machine learning
  Proyek frontend web memang selalu dianggap punya banyak dependensi pihak ketiga, tetapi bagi saya ekosistem machine learning tampak jauh lebih kusut
  Selain itu, pengembangan web selama ini dianggap sensitif terhadap keamanan sehingga sudah lama mengumpulkan banyak kebijaksanaan dan praktik keamanan, sedangkan pengembangan machine learning tampak jauh lebih ad hoc dan banyak praktik rekayasa perangkat lunak umum yang tidak diterapkan
  Misalnya, salah satu cara deployment model machine learning saat itu adalah Python pickle, yaitu objek executable tanpa batasan bawaan
  Model dalam format ini bisa melakukan apa saja pada komputer yang mengimpornya, dan ekosistem ala wild west semacam itu bisa membuat insiden keamanan dan serangan rantai pasok lebih mudah terjadi

  • Banyak orang di ekosistem itu pada awalnya memang bukan software engineer
    Sebagian belajar sedikit coding sambil jalan, sebagian adalah matematikawan, dan sebagian lagi pengembang yang sedang mabuk AI
    Ada juga pola pikir bahwa “kode tidak penting lagi, yang penting jalan”
    Bagi banyak orang, manajemen dependensi yang benar hanyalah pekerjaan remeh yang tidak ingin mereka pikirkan
    Dalam banyak proyek machine learning, semua faktor ini bercampur, padahal sebenarnya proyek machine learning justru termasuk bidang yang paling perlu fokus pada reproduksibilitas

• Saya mencoba pencarian repo dan menemukan 2,2 ribu repo yang dibuat dalam sehari terakhir dengan teks "A Mini Shai-Hulud has Appeared": https://github.com/search?q=A%20Mini%20Shai-Hulud%20has%20Ap...

  • Nama repo semuanya tampak berupa dua istilah/kata dari dune, misalnya harkonen, mentat, ornithoptor, dengan angka di belakangnya
    Ini tampak seperti tanda bahwa akun, mungkin token autentikasi GitHub/Actions, telah dikompromikan lalu dipakai untuk membuat repo
  • Akun https://github.com/tinin46 tampaknya menyimpan banyak key, tapi saya tidak begitu paham dipakai untuk apa
  • Saya tidak mengerti kenapa GitHub tidak langsung bertindak dan memblokir repo yang README-nya cocok dengan regex itu
    Ini pernah terjadi sebelumnya, jadi saya kira mereka sudah belajar
    Malware ini tampaknya tidak berusaha keras, dan Microsoft juga tampaknya tidak terlalu berusaha
  • Ini sebenarnya sedang terjadi apa?

• Sebagai disclaimer, saya belum pernah memakai pytorch dan juga tidak terlalu paham praktik keamanan perangkat lunak
  Tetapi saya sulit membayangkan skenario di mana pytorch memerlukan akses jaringan
  Rasanya salah kalau modul mana pun bisa diimpor dari mana saja di codebase lalu memakai API itu
  Sepertinya perlu ada pembatasan import tambahan atau analisis statis
  Bahasa pemrogramannya tampaknya belum punya abstraksi yang tepat untuk menangani masalah seperti ini
  Sebagai perbandingan, saya suka bahwa di Rust kita bisa melihat mutability dan lifetime hanya dari signature fungsi, tanpa harus memahami kode internalnya
  Rasanya dependensi juga butuh sesuatu yang mirip
  Developer seharusnya bisa mengaudit semua dependensi dengan mudah tanpa harus mengintip kode level bawah, lalu langsung melihat “oh, dependensi ini memakai eval()” atau “yang ini mengakses jaringan”
  Aplikasi mobile memaksa permission, jadi rasanya developer juga seharusnya bisa membuat allowlist hanya untuk kemampuan tertentu alih-alih menerima seluruh tumpukan fitur begitu saja

  • Ekosistem Python mungkin tidak akan pernah mengizinkan hal seperti ini, tetapi saya berharap topik ini bisa lebih dipahami dan diakui di sana
    Saya tidak ingin terlalu menggeneralisasi, tetapi khususnya komunitas pengembangan AI tampaknya lebih memilih kenyamanan daripada semua pertimbangan lain
    Misalnya, sudah seperti standar bahwa sebuah proyek akan otomatis mengunduh model besar saat pertama kali dijalankan
    Biasanya itu bisa dimatikan, tetapi mencari parameter yang benar benar-benar menyakitkan karena lapisan class kode yang dalam di banyak pustaka
    Memang menyenangkan kalau hal-hal rumit, yang sering kali nyaris cuma mainan, bisa dimulai dengan sangat mudah, tetapi suasana permisif ini cukup membuat tidak nyaman
    Langkah pertama penyelesaian masalah rasanya selalu “pip install …”, dan beberapa lingkungan, misalnya MacOS, juga tidak terlalu baik dalam virtualisasi akses GPU
  • Ada kasus training model di banyak compute node. Itu adalah contoh besar yang memang membutuhkan akses jaringan

• Minggu ini saya sempat bertanya-tanya apakah memakai uv untuk manajemen versi Python adalah ide yang bagus
  Di situs webnya [1] tertulis, “karena Python tidak menyediakan binary resmi untuk distribusi, uv memakai distribusi dari proyek Astral python-build-standalone”
  Itu menunjuk ke repo GitHub ini https://github.com/astral-sh/python-build-standalone, yang kemudian merujuk lagi ke https://gregoryszorc.com/docs/python-build-standalone/main/r...
  Kalau saya memahaminya dengan benar, sepertinya source code untuk build Python tidak diambil langsung dari python.org, dan saya tidak yakin seberapa aman itu
  Saya punya kekhawatiran yang sama terhadap asdf [2], tetapi asdf memakai pyenv [3] dan itu terasa sedikit lebih dekat ke jalur resmi
  Bisakah seseorang menjelaskan alat mana yang lebih baik dan lebih aman antara uv dan asdf untuk instalasi Python?
  [1] https://docs.astral.sh/uv/guides/install-python/
  [2] https://github.com/asdf-community/asdf-python
  [3] https://github.com/pyenv/pyenv/tree/master/plugins/python-bu...

  • python-build-standalone mengambil source CPython langsung dari python.org[1]
    Memangnya mau ambil dari mana lagi?
    [1]: https://github.com/astral-sh/python-build-standalone/blob/a2...
  • Saya tidak terlalu khawatir tentang uv dan cpython. Prosesnya kokoh, responsnya cepat, dan sekarang dananya juga cukup besar
    Yang saya khawatirkan adalah formatter seperti mdformat, yang dipakai luas tetapi pada dasarnya dikelola satu orang di waktu luangnya, atau dependensi yang sangat spesifik yang sudah bertahun-tahun tidak diperbarui dan berada tiga tingkat di bawah dalam pohon dependensi
    Saya tidak ingin mem-pin semua pembaruan dan menyetujui manual semuanya pada aplikasi yang sedang aktif dikembangkan, tetapi untuk aplikasi serius itu mulai terasa seperti keharusan sekarang
    Sementara itu saya akan mengambil API key dari file .env yang tidak terenkripsi
    Kalau ini terjadi pada webapp konsumen besar, itu memalukan tapi masih bisa dimengerti; tetapi kehilangan ratusan sampai ribuan dolar gara-gara dependensi tidak langsung dari repo demo main-main yang kebetulan ada di host dan sistem yang sama itu terlalu menyakitkan
    Ada yang tahu apakah OAI atau Anthropic akan memberi refund jika key dicuri dengan cara seperti ini? Atau itu dianggap kesalahan pengguna?
  • Dari awal, uv sendiri adalah binary yang Anda jalankan di komputer untuk mengelola binary Python, paket, binary di dalamnya, alat sistem global, dan seterusnya
    Saya tidak tahu seberapa besar perbedaan risikonya antara Python binary yang mereka build sendiri dengan yang dibangun orang lain

• Belakangan ini sebagian besar pip install saya terjadi karena Claude Code yang menyarankan lalu saya tinggal menekan Enter
  Model itu dilatih dengan data beberapa bulan lalu, jadi jelas tidak mungkin tahu apa yang dikompromikan minggu ini
  Saya sadar saya telah membuat filter terburuk untuk menilai “apakah paket ini aman saat ini”

  • Jangan menyalahkan LLM atas kemalasan dan kurangnya due diligence
  • Filter yang mana?
    Anda bilang Claude Code merekomendasikan software untuk diinstal dari internet, lalu Anda langsung menginstalnya
    Saya belum pernah mendengar ada yang menyarankan Claude Code atau LLM mana pun sebagai filter untuk menilai “apakah paket ini aman saat ini”, dan dengan alasan yang Anda sebut sendiri, itu terdengar seperti heuristik yang sangat buruk
  • Data pelatihan yang usang memang sebagian masalahnya, tetapi bahkan model terbaru pun tidak bisa tahu apa yang akan dijalankan setup.py di mesin saya
    Karena memang tidak ada yang benar-benar memeriksa paket itu sebelum dijalankan
    Yang dibutuhkan adalah alat yang mengambil metadata sebelum eksekusi untuk memeriksa hook apa saja yang ada
  • Ini mudah dihindari kalau Anda tidak menekan Enter
  • Yang dimaksud “filter terburuk” itu kebiasaan menekan Enter begitu saja karena Claude yang menyuruh?

• Claude Code diperbarui hampir setiap hari, kadang bahkan beberapa kali sehari
  Kalau suatu hari Anthropic dikompromikan, kita semua bakal kena parah

  • “Kita” itu siapa?
  • Kalau dijalankan dalam VM/kontainer tanpa privilege dan dengan akses jaringan terbatas, tidak juga
    Tapi akhir-akhir ini semua orang serba YOLO
  • Rasanya itu sudah tercermin dalam harga Polymarket

• Saya melihat pesan ini di GitHub yang diposting pada 20 April dan agak bingung
  "deependujha hi @thebaptiste, thanks for inquiring. Release of 2.6.2 is blocked due to some internal reasons. Will notify once release is made."
  Kalau mereka sudah tahu soal masalahnya sejak saat itu dan masih belum memberi peringatan sampai sekarang, saya akan sangat tidak suka
  Saya berharap ada orang yang tahu lebih banyak dan bisa menjelaskan dengan jelas
  https://github.com/Lightning-AI/pytorch-lightning/issues/216...

  • Saya Andy dari Lightning. Paket berbahaya itu dipublikasikan ke PyPI hari ini pada 12:45 PM UTC
    Sebelum itu tidak ada distribusi terdampak, dan kami juga belum mengetahui kebocorannya
    Rilis asli di GitHub tidak bermasalah, tetapi kami tetap menurunkannya untuk mencegah kebingungan
  • Untuk pengguna uv: https://docs.astral.sh/uv/reference/settings/#exclude-newer