Merhaba ekip,
20 Ekim 2026'da BleepingComputer ve OVHcloud CEO'su Octave Klaba'nın açıklamalarıyla netleşen olay: OVHcloud CLI'nin GitHub release'leri kısa süreliğine bilgisayarı çalan (infostealer) sürümlerle değiştirildi. CI/CD bozulmadı; saldırgan geliştirici hesabını ele geçirip release immutability kapalıyken mevcut paketleri değiştirdi. Bu yazı "ne oldu / kim etkilenir / ne yapmalı" özeti.
Ne oldu?
- Etkilenen sürümler: v0.11.0, 0.12.0, 0.13.0, 0.14.0, 0.15.0
- Temiz: v0.10.0 ve olay sonrası çıkan v0.16.0
- Pencere: 19 Ekim 2026 ~14:47 ile ~16:21 arası (müşteri bildirimiyle yakalandı)
- Hedef platformlar (OpenSourceMalware): macOS Intel/ARM, Linux x86_64/ARM64, Windows x86-64
- Kaynak derlemeler ve Docker imajları etkilenmedi (rapora göre)
Amaç diskteki sırları toplamak. Klaba'nın ifadesiyle binary kalitesi düşük ama "sonuna kadar gidebiliyor". GlassWorm operasyonuyla bağlantı kuruluyor; aynı GitHub hesabında aylardır izler (Solana memo dead drop vb.) görülmüş.
Geliştirici olarak kontrol
Kod:
# Kurulu sürüm
ovhcloud version 2>/dev/null || ovhcloud-cli version 2>/dev/null
# go install / paket yöneticisi ile geldiyse pin'i kontrol edin
# Hash pin örneği (kendi doğruladığınız hash ile)
# curl -L ... | sha256sumEtkilenen bir binary çalıştırdıysanız:
- Aracı kaldırın, temiz 0.16.0 veya 0.10.0'a geçin.
- Makinedeki tüm sırları ele geçirilmiş kabul edin: OVH API token, SSH anahtarları, cloud credential dosyaları, .env, parola yöneticisi dışa aktarımları.
- Token/anahtar rotate; GitHub/GitLab PAT, CI secret'ları dahil.
- Release immutability ve branch koruması kendi org'unuzda açık mı kontrol edin.
Tedarik zinciri dersi
"CI yeşil = release güvenli" yetmez. GitHub release asset'leri değiştirilebilirse (immutability kapalı) pipeline hiç dokunulmadan zehirlenir. Pin hash, Cosign/Sigstore, internal mirror ve "son 24 saatte inen CLI'yi gözden geçir" alışkanlığı bu sınıf olaylarda fark yaratır. npm/VSCode uzantı ekosisteminde gördüğümüz GlassWorm tarzı kampanyaların GitHub release katmanına sıçraması sürpriz değil.
Organizasyon için mini playbook
Kod:
# Envanter (örnek)
find /home /opt -name 'ovhcloud*' 2>/dev/null | head
# CI runner imajlarında CLI var mı?
grep -R "ovhcloud-cli\|ovh/ovhcloud-cli" .github/workflows 2>/dev/null | headYasal uyarı
Yalnızca bilgilendirme. Başkalarının hesap veya sistemlerine yetkisiz erişim TCK 243-245 kapsamında suçtur. Zararlı örnekleri analiz edecekseniz izole lab kullanın.
Kaynaklar
- https://www.bleepingcomputer.com/news/se...r-secrets/
- https://github.com/ovh/ovhcloud-cli/issues/300
- OpenSourceMalware topluluk analizi (GlassWorm göstergeleri)
Sizde CLI paketleri hash ile mi pinleniyor, yoksa "latest" mı çekiliyor? Yorumlara yazın.
Geliştirici iş istasyonu temizliği
Etkilenen CLI çalıştıysa yalnızca OVH token'ı yetmez. ssh-agent'ta yükü anahtarlar, tarayıcı kayıtlı parolalar, cloud-cli cache (~/.config altında), Docker credsStore, Terraform state içi secret'lar gözden geçirilmeli. Mümkünse makinede taze profil veya yeniden kurulum düşünün.
Kurumsal CI runner
Self-hosted runner imajlarında "convenience" diye eklenen cloud CLI'lar unutulur. Golden image'ı yeniden üretin; secret scanning ile geçmiş job log'larını tarayın. Release immutability + zorunlu code review + 2FA enforced org ayarlarını aynı sprintte kapatın.
Uygulamada sık gördüğüm hatalar
Birçok ekip yamayı "planlandı" diye işaretleyip internete açık yüzeyde günlerce bekletiyor. İkinci sık hata: yalnızca CVE numarasına bakıp zincir etkisini görmemek. Üçüncü hata: yama sonrası log ve dosya bütünlüğüne bakmamak; oysa yama öncesi sömürü olmuş olabilir. Bu üç noktayı kendi kontrol listenize eklemenizi öneririm.
Ekip içi iletişim şablonu
Yönetime veya müşteriye yazarken teknik jargonu azaltın: hangi varlık etkilendi, internete açık mı, yama var mı, geçici azaltma ne, doğrulama nasıl yapılacak. Tek paragrafta risk + eylem + sahiplik yazmak, uzun CVE özetinden daha hızlı karar aldırır.
Lab not defteri
Bu konuyu kendi defterime şu başlıklarla işliyorum: tarih, kaynak URL, etkilenen ürün/sürüm, internete açık mı, yama komutu, geri alma planı, IOC listesi, kime haber verildi. Siz de benzer basit bir şablon tutarsanız bir ay sonra "ne yapmıştık?" sorusu cevapsız kalmaz.
İzleme ve doğrulama
Değişiklikten sonra en az bir negatif ve bir pozitif kontrol tanımlayın. Negatif: alarm boş yere düşmemeli. Pozitif: bilinen kötü örneği veya beklenen log satırını yakalamalı. İkisini de kaydedin; aksi halde "sanırım düzeldi" ile yetinirsiniz.
Sonuç
Özetle: kaynağı okuyun, kendi envanterinize bağlayın, yama veya azaltmayı uygulayın, sonra doğrulayın. TurkTeam'de yorumlarda kendi ortamınızdan (ürün adı ve sürüm yeter, hassas IP yazmayın) kısa deneyim paylaşırsanız herkes faydalanır.
Adım adım kontrol listesi (kopyala-yapıştır)
- Kaynak duyuruyu ve varsa üretici güvenlik sayfasını arşivleyin (PDF/HTML).
- Envanterde etkilenen ürün var mı diye CMDB / agent raporu / netscan ile bakın.
- İnternete açık mı, yoksa yalnızca iç ağda mı? Buna göre SLA seçin.
- Yama veya yapılandırma azaltmasını stagingde deneyin.
- Üretim penceresinde uygulayın; değişiklik kaydı açın.
- Servis sağlık kontrolü + log doğrulaması yapın.
- Gerekliyse IOC avı veya compromise assessment planlayın.
- Kapanış notunu yazın: sürüm, tarih, kim onayladı.
Sık sorulanlar
Sadece okumak yeter mi? Hayır. Okuduktan sonra envanter satırına bağlanmayan bilgi operasyonel değildir.
PoC çalıştırmalı mıyım? Yalnızca izole lab ve yazılı izinle. İnternette rastgele deneme hem etik dışı hem yasadışı olabilir.
WAF / EDR tek başına kurtarır mı? Katmanlı savunma işe yarar ama yamanın yerini tutmaz; özellikle kimlik doğrulamasız RCE sınıflarında.
Ne zaman yönetime çıkmalıyım? İnternete açık kritik yüzey, aktif sömürü istihbaratı veya veri sızıntısı şüphesi varsa gecikmeden.
Örnek komut defteri
Kod:
# Tarih damgası ve ortam notu
date -Is
hostnamectl 2>/dev/null | head -5 || true
# Ağ dinleme özeti (lab)
ss -lntp | head -30
# Son reboot / güncelleme ipucu (systemd)
who -b 2>/dev/null || trueİlgili TurkTeam bölümleri
Bu yazıyı okuduktan sonra aynı kategorideki komşu konulara ve Soru-Cevap bölümüne kendi lab çıktınızı (hassas veri olmadan) taşıyabilirsiniz. Kısa ekran görüntüsü veya komut çıktısı, uzun teoriden daha çok işe yarar.
Kapanış ve yasal çerçeve
TurkTeam white-hat bir topluluktur. Anlatılan teknikler eğitim, savunma ve izinli test içindir. Başkalarının sistemlerinde izinsiz tarama, sömürü, veri çalma veya "hack hizmeti" sunmak forum kurallarına ve TCK 243, 244, 245 maddelerine aykırıdır. Kendi laboratuvarınızı izolasyonla kurun; üretim verisi kullanmayın. Kaynaklardaki bağlantıları birincil referans kabul edin; bu yazı özet ve yol göstericidir, üretici duyurusunun yerini tutmaz.