Klue ihlali: bir OAuth bağlantısı Salesforce verinizi nasıl sızdırdı?

Klue ihlalinde tam olarak ne oldu?

Klue, satış ekiplerinin rakipleri karşısında kullandığı "battlecard" içeriklerini üreten bir pazar-istihbaratı platformu. İşini yapabilmek için müşterilerinin Salesforce, Gong, HubSpot, Slack gibi sistemlerine bağlanıyor; bu bağlantılar da OAuth üzerinden, yani her müşterinin Klue'ya verdiği erişim izinleriyle kuruluyor. İhlalin temelinde teknik olarak parlak bir açık değil, klasik bir ihmal var: Klue'nun yıllar önce bir prototip entegrasyon için oluşturduğu, sonra unutulmuş ama hâlâ aktif bir kimlik bilgisi.

Saldırgan bu atıl kimlik bilgisiyle Klue'nun arka uç sistemine girdi ve oraya, müşterilerin OAuth token'larını toplayan kötücül bir kod yerleştirdi. Ardından bu token'ları kullanarak — Klue'nun arayüzüne hiç uğramadan — doğrudan müşterilerin Salesforce ve Gong ortamlarına sorgu attı. Olayı raporlayan kaynaklara göre API sorguları yaklaşık 24 saat sürdü, asıl veri sızdırma ise 6 saatlik bir pencerede, 15 dakikalık küçük partiler hâlinde gerçekleşti; böylece anormal trafik dikkat çekmedi. Çalınan veri CRM içeriğiydi: iş bağlantıları, satış yazışmaları, fiyat teklifleri, rakip-analizi notları ve abonelik detayları. Şifreler, ödeme kartları, telemetri ve ürün altyapısı etkilenmedi.

Zaman çizelgesi de olayın ne kadar sessiz ilerlediğini anlatıyor: anormal davranış 11 Haziran'da başladı, Klue durumu 12 Haziran'da fark etti ve müşterilerini 13 Haziran'da uyardı. Nisan 2026'da ortaya çıkan, kendine Icarus adını veren bir şantaj grubu olayı üstlendi ve 16 Haziran'da kurbanlara 48 saatlik ültimatomlu fidye e-postaları göndermeye başladı. Salesforce ise olay soruşturulurken Klue Battlecards entegrasyonunu platform genelinde devre dışı bıraktı.

OAuth token'ı neden bu kadar değerli bir hedef?

Bir SaaS aracını "Salesforce'a bağlan" diyerek yetkilendirdiğinizde arka planda parolanız o araca verilmez; bunun yerine sınırlı bir erişim anahtarı, yani bir OAuth token üretilir. Bu token tek başına şu üç özelliğiyle çok değerli bir hedeftir: kalıcıdır (siz iptal edene kadar genelde geçerli kalır), parolaya gerek bırakmaz (token'a sahip olan, kim olduğunu kanıtlamak zorunda kalmadan veriye ulaşır) ve çoğu zaman ikinci faktörü (MFA) atlar — çünkü MFA giriş anında çalışır, token ise girişten sonra verilmiş bir geçiş kartıdır.

İşin asıl meselesi de burada: bu token'ların ne kadar geniş yetkiyle üretildiğini çoğu kurum hiç sorgulamaz. Bir araç "işimi düzgün yapayım" diye geniş okuma izni ister, siz de kurarken hızlıca onaylarsınız. Sonuç olarak Salesforce'unuzun büyük bölümünü okuyabilen bir anahtar, sizin denetiminizin dışında, üçüncü bir şirketin sunucusunda öylece durur. Klue ihlali tam olarak bu duran anahtarların toplanmasıyla işledi; aracın kendisini kırmaya bile gerek kalmadı.

unutulmuş ama aktif kimlik bilgisi  (prototip entegrasyonu)
   ↓
Klue arka ucuna kötücül kod yerleştirilir
   ↓
müşterilerin OAuth token'ları toplanır
   ↓
token'larla doğrudan Salesforce / Gong sorgulanır
   ↓
CRM verisi ~6 saatte, küçük partiler hâlinde dışarı
   ↓
kurbanın kendi sisteminde tek bir uyarı bile yok

Güvenlik firmaları bile vurulduysa sorun nerede?

Kurbanların arasında Huntress, ReliaQuest, Tanium ve Jamf gibi tehdit avı ve cihaz yönetimi işini meslek edinmiş şirketlerin olması rastlantı değil; tam da meselenin özünü gösteriyor. Bu kurumların kendi parolaları, kendi MFA'ları, kendi günlükleri kusursuz olabilir. Ama zincirin en zayıf halkası onların kontrol ettiği bir yer değildi — satış ekibinin yıllar önce bağladığı, kimsenin "kritik sistem" olarak görmediği bir battlecard aracıydı. Verinizin güvenliği, artık yalnızca sizin hijyeninize değil, eriştiği her aracın hijyenine de bağlı.

Bu, klasik tedarik zinciri saldırısının SaaS dünyasına taşınmış hâli. Daha önce çalınan bir kimliğin koca bir kod zincirine yayılmasını ve ihlallerin neden kimlik katmanından tekrarladığını ele almıştık; Klue olayı bunların kesişiminde duruyor. Burada saldırgan ne sizin koda sızdı ne de sizin parolanızı çaldı; sizin adınıza verilmiş bir izni, o izni saklayan üçüncü tarafta ele geçirdi. Bu yüzden bir SaaS aracını değerlendirirken sorulması gereken soru "bu araç işime yarıyor mu" kadar "bu araç ele geçirilirse benim hangi verim açığa çıkar" sorusudur.

Ekipler bugün ne yapmalı?

Bu olay yüzünden tüm entegrasyonları kapatmanız gerekmez; gereken, görünmeyen erişimleri görünür kılmak ve fazlasını budamak. Sade bir kontrol listesi:

• Bağlı uygulamaları envantere alın — Salesforce, Google Workspace ve Microsoft 365'te "bağlı uygulamalar / OAuth izinleri" ekranını açın. Çoğu kurum buradaki listenin uzunluğuna şaşırır; tanımadığınız ya da artık kullanmadığınız her bağlantı bir risk.
• En az yetki ilkesini uygulayın — her araca yalnızca işini görecek kadar izin verin. Bir battlecard aracının tüm CRM'i okumaya değil, yalnızca ihtiyaç duyduğu alanlara erişmesi yeterli olmalı.
• Token'ları düzenli olarak döndürün ve atılları iptal edin — kullanılmayan entegrasyonların erişimini kaldırın. Klue olayında zincirin başı, yıllar önce unutulmuş ama hâlâ geçerli bir kimlik bilgisiydi.
• Entegrasyon trafiğini izleyin — bir uygulamanın olağandışı hacimde veri çekmesi (Klue'da 6 saatte küçük partiler) erken bir alarmdır. API erişim günlükleri olmadan bu sinyali yakalayamazsınız.
• "Tedarikçim ihlal edildi" senaryosunu planınıza yazın — hangi aracın hangi veriye eriştiğini bilirseniz, bir tedarikçi sızdığında saatler içinde "bizden ne çıkmış olabilir" sorusunu yanıtlayabilirsiniz.

Peki geriye ne kalıyor?

Klue ihlali, bir SaaS aracının ne kadar iyi olduğuyla ilgili bir tartışma gibi değil; kullanmadığımız ama hâlâ açık duran kapılarla ilgili bir hatırlatma olarak okunmalı. Modern bir kurumun verisi artık tek bir kalede durmuyor; birbirine OAuth bağlantılarıyla tutturulmuş onlarca aracın arasında dolaşıyor. Bu bağlantıların her biri size hız ve kolaylık kazandırıyor — ama aynı zamanda güven sınırınızı, çoğu zaman fark etmeden, başkasının altyapısına kadar genişletiyor.

İyi haber, bu riskin yönetilebilir olması; üstelik gereken araçlar yeni değil. Bağlı uygulama envanteri, en az yetki, düzenli token rotasyonu ve erişim günlüklerinin izlenmesi — bunların hepsi kimlik ve erişim yönetiminin yıllardır bildiğimiz disiplinleri. Tek değişen, bu disiplinleri artık yalnızca kendi çalışanlarınıza değil, verinize dokunan her üçüncü taraf araca da uygulamanız gerektiği.

Konunun temellerine daha yakından bakmak isterseniz Bilgi Merkezi · Kimlik & Erişim, Web Uygulama Güvenliği ve API Tasarımı & Entegrasyon rehberlerine göz atabilirsiniz.