Google'ı yapay zekayla hackleyip 700 milyon won kazanmak

• Yapay zekaya Google'ın API'lerini otomatik olarak durmadan yoklatmanın sonucunda, bir güvenlik araştırmacısı 3 ayda 500 bin dolar bug bounty geliri elde etti
• 60.000'den fazla Android uygulamasından toplanan API anahtarları ile Google'ın API spesifikasyonlarını (discovery document) birleştirerek, dışarıda pek bilinmeyenler dahil 1.500'den fazla API test kapsamına alındı
• Claude tabanlı yapay zekaya bir API test aracı bağlanarak, insan gibi istek göndermesi ve yetki kontrolü eksik erişim kontrolü açıklarını otomatik bulması sağlandı
• Google Voice hesap ele geçirme, YouTube özel videolarının sızdırılması, Widevine DRM anahtarlarının açığa çıkması, Nest cihaz sahiplerinin kimliğinin izlenmesi gibi çok sayıda ciddi açık bulundu
• Çoğu, gelişmiş saldırılardan değil; yetki kontrolü eksikliği, kimlik doğrulamasız API'ler, gerçek veriyi olduğu gibi açığa vuran test ortamları gibi tekrar eden temel hatalardan kaynaklandı

---

Araştırmanın çıkış noktası

• 2025 Ekim'deki bugSWAT Mexico davetiyle birlikte Google üzerine araştırmalara yeniden odaklanıldı; Google kaynak kodunun bir kısmına bakılabilmesi özellikle ilgi çekiciydi
• Son 1 yılda Claude ile küçük projeler geliştirirken, bunu Google API'lerini büyük ölçekte otomatik test etmek için kullanma potansiyelinin yüksek olduğu sonucuna varıldı
• Temel giriş noktası discovery document idi — Google'ın Swagger benzeri dokümanı; tüm endpoint, parametre ve metodları makinenin okuyabileceği şekilde tanımlıyor
  • YouTube Data API gibi herkese açık olanlar var, ancak Internal People API gibi iç API'lerde de bulunuyor
  • Bazılarına doğrudan erişilebiliyor ama çoğu için geçerli bir API anahtarı gerekiyor

API anahtarı toplama

• Bir serviste bulunan bir anahtarın, aynı GCP projesindeki başka birçok API için de aktif olduğu sık görüldüğünden, ne kadar çok anahtar toplanırsa erişilebilen API kapsamı da o kadar genişledi
• Arkadaşı Michael ile iş birliği içinde anahtar toplandı
  • Google uygulamalarının tüm sürümlerini içeren 61.200 Android APK indirildi, açıldı ve içlerinden API anahtarları tarandı
  • Chrome Debugger API tabanlı bir eklentiyle trafik yakalanarak, bilinen yaklaşık 2.800 Google web alanı ziyaret edilirken gerçek zamanlı isteklerden anahtar toplandı
  • Google iOS uygulamalarının (IPA) şifresini çözme ve erişilebilen Google binary'lerini analiz etme çalışmaları da paralel yürütüldü

• Yalnızca Google anahtarlarını ayıklama

  • VRP kapsamına uymak için Cloud Marketplace API üzerinden anahtara bağlı proje bilgileri sorgulanarak Google dışı anahtarlar elendi
  • Yetkisiz bir API'de anahtar denendiğinde dönen hatada proje numarası görünüyordu (ör. "...in project 244648151629...")
  • Bu numarayla yapılan sorguda company alanı proje sahibinin alan adını verdiği için, google.com ile birlikte nest.com, fitbit.com, wing.com gibi satın alınan şirketler dışındaki anahtarlar atıldı

Çalışan Google API alan adlarını bulma

• Eklentinin kaydettiği alan adları, anahtar kelime tabanlı kaba üretim ve certificate transparency kayıtları birleştirilerek aday alan adları çıkarıldı
• Her alan adına istek gönderilip Server başlığının ESF, GSE veya scaffolding on HTTPServer2 olması durumunda bunun çalışan ve geçerli bir Google API olduğu kabul edildi

Gizli spesifikasyonları da çekip çıkarma

• Google 2025 Temmuz'unda çoğu API'de /$discovery/rest yolunu kaldırmış olsa da, bazılarında dolaylı yollardan erişim mümkün kaldı

• Visibility Label ile gizlenmiş endpoint'ler

  • Bazı projelerde visibility label etkin olduğundan, yalnızca labels parametresi verildiğinde görülebilen gizli endpoint'lere erişilebildi
  • Service Management API spesifikasyonu etiketsiz alındığında 253KB iken, ?labels=GOOGLE_INTERNAL eklendiğinde 329KB'a çıkıyor ve çok sayıda gizli doküman açığa çıkıyordu
  • Bir seferde yalnızca tek bir label alınabildiği için, tüm label + tüm anahtar + tüm API kombinasyonlarını denemek üzere çok büyük hacimde istek gerekti
• Böylece 1.500'den fazla API spesifikasyonu toplandı ve geçmiş araştırmalardan biriken belgelerle birleştirilerek yapay zekalı otomatik test için hazırlık tamamlandı

Kimlik doğrulama sorununu çözme

• API anahtarlarıyla "yetki" kısmı çözülse de, pek çok endpoint çağıranın kim olduğunu doğrulayan ayrı bir authentication mekanizması istiyordu
• Bearer token'lar GCP projelerine bağlı olduğundan, API anahtarıyla karıştırıldığında "farklı projeler" hatası oluşuyordu; bilinen bir bypass yoktu

• First Party Authentication (FPA)

  • Google'ın birçok API'de desteklediği özel kimlik doğrulama yöntemi FPA, API anahtarlarıyla birlikte çalışabiliyordu
  • Web istekleri oturum Cookie'si ile bundan türetilen Authorization değerini içeriyor ve *.clients6.google.com host'una gönderiliyordu
  • drivefrontend-pa gibi bazı API'ler, e-posta gibi kullanıcı tanımlayıcılarını hash'e ekleyen daha tam bir FPA v2 başlığı gerektiriyordu
  • Michael, Google'ın bir süre yanlışlıkla sızdırdığı sourcemap'i buldu ve içte kullanılan gapix kütüphanesinden FPA v2 başlığı üretim kodu çıkarıldı

• Token yapısı ve Gaia ID

  • Token biçimi <timestamp>_<hash>_<identifierkey> ve SHA1 girdisi "email:gaiaId timestamp sessionCookie origin" şeklindeydi
  • Tanımlayıcı anahtar yalnızca üç türdü: e (e-posta), u (obfuscate edilmiş Gaia ID), a (Workspace alanı); diğer harfler backend tarafından yok sayılıyordu
  • Gaia, "Google Accounts and ID Administration"ın kısaltması ve her hesabın sıralı unobfuscated Gaia ID'si (ör. 131337133377) ile uzun bir obfuscate edilmiş kimliği bulunuyordu

• Origin whitelist'i ve anahtar kısıtları

  • Birçok API'nin izin verilen Origin listesi vardı; izin verilmeyen bir origin kullanıldığında, çerez sorunu sanılabilecek SESSION_COOKIE_INVALID hatası dönüyordu
  • Anahtarlarda Server, Browser, Android, iOS olmak üzere dört kısıt türü vardı; Browser için Referer, iOS için X-Ios-Bundle-Identifier, Android için X-Android-Package ve sertifika parmak izi eşleşmesi gerekiyordu
  • Anahtar toplama sırasında bu değerler de kaydedilerek brute-force süreci aynı programa dahil edildi
  • *.corp.google.com origin'inde kısıt olmaması, bu API'lerin dış kullanım için değil iç kullanım için tasarlanmış olabileceğini ve daha çok hata barındırdığını gösteriyordu — bir örnek erişim kontrolü açığı için 9.000 dolar ödül verildi

İstek akış haritası ve özel test aracı

• Bir isteğin hangi aşamada reddedildiğini sınıflandıran bir program geliştirildi: metod çözümleme → anahtar geçerliliği → anahtar kısıtı → kimlik doğrulama → origin kontrolü → label vb. Böylece hangi anahtarın hangi API'de işe yaradığını gösteren bir eşleştirme tablosu çıkarıldı
• Google'ın API Explorer'ı yalnızca açık API'leri desteklediğinden ve kapalı kaynak olduğundan doğrudan kullanılamadı; bunun yerine FPA v2 desteğine kadar uzanan özel bir API Explorer yaklaşık bir haftada yazıldı
  • Spesifikasyonlar istemci tarafında parse edilerek geçerli istek/yanıt JSON'u otomatik oluşturuldu ve rastgele payload'ları hızlıca denemeye yarayan bir arayüz sağlandı
  • Demoda kullanılan endpoint, assignedTams (teknik hesap yöneticileri) bilgisini sızdıran bir erişim kontrolü hatasıydı ve 6.000 dolar ödül getirdi

Yapay zekalı otomatik test kurgusu

• Amaç, temel erişim kontrolü sorunlarını yapay zekanın otomatik bulması, ardından insanların bunları daha ciddi açıklara dönüştürmesiydi
• Frontend'deki JSON parse kodu MCP aracı olarak yapay zekaya bağlandı; böylece bir insan gibi API testi yapması sağlandı

• Daha kapsamlı, daha sessiz

  • İlk denemelerde yapay zeka birkaç yoklamadan sonra erken bitirdiği için, Ralph Wiggum loop ile tüm endpoint'leri en az bir kez test etmeden sürecin bitmesine izin verilmedi
  • Endpoint'ler önce mantıksal gruplara ayrıldı, testler grup bazında yapıldı ve önceki gruplardaki bulgular sonraki gruplara aktarıldı
  • probe_api girdisi endpoint, path, body etrafında sadeleştirildi; karmaşık FPA kimlik doğrulaması backend tarafından ele alındı, böylece yapay zeka yalnızca payload yazımına odaklandı
  • Her anahtarla farklı yanıt dönebileceğinden, aynı istek tüm anahtarlarla otomatik gönderildi ve aynı yanıtlar hash'lenerek gruplanıp düzenlendi
  • Method not found gibi kafa karıştırıcı hatalar, yapay zekanın şaşırmaması için MISSING_REQUIRED_VISIBILITY_LABEL gibi açıklayıcı karşılıklara çevrildi

• Gürültü ve doğrulama sorununu çözme

  • İlk aşamada gerçek açıklar %90 oranındaki gürültü içinde kayboldu; iki temel sorun öne çıktı: doğrulamanın zorluğu ve aşırı false positive
  • Raporlara, gerçek isteğe işaret eden operation ID eklendi; böylece frontend üzerinde "Play" ile yeniden üretilebiliyor ve değiştirilemez kanıt elde ediliyordu
  • Bir aydan uzun süre sistem prompt'u iyileştirilerek raporlama kriterleri netleştirildi — yalnızca başka kullanıcı verisine erişim ya da 4xx dönmesi gerekirken 2xx dönen durumlar kabul edildi; basit existence enumeration ise açık kapsamı dışında bırakıldı
  • Sonrasında yapay zeka %50'nin üzerinde doğrulukla çok sayıda açık bulmaya başladı; tek gerçek sınır eldeki API anahtarı sayısıydı

Bulunan başlıca açıklar

• 3 aydan kısa sürede 500.000 dolar değerinde açık bulundu; aşağıdakiler düzeltilmiş öne çıkan örneklerden bazıları

• Google Voice hesap ele geçirme

  • gfibervoice-pa üzerinde hiç erişim kontrolü yoktu; kimlik doğrulamasız tek satırlık bir curl ile kurbanın unobfuscated Gaia ID'si biliniyorsa telefon numarası, bildirim adresleri gibi tüm PII dökülebiliyordu
  • Yanıtta, kurbanın Google hesap kurtarma telefon numarası da görülebiliyordu (yalnızca belirli koşullarda görünüyordu; tam koşullar Google tarafından açıklanmadı)
  • Rastgele hesaplara Voice numarası zorla atayan bir endpoint de vardı (500 hatası dönse bile numara gerçekten ekleniyordu); ayrıca SIM swap ihtimali taşıyan bir endpoint de bulundu
  • P0/S0 olarak sınıflandırıldı, saatler içinde yamalandı ve 20.000 dolar ödül verildi
  • Yamanın hemen ardından /btz gibi intranet'e özel zhandler yüzeylerinin açığa çıktığı görüldü; /flagz erişilebilirse çalışan servisten API anahtarı çekilebiliyordu

• AdExchange hesap ele geçirme

  • Tüm AdExchange hesap listesini tek istekle döken bir endpoint bulundu
  • Üretimde engellenmiş bir hesap endpoint'i, staging ortamında erişim kontrolü olmadan çalışıyordu ve bu staging gerçek üretim verisine bakıyordu
  • Rastgele bir hesaba kendini ADMIN olarak eklemek de mümkündü; iki rapor toplamda 30.000 dolar getirdi

• eldar.corp.google.com

  • İç gizlilik değerlendirmesi yönetiminde kullanılan, Googler'lara özel Eldar sitesinin API'si dışarıya açılmıştı; Googler olmayan kullanıcılar iç log erişim talepleri gibi hassas bilgileri sorgulayabiliyordu
  • Engellendikten sonra bile başka sandbox adreslerinden ulaşılabildiği ayrıca bildirildi; toplam 26.674 dolar ödül alındı

• YouTube özel videolarının sızması

  • Video yüklenirken oluşturulan asset adı Auto generated asset - <video_id> biçiminde olduğundan, sadece arama yaparak özel video ID'leri sızdırılabiliyor ve videolar izlenebiliyordu
  • 30 saniyede bir istek atılarak partnerlerin yüklediği özel videoların gerçek zamanlı akışı elde edilebiliyordu — şirketlerin ürün tanıtım videolarını önceden özel yükleme pratiği nedeniyle bu durumun prediction market üzerinde içeriden bilgiyle bahis için kötüye kullanılabileceği belirtildi
  • 12.000 dolar ödül verildi (yüksek rapor kalitesi)

• Widevine DRM anahtarlarının açığa çıkması

  • Disney, Netflix vb. tarafından kullanılan dünyanın en büyük DRM sistemlerinden Widevine'ın partner portalı API'sine herkese açık erişim vardı
  • Tüm organizasyon listesini dökmek, belirli bir organizasyonun PGP ve AES anahtarlarını görmek ve çözmek, rastgele bir organizasyona kendini ekleyip cihaz yönetimi yapmak mümkündü
  • 16.004,40 dolar ödül verildi (yüksek rapor kalitesi)

• plx.corp.google.com

  • Çalışanlara özel iç analiz platformu PLX'in altyapısındaki DataHub API'si açığa çıkmıştı; aktif çalışan bilgi tablolarının metadata'sı sorgulanabiliyordu
  • Staging API'de setIamPolicy ile dataset admin yetkisi kendine eklenebiliyor, böylece gizli YouTube verileri (2,1PB boyuta ulaşan tablolar dahil) dökülebiliyordu
  • 1 saat içinde P0/S0 kabul edildi; iki ayrı açık için ayrı ayrı 12.000'er dolar ödül verildi

Translation Hub'daki cross-tenant açıklar

• Büyük ölçekli doküman çeviri yönetim ürünü Translation Hub'da çok sayıda erişim kontrolü sorunu bulundu
• ListOperations, OAuth token olmadan çalışıyor; iç servis hesabı adları, GCS bucket adları ve iç tablo adları sızıyordu
• Herhangi bir Google hesabının bearer token'ı ile çevirmen e-postaları ve işlere ait gizli dosya adları gibi başka projelere ait verilere erişilebiliyordu
• UpdateProjectConfig ile kurbanın ayarları rastgele bir GCS yoluna çevrilirse, paylaşılan servis hesabı yetkileri kötüye kullanılarak özel GCS nesneleri base64 olarak dışarı alınabiliyordu
• Üç açığın toplam ödülü 36.500 dolar oldu

YouTube TV CMS

• Rastgele videolara strike, claim ve monetize işlemi uygulanabilen YouTube CMS hesap API'sinde, campaign endpoint'inin çağıran ile ilişkiyi hiç kontrol etmediği görüldü
• GET /v1/campaigns, herhangi bir scope olmadan sistemdeki tüm campaign'leri küresel olarak döküyor, ayrıca yalnızca ID ile değiştirme, kopyalama ve silme yapılabiliyordu
• Yan etki olarak hassas CMS hesap e-postaları da sızdı; 24.000 dolar ödül verildi (yüksek rapor kalitesi)

Vertex AI Search for Commerce

• Perakende arama ve öneri ürünündeki conversationalSearchCustomizationConfig, erişim kontrolü olmadan rastgele projelerin ayarlarını okuma ve değiştirmeye izin veriyordu
• Okuma sırasında müşterinin sistem prompt'u (model preamble) ve iç politika notları eklenmiş sınıflandırma örnekleri açığa çıkıyordu
• Yazma tarafında ise müşteriye dönük arama yapay zekasının sistem prompt'una prompt injection payload'ı enjekte etmek mümkündü; ödül 30.000 dolar oldu

Cloud Console GraphQL

• İnternete açık olmayan iç servisler bile proxy yüzeyi üzerinden dolaylı erişilebilir hale gelebiliyor; Cloud Console'un kod adı olan Pantheon, gRPC backend'ini GraphQL ile proxy'liyordu

• İmza doğrulamasını atlatma

  • Her istekte sorgu imzası (querySignature) doğrulanarak manipülasyon zorlaştırılıyordu, ancak staging'deki kimlik doğrulamasız sorgularda imza doğrulanmıyordu
  • Introspection ile 3.448 şema çekilip GitHub'a arşivlendi; ardından "query path" kavramı eklenerek mevcut yapay zekalı fuzzing altyapısına GraphQL desteği entegre edildi

• App Engine istek logları

  • GetDashboardAppStats, IAM doğrulaması olmadan — hatta kimlik doğrulaması bile istemeden — rastgele bir projenin 24 saatlik App Engine loglarını döndürüyordu
  • İstek URL'lerinde parola sıfırlama linkleri, token'lar vb. bulunabildiğinden, 18.000 dolar ödül verildi ve CVE-2026-8934 atandı

• Vertex Assistant

  • 5GB'lık frontend JS analiz edilerek gizli deneysel özellik Vertex Assistant tespit edildi ve feature flag DevTools üzerinden zorla etkinleştirildi
  • İlgili sorguların tamamı yalnızca userId ile, üstelik kimlik doğrulaması olmadan çalışıyordu; hedefin e-postasını bilmek, oturum listesini ve tüm konuşma geçmişini görüntülemek ve değiştirmek için yeterliydi; ödül 30.000 dolar oldu

• Maps Platform faturalama kredileri

  • ListBillingAccountCredits, yetki kontrolü olmadan çalışıyor ve wildcard ile çok sayıda müşterinin kredi bilgilerini döndürüyordu
  • Google çalışanlarının onay sırasında yazdığı müşteriye ait PII, justification alanında olduğu gibi görünüyordu; ödül 12.000 dolar oldu

Sonuç ve çıkarımlar

• Bu kurulumla 3 ay içinde 500.000 doların üzerinde bounty elde edildi; yayımlananlar bunun yalnızca bir kısmı
• Google'daki açıkların çoğunda kilit unsur gelişmiş exploit'ler değil, sabır oldu; aynı bozuk kalıplar her yerde tekrar etti — eksik IAM kontrolleri, kimlik doğrulamasız GraphQL, prod üzerindeki debug endpoint'leri, gerçek veriye işaret eden sandbox'lar
• Yapay zekanın rolü yenilik üretmekten çok, insanların sonuna kadar elle uğraşamayacağı kadar geniş bir yüzeyde apaçık şeyleri yorulmadan tekrar tekrar doğrulamak oldu
• Temel çıkarımlar
  • operation_id tabanlı yeniden üretim sistemi, iş akışını verimli hale getiren belirleyici unsurdu — tek tıkla doğrulama olmadan yapay zeka çıktısı işe yaramaz gürültüye dönüşüyor
  • discovery doc, GraphQL SDL ve proto elde edildiğinde yapay zeka anlamlı biçimde test edebileceği girdileri anlayabiliyor
  • Google'ın sunucu tarafı yüzeyi son derece standart olduğundan, altyapı farklılıkları yapay zekadan soyutlandığında asıl API testine daha fazla odaklanmak mümkün oluyor

[j2sus91]

Vibe coding’in gerçek anlamda yeni nesil gelir modeli bu galiba.