Взлом аккаунта мессенджера с помощью Burp Suite

Эту уязвимость я нашел при анализе мобильного приложения популярной региональной соцсети. Уязвимость заключается в том, что когда пользователь производит авторизацию в приложении с помощью SMS, необходимые для успешного входа данные генерируются на стороне клиента. Хакер, не имея доступа к смартфону пользователя, может подделать цепочку запросов и ответов приложения и завладеть его учетной записью.

Еще по теме: Вы верите в безопасность мессенджеров?

Приложение распространяется в версиях для iOS и Android, дополнительно может быть использован веб-интерфейс. На сегодняшний день только на Андроид свыше миллиона загрузок. Аналог для iOS находится в списке 200 самых популярных мессендлеров в App Store.

Для анализа приложения использовался метод «черного ящика» — на основе общедоступных приложений и веб-клиента. При исследовании приложений был выявлен используемый SSL Pinning. На Android его удалось частично обойти путем настройки скриптов Frida (см. Способы обхода SSL Pinning Android). На iOS разрабы использовали последние версии средств защиты, для которых пока не существует обхода.

Статья в образовательных целях для обучения этичных хакеров (багхантеров). Баг Баунти — это программа, которую владелец приложения проводит для привлечения сторонних специалистов к поиску уязвимостей. При участии в программе Bug Bounty нужно действовать этично и придерживаться установленных правил. Ни редакция spy-soft.net, ни автор не несут ответственности за ваши действия.

Основная проблема заключалась в том, что для взаимодействия с сервером приложение использовало gRPC (на основе Protobuf). Поскольку тестирование осуществлялось методом «черного ящика», у меня не было proto-файла с описанием структур. Поэтому все обнаруженные уязвимости были выявлены при ручном анализе proto-запросов.

Для работы gRPC я использовал расширение Blackbox Protobuf для Burp Suite (см. Перехват трафика Android-приложения в Burp и Frida). Но версия из репозитория неправильно парсила поля запроса. Для того чтобы она работала корректно, мне понадобилось модифицировать расширение, добавить новый заголовок к сообщениям и поменять алгоритм разбора поля Additional Data в gRPC.

Сум­марно на обход SSL Pinning и модифи­кацию рас­ширения для Burp Suite ушла одна рабочая неделя. На руч­ной ана­лиз gRPC и поиск уяз­вимос­тей в мес­сен­дже­ре — око­ло трех недель. По ходу дела в при­ложе­нии уда­лось най­ти три уяз­вимос­ти высоко­го уров­ня опас­ности, одну — сред­него и одну — низ­кого.

Взлом аккаунта мессенджера с помощью Burp Suite

Так как наз­вание полей было неиз­вес­тно, на схе­ме они пред­став­лены циф­рами (иден­тифика­тора­ми полей).

Для вхо­да в при­ложе­ние вво­дит­ся номер телефо­на поль­зовате­ля и кап­ча. В ответ сер­вер воз­вра­щает UUID сес­сии аутен­тифика­ции.

Для вхо­да в при­ложе­ние поль­зователь дол­жен ввес­ти одно­разо­вый код, получен­ный по SMS. Код отправ­ляет­ся с UUID, получен­ным из прош­лого зап­роса.

При вво­де невер­ного кода при­ложе­ние вер­нет ответ 11. Это код ошиб­ки, озна­чающий, что невер­но вве­ден код OTP.

При вер­ном коде в зна­чении поля воз­вра­щает­ся null, это зна­чит, что код кор­рек­тный. Если ошиб­ки нет, при­ложе­ние соз­дает UUID #2 (помечен крас­ным). И отправ­ляет эти два UUID сер­веру, в ответ получая сес­сию.

Как вид­но из схе­мы, сер­вер не воз­вра­щает допол­нитель­ную информа­цию при отправ­ке кор­рек­тно­го кода. Поэто­му я пред­положил, что UUID #2 генери­рует­ся толь­ко на осно­ве вре­мени.

Для про­веде­ния ата­ки я с помощью Burp Suite модифи­циро­вал ответ, который сер­вер воз­вра­щает при вво­де невер­ного одно­разо­вого кода. Это поз­волило сге­нери­ровать на кли­енте вер­ный UUID #2 для сес­сии и получить дос­туп к акка­унту.

Шаг 1. Запрос на отправку SMS (создание новой сессии аутентификации)

Пер­вым вызыва­ется метод SendCodeRecaptcha сер­виса аутен­тифика­ции (AuthService).

Зап­рос SMS выг­лядит сле­дующим обра­зом.

Этот gRPC-зап­рос в декоди­рован­ном виде содер­жит два поля:

• по­ле 1 — номер телефо­на (+79…);
• по­ле 2 — reCAPTCHA (03A…).

От­вет сер­вера будет таким.

В декоди­рован­ном виде ответ содер­жит два поля:

• по­ле 2 — UUID сес­сии аутен­тифика­ции, который будет исполь­зовать при даль­нейших зап­росах (e94f46ce-c9f1-11eb-9433-027eb92e4dfc);
• по­ле 4 — секун­ды до того, как мож­но будет отпра­вить еще одну SMS на тот же номер (120 секунд).

Шаг 2. Ввод одноразового кода из SMS

Да­лее зло­умыш­ленник вво­дит слу­чай­ный код под­твержде­ния (OTP) и отправ­ляет зап­рос.

Зап­рос на отправ­ку кода под­твержде­ния про­изво­дит­ся через метод VerifyCode сер­виса аутен­тифика­ции.

Зап­рос в декоди­рован­ном виде содер­жит два поля:

• по­ле 1 — UUID сес­сии аутен­тифика­ции (содер­жимое поля 2 из отве­та сер­вера на прош­лом шаге);
• по­ле 2 — код под­твержде­ния из SMS (2345).

Хакер перех­ватыва­ет ответ сер­вера с ошиб­кой.

В декоди­рован­ном виде ответ содер­жит поле 1 с ошиб­кой 11 (некор­рек­тный код из SMS).

Шаг 3. Подмена ответа сервера с ошибки на успешный

Для ата­ки зло­умыш­ленник под­меня­ет ответ сер­вера: вмес­то отве­та с ошиб­кой при­дет сооб­щение об успешном вво­де кода из SMS.

В декоди­рован­ном виде:

• по­ле 1 — опре­деля­ет ошиб­ки от сер­вера (пус­той мас­сив);
• по­ле 2 — пред­положи­тель­но переда­ет зна­чение успе­ха о вво­де кода (True).

Шаг 4. Генерация кода подтверждения и отправка запроса на вход в систему

На осно­ве успешно­го отве­та JavaScript генери­рует код под­твержде­ния. Дан­ные для вхо­да в при­ложе­ние отправ­ляет метод SignIn сер­виса аутен­тифика­ции.

Рас­шифро­ван­ные дан­ные содер­жат два поля:

• по­ле 1 — UUID сес­сии аутен­тифика­ции из прош­лых зап­росов;
• по­ле 3 — код под­твержде­ния (UUID #2), генери­руемый сай­том при успешном вво­де кода из SMS.

В ответ на этот зап­рос сер­вер воз­вра­щает сооб­щение об успешном вхо­де вмес­те с токеном JWT. Этот токен поз­воля­ет получить пол­ный дос­туп к акка­унту жер­твы.

Для про­вер­ки уяз­вимос­ти я успешно вошел в акка­унт кол­леги с его раз­решения.

Выводы

Итак, мне уда­лось про­демонс­три­ровать воз­можность зах­вата чужой учет­ной записи. Что­бы зак­рыть эту дыру, раз­работ­чику дос­таточ­но перенес­ти на сер­вер генера­цию дан­ных, необ­ходимых для вхо­да в акка­унт. Ког­да я тес­тировал эту уяз­вимость во вто­рой раз, механизм был перера­ботан: генера­ция вто­рого кода (UUID #2) теперь про­изво­дит­ся на осно­ве одно­разо­вого кода и вре­мени, количес­тво отпра­вок так­же огра­ниче­но.

Спасибо, Danr0, за интересный райтап.

ПОЛЕЗНЫЕ ССЫЛКИ:

• Установка Frida Server на Android
• Взлом приложений iOS с помощью Objection
• Пентест мобильных приложений iOS используя Frida