Bruteforcing nomor telepon pengguna Google mana pun

 (brutecat.com)
1 poin oleh GN⁺ 2025-06-10 | 1 komentar | Bagikan ke WhatsApp
  • Dengan melewati formulir Temukan akun Google, dimungkinkan untuk memeriksa apakah ada nomor telepon yang terhubung ke nama pengguna tertentu
  • Bahkan dalam lingkungan dengan JavaScript dinonaktifkan, dimungkinkan menerapkan metode serangan yang secara sengaja menyisipkan token BotGuard untuk melewati pembatasan IP
  • Di beberapa negara seperti Belanda, karena karakteristik format nomor telepon hanya ada kurang dari 1 juta kombinasi, secara realistis brute force skala besar dapat dilakukan melalui rotasi proxy dan IPv6
  • Display name akun Google dapat diungkap dengan mudah menggunakan Looker Studio tanpa tindakan apa pun dari korban
  • Kerentanan ini telah dilaporkan ke Google dan ditambal, dan rantai serangan nyata dapat memverifikasi nomor telepon dalam waktu sangat singkat melalui otomatisasi

Ikhtisar

Tulisan ini membahas secara rinci kasus nyata tentang cara mengetahui nomor telepon akun Google dengan serangan brute force, prosesnya, dan respons dari pihak pertahanan. Secara umum, formulir pencarian/pemulihan akun memblokir penyalahgunaan dengan memanfaatkan lingkungan JavaScript dan sistem pencegahan bot. Namun, artikel ini membuktikan bahwa dengan lingkungan JS mati + pola tertentu, sistem tersebut dapat dilewati.

Latar belakang dan metode investigasi

  • Ditemukan bahwa formulir Google untuk mencari nama pengguna akun berjalan tanpa JavaScript
  • Formulir tersebut memeriksa keberadaan nomor telepon yang terhubung ke nama tertentu (Display Name) hanya dengan 2 permintaan HTTP
    • Permintaan pertama: memperoleh nilai ess (token sesi) berdasarkan nomor telepon
    • Permintaan kedua: menentukan apakah akun ada dengan parameter ess dan nama (GivenName/FamilyName)
  • Jika akun ada, respons berupa redirect ke usernamerecovery/challenge, jika tidak ada maka redirect ke noaccountsfound

Melewati pembatasan IP (memanfaatkan proxy dan IPv6)

  • Pada awalnya, brute force tidak memungkinkan karena rate limit per IP dan CAPTCHA
  • Untuk nomor ponsel Belanda, karena ada 1 juta kombinasi (digit awal sudah tetap), serangan menjadi realistis bila memakai proxy,
  • Dengan memanfaatkan blok /64 IPv6 dari cloud seperti AWS/Vultr, alamat bisa dirotasi berbeda di setiap permintaan, dan server juga mendukung IPv6

Bypass token BotGuard

  • Pada formulir JS, token BotGuard diperlukan
  • Jika alih-alih parameter bgresponse=js_disabled pada formulir no-JS disisipkan token yang dikumpulkan dari formulir JS, maka pengiriman tanpa batas menjadi mungkin
  • Dibuat alat multithread untuk memasukkan nomor telepon dalam jumlah besar dan dengan cepat mendeteksi akun yang ada

Menyaring false positive

  • Karena kondisi dua digit terakhir nomor yang sama pada nama yang sama, ada kemungkinan beberapa orang ikut terjaring
  • Dengan memasukkan nama belakang acak lalu menguji ulang, ditambahkan logika untuk secara otomatis memfilter apakah itu false positive

Format nomor telepon per negara dan pengumpulan informasi nama

  • Formulir pemulihan hanya memberikan sebagian format masking nomor telepon
  • Pola nomor telepon tiap negara (national format) dapat diketahui dengan meneliti informasi libphonenumbers milik Google
  • Display name korban dapat diketahui tanpa tindakan pengguna dengan menyalahgunakan fitur perubahan kepemilikan di Looker Studio

Optimasi dan otomatisasi

  • Menggunakan libphonenumbers untuk membuat kamus aturan prefix/panjang/validasi tiap negara
  • Membuat API penerbitan token BotGuard otomatis berbasis Go dan chromedp, sehingga bisa diautomatisasi saat serangan nyata

Prosedur serangan nyata

  1. Mendapatkan nama korban (display name) melalui pemindahan kepemilikan Looker Studio
  2. Mengumpulkan sebagian masking nomor telepon email tersebut dari alur “Lupa kata sandi”
  3. Menjalankan serangan brute force berdasarkan nama, masking, dan kode negara melalui alat gpb

Waktu dan efisiensi

  • Berdasarkan server 16 vCPU, 3000 thread, sekitar 40 ribu pemeriksaan per detik
  • Bergantung pada kombinasi nomor dan panjang petunjuk per negara, cukup sekitar Amerika Serikat (20 menit), Inggris (4 menit), Belanda (15 detik), Singapura (5 detik)
  • Jika layanan lain memberi petunjuk penuh (misalnya PayPal), waktu dapat dipersingkat lebih jauh

Timeline Google dan patch

  • 2025.4.14: laporan dikirim ke Google, ucapan terima kasih ditampilkan di panel pada 4.25
  • 2025.5 pertengahan: bug bounty $5.000 dibayarkan
  • 2025.5: formulir no-JS dihentikan secara bertahap dan langkah respons diterapkan
  • 2025.6.9: kerentanan resmi dipublikasikan

Kesimpulan

Kasus ini menunjukkan bahwa serangan otomatis skala besar dimungkinkan hanya dengan kombinasi beberapa informasi seperti alur pemulihan akun, masking nomor telepon, dan display name. Google telah menyelesaikan respons dengan memperbaiki kelemahan dalam prosedur dan menutup formulir terkait.

Untuk pertanyaan, dapat menghubungi melalui Signal/email (lihat naskah asli)

Bacaan terkait

1 komentar

 
GN⁺ 2025-06-10
Komentar Hacker News

  • Hal yang menarik dari tulisan ini adalah, meskipun sebagian besar penyedia hosting atau ISP setidaknya memberikan satu blok IPv6 /64, kebanyakan rate limit atau pemblokiran IP masih diterapkan per satu IP. Di lingkungan IPv6, menurut saya rate limit atau blokir seharusnya dilakukan berdasarkan seluruh blok /64

    • Bahkan perusahaan yang bertanggung jawab mengelola masalah seperti ini atau yang menghasilkan uang dari sana pun sering terlihat salah arah dalam menangani IPv6. Perusahaan tempat saya bekerja memakai layanan CDN terkenal, dan kadang kami menerima alert keamanan konyol seperti "login dari IP aneh" meskipun aksesnya berasal dari blok /64 yang sama

    • Menurut saya, sejak kemunculan IPv6, metode pemblokiran IP lama jadi sangat tidak efektif. Bahkan pengguna internet rumahan biasa bisa otomatis mendapat blok /56 atau /48 lewat DHCPv6 Prefix Delegation. Misalnya saya mendapat /56 dari Comcast, dan itu bisa dipecah menjadi hingga 65536 blok /64. Untuk melakukan filtering IP yang efektif di IPv6, tidak cukup hanya mengganti basis satu IP lama menjadi /64

    • Bahkan rate limit per blok /64 pun mungkin tidak cukup. Mendapat blok /48 juga terlalu mudah. Untuk kontrol yang optimal, perlu dipikirkan penyesuaian granularity dengan mengelompokkan per ASN dan melihat bagaimana tiap operator mendistribusikan IP

    • Rate limit per /64 di IPv6 sudah dikenal luas di industri, dan Google juga menerapkannya pada layanan lain. Saya menilai ini akibat kebijakan lama yang tidak benar-benar diperbarui saat adopsi IPv6

    • Penyedia hosting murah seperti BuyVM pun memberi alamat per /48 pada paket termurahnya ($2/bulan, saat ini yang tersedia hanya $7/bulan). Karena itu layanan seperti ini cenderung disukai operator yang mencurigakan

  • Dulu saya pernah mencoba metode serupa di Facebook untuk mencari nomor telepon seseorang. Dalam proses reset kata sandi, Facebook menampilkan sebagian besar nomor teleponnya, jadi saya susun angka-angka itu ke dalam file vCard, impor ke ponsel saya, lalu mencocokkannya lewat foto. Cara ini ternyata lebih efektif dari dugaan

    • Ada celah serupa di foto profil Google atau aplikasi Google juga. Misalnya jika di review Google Maps tertulis John Smith, Anda bisa menambahkan berbagai variasi email (johnsmith@gmail.com, smithjohn@gmail.com, dan seterusnya) ke Hangouts lalu memeriksa foto profil untuk melacak apakah itu orang yang sama

    • Karena alasan seperti ini saya tidak pernah memasukkan nomor telepon asli saya. Toh itu juga tidak benar-benar diperlukan untuk menjalankan layanannya

  • Menarik bahwa satu orang bisa menembakkan 40 ribu request per detik ke server dalam waktu lama tanpa lonjakan resource besar atau alarm berbunyi

    • Mungkin saja alarm benar-benar sempat berbunyi, tetapi aksinya cepat berhenti atau keadaan pulih dengan cepat sehingga saat engineer membuka dashboard semuanya sudah normal lagi. 40 ribu QPS tidak terlalu menonjol pada skala trafik Focus atau Google API, dan jika disebar ke berbagai IP serta blok IPv6 /64, hal seperti ini bisa lewat tanpa terlihat. Inti kasus ini menurut saya bukan monitoring, melainkan bahwa flow saat JS dinonaktifkan (menggunakan token yang dipinjam dari flow lama saat JS aktif) sama sekali tidak punya rate limit

    • Saya juga sempat berpikir apakah dia memakai botnet, tetapi sepertinya IP-nya berubah pada setiap request

  • Bug bounty untuk jenis kerentanan seperti ini sering dibayar sangat rendah. Disayangkan

    • Kalau terus menekan nilai hadiah, pada akhirnya itu malah merugikan diri sendiri

    • Membayar kurang dari $100.000 untuk isu keamanan seperti ini benar-benar terasa pelit

  • Saya sering merasa bahwa mempertahankan dan merawat halaman web legacy itu beban yang luar biasa besar. Banyak situs harus terus memelihara kode dan halaman yang sudah berumur puluhan tahun, dan praktis mustahil menguji semua kombinasinya. Jika menyusuri bagian dalam pengaturan Gmail, Anda masih bisa melihat popup tua bergaya 2004

    • Program bug bounty tampak seperti penggunaan biaya yang sangat efisien. Hanya dengan beberapa ribu dolar, Anda bisa mengerahkan tenaga sukarela yang mencari edge case ekstrem. Kalau memakai tenaga internal, biayanya pasti jauh lebih besar

    • Inilah alasan terbesar perusahaan berusaha agresif mematikan layanan dan produk lama. Jawaban atas pertanyaan "bukankah bisa dibiarkan saja?" adalah karena pada akhirnya semua layanan legacy menjadi lubang keamanan. Kode yang benar-benar aman hanyalah kode yang tidak ada sama sekali

    • Saya selalu penasaran siapa yang masih menangani fitur "poke" milik Facebook

    • Infrastruktur legacy serupa juga terus berjalan di dalam perusahaan besar. Misalnya teman saya memelihara aplikasi pemendek tautan internal di sebuah perusahaan global besar, dan meskipun pemakaiannya nyaris meledak, tiket yang masuk tiap kali hanya satu-dua untuk hal-hal sangat sederhana seperti update versi Node. Bahkan saat monitoring tidak berfungsi normal pun laporan bug begitu jarang

    • Baru-baru ini saya juga menemukan halaman di Google yang masih menampilkan logo Catull lama (~2013)

  • Disebutkan, "2025-05-15 – panel memberi $1.337 + swag. Dasar: potensi eksploitasi rendah (lol)", tetapi menurut saya sebenarnya potensi eksploitasinya sangat tinggi. Mungkin tidak banyak korban yang nomor teleponnya terekspos, tetapi saya yakin siapa pun yang membutuhkannya—detektif swasta, kriminal, penyelidik, dan lain-lain—benar-benar akan memanfaatkan celah ini

  • Baru kali ini saya sadar bahwa memberi petunjuk sebagian nomor telepon dalam flow lupa kata sandi sebenarnya adalah risiko keamanan. Jika beberapa layanan memberikan petunjuk nomor telepon/email yang dimasking dalam urutan berbeda-beda, risikonya jadi lebih besar lagi

    • Mungkin ini tidak menghibur, tetapi karena 2FA dan berbagai alasan lain, ratusan atau ribuan layanan sudah mengumpulkan nomor telepon saya, dan banyak di antaranya sudah bocor terlepas dari ada tidaknya persetujuan saya. Kombinasi nama asli-email-nomor telepon hampir pasti sudah dibuang ke data publik

    • Bahkan ada bot Telegram yang mencari informasi seperti ini. Saat kerentanan brute-force seperti ini terungkap, tampaknya bahkan pengguna alat otomatis pun merasa tidak nyaman (contoh yang terkenal adalah bot EoG)

    • Layanan berbayar yang secara otomatis mengumpulkan informasi pribadi seperti ini juga sudah ada sejak lama. Email, nomor telepon, dan berbagai data lain menumpuk dari banyak sumber, dan secara global insentifnya cukup besar untuk secara agresif menyerang kelemahan keamanan layanan. Pada akhirnya strukturnya memang mengarah ke kebocoran massal

    • Dulu juga pernah ada kasus social engineering di mana seseorang menanyakan 4 digit terakhir kartu kepada customer service sebuah perusahaan, lalu memakainya untuk melewati verifikasi identitas di perusahaan lain

    • Saya juga ingat saat kuliah pernah mendengar presentasi peneliti keamanan bahwa kartu kredit pun bisa dieksploitasi untuk memperoleh informasi dengan cara seperti ini

  • Pada 2025, 2023, dan 2021, artikel "tidak ada cara untuk mencegah ini" dan kebocoran data besar terus berulang. Versi 2025, versi 2023, dan versi 2021 terus muncul lagi. Saya jadi berpikir versi mana yang paling lucu

  • Menurut saya kasus ini sangat kreatif dan keren. Brutecat melakukannya lagi

  • Google sekarang benar-benar terasa seperti kapal hantu. Bug bounty $5.000 itu levelnya menghina, dan fakta bahwa mereka memulai dari nominal sekecil itu sendiri terasa seperti bukti kuat bahwa Google tidak serius melindungi data pengguna

    • Ikut program bug bounty bukan kewajiban. Kalau tidak suka nilai hadiahnya, ya tinggal tidak ikut. Pada akhirnya program seperti ini juga punya batas sebagai model yang berkelanjutan