.gif)
Эта статья носит исключительно образовательный характер. Автор не несет ответственности за любые последствия ее прочтения.
Данная статья является переводом и ведется со слов автора. .
Когда дело доходит до баг-хантинга, я предпочитаю мобильные-приложения, вместо веба, поэтому в январе я решил углубиться в конечные точки apk в надежде найти что-нибудь интересное.
Я скачал кучу apk файлов Facebook и мессенджеров разных версий, нашел все конечные точки, отсортировал их и просмотрел.
В процессе я наткнулся на одну интересную конечную точку с названием:
POST auth/flashcall_account_recovery
Конечная точка требует 3 параметра:
cuid, encrypted_phone_numbers и cli
CUID в основном означал зашифрованную электронную почту/номер телефона, которые оказалось легко найти.
Просто указываем адрес электронной почты жертвы в конечной точке
POST /recover_accounts
И в ответ вы получите CUID.
Затем, следует пройти по пути восстановления пароля на Facebook.
Я заметил, что в конечной точке, ответственной за отправку OTP кода в Facebook, был параметр с именем:
should_use_flash_call=false
Если он установлен в false, вы получите OTP SMS на свой телефон, а если он установлен в true, вы получите телефонный звонок вместо OTP для восстановления учетной записи.
И в ответе содержались требуемые зашифрованные номера телефонов.
Теперь я не мог понять, что означает параметр cli.
Единственное, что мне пришло в голову, это «интерфейс командной строки (cli)».
Не сумев понять, я подставил null вместо значения.
Когда я сделал запрос, я получил идентификатор пользователя, значение электронной почты которого я указал в качестве CUID.
Это означает, что злоумышленник может предоставить чей-либо адрес электронной почты/телефона в качестве CUID, и в ответ он сможет точно определить, кому принадлежит этот адрес электронной почты.
Я быстро отправил отчет, и он был принят и исправлен в течение дня.
Мне было очень интересно узнать об этой конечной точке, поскольку я никогда не использовал «восстановление с помощью телефонного звонка» для сброса пароля.
Ни в моем пользовательском интерфейсе, ни в Google, ни в Youtube не было много информации об этом процессе восстановления учетной записи.
Итак, я начал анализировать, как работает этот процесс восстановления.
Конечная точка работала следующим образом.
cuid=x&enc_phone=x&cli=+1xxxxx
Оказывается, в cli параметре мы должны указать номер телефона, с которого мы получили телефонный звонок на шаге 3.
Теперь стало понятно, почему это назвали восстановлением с помощью телефонного звонка. Я думаю, что cli означает что-то вроде caller identification.
В идеальном сценарии, когда мы предоставим все допустимые значения, мы получим следующий ответ:
{"id":"UserID","nonce":"XXXX","skip_logout_pw_reset":""}
Значение nonce действует как код OTP, а затем будет передано в конечную точку для проверки OTP.
Эта конечная точка выполняет проверку nonce и установку нового пароля.
В POST /flashcall_account_recovery, я сначала проверил будет ли работать сброс, если указать валидный cli другого пользователя, вместе с cuid жертвы, но это не сработало.
Я пробовал заменить все параметры тут и там, но ни один из них не работал.
Теперь единственный вариант, который у меня оставался, - это брутфорс параметра cli.
Учитывая, насколько строг Facebook с ограничением скорости брутфорса, так как он имеет ограничение скорости, реализованное даже на конечных точках без аутентификации, у меня не было почти никакой надежды.
Но, к моему абсолютному удивлению, в этой конечной точке не было реализовано ограничение скорости.
Следовательно, атака будет работать так:
Таймлайн раскрытия электронной почты
Submitted: April 25, 2021
Triaged: April 27,2021
Fixed: April 27,2021
Таймлайн захвата аккаунта
Submitted: April 29, 2021
Triaged : April 30, 2021 at 3:32 PM
Fixed: April 30, 2021 at 3:49 PM
Мне потребовалось больше времени, чтобы проверить исправление, чем у Facebook, чтобы выпустить исправление, лол.
После тщательного расследования Facebook не обнаружил доказательств злоупотреблений, и 2 сентября вопрос был окончательно закрыт.
Данная статья является переводом и ведется со слов автора. .
Когда дело доходит до баг-хантинга, я предпочитаю мобильные-приложения, вместо веба, поэтому в январе я решил углубиться в конечные точки apk в надежде найти что-нибудь интересное.
Я скачал кучу apk файлов Facebook и мессенджеров разных версий, нашел все конечные точки, отсортировал их и просмотрел.
В процессе я наткнулся на одну интересную конечную точку с названием:
POST auth/flashcall_account_recovery
Конечная точка требует 3 параметра:
cuid, encrypted_phone_numbers и cli
CUID в основном означал зашифрованную электронную почту/номер телефона, которые оказалось легко найти.
Просто указываем адрес электронной почты жертвы в конечной точке
POST /recover_accounts
И в ответ вы получите CUID.
Затем, следует пройти по пути восстановления пароля на Facebook.
Я заметил, что в конечной точке, ответственной за отправку OTP кода в Facebook, был параметр с именем:
should_use_flash_call=false
Если он установлен в false, вы получите OTP SMS на свой телефон, а если он установлен в true, вы получите телефонный звонок вместо OTP для восстановления учетной записи.
И в ответе содержались требуемые зашифрованные номера телефонов.
Теперь я не мог понять, что означает параметр cli.
Единственное, что мне пришло в голову, это «интерфейс командной строки (cli)».
Не сумев понять, я подставил null вместо значения.
Когда я сделал запрос, я получил идентификатор пользователя, значение электронной почты которого я указал в качестве CUID.
Это означает, что злоумышленник может предоставить чей-либо адрес электронной почты/телефона в качестве CUID, и в ответ он сможет точно определить, кому принадлежит этот адрес электронной почты.
Я быстро отправил отчет, и он был принят и исправлен в течение дня.
Мне было очень интересно узнать об этой конечной точке, поскольку я никогда не использовал «восстановление с помощью телефонного звонка» для сброса пароля.
Ни в моем пользовательском интерфейсе, ни в Google, ни в Youtube не было много информации об этом процессе восстановления учетной записи.
Итак, я начал анализировать, как работает этот процесс восстановления.
Конечная точка работала следующим образом.
- Я ввожу свой адрес электронной почты / телефон.
- Выбираю вариант восстановления с помощью телефонного звонка.
- Мне звонят по телефону.
- Этот номер телефона будет автоматически передан конечной точке как:
cuid=x&enc_phone=x&cli=+1xxxxx
Оказывается, в cli параметре мы должны указать номер телефона, с которого мы получили телефонный звонок на шаге 3.
Теперь стало понятно, почему это назвали восстановлением с помощью телефонного звонка. Я думаю, что cli означает что-то вроде caller identification.
В идеальном сценарии, когда мы предоставим все допустимые значения, мы получим следующий ответ:
{"id":"UserID","nonce":"XXXX","skip_logout_pw_reset":""}
Значение nonce действует как код OTP, а затем будет передано в конечную точку для проверки OTP.
Эта конечная точка выполняет проверку nonce и установку нового пароля.
В POST /flashcall_account_recovery, я сначала проверил будет ли работать сброс, если указать валидный cli другого пользователя, вместе с cuid жертвы, но это не сработало.
Я пробовал заменить все параметры тут и там, но ни один из них не работал.
Теперь единственный вариант, который у меня оставался, - это брутфорс параметра cli.
Учитывая, насколько строг Facebook с ограничением скорости брутфорса, так как он имеет ограничение скорости, реализованное даже на конечных точках без аутентификации, у меня не было почти никакой надежды.
Но, к моему абсолютному удивлению, в этой конечной точке не было реализовано ограничение скорости.
Следовательно, атака будет работать так:
- Пользователь подставляет cuid жертвы и enc_phone_number в конечную точку flashcall_account_recovery
- Брутфорс cli
- Получаем nonce из ответа
- Предоставляем nonce в конечную точку проверки OTP и устанавливаем новый пароль для учетной записи жертвы.
Таймлайн раскрытия электронной почты
Submitted: April 25, 2021
Triaged: April 27,2021
Fixed: April 27,2021
Таймлайн захвата аккаунта
Submitted: April 29, 2021
Triaged : April 30, 2021 at 3:32 PM
Fixed: April 30, 2021 at 3:49 PM
Мне потребовалось больше времени, чтобы проверить исправление, чем у Facebook, чтобы выпустить исправление, лол.
После тщательного расследования Facebook не обнаружил доказательств злоупотреблений, и 2 сентября вопрос был окончательно закрыт.
