Google kullanıcılarının telefon numarasını kaba kuvvetle bulma saldırısı (Bruteforcing the phone number of any Google user)

 (brutecat.com)
1 puan yazan GN⁺ 2025-06-10 | 1 yorum | WhatsApp'ta paylaş
  • Google hesap bulma formu atlatılarak belirli bir kullanıcı adıyla ilişkili telefon numarasının var olup olmadığı doğrulanabiliyor
  • JavaScript devre dışı ortamda bile BotGuard token’ı kasıtlı olarak eklenerek IP sınırlamasını aşan bir saldırı yöntemi uygulanabiliyor
  • Hollanda gibi bazı ülkelerde telefon numarası formatı gereği 1 milyondan az kombinasyon bulunduğundan, proxy ve IPv6 rotasyonu ile geniş çaplı kaba kuvvet denemeleri pratik hale geliyor
  • Google hesabının görünen adı, Looker Studio kullanılarak kurbanın herhangi bir işlem yapmasına gerek kalmadan kolayca açığa çıkarılabiliyor
  • Bu açık Google’a bildirildi ve yamandı; gerçek saldırı zinciri ise otomasyonla çok kısa sürede telefon numarasını doğrulayabiliyor

Genel Bakış

Bu yazı, Google hesaplarının telefon numaralarını kaba kuvvet saldırısıyla ortaya çıkarma yöntemini, sürecini ve savunma tarafının verdiği yanıtı ayrıntılı biçimde ele alan gerçek bir vakayı anlatıyor. Normalde hesap bulma/kurtarma formları, kötüye kullanımı engellemek için JavaScript ortamı ve bot önleme mekanizmalarından yararlanır. Ancak burada, JS kapalı bir ortamın ve belirli bir desenin bu mekanizmaları aşabildiği gösteriliyor.

Araştırmanın Arka Planı ve Yöntemi

  • Google’ın hesap kullanıcı adını bulma formunun JavaScript olmadan da çalıştığı fark edildi
  • Form, belirli bir isimle (Display Name) ilişkili telefon numarasının varlığını iki HTTP isteğiyle kontrol ediyor
      1. istek: telefon numarasına dayalı olarak ess değeri (oturum token’ı) alınıyor
      1. istek: ess ve isim (GivenName/FamilyName) parametreleriyle hesabın var olup olmadığı belirleniyor
  • Hesap varsa usernamerecovery/challenge yönlendirmesi, yoksa noaccountsfound yönlendirmesi dönüyor

IP Sınırlamasını Aşma (proxy, IPv6 kullanımı)

  • Başlangıçta IP başına rate limit ve CAPTCHA nedeniyle kaba kuvvet saldırısı mümkün değildi
  • Hollanda mobil numaralarında 1 milyon kombinasyon bulunduğundan (başlangıç rakamları sabit), proxy kullanımıyla saldırı pratik hale geliyor
  • AWS/Vultr gibi bulut sağlayıcılarının /64 IPv6 blokları kullanılarak her istekte farklı bir adres döndürülebiliyor; sunucu tarafı da IPv6 destekliyor

BotGuard Token Atlama

  • JS formunda BotGuard token’ı gerekiyor
  • No-JS formunda bgresponse=js_disabled parametresi yerine JS formundan toplanan bir token eklenirse sınırsız gönderim mümkün oluyor
  • Çok iş parçacıklı bir araç geliştirilerek, çok sayıda telefon numarası girilip mevcut hesaplar hızla tespit edilebiliyor

Yanlış Pozitifleri Ayıklama (filtreleme)

  • Aynı isim/numara son 2 hanesi koşuluyla birden fazla kişi eşleşebiliyor
  • Rastgele bir soyad girilip yeniden test edilerek yanlış pozitiflerin otomatik filtrelenmesini sağlayan bir mantık eklendi

Ülkelere Göre Telefon Numarası Formatı ve İsim Bilgisi Toplama

  • Kurtarma formu yalnızca telefon numarası maskeleme formatının bir kısmını gösteriyor
  • Ülkelere göre telefon numarası desenleri (ulusal format), Google’ın libphonenumbers bilgileri incelenerek anlaşılabiliyor
  • Kurbanın görünen adı, Looker Studio’daki sahiplik değiştirme özelliğinin kötüye kullanılmasıyla kullanıcı etkileşimi olmadan öğrenilebiliyor

Optimizasyon ve Otomasyon

  • libphonenumbers ile ülkelere göre prefix/uzunluk/geçerlilik doğrulama kuralları sözlüğü oluşturuldu
  • Go tabanlı chromedp ile BotGuard token’ını otomatik üreten bir API geliştirildi; gerçek saldırıda otomasyon mümkün hale geldi

Gerçek Saldırı Prosedürü

  1. Looker Studio sahiplik devri yoluyla kurbanın adı (görünen adı) elde edilir
  2. “Şifremi unuttum” akışında ilgili e-posta için telefon numarasının kısmen maskelenmiş hali toplanır
  3. gpb aracı ile isim, maskeleme ve ülke koduna dayalı kaba kuvvet saldırısı yürütülür

Süre ve Verimlilik

  • 16 vCPU, 3000 thread’li bir sunucuda saniyede yaklaşık 40 bin kontrol yapılabiliyor
  • Ülkeye göre numara kombinasyonu ve ipucu uzunluğuna bağlı olarak ABD (20 dakika), Birleşik Krallık (4 dakika), Hollanda (15 saniye), Singapur (5 saniye) yeterli oluyor
  • Başka servisler tam ipucu verdiğinde (ör. PayPal) süre daha da kısalıyor

Google ve Yama Zaman Çizelgesi

  • 14.04.2025: Google’a raporlandı, 25.04’te panelde teşekkür gösterildi
  • 2025 Mayıs ortası: 5.000 dolarlık bug bounty ödendi
  • 2025 Mayıs: No-JS formu kademeli olarak kaldırıldı ve önlemler uygulandı
  • 09.06.2025: Açık resmen kamuya açıklandı

Sonuç

Bu vaka, hesap kurtarma akışı, telefon numarası maskelemesi ve görünen ad gibi birden çok bilginin birleşimiyle geniş çaplı otomatik saldırıların mümkün olabildiğini gösteriyor. Google, süreçteki zafiyetleri giderip ilgili formu kapatarak müdahaleyi tamamladı.

İletişim için Signal/e-posta kullanılabilir (ayrıntılar için özgün metne bakın)

İlgili okumalar

1 yorum

 
GN⁺ 2025-06-10
Hacker News görüşleri

  • Bu yazıda ilginç olan nokta, çoğu hosting sağlayıcısı ya da ISP en az bir /64 IPv6 bloğu sağlıyor olmasına rağmen, rate limit ve IP engellemelerin hâlâ çoğunlukla tek bir IP'ye uygulanması. IPv6 ortamında rate limit veya engellemenin tüm /64 bloğu baz alması gerektiğini düşünüyorum

    • Bundan sorumlu olan ya da bundan para kazanan şirketlerin bile IPv6 yönetiminde sık sık saçma tepkiler verdiğini görüyorum. Çalıştığım şirket tanınmış bir CDN hizmeti kullanıyor ama aynı /64 blok içinden bağlanılsa bile bazen "alışılmadık bir IP'den giriş yapıldı" gibi absürt güvenlik uyarıları geliyor

    • IPv6 çıktığından beri eski IP engelleme yöntemlerinin büyük ölçüde etkisiz kaldığını düşünüyorum. Sıradan ev interneti kullanıcıları bile DHCPv6 Prefix Delegation ile otomatik olarak /56 veya /48 blok alabiliyor. Örneğin ben Comcast üzerinden /56 alıyorum ve bu en fazla 65536 adet /64 bloğa bölünebiliyor. IPv6'da etkili IP filtreleme yapmak için eski tekil IP tabanını sadece /64 ile değiştirmek yeterli değil

    • /64 blok bazlı rate limit de yeterli olmayabilir. /48 blok almak fazla kolay. En iyi kontrol için ASN bazında sınıflandırma yapıp, her sağlayıcının IP'leri nasıl dağıttığını da inceleyerek granularity'yi ayarlamak gerekir

    • IPv6'da /64 biriminde rate limit uygulamak sektörde zaten iyi bilinen bir şey ve Google da bunu diğer hizmetlerinde kullanıyor. Bence bu, IPv6'ya geçerken mevcut politikaların düzgün güncellenmemesinin sonucu

    • BuyVM gibi ucuz hosting şirketleri bile en ucuz pakette /48 adres veriyor (aylık $2, şu anda stokta yalnızca aylık $7'lık seçenek var). Bu yüzden şüpheli operatörler tarafından sık tercih ediliyor

  • Geçmişte Facebook'ta belirli bir kişinin telefon numarasını bulmak için benzer bir yöntem denedim. Şifre sıfırlama sürecinde Facebook telefon numarasının büyük kısmını gösteriyordu; ben de bu rakamları bir vcard dosyasında düzenleyip telefonuma aktardım, sonra fotoğraflarla karşılaştırdım. Beklediğimden etkili olmuştu

    • Google profil fotoğrafında veya Google uygulamalarında da benzer bir açık var. Örneğin Google Haritalar yorumlarında John Smith görünüyorsa, çeşitli e-posta varyasyonlarını (johnsmith@gmail.com, smithjohn@gmail.com vb.) Hangouts'a ekleyip profil fotoğrafını kontrol ederek aynı kişiyi takip edebilirsiniz

    • Bu yüzden gerçek telefon numaramı asla vermiyorum. Zaten hizmet işletmek için de gerçekten gerekli değil

  • Tek bir kişinin uzun süre boyunca sunucuya saniyede 40 bin istek göndermesine rağmen kaynak kullanımının ciddi biçimde yükselmemesi veya alarm çalmaması etkileyici

    • Aslında alarm çalmış olabilir ama davranış hızla durmuş ya da durum çabuk toparlanmış, bu yüzden mühendis dashboard'a baktığında her şey normale dönmüş olabilir. 40 bin QPS, Focus veya Google API trafiği ölçeğinde çok sırıtmayabilir; farklı IP'lere ve IPv6 /64 bloklarına dağıtılırsa daha da fark edilmeden geçebilir. Bu olayın özü bence izleme eksikliği değil, JS devre dışı akışında (önceki JS etkin akıştan ödünç alınan token'ı kullanan akış) hiç rate limit olmaması

    • Acaba botnet mi kullandı diye de düşünüyorum ama her istekte IP'yi değiştirmiş gibi görünüyor

  • Bu tür bug bounty'lerde ödül miktarı saçma derecede düşük oluyor. Üzücü

    • Ödülü sürekli düşürürsen sonuçta kendi ayağına sıkmış olursun

    • Böyle bir güvenlik sorunu için 100 bin doların altında ödeme yapmak gerçekten cılız kalıyor

  • Legacy web sayfalarını ayakta tutup yönetmenin ne kadar büyük bir yük olduğunu sık sık hissediyorum. Onlarca yıllık kodu ve sayfaları sürdürmek zorunda kalan çok site var, tüm kombinasyonları test etmek de fiilen imkânsız. Gmail ayarlarının derinlerine inince hâlâ 2004 tarzı eski popup'ların çıktığını bizzat görebilirsiniz

    • Bug bounty programları bence maliyeti çok verimli kullanan bir yöntem. Birkaç bin dolarla uç edge case'leri bulan gönüllü bir iş gücünü harekete geçirebiliyorsunuz. Bunu şirket içi ekiple yapmaya kalksanız maliyet çok daha yüksek olurdu

    • Şirketlerin eski hizmet ve ürünleri agresif biçimde kapatmaya çalışmasının en büyük nedeni de tam olarak bu. "Olduğu gibi bıraksak olmaz mı?" sorusunun cevabı şu: eninde sonunda her legacy hizmet bir güvenlik deliğine dönüşür. Gerçekten güvenli tek kod, hiç var olmayan koddur

    • Facebook'un "poke" özelliğinden kimin sorumlu olduğunu hep merak etmişimdir

    • Büyük şirketlerin içinde de benzer legacy altyapılar dönmeye devam ediyor. Örneğin bir arkadaşım küresel bir dev şirkette dahili link kısaltma uygulamasının bakımını yapıyor; kullanım çok yoğun olmasına rağmen Node sürümünü güncellemek gibi çok basit nedenlerle bile her seferinde ancak bir iki ticket geliyor. İzleme sistemi düzgün çalışmasa bile bug raporları o kadar seyrek ki fark edilmeyebiliyor

    • Ben de yakın zamanda Google'da eski (~2013) Catull logosunun çıktığı bir sayfayla karşılaştım

  • "2025-05-15 – Panel $1,337 + swag verdi. Gerekçe: düşük exploit edilebilirlik (lol)" denmiş ama bence pratikte exploit edilebilirlik çok yüksek. Etkilenen telefon numarası sahiplerinin sayısı çok büyük olmayabilir ama ihtiyaç duyan özel dedektifler, suçlular, soruşturmacılar ve benzerleri bu açığı gerçekten kullanacaktır

  • Şifre kurtarma akışında telefon numarasının bir kısmını ipucu olarak göstermenin aslında bir güvenlik riski olduğunu bu olayla yeni fark ettim. Eğer birden fazla hizmet, maskelenmiş telefon numarası/e-posta ipuçlarını farklı sıralarda veriyorsa risk daha da büyür

    • Teselli olur mu bilmem ama 2FA ve başka nedenlerle yüzlerce/binlerce hizmet zaten telefon numaramı topladı ve rızam olsun ya da olmasın bunların önemli bir kısmı çoktan sızdırıldı. Gerçek ad-e-posta-telefon numarası kombinasyonları neredeyse kesin biçimde herkese açık veri dump'larında bulunuyor

    • Bu tür bilgileri bulan Telegram botları da var. Böyle brute force açıkları ortaya çıkınca, normalde otomasyon araçları kullanan kişilerin bile rahatsız olduğu görülüyor (EoG botu bunun tipik örneği)

    • Bu tür kişisel verileri otomatik toplayan ücretli hizmetler de yıllardır var. E-posta, telefon numarası ve başka birçok bilgi farklı kaynaklardan birikiyor; dünya genelinde bunun için yeterli teşvik olduğu için hizmetlerin güvenlik açıkları da agresif biçimde hedef alınıyor. Sonuçta yapı toplu sızıntıya bağlanıyor

    • Geçmişte bir şirketin müşteri hizmetlerini arayıp kartın son 4 hanesini öğrenen, sonra bununla başka bir şirkette kimlik doğrulamayı aşan sosyal mühendislik vakaları da olmuştu

    • Ben de üniversitedeyken, kredi kartları hakkında bilgilerin bu şekilde elde edilebildiğini anlatan bir güvenlik araştırmacısının sunumunu dinlediğimi hatırlıyorum

  • 2025'te, 2023'te ve 2021'de de "bunu önlemenin yolu yok" haberleri ve büyük veri sızıntıları tekrar tekrar yaşandı. 2025 sürümü, 2023 sürümü, 2021 sürümü diye sürüp gidiyor. Hangisinin daha komik olduğuna karar veremiyorum

  • Bence bu vaka çok yaratıcı ve havalı. Brutecat yine iş çıkarmış

  • Google artık gerçekten bir hayalet gemi gibi hissettiriyor. $5,000 bug bounty hakaret düzeyinde ve böyle düşük bir rakamla başlamış olmaları bile Google'ın kullanıcı verisini korumayı ciddiye almadığının açık kanıtı gibi

    • Bug bounty'ye katılmak zorunlu değil. Ödül hoşuna gitmiyorsa katılmazsın. Sonuçta bu programların da sürdürülebilir bir model açısından sınırları var