Это первая уязвимость из списка OWASP TOP 10, скрывающихся в мобильных приложениях. Статейка посвящена первой категории списка, M1-Improper platform usage, на нашем (Неправильное использование платформы).
Неправильное использование платформы в основном охватывает злоупотребление функциями платформы или неиспользование средств управления безопасностью платформы, предоставленных и задокументированных платформой и ее сообществом. К примеру, в приложениях на Android, всегда есть файл AndroidManifest.xml, который является хорошим носителем информации о конфигурации приложения и о том, как приложение должно вести себя. Этот файл действительно необходим для проверки ошибок конфигурации. Здесь мы будем использовать проект InsecureBankv2 - это специальное уязвимое приложение Android, предназначенное для практики на безопасность, чтобы узнать об уязвимостях в Android. Сначала мы загружаем проект InsecureBankv2, но прежде чем запустить эмулятор и установить приложение, давайте сосредоточимся на получении доступа к файлу AndroidManifest.xml и посмотрим, что у нас есть. Для этого мы будем использовать apktool, инструмент, предназначенный для обратного проектирования Android apks. У инструмента есть несколько опций, но мы сосредоточимся на опции декодирования, которая извлекает и декодирует ресурсы apk, инструмент создает читаемый файл AndroidManifest.xml и код smali для исходного кода приложения :
В предыдущей команде мы установили опцию -d для декода приложения и опцию -o, чтобы указать каталог, в который мы хотим отправить результаты. Теперь перейдем в папку и увидим, что инструмент сгенерировал AndroidManifest.xml, а также папки resources и smali, а сейчас мы сосредоточимся на манифесте. Кстати эти все действия по декодированию и изъятию первоистоков кода приложения, относятся к девятой категории уязвимости OWASP TOP 10 mobile и имеет название M9 Reverse Engineering
Отлаживаемое приложение
При создании приложения отладчик - лучший друг разработчика, он позволяет построчно проверять код приложения во время его выполнения, что помогает выявлять основные причины ошибок и исправлять их. Однако отправка вашего приложения с включенным флагом отладки представляет угрозу безопасности для вашего приложения; это может позволить злоумышленнику получить доступ к конфиденциальной информации, контролировать поток приложения и получить выполнение кода в контексте отлаженного приложения.
Разрешить резервное копирование
Разрешение резервного копирования приложения может также привести к ситуациям, в которых злоумышленник, имеющий доступ к устройству, может внедрить код. Как только злоумышленник может получить резервную копию приложения, заголовок резервной копии отделяется от содержимого (кода и ресурсов), содержимое затем модифицируется путем введения кода или изменения значений ресурсов, затем добавляется измененное содержимое к неизмененному заголовку и вставьте обратно в устройство.
Заключение
Согласно OWASP Mobile Top 10, неправильное использование платформы является основным риском, влияющим на мобильные приложения в мире. Это имеет смысл в том смысле, что разработчики в основном заинтересованы в том, чтобы заставить приложение работать, и иногда неправильно используют функции платформы или упускают специальные средства управления безопасностью, которые могут легко снизить эти риски. Таким образом, осведомленность разработчиков о безопасности является одним из наиболее эффективных компонентов в создании защищенного программного обеспечения.
Из-за неправильного использования платформы, могут возникнуть также такие векторы уязвимостей:
- Poor Web Services Hardening
- Insecure web server configurations
- Injection (SQL, XSS, Command) on both web services and mobile-enabled websites
- Authentication flaws
- Session Management flaws
- Access control vulnerabilities
- Local and Remote File Includes
В данной категории трудно дать правильный совет, так как очень много есть векторов от данной категории уязвимости, но овасп тут рекомендует вот такое:
Безопасные методы кодирования и настройки должны использоваться на стороне сервера мобильного приложения. За конкретной информацией об уязвимости обращайтесь к проектам OWASP Web Top Ten или Cloud Top Ten.
А теперь давайте рассмотрим один из случаев данной категории уязвимости, под названием Insecure Logging.
Открыв AndroidManifest.xml, начнем исследовать его содержимое, в этом случае мы будем использовать текстовый редактор nano следующим образом. С помощью команды nano AndroidManifest.xml, мы откроем этот файл:
Небезопасные компоненты
Одна из первых вещей, которую вы должны проверить в этом файле конфигурации - это содержимое внутри тега <application> , здесь вы найдете компоненты, определенные для этого приложения, компоненты - это действия, приемники широковещания, поставщики контента или сервисы, каждый из которых со своими собственными функциональными возможностями и характеристиками. В целом, если вы видите несколько компонентов с установленным флагом true, это, скорее всего, является признаком неправильной конфигурации и неправильного использования платформы.
Каждый компонент должен быть рассмотрен и проанализирован, чтобы понять, для чего он используется и какой информацией они могут делиться с другими компонентами. Одним из очень полезных инструментов, который поможет в этом вопросе, является среда drozer, которая позволяет вам искать уязвимости в системе безопасности на базе Android. Вы можете найти пример работы с ним в моей статье по четвертой уязвимости, в которой мы искали обход авторизации.
С помощью инструмента Jadx, мы можем узнать исходный код нашего приложения apk. Этот метод декомпилирования тоже относиться к реверс инженерии, то-есть к 9-ой категории оваспа. В этом примере будем юзать приложение DIVA. Выполнив команду:
d2j-dex2jar classes.dex
Мы получим вид кода данного приложение в первичном виде, а затем, чтоб открыть данный файл в редакторе для анализа, выполним такую команду:
jd-gui classes-dex2jar.jar
Этот вектор атаки можно совершить, если разработчик употреблял функцию Logcat, в дебаг режиме, для тестирования работы приложения. Для нагнетания ситуации, возьмем пример функционал ввода данных кредитной карты. Затем забыл убрать из кода ее, задеплоив на продакшен билд вместе с получением логов данной функции. В итоге какой бы не был приличный программер, у него будет доступ к карточным данным ваших пользователей, так как он будет видеть в логах эти данные, а представьте, если к этим логам будет доступ не только у этого программиста... Посмотрим пример на видео ниже...
А вся проблема такой уязвимости кроется, в этом...