Как провести тестирование на безопасность Android-приложения
Всем привет! Меня зовут Святослав, работаю QA gangsta lead в EVO, а в тестировании уже более 8 лет. Ищу уязвимости свыше 4 лет, веду тренинги по тестированию безопасности, провожу независимые аудиты security и QA. Также у меня есть security QA-блог для начинающих и Telegram-канал.
Cтатья будет актуальна для QA и в особенности для DEV, так как на их плечах лежит ответственность за безопасность приложения. Поэтому будет полезно узнать хотя бы косвенно, что могут быть такие-то и такие-то дыры при разработке мобильного приложения, так как все мы люди и человеческий фактор никто не отменял. Также расскажу об инструментах, с помощью которых можно базово определить слабые места проекта. И надо помнить: дополнительные знания не бывают лишними. Чем больше спектр ваших знаний, тем больше прибавки можно косить на проектах, так как вы частично можете перекрывать некоторые должности, беря на себя больше ответственности.
Вступление
В предыдущей статье я писал о том, как с Manual QA перешел к поиску веб-уязвимостей. К чему это я?! Когда занимаешься чем-то одним длительное время, оно надоедает, и я решил попробовать разобраться, как же происходят проверки на уязвимости в мобильных приложениях. Топик взял из списка OWASP TOP 10, только для мобайла. OWASP переехал, поэтому не смогу скинуть ссылку на официальный топик.
До переезда же сайта список уязвимостей был таков:
После того как я открыл список и ознакомился с мобильными топ-уязвимостями, понял, что половина из них полностью похожи на вебовские, то есть OWASP TOP 10 классический, который мы все так привыкли видеть. Так как, по сути, у нативных и веб-приложений один и тот же способ работы — по типу клиент-серверной архитектуры. То есть в мобайле клиентом является нативное приложение, а в вебе — браузер, но и у того, и у другого запросы поступают на сервер. Это и приводит к выводу, что половину техник можно взять из веб-уязвимостей, чтобы применить поиски дыр в нативных приложениях...
Начнем с того, какой набор инструментов нам нужен для проведения базового анализа защищенности приложения. Да, дополню: далее я буду рассказывать, как это применять для Android-приложений. У iOS немного другая специфика, об этом в другой статье.
Что нам понадобится
Тестовая среда, то есть апка. Для этого можем взять приложение DIVA. В нем собраны самые распространенные уязвимости мобильных приложений, и вы сможете попрактиковаться в их поиске.
Мобильный девайс. Либо поднятый через эмулятор Genymotion, либо реальный, но обязательно рутированный, так как без рут-привилегий пенетретить не удастся.
Santoku Linux. Этот дистрибутив был создан специально для того, чтобы проверять Android-апликухи на уязвимости. В нем уже из коробки предустановлены все нужные приложения для взлома.
В принципе все.
Итак, начнем поиск со статистики распространенности каждой из дыр топа OWASP. Если возьмем статистику 2018 года, то увидим, на какие категории уязвимостей стоит обращать больше внимания при аудите мобильного приложения.
А теперь, думаю, пора перейти к разбору каждой из категорий. Начнем рассматривать их не по порядку, а с M9 — Reverse Engineering, так как пентест начинается именно с нее.
M9 — Reverse Engineering
Реверс-инжиниринг мобильного кода — обычное явление. Это процесс простого и несанкционированного анализа:
- исходного кода приложения;
- библиотек;
- алгоритмов;
- таблиц и т. д.
Чтобы получить исходный код приложения, нужно на Santoku Linux закинуть установочный файл мобильного приложения, то есть APK, открыть консоль и выполнить нетрудные команды.
Выполняем команду unzip -d diva-beta base.apk. Как вы догадались, она разархивирует приложение и все файлы положит в папку, которую мы назвали diva-beta.
Далее нужно перейти в эту папку и в ней выполнить следующую команду: d2j -dex2jar classes.dex. С ее помощью мы совершаем декомпиляцию кода, который находится в этом файле. Если мы откроем этот файл без декомпиляции, то увидим в нем только кракозябры. После отработки этой команды в папке появится новый файл с именем classes-dex2jar.jar, в котором будет нормальный исходный код приложения, пригодный для чтения человеком.
Для того чтобы открыть этот файл и начать изучать код приложения, нам понадобится приложение Jadx, которое также установлено в нашем дистрибутиве Linux. Выполняем команду jd-gui classes-dex2jar.jar.
После отработки этой команды откроется приложение Jadx. Мы увидим в нем весь исходный код и сможем понять все его недостатки, то есть найти уже с его помощью какие-то уязвимости.
M1 — Improper Platform Usage
И с M9-категории перейдем к M1. К этой категории относится неправильное использование функции операционной системы или мер безопасности платформы. Это случается часто и может оказать существенное влияние на уязвимые приложения.
Давайте перейдем к примеру. Так как у нас это приложение уже есть с исходным кодом, с помощью предыдущей уязвимости изучим одну из activity этой апки.
Мы видим, что разработчик при дебаге приложения использовал logcat, чтобы понимать, какие ошибки были в данном поле. Но при компилировании приложения в релизную сборку забыл убрать эту команду дебага. Что это может означать для пользователей приложения? То, что действия будут логироваться, если там будут какие-то ошибка или предупреждения. То есть, когда юзер будет писать в форму (а, допустим, это форма для принятия карточных данных), эти данные будут мелькать в логах приложения, если пользователь допустит ошибку при заполнении формы или получит предупреждение по заполнению. Нетрудно догадаться, что к этим логам злоумышленник может получить доступ. Подробнее — в этом видосе.
M2 — Insecure Data Storage
Этот риск в списке OWASP информирует сообщество разработчиков о небезопасном хранении данных на мобильном устройстве. Злоумышленник может либо получить физический доступ к украденному устройству, либо войти в него, используя вредоносное ПО.
В случае физического доступа к устройству злоумышленник может легко получить доступ к файловой системе устройства после подключения его к компьютеру. Многие свободно распространяемые программы позволяют злоумышленнику получать доступ к каталогам и личным данным, содержащимся в них.
То есть нужно помнить о двух моментах:
- конфиденциальные данные в приложении надо хранить в зашифрованном виде;
- приложения могут делиться данными с другими приложениями.
Как пример возьмем форму регистрации в мобильном приложении.
Я как пользователь зарегистрировался в приложении. Разработчик взял и положил мои данные в незашифрованном виде в общедоступную папку, к которой имеют доступ другие приложения, установленные у меня в телефоне. Получаем то, что мои данные были слиты. Подробнее — в этом видео.
M3 — Insecure Communication
M3 — это еще один распространенный риск, о котором разработчики мобильных приложений забывают. Передача данных в мобильное приложение и из него обычно осуществляется через оператора связи или Wi-Fi. Известно, что злоумышленники добиваются успеха в раскрытии личной информации пользователей, если эта передача не защищена. Хакеры перехватывают данные пользователей в локальной сети через скомпрометированную сеть Wi-Fi, подключаясь к ней через маршрутизаторы, вышки сотовой связи, прокси-серверы либо используя зараженное приложение с помощью вредоносного ПО. При отправке запросов на сервер с данными, которые отправляет пользователь, некоторые из них иногда посылают по протоколу HTTP вместо HTTPS.
Пример эксплуатации такой уязвимости: злоумышленник создает скомпрометированную сеть Wi-Fi, к которой подключится пользователь. Затем этот man in the middle начинает анализировать весь трафик, который будет ходить через него. Соответственно, данные пользователя, которые отправляются к серверу по HTTP-протоколу, могут перехватываться. Злоумышленник будет видеть его креды в перехваченном пакете. Ниже приведены примеры, как передавать данные плохо и как — хорошо. Также можно посмотреть этот видос о перехвате трафика.
Плохо:
Данные стоит шифровать: даже если злоумышленник начнет слушать трафик, подключившись к той же сети, что и мы, то он хотя бы не увидит информации в открытом виде. То есть мы усложним ему задачу воровства данных, как это показано на картинке ниже.
M5 — Insufficient Cryptography
Ладно, мы применили шифрование, о котором говорили в разделе о предыдущей уязвимости. Но если мы используем слабые процессы шифрования/дешифрования или допускаем огрехи в алгоритмах, запускающих их, то данные пользователей опять становятся уязвимыми. Есть три способа, с помощью которых злоумышленники пытаются использовать криптографические проблемы:
- получить физический доступ к мобильному устройству;
- следить за сетевым трафиком;
- использовать вредоносные приложения на устройстве для доступа к зашифрованным данным.
Чтобы понять, какими же методами пользуются разработчики для шифрования данных, нужно взглянуть на исходный код, который мы уже имеем.
На картинке выше видим, что разработчик применил метод хеширования MD5, который прям так и кричит: «Ломай меня полностью!» Это один из самых легких методов.
При перехвате запроса от юзера мы увидим засекреченные на первый взгляд данные.
Но если пойдем на какой-то онлайн-декодер и забросим туда этот хеш, то увидим реальный пароль данного пользователя.
M4 — Insecure Authentication
Плохие схемы аутентификации позволяют злоумышленнику анонимно выполнять любые действия, доступные пользователю, в мобильном приложении или на сервере, используемом мобильным приложением. Слабая аутентификация для мобильных приложений довольно распространена из-за формфактора ввода мобильного устройства. Формфактор настоятельно рекомендует использовать короткие пароли, которые часто основаны на четырехзначных PIN-кодах. Требования аутентификации для мобильных приложений могут существенно отличаться от традиционных схем веб-аутентификации из-за требований доступности. Ожидается, что в традиционных веб-приложениях пользователи будут подключены к сети и будут аутентифицироваться в режиме реального времени.
Как только злоумышленник понимает, насколько уязвима схема аутентификации, он подделывает или обходит аутентификацию, отправляя запросы серверу на обработку мобильного приложения, при этом вообще не задействуя последнее.
Для примера: злоумышленник может использовать просто какой-то анализатор приложения, допустим тот же Burp Suite. Ему достаточно проанализировать, какие есть страницы у этого приложения.
Рассмотрим запрос на авторизацию. Мы видим данные, которые отправляются на сервер. Далее злоумышленник просто-напросто пытается получить информацию от сервера, используя исходную инфу в запросе. Он перебирает выделенные места, дабы достичь положительного результата несанкционированного доступа к данным кого-то из пользователей.
В этом запросе можно:
- обратить внимание на урлы;
- обратить внимание на тип юзера;
- попробовать подменить токен, подобрав нужный (с доступом к админским функциям), и т. д.
О том, как настраивать анализатор к мобильному приложению, я писал в статье о M3 — Insecure Communication.
M6 — Insecure Authorization
Многие люди путают риск M4 с риском M6, поскольку оба они касаются учетных данных пользователя. Разработчик должен иметь в виду, что M6 включает в себя использование авторизации для входа в систему в качестве легитимного пользователя, в отличие от M4, когда злоумышленник пытается обойти процесс аутентификации, войдя в систему как анонимный пользователь.
Как только злоумышленник получит доступ к приложению в качестве законного пользователя, обманув механизм безопасности приложения, следующая его задача в M6 — получить административный доступ путем принудительного перебора запросов, среди которых он может наткнуться на команды администратора. Злоумышленники обычно применяют ботнеты или вредоносные программы на мобильном устройстве для использования уязвимостей авторизации. Результатом этого нарушения безопасности становится то, что злоумышленник может выполнить бинарные атаки на устройстве в автономном режиме.
Поиск можно делать также с помощью Burp Suite, пытаясь выполнить запросы, которые доступны админу, в качестве обыкновенного пользователя. Смотрите уязвимость M4.
M7 — Client Code Quality
Риск M7 возникает из-за плохой или противоречивой практики кодирования, когда каждый член команды разработчиков придерживается разных практик кодирования и создает несоответствия в конечном коде. Экономия для разработчиков здесь заключается в том, что, даже если распространенность этого риска общая, его выявляемость низкая. Хакерам нелегко изучить паттерны плохого кодирования, часто требуется непростой ручной анализ. Из-за плохого кодирования пользователь мобильного устройства может столкнуться с замедлением обработки запросов и невозможностью правильно загрузить необходимую информацию.
В пример можно привести историю с WhatsApp, когда его инженеры обнаружили возможность переполнения буфера путем отправки специально созданной серии пакетов. Для этого не нужно было отвечать на вызов, и злоумышленник мог выполнить произвольный код. Оказалось, что такая уязвимость использовалась для установки на телефон программ-шпионов. Эту услугу продала израильская компания NSO Group.
Не стоит использовать функции, которые могут переполнить буфер, вот так:
M8 — Code Tampering
Здесь все ясно и понятно, и рассказывать нечего. Просто не стоит скачивать приложения APK со сторонних ресурсов, так как хакеры предпочитают фальсификацию кода в приложениях, поскольку это позволяет им получить неограниченный доступ:
- к другим приложениям в вашем телефоне;
- к поведению пользователя.
M10 — Extraneous Functionality
Перед тем как приложение будет готово к работе, команда разработчиков часто хранит в нем код, чтобы иметь легкий доступ к внутреннему серверу. Этот код никаким образом не влияет на функционирование приложения. Но когда злоумышленник найдет эти подсказки, то разработчикам будет не очень прикольно. Вдруг это будут креды для входа в систему с правами админа?
В качестве примера возьмем страницу, на которой нужно ввести ключ для получения доступа к важным данным. Изучим, как выглядит эта страница под капотом, то есть в коде.
Увидим, что здесь разработчик оставил подсказку, что нужно ввести, чтобы получить доступ к необходимым нам данным. Видос здесь.
Подытожим
Теперь вы знаете:
- об OWASP Mobile Top 10;
- инструменты, с помощью которых можно искать уязвимости;
- программах, в которых можно попрактиковаться в поиске уязвимостей.
Приобретя новые навыки в тестировании, вы можете поднять свою значимость в компании, взяв на себя больше ответственности, и найти уязвимые места в своих приложениях. Когда руководство увидит ваш отчет о проделанной работе, то непременно накинет вам премию либо пересмотрит размер вашей зарплаты. Теперь вы специалист по безопасности, а таких на рынке большая недостача, то есть ценность вас как профессионала повышается. И помните: все показанное выше предназначено для обучения! Применять эту информацию в своих проектах можно только с разрешения правообладателя.
