Google kullanıcı telefon numaralarına kaba kuvvet saldırısı

• Google’ın No-JS kullanıcı adı kurtarma formu, telefon numarası ve görünen ad kombinasyonunu doğrulayabildiği için belirli bir Google kullanıcısının tam telefon numarasını ortaya çıkarabilen bir saldırı zinciri oluşturuldu
• Kritik nokta, /signin/usernamerecovery ve /signin/usernamerecovery/lookup arasındaki yönlendirme farkıydı; bu sayede hesap yok durumu ile hesap var durumu ayırt edilebiliyordu
• IP tabanlı istek kısıtlaması ve CAPTCHA vardı, ancak JS formundaki BotGuard token değeri No-JS formunun bgresponse alanına konunca kısıtlama olmadan çalıştı ve buna IPv6 rotasyonu da eklendi
• Saldırgan, Looker Studio üzerinden Google hesap görünen adını elde edip parola kurtarma akışındaki maskelenmiş telefon numarası ile ülkeye özgü numara biçimlerini birleştirerek adayları büyük ölçüde daraltabildi
• Saatlik 0,30 dolarlık 16 vCPU sınıfı bir sunucuda yaklaşık saniyede 40 bin doğrulama yapılabildi; Google ise 6 Haziran 2025’te No-JS kullanıcı adı kurtarma formunu tamamen kaldırdı ve toplam 5.000 dolar ödedi

---

No-JS kullanıcı adı kurtarma formunda başlayan açık

• Tarayıcıda JavaScript kapalıyken Google servislerinin nasıl davrandığı incelenirken, kullanıcı adı kurtarma formunun hâlâ çalıştığı fark edildi
• Hesap kurtarma formunun geçmişten beri, gizlenmiş proof-of-work JavaScript kodunun ürettiği BotGuard tabanlı savunmalara dayandığı için JavaScript gerektirdiği düşünülüyordu
• Ancak No-JS formu, kurtarma e-postasının veya telefon numarasının belirli bir görünen adla bağlantılı olup olmadığını doğrulayabilen bir akış sunuyordu

İki istekle hesap varlığını doğrulama

• İlk istekte /signin/usernamerecovery adresine telefon numarası gönderiliyor ve yanıttaki Location üzerinden bu telefon numarasına bağlı ess değeri alınıyordu
  • Çerezler ve gxf değeri başlangıç sayfasının HTML’inden alınıyordu
• Ardından /signin/usernamerecovery/lookup adresine ess, ad, soyad ve bgresponse=js_disabled gönderiliyordu
• Yanıttaki yönlendirme değiştiği için, bu telefon numarası ve görünen ada sahip bir Google hesabı olup olmadığı anlaşılabiliyordu
  • Hesap yok: usernamerecovery/noaccountsfound
  • Hesap var: usernamerecovery/challenge

IP kısıtlaması, IPv6 ve BotGuard atlatma

• İlk denemelerde birkaç isteğin ardından IP adresi istek kısıtlamasına takılıyor ve CAPTCHA gösteriliyordu
• Hollanda mobil numarası örneğinde parola kurtarma akışı •• ••••••03 gibi bir ipucu veriyordu
  • Hollanda mobil numaraları 06 ile başladığı için kalan 6 haneyi, yani 10^6 = 1,000,000 adayı denemek gerekiyordu
• Vultr gibi sağlayıcılar /64 IPv6 aralığı veriyor; teorik olarak 18,446,744,073,709,551,616 adres kullanılabiliyor
• reqwest içindeki ClientBuilder.local_address ile alt ağdan rastgele bir IPv6 adresini her istekte ayarlayan bir PoC hazırlandı
• Veri merkezi IP’siyle JS kapalı form kullanıldığında sürekli CAPTCHA çıkıyordu, ancak JS açık hesap kurtarma formunun BotGuard token değeri No-JS formunun bgresponse alanına konunca istekler geçmeye başladı
  • No-JS formunda bu BotGuard token için bir istek kısıtlaması yokmuş gibi görünüyordu

Hatalı eşleşmeleri eleme

• İlk çalıştırma sonuçlarında adı Henry, soyadı boş ve telefon numarasının son iki hanesi 03 olan çok sayıda hesap yer aldı
• Bu durumda ad Henry ise soyad ne olursa olsun usernamerecovery/challenge dönüyordu
• Olası eşleşmeleri doğrulamak için aynı adla 0fasfk1AFko1wf gibi rastgele bir soyad tekrar denendi
  • Sonuç yine eşleşme gelirse bunun yanlış pozitif olduğu kabul edilip filtrelendi
• Aynı tam görünen ad, aynı ülke kodu ve aynı son iki numara hanesine sahip başka Google kullanıcılarının bulunma olasılığının düşük olduğu değerlendirildi

Ülke kodu ve görünen adı elde etme

• Parola kurtarma akışındaki telefon numarası maskesi, ülke kodunu tahmin etmek için kullanılabiliyordu
• Google her numara için libphonenumber içindeki national format biçimini kullanıyor
• Ülkeye göre maskelenmiş national format’lar toplanarak mask.json oluşturuldu
  • Rusya, Hollanda, Birleşik Krallık ve ABD farklı maske desenlerine sahip
• Google 2023’te adı yalnızca hedefle doğrudan etkileşim olduğunda gösteren bir politikaya geçti; Nisan 2024’te ise Internal People API, kimliği doğrulanmamış hesaplar için görünen ad döndürmeyi tamamen durdurdu
• Ancak Looker Studio üzerinde bir belge oluşturulup kurbana sahiplik devredilirse, kurbanın herhangi bir etkileşimi olmadan ana ekranda görünen ad açığa çıkıyor

Aday aralığını optimize etme ve araçlar

• libphonenumber’ın numara doğrulaması kullanılarak ülkeye göre mobil önekler, bilinen alan kodları ve hane sayılarını içeren format.json üretildi
  • Hollanda örneği; ülke kodu 31, alan kodları 61, 62, 63, 64, 65, 68 ve hane sayısı [7] içeriyor
• Gerçek zamanlı libphonenumber doğrulaması ile geçersiz numaralara yönelik Google API sorguları azaltıldı
• BotGuard token üretmek için chromedp kullanan bir Go betiği yazıldı
  • http://localhost:7912/api/generate_bgtoken çağrısıyla bgToken alınabiliyor
• Tüm saldırı akışı üç aşamadan oluşuyordu
  • Looker Studio ile Google hesap görünen adını sızdırma
  • Parola kurtarma akışından maskelenmiş telefon numarasını alma
  • Görünen ad ve maskelenmiş telefon numarasıyla gpb kullanarak tam telefon numarasına kaba kuvvet uygulama

Kaba kuvvet performansı ve tahmini süre

• Saatlik 0,30 dolarlık sunucuda ve tüketici sınıfı 16 vCPU yapılandırmasında yaklaşık saniyede 40 bin doğrulama yapılabildi
• Parola kurtarma akışında yalnızca son iki hane verildiğinde tahmini süreler:
  • ABD +1: 20 dakika
  • Birleşik Krallık +44: 4 dakika
  • Hollanda +31: 15 saniye
  • Singapur +65: 5 saniye
• PayPal gibi diğer servislerin parola sıfırlama akışları daha fazla rakam ipucu verirse süre ciddi biçimde kısalabiliyor
  • Örnek: +14•••••1779

Google’a bildirim ve aksiyon zaman çizelgesi

• 2025-04-14: Rapor üreticiye gönderildi
• 2025-04-15: Üretici raporu aldı ve sınıflandırdı
• 2025-04-25: “Nice catch!” yanıtı verildi
• 2025-05-15: Panel, 1.337 dolar + swag ödül belirledi
  • Gerekçe olarak kötüye kullanım olasılığının düşük görülmesi gösterildi ve konu, etkisi yüksek kötüye kullanım odaklı metodoloji olarak kabul edildi
• 2025-05-15: Ödül gerekçesine itiraz edildi
  • Abuse VRP tablosuna göre probability/exploitability, saldırı ön koşulları ve kurbanın kötüye kullanımı fark edip edemeyeceğine göre belirleniyor
  • Bu saldırıda ön koşul olmadığı ve kurbanın kötüye kullanımı fark edemeyeceği belirtildi
• 2025-05-22: Panel ek 3.663 dolar ödeyerek toplam ödülü 5.000 dolar olarak güncelledi
  • Likelihood seviyesi medium’a yükseltildi
• 2025-05-22: Üretici, dünya çapındaki endpoint kaldırımı tamamlanana kadar geçerli olacak azaltma önlemlerini devreye aldığını doğruladı
• 2025-05-22: 2025-06-09 açıklama tarihi üzerinde uzlaşıldı
• 2025-06-06: Üretici, No-JS kullanıcı adı kurtarma formunun tamamen kaldırıldığını doğruladı
• 2025-06-09: Rapor yayımlandı