Пентестинг Android: Анализ проблем с проверкой ввода DIVA для Parrot OS

Прошел еще один день, и настало время для очередного отчета по пен-тесту Android. Сегодня мы рассмотрим четвертый раздел APK DIVA, Проблемы с проверкой ввода. Когда у нас есть приложение, которое не проверяет ввод должным образом, это облегчает злоумышленникам задачу по созданию ввода, который не ожидается остальной частью приложения. Это приводит к тяжелым последствиям, начиная от изменения данных, выполнения произвольного кода и заканчивая несанкционированным доступом к данным. Нехорошо!

Если вы не видели предыдущих статей, не стесняйтесь зайти на мой GitHub и взять все, что захотите. Когда вы будете готовы, наденьте свою любимую толстовку и возьмите ближайший напиток, и давайте начнем HACKING! 👾

Проблемы валидации ввода — часть первая

Когда мы открываем раздел Input Validation Issues — Part 1 на нашем устройстве, перед нами встает следующая задача: попытаться получить доступ ко всем данным пользователя, не зная ни одного имени пользователя. По умолчанию есть три пользователя, и ваша задача — вывести данные всех трех пользователей с помощью одного вредоносного поиска.

Давайте обратим внимание на ключ к этой задаче: вредоносный поиск. Мы также видим небольшую подсказку, которая говорит нам, что в базе данных есть три пользователя, один из которых — администратор.

Поскольку мы работаем с базой данных, нам, скорее всего, придется создать SQL Injection, но прежде чем мы перейдем к этому, давайте посмотрим, что произойдет, если мы введем любое имя пользователя (не зная истинных значений).

Когда мы вводим случайное/предполагаемое значение, мы видим, что ни один пользователь не возвращается. Однако, когда мы вводим admin, мы видим, что возвращаются данные пользователя admin! 👀

Теперь, когда мы знаем, что admin определенно является пользователем, мы можем использовать это для создания нашей команды SQL Injection. Но прежде чем мы это сделаем, я хочу немного схитрить и порыться в файлах нашей базы данных, чтобы посмотреть, можем ли мы увидеть трех пользователей, которых нам нужно вернуть с помощью нашей команды.

Если вы хотите сделать это, откройте терминал с помощью CTRL + ALT + T и введите следующие команды:

adb shell
su
cd data/data/jakhar.aseem.diva/databases

> qlite3 (To enter this option start typing sql, press TAB + Enter)
> .open sqli
> .tables
> .table sqliuser
> .dump sqliuser
Войти в полноэкранный режим Выйти из полноэкранного режима

Мы видим, что нам нужно создать команду для возврата пользователей admin, diva и john. Возвращайтесь в свое приложение, потому что сейчас мы напишем самую гениальную, оригинальную, самую хакерскую команду SQL Injection!

''admin' OR 1=1;--
Вход в полноэкранный режим Выход из полноэкранного режима

DUHN DUHN DUUUUUUUHN, мы успешно сбросили их таблицу базы данных! Разве это не весело? 😀

Проблемы валидации ввода — часть вторая

Когда мы открываем раздел Input Validation Issues — Part 2 на нашем устройстве, перед нами встает следующая задача: попробуйте получить доступ к любой конфиденциальной информации, кроме URL-адреса веб-сайта.

Давайте обратим внимание на важную часть этой задачи, которая заключается в том, чтобы НЕ получить доступ к информации с веб-адреса — так что не пытайтесь взломать Google или ваш любимый сайт! Нам нужно получить доступ к локальным данным. 😂

Теперь, прежде чем мы продолжим, я должен кое в чем признаться. Я допустил оплошность и был вынужден начисто установить все свои инструменты. Это означает, что все те файлы tmp и shared_prefs, которые мы создали в предыдущих статьях, исчезли. Не волнуйтесь, потому что я собираюсь обойти это. 🤠

Давайте зайдем в наш APK и посмотрим, какие конфиденциальные данные мы можем использовать. Если вы не я, и у вас все еще есть ваш файл tmp, вы можете легко использовать этот файл. Вместо этого я создам «секретный» файл, который будет содержать некоторые пользовательские данные. Затем мы будем использовать этот файл, чтобы проверить, можем ли мы получить к нему доступ в приложении. Откройте терминал и сделайте следующее:

adb shell
su
cd data/data/jakhar.aseem.diva/
echo "password:123; username:alex" > private.txt
cat private.txt
Войдите в полноэкранный режим Выйти из полноэкранного режима

Теперь, когда наш файл создан, а конфиденциальные данные хранятся локально на нашем устройстве, мы можем вернуться в наше приложение и попытаться получить доступ к файлу private.txt через ввод. Давайте перейдем к этому файлу через:

file:///data/data/jakhar.aseem.diva/private.txt
Войти в полноэкранный режим Выйти из полноэкранного режима

Когда мы нажмем кнопку просмотра, мы увидим, что наши данные открыты! 🙃

Вот мы и закончили со второй частью. Давайте продолжим.

Проблемы валидации ввода — часть третья

Когда мы открываем раздел Input Validation Issues — Part 1 на нашем устройстве, перед нами встает следующая задача: …DOS the damn thing! Не ищите код, просто уничтожьте приложение (а затем найдите первопричину сбоя).

Прежде всего, давайте разберемся, что такое DOS-атака. Атака на отказ в обслуживании (Denial-of-Service, DOS) — это атака, целью которой является выключение системы, что, в свою очередь, делает ее недоступной или медленной. Мы осуществляем DOS-атаки, заваливая цель трафиком или большими объемами информации, что приводит к сбою системы.

Теперь мы можем действовать по-разному, но для данного обзора мы сделаем это самым простым способом: введем большое количество данных на вход и нажмем красную кнопку!

Чтобы заставить приложение аварийно завершить работу, я просто нажимал на клавиатуре 0 до тех пор, пока ввод не перестал принимать длину строки, и вуаля, все заработало!


Итак, мы успешно выполнили первую часть задачи, которая заключалась в том, чтобы вывести приложение из строя с помощью DOS-атаки. Давайте зайдем в Android Studio, или, как вариант, вы можете использовать команду adb logcat в терминале (но мне нравятся красивые цвета AS 😆), чтобы посмотреть, что мы получили в журнале.

Здесь много всего происходит, и легко запутаться, но давайте сосредоточимся на коде ошибки SIGSEGV. Я выделил код SIGSEGV, потому что он очень важен, так как указывает на ошибку сегментации в контейнерах Linux. Проще говоря, мы получаем этот код, когда наше приложение пытается читать/писать за пределами выделенной для него памяти или при записи памяти, которую можно только читать.

Давайте откроем наш JDX-GUI (jadx-gui) и посмотрим, что говорит наш исходный код. Когда мы открываем нашу InputValidation3Activity, мы узнаем класс (Divajni), который мы должны были использовать в прошлом в наших проблемах с жестким кодированием при записи. Мы видим, что он использует это значение, чтобы инициировать нашу последовательность запуска.

Давайте откроем Divajni. Нас снова встречает soName, которое, как мы знаем, имеет отношение к нашему файлу libdivajni.so.

Хорошо, теперь мы можем открыть терминал и посмотреть, сможем ли мы найти в файле libdivajni.so что-то странное — или связанное с нашим кодом ошибки. Нам не придется далеко листать, прежде чем мы определим виновника: strcpy.

Хотя мы не можем получить к нему доступ, чтобы увидеть, как он используется, strcpy является распространенным виновником ошибок сегментации. Это происходит потому, что код strcpy() подходит для обработки небольших входных данных, но не для больших, таких как входные данные, которые мы использовали для нашей DOS-атаки.


Поздравляем, вы успешно выполнили все три части задания по проверке входных данных DIVA! 🥳

Надеюсь, это было достаточно просто для понимания. Увидимся в следующий раз на нашем последнем разделе (раздел 4): Вопросы контроля доступа. Если у вас есть рекомендации по каким-либо классным инструментам, техникам или учебникам, которые я тоже могу использовать, не стесняйтесь, оставьте их ниже, и я посмотрю! 😊

(Запишите это на мой GitHub для дальнейшего использования)

Оцените статью
Procodings.ru
Добавить комментарий