- 372
- 128
- 22 Июн 2019
Damn Insecure Vulnerable App (DIVA) - это невероятно уязвимое приложение, предназначенное, чтобы познакомить вас с типовыми багами, которые можно повстречать на платформе Android.
Давайте учиться на практике!
Шаг 1. Скачайте DIVA по Для просмотра ссылки Войдиили Зарегистрируйся, распакуйте и установите.
Шаг 2. Если у вас все еще отсутсвует Android-лаборатория для анализа, рекомендую развернуть ее с помощью Android Studio. То, как это можно сделать, можно узнать в одной из моих Для просмотра ссылки Войдиили Зарегистрируйся статей.
Шаг 3. После того, как Diva будет запущено на эмуляторе, откройте его параллельно в jadx-gui, если хотите просмотреть исходный код на Java.
Небезопасное логгирование
Находясь в терминале Android Studio, перейдите в папку с adb:
Код:
cd ~/Library/Android/sdk/platform-tools
И запустите оболочку: ./adb shell
Находясь в ней, введите команду ps, чтобы просмотреть список запущенных процессов. Поищите в нем jakhar.aseem.diva и обратите внимание на второй столбец - это PID-идентификатор, который необходимо запомнить. В данном случае он равен 18976.
Теперь для того, чтобы просмотрить логи нужного приложения (в данном случае, DIVA), я выполняю logcat | grep 18976 (где 18976 - его PID) или ./adb logcat, однако вторую команду использовать не рекомендуется, поскольку она будет выводить логи всех приложений со множеством мусорных строк.
Как вы можете заметить, в логах иногда проскакивает конфиденциальная информация, которая может быть доступна другим приложениям, если у них будет соотствествующее разрешение на чтение.
Хардкодинг, часть первая
Как я уже упоминал выше, используя jadx-gui, вы можете просматривать исходный код apk-файла в формате Java. Обратите внимание на жестко запрограммированный ключ доступа - он и есть искомая уязвимость.
Небезопасное хранение данных, часть первая
После того, как мы ввели некоторые данные и сохранили их, приложение оповещает о том, что они успешно сохранены. Однако, где?
Потребуется запустить шелл от имени рутового пользователя, как это показано на скриншоте ниже. А затем перейти в директорию /data/data - именно в ней, предположительно, находятся сохраненные сведения.
А, если быть точнее, данные хранятся в каталоге shared_prefs. Я нашел его, когда стокнулся с упоминаниями SharedPreferences в исходном коде.
Небезопасное хранение данных, часть вторая
Во второй части таска с небезопасных хранением исходный код указывает на то, что учетные данные хранятся в базе данных SQL
В той же самой директории, которая была найдена на предыдущем этапе, в подпапке databases лежит 4 файла, ids2 - база данных, в которую была сохранена информация.
Небезопасное хранение данных - часть третья
После сохранения введенных данных, я в очередной раз взглянул на исходники.
Меня заинтересовал метод createTempFile, создающий, как вы уже поняли, временный файл с информацией, отправленной из формы.
Он точно также, как и раньше, лежит в каталоге /data/data/jakhar.aseem.diva.
Небезопасное хранение данных, часть четвертая
«Произошла ошибка файла» - когда я нашал на кнопку "Save".
В чем проблема? Похоже, что приложение пытается сохранить учетные данные во внешнем хранилище устройства. Скорее всего, ему не хватает для этого прав. Проверить права на хранение можно в настройки > разрешения приложений > хранилище > Diva, там же - предоставить доступ.
Я попытался еще раз сохранить данные, и на этот раз сработало!
Используя терминал, перемещаемся на sdcard и видем, что учетные данные сохранены в /sdcard/.uinfo.txt.
Проблемы валидации входных данных, часть первая
Приложение просит ввести имя пользователя. Если его ввести верно, то выведется его пароль и данные кредитной карты.
Поскольку в данной секции подразумеваются проблемы с проверкой входных данных, я попробовал реализовать простую SQL-инъекцию - и она сработала.
Проблемы валидации входных данных, часть вторая
Сначала я попытался обратиться к реально существующему сайту, чтобы проверить, отправится ли к нему запрос. Затем я использовал аббревиатуру file:/ для доступа к локальным файлам на тестируемом устройстве, и смог получить всю конфиденциальную информацию из разных мест.
Проблемы контроля доступа, часть первая
Просмотреть учетные данные для подключения к API можно нажав на кнопку «VIEW API CREDENTIALS». Проблема состоит в том, что к этим данным можно также получить доступ и извне.
Запустите logcat, чтобы увидеть, что происходит после нажатия на кнопку «VIEW API CREDENTIALS». Здесь есть интересная запись ActivityManager'а и произведенное им действие.
Отталкиваясь от него, для того, чтобы приложение само открылось и отобразило повторно эти данные, но уже без нажатия на кнопку, будет достаточно команды
Код:
am start jakhar.aseem.diva/.APICredsActivity
Проблемы контроля доступа, часть вторая
Здесь уже не получится так просто получить данные извне, так как для того, чтобы открыть то же самое окно с критичной информацией, необходимо будет ввести PIN. Давайте нажмем на кнопку "Register Now" и проверим логи (logcat)
Обратите внимание, что фактическое значение chk_pin - check_pin.
Нужно обойти проверку, чтобы получить доступ к учетным данным без пин-кода.
Из logcat мы уже знаем, что диспетчер активности - jakhar.aseem.diva / .APICreds2Activity
Код:
./adb shell am start -n jakhar.aseem.diva / .APICreds2Activity --ez check_pin false
Теперь давайте переключимся обратно, нажмем на кнопку и удостоверимся в том, что приложение больше не потребовало ввести пин-код.
Проблемы контроля доступа, часть третья
Перед тем, как приступить к редактированию личной заметки, приложение предложит создать для нее индивидуальный пин-код, чтобы никто посторонний не смог получить доступ к ее содержимому.
Давайте снова обратимся к исходному коду .xml и .java, чтобы найти недостатки. Нас интересует следующее:
Из logcat мы видим, что диспетчер активности - jakhar.aseem.diva / .AccessControl3Activity
AndroidManifest.xml показывает поставщика содержимого jakhar.aseem.diva.provider.notesprovider; android: enabled = «true» и android: exported = «true», что означает, что компоненты других приложений могут иметь к нему доступ.
А исходники NotesProvider.java показывают, где хранятся заметки.
CONTENT_URI = Uri.parse(“content://jakhar.aseem.diva.provider.notesprovider/notes”);
Выполнение следующей команды предоставляет доступ к содержимому заметок без пин-кода.
Код:
./adb shell content query --uri content://jakhar.aseem.diva.provider.notesprovider/notes
Хардкодинг, часть вторая
Вместо использования jadx-gui, на этот раз я задумался о том, чтобы перейти к более серьезные инструментам для реверс-инжиниринга. Это нужно для того, чтобы изучить файл библиотеки (.so), который не поддерживается jadx-gui.
[automerge]1619000923[/automerge]
Здесь есть два способа: использовать гидру (читайте Для просмотра ссылки Войдиили Зарегистрируйся статью), либо apktool.
Использование apktool
Извлеките содержимое diva-beta.apk, выполнив команду:
Код:
apktool d diva-beta.apk
Теперь, просматривая libdivajni.so, обращайте внимание на любые подозрительные строки и вводите их в поле ввода имени пользователя.
Код:
strings arm64-v8a/libdivajni.so
оригинал на английском можно Для просмотра ссылки Войдиили Зарегистрируйся.
Давайте учиться на практике!
Шаг 1. Скачайте DIVA по Для просмотра ссылки Войди
Шаг 2. Если у вас все еще отсутсвует Android-лаборатория для анализа, рекомендую развернуть ее с помощью Android Studio. То, как это можно сделать, можно узнать в одной из моих Для просмотра ссылки Войди
Шаг 3. После того, как Diva будет запущено на эмуляторе, откройте его параллельно в jadx-gui, если хотите просмотреть исходный код на Java.
Небезопасное логгирование
Находясь в терминале Android Studio, перейдите в папку с adb:
Код:
cd ~/Library/Android/sdk/platform-tools
И запустите оболочку: ./adb shell
Находясь в ней, введите команду ps, чтобы просмотреть список запущенных процессов. Поищите в нем jakhar.aseem.diva и обратите внимание на второй столбец - это PID-идентификатор, который необходимо запомнить. В данном случае он равен 18976.
Теперь для того, чтобы просмотрить логи нужного приложения (в данном случае, DIVA), я выполняю logcat | grep 18976 (где 18976 - его PID) или ./adb logcat, однако вторую команду использовать не рекомендуется, поскольку она будет выводить логи всех приложений со множеством мусорных строк.
Как вы можете заметить, в логах иногда проскакивает конфиденциальная информация, которая может быть доступна другим приложениям, если у них будет соотствествующее разрешение на чтение.
Хардкодинг, часть первая
Как я уже упоминал выше, используя jadx-gui, вы можете просматривать исходный код apk-файла в формате Java. Обратите внимание на жестко запрограммированный ключ доступа - он и есть искомая уязвимость.
Небезопасное хранение данных, часть первая
После того, как мы ввели некоторые данные и сохранили их, приложение оповещает о том, что они успешно сохранены. Однако, где?
Потребуется запустить шелл от имени рутового пользователя, как это показано на скриншоте ниже. А затем перейти в директорию /data/data - именно в ней, предположительно, находятся сохраненные сведения.
А, если быть точнее, данные хранятся в каталоге shared_prefs. Я нашел его, когда стокнулся с упоминаниями SharedPreferences в исходном коде.
Небезопасное хранение данных, часть вторая
Во второй части таска с небезопасных хранением исходный код указывает на то, что учетные данные хранятся в базе данных SQL
В той же самой директории, которая была найдена на предыдущем этапе, в подпапке databases лежит 4 файла, ids2 - база данных, в которую была сохранена информация.
Небезопасное хранение данных - часть третья
После сохранения введенных данных, я в очередной раз взглянул на исходники.
Меня заинтересовал метод createTempFile, создающий, как вы уже поняли, временный файл с информацией, отправленной из формы.
Он точно также, как и раньше, лежит в каталоге /data/data/jakhar.aseem.diva.
Небезопасное хранение данных, часть четвертая
«Произошла ошибка файла» - когда я нашал на кнопку "Save".
В чем проблема? Похоже, что приложение пытается сохранить учетные данные во внешнем хранилище устройства. Скорее всего, ему не хватает для этого прав. Проверить права на хранение можно в настройки > разрешения приложений > хранилище > Diva, там же - предоставить доступ.
Я попытался еще раз сохранить данные, и на этот раз сработало!
Используя терминал, перемещаемся на sdcard и видем, что учетные данные сохранены в /sdcard/.uinfo.txt.
Проблемы валидации входных данных, часть первая
Приложение просит ввести имя пользователя. Если его ввести верно, то выведется его пароль и данные кредитной карты.
Поскольку в данной секции подразумеваются проблемы с проверкой входных данных, я попробовал реализовать простую SQL-инъекцию - и она сработала.
Проблемы валидации входных данных, часть вторая
Сначала я попытался обратиться к реально существующему сайту, чтобы проверить, отправится ли к нему запрос. Затем я использовал аббревиатуру file:/ для доступа к локальным файлам на тестируемом устройстве, и смог получить всю конфиденциальную информацию из разных мест.
Проблемы контроля доступа, часть первая
Просмотреть учетные данные для подключения к API можно нажав на кнопку «VIEW API CREDENTIALS». Проблема состоит в том, что к этим данным можно также получить доступ и извне.
Запустите logcat, чтобы увидеть, что происходит после нажатия на кнопку «VIEW API CREDENTIALS». Здесь есть интересная запись ActivityManager'а и произведенное им действие.
Отталкиваясь от него, для того, чтобы приложение само открылось и отобразило повторно эти данные, но уже без нажатия на кнопку, будет достаточно команды
Код:
am start jakhar.aseem.diva/.APICredsActivity
Проблемы контроля доступа, часть вторая
Здесь уже не получится так просто получить данные извне, так как для того, чтобы открыть то же самое окно с критичной информацией, необходимо будет ввести PIN. Давайте нажмем на кнопку "Register Now" и проверим логи (logcat)
Обратите внимание, что фактическое значение chk_pin - check_pin.
Нужно обойти проверку, чтобы получить доступ к учетным данным без пин-кода.
Из logcat мы уже знаем, что диспетчер активности - jakhar.aseem.diva / .APICreds2Activity
Код:
./adb shell am start -n jakhar.aseem.diva / .APICreds2Activity --ez check_pin false
Теперь давайте переключимся обратно, нажмем на кнопку и удостоверимся в том, что приложение больше не потребовало ввести пин-код.
Проблемы контроля доступа, часть третья
Перед тем, как приступить к редактированию личной заметки, приложение предложит создать для нее индивидуальный пин-код, чтобы никто посторонний не смог получить доступ к ее содержимому.
Давайте снова обратимся к исходному коду .xml и .java, чтобы найти недостатки. Нас интересует следующее:
- AndroidManifest.xml
- AccessControl3Activity
- AccessControl3NotesActivity
- NotesProvider
Из logcat мы видим, что диспетчер активности - jakhar.aseem.diva / .AccessControl3Activity
AndroidManifest.xml показывает поставщика содержимого jakhar.aseem.diva.provider.notesprovider; android: enabled = «true» и android: exported = «true», что означает, что компоненты других приложений могут иметь к нему доступ.
А исходники NotesProvider.java показывают, где хранятся заметки.
CONTENT_URI = Uri.parse(“content://jakhar.aseem.diva.provider.notesprovider/notes”);
Выполнение следующей команды предоставляет доступ к содержимому заметок без пин-кода.
Код:
./adb shell content query --uri content://jakhar.aseem.diva.provider.notesprovider/notes
Хардкодинг, часть вторая
Вместо использования jadx-gui, на этот раз я задумался о том, чтобы перейти к более серьезные инструментам для реверс-инжиниринга. Это нужно для того, чтобы изучить файл библиотеки (.so), который не поддерживается jadx-gui.
[automerge]1619000923[/automerge]
Здесь есть два способа: использовать гидру (читайте Для просмотра ссылки Войди
Использование apktool
Извлеките содержимое diva-beta.apk, выполнив команду:
Код:
apktool d diva-beta.apk
Теперь, просматривая libdivajni.so, обращайте внимание на любые подозрительные строки и вводите их в поле ввода имени пользователя.
Код:
strings arm64-v8a/libdivajni.so
оригинал на английском можно Для просмотра ссылки Войди
