- Google, 10 yılı aşkın süredir API anahtarlarının sır olmadığını ve açık olsa da güvenli olduğunu söylüyordu; ancak Gemini API etkinleştirildikten sonra aynı anahtarlar hassas bir kimlik doğrulama aracına dönüştü
- Daha önce Google Maps, Firebase vb. için kullanılan herkese açık anahtarlar, otomatik olarak Gemini API erişim izni kazandı; böylece açığa çıkmış anahtarlarla kişisel verilere erişmek ve ücretlendirme yapmak mümkün hale geldi
- Truffle Security, internette gerçek kullanımda olan 2.863 Google API anahtarının açığa çıktığını ve bunların bir kısmının Google'ın kendi hizmetlerine ait anahtarları da içerdiğini doğruladı
- Google sorunu kabul etti ve sızan anahtarların engellenmesi, Gemini'ye özel varsayılan ayarlar ve maruz kalma bildirimi özelliklerini devreye almaya başladı; ancak mevcut anahtarların geriye dönük taraması henüz tamamlanmış değil
- Bu olay, yapay zeka özelliklerinin entegrasyonu nedeniyle mevcut kimlik bilgilerinin yetkilerinin genişlemesi riskini gösteriyor; geliştiricilerin derhal Gemini API etkinleştirme durumunu ve anahtar maruziyetini kontrol etmesi gerekiyor
Temel sorun
- Google Cloud,
AIza... biçimindeki tekil API anahtarı yapısını kullanıyor ve bu yapı aynı anda hem genel tanımlama hem de hassas kimlik doğrulama amacı taşıyor
- Geçmişte Google, geliştiricilere API anahtarını istemci koduna doğrudan gömmenin güvenli olduğunu açıkça belirtmişti
- Firebase güvenlik kontrol listesinde de “API anahtarı sır değildir” ifadesi yer alıyordu
- Ancak Gemini API etkinleştirildiğinde, mevcut projedeki tüm API anahtarları otomatik olarak Gemini uç noktalarına erişim yetkisi kazanıyor
- Yetki uyarı, onay süreci veya e-posta bildirimi olmadan genişliyor
- Bu durum iki soruna yol açıyor
- Geriye dönük yetki genişlemesi (Retroactive Privilege Expansion): Geçmişte açık olan Maps anahtarları Gemini erişim kimliğine dönüşüyor
- Güvensiz varsayılanlar (Insecure Defaults): Yeni anahtar oluştururken varsayılan ayar “Unrestricted” olduğundan, Gemini dahil tüm API'lere erişim mümkün oluyor
- Sonuç olarak binlerce faturalandırma amaçlı token gerçek kimlik doğrulama bilgisine dönüşmüş halde internette açıkta bulunuyor
Olası saldırı senaryosu
- Saldırgan, bir web sitesinin kaynak kodundan
AIza... anahtarını kopyalayıp basit bir curl isteğiyle Gemini API'ye erişebilir
- Saldırgan bununla
- Özel verilere erişebilir (
/files/, /cachedContents/ uç noktaları)
- Gemini API kullanım ücretlerini mağdura yansıtabilir
- Kotayı tüketerek hizmet kesintisine yol açabilir
- Saldırganın kurbanın altyapısına sızması gerekmez; yalnızca herkese açık web sayfalarından anahtarı çıkararak saldırıyı gerçekleştirebilir
Açığa çıkan anahtarların ölçeği
- Truffle Security, Common Crawl 2025 Kasım veri kümesini (yaklaşık 700TiB) analiz ederek aktif 2.863 Google API anahtarı buldu
- Bu anahtarlar başlangıçta Google Maps gibi herkese açık hizmetler için kullanılıyordu, ancak Gemini API erişim iznine sahipti
- Etkilenenler arasında finans kuruluşları, güvenlik şirketleri, küresel işe alım firmaları ve Google'ın kendisi de vardı
- Google bile aynı yapısal riskten etkilenmiş durumdaydı
Google iç anahtarı vakası
- Truffle Security, Google ürün web sitesinin herkese açık kaynak kodunda bulunan bir anahtarla Gemini API erişimini gösterdi
- Bu anahtar 2023 Şubat ayından önce de açıktaydı ve başlangıçta yalnızca basit proje tanımlaması için kullanılıyordu
/models uç noktasına yapılan çağrı geçerli yanıt (200 OK) döndürdü ve hassas API erişiminin mümkün olduğunu doğruladı
- Yani bu, geçmişte zararsız olan bir anahtarın geliştirici müdahalesi olmadan hassas yetkiler kazanması anlamına geliyor
Güvenlik açığı bildirimi ve müdahale zaman çizelgesi
- 21 Kasım 2025: Google VDP'ye raporlandı
- 25 Kasım: Google bunu “amaçlanan davranış” olarak değerlendirdi
- 1-2 Aralık: Truffle Security, Google iç anahtar vakasını sunduktan sonra Google, durumu yeniden hata olarak sınıflandırdı ve ciddiyet düzeyini yükseltti
- 12 Aralık: Google, sızan anahtar tespit hattını genişletme ve Gemini erişimini sınırlama önlemlerini başlattı
- 13 Ocak 2026: Google, açığı “tek hizmette yetki yükseltme (Single-Service Privilege Escalation, READ)” olarak sınıflandırdı
- 2 Şubat: Kök neden düzeltmesi üzerinde çalışıldığı doğrulandı
Google'ın sonraki adımları
- Google, resmi belgelerinde şu güvenlik güçlendirme planlarını duyurdu
- Scoped defaults: AI Studio'da oluşturulan yeni anahtarlar yalnızca Gemini'ye özel erişime izin verecek
- Leaked key blocking: Sızmış anahtarların Gemini API erişimi otomatik olarak engellenecek
- Proactive notification: Sızan anahtar tespit edildiğinde kullanıcıya anında bildirim gönderilecek
- Bazı iyileştirmeler zaten uygulanıyor; ancak mevcut açık anahtarların geriye dönük denetimi ve kullanıcı bilgilendirmesi henüz tamamlanmadı
Geliştirici kontrol rehberi
- 1. adım: Tüm GCP projelerinde Generative Language API'nin etkin olup olmadığını kontrol edin
- 2. adım: Etkinse, API anahtarı ayarlarında “Unrestricted” olan veya Gemini'yi kapsayan anahtarları belirleyin
- 3. adım: Bu anahtarların açık kodda veya web sayfalarında yer alıp almadığını kontrol edin
- Açığa çıkmış anahtarlar derhal rotate edilmeli
- Bonus: TruffleHog aracı kullanılarak Gemini erişimine sahip gerçek kullanım anahtarları otomatik olarak tespit edilebilir
- Komut örneği:
trufflehog filesystem /path/to/your/code --only-verified
Sonuç
- Bu olay, yapay zeka özelliklerinin eklenmesi nedeniyle mevcut açık kimlik bilgilerinin hassas yetkiler kazanabildiği yapısal riski ortaya koyuyor
- Google sorunun farkında ve müdahale ediyor; ancak güvenli varsayılanların ve anahtar ayrımı tasarımının önemi bir kez daha öne çıkıyor
- Geliştiriciler ve şirketler, Gemini API etkinleştirme durumunu ve anahtar maruziyetini derhal kontrol etmeli
1 yorum
Hacker News görüşleri
Google AI Studio belgeleri, uygulamaların açık proxy üzerinden dağıtılmasını öneriyor
Bu yaklaşım, API anahtarının proxy arkasında olduğu için güvenli olduğu yanılgısını yaratıyor, ancak gerçekte AI faturalandırmasının kötüye kullanılmasını mümkün kılıyor
Yapay zeka özelliği hiç olmayan uygulamalar bile, anahtar kapsamı manuel olarak kısıtlanmadıysa yüksek maliyetli modellere açık hale geliyor
Bu tür savunmasız uygulamalar Google, Twitter, Hacker News aramalarıyla bile kolayca bulunabiliyor
İlgili analiz bu yazıda derlenmiş
Google sızdırılmış anahtarları engellediğini söylüyor, ancak baştan beri bu anahtarları gizli olarak değerlendirmiyordu
İdeal olan, Gemini yayımlanmadan önce oluşturulan tüm anahtarların Gemini’ye erişememesini sağlamaktı
Eğer sızıntı tespit sistemi yanlış pozitif üretiyorsa, meşru Gemini anahtarlarının da engellenme riski var
En azından Generative Language API izinlerinin tüm mevcut anahtarlardan kaldırılması gerekir, ama bu bile tam bir çözüm değil
Sonunda bu iznin tüm anahtarlardan topluca kaldırılması gerekebilir
Bu, sayısız uygulamayı bozacaktır ve Google’ın sorunu kabul etmek istememesinin nedeni de bu olabilir
Daha da ciddi olan, anahtarların önbelleğe alınmış bağlamı ve yüklenen verileri de açığa çıkarıyor olması
Eski Android imajlarına hardcode edilmiş Google anahtarlarının gerçekten Gemini’de kullanılabildiği fark edilmiş
Bazıları zaten çok kişi tarafından kullanıldığı için hız sınırına takılmıştı, ancak birkaçı hâlâ çalışıyordu
Yaklaşık iki ay önce bu anahtarlar sızmış kabul edilerek tamamen devre dışı bırakılmış
Uzun zaman önce oluşturulmuş anahtarlar aslında Firebase veya Firestore gibi sınırlı hizmetler içindi
Ancak Gemini çıktıktan sonra, mevcut anahtarlarda Gemini erişimi otomatik olarak etkinleştirildi ve istismar edilmesi kolaylaştı
APK dosyasına gömülü herkese açık anahtarlar, fiilen Gemini erişim anahtarına dönüşmüş oldu
Örneğin geliştirici X, Maps için bir anahtar oluşturur ve aynı projedeki başka bir geliştirici Y Gemini’yi açarsa
X’in anahtarı Gemini erişim izni kazanıyor
Bu yüzden proje yeniden kullanımından kaçınılmalı ve hizmet bazında ayrılmış GCP projeleri kullanılmalı
Bu kadar bariz bir güvenlik kusurunun neden önceden yakalanmadığı sorgulanıyor
Google gibi büyük bir şirkette standartlaştırılmış testler veya spesifikasyonlar olması gerekirdi
Organizasyon büyüyüp karmaşıklaştıkça bu tür gözetim kör noktaları daha da artıyor
ama onlar hâlâ sadece ikili ağacı ters çevirme sorularına odaklanıyordu
Bu olay, geçmişteki SSN (Sosyal Güvenlik Numarası) istismarı vakalarını hatırlatıyor
Başlangıçta sadece basit bir kimlik numarasıyken, bir noktada kimlik doğrulama anahtarı olarak kullanılmaya başlanmasıyla sorunların büyümesi gibi
Hızlı ve ucuz uygulama tercihlerinin bedeli sonunda kullanıcılara yıkılıyor
Google’ın bu sorunu hâlâ tamamen çözememiş gibi göründüğü söyleniyor
Gemini’yi aceleyle piyasaya sürerken yapılmış büyük bir hata ve
sorunu düzeltmek için mevcut anahtarları devre dışı bırakmak gerekirse müşteri iş akışlarının bozulma ihtimali yüksek
Google açısından da son derece yıkıcı bir itibar kaybı anlamına geliyor
Bu, bir tür geriye dönük yetki genişlemesi (Retroactive Privilege Expansion) sorunu
Eskiden Maps anahtarlarını web sitelerinde açıkça yayımlamak mümkündü, ancak ekipteki başka bir geliştirici Gemini’yi açtığında
o herkese açık anahtar anında Gemini erişim yetkisine dönüşüyor
Sonuç olarak herkes bu anahtarla dosya yüklemelerine veya önbellek verilerine erişebilir hale geliyor
Eski belgelere uyarak açık anahtar kullanan kullanıcılar şimdi zarar görüyor
Saldırganlar o anahtarı çalıp faturalandırma şoku yaratabilir
Basitçe anlatmak gerekirse, binlerce mevcut API anahtarı yalnızca faturalandırma belirteci olmaktan çıkıp
bir anda Gemini erişim kimliğine dönüşmüş durumda
Maps API anahtarları aslında kullanıcılara harita hizmeti sunulurken ödemenin benim kartımdan alınması için tasarlanmıştı
Sorun, bu anahtarların artık Gemini’ye de erişebilmesi
Dahili kullanım için ayrı projeler oluşturulup anahtarlar ayrılmalıydı,
ama hızlı yayımlama uğruna LLM’in ürettiği kod olduğu gibi kullanılıp sorun çıkınca suç Google’a atılıyor
Bu sorunu analiz eden güvenlik şirketinin önceki araştırmaları da etkileyiciydi
Örneğin “Anyone can Access Deleted and Private Repository Data on GitHub” yazısında
silinmiş ve özel GitHub depo verilerine erişim açığını ortaya çıkarmışlardı
Bu kez de onların analizi çok yardımcı olmuş