Analiz Rapor Otopsisi 2: Google'ın Kendi Destek Sisteminde 15.000$'lık PII Sızıntısı (ve "Fixed" Yalanı)

Kaynak: michaeldalton.au/posts/hacking-google-support ve bughunters.google.com/reports/vrp/VBbY59QXh — halka açık, tüm teknik detaylar Google Bug Hunters ve araştırmacı (Michael Dalton) tarafından zaten yayınlanmış. Ben burada kendi yorumumu ve çıkardığım dersleri ekliyorum.

Genişletmek için tıkla ...

​

Bu Rapor Neden Beni Bu Kadar Etkiledi?​

• Google'ın "discovery document" mekanizmasının, gizli/dokümante edilmemiş API yüzeyini nasıl ortaya çıkardığı,
• Bir endpoint'in URL'sinde "kaynak ID'si" olup olmamasının, arkasında yetkilendirme katmanı olup olmadığına dair nasıl bir sinyal verdiği,
• Sıradan görünen bir "değişiklik listesi" endpoint'inin neden milyonlarca kaydı sızdırabildiği,
• Ve "Google düzelttik dedi" ile "gerçekten düzeldi" arasındaki farkın neden araştırmacının kendi sorumluluğunda olduğu.

Önce Künyeye Bakalım​

Önce Şu Kavramları Netleştirelim​

Benim kuralım: Bir uygulamanın arayüzünde (UI) görünen özellik sayısı ile, altındaki API'nin gerçekte sunduğu metod sayısı arasında fark olduğunu varsayarım. UI sadece "kullanılan" yüzeyi gösterir; "var olan" yüzeyi görmek için API'nin kendi self-documentation mekanizmasına bakmak gerekir.

Genişletmek için tıkla ...

Peki Burada Tam Olarak Ne Bozuk?​

POST /v2/changes:list HTTP/2
Host: realtimesupport.clients6.google.com
Cookie: <redacted>
Authorization: SAPISIDHASH <redacted>
X-Goog-Api-Key: AIzaSyB5V4SIBGmrqREm7kf2fBJgPcBMCdUrLzE
Origin: https://support.google.com
Content-Type: application/json

{
  "includeInitialSnapshot": true,
  "timeRange": {
      "startTimestamp": "1735713335000",
      "endTimestamp": "1735713345000"
  }
}

{
  "initialSnapshot": {
    "phoneSupportRequestDiff": [{
      "phoneSupportRequestId": "00000000-0000-0000-0000-000000000000",
      "after": {
        "caseId": "6-1234567891234",
        "agentId": "01189998819991197253",
        "customerInformation": {
          "customerPhoneNumber": "+61 2 8503 8000"
        },
        "callType": "CALLBACK"
      }
    }],
    "agentDiff": [{
      "agentId": "01189998819991197253",
      "after": {
        "jid": "sergeybrin@google.com",
        "preferredName": "Sergey",
        "status": "AVAILABLE",
        "activityStatus": { "label": "Chat" }
      }
    }]
  }
}

Araştırmacı Buraya Nasıl Geldi?​

1. Domain anomalisi: Destek widget'ının `clients6.google.com` üzerinde çalıştığını fark edip, bunun gizli bir private API olduğunu çıkarıyor.
2. API anahtarını çıkarma: Client-side JS dosyasında sabit kodlanmış anahtarı buluyor.
3. Yüzeyi büyütme: Discovery document ile 93 metod buluyor widget'ın arayüzü sadece 14'ünü kullanıyor, yani 79 metod hiç test edilmemiş, "kör nokta" durumunda.
4. Sistematik tarama + örüntü tanıma: Minimal bir temel istek kurup discovery document'teki her metodu deniyor. Kritik gözlem: URL'sinde bir kaynak ID'si olan endpoint'ler (`/v2/agents/{agent_id}ools`) hep 403 Permission Denied veriyor yani bir ara katman (middleware) bu ID'yi kontrol ediyor. Ama URL'sinde kaynak ID'si olmayan endpoint'ler farklı davranıyor: 400 Invalid Argument, yani istek daha ileri bir noktada başarısız oluyor.
5. Önceliklendirme: "ID yok → farklı/daha zayıf kontrol noktası" örüntüsünü kırmızı bayrak olarak işaretleyip bu sınıftaki metodları önceliklendiriyor.

Benim genel ilkem: Bir API'de aynı sınıftaki farklı endpoint'ler farklı hata kodlarıyla başarısız oluyorsa (403 vs 400 gibi), bu genelde "aynı yetkilendirme katmanından geçmiyorlar" anlamına gelir. Hata kodu farkı, içeride farklı bir kod yolu olduğunun dışarıdan görülebilen izidir — tıpkı ilk yazımızdaki compile oracle mantığı gibi.

Genişletmek için tıkla ...

Peki Etkisi Ne Olabilirdi?​

• Ajan deanonymization: Gerçek ad, @google.com e-posta adresi, ve dakika dakika aktivite durumu ("Lunch", "Coaching", "Twitter Support" gibi etiketler) bu, bireysel ajanların mesai programının çıkarılabilmesi anlamına geliyor (stalking riski).
• Müşteri PII'si: Telefon görüşmesi yapan her müşterinin redakte edilmemiş telefon numarası, hangi ajan ve case ile eşleştiği.

Burada Durmak da Bir Beceridir​

• Sadece 4 başarılı çağrı yapmış, daha fazlasını denememiş.
• `cbfConversationId` alanının chat içeriğine erişim sağlayabileceğini fark etmiş ama verinin hassasiyeti nedeniyle bunu denememiş.
• Telefon çağrılarını transfer etme gibi başka olası aksiyonları da not etmiş ama test etmemiş.
• Şokun ardından hemen, gece yarısından kısa süre sonra raporu yazmaya başlamış.

"Fixed" Demek Düzeldi Demek Değildir​

• 1 Haziran 2025: Rapor gönderiliyor.
• 2 Haziran: Triyaj + P1/S1 olarak kabul ("Nice catch!").
• 10 Haziran: Google $14.337 + $1.000 bonus ödül veriyor ve raporu kapatıyor.
• 27 Eylül 2025: Araştırmacı zafiyeti yeniden test ediyor — hâlâ çalışıyor.
• 29 Eylül: Google, ürün ekibinin kök sorunu hâlâ düzelttiğini doğruluyor.
• 12 Kasım 2025: Rapor gerçekten "fixed" olarak kapanıyor — ilk rapordan 164 gün sonra.

Benim genel ilkem: Bir programın "resolved/fixed" etiketi benim için bir iddiadır kanıt değil. Özellikle yüksek etkili bulgularda fix'in yayına girdiği iddia edilen tarihten sonra bir kontrol turu atmak raporun gerçek değerini koruyor.

Genişletmek için tıkla ...

Benden Size Çıkarımlar​

1. Bir API'nin UI'da kullanılan kısmı ile gerçekte sunduğu tüm yüzey arasındaki farkı kapatın. discovery document, OpenAPI/Swagger şeması, GraphQL introspection gibi self-documentation mekanizmaları bu farkı ücretsiz olarak gösterir.
2. Aynı API ailesindeki endpoint'ler arasında hata kodu/davranış farkı arıyorsanız, bu genelde "hangi kod yolundan geçtiği" konusunda dışarıdan görülebilen bir sinyaldir.
3. "Bu endpoint URL'sinde hangi kaynağa ait olduğunu belirten bir parametre yok" gözlemini, "o zaman kim sahibi olduğunu nasıl kontrol ediyor?" sorusuna çevirin. çoğu zaman cevap kontrol etmiyor olur.
4. Bulduğunuz primitive'i kanıtlamak için en az veriyi çekin, daha hassas alanlara (örn. chat içeriği) gerek olmadıkça dokunmayın.
5. Bir rapor "fixed" olarak kapandığında işiniz bitmiş sayılmaz. özellikle yüksek etkili bulgularda, birkaç ay sonra geri dönüp doğrulamak, hem etik hem de profesyonel bir alışkanlıktır.