Инструкция по использованию 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

Продолжение:


Рекомендуется Вам:

3 комментария to Инструкция по использованию sqlmap. Ч.2: Продвинутое сканирование и эксплуатация (POST, после аутентификации, AJAX/jQuery)

  1. Евгений:

    У меня в Burp нет такого "Теперь спуститесь в самый низ, найдите Allow requests to web interface using fully-qualifyed DNS hostnames и поставьте там галочку. "

    Версия 1.7.27. Как быть?(

    • Alexey:

      Убрали (или переместили) в последних версиях эту опцию - без неё также работает.

  2. russia_the_best:

    Спасибо за статью. Однако автор забыл указать, что целевой сайт пишется в кавычках после тега -u

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *