Shai-Hulud Geri Döndü: 300’den Fazla NPM Paketi Enfekte Oldu

 (helixguard.ai)
17 puan yazan GN⁺ 2025-11-25 | 5 yorum | WhatsApp'ta paylaş
  • NPM kayıt defterinde 1.000’den fazla bileşen, birkaç saat içinde aynı yöntemle enfekte edildi ve kötü amaçlı kod içeren yeni sürümler yayımlandı
  • Kötü amaçlı paketler, Bun runtime kurulum betiği gibi davranarak setup_bun.js ve obfuscate edilmiş bun_environment.js dosyasını ekledi; çalıştırıldığında TruffleHog kullanarak yerel kimlik bilgilerini çaldı
  • Toplanan AWS/GCP/Azure·GitHub·NPM token’ları gibi hassas bilgiler, SHA1HULUD adlı bir GitHub Action runner üzerinden dışarı aktarıldı
  • Kötü amaçlı betik, npm publish komutunu otomatik çalıştırarak solucan benzeri kendi kendini çoğaltma gerçekleştirdi; sonuç olarak 27.000’den fazla GitHub deposu enfekte oldu
  • Bu olay, açık kaynak ekosisteminin geneline yayılan tedarik zinciri güvenliği tehdidini yeniden gündeme getiren bir örnek olarak değerlendiriliyor

Saldırıya genel bakış

  • 24 Kasım 2025’te HelixGuard, NPM kayıt defterinde 1.000’den fazla paketin birkaç saat içinde aynı yöntemle enfekte edildiğini tespit etti
    • Yeni sürümler, Bun runtime ekliyormuş gibi davranıyor ve preinstall: node setup_bun.js betiğini içeriyordu
    • Birlikte dağıtılan bun_environment.js dosyası obfuscate edilmiş kötü amaçlı koddu; çalıştırıldığında TruffleHog’u indirip yürütüyordu
  • TruffleHog, yerel ortamda NPM token’ları, AWS/GCP/Azure kimlik bilgileri, ortam değişkenleri gibi verileri tarayarak çaldı
  • Çalınan bilgiler, SHA1HULUD adlı GitHub Action runner’ı oluşturup Sha1-Hulud: The Second Coming. açıklamasına sahip bir GitHub deposu üzerinden dışarı sızdırıldı
  • HelixGuard, bu saldırının Eylül 2025’te yaşanan “Shai-Hulud” olayıyla aynı saldırgan tarafından gerçekleştirilmiş olabileceğine işaret ediyor

Kötü amaçlı kodun çalışma analizi

  • Örnek olarak @asyncapi/specs paketi incelendiğinde, NPM’de yayımlanan sürümün enfekte olduğu ancak GitHub’daki kaynak deponun güvenli olduğu görüldü
  • Saldırgan, package.json dosyasını değiştirerek setup_bun.js ekledi ve bu betiğin bun_environment.js dosyasını çağırmasını sağladı
  • bun_environment.js, 10 MB’tan büyük yüksek derecede obfuscate edilmiş bir JavaScript dosyası ve başlıca işlevleri şunlar:
    • Ortam değişkenlerinden bulut kimlik bilgileri ve token toplama
    • TruffleHog kullanarak gizli anahtar taraması yapma
    • GitHub Actions üzerinden veri sızdırma
  • Ayrıca package.json dosyasını değiştirip enfeksiyon kodunu ekliyor ve npm publish komutunu otomatik çalıştırarak solucan benzeri yayılma gerçekleştiriyordu
Reklam

GitHub enfeksiyonu ve veri sızdırma

  • Kötü amaçlı betik, .github/workflows/formatter_123456789.yml dosyasını oluşturup SHA1HULUD runner’ını kaydediyor
  • Bu workflow, deponun gizli anahtarlarını çift Base64 kodlamasıyla actionsSecrets.json dosyası halinde paketliyor
  • Ardından Sha1-Hulud: The Second Coming. açıklamasına sahip rastgele adlı bir GitHub deposu oluşturup verileri yüklüyor
  • HelixGuard, 27.000’den fazla GitHub deposunun enfekte olduğunu doğruladı
  • Çalınan gizli bilgiler arasında AWS_ACCESS_KEY_ID, SLACK_WEBHOOK_URL, CODECOV_TOKEN, WEBFLOW_TOKEN gibi çeşitli hizmet kimlik bilgileri bulunuyor

Enfekte paketlerin listesi

  • HelixGuard, yüzlerce NPM paketinin enfekte olduğunu bildirdi
    • Bunlar arasında @asyncapi, @ensdomains, @posthog, @zapier, @postman, @voiceflow gibi önemli kuruluşların paketleri de yer alıyor
    • Her paket içinde birden fazla sürümün enfekte olduğu görüldü (ör. @asyncapi/specs@6.8.2, @postman/csv-parse@4.0.5)
  • Enfekte paketlerin çoğu meşru açık kaynak projeleri gibi görünüyordu ve otomatik dağıtım sürecine kötü amaçlı kod enjekte edilmişti

Güvenlik açısından çıkarımlar

  • Bu saldırı, tedarik zinciri güvenliğindeki zayıflıkları istismar ederek büyük ölçekli açık kaynak ekosistemini enfekte eden bir vaka
  • NPM·GitHub·bulut kimlik bilgileri dahil geliştirme altyapısının genelinde güvenlik yönetiminin güçlendirilmesi gerekliliğini ortaya koyuyor
  • HelixGuard, enfekte paketlerin kurulumunun derhal durdurulmasını ve ilgili token’lar ile kimlik bilgilerinin hemen iptal edilmesini tavsiye ediyor

İlgili okumalar

5 yorum

 
ahwjdekf 2025-11-27

JS ekosisteminin gerçekten tam bir çöplük olduğu yorumu doğru.
 
developerjhp 2025-11-25

Gerçek zamanlı bir tarayıcı betiği oluşturdum.

Şüpheli deponun path'inde
npx sha1-hulud-scanner
komutunu girmeniz yeterli.

Kaynak kodu: https://github.com/developerjhp/sha1-hulud-scanner
 
GN⁺ 2025-11-25
Hacker News yorumu

  • Bir ipucu paylaşayım: NPM yerine PNPM kullanmak daha iyi
    PNPM 10.x birçok saldırı vektörünü engelliyor
    1️⃣ Varsayılan olarak post-install scriptlerini çalıştırmıyor ve manuel onay istiyor
    2️⃣ Yeni bir sürüm yayınlandıktan sonra belirli bir süre geçmeden (ör. 4 gün) kurulmayacak şekilde ayarlanabiliyor
    NPM, production CLI ortamında fazla istikrarsız
    Publisher anahtarlarını en az ayrıcalıkla sınırlamak, yalnızca belirli paketlere bağlamak ve IP’yi CI/CD runner’larına sabitlemek iyi olur
    Publish anahtarlarını lokalde tutmayın; gerekirse OIDC Trusted Publisher ya da token tabanlı erişimi değerlendirin

    • NPM, üzerine çok fazla teknik borç birikmiş bir ürün gibi görünüyor
      Sadece lockfile için bile beş kez denediler ama hâlâ kusursuz değil
      Yapıya ve commit geçmişine bakınca ekibin ciddi şekilde iyileştirmeye çalıştığı belli ama sanki işe çok derin bir çukurdan başlamışlar
      Hâlâ dosya aktarımı sırasında erken EOF’yi algılayamıyor ve cache’te eksik dosyalar bırakıyor; bu da yavaş internet ortamlarında update hataları yüzünden ciddi zaman kaybına yol açıyor
    • Ben HashiCorp Vault / OpenBao’nun dinamik secret yönetimi yaklaşımını tercih ediyorum
      Başta karmaşık ama secret’ları lease kavramıyla yönetebiliyorsunuz
      Her CI build’i için bir lease oluşturuluyor ve bittiğinde otomatik olarak iptal ediliyor; ayrıca TTL ve otomatik rotasyon da destekleniyor
      Bu sayede uzun ömürlü kimlik bilgilerini saklamak yerine yalnızca build anında kısa ömürlü token’lar verebiliyorsunuz
      Böyle saldırılar sayesinde şirket içinde gerçek bir güvenlik tartışması başlaması olumlu
    • Sadece npm ci kullanmak yeterli
      Çünkü package-lock.json’da belirtilen sürümler kuruluyor, bu da otomatik güncellemelerden kaynaklanan saldırı riskini azaltıyor
      Önemli olan yalnızca bilinçli güncelleme yapmak
    • Python ekosisteminde pip install --only-binary=:all: seçeneğiyle benzer koruma elde edebilirsiniz
      Source distribution’ları tamamen engelliyor ve yalnızca wheel kuruyor
      Ama bunun bazı sürüm kısıtları olabilir
      uv içinde --exclude-newer seçeneğiyle PNPM’in “minimum release age” özelliği taklit edilebilir
    • Yakın zamanda “dependency cooldown” ile ilgili bir yazı gördüm ve çok katıldım
      Ben tüm dependency’leri sabitliyorum ve dependabot bildirimlerini manuel inceliyorum
      Bunun aşırı mı yoksa doğru bir alışkanlık mı olduğundan hâlâ emin değilim

  • Bugün özellikle ilgili bir yazı var: “We should all be using dependency cooldowns”
    Otomatik dependency güncellemeleri, bir günlük bir açıktan daha tehlikeli olabilir
    Çünkü zaten binlerce lockfile’a yayılmış bulaşmış paketleri geri almak çok daha zor

    • Bence en iyisi yalnızca gerçekten gerektiğinde güncellemek
      Bir şey düzgün çalışıyorsa durduk yere dokunmaya gerek yok
    • Ama bunu yapsanız bile yine başka birinin bug’ı düzeltmesi gerekir ve herkes cooldown kullanırsa sonuçta olduğumuz yerde sayabiliriz
    • Python’un uv aracında uv lock --exclude-newer $(date --iso -d "24 hours ago") komutuyla benzer bir etki elde edilebilir
      İlgili tartışma issue #14992 içinde var
    • npm-check-updates ile de kolayca yapılabiliyor
      npx npm-check-updates -c 7 komutuyla 7 günlük cooldown ayarlanabilir
      Ayrıntılar için npm-check-updates dokümanı
    • Bu mantığa katılmıyorum
      Cooldown, 0-day açıkların yayılma süresini uzatabilir
      Herkes aynı cooldown’ı kullanırsa sadece tespit gecikmesi yaratır

  • PostHog kurucu ortaklarından biriyim
    Bu saldırının mağdurlarından biriydik
    Bulaşmış sürümler posthog-node 4.18.1, 5.13.3, 5.11.3 / posthog-js 1.297.3 / posthog-react-native 4.11.1 / posthog-docusaurus 2.0.6
    Anahtarların ve parolaların hepsini değiştirdik, ayrıca yeni sürümler yayınladık
    Kök neden analizi yapıyoruz ve status.posthog.com üzerinde güncelleme paylaşacağız

    • Yeni paket sürümleri CI/CD çalışmalarıyla ilişkili değilse alarm üretecek şekilde ayarlamanızı tavsiye ederim
    • Bulaşmış JS’nin gerçek kullanıcıları etkileyip etkilemediğini merak ediyorum
      Eğer web sitesi bulaşmış sürümü dağıttıysa ziyaretçilere zarar verip vermediğini bilmek isterim
    • Sebep bilinmiyorsa saldırının hâlâ yayılıyor olma ihtimali de var
    • En son sürüm yine bulaşmış olabilir; o halde insanların bu kez neden güvenmesi gerektiği soru işareti
    • Buradaki güncellemenin Twitter duyurusundan daha görünür olması iyi. Umarım toparlanırsınız

  • Ciddi bir soru: Node ile yeni proje başlatmak doğru mu
    Astro ile bir SaaS frontend’i yapıyorum ve dependency güncellemesi yaparken her seferinde tedirgin oluyorum
    npm ekosistemindeki güvenlik eksikliği fazla ciddi hissettiriyor

    • Sorun Node ya da JS değil, paketleme modeli
      Rust gibi sayısız alt pakete bağımlı ekosistemler de bir gün aynı şeyi yaşayacaktır
      C, C++ ya da Odin gibi package manager olmayan yaklaşımlar güvenlik açısından daha akıllıca olabilir
    • Bence sorun Node’dan çok npm’in kendisi
      Son zamanlarda Deno’nun JSR yapısına daha çok güveniyorum
      JSR tabanlı paketler npm’e de çapraz olarak yayınlanıyor ve Deno’ya özel paketler de var
      Örneğin Lume yavaş ama istikrarlı bir SSG olarak etkileyiciydi
    • Bu sadece Node’a özgü bir sorun değil
      npm en büyük repository olduğu için saldırganlar açısından sadece daha değerli
      Aynı şey RubyGems ya da Cargo’da da rahatlıkla olabilir
    • Node’dan kaçınalım görüşü abartılı
      Sadece en çok kullanılan ekosistem olduğu için saldırılar oraya yoğunlaşıyor
      Dependency’leri dikkatli yönetin, her gün update etmeyin, yeter
    • Biz ürün güvenliği analiz platformumuzu PHP ile geliştirdik
      Sayfa render etmek için 100’den fazla dependency gerekmemesi önemli bir avantaj
      Proje bağlantısı

  • Bu aralar tüm geliştirmeyi sadece Podman container içinde yapıyorum
    Okumadığım kodu mutlaka izole bir ortamda çalıştırıyorum
    Mükemmel değil ama en azından temel bir güvenlik alışkanlığı bence

    • Çoğu insan için vakaların %99,99’unda sorun çıkmadığından risk algısı köreliyor
      Güvenlik genelde uzmanlara devredilen bir alan olduğu için bunu pratikte değiştirmek zor
    • npm paketlerinin dependency ağacı çok derin; böyle durumlarda container izolasyonunun nasıl çalıştığını merak ediyorum
    • PostHog SDK gibi npm paketlerini container içinde nasıl kullandığınıza dair somut yöntemi merak ediyorum
    • Podman, Docker’dan daha güvenli ve gerekirse QEMU gibi ek izolasyon katmanları da düşünülebilir
    • Ben doğrudan farklı bir yerel kullanıcıyla SSH yapıp tmux içinde geliştiriyorum

  • 12 yıl önce NPM bir kez tamamen çökmüştü
    O zamanlar yalnızca bir açık kaynak projesiydi ama şimdi Microsoft’un elinde
    Dünyanın en büyük şirketlerinden biriyse bu tür sorunları çözmesi gerekmez mi?
    Ama hâlâ pek bir şey değişmiş değil

    • MS, Windows’u bile düzgün yönetemiyor
      Enterprise lisansıyla para getirmeyen şeyleri ihmal ediyor
      Bu yüzden Windows 11 daha çok bir pazarlama paketi gibi geliyor

  • Şu anda saldırı faaliyetini izliyoruz ve bulaşmış paket listesini Wiz blogunda güncelliyoruz
    Kötü amaçlı payload’u reverse engineer ediyoruz ve birkaç saat içinde sonuçları paylaşmayı planlıyoruz

  • PostHog’un “Talk to a human” sohbeti gerçekte robot yanıtları verdiği için rahatsız ediciydi
    Acil destek bağlantısı da düzgün yönlendirmiyor
    O yüzden sormak istiyorum — hangi sürümlerden kaçınmalıyız?

    • Kurucu ortaklardan biriyim. Ana başlıkta ve status.posthog.com üzerinde zaten duyurduk
      Bulaşmış sürümler posthog-node 4.18.1, 5.13.3, 5.11.3 / posthog-js 1.297.3 / posthog-react-native 4.11.1 / posthog-docusaurus 2.0.6
      En son sürüme güncellerseniz güvendesiniz
    • Slack kanalında da aynı sürüm listesinin paylaşıldığını gördüm

  • Bu paket karmaşasının neden hep Node ekosisteminde yaşandığını merak ediyorum
    Bu topluluğun neden karmaşık install hook’larını ve otomatik güncellemeleri iyi mühendislik saydığını anlamıyorum
    Node’un yaratıcısının neden çoktan ayrıldığını anlıyorum

    • Node yeni PHP gibi
      Devasa bir ekosistem, acemi geliştirici ağırlığı, düşük güvenlik farkındalığı ve en küçük işlev için bile kütüphane bağımlılığı
    • Ciddi bir ekosistemde paket maintainers olmalı
      Debian’daki gibi güvenilir bakımcılar doğrulama yapmalı ama JS topluluğu bunu gatekeeping diye reddediyor
      Bu yüzden bu tür olaylar tekrar tekrar yaşanıyor
    • Başkalarını küçümseyip bununla üstünlük hissetmek kısa sürer
      Böyle bir tavırla hiçbir şey değişmez

  • Konudan biraz sapacağım ama HelixGuard’ın kim olduğunu merak ediyorum
    Web sitesi berbat ve neredeyse hiç bilgi yok
    Müşterileri bir kripto borsasıymış gibi görünüyor, bu da biraz şüpheli
 
laeyoung 2025-11-25

2️⃣ Yeni bir sürüm yayımlandıktan sonra belirli bir süre (ör. 4 gün) geçmeden kurulmayacak şekilde ayarlanabiliyor.

Çok iyi bir özellikmiş. Google da bazen hatalı ya da çalışmayan sürümleri NPM'e yüklüyor; o zaman da sorun bende mi diye paniklediğim oluyor.