Security Blog

Hasat Edilecek Bir Şey Kalmamalı

#91

October 2, 2026 · By Marketing team

← All posts

Ele geçirilmiş bir Bitwarden CLI, 334 geliştirici makinesinden SSH anahtarlarını, bulut kimlik bilgilerini ve npm token'larını topladı. Asıl sorun, kötü amaçlı yazılımın nasıl girdiği değil. Her sırrın okunmayı bekleyen düz bir dosya halinde orada duruyor olması.

Dün, Bitwarden CLI'ının ele geçirilmiş bir sürümü 334 geliştirici makinesinden SSH anahtarlarını, AWS kimlik bilgilerini, npm token'larını, ortam değişkenlerini, kabuk geçmişini ve Git sırlarını topladı.

Bugün Bitwarden'dı. Geçen ay Axios'tu. Ondan önce Checkmarx. Yarın bir VS Code eklentisi, ya da Acrobat, ya da bir Homebrew formülü, ya da bir Docker imajı olacak. Vektör her hafta değişiyor. Sonuç her zaman aynı.

Kötü amaçlı yazılım yerleşir. ~/.ssh/ klasörünü okur. ~/.aws/credentials dosyasını okur. ~/.npmrc dosyasını okur. ~/.git-credentials dosyasını okur. Kabuk geçmişini, ortam değişkenlerini, tarayıcı parola depolarını okur. Hepsini paketler ve bir C2 sunucusuna gönderir.

Ve işe yarar. Her seferinde.

Hasat

Bitwarden yükü — bw1.js adlı, 10 MB boyutunda, gizlenmiş bir dosya — hiçbir şifrelemeyi kırmaya çalışmadı. Buna gerek de yoktu. Socket ve Aikido'nun belgelediği üzere topladıkları şunlardı:

  • SSH anahtarları ve ana bilgisayar parmak izleri
  • AWS, GCP ve Azure bulut kimlik bilgileri
  • npm kimlik doğrulama token'ları
  • Git kimlik bilgileri ve uzak URL'ler
  • Ortam değişkenleri
  • Kabuk geçmişi
  • Claude Code kimlik doğrulaması ve MCP yapılandırmaları

Ardından, çalınan npm token'larını kullanarak kurbanın sürdürdüğü diğer paketleri yeniden yayımladı ve böylece daha da yayıldı. Kurbanlar vektöre dönüştü.

Bunların hiçbiri şifrelemenin kırılmasını gerektirmedi. Bu sırların her biri, kullanıcı olarak çalışan herhangi bir sürecin okuyabileceği bir dosya sistemi dosyasıydı.

Bu bir Bitwarden hikâyesi değil

Bitwarden'ın kasa şifrelemesi ihlal edilmedi. Sıfır bilgi mimarileri tuttu. Kötü amaçlı yazılım kasaya hiç dokunmadı.

Dokunması da gerekmiyordu.

Kasa, içindekini korur. Ama SSH anahtarları hiçbir zaman kasada değildi. AWS kimlik bilgileri hiçbir zaman kasada değildi. npm token'ları, Git kimlik bilgileri, .env dosyalarındaki API anahtarları — bunların hiçbiri parola yöneticilerinde yaşamaz. Nokta dosyalarında, düz metin olarak, her geliştiricinin makinesinde yaşar.

Saldırgan bunu anlamıştı. Kasa, her çekmecenin açık olduğu bir evde kilitli bir kasa.

Gerçek saldırı yüzeyi

Şu anda bir terminal açın. Makinenizde ne olduğuna bakın.

~/.ssh/id_ed25519 — özel anahtarınız. Düz metin dosya.

~/.aws/credentials — bulut erişiminiz. Düz metin dosya.

~/.npmrc — yayımlama token'ınız. Düz metin dosya.

~/.git-credentials — depo erişiminiz. Düz metin dosya.

Bir düzine proje dizinindeki ~/.env — API anahtarları, veritabanı parolaları, imzalama sırları. Hepsi düz metin dosya.

Kullanıcınız olarak çalışan herhangi bir süreç bunların hepsini okuyabilir. Ayrıcalık yükseltmeye gerek yok. İstismar gerekmiyor. Sadece cat.

2026'da varsayılan geliştirici kurulumu bu. Parolalarımızı şifreli bir kasaya koyuyoruz ve geri kalan her şeyi açıkta bırakıyoruz.

Yanlış soru

Her tedarik zinciri saldırısından sonra sektör aynı soruyu sorar: kötü amaçlı yazılımın içeri girmesini nasıl önleriz?

Daha iyi CI/CD güvenliği. Kod imzalama. Bağımlılık taraması. Korumalı çalışma zamanları. Bunların hepsi iyi şeyler. Hiçbiri yeterli değil. Saldırı yüzeyi çok geniş. Çok fazla vektör var — paket yöneticileri, tarayıcı uzantıları, IDE eklentileri, OAuth uygulamaları, ele geçirilmiş derleme araçları. Her giriş noktasını kapatamazsınız.

Doğru soru şudur: kötü amaçlı yazılım kaçınılmaz olarak bir geliştiricinin makinesinde çalıştırma elde ettiğinde ne bulur?

Cevap "öngörülebilir dosya sistemi konumlarında yüzlerce düz metin kimlik bilgisi" ise, tedarik zinciri sertleştirmesinin hiçbir miktarı önemli değildir. Arkasında kalemin sonuna kadar açık olduğu bir sahada savunma oynuyorsunuz.

Hasat edilecek bir şey kalmamalı

Çözüm daha iyi kötü amaçlı yazılım tespiti değil. Çözüm npm install'ı korumalı alanda çalıştırmak değil. Çözüm daha hızlı olay müdahalesi değil.

Çözüm şudur: sırlar disk üzerinde dosya olarak var olmamalı.

Kimlik doğrulama anında donanımdan türetilen SSH anahtarları — ~/.ssh/ içinde saklanan değil. Donanıma bağlı bir kimlikten oturum bazında verilen bulut kimlik bilgileri — ~/.aws/ içine yazılmayan değil. Kapsamlı, geçici ve donanım kontrollü API token'ları — .env dosyalarında duran değil.

Bir kimlik bilgisi yalnızca bir donanım güvenlik modülünün içinde ve kullanım sırasında geçici işlem belleğinde var olduğunda, kötü amaçlı yazılımın okuyacağı bir şey kalmaz. Sızdırılacak dosya yok. Toplanacak nokta dosyası yok. Süreç çalışır, hiçbir şey bulamaz, yoluna devam eder.

Bu teorik değil. Donanıma bağlı kimlik bilgileri bugün mevcut. WebAuthn PRF, fiziksel bir kimlik doğrulayıcı dokunuşundan kriptografik anahtarlar türetebilir — dosya sistemine hiç değmeyen anahtarlar. Teknoloji burada. Sektör bunu henüz varsayılan olarak benimsemedi.

Şimdi ne yapmalı

Bitwarden CLI ihlalinden etkilendiyseniz:

  • Makinedeki her kimlik bilgisini değiştirin — SSH anahtarları, bulut token'ları, npm token'ları, API anahtarları, nokta dosyalarındaki ve ortam değişkenlerindeki her şey
  • Sürdürdüğünüz npm paketlerinden herhangi birinin yeniden yayımlanıp yayımlanmadığını kontrol edin
  • Yetkisiz değişiklikler için GitHub etkinliğini ve CI/CD iş akışlarını denetleyin

Etkilenmediyseniz, eylem aynıdır. Makinenize bakın. Düz metin sırları sayın. Kendinize, kullanıcınız olarak kötü amaçlı bir şey çalıştığında — eğer değil, ne zaman — ne olacağını sorun.

Cevap şu olmalı: hiçbir şey. Hasat edilecek bir şey kalmamalı.