Атака на некоторые уязвимые веб-приложения Vulnhub. Взлом и эксплуатация уязвимостей
Всех приветствую читатели (и не только читали) хабра!
В моей сегодняшней статье я затрону анализ защищенности веб-приложений и некоторые способы атаки на них
Но для начала уточню пару моментов
Я публикую только те примеры, которые я сам лично пробовал на практике, примеры с которыми не должно возникнуть сложностей, которые хороши также для освоения или закрепления новых навыков. Огромная просьба не писать гневных коментариев или переходить на личности, а писать только по существу, например предложить другие методы решения
Правовая информация:
Данная статья создана исключительно в ознакомительных/образовательных/развивающих целях.
Автор статьи не несет ответственности за ваши действия.
Автор статьи ни к чему не призывает, более того напоминаю о существовании некоторых статей в уголовном кодексе РФ, их никто не отменял:
УК РФ Статья 272. Неправомерный доступ к компьютерной информации
УК РФ Статья 273. Создание, использование и распространение вредоносных компьютерных программ
УК РФ Статья 274. Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей
Итак приступим
В своих примерах я буду использовать уязвимые веб-приложения на докер-контейнерах
Для начала необходимо установить сам докер. В линукс это можно введя в терминал команды:
sudo apt update; sudo apt install docker-compose
Докер — также является средой виртуализации, отличие его от например virtualbox лишь в том, что бокс поднимает полноценную операционную систему, докер же поднимает все програмное обеспечение (обычно это серверные программы) на сетевом интерфейсе
Теперь об уязвимых машинах
Скачать их можно здесь:
https://github.com/vulhub/vulhub
Это целый архив уязвимых машин для докер, я разберу лишь наиболее успешные примеры которые были выполнены мной (хотя примеры которые я затрону в статье не единственные, я смог проэксплуатировать уязвимости и в других машинах). Хочу сказать сразу, что для каждой уязвимой машины в папке (а они лежат в отдельных папках) лежат очень краткие инструкции взлома, файлы под названиями README.md. Правда зачастую эит инструкции настолько краткие и невнятные, что приходится сидеть иногда очень долго чтобы разобрать их. К тому же все инструкции написаны на анлийском (что естественно), а некоторые вообще на китайских иероглифах. Короче говоря очень непросто зачастую ими пользоваться.
Суть всех примеров (а их будет три в данной статье) сводится к следующему алгоритму:
Запуск виртуальной машнины (уязвимого веб-приложения) в сетевом интерфейсе
Поиск ip-адреса локального хоста, бриджа (бридж-сетевой мост, некоторые машины в примерах ниже будут на бриджах) в сетевом интерфейсе. Сканирование цели
Энумерация. Перечисление всех файлов и папок на уязвимой машине, проще говоря перечесление всех возможных адресов. Данный пункт в приведенных примерах будет не везде, поэтому следующий
Эксплуатация уязвимости. Либо ее обнаружение без эксплуатации. Тут примеров и техник как и программ масса
Правда есть конечно же последующие шаги в пентесте, такие как закрепление вовзломанной системе, проброс сетевого трафика (использование взломанного хоста или узла как своего прокси сервера) и так далее. Но в данных примерах это неактуально так как это уязвимые веб-приложения и их цель научить на практике находить уязвимость именно в вебприложении.
Теперь перейдем к практике
1 Первая машина назывется bash
Уязвимость CVE-2014–6271
Поясню: CVE (англ. Common Vulnerabilities and Exposures) — база данных общеизвестных уязвимостей информационной безопасности (https://ru.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures)
На сайте https://www.exploit-db.com/ как раз представлены различные уязвимости и эксплойты.
Вернемся к примеру. Заходим в папку где лежит докер контейнер (там находится файл docker-compose.yml), открываем в папке терминал, и собираем и запускаем уязвимую машину на докере командами:
sudo docker-compose build
sudo docker-compose up -d
Следующим делом проверяем что запущенно на интерфейсе командой
ifconfig
Важно проверить все мосты и локалхост (127.0.0.1). В моем примере данная машина поднялась на сетевом мосту (далее бридж). Иногда машина поднимается на localhost — 127.0.0.1, но у меня произошла какая то ошибка при запуске машин которые я поднимал до этого и виртуальные машины стали подниматься на бриджах, хотя это мне и не помешало
Далее сканируем ip
nmap 172.24.0.1
Видим отфильтрованный порт 8080. Заходим в браузер по адресу 172.24.0.1:8080 (http://172.24.0.1:8080). Меня встретил интерфейс апаче на дебиан
После чего в данном примере я решил провести энумерацию по данному адресу. Хоть она не дала особых результатов, но для практики использования инструментов анализа веб-приложений я решил порактиковать (так сказать «набить руку»). Энумерация это процесс перечисления папок и файлов на адресе. В Kali Linux имеются инструменты энумерации такие как dirb, dirbuster и другие. Но я предпочитаю использовать инструмент dirsearch. В Kali Linux данный инструмент устанавливается командой
sudo apt install dirsearch
Преступим к энумерации
dirsearch -u http://172.24.0.1:8080
Кстати говоря для энумерации хорошо подходит инстурмент zaproxy. Это аналог burp suite только с открытым исходным кодом. Чем хорош данный инструмент — он прост в использовании, достаточно только открыть программу зайти в «быструю атаку» ввести адрес домена и нажать «attack» как программа прошерстит практически весь адрес и создаст древо каталогов и файлов на машине. Запросто найдет куки администратора на машине, если таковые имеются. На одном изтасков CTF было именнотакое задание. Zaproxy мне помог решить задание указав на куки админа которая являлась строкой зашифрованной в base64 (которая и была флагом ответом к таску). Кроме того, программа автоматически ищет уязвимости и имеет множество встроенных модулей и векторов атаки. Но в русскоязычном сегменте интернета я нашел очень мало информации оданной программе. Установить ее в дебиан-подобные дистрибутивы так же легко:
sudo apt install zaproxy
Атакуем http://172.24.0.1:8080
Как я и говорил особого результата энумерация не дала. В первом случае с программой dirsearch 403, во втором случае нужных мне вайлов не получилось найти.
Далее я зашел в инструкцию уязвимой машины. Но домене есть два файла интересующие меня safe.cgi, victim.cgi. Проверяем при помощи curl
curl http://172.24.0.1:8080/safe.cgi
curl http://172.24.0.1:8080/victim.cgi
Видно что ответ сервера 200, а не 403, 404. Следовательно такие файлы есть и данный адрес существует. А далее идет процесс эксплуатации уязвимости. Эксплуатировать уязвимость можно при помощи инстумента burp suite
Запустим программу, перейдем во вкладку прокси, включим перехват пакетов intercept on и откроем браузер
В браузере введем адрес http://172.24.0.1:8080/safe.cgi нажмем enter
После чего возвращаемся в burp нажмем правой кнопкой мыши по перехваченному пакету и нажимаем скинуть в репитер (send to repeater)
В репитере пробуем сменить юзер агент (user agent). В данном примере уязвимость эксплуатируется именно таким образом. Пробуем сменить юзер агент со значений версии браузера и ОС на команду, которая должна выполниться на уязимой машине:
() { foo; }; echo Content-Type: text/plain; echo; /usr/bin/id
Нажимаем скинуть send
Для файла http://172.24.0.1:8080/safe.cgi изменений не наблюдается. Проделаем все тоже самое, но с http://172.24.0.1:8080/victim.cgi
Также в юзер агент вписываем () { foo; }; echo Content-Type: text/plain; echo; /usr/bin/id
Отправляем
И видим ответ сервера
Сервер вернул идентификаторы пользователей и групп. Таким образом я записал код в уязвимом юзер-агенте вернул запрос серверу и на сервере запустил свой код, после чего сервер выдал ответ
Это уязвимость типа «шеллшок» shellshock — позволяет выполнить на серевере некоторые команды злоумышленника.
2 Вторая машина openssl
Openssl — это библиотека которая позволяет безопасно соединятся серверу — клиенту через шифрование.
В предидущей папке (bash) остановим прежнюю виртуальную машину командой
sudo docker-compose down
И так необходимо делать с каждой машиной. Далее переходим в папку openssl и выполняем все те же действия в терминале:
sudo docker-compose build
sudo docker-compose up -d
В этом примере машина поднялась не на бридже, а на локальном хосте 127.0.0.1 сканируем его
nmap 127.0.0.1
Видим два открытых порта, заходим в браузер по адресу 127.0.0.1:8080 и 127.0.0.1:8443
В папке где находится машина, есть скрипт на питоне ssltest.py. Запустим его
python3 ssltest.py -h
Запустим скрипт, но запустим эксплоит на оба открытых порта сервера, которые указад нам nmap
python3 ssltest.py 127.0.0.1 -p 8443
python3 ssltest.py 127.0.0.1 -p 8080
Очевидно что с порта 8443 прилетел «хекс». И надпись выделенная на рисунке
говорит сама за себя
Попробуем то же самое с гуглом google.com:
python3 ssltest.py google.com -p 80
python3 ssltest.py google.com -p 443
Как видно из вывода сервер защищен от уязвимости. Но в моем примере уязвимость обнаружена.
3 Третья папка и уязвимость rsync
Выполняем все те же действия — роняем предидущую машину, заходим в папку с новой, поднимаем все теми же командами sudo docker-compose build; sudo docker-compose up -d
Но эта уязвимость самая интересная из всех трех
В этом примере виртуальная машина поднялась на бридже с ip 172.23.0.1
Сканируем nmap
nmap 172.23.0.1
Видим фильтрованный порт 873/tcp с запущенной службой rsync. Rsync — утилита передачифайлов в linux/Unix-подобных системах
Далее в терминале вводим следующее
rsync rsync://172.23.0.1:873
Сервер вернул директории. Одна из них src
Далее я запросил помощьутилиты — rsync --help
Далее я зашел в директорию выполнив в терминале
rsync rsync://172.23.0.1:873/src
rsync rsync://172.23.0.1:873/src/etc
rsync rsync://172.23.0.1:873/src/etc/passwd
Далее я скопировал файл /etc/passwd уязвимой машины в текущую директорию «родной» ОС Kali Linux командой в файл passwd (в текущей директории).
rsync rsync://172.23.0.1:873/src/etc/passwd -k passwd
Проверил содержимое текущей директории командой ls и убедился что файл скопирован. Вывел содержимое файла
cat passwd
В терминале вывело содержимое файла passwd «родной» машины, который был скопирован с уязвимой машины с помощью rsync. Теперь о том что это за файл. /etc/passwd — файл, содержащий в текстовом формате список пользовательских учётных записей (аккаунтов). Является первым и основным источником информации о правах пользователя операционной системы. Существует в большинстве версий и вариантов UNIX-систем. Обязан присутствовать в POSIX-совместимой операционной системе. (https://wiki.ublinux.ru/ru/Использование/Настройка/Вводная_информация)
Этот файл должен находится под тремя замками за семью печатями.
Но я получил доступ к файлу благодаря уязвимости, эксплуатация прошла успешно. Таким образом, я подробно разобрал эксплуатацию уязвимостей трех машин.
Ну, а на сегодня все! До новых встреч!
