Bitwarden CLI, devam eden Checkmarx tedarik zinciri kampanyasında ele geçirildi

 (socket.dev)
1 puan yazan GN⁺ 7 일 전 | 1 yorum | WhatsApp'ta paylaş
  • npm için Bitwarden CLI paketi, devam eden Checkmarx tedarik zinciri saldırısının bir parçası olarak ele geçirildi ve şu anda doğrulanan etki alanı @bitwarden/cli 2026.4.0 derlemesiyle sınırlı
  • Pakete eklenen bw1.js zararlı kodu, audit.checkmarx[.]cx/v1/telemetry gibi aynı altyapıyı ve obfuscation yöntemini kullanıyor; ayrıca ele geçirilmiş bir GitHub Action kullanılarak CI/CD ihlali yaşandığına dair bulgularla da örtüşüyor
  • Hedeflenen veriler yalnızca GitHub tokenları ile sınırlı değil; AWS, Azure, GCP kimlik bilgileri, .npmrc, SSH anahtarları, ortam değişkenleri ve Claude/MCP yapılandırma dosyalarına kadar genişliyor
  • Çalınan bilgiler, herkese açık GitHub deposu oluşturma ve commit atma, npm tokenlarıyla yeniden dağıtım yoluyla yayılma ve workflow enjeksiyonuna kadar uzanıyor; ayrıca ~/.bashrc ve ~/.zshrc dosyalarını değiştirme gibi kalıcılık mekanizmalarını da içeriyor
  • Bitwarden CLI kullanan kuruluşların bu olayı kimlik bilgisi sızıntısı ve CI/CD ihlali olarak ele alması; CI loglarını incelemesi ve açığa çıkmış olabilecek gizli bilgileri değiştirmesi önemli

Genel Bakış

  • Bitwarden CLI npm paketi, devam eden Checkmarx tedarik zinciri saldırısının bir parçası olarak ele geçirildi ve doğrulanan hedef sürüm @bitwarden/cli2026.4.0
    • Zararlı kod, pakette bulunan bw1.js içine yerleştirilmişti
    • Saldırı yolu, Bitwarden'ın CI/CD pipeline'ı içinde ele geçirilmiş bir GitHub Action'ın kullanıldığına işaret eden bulgularla örtüşüyor ve diğer depolarda gözlenen kampanya kalıplarıyla eşleşiyor
  • Şu ana kadar doğrulanan kapsam Bitwarden CLI derlemesiyle sınırlı ve ele geçirme olayı, daha geniş Checkmarx campaign içinde tanımlanan GitHub Actions tedarik zinciri vektörünü izliyor
    • Yalnızca npm için CLI paketi etkilenmiş durumda
    • Chrome uzantısı, MCP sunucusu ve diğer resmi dağıtımlarda şu ana kadar etkilenme doğrulanmadı
  • Soruşturma sürüyor; tam teknik analiz, etkilenen sürümler, ihlal göstergeleri ve müdahale yönergeleri daha sonra ayrıca paylaşılacak
  • Bitwarden CLI kullanılıyorsa CI loglarının incelenmesi ve açığa çıkmış olabilecek gizli bilgilerin değiştirilmesi gerekiyor

Teknik Analiz

  • Zararlı yük bw1.js, önceki gün analiz edilen Checkmarx mcpAddon.js ile temel altyapıyı paylaşıyor
    • Aynı C2 endpoint'i olan audit.checkmarx[.]cx/v1/telemetry kullanılıyor ve __decodeScrambled ile 0x3039 seed'i üzerinden obfuscation uygulanıyor
    • GitHub API üzerinden commit tabanlı veri sızdırma ile npm registry üzerinden token çalma ve yeniden dağıtım da gerçekleştiriliyor
  • Gömülü payload yapısı da aynı aileye ait
    • gzip+base64 yapısı içinde, GitHub Actions Runner.Worker belleğini tarayarak GitHub tokenlarını hedefleyen bir Python script'i yer alıyor
    • Yeniden dağıtılan npm paketleri için setup.mjs loader'ı, GitHub Actions workflow YAML dosyası, hard-code edilmiş RSA açık anahtarı ve ideolojik manifesto metni de birlikte bulunuyor
  • Kimlik bilgisi toplama kapsamı çok geniş
    • GitHub tokenları, Runner.Worker bellek kazıması ve ortam değişkenlerinden toplanıyor
    • AWS kimlik bilgileri ~/.aws/ dosyaları ve ortam değişkenlerinde aranıyor
    • Azure tokenları azd, GCP kimlik bilgileri ise gcloud config config-helper üzerinden toplanıyor
    • .npmrc, SSH anahtarları, ortam değişkenleri ve Claude/MCP yapılandırma dosyaları da hedefler arasında
  • GitHub üzerinden veri sızdırma yöntemi de ayrıntılı biçimde doğrulandı
    • Kurban hesabı altında, Dune temalı adlandırma kuralı {word}-{word}-{3digits} izleyen herkese açık depolar oluşturuluyor
    • Şifrelenmiş çıktılar commit ediliyor ve commit mesajına LongLiveTheResistanceAgainstMachines işaretçisiyle birlikte tokenlar ekleniyor
  • Tedarik zinciri üzerinden yayılma mekanizması da buna dahil
    • Çalınan npm tokenlarıyla yazma izni olan paketler bulunup, içine preinstall hook eklenmiş şekilde yeniden yayımlanıyor
    • GitHub Actions workflow enjeksiyonu yapılarak depo gizli bilgileri ek olarak toplanıyor
  • Rusça locale kill switch bulunuyor
    • Sistem locale'i "ru" ile başlıyorsa sessizce çıkıyor
    • Intl.DateTimeFormat().resolvedOptions().locale ile LC_ALL, LC_MESSAGES, LANGUAGE, LANG ortam değişkenleri kontrol ediliyor
  • Runtime olarak Bun v1.3.13 kullanılıyor ve GitHub Releases'ten indiriliyor

Checkmarx olayıyla farklılaşan noktalar

  • bw1.js, Checkmarx olay belgelerinde yer almayan ek ihlal göstergeleri içeriyor
    • Eşzamanlı çalışmayı engellemek için hard-code edilmiş kilit dosyası /tmp/tmp.987654321.lock kullanılıyor
    • ~/.bashrc ve ~/.zshrc içine payload enjekte edilerek shell profil kalıcılığı sağlanıyor
    • Depo açıklaması Shai-Hulud: The Third Coming olarak ayarlanıyor ve debug string'lerinde "Would be executing butlerian jihad!" ifadesi geçiyor; yani açık bir branding kullanılıyor
  • Paylaşılan araç seti, aynı zararlı yazılım ekosistemine güçlü şekilde işaret etse de operasyonel imzalar atıf yapmayı daha zor hale getiriyor
    • Checkmarx saldırısı ortaya çıktıktan sonra TeamPCP, @pcpcats sosyal hesabı üzerinden bunun kendi eylemleri olduğunu iddia etmişti
    • Söz konusu zararlı yazılım, meşru görünen açıklamalarla kendini gizlemeye çalışmıştı
  • Bu payload ise kamusal tavır açısından farklılık gösteriyor
    • Shai-Hulud depo adı, "Butlerian Jihad" manifestosu ve makinelere karşı direnişi öne çıkaran commit mesajları gibi ideolojik işaretler doğrudan zararlı yazılımın içine yerleştirilmiş
    • Aynı altyapıyı kullanan farklı bir operatör, daha güçlü ideolojik çizgisi olan bir alt grup ya da kampanyanın kamusal tavrında değişim gibi olasılıkların tümü hâlâ mümkün

Öneriler

  • Zararlı Bitwarden npm paketini kurmuş kuruluşlar bu olayı kimlik bilgisi sızıntısı ve CI/CD ihlali olarak değerlendirmeli
  • Geliştirici sistemlerinden ve build ortamlarından etkilenen paket derhal kaldırılmalı; bu ortamlarda açığa çıkmış olabilecek tüm kimlik bilgileri değiştirilmeli
    • Buna GitHub tokenları, npm tokenları, bulut kimlik bilgileri, SSH anahtarları ve CI/CD gizli bilgileri dahildir
  • GitHub tarafında yetkisiz depo oluşturma ve anormal workflow'lar incelenmeli
    • .github/workflows/ altında beklenmeyen dosyalar, şüpheli workflow çalıştırmaları, artifact indirmeleri ve Dune temalı adlandırma kalıbı {word}-{word}-{3digits} taşıyan herkese açık depolar kontrol edilmeli
    • Etkilenme ihtimali varsa, yeni yayımlanmış depolarda aşağıdaki anahtar kelimeler aranmalı
      • atreides
      • cogitor
      • fedaykin
      • fremen
      • futar
      • gesserit
      • ghola
      • harkonnen
      • heighliner
      • kanly
      • kralizec
      • lasgun
      • laza
      • melange
      • mentat
      • navigator
      • ornithopter
      • phibian
      • powindah
      • prana
      • prescient
      • sandworm
      • sardaukar
      • sayyadina
      • sietch
      • siridar
      • slig
      • stillsuit
      • thumper
      • tleilaxu
  • npm tarafında yetkisiz yayımlar denetlenmeli
    • Onaylanmamış publish işlemleri, sürüm değişiklikleri ve sonradan eklenen install hook'lar kontrol edilmeli
  • Bulut ortamlarında erişim logları yeniden gözden geçirilmeli
    • Anormal gizli bilgi erişimi, token kullanımı ve yeni oluşturulmuş kimlik bilgileri izlenmeli
  • Endpoint'lerde ve runner'larda gözlenen veri sızdırma altyapısı ve dosya erişim izleri takip edilmeli
    • audit[.]checkmarx[.]cx adresine yapılan dış bağlantılar aranmalı
    • Normalde kullanılmayan ortamlarda Bun çalıştırılması olup olmadığı kontrol edilmeli
    • .npmrc, .git-credentials, .env, bulut kimlik bilgisi depoları, gcloud, az, azd erişim izleri incelenmeli
    • /tmp/tmp.987654321.lock dosyasının varlığı ile ~/.bashrc ve ~/.zshrc değişiklikleri de kontrol edilmeli
  • GitHub Actions tarafında onaysız workflow oluşturma olayları incelenmeli
    • Workflow'ların geçici branch'lerde oluşturulup oluşturulmadığı kontrol edilmeli
    • format-results.txt gibi artifact'lerin oluşturulup oluşturulmadığı veya indirilip indirilmediği de gözden geçirilmeli
  • Uzun vadede, gelecekteki tedarik zinciri olaylarında etki alanını küçültmeye odaklanılmalı
    • Token yetki kapsamları daraltılmalı ve mümkünse kısa ömürlü kimlik bilgileri kullanılmalı
    • Paket oluşturma ve yayımlama yetkileri sınırlandırılmalı, GitHub Actions izinleri sıkılaştırılmalı
    • Gereksiz artifact erişimleri devre dışı bırakılmalı; normal release süreci dışında oluşan herkese açık depolar ve workflow değişiklikleri izlenmeli

İhlal Göstergeleri

İlgili okumalar

1 yorum

 
GN⁺ 7 일 전
Hacker News yorumları

  • Minimum sürüm bekleme süresi koymaktan daha iyi bir savunma olup olmadığını merak ediyorum
    .npmrc içine sadece min-release-age=7 eklenmiş olsaydı, yaklaşık 19 saat önce yüklenip sonradan zararlı olduğu ortaya çıkan @bitwarden/cli 2026.4.0 sürümünü alan 334 kişi bundan kaçınabilirdi gibi görünüyor
    Benzer şekilde axios, ua-parser-js, node-ipc vakalarında da oldukça işe yarıyor ve event-stream gibi uzun süre gizli kalan durumları engelleyemese de, çoğu akut tedarik zinciri saldırısında etkili görünüyor
    Örnek yapılandırma olarak npm/pnpm/bun/uv için ayrı ayrı bekleme süresi ekleme yöntemleri var; tek tıkla denetleyip uygulayan bir araç olmadığı için ben de https://depsguard.com aracını yaptım
    Benzer fikirde olan https://cooldowns.dev sitesini de az önce gördüm

    • Aikido safe-chain kullanıyorum
      Sadece minimum sürüm bekleme süresi koymakla kalmıyor; npm/uv gibi araçları saran bir wrapper olarak kurulumdan önce her bağımlılığı ticari zafiyet veritabanı ile karşılaştırıp bilinen sorunları ve şüpheli sinyalleri denetliyor
    • Cooldown fikri güzel ama kimse hemen güncelleme yapmasaydı bu saldırının gerçekten yakalanıp yakalanmayacağını da merak ediyorum
      Gerçekte her zaman birileri anında güncelleyecektir ama bu tür olayların ortaya çıkma sürecinin hızlı güncelleyen kullanıcılara dayanıyor olması da dikkat çekici
    • Bence işe backend ya da CLI araçlarını NPM üzerinde barındırmamakla başlamak daha iyi
    • Yeni kurulumlarda tamam da, mevcut bağımlılıklarda patch sürümüne pinlemek ve sha sabitlemek yeterli olmaz mı?
    • Bu tür saldırılar çoğu zaman upstream source katmanına kadar inmiyor; bu yüzden https://www.chainguard.dev/libraries gibi kaynak koddan derleme yaklaşımı kabaca %98'ini engelleyebilir
      Kayıt defterindeki binary'leri doğrudan çekmek zorundaysanız cooldown riski bir miktar azaltabilir
      GitHub tarafına kadar sızan uzun kuyruklu vakalarda ise commit/bakımcı heuristikleri ile AI tabanlı kod değişikliği analizi birlikte çalıştırılıp, anormallik varsa insan incelemesine gidilmesi gerekiyor gibi görünüyor
      Bu arada burada çalışıyorum

  • Bu olayın özünde build pipeline'ın ele geçirilmesi ve kirlenmiş paketin dağıtılması var
    Yine de iş açısından kritik bir şeyi npm üzerine koyuyorsanız bağımlılıkları mutlaka pinning yapmanın daha iyi olduğunu düşünüyorum
    Pek çok geliştirici lockfile'ı yeterli sanıyor ama ^ aralığı duruyorsa lockfile güncellenirken açıkça seçmediğim yeni bir sürüm yine gelebilir
    Şirketin varlığını etkileyebilecek sistemler için bu kadar zahmete değeceğini düşünüyorum

    • Öte yandan, sonraki sürümlerde güvenlik açığı düzeltilmişse, sistemin bunu otomatik alıp uygulaması da ideal olurdu

  • https://github.com/doy/rbw, Bitwarden CLI için Rust tabanlı bir alternatif
    Rust ekosistemi de giderek npm gibi büyük ve derin bağımlılık ağaçlarına gidiyor gibi hissettiriyor ama yine de JavaScript'te yaygın olan senaryolara kıyasla güvenmeniz gereken yazar sayısı çok daha az

    • https://github.com/doy/rbw/blob/main/Cargo.toml#L16 bağlantısına bakınca burada da oldukça fazla bağımlılık var
      Yine de en azından sürümler pinlenmiş
    • Firefox'un yerleşik parola yöneticisini kullanmanın bir dezavantajı var mı diye merak ediyorum
    • Herkes Rust'ı daha güvenli görüyor ama bağımlılıklar üzerinden malware çekme riskinin ciddi biçimde arttığını çok kolay göz ardı ediyor gibi görünüyor
    • rbw + vaultwarden kombinasyonu, self-host edilebilir Rust sürümü bir Bitwarden gibi çalıştığı için oldukça iyi
    • Böyle olaylar yüzünden daha fazla yazılımın .Net gibi üçüncü taraf bağımlılıklara gerek kalmadan çoğu şeyi çözebilen stack'lere yönelebileceğini düşünüyorum
      Ya da tersine, dil standart kütüphanelerine daha fazla işlev eklenebilir

  • Bitwarden CLI deneyimi çok kötüydü
    bw list komutunu çalıştırdığımda sadece parola adlarının çıkacağını sanmıştım ama gerçekte parolaların tamamını ve güncel TOTP kodlarını da gösterdi
    Daha korkuncu, sunucuya ssh ile girip tmux içindeki weechat'i açtığımda, bw komutunun tam içeriğine weechat giriş geçmişinden erişilebildiğini gördüm
    Neden olduğunu hiç bilmiyorum; tmux ve weechat oturumlarını aşarak kalmaya devam etti ve ancak sunucuyu yeniden başlatınca kayboldu
    Ondan sonra bw CLI'ı hemen sildim ve yeniden kurmayı da düşünmüyorum
    Bu arada terminal olarak ghostty kullanıyorum

    • Bu, asıl konuyla ilgili olmaktan çok yakınmaya benziyor
    • CLI'ı denemeyi düşünmüştüm ama JavaScript tabanlı olduğunu görünce vazgeçtim
    • Gerçekten tuhaf bir durum
      weechat için bir bwcli eklentisi mi var diye merak ediyorum; Bitwarden'ın CLI'ı olduğunu da bu olayla öğrendim
      Ben yerelde keepass kullanıyorum

  • CLI'ı hiç kullanmadım ama tarayıcı eklentisini kullanıyorum
    Bunun da ele geçirilmesi gerçekten felaket olurdu; bunu önlemek için ne yapılabileceğini bilmiyorum
    Çözümün doğrulanmış bir eski sürümü kullanmaya devam etmek olup olmadığını düşünüyorum
    Hayatımın önemli bir kısmının bu sırların sır olarak kalmasına bağlı olması bir anda çok tuhaf hissettiriyor

    • Entegrasyon noktaları arttıkça saldırı yüzeyi de büyüyor
      Bu yüzden parola yöneticisi tarayıcı eklentileri kullanmıyorum
      Geçmişte tarayıcı entegrasyonunda güvenlik sorunu yaşayan ürünler gördükten sonra tamamen kaçınır oldum; iOS entegrasyonuna görece daha çok güveniyorum ama yine de temkinliyim
    • Bence cooldown varsayılan olarak her yerde olmalı
      Buna geliştirme amaçlı paket yöneticileri, OS paket yöneticileri, tarayıcı eklentileri ve bağımsız uygulamaların otomatik güncellemeleri dahil
      Socket gibi şirketlerin zararlı güncellemeleri yakalayabilmesi için zaman kazanmak gerekiyor; herkes yayımlandıktan birkaç dakika sonra indirirse bu tür tespitlerin anlamı kalmaz
    • Dijital varlıklarım içinde en değerli olan e-posta ve Bitwarden hesaplarımı, sürekli yanımda taşıdığım bir Yubikey ve farklı bir bölgede tuttuğum bir yedek anahtarla koruyorum
      Bu kurulumu şiddetle tavsiye ederim
      Başlığı görünce biraz ürktüm ama paranoya seviyesine çıkmadan makul olarak yapılabilecek her şeyi yaptığımı düşünüyorum
    • Tarayıcı eklentisi yerine masaüstü uygulamasını ya da web vault'u doğrudan kullanabilirsiniz
    • Bunu önlemenin yolu kısaca şu ikisi
      https://cooldowns.dev
      https://depsguard.com
      İkincisini ben yönetiyorum; birincisini önceden bilseydim muhtemelen bunu yapmazdım
      İkisi de neredeyse aynı işi yapıyor, benimki Rust kullandığı için biraz fazla kaçıyor

  • Buradaki en önemli nokta, sadece npm install çalıştırmanın yeterli olmasıydı
    Ele geçirme noktası preinstall ise, kurulumdan sonra inceleme yapma yönündeki yaygın düşünce hemen çöküyor
    Çünkü o noktada payload zaten çalıştırılma fırsatını elde etmiş oluyor
    Bu özellikle agent, CI ve ephemeral sandbox ortamlarında ilginç; maruz kalma süresi kısa olsa bile kurulum otomatik olarak tekrarlanıyorsa yine de etkilenebilirsiniz
    Dikkat çekici bir başka nokta da bu payload'un sadece gizli bilgileri değil, AI tooling yapılandırmalarını da hedef alması
    Shell profillerinin değiştirilmesi, bir sonraki kodlama asistanının okuyacağı bağlamın kirletilmesine giden gerçekçi bir yol olabilir
    Bu bakış açısını AgentSH çalışmasıyla birlikte https://www.canyonroad.ai/blog/the-install-was-the-attack/ yazısında daha uzun anlattım

    • İnsanlar gerçekte paketleri kurulumdan sonra incelemiyor; npm install script'lerini özel olarak sorun etmek de birçok kez çürütülmüş bir argüman bence
      Sonuçta yine gerçek binary'yi çalıştırıyorsunuz
      Hatta işi sıkı tutarsanız kurulumdan önce paketi manuel indirip incelemek de mümkün; kurulum aracının davranış garantilerini ve kapsamını derinlemesine anlamadan, zararlı kodu indirip açma sürecine gelişigüzel güvenmek daha da garip geliyor

  • Rusça locale kill switch cesur ama aynı zamanda korkakça görünüyor

    • Daha kötüsü, bunun gerçekten bir iz mi yoksa false flag mi olduğunu bile bilmiyoruz
    • Discretion is the better part of valor gibi türlü özdeyişleri akla getiriyor
      Kısacası kendi ayağına sıkmama tavrı gibi duruyor
    • Bu tek başına kesin kanıt değil
      Vault7 sızıntılarında NSA ve CIA'in kaynağı gizlemek için bu tür izleri bilerek bıraktıklarına dair şeyler vardı; diğer devlet aktörleri de rahatlıkla böyle teknikler kullanabilir
    • Başka bir ülkenin yaptığı tehdit amaçlı operasyon gibi de görünebilir
    • npm publish GitHub CI işinde kim locale'i öyle ayarlamış olur ki
      Fazla bariz bir şaşırtma izi gibi ama aynı zamanda devlet aktörü müdahalesi izlenimini de güçlü biçimde veriyor

  • KeePass kullanıcısı olarak yaşayınca bu stres çok daha az oluyor
    Son 5 yılda yalnızca yerel altyapıda KeePass kullanarak birkaç güvenlik olayından kaçındım

    • Bu olayda sorun vault'un kendisi değil, erişim aracıydı
      KeePass erişim aracı için böyle bir şeyin imkânsız olduğunu söyleyemeyiz; farkın tam olarak ne olduğunu ben de bilmiyorum
    • Parolalara hem altyapıdan hem telefondan erişmem gerekiyor; KeePass ile bunun nasıl çözüldüğünü merak ediyorum
      Şimdiye kadar imkânsız sanıyordum ama açıkçası derinlemesine bakmadım
    • Kendi altyapısını işletebilen biri için iyi olabilir ama stress free ifadesini ortalama kullanıcıya kadar genişletmek zor
    • Tek dosya yaklaşımını anlıyorum ama pratikte senkronizasyon ve çakışma çözümü nasıl yapılıyor merak ediyorum
      İki cihaz çevrimdışıyken ayrı ayrı parola ekleyip sonra yeniden çevrimiçi olursa ne oluyor?
    • KeePass'te hâlâ kafama oturmayan şey bulut yedeği
      Yedeği şifrelerseniz o parolayı nerede tutuyorsunuz, sonra bulut sağlayıcısının parolasını nerede tutuyorsunuz diye düşünüyorum

  • Bu saldırıda özellikle etkileyici olan şey, saldırganların tam olarak GitHub'ın kapalı olmadığı zamana denk getirmek zorunda olmalarıydı

  • Bu yüzden ben üçüncü taraf parola yöneticileri hiç kullanmıyorum
    Güvenlik, güncellemeler ve yedekleri düzgün yapacaklarına sürekli güvenmek zorunda kalıyorsunuz
    Kendi stateless parola üreticimi yaptım; böylece cihazlar arasında veri yedeği ya da senkronizasyon ihtiyacı tamamen ortadan kalktı
    Çok uzun ve güçlü bir ana parola ile servis adı ve kullanıcı adını veriyorum; ardından uygun parametrelerle scrypt hash hesaplanıyor ve brute force fiilen imkânsız hale geliyor
    Önemli hesaplarda ayrıca 2FA da kullanıyorum