Gerçekten Büyük Bir Tehdidi Atlattık

• Yakın zamanda NPM paket ekosisteminde yaşanan tedarik zinciri saldırısı, aslında çok daha büyük zararlara yol açabilirdi
• Saldırgan, popüler kütüphaneleri kötüye kullanarak zararlı kodu yalnızca kripto para cüzdan adreslerini değiştirme yönünde kullandı
• Bu saldırı, geliştiricilerin iki aşamalı kimlik doğrulama bilgilerini çalmak için sofistike phishing e-postaları üzerinden gerçekleştirildi
• Eğer daha ölümcül bir biçimde kullanılsaydı (ör. API anahtarlarının çalınması gibi), çok büyük çaplı zarar ihtimali vardı
• Tüm bağımlılıkların potansiyel olarak riskli olduğu gerçeği ve bağımlılık ağacının tamamını anlamanın önemi vurgulanıyor

---

Saldırıya genel bakış ve endişeler

• Yakın zamanda en büyük paket ekosistemlerinden biri olan NPM içinde popüler paketler saldırıya maruz kaldı
  • Örnek işlevler: terminal renk işleme, renk adı-RGB eşlemesi, fonksiyon hata ayıklama dekoratörleri, dizi benzeri değerleri tespit eden yardımcı araçlar vb.
• Bu tür genel amaçlı bağımlılıklar çok geniş biçimde kullanılıyor ve koda sızdığında doğrudan production ortamına dağıtılma ihtimali yüksek
• Eğer içine kötü amaçlı proxy, API anahtarı hırsızlığı ya da başka ciddi saldırılar eklenmiş olsaydı, sonuçlar çok daha ağır olabilirdi
• Gerçekte ise bu zararlı kod, çevrim içi cüzdanlarda (ör. MetaMask) yalnızca kripto para ödeme adreslerini değiştirme yöntemiyle çalışıyordu

Phishing saldırısının sofistikeliği

• Saldırının başlangıç noktası çok iyi hazırlanmış bir phishing e-postasıydı
  • NPM kullanıcı adını kullanarak kişiselleştirilmiş bir izlenim veriyordu
  • "Güvenlik için parolanızı ve iki aşamalı kimlik doğrulama bilgilerinizi değiştirin" mesajıyla güven oluşturmaya çalışıyordu
  • NPM'in kendine özgü işleyişiyle birleşince, sıradan bir kullanıcının kolayca kanabileceği bir içerik kurgulanmıştı
  • Belirli bir son tarih vererek aciliyet hissi yaratıyor, yoğunluk içinde dikkatsizce phishing bağlantısına tıklanmasını hedefliyordu
  • Gerçek NPM resmi alan adına benzeyen bir .help alan adı kullanıyordu
• En dikkat çeken kısım, resmi alan adı yerine yalnızca "npmjs.help" kullanılmasıydı
  • Günümüzde çeşitli yeni gTLD'ler (Generic Top Level Domain) bloglarda ve belgelerde yaygın biçimde kullanıldığı için bu da doğal görünebiliyordu

Saldırının potansiyel zararı

• Phishing e-postası, kullanıcının iki aşamalı kimlik doğrulama bilgilerini çaldıktan sonra saldırı kodu ekleyip yeni paket sürümleri yayımlamayı mümkün kılıyordu
• is-arrayish, color-string, color-name gibi son derece yaygın kullanılan önde gelen kütüphaneler hedef alındı
  • Eğer zararlı kod yalnızca kripto para ele geçirmekle kalmayıp API anahtarı hırsızlığına kadar genişletilseydi, ölümcül sonuçlar doğurabilirdi
  • Örneğin OpenAI ve AWS API anahtarlarının kitlesel biçimde sızması gibi, uzun vadeli ve büyük ölçekli zararlar ortaya çıkabilirdi
• Gerçekte enfekte edilen kütüphanelerin çoğu daha çok komut satırı araçlarında kullanıldığından, kripto para hırsızlığı amacı da o ölçüde sınırlı kaldı

Web3 ekosistemini hedef alma ve saldırganın stratejisi

• Bu saldırının ana hedefinin Web3 kullanıcıları (tarayıcı üzerinden ödeme yapanlar vb.) olduğu anlaşılıyor
  • Web3 ile ilgisiz genel amaçlı kütüphaneleri hedef alarak, Web3 ekosisteminde hızlı fark edilme ve engellenme ihtimalinden kaçınıldı
  • Örnek: MetaMask ile entegre çalışan kütüphaneler dikkatle denetlense bile, saldırının metin rengiyle ilgili bir yardımcı araçtan geleceğini öngörmek zordur

Geliştirici ekosistemi için dersler

• Bu vaka, tüm bağımlılık paketlerinin gerçekte zararlı olabileceği gerçeğini vurguluyor
  • Bağımlılık ağacını her zaman tamamen kontrol etmek veya izlemek konusunda pratik sınırlar var
  • Hızlı production dağıtım akışı ve zaman baskısı altında, güvenlik incelemesinin geri planda kalabildiğini gösteriyor
• Bundan sonra projenin tüm bağımlılık yapısını anlamanın ve dikkatli yönetmenin önemi daha da artıyor

Kapanış ve not

• Bu içerik belirli bir kişiyi suçlamak ya da sorumluluk yüklemek amacı taşımıyor; önemli olan herkesin phishing saldırılarına maruz kalabileceğini bilmesi
• Bu yazının yayımlanmasının ardından durum değişmiş olabilir; içerikte hata ya da soru işareti varsa doğrudan doğrulama yapılması gerekir

Tags:

[GN⁺]

Hacker News görüşü

• nx npm tedarik zinciri saldırısı, pek çok şirketin kaçamadığı bir kurşundu; sadece VS Code nx eklentisini kurmak bile npm üzerinden en güncel nx sürümünü otomatik kontrol ediyordu ve Github oturumu (ör. GH CLI ile şirket hesabına giriş) ya da .env dosyasında kritik kimlik bilgileri varsa bunların tamamı sızdırılabiliyordu; bu, bağımlılık sabitlemesini veya güvenlik güncellemelerini iyi yönetseniz bile kaçınamayacağınız bir durumdu; bu ekosistemde temelden daha derin değişikliklere ihtiyaç var; ayrıntılar için resmî güvenlik duyurusuna bakın

  • NPM ile ilgili her şeyden kaçınıyorum; tek istisna olarak typescript compiler kullanıyorum ama Go ile yeniden yazılırsa onu da bırakmayı planlıyorum; Go tarafında minimum sürüm belirtme özelliği var ve indirilen şeyi derleme sürecinde asla çalıştırmaması da çok iyi; NPM tarafında ise kaynağın github ile farklı olduğu çok oluyor ve bunu güvenilmez buluyorum
  • Editör eklentileri, yüksek riskli geliştirme ortamlarında otomatik güncellendiği ve kurulduğu için çok cazip saldırı hedefleri; neden hâlâ tarayıcı eklentilerindeki gibi kötü niyetli aktörlerin kitlesel satın almaları olmadığını merak ediyorum; VsCode ekibinin kötü amaçlı yazılım tespiti için çok çaba harcadığını duydum ama Sublime gibi tüm editörlerde böyle bir doğrulama süreci var mı merak ediyorum
  • Tüm paketleri ve veritabanlarını yerelde tutuyorum ve geliştirme makinesinde uçak modunda çalışıyorum; yalnızca git push yaparken internete bağlanıyorum

• Gerçekten de kıl payı kurtulduk; böyle paketlere erişimi olan bir saldırganın sadece bir kripto para hırsızlık aracı yüklemiş olmasına inanmak zor; eline böyle kusursuz bir fırsat geçmişken fazladan bir hafta harcayıp daha sofistike exploit'ler yerleştirmek daha mantıklı görünürdü; API anahtarları, SSH açık anahtarı ekleme, sunucu IP'lerini sızdırma, geliştirici cihazlarının tarayıcı profilleri veya oturum token'ları, hatta masaüstümde kayıtlı Amazon kart bilgileri gibi çalınabilecek çok fazla şey var; bunları kendin kullanmasan bile dark web forumlarında kolayca satabilirsin; belki de gerçekten yetenekli siber suçlular zaten istikrarlı ve yüksek maaşlı teknoloji şirketlerinde çalışıyordur da geriye bu kadar basit saldırılar kalıyordur diye düşünüyorum

  • Bu saldırı yönteminin çok çabuk fark edileceği kesindi, bu yüzden gizli kalmaya çalışmak yerine tam hesap ele geçirme, yani hızlı vur-kaç stratejisini seçmiş görünüyorlar; birkaç saat içinde otomasyonla en çok parayı en hızlı nasıl çıkarabileceklerine bakmaları gerekiyordu ve kripto bunun bariz cevabıydı; dünyanın yarısı kodu didik didik etse bile arka kapının fark edilmeyeceği kadar iyi değilse, daha uzun hazırlanmanın anlamı yoktu
  • Çalınan kripto para işlemleri geri alınamadığı, iade edilemediği ve kurtarılamadığı için fiilen kesin olarak ele geçirilebilen bir varlık; buna karşılık geliştiricinin API veya SSH anahtarlarının değeri neredeyse yok ve şanslı olsan bile onları nakde çevirmek için sonunda yine kriptoya dönmen gerekiyor
  • Hızlıca gir, yüz binlerce dolar çal, çık, birkaç ay sonra aynısını tekrar et; polisi iyi atlattığın sürece ömür boyu rahat yaşarsın; AWS anahtarı çalsan da o kadar büyük kazanç sağlamaz; kripto dışında parola veya parola yöneticisi veritabanlarını hedefleyen suçlular da var ama sonuçta yine çoğu kez kriptoyla ilgili siteleri hedefliyorlar; şu anda bile şirketlere dikkatle sızmak için doğru zamanı kollayan suçlular vardır ve bunlar ortaya çıkmadan, başarılı olana kadar saklanırlar
  • Bu, hayatta bir kez ele geçen bir fırsat değil; suçlular, sadece birkaç "geliştiriciyi" hedef alarak milyonlarca dolara kolayca erişebileceklerini fark ettikçe daha cüretkâr yöntemler gelmeye devam edecek; açık kaynak kod bakımcısıysan çevrimiçi ortamda fiziksel kimliğini ne kadar iyi gizlediğini mutlaka düşünmen gereken bir noktadayız

• Ertelemek benim için bir hayatta kalma tekniği; başkaları beta test yapana kadar beklediğim için geçmişte şirkette 12 yıl boyunca yalnızca Microsoft Office 2000 kullandım ve yükseltmelerden kaynaklanan sorunlar ya da yeniden eğitim olmadan 10 yıl huzurlu zaman geçirdim; ayrıca e-postalardaki bağlantılara asla tıklamama alışkanlığım var

  • Honda aracım ve Kubernetes için de durum böyle; 2006 model arabayı uzun süre kullanarak birçok nesil boyunca yaşanan büyük küçük araç-telefon entegrasyon sorunlarını atlamış oldum ve ancak yakın zamanda 2023 model araçta iPhone bağlantısı gerçekten sorunsuz hâle geldi; Kubernetes de aynı şekilde, patronun önerisini uzun süre ertelediğim için ancak EKS, GKE vb. yeterince olgunlaştıktan sonra geçiş yaptım ve yaşadığım zorluk çok daha az oldu; 6-7 yıl önce hemen atlamış olsaydım muhtemelen tonla angarya uğraşırdım
  • npm ekosisteminde 54 saniyede bir güncelleme yapmazsan zaten ciddi şekilde geri kalmış oluyorsun
  • Yeni kötü amaçlı paketlere karşı etkili ama zaten enfekte olmuş yazılım bir de worm kapmışsa işe yaramayabiliyor
  • Yarın cevap veririm
  • "Yeni sürümleri varsayılan olarak 2 hafta geciktirmek" tedarik zinciri saldırılarına karşı çok etkili bir savunma

• Küçük startup'lar için zor olabilir ama npm gibi büyük oyuncuların npm.io, npm.sh, npm.help gibi npm alan adının tüm TLD sürümlerini önceden alması gerektiğini düşünüyorum; saldırganın npm.help alan adını ele geçirmiş olması bu saldırıyı daha etkili kıldı

  • AWS gibi şirketler müşterilerine phishing'e dikkat etmelerini söyleyip resmî fatura e-posta adresini [e-mail] yerine [e-mail] yapabiliyor; ilk kez görülen bu adres neredeyse phishing e-postası gibi görünüyor ama resmî olduğu söylenince insan kararsız kalıyor; hatta önceden gönderilen bilgilendirme e-postası bile phishing gibi göründüğü için gerçek faturayı görene kadar ekli PDF dosyasını açmıyorum; şirketler müşterilere phishing'e dikkat edin derken gereksiz yere kafa karıştırıcı davranıyor
  • 1.500'den fazla TLD var ve bazıları kısıtlı ya da ülke kodu olsa da bunların hepsini kaydetmenin gerçek yıllık maliyetinin ne olacağını merak ediyorum; bunu SaaS olarak yapan birileri de vardır herhâlde
  • TLD listesine bakınca alan adı sayısı aşırı fazla; büyük şirketler için bile benzer tüm TLD'leri kapatarak phishing'i önlemeye çalışmak gerekli olsa da bunun tamamen engellenebilir olduğunu sanmıyorum
  • Önce her zaman resmî alan adı olup olmadığını kontrol etmek gerekir; yakın zamanda kaydedilmiş indirimli alan adı kayıt şirketleri ya da kullanım süresi yakında bitecek alan adları bana otomatik olarak şüpheli gelir; özellikle son tarih vurgulayıp "zaman yok" diye insanı sıkıştıran bağlantılarsa daha derin incelerim; resmî iletişimin yalnızca bilinen ana alan adı (veya onun alt alan adları) üzerinden yapılması gerektiğini düşünüyorum
  • npm ve benzeri alan adı adlandırmalarında varyasyonların sonu yok; hepsini önceden alma yöntemi pratikte bunu durduramaz; yalnızca alan adına bakınca phishing olduğu anlaşılacak olsa bile npmjs.help gibi alan adlarına yanlışlıkla tıklanması çok gerçek bir şey

• Ya biri çok ince çalışan bir yaklaşımı (Jia Tan tarzı) bizim gevşek güvenliğimizle (editör eklentileri, shell userland vb.) birleştirirse? Geliştirici araçları süper kullanıcı yetkileriyle çalışıyor ama en az denetlenen şeyler de bunlar; ben de elisp, neovim, vscode ve basit userland araçlarının hepsini tek tek denetleyemem; en iyi ihtimalle nixpkgs üzerinden alıyorum; biri bir gün daha iyi bir VSCode eklentisi çıkarır ve 1-2 yıl beklerse oyun biter, GG

  • Umarım bir gün biri xkcd 1200 numaralı meseleyi gerçekten çözer

• MetaMask gibi cüzdanlar hedef alınmıştı ama MetaMask'in LavaMoat adlı izolasyon modülü sayesinde bu tür saldırılara karşı epey iyi korunduğunu duydum; gerçek koruma seviyesini ayrıntılı analiz eden bir yazı varsa gerçekten görmek isterim; kişisel olarak MetaMask ile ilgim yok ama bu tür güvenlik önlemlerinin (gerçek saldırılara kıyasla uygulamaya alınması yavaş olsa da) ne kadar etkili olduğunu merak ediyorum; ayrıca ilgili haberi ekliyorum

• "Gerçek şu ki bu tür phishing saldırılarında eninde sonunda herkes düşer" sözüne karşılık, ben şahsen muhtemelen düşmem diye düşünüyorum; kendim talep etmediğim hiçbir e-postadaki bağlantıya asla kimlik bilgisi girmem (ör. parola sıfırlama); bence 2025'te herkesin mutlaka edinmesi gereken bir güvenlik becerisi bu

  • "'Bu tür' phishing saldırısı" denince kulağa sofistike bir saldırı gibi geliyor ama aslında geliştiricinin yine düpedüz sıradan bir phishing e-postasına kandığı bir vaka bu; çok temel bir hata, hatta bazen idari işler personelinin bile kanmayacağı kadar bariz; elbette herkes hata yapabilir ama bence bunların tekrarlanmasının sebebi açık bir dikkatsizlik ve amatörce hatalar

• Makaledeki "tüm kötü amaçlı yazılımlar yalnızca kripto cüzdan adreslerini değiştirdi" açıklamasının aksine, MetaMask'in etkilenmemesinin nedeni şuydu:

1. saldırı anında paket hemen güncellenmedi
2. MetaMask hem kurulumda hem çalışma zamanında LavaMoat ile korunuyordu; buna karşılık bu kötü amaçlı payload, MetaMask ile etkileşen diğer cüzdan kullanan web sayfalarını hedef almaya çalışıyordu; bu arada ben LavaMoat geliştirmesinde yer aldım; daha fazla bilgi için LavaMoat GitHub sayfasına bakın

• Büyük açık paket depolarının çok daha güçlü güvenlik çözümlerine ihtiyacı var; olmadı en azından güvenilir şekilde incelenmiş temel paketlerden oluşan bir küme olmalı; Python, Rust ekosistemleri vb. de aynı şekilde güvene dayanarak işliyor

  • npm'nin temel sorunu, namespace zorunluluğunun olmaması; Java'nın Maven ekosisteminde acemiler "neden npm kadar kolay değil" diye şikâyet ediyor ama Maven'in ad alanı sistemi gibi kalite kontrol takıntılarını yıllar geçtikçe daha çok takdir eder oldum; POM xml rahatsız edici olsa da muhafazakâr değişiklik yönetimi güven veriyor; ilgili yazı: neden herkese açık açık kaynak depolarında namespacing önemlidir
  • Bu örnekte olduğu gibi paket bakımcısının hesabı doğrudan ele geçirilirse namespace gibi yapısal önlemler de anlamsız kalıyor; tek çözüm yeni sürümlerin hemen uygulanmasını engelleyecek bir gecikme koymak
  • Linux dağıtımları da güvene dayanır ama paket yükleme yetkisi almak için bu güveni "kanıtlamak" gerekir ve bunun etrafında bütün bir güven doğrulama sistemi vardır; NPM ise sanki herkesin dilediğini yükleyebildiği serbest bir sistem gibi

• "Bunu durdurmanın yolu yok" iddiası en sık, ihlallerin en çok yaşandığı ekosistemlerde duyuluyor

  • Sorun da tam olarak bu; fazlasıyla tembel bir sonuç