Четвёртый апдейт по стажировке Positive Technologies

Четвёртый вебинар, посвящённый уязвимостям мобильных приложений, был категорически интересным. Но интереснее вебинара было домашнее задание, которого пришлось ждать больше двух недель, но оно того стоило. Впрочем, обо всём по порядку.

Изначально я хотел описать и лекцию, но тут итак много букв, потому скажу, что Артём довольно ёмко уместил туда теорию устройства типичного приложения, описал основные векторы атак и включил ряд классных примеров из его собственной практики.

Теперь к самому интересному — домашней работе. Специально для этого нам предоставили серверную часть в форме дистрибутива Kali, с находящимся на нём бэкендом, имитирующим интернет-банк (по всей видимости, это Bankf с Positive Hack Days 6).

bankf-web0

bankf-web1

В такой форме он уже является интересной площадкой для тестирования, поскольку имеется два аккаунта, что позволяет тестить атаки типа клиент-клиент, а также множество возможностей для race condition, CSRF и прочего. Задача — проэксплуатировать клиентские уязвимости, при этом мне так и не удалось понять, является ли веб-клиент мишенью или нет. Вместе с бэкендом предоставили и клиентское мобильное приложение для этого импровизированного банка. Поскольку блок был посвящён уязвимостям мобильных приложений, то баги я искал только в нём. Возможно, этого было недостаточно.

bankf-app0

Поскольку раньше я с задачей разбора apk не сталкивался, я сразу же попытался найти дистрибутив, где все инструменты были бы готовы к применению. Дистрибутив нашёлся и, к счастью, очень удобный и грамотно укомплектованный. К сожалению, заброшенный в 2014-м году на версии 0.5, такая досада. Итак, ковырять будем в Santoku Linux на базе Ubuntu версии 14.04. Несколько дней ушло на первичную подготовку и освоение инструментария, но оно того, безусловно, стоило.

События, которые пошли не по плану:

  • При декомпиляции apk с помощью apktool d snatch_exam.apk программа возвращала ошибку посреди процесса, ругаясь на косяки при декодировании XML. При этом AndroidManifest.xml декодировался и выглядел исправно. Если же запустить программу с параметром «—no-res Do not decode resources«, нормально выгружается всё остальное содержимое архива с приложением, но нечитаемым становится AndroidManifest.xml.
  • Какое-то время ушло на поиск способа прогонять весь трафик через Burp Suite. Для штатного эмулятора, которым я пользовался, это делается при запуске с помощью дополнительного параметра: emulator -avd snatch -http-proxy http://xxx.xxx.xxx.xxx:pppp, где snatch — название эмулятора в AVD.

А теперь кратко пройдёмся по тому, что я зарепортил.

  • Самое простое: API выкидывает ошибку в ответ на запрос метода auth, даже если вход осуществляется корректно. В ошибке содержится полный путь, что не есть хорошо.

  • Также в коде приложения обнаружилось, что должен применяться certificate pinning, дабы затруднить задачу перехвата трафика приложения, однако у меня при совершении транзакций certificate pinning не работал, позволяя беспрепятственно проксировать трафик. А если бы и заработал, то внутри apk обнаружился и сам сертификат, бесхитростно лежащий в каталоге /assests.
  • Кука, полученная мобильным приложением при авторизации, остаётся активной даже после выполнения штатного выхода из приложения и новый вход не деактивирует старую куку. Если сложить эту уязвимость с возможностью изъять файл сертификата (или совершить иную атаку на защищённое соединение) и контролировать трафик клиентов банка, то можно представить себе атаку, когда злоумышленник собирает в общественной сети валидные куки клиентов банка, а потом использует их для осуществления переводов. Помимо валидности куки, других механизмов, призванных этому воспрепятствовать, я не обнаружил. При этом мобильное API имеет удобные методы, при помощи которых, обладая кукой, можно получить и номера счетов и балансы жертвы, после чего осуществить перевод на всю сумму.

Несложно крафтится и запрос на перевод:

  • Интереснее ломается приложение именно через эксплуатацию уязвимости, связанной с межпроцессным взаимодействием Android. Непосредственно за перевод средств в приложении отвечает MoneyTranferActivity. Чтобы полнее увидеть, в чём заключается уязвимость, лучше глянуть на манифест целиком.

Итак, активити под названием MoneyTransferActivity, во-первых, использует кастомное разрешение payment_permission с уровнем защиты dangerous, а во-вторых, включает intent-filter, что делает данную активити неявно экспортированной. Комбинация этих двух условий позволяет атакующему вызывать критическую для приложения функциональность извне и со своими параметрами при помощи, например, вредоноса. В качестве proof-of-concept, пишем примитивное приложение, предназначенное исключительно для атаки на данное клиентское банковское приложение.

В манифесте запрашиваем то самое кастомное разрешение payment_permission. Благодаря уровню защиты dangerous помимо намерения не требуется больше ничего.

Теперь в onCreate вставляем следующий код:

id = 33 это идентификатор клиента, а вот в receiver бережно кладём счёт атакующего. Если на момент установки/запуска нашего вредоноса клиент залогинен в Snatch, то произойдёт перевод на указанный нами счёт, после чего фокус возвращается на наше приложение.

bankf-app1

bankf-app2

Конечно, можно доработать вредонос, чтобы он висел в фоне и определял, залогинен ли пользователь, умел из логов дебага доставать счёт и идентификатор жертвы, но это всего лишь PoC.

В приложении имеется и другая, более продвинутая уязвимость, проэксплуатировать которую мне пока что не удалось. Она связана с возможностью отправлять сообщения другим пользователям приложения во вкладке с чатом технической поддержки. Если мне это удастся, я дополню пост.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *