Уразливість дозволяла дослідникам зламати будь-який номер телефону для відновлення облікового запису Google, просто знаючи ім’я користувача в профілі та легко відновлюваний частковий номер телефону, що створювало величезний ризик фішингових атак та атак із заміною SIM-картки. Метод атаки полягає у зловживанні застарілою версією форми відновлення імені користувача Google з вимкненим JavaScript, якій бракувало сучасних засобів захисту від зловживань. Уразливість виявив дослідник безпеки BruteCat, той самий, який у лютому продемонстрував, що можна розкрити приватні адреси електронної пошти облікових записів YouTube.
BruteCat повідомив BleepingComputer, що хоча атака і отримує номер телефону, налаштований користувачами для відновлення облікового запису Google, у переважній більшості випадків він збігається з основним номером телефону власника облікового запису.
Перебір номерів Google методом перебору
BruteCat виявив, що може отримати доступ до застарілої форми відновлення імені користувача без JavaScript, яка, схоже, працювала належним чином. Форма дозволяла запитувати, чи пов’язаний номер телефону з обліковим записом Google, на основі відображуваного імені профілю користувача («Джон Сміт»), через два POST-запити.
Дослідник обійшов елементарні засоби захисту, що обмежують швидкість, у формі, використовуючи ротацію IPv6-адрес для генерації трильйонів унікальних вихідних IP-адрес через підмережі /64 для цих запитів. CAPTCHA, що відображалися багатьма запитами, обходили шляхом заміни параметра ‘bgresponse=js_disabled’ дійсним токеном BotGuard з форми з увімкненим JS.
Використовуючи цю техніку, BruteCat розробив інструмент для перебору даних (gpb), який перебирає діапазони чисел, використовуючи формати, специфічні для кожної країни, та фільтрує хибнопозитивні результати. Дослідник використав «libphonenumber» від Google для генерації дійсних форматів номерів, створив базу даних масок країн для ідентифікації форматів телефонів за регіонами та написав скрипт для генерації токенів BotGuard через Chrome без headless-автоматизації. При швидкості перебору даних методом повного перебору 40 000 запитів на секунду, отримання даних з США займе близько 20 хвилин, з Великої Британії – 4 хвилини, а з Нідерландів – менше 15 секунд.
Щоб розпочати атаку на когось, для форми потрібна його адреса електронної пошти, але Google з минулого року приховав її. BruteCat виявив, що може отримати його, створивши документ Looker Studio та передавши право власності на адресу Gmail цілі. Після передачі права власності ім’я цільової організації в Google відображається на панелі інструментів Looker Studio автора документа, що не вимагає жодної взаємодії з нею.
Озброївшись цією електронною адресою, вони могли виконувати повторні запити, щоб визначити всі номери телефонів, пов’язані з іменем профілю. Однак, оскільки можуть існувати тисячі облікових записів з однаковим іменем профілю, дослідник звузив його, використовуючи частковий номер цільової групи. Щоб отримати частковий номер телефону користувача, дослідник використав робочий процес Google «відновлення облікового запису», який відображатиме дві цифри налаштованого номера телефону для відновлення.
«Цей час також можна значно скоротити за допомогою підказок щодо номерів телефонів із процесів скидання пароля в інших сервісах, таких як PayPal, які надають кілька додаткових цифр (наприклад, +14•••••1779)», пояснює BruteCat. Витік номерів телефонів, пов’язаних з обліковим записом Google, може створити величезну загрозу безпеці для користувачів, які потім можуть стати ціллю цільових атак типу «вішинг» або «підміна SIM-карт». Демонстрацію використання цієї недосконалості можна побачити на відео нижче.
Виправлено помилку
BruteCat повідомив про свої висновки Google через Програму винагороди за вразливості (VRP) технологічного гіганта 14 квітня 2025 року. Спочатку Google вважав ризик використання низьким, але 22 травня 2025 року підвищив рівень проблеми до «середнього», застосувавши тимчасові заходи пом’якшення та виплативши досліднику винагороду в розмірі 5000 доларів США за розкриття інформації. 6 червня 2025 року Google підтвердив, що повністю виключив вразливу кінцеву точку відновлення no-JS. Вектор атаки більше не можна використовувати, але чи використовувався він коли-небудь зловмисно, залишається невідомим.