GitLab, Yaygın NPM Tedarik Zinciri Saldırısını Tespit Etti

 (about.gitlab.com)
1 puan yazan GN⁺ 2025-11-29 | 1 yorum | WhatsApp'ta paylaş
  • npm ekosistemi genelinde yıkıcı kötü amaçlı yazılım varyantları yayılıyor ve GitLab güvenlik ekibi bunu tespit etti
  • Kötü amaçlı yazılım, Shai-Hulud'un evrimleşmiş bir biçimi; enfekte geliştiricinin diğer paketlerini de otomatik olarak bulaştıran solucan benzeri yayılma yapısına sahip
  • GitHub, AWS, GCP, Azure vb. ortamlardan kimlik bilgileri çalındıktan sonra veriler, saldırganın kontrolündeki GitHub depolarına sızdırılıyor
  • GitHub ve npm erişimi aynı anda engellenirse kullanıcı verilerini anında silen bir “deadman switch” içeriyor
  • GitLab, kendi sistemlerinin enfekte olmadığını doğruladı ve Dependency Scanning ile GitLab Duo Chat üzerinden tespit ve müdahale yöntemleri sundu

Saldırıya genel bakış

  • GitLab Vulnerability Research ekibi, npm ekosisteminde büyük ölçekli bir tedarik zinciri saldırısı tespit etti
    • Dahili izleme sistemi birden fazla enfekte paketi keşfetti
    • Kötü amaçlı yazılımın Shai-Hulud varyantı olduğu doğrulandı
  • Kötü amaçlı yazılım, solucan benzeri yayılma yoluyla enfekte geliştiricinin diğer paketlerine de otomatik olarak bulaşıyor
  • GitLab, kendi bünyesinde kötü amaçlı paketler kullanmadığını doğruladı ve bilgileri güvenlik topluluğuyla paylaştı

Saldırının iç yapısı

  • Dahili izleme sisteminin tespit ettiği kötü amaçlı npm paketleri şu işlevleri yerine getiriyor
    • GitHub, npm, AWS, GCP ve Azure'dan kimlik bilgisi toplama
    • Ele geçirilen verileri saldırgan kontrolündeki GitHub depolarına gönderme
    • Kurbanın diğer paketlerini otomatik olarak enfekte etme
    • Altyapıya erişim engellenirse yıkıcı payload çalıştırma
  • Birden fazla enfekte paket doğrulandı ve soruşturma sürüyor

Teknik analiz: saldırının işleyişi

İlk enfeksiyon vektörü

  • Kötü amaçlı yazılım sisteme çok aşamalı bir yükleme süreciyle sızıyor
    • Enfekte paketin package.json dosyasına setup_bun.js betiği ekleniyor
    • Görünüşte Bun JavaScript runtime'ını kurmak için gizlenmiş durumda
    • Gerçekte ise bun_environment.js (10MB, obfuscate edilmiş payload) çalıştırılıyor
  • Küçük bir loader dosyası ve büyük bir obfuscate payload kombinasyonuyla tespitten kaçıyor

Kimlik bilgisi toplama

  • Çalıştırıldığı anda çeşitli kaynaklardan token ve gizli bilgileri topluyor
    • GitHub token'ları (ghp_, gho_)
    • AWS, GCP, Azure kimlik bilgileri
    • npm token'ları (.npmrc ve ortam değişkenleri)
    • Trufflehog aracıyla tüm home dizinini tarayarak API anahtarları, parolalar, Git geçmişi vb. bilgileri arıyor

Veri sızdırma ağı

  • Ele geçirilen GitHub token'larıyla açıklamasında “Sha1-Hulud: The Second Coming.” bulunan herkese açık depolar oluşturuyor
    • Bu depolar veri bırakma kutusu işlevi görüyor
    • Kalıcılık için GitHub Actions runner kuruluyor
  • Yetki yetersiz olduğunda, aynı işareti taşıyan diğer depoları arayarak başka sistemlerin token'larını yeniden kullanıyor
    • Böylece dağıtık bir token paylaşım ağı oluşuyor

Tedarik zinciri boyunca yayılma

  • Ele geçirilen npm token'larıyla kurbanın tüm paketleri enfekte ediliyor
    1. Orijinal paketi indirme
    2. setup_bun.js dosyasını preinstall script'i olarak ekleme
    3. bun_environment.js payload'unu ekleme
    4. Sürüm numarasını artırma
    5. Enfekte paketi npm'e yeniden yayımlama

Deadman switch

  • Kötü amaçlı yazılım GitHub'a (veri sızdırma) ve npm'e (yayılma) erişimi sürekli izliyor
    • Her iki kanal da engellenirse hemen veri imhası başlatıyor
  • Windows: kullanıcı dosyalarını silme ve disk sektörlerinin üzerine yazma
  • Unix türevleri: shred komutuyla dosyaların üzerine yazıp ardından silme
  • GitHub depolarının topluca silinmesi veya npm token'larının toplu olarak iptal edilmesi durumunda, enfekte sistemlerin aynı anda veri silme işlemi yapma riski bulunuyor

İhlal göstergeleri (IoC)

  • Başlıca tespit göstergeleri
    • Dosya: bun_environment.js (kötü amaçlı post-install script'i)
    • Dizin: .truffler-cache/, .truffler-cache/extract/
    • Süreçler: del /F /Q /S "%USERPROFILE%*", shred -uvz -n 1, cipher /W:%USERPROFILE%
    • Komutlar: curl -fsSL https://bun.sh/install | bash, powershell -c "irm bun.sh/install.ps1|iex"

GitLab'in tespit ve müdahale desteği

  • GitLab Ultimate kullanıcıları, yerleşik güvenlik özellikleriyle maruziyet durumunu hemen kontrol edebilir
    • Dependency Scanning etkinse package-lock.json veya yarn.lock içindeki enfekte paketleri otomatik olarak tespit eder
    • Enfekte paket içeren merge request'lerde uyarı gösterilir
  • GitLab Duo Chat entegrasyonuyla sorgu tabanlı hızlı tespit yapılabilir
    • Örnek: “Shai-Hulud v2 kampanyasından etkilenen bağımlılıklar var mı?”
    • Security Analyst Agent, proje zafiyet verilerini sorgulayıp doğrudan yanıt verir
  • Birden fazla depo yöneten ekipler için CI/CD tabanlı otomatik tespit ile ajan tabanlı hızlı müdahalenin birlikte kullanılması öneriliyor

Geleceğe bakış

  • Bu saldırı, saldırı altyapısını korumak için kurban verilerini yok etmeyi kullanan yeni bir tedarik zinciri saldırısı biçimi olarak değerlendiriliyor
  • GitLab, toplulukla iş birliği içinde güvenli kurtarma stratejileri geliştiriyor ve otomatik tespit sistemleriyle varyantları sürekli izliyor
  • Amaç, erken bilgi paylaşımı sayesinde deadman switch kaynaklı ikincil zararları önlemek

İlgili okumalar

1 yorum

 
GN⁺ 2025-11-29
Hacker News yorumları

  • Yaklaşık bir ay önce can sıkıcı bir iş yapmam gerekti ve bir NPM paketi aradım
    brew install npm komutunu çalıştırınca bağımlılık şelalesi üzerime aktı; bir an durup riskleri ve getirileri düşündüm, sonra sonunda brew uninstall npm ile geri aldım
    Bunun yerine eski bir Unix yardımcı programı boru hattı ve awk ile çözdüm; şimdi dönüp bakınca verdiğim en iyi kararlardan biri buydu

    • Ders çok açık — yerel betikleme için web teknolojileri kullanılmamalı
      NPM, tarayıcı uyumluluğu sorunlarını çözmek için yapılmış bir araç; tarayıcının olmadığı ortamlarda gereksiz karmaşıklık yaratıyor
    • İşte bu yüzden kapsayıcılaştırma veya sanallaştırma gerekli
      Node ya da Python gibi bağımlılığı bol ekosistemlerin kodunu ana sistemde doğrudan çalıştırmak, tedarik zinciri saldırılarına maruz kalma riskini artırıyor
      Bu yüzden ben varsayılan sisteme Python ya da JS yorumlayıcısı kurmuyorum
    • Ben de eskiden npm'i yalnızca Docker konteyneri içinde çalıştırırdım, ama forumlarda sık sık bununla dalga geçilirdi
      Sonunda vazgeçtim ama şimdi bakınca doğru olan oymuş gibi geliyor
    • Benim de benzer bir deneyimim oldu. artillery'nin çekmek istediği bağımlılık sayısını görünce hemen vazgeçtim
    • İronik olan şu ki geliştiriciler sürekli “sağduyu en iyi güvenliktir” derken, doğrulanmamış sayısız paketi tek satırlık bir komutla kuruyor

  • “GitHub kötü amaçlı depoları topluca silerse, binlerce sistem aynı anda kullanıcı verilerini yok edebilir” denmişti,
    Bu biraz rehine krizine benziyor — bu yüzden “rehineyi vur” şakası yapıldı

    • Ama rehine (kullanıcı) aslında kendi isteğiyle bu riske girmiş durumda, yani sonuçta bu kendi seçiminin sonucu

  • Ben de bu npm saldırısının kurbanlarından biriyim
    GitHub CLI'ın HOME dizininde düz metin OAuth token'ı sakladığını öğrenince şoke oldum
    Bir saldırgan buna erişse hesabımla neredeyse her şeyi yapabilirdi

    • Aslında GitHub CLI token'ı yalnızca keyring yoksa düz metin olarak saklıyor
      macOS'ta güvenli biçimde işletim sistemi anahtar zincirinde tutuluyor — ilgili tartışma
    • Doğru, ama tarayıcı çerez dosyalarında da benzer bir sorun var
      Chrome işletim sistemi koruma özelliklerini kullanıyor ama Firefox hâlâ kullanmıyor
      Sonuçta asıl çözüm sandbox tabanlı erişim denetimi
    • Tüm token'lar korumalı bir anahtar zincirinde olmalı
      Ama platformlar arasında tutarlı bir çözüm yok ve macOS'ta bile kusursuz bir yöntem bulunmuyor
    • Ben de mağdurum. Backstage kurulumundan sonra enfekte oldum
      ~/.dev-env dizini oluştu ve dizüstü bilgisayarım bir GitHub runner'ına dönüştü
      Bluefin Linux'un salt okunur dosya sistemi sayesinde hasar azalmış olabilir

  • Herkes sadece npm'i suçluyor ama GitHub'ın da sorumluluğu büyük
    Kötü amaçlı depoları yeterince hızlı tespit edemedi ve zararlı yazılım deposu sorunu zaten ciddi boyutta

    • Yine de GitHub'a yüklenmiş olması sayesinde zararı çabuk fark edenler oldu
      Eğer gizlice harici bir sunucuya gönderilseydi çok daha korkunç olurdu
    • Microsoft her şeyi filtreleyemez
      Topluluk düzeyinde araçlara ve uygulamalara ihtiyaç var
    • GitHub, Microsoft'un sahipliğinde olduğu için GoLang paket deposu ile de iç içe
      Ticari düzenleme ya da build iş akışı kısıtları gelirse bu büyük bir soruna dönüşebilir
    • Her iki şirketin de güvenlik seviyesinin sıradan olduğunu inkâr etmek zor
    • Bu kötü amaçlı yazılım depoları aynı kalıpla oluşturuyor, dolayısıyla basit kurallarla bile tespit edilebilirdi

  • Neden hep NPM'in hedef alındığını merak ediyordum
    Python ya da Java da çok popüler ama son zamanlarda sessizler

    • NPM'de post-install hook sayesinde rastgele komutlar çalıştırılabiliyor ve
      sürüm aralığı bağımlılığı kültürü nedeniyle enfeksiyon hızla yayılıyor
      Java'da belirli sürümlere sabitlemek yaygın olduğundan bu tür olaylar daha nadir
    • Node'un standart kütüphanesi küçük ve topluluğa bağımlılığı yüksek
      Bu yüzden tek bir paket onlarca alt bağımlılığı beraberinde getiriyor
    • JS, GitHub'daki en popüler dil olduğu için saldırı yüzeyi geniş ve
      deneyimi az geliştirici sayısı fazla olduğundan güvenlik zayıf kalıyor
    • JS topluluğunda ciddi bir “en son sürüm takıntısı” var
      Diğer dil ekosistemleri güncellemeyi doğruladıktan sonra yaparken, JS tarafında hemen yükseltme yapılıyor
    • NPM'in güvenlik sınırları zayıf
      Kurulum sırasında betikleri serbestçe çalıştırabiliyor; JVM ya da Python tarafı böyle değil

  • .npmrc dosyasına

    ignore-scripts=true

    eklemek saldırı vektörünü azaltabilir
    ilgili yazı

    • Kurulumdan önce preinstall/postinstall hook içeren paketleri önceden görmenin bir yolu olup olmadığını merak ediyorum
    • “ignore scripts” güvenliyse neden bir seçenek olarak var,
      devre dışı bırakıldığında bağımlılıkların bozulması riski yok mu, diye de düşünüyorum
    • Ama sonuçta Node ortamında JS çalıştırıyorsanız ortam değişkenlerine ya da dosyalara erişimi engelleyemezsiniz
    • Ya da doğrudan pnpm kullanmak da bir yöntem olabilir

  • Bu saldırıda beni en çok endişelendiren şey kimlik bilgilerinin çalınması
    Enfekte paketi kurduysanız ortam değişkenleriniz ya da .npmrc token'larınız sızdırılmış olabilir
    Token'ları ve API anahtarlarını derhal döndürmek gerekir
    Düzenli döndürme, ihlal sonrası müdahale değil, önleyici bir tedbirdir

    • Eğer geliştirici parolaları yeniden kullanıyorsa bu gerçekten çok ciddi bir sorun
      Kimlik bilgileri ortam değişkenlerinde ya da dosyalarda saklanmamalı; güvenlik anahtarı veya şifrelenmiş dosyalar kullanılmalı
    • Enfekte olup olmadığınızı bilmiyorsanız önce enfeksiyon tespiti → temizlik → token döndürme sırasıyla ilerlemelisiniz
    • Bu saldırı basit bir enfeksiyon değil, tüm ekosistemi rehin alma biçiminde olduğu için daha tehlikeli
      Biraz dağıtık deftere kötü amaçlı işlem yerleştirmeye benziyor
    • Sırlar mutlaka güvenli bir secret locker içinde tutulmalı
      Sorun, hâlâ birçok hizmetin varsayılan olarak düz metin saklaması
    • Ayrıca bu kötü amaçlı yazılım, yayılma durursa veri yok etmeye de çalışıyor

  • Bu tür saldırılar tekrar edip dururken neden yapay zeka tabanlı tespit sistemlerinin çalışmadığını merak ediyorum
    Microsoft yapay zekayı bu kadar öne çıkarıyor ama GitHub güvenliğinde kullanmıyor gibi görünüyor

    • Ama “AI saldırıyı tespit etti” söylemi zaten güvenlik pazarlamasının klişesi haline geldi
      Güvenlik duvarının engellediği her denemeye saldırı dendiği dönem gibi, anlamı aşınmış durumda
    • Bizim şirket SonaType Lifecycle kullanıyor; bunun yapay zeka tabanlı olarak bu tür saldırıları durdurduğunu söylüyorlar
      İçeride bunu SonaType IQ Server destekliyor
    • Günümüzdeki “AI” aslında üretken modeller; odakları değerlendirmeden çok üretim
      Nitekim curl projesinin AI üretimi güvenlik raporu spam'i ile uğraştığı bir örnek de var

  • postinstall script'lerine izin vermek için hâlâ bir gerekçe olup olmadığını merak ediyorum
    Kullanıcıya çalıştırılsın mı diye sormak daha iyi olmaz mı?

    • Ama kullanıcıların çoğu “evet” diyecektir ve
      CI sunucularında etkileşimsiz kurulum gerektiği için bunun pratikte zor olduğunu düşünüyorum

  • Yazı çok içgörülüydü ama sonunda GitLab güvenlik özellikleri reklamıyla bitmesi biraz hayal kırıklığı yarattı

    • GitLab kullanıcıları için yine de faydalı olmuş olabilir
    • Yine de bu, yazının içgörüsünün kendisini azaltmıyor