Shai-Hulud temalı kötü amaçlı yazılım, PyTorch Lightning AI eğitim kütüphanesinde tespit edildi

• Derin öğrenme çatısı lightningin 2.6.2 ve 2.6.3 sürümleri tedarik zinciri saldırısında kötüye kullanıldı — yalnızca pip install lightning komutunu çalıştırmak bile gizli _runtime dizinindeki obfuscate edilmiş JavaScript yükünün otomatik olarak çalışmasına neden oluyor
• Görüntü sınıflandırıcı oluşturma, LLM fine-tuning, difüzyon modelleri ve zaman serisi tahmini gibi alanlarda yaygın kullanılan bir çatı olduğundan, birçok AI/ML ekibinin bağımlılık ağacında zaten yer alıyor olma ihtimali yüksek
• Kötü amaçlı yazılım çalıştığında yerel dosya sisteminde 80'den fazla yolu tarayarak GitHub token'larını (ghp_, gho_), npm token'larını (npm_), ortam değişkenlerini ve bulut gizli anahtarlarını çalıyor; dosya başına en fazla 5 MB işliyor
• AWS (kimlik bilgisi dosyaları·IMDSv2·ECS·Secrets Manager·SSM), Azure (Key Vault), GCP (Secret Manager) dahil üç büyük bulut sağlayıcısının tamamında gizli değerleri enumerate edip alıyor
• GitHub Actions ortamında yerleşik Python ile Runner.Worker süreç belleğini dump ederek "isSecret":true olarak işaretlenmiş tüm gizli değerleri ve depo·workflow bilgilerini çıkarıyor
• Giriş noktası PyPI (Python) olsa da worm yayılımı npm (JavaScript) üzerinden genişliyor — çalınan npm token'larıyla yayımlama yetkisi olan tüm paketlere dropper (setup.mjs) ve kötü amaçlı yazılımı (router_runtime.js) enjekte ediyor, patch sürümünü artırıp yeniden yayımlıyor; bu paketleri kuran alt geliştiricilerin makinelerine kadar zincirleme bulaşıyor
• Veri sızdırma, tek bir yolu engelleyerek durdurulamasın diye 4 paralel kanal kullanıyor: ① HTTPS POST ile C2 sunucusuna gönderim, ② GitHub commit arama API'sini kullanan dead drop (commit mesajına çift Base64 kodlanmış token yerleştirme), ③ Dune evrenindeki isimleri taşıyan herkese açık GitHub depolarına results-<timestamp>.json olarak commit etme, ④ doğrudan kurban deposuna push etme
• Depoya sızdıktan sonra geliştirme araçlarına kalıcılık hook'ları yerleştirerek yeniden bulaşmayı garanti ediyor — Claude Code'un .claude/settings.json dosyasına oturum başında otomatik çalışan bir SessionStart hook'u yazıyor, VS Code'un .vscode/tasks.json dosyasına ise klasör her açıldığında çalışan runOn: folderOpen görevi ekliyor
  • Her iki hook da self-contained dropper setup.mjsyi çağırıyor; Bun runtime yoksa GitHub'dan sessizce indirip 14.8 MB'lık router_runtime.js yükünü çalıştırıyor
• Yazma yetkisine sahip bir GitHub token'ı ele geçirirse kurban deposuna Formatter adlı kamufle edilmiş bir workflow push ediyor — her push işleminde ${{ toJSON(secrets) }} ile depo gizli değerlerini dump edip Actions artifact olarak yüklüyor
• Etkilenen dönem içinde bu sürümleri kurmuş tüm makineler tam olarak ele geçirilmiş kabul edilmeli; GitHub token'ları, bulut kimlik bilgileri ve API anahtarları derhal değiştirilmeli, ayrıca .claude/ ve .vscode/ dizinlerinde beklenmeyen dosyalar olup olmadığı denetlenmeli
• Saldırı göstergeleri arasında commit mesajlarında EveryBoiWeBuildIsAWormyBoi öneki, depo açıklamasında "A Mini Shai-Hulud has Appeared" ifadesi ve depo içinde _runtime/ dizininin bulunması yer alıyor; bunlar GitHub aramasıyla doğrudan doğrulanabilir

[picopress]

Artık güncelleme yapmamak gerekecek...

[GN⁺]

Hacker News görüşleri

• Bu sadece bir sıklık yanılgısı da olabilir ama son zamanlarda büyük paketlerde ses getiren tedarik zinciri saldırıları epey fazla görünmeye başladı
  Şu an bile HN’in ilk birkaç sayfasında farklı vakaları ele alan birden çok yazı var
  10 yıl önceki left-pad olayını düşününce, bugün başarılı saldırıların eskisine göre daha fazla olup olmadığını merak ediyorum; muhtemelen öyle
  Başarılı saldırıların değeri de kesinlikle artmıştır, ama topluluk olarak paket yayınlanmadan önce bunları tespit etme becerimiz gerçekten gelişiyor mu, onu merak ediyorum
  Ticari yazılım şirketleri daha iyisini yapmak zorunda, ama hobi/amatör kod olarak başlayıp sonra pek çok projenin bağımlılığına dönüşen durumlar için genel geçer ve kolay araçlar hâlâ eksik görünüyor
  Aynı yorumu mevcut SAP tedarik zinciri saldırısı başlığında da yazdım: https://news.ycombinator.com/item?id=47964003

  • Bu gerçekten yaşanan bir durum. Nisan başı itibarıyla son 12 ayda 7 olay oldu; ondan önceki 20 yılda ise 9 olay vardı: https://www.jefftk.com/p/more-and-more-extensive-supply-chai...
  • İnsanlar kodu düzgün incelemeden her yere topluca itiyor, dolayısıyla tedarik zinciri saldırılarının artması doğal
  • Sebep, otomatik güncellemeler ve CI araçlarının kritik yaygınlığa ulaşıp herkes tarafından kullanılması
    Eskiden npm install daha çok elle çalıştırılırdı; muhtemelen build bozulduğunda ya da çok nadiren çalıştırılıyordu
    Tedarik zinciri saldırıları, insanların ya da daha doğrusu pipeline’ların yeni sürüm çıkar çıkmaz paketleri düşünmeden otomatik güncellemesine dayanıyor
  • Tarihsel olarak ek güvenlik kontrollerinden geçirilmiş artefakt işleme, ücretli kurumsal seçenekti; daha az güvenli olan taraf ise çok daha zahmetsiz varsayılandı
    Bunun iyi bir iş modeli olup olmadığını bilmiyorum; muhtemelen pek değil
  • left-pad bir saldırı değil, NPM hatasıydı
    Başka herkese açık paketlerin zaten bağımlı olduğu bir paket sürümünü silebilmek mümkün olmamalıydı; buna karşılık yeni bir sürüm olup kimsenin bağımlı olmadığı belirli paket sürümleri silinebilmeliydi
    left-pad yazarı hizmetten ayrılma niyetiyle tüm verilerini silmeye çalıştığında NPM bir hata kodu döndürmeliydi
    Wikipedia’ya göre Koçulu, npm, Inc.’in kararlarından hayal kırıklığına uğrayıp platformun parçası olarak kalmak istemediğini söyleyince, NPM yazarı Schlueter ona kayıtlı 273 modülü silmeye yarayan komutu vermiş

• Garip olan şu ki 4 güvenlik sorunu açılmış, ama hepsine pl-ghost adlı bot otomatik yorum yazıp kapatmış [1][2][3][4]
  Sonunda bunlardan yalnızca [4] düzgün ele alınmış ve bot yorumlarının hepsi silinmiş
  Bot yorumlarını başka bir raporda [5] görebiliyorsunuz; orada özgün metinden daha fazla bilgi var
  [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

  • Ben Lightning’den Andy. Evet, PyPI kimlik bilgileri, ele geçirilmiş pl-ghost bot hesabı üzerinden çalındı
    Saldırgan bu hesapla yeni bir Actions workflow’u oluşturdu ve çalıştırılan workflow içinden PyPI secret’larını parse edip dışarı çıkardı
    Paketi yayımladıktan sonra da aynı hesapla yorum yazarak bizimle biraz alay etti

• Keşke hiç bağımlılık olmayan günler bir an önce gelse
  Uç bir örnek olarak, bu aralar kızım için etkileşimli eğitim uygulamaları yaparken Opus’a yalnızca saf JavaScript ve HTML kullandırıyorum
  Çift sarkaçtan akışkan simülasyonuna kadar her şey tek seferde gayet iyi çalışıyor; eskiden bunun için yüzlerce bağımlılık olurdu
  Kod MIT lisanslıysa, Opus’a sadece gereken kısımları tam olarak çekip benim kullanım amacım için değiştirerek projeye dahil etmesini söyleyebiliyorum
  Hobi projelerinde şu ana kadar iyi işledi; ileride prodüksiyon yazılımında da bağımlılıklardan kurtulabilsek keşke

  • Bunu yaparsanız her değişikliği ve sayısız istisnayı kendiniz yönetmek zorunda kalırsınız
    Chrome bir API biçimini değiştirirse gidip kendiniz bulup düzeltmeniz gerekir; Fas yaz saati başlangıç zamanını değiştirirse tarih/saat işleme kodunu da kendiniz güncellemeniz gerekir
    Bunlar, kütüphanelerin bizim yerimize hallettiği için doğal karşıladığımız şeyler
    Kızınızın gelecek hafta ilgisini kaybedeceği bir çift sarkaç simülatörü için büyük mesele değil, ama süresiz çalışması gereken bir şey yapan şirket için sorun olur
  • Artık gerçek bağımlılık olan tarayıcıya maruz kalmış oluyorsunuz
  • Elbette Opus’un ürettiği kodun her satırını, açık kaynak bakımcılarından beklediğiniz titizlik seviyesinde tek tek inceleyeceksiniz, değil mi?
    Sanırım uzaktan erişim sağlayan MIT lisanslı bir kod yayımlayıp Opus eğitim verisine girmesini sağlamalıyım
  • Rust’ı Go’ya tercih ettiğim için kararsızım. LLM açısından da Rust daha iyi, ama Rust’ın bağımlılık felsefesi fiilen bir güvenlik kara deliği ve Go çok daha iyi
  • Paylaşılabilir bir repo ya da forge üzerinde duran bir şeyin var mı? Çiftlik hayvanları için heceleme oyunum var; kütüphanemi genişletip daha fazla fikir üretmek istiyorum

• Fast.AI derin öğrenme kursunu alırken, makine öğrenmesi projelerinin beraberinde getirdiği Python bağımlılıklarının sayısına şaşırmıştım
  Web frontend projelerinin her zaman çok sayıda üçüncü taraf bağımlılığına sahip olduğu düşünülür, ama bana göre makine öğrenmesi ekosistemi çok daha fazla birbirine dolanmış durumda
  Üstelik web geliştirme güvenliğe duyarlı kabul edildiği için uzun zamandır güvenlik bilgeliği ve pratikleri birikti, ama makine öğrenmesi geliştirme çok daha geçici çözümlerle ilerliyor gibi ve genel yazılım mühendisliği pratiklerinin çoğu da uygulanmıyor
  Örneğin o dönemde makine öğrenmesi modeli dağıtım yollarından biri Python pickle’dı; bu da temelde kısıtsız çalıştırılabilir nesne demek
  Bu biçimdeki modeller, içe aktarıldıkları makinede her şeyi yapabiliyordu; böylesi erken dönem kanunsuz ekosistemler güvenlik ihlallerini ve tedarik zinciri saldırılarını kolaylaştırabiliyor

  • O ekosistemde baştan beri yazılım mühendisi olmayan çok kişi var
    Kimisi süreç içinde biraz kod yazmayı öğrendi, kimisi matematikçi, kimisi de AI’a fazlasıyla kapılmış geliştirici türünden
    “Kod artık önemli değil, çalışsın yeter” zihniyeti de var
    Pek çok kişi için düzgün bağımlılık yönetimi, uğraşmak istemedikleri sıkıcı bir angarya sadece
    Çeşitli makine öğrenmesi projelerinde bütün bu unsurlar birleşiyor; oysa aslında yeniden üretilebilirliğe en çok odaklanması gereken alanlardan biri makine öğrenmesi olmalı

• Repo araması yaptım; son bir gün içinde oluşturulan depolarda "A Mini Shai-Hulud has Appeared" metnini içeren 2,2 bin depo çıktı: https://github.com/search?q=A%20Mini%20Shai-Hulud%20has%20Ap...

  • Depo adlarının hepsi, örneğin harkonen, mentat, ornithoptor gibi dune’dan iki terim/kelimeye sayı eklenmiş biçimde görünüyor
    Bu, hesapların, muhtemelen GitHub auth/Actions token’larının, ele geçirildikten sonra depo oluşturmak için kullanıldığına işaret ediyor gibi
  • https://github.com/tinin46 hesabı çok sayıda anahtar depoluyor gibi duruyor ama ne amaçla kullandığını anlayamadım
  • GitHub neden hemen harekete geçip README’si bu regex’e uyan depoları engellemiyor, anlamıyorum
    Bu daha önce de oldu; ders almış olurlar sanıyordum
    Bu malware pek çaba göstermemiş, Microsoft da pek çaba göstermiyor gibi
  • Bu tam olarak ne oluyor?

• Sorumluluktan kaçmak için söylemiyorum; pytorch’u hiç kullanmadım ve yazılım güvenliği pratiklerini de çok iyi bilmiyorum
  Ama pytorch’un ağ erişimine ihtiyaç duyduğu bir senaryoyu gözümde pek canlandıramıyorum
  Kod tabanının herhangi bir yerinde rastgele bir modülün içe aktarılıp bu API’yi kullanabilmesi yanlış geliyor
  İlave import kısıtlamaları ya da statik analiz gerekli gibi görünüyor
  Dilin bu sorunları ele almak için doğru soyutlamalara sahip olmadığı hissine kapılıyorum
  Karşılaştırma için, Rust’ta bir fonksiyon imzasına bakıp iç kodu anlamadan değiştirilebilirliği ve lifetime’ları görebilmeyi seviyorum
  Bağımlılıklar için de benzer bir şeye ihtiyaç var gibi
  Geliştirici, alt düzey koda bakmak zorunda kalmadan tüm bağımlılıkları kolayca denetleyebilmeli ve “aa, bu bağımlılık eval() kullanıyor” ya da “ağ erişimi var” diyebilmeli
  Mobil uygulamalarda izinler zorunlu; geliştiriciler de yalnızca belirli işlevleri allowlist’e alabilmeli ve her şeyi toptan kabul etmek zorunda kalmamalı diye düşünüyorum

  • Python ekosistemi bunu asla kabul etmez, ama bu konunun orada daha iyi anlaşılmasını ve kabul görmesini isterdim
    Genelleme yapmak istemem ama özellikle AI geliştirici topluluğu, diğer tüm kaygıların önüne kolaylığı koyuyor gibi
    Örneğin projelerin ilk çalıştırmada büyük modelleri otomatik indirmesi neredeyse standart olmuş durumda
    Genelde kapatılabiliyor ama birçok kütüphaneye yayılan kod sınıflarının derin katmanları yüzünden doğru parametreyi bulmak gerçekten çok acı verici
    Karmaşık, çoğu zaman oyuncağa yakın şeylere başlamayı bu kadar kolaylaştırmak güzel, ama bu aşırı izin verici kültür epey rahatsız edici
    İlk sorun çözme adımı hep “pip install …” gibi geliyor; bazı ortamlarda, örneğin MacOS’ta, GPU erişimi sanallaştırması da pek iyi değil
  • Modellerin birden fazla compute node üzerinde eğitildiği durumlar var. Bu, ağ erişimi gerektiren büyük örneklerden biri

• Bu hafta Python sürüm yönetimi için uv kullanmanın iyi bir fikir olup olmadığını düşünüyordum
  Web sitesinde [1] “Python resmî dağıtım için binary sağlamadığından uv, Astral python-build-standalone projesinin dağıtımlarını kullanır” yazıyor
  Bu da şu GitHub reposuna işaret ediyor: https://github.com/astral-sh/python-build-standalone, orası da https://gregoryszorc.com/docs/python-build-standalone/main/r... bağlantısını veriyor
  Doğru anladıysam, Python build için kaynak kodu doğrudan python.org’dan almıyorlar gibi; bunun ne kadar güvenli olduğundan emin değilim
  asdf [2] için de aynı kaygım var ama asdf, pyenv [3] kullanıyor ve o taraf daha resmî hissettiriyor
  Python kurulumunda uv ile asdf arasında hangisi daha iyi ve daha güvenli, bunu açıklayabilecek var mı?
  [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, CPython kaynağını doğrudan python.org’dan alıyor[1]
    Zaten başka nereden alacaktı ki?
    [1]: https://github.com/astral-sh/python-build-standalone/blob/a2...
  • uv ve cpython konusunda pek endişelenmiyorum. Süreç sağlam, müdahale hızlı ve artık ciddi finansmanları da var
    Asıl kaygı verici olan, örneğin mdformat gibi yaygın kullanılan ama esasen bir kişinin boş zamanında bakımını yaptığı formatter’lar ya da yıllardır güncellenmemiş ve bağımlılık ağacında üç seviye aşağıda duran çok spesifik bağımlılıklar
    Aktif geliştirilen bir uygulamada bütün güncellemeleri sabitleyip elle onaylamak istemezdim, ama ciddi bir uygulama için artık bu zorunluymuş gibi görünmeye başlıyor
    Bu arada şifrelenmemiş .env dosyalarından API anahtarı çıkarmaya devam edebilirim sanırım
    Büyük ölçekli tüketici web uygulamasında olursa utandırıcı ama anlaşılabilir; ama aynı host ve sistemde tesadüfen duran oyuncak bir demo reposunun dolaylı bağımlılığı yüzünden yüzlerce ya da binlerce dolar kaybetmek çok can yakıcı
    Anahtarlar böyle çalınırsa OAI ya da Anthropic geri ödeme yapıyor mu bilen var mı? Yoksa bu tamamen kullanıcı hatası mı sayılıyor?
  • Sonuçta uv, bilgisayarınızda çalışan ve Python binary’lerini, paketleri, içlerindeki binary’leri, sistem genelindeki araçları vb. yöneten bir binary
    Python binary’lerini onların mı yoksa bir başkasının mı derlediğinin riski ne kadar değiştirdiğinden emin değilim

• Son zamanlarda yaptığım pip install işlemlerinin çoğu Claude Code önerisiyle oluyor; ben de sadece Enter’a basıyorum
  Model birkaç ay öncesinin verileriyle eğitildiği için bu hafta nelerin ele geçirildiğini bilmesi mümkün değil
  “Bu paket şu anda güvenli mi?” sorusunu değerlendirmek için olabilecek en kötü filtreyi yaratmış oldum

  • Tembelliği ve yetersiz incelemeyi LLM’lerin suçuymuş gibi göstermemek lazım
  • Hangi filtreden söz ediyorsun?
    Claude Code’un internetten kurulacak yazılımı önermesine izin verip sonra da aynen kurduğunu söylemiş oldun
    Claude Code’un ya da herhangi bir LLM’in “bu paket şu anda güvenli mi” sorusunu cevaplayan bir filtre olduğunu öne süren birini hiç duymadım; söylediğin nedenle de bu çok kötü bir sezgisel yöntem gibi görünüyor
  • Eski eğitim verisi işin bir kısmı, ama en yeni model bile setup.py dosyasının benim makinemde ne çalıştıracağını bilemez
    Çünkü çalıştırmadan önce paketi gerçekten inceleyen bir şey yok
    İhtiyaç duyulan şey, çalıştırmadan önce metadata’yı çekip hangi hook’ların olduğunu gösteren bir araç
  • Enter’a basmazsan bunu kolayca atlatabilirsin
  • “En kötü filtre” derken Claude ne diyorsa diye Enter’a basmanı mı kastediyorsun?

• Claude Code neredeyse her gün, bazen günde birkaç kez güncelleniyor
  Bir gün Anthropic ele geçirilirse hepimiz çok kötü etkileniriz

  • “Hepimiz” derken kimden bahsediyorsun?
  • Yetkisiz bir VM/container içinde, kısıtlı ağ erişimiyle çalıştırırsan hayır
    Ama bugünlerde her şey YOLO
  • Muhtemelen Polymarket fiyatına zaten yansımıştır

• GitHub’da 20 Nisan’da gönderilmiş şu mesajı gördüm, biraz kafam karıştı
  "deependujha hi @thebaptiste, thanks for inquiring. Release of 2.6.2 is blocked due to some internal reasons. Will notify once release is made."
  Eğer o zamandan beri sorunu biliyorlardı da şimdiye kadar uyarı vermedilerse, bu gerçekten hoşuma gitmezdi
  Daha fazla bilen biri net bir açıklama yaparsa iyi olur
  https://github.com/Lightning-AI/pytorch-lightning/issues/216...

  • Ben Lightning’den Andy. Kötü amaçlı paket bugün UTC 12:45 PM’de PyPI’a yüklendi
    Ondan önce etkilenmiş dağıtım yoktu ve sızıntıdan da haberimiz yoktu
    GitHub’daki orijinal release’de sorun yoktu, ama kafa karışıklığını önlemek için onu da yayından kaldırdık
  • uv kullananlar için: https://docs.astral.sh/uv/reference/settings/#exclude-newer