npm Tedarik Zinciri Saldırısında 300’den Fazla Paket Zehirlendi

Anasayfa » npm Tedarik Zinciri Saldırısında 300’den Fazla Paket Zehirlendi
npm Tedarik Zinciri Saldırısında 300’den Fazla Paket Zehirlendi

npm ekosistemini hedef alan yeni bir tedarik zinciri saldırısı, çok sayıda açık kaynak paketinin ele geçirilmiş bakımcı hesapları üzerinden zararlı sürümlerle güncellenmesine yol açtı. Etkilenen paketler arasında veri görselleştirme, grafik çizimi, haritalama ve React bileşenleri için yaygın kullanılan kütüphaneler bulunuyor; bu da özellikle yazılım ekipleri, SaaS sağlayıcıları, kurumsal geliştirme ortamları ve otomatik bağımlılık güncellemesi yapan CI/CD hatları için risk oluşturuyor.

Saldırı, kısa sürede yüzlerce pakete yayılan ve kimlik bilgisi çalmaya odaklanan bir yük taşıyor. Analizler, bunun daha önce görülen “Mini Shai-Hulud” tarzı bir kampanyanın devamı olduğunu gösteriyor: ele geçirilmiş bir bakımcı hesabı kullanılıyor, paketler hızla trojanize ediliyor ve ardından aynı zincir başka paketlere de sıçrayabiliyor. Bu nedenle olay yalnızca tek bir paket ailesiyle sınırlı değil; açık kaynak bağımlılıklarını otomatik çeken kurumların tamamı potansiyel hedef konumunda.

Saldırının Genel Çerçevesi

İlk bulgular, saldırganın bakımcı kimlik bilgilerini ele geçirerek npm üzerinde toplu yayın yaptığını ortaya koyuyor. Etkilenen paketler arasında @antv ekosistemine ait çok sayıda bileşen ile echarts-for-react, timeago.js, size-sensor ve canvas-nest.js gibi yaygın kullanılan bağımlılıklar yer alıyor. Bu paketlerin bir kısmı doğrudan uygulamalarda, bir kısmı ise dolaylı bağımlılık olarak kullanıldığı için etki alanı görünenden daha geniş olabilir.

Bu tür olaylarda asıl risk, tek bir geliştirici hesabının ele geçirilmesinin kurumsal yazılım zincirine toplu şekilde sızma imkânı vermesidir. Özellikle npm install, CI job’ları, build pipeline’ları ve container image üretim süreçleri otomatik çalışıyorsa, zararlı sürüm çok kısa sürede üretim ortamına kadar ulaşabilir.

Saldırı Zinciri ve Teknik Detaylar

İncelemelere göre zararlı sürümler, kurbanın ortamından çok sayıda kimlik bilgisi toplamaya çalışıyor. Hedeflenen varlıklar arasında AWS, Google Cloud, Microsoft Azure, GitHub, npm, SSH, Kubernetes, Vault, Stripe ve veritabanı bağlantı dizeleri bulunuyor. Zararlı kod ayrıca host socket üzerinden konteyner kaçışı denemesi yaparak Docker ortamlarına erişmeye çalışıyor.

Bu davranışlar, MITRE ATT&CK açısından birkaç tekniğe karşılık geliyor: kimlik bilgisi toplama, bulut ortamlarında erişim kötüye kullanımı, CI/CD boru hatlarının istismarı, yazılım tedarik zinciri manipülasyonu ve kalıcılık için geliştirme araçlarının içine yerleştirilen hook’lar. Özellikle preinstall aşamasına eklenen komutlar, paket kurulur kurulmaz zararlı kodun çalışmasını sağlıyor.

Gözlemlenen bir başka unsur da npm yayın sürecinin otomatikleştirilmiş olması. Saldırganın ele geçirilen token’ları doğruladıktan sonra bakımcının yönettiği paketleri listelediği, paket arşivlerini indirdiği, zararlı yükü eklediği, sürüm numarasını artırdığı ve yeniden yayımladığı anlaşılıyor. Bu, manuel bir müdahaleden çok, hız ve ölçek için tasarlanmış bir otomasyon zincirine işaret ediyor.

Veri Sızıntısı ve Kalıcılık Mekanizması

Toplanan veriler önce serileştiriliyor, ardından sıkıştırılıp şifreleniyor ve saldırganın kontrolündeki bir alan adına gönderiliyor. Yedek mekanizma olarak ise çalınan GitHub token’ı kullanılarak kurban hesabı altında herkese açık bir depo oluşturuluyor ve veriler JSON dosyası olarak buraya yazılıyor. Bu yaklaşım, ağ çıkış filtrelerini aşmak veya doğrudan dışarı veri gönderemeyen ortamlarda ikinci bir sızıntı kanalı sağlamak için kullanılıyor olabilir.

Depo açıklamalarında ters çevrilmiş bir ifade kullanılması, kampanyanın daha önceki Shai-Hulud izlerini taşıdığını gösteriyor. Güvenlik ekipleri, GitHub üzerinde bu işaretleri taşıyan binlerce depo tespit edildiğini bildiriyor. Bu durum, olay müdahale ekipleri için yalnızca paketleri değil, aynı zamanda GitHub organizasyonlarını, CI runner’larını ve erişim token’larını da inceleme zorunluluğu doğuruyor.

Sigstore ve Sahte Provenance Riski

Yeni sürümlerde dikkat çeken bir diğer unsur, Sigstore tabanlı attestation akışının kötüye kullanılması. Saldırgan, CI ortamında yeni üretilmiş bir OIDC token ile meşru sertifikalar üzerinden artefakt imzalama girişiminde bulunabiliyor. Bu da SLSA provenance kayıtlarını manipüle ederek zararlı bir sürümün güvenilir bir yayın gibi görünmesine neden olabiliyor.

Bu nokta özellikle bulut güvenliği ve yazılım bütünlüğü açısından kritik. Çünkü birçok kurum, imzalı artefaktları güvenilir kabul eden otomasyon kurallarına sahip. Eğer imza süreci yetkisiz bir CI koşusunda tetiklenirse, doğrulama mekanizması teknik olarak geçerli görünen ama operasyonel olarak yetkisiz bir sürümü kabul edebilir.

Kurumsal Ortamlarda Olası Etki

Bir e-ticaret şirketi düşünelim: frontend uygulaması React bileşenleri, grafik kütüphaneleri ve yardımcı npm paketleri üzerinden derleniyor. Eğer build pipeline’ı güncel bağımlılıkları otomatik çekiyorsa, zararlı sürüm bir sonraki deploy sırasında üretim ortamına taşınabilir. Ardından GitHub token’ları, cloud erişim anahtarları veya veritabanı bağlantı dizeleri sızdırılabilir.

Benzer şekilde bir SaaS sağlayıcısında CI/CD runner’ları, container registry erişimleri ve Kubernetes secret’ları hedef alınabilir. Bu nedenle olay yalnızca geliştirici makineleri için değil; IAM, secrets management, ağ segmentasyonu ve olay müdahale süreçleri açısından da değerlendirilmelidir.

SOC ve Sistem Yöneticileri İçin Kontrol Listesi

1) npm, GitHub ve cloud erişim token’larını derhal gözden geçirin; şüpheli kullanım varsa rotasyon uygulayın.

2) CI/CD log’larında beklenmeyen preinstall, postinstall ve bun run index.js benzeri çağrıları arayın.

3) EDR üzerinde node, npm, bun, curl, wget ve tar süreçlerinin olağandışı ağ bağlantılarını izleyin.

4) GitHub organizasyonlarında yeni açılan public repository’leri ve açıklamalarda Shai-Hulud benzeri dizeleri tarayın.

5) Kubernetes, Vault ve cloud IAM günlüklerinde kısa sürede çoklu kimlik doğrulama denemelerini inceleyin.

6) Paket bağımlılıklarını sabitleyin, lockfile bütünlüğünü doğrulayın ve otomatik major/minor güncellemeleri sınırlayın.

7) Container ortamlarında host socket erişimini kısıtlayın ve gereksiz Docker socket mount kullanımını kaldırın.

8) SIEM üzerinde npm registry, GitHub API ve cloud provider API çağrıları için anomali kuralları oluşturun.

Ne Yapılmalı?

Bu olay, açık kaynak bağımlılıklarının yalnızca teknik değil, aynı zamanda operasyonel bir güvenlik riski olduğunu bir kez daha gösteriyor. Kurumlar, e-posta güvenliği, bulut güvenliği, ağ segmentasyonu ve olay müdahale süreçlerini birlikte ele almalı; yalnızca uç nokta korumasına güvenmemeli. Özellikle geliştirici hesaplarında çok faktörlü kimlik doğrulama, kısa ömürlü token kullanımı ve least privilege yaklaşımı kritik önem taşıyor.

Ayrıca yazılım tedarik zinciri için güvenilirlik kontrolleri güçlendirilmeli. İmzalı paketler tek başına yeterli kabul edilmemeli; build provenance, CI runner kimliği, artifact kaynağı ve bağımlılık ağacı birlikte doğrulanmalı. Bu yaklaşım, hem sahte sürümlerin hem de zincirleme bulaşmaların etkisini azaltabilir.

Son olarak, güvenlik ekiplerinin yalnızca zararlı paketi kaldırmakla yetinmemesi gerekiyor. Ele geçirilmiş token’ların nerede kullanıldığı, hangi pipeline’ların etkilendiği, hangi depolara veri yazıldığı ve hangi container’ların dışa bağlantı kurduğu ayrıntılı biçimde incelenmeli. Bu tür kampanyalarda bir ihlal, çoğu zaman bir sonrakini tetikleyen başlangıç noktası oluyor.