ChainDrop Bir Patch Sürümüne Bindi. Patch Sürümleri Beklesin.

Microsoft, 4 Ağustos'ta ChainDrop analizini yayımladı. ChainDrop, Microsoft'un Mini Shai-Hulud varyantı dediği bir şeyi yayan bir tedarik zinciri kampanyası: kendi kendine yayılan ve kimlik bilgisi çalan bir solucan. Birbiriyle ilgisi olmayan yayıncılara ait 400'den fazla npm paketi ele geçirildi. Aralarında keyv, flat-cache ve cache-manager da var. En önemli detay şu: zararlı sürümler, sıradan patch sürümleri gibi görünerek geldi.

ChainDrop nasıl yayılıyor#

• Bir preinstall lifecycle script'i, paketin içinde gelen setup.mjs dosyasını çalıştırıyor. Bu dosya da Bun runtime üzerinde büyük ve yoğun şekilde obfuscate edilmiş bir JavaScript bundle'ı başlatıyor.
• Geliştirici makinelerinde kendini ayırıp arka planda çalışmaya devam ediyor. CI'da ise job'ın içinde kalıyor; orada workflow secret'larına, runner kimlik bilgilerine ve OIDC yayınlama yetkilerine erişebiliyor.
• Yerel dosyalardan, ortam değişkenlerinden, komut satırı araçlarından ve runner belleğinden kimlik bilgilerini topluyor, sonra bunları npm, GitHub, AWS, Kubernetes ve HashiCorp Vault'a karşı kullanıp daha fazla secret çekiyor. Microsoft'un hunting sorguları, Bun'ın gh auth token, gcloud config config-helper ve az account get-access-token çağırmasını işaretliyor.
• Çalınmış bir npm yayınlama token'ı ele geçirdiğinde, o kimliğin erişebildiği paketleri listeliyor, en son tarball'larını indiriyor, kendini içlerine ekliyor, patch sürümünü artırıyor ve yeniden yayımlıyor.

Ayrı bir yol da npm trusted publisher olarak yapılandırılmış GitHub Actions workflow'larını hedefliyor. Bu şekilde yayımlanan paketler geçerli provenance taşıyabiliyor, çünkü yayın gerçekten de meşru bir workflow kimliğinden yapılmış oluyor.

Saldırı yüzeyi patch sürümün kendisi#

Microsoft, zararlı sürümlerin çoğunun karşılığında bir kaynak commit, pull request, tag ya da meşru bir release olmadığını tespit etti; saldırganlar değiştirilmiş tarball'ları doğrudan yayımlamış.

Caret aralıkları bu tür bir sürümü sorgusuz sualsiz kabul ediyor: bir kurulumun bağımlılıkları yeniden çözmesine izin verildiği anda, ^1.2.0 yayımlanır yayımlanmaz 1.2.1'i alıyor. Commit edilmiş bir lockfile sizi zaten sahip olduğunuz sürümlerde tutar, ama yalnızca kurulumlar ona uyduğu sürece: npm ci tam olarak lockfile'da yazanı kurar ve package.json ile uyuşmazlık varsa hata verir; öte yandan dikkatlice incelenmeden commit edilen gelişigüzel bir npm update her şeyi bir anda yeniden çözer.

Provenance size bir paketi hangi workflow'un yayımladığını söyler, o workflow'un temiz olduğunu değil. Artık onu tek başına bir güvenlik sinyali olarak görmüyorum.

Yeni temel ayarlar#

npm 12, 8 Temmuz'da genel kullanıma açıldı ve GitHub'ın changelog'u neyin değiştiğini sıralıyor: bağımlılıkların preinstall, install ve postinstall script'leri ile örtük node-gyp build'leri açıkça izin verilmedikçe artık çalışmıyor; git ve uzak URL bağımlılıkları da izin verilmedikçe artık çözülmüyor. Onaylar package.json içindeki allowScripts alanında tutuluyor ve npm approve-scripts --allow-scripts-pending hâlâ karar bekleyenleri listeliyor.

Gözden kaçması kolay iki detay var. Birincisi, npm ekibinin v12 hazırlık başlığındaki kabul edilmiş cevabın açıkladığı gibi, varsayılan davranış yumuşak bir atlama: onaylanmamış bir script bir uyarıyla atlanıyor ve kurulum yine başarılı oluyor. strict-allow-scripts=true bunu kesin bir hataya çeviriyor; CI'da istediğim de bu. İkincisi, min-release-age v12'de varsayılan değil; başlığın yazarı bunun kullanıcı ya da organizasyon bazında yapılandırılması gerektiğini söyledi. Config dokümanları bu ayarı, yalnızca belirli bir gün sayısından daha önce yayımlanmış sürümleri kurmak olarak tanımlıyor. Microsoft'un ilk önerdiği önlem de aynı ikili: npm 12 artı min-release-age.

Node repolarımız için önerdiğim .npmrc:

min-release-age=3
strict-allow-scripts=true

Üç gün benim tercihim, npm'in bir önerisi değil; önemli olan, yeni bir patch'in herhangi bir build tarafından alınmadan önce beklemesi. Ardından, zaten 12 çalıştırdıklarını varsaymak yerine gerçek CI imajlarınızın içinde npm -v ile kontrol edin.

Agent ve editör yapılandırmaları artık hedefte#

Beklemediğim kısım şu: Microsoft, payload'ın çalınan GitHub kimlik bilgileriyle kendini repo branch'lerine enjekte edebildiğini söylüyor. Hedefte .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json ve .vscode/setup.mjs var; böylece ilk kurulumdan çok sonra bile ileride yapılacak Claude ya da VS Code etkinliği onu yeniden başlatabiliyor. Ben her gün Claude Code ve Codex kullanıyorum ve bu dizinler repoda duruyor. Her iki format da Claude Code hook'ları ya da VS Code task'ları üzerinden otomatik çalışan komutlar tanımlayabiliyor; bu yüzden oradaki bir diff, bir CI workflow diff'i kadar dikkatli incelenmeyi hak ediyor. CODEOWNERS kullanıyorsanız bu dizinleri de ekleyin.

Microsoft ayrıca zararlının tüm process ortam değişkenlerinin değerlerini topladığını söylüyor. Coding agent çalıştıran bir makinede buna genellikle model sağlayıcılarının API anahtarları da dahil. Onları da npm ve cloud token'larının yanına, rotasyon listesine koyun ve uzun ömürlü shell profillerinden uzak tutun.

Ben ne yapıyorum#

Microsoft'a göre, lifecycle script'leri açıkken yapılan bir kurulum etkilenen bir sürümü çektiyse, o geliştirici makinesini ya da build runner'ı potansiyel olarak ele geçirilmiş kabul etmek gerekiyor. Kontrol listesi şöyle: lockfile'ları, bağımlılık ağaçlarını, artifact repolarını ve CI cache'lerini gözden geçirin; bilinen temiz sürümleri sabitleyin; geliştirici makinelerinde ve build host'larında npm ve yarn cache'lerini temizleyin; kimlik bilgilerini temiz bir makineden rotate edin; paylaşılan base imajları ve golden build runner'ları yeniden oluşturun; endpoint telemetrisinde Math_Symbol.js ve Math_init.js gibi kalıntıları arayın.

Geri kalan herkes için pazartesi listem:

• Yerelde ve CI'da npm 12'ye geçin, her repoda npm approve-scripts --allow-scripts-pending çalıştırın, yalnızca gerçekten ihtiyacınız olanı onaylayın ve allowlist'i commit edin.
• Yukarıdaki .npmrc'yi commit edin ve pipeline'larda tek kurulum yolu npm ci olsun.
• Token yetki kapsamlarını gözden geçirin ve yayın workflow'larını protected environment'ların arkasına alın.
• .claude/ ve .vscode/ değişikliklerini çalışan kod gibi ele alın.

Bunların hiçbiri egzotik değil. Bir patch sürümünün düşmanca olabileceğini varsayan bir npm hijyeni; bu haftadan sonra da dürüstçe yapılabilecek tek varsayım bu.