Приветствую!
В данной статье разберём очень классный кейс с SQLi, CSRF и уязвимостью, связанной с подменой cookie. Пытался раскрутить RCE, но не за что было зацепиться для записи какого-то публичного файла и внедрения вредоносного кода. Приступим!
Сбор информации
Для начала посмотрим какие порты открыты на хосте:
Не густо! Открыт только 80-й порт с Apache версии 2.4.46. Забегая наперёд скажу, что эксплойтов на эту персию Apаche нет. DoS мы не считаем т.к. это уже вредительство, а не пентест.
Воспользуемся тузлой nikto для поиска возможных векторов:
Какие выводы мы можем сделать:
- Отсутствует заголовок X-Frame-Options
Это позволяет другим сайтам внедрять этот сайт через <iframe>, что может привести к clickjacking-атакам. - Отсутствует заголовок X-Content-Type-Options
Без этого заголовка браузеры могут интерпретировать файлы иначе, чем указано в Content-Type, что может быть использовано в MIME-sniffing атаках. - Устаревшая версия Apache
Используется версия Apache 2.4.46, хотя текущая — минимум 2.4.54. Устаревшие версии могут содержать неисправленные уязвимости. - ETag утечка информации
Заголовок ETag включает значения inode/mtime, что потенциально позволяет идентифицировать файлы и проводить атаки по кэшу. - Разрешённые HTTP-методы: GET, POST, OPTIONS, HEAD
Наличие метода OPTIONS — не критично, но иногда используется для разведки.
Хоть нас и не просили, но заглянем в robots.txt
Ладно, тогда профаззим директории:
dirsearch -u http://192.168.0.103
Ничего особенного...
Находим код java одного из фреймворков, но это нам ничего особенного не даст.
Заёдём всё же на 80-й порт:
Заглянем на найденную директорию:
Чёрт! Да что мы упускаем? Иду во банк и бручу директории по крупному:
dirsearch -u http://192.168.0.103 -w /home/b0rn2ber00t/Desktop/directory-list-2.3-big.txt
Вы не поверите, но найти совсем ничего не удавалось. Оказалось, что директория не брутится т.к. такой вообще нет ни в какой словаре. Подсмотрел у других и понял, что кейс становиться интересным от таких финтов ушами.
Эксплуатация уязвимостей
CSRF
CSRF — это атака, при которой злоумышленник заставляет ваш браузер выполнить действие на другом сайте от вашего имени, пока вы на нём залогинены.
Простой пример CSRF:
Представь, ты — админ сайта example.com, и ты вошёл в админку. Пока ты залогинен, ты решил открыть сайт с анекдотами — badguy.com. А там в коде незаметно спрятано: <img src="https://example.com/delete_user?id=42">
Браузер думает: «О, запрос на example.com, да ты же там авторизован! Держи куки, держи сессию!» И выполняет запрос от твоего имени, хотя ты ничего не нажимал.
В результате: ты сам, не зная, удалил пользователя №42 с сайта, потому что кто-то подсунул тебе скрытую команду.
Вернёмся к нашему кейсу!
Хочу сразу заметить, что в данной тачке это не совсем CSRF-атака всё же. После разбора кейса, я это поясню.
При отправке reverse-shell или любого другого файла возникнет проблема с подключением.
Попробуем выяснить в чём может быть проблема, просмотрев исходный код:
Видим что в форме action лежит адрес localhost. То есть форма нацелена на клиента, что не эффективно для нас. Попробуем изменить адрес HTML-формы с localhost на адрес хоста и посмотрим что выйдет:
Можем поменять прям в инструменте разработчиков. После чего жмём Submit Query.
Мы получили первую часть флага!
Почему это не полноценный CSRF?
CSRF-атака происходит автоматически, потому что пользователь сам инициирует отправку формы. В реальной атаке злоумышленник размещает такую форму на своём сайте, и при переходе жертвы туда она автоматически отправляется через JavaScript.
В данной кейсе мы сами видоизменили форму HTML и инициировали запрос на хосте. Изначально форма нацелена на выполнение запроса на стороне клиента, но мы можем заставить сервер выполнить действия от своего лица.
SQLi
SQLi (SQL-инъекция) — это тип уязвимости в веб-приложениях, при котором злоумышленник может вставить вредоносный SQL-код в запрос к базе данных.
Очередной раз заходим на директорию, которую нельзя найти. Нам предоставляют форму авторизации:
По классике жанра попробуем найти SQLi в данной форме. Сохраняем запрос:
Запускаем sqlmap и ищем инъекцию:
sqlmap -r req.txt --risk=3 --level=5 --batch --dump
Форма всё же уязвима к Time-based blind инъекции.
Посмотрим что тут есть за БД:
sqlmap -r req.txt --dbs --batch
Вытащим таблицы с БД "Machine"
sqlmap -r req.txt -D Machine --tables --batch
Дампим найденную таблицу login:
sqlmap -r req.txt -D Machine -T login --dump --batch
Вторая часть флага теперь у нас!
Попытка накрутить RCE
Информацию с базы данных мы уже выкачали, но хочется получить доступ к самому серверу. Для этого попробуем реализовать RCE.
RCE (Remote Code Execution) — это уязвимость, которая позволяет злоумышленнику выполнить любой код на удалённом сервере или компьютере.
Для начала посмотрим под каким пользователем выполняются команды в БД:
sqlmap -r req.txt --current-user --batch
Отлично! Мы root! На всякий посмотрим привилегии. Понятно, что все они будут, но админ мог быть хитрым и позакрывать какие-то важные.
sqlmap -r req.txt --privileges --batch
На перезапись права есть! В таком случае реализуем RCE, перезаписав какой-то файл.
sqlmap -r req.txt --os-shell
Попробуем найти какой-то стандартный файл, который можно использовать для перезаписи:
Проблема этого кейса в том, что у нас ничего нет из доступных файлов для перезаписи. Оставим попытки докрутить RCE...
Cookie
При запросе директории /enter_network/ в Burp Suite видим ответ с Set-Cookie.
Я человек простой - если сервер просит установить cookie, я так и делаю :)
Однако перед этим всё же проверю какие конечные точки есть у директории:
Парочку нашлось! К admin.php у нас нет доступа. Исследуем структуру Cookie:
Видим, что Burp декодирует куку в параметре role с base64 в какой-то хеш. Закинем его на CrackStation и посмотрим, что выйдет.
Интересно! Мы уже присвоили себе роль админа, но на admin.php нас не пускает.
Кстати, алгоритм хеширования Argon2, который используется в таске, является очень надёжным, но в кейсе по части безопасности он не помог :)
Знаете что я сильно люблю в пентесте? А вот такие моменты, когда вы вот так на шару получаете доступ к конф. инфе.
Вместо этой ерунды пишу роль admin и прохожу на админ. панель.
Результат:
Ещё один способ получить вторую часть флага :)
Кстати, если посмотрите Cookie пользователя, то можно увидеть креды авторизации:
Мы, конечно не авторизированный пользак, но походу это условность таска.
Выводы
Кейс вышел очень интересным, но хочется отметить часть с фаззингом директорий. Упущенное время уже не вернуть...
От такого правда никто не застрахован на реальных тестированиях. Хорошая защита от разведки на начальных этапах - назвать директории нестандартно.
Здорово, когда кейсы вмещают в себя много различных векторов атаки! Мы тут покрутили SQLi, пытались RCE доделать, реализовали кастрированный CSRF и ещё с куками победокорили. Последнее было совсем весело найти :)
Спасибо за внимание! С вас лайк! А вы как думали? :) Автор балдеет от такой прикормки))
Всех вам благ, друзья!