Приветствую, коллеги!
В данной статье мы рассмотрим различные методы по раскрытию технической информации об уязвимом сервере на этапе сбора информации. Все кейсы будут разобраны на примере заданий PortSwigger.
Приступим к разбору!
Раскрытие информации в сообщениях об ошибках
Допустим, в испытываемом web-приложении есть возможность просматривать страницы товаров. В URL присутствует параметр productId. Потыкав страницы, видим, что этот параметр принимает числовые значения чтобы отдать страницу с товаром клиенту. Если введём несуществующую страницу, то получим ошибку 403.
Но а что, если ввести не числовое значение, а буквенное?
Сервер выплюнул много чувствительных данных с версией Apache Struts.
Чувствительные данные — это категория информации, которая требует специальных мер защиты в силу своих характеристик, поскольку ее компрометация может нанести существенный ущерб.
Часто так бывает, что софт при какой-то ошибке при обработке запроса выдаёт свою версию, ссылки на документацию с решением вопроса и т. д.
Раскрытие информации на странице отладки
Просматривать код страницы — хорошая привычка. Иногда она может нас привести к ненайденным директориям или панелям управления без авторизации, что крайне редко, но бывает. В нашем случае это приводит к служебной информации сайта:
phpinfo() — это встроенная функция PHP, которая генерирует HTML-страницу с полной информацией о конфигурации и настройках сервера PHP.
Тут же лежит ключ для завершения задания:
Сдаем флаг:
Раскрытие исходного кода с помощью файлов резервных копий
robots.txt — это простой текстовый файл, который находится на веб-сайте и содержит инструкции для поисковых роботов (краулеров) о том, какие разделы или файлы сайта им не следует сканировать и индексировать. Проще говоря, этот документ указывает доступ для браузера на разделы сайта.
Вот как раз всё что находится под отметкой Disallow нас как пентестеров должно очень интересовать.
Вот так мы нашли директорию с бэкапом.
При просмотре .bak-файла найдём там ключ для завершения задания:
Также сдаём ключ:
Обход аутентификации посредством раскрытия информации
Бывают случаи, когда администраторы делают доступ к панелям управления доступ только ограниченному количеству IP-адресов.
Обратите внимание, что при входе сервер возвращает ответ с заголовком X-Custom-IP-Authorization, где указывается ваш внешний IP-адрес, который, судя по всему, зафаерволлен.
Мы можем этот кастомный заголовок (кастомный т. к. он начинается на X- и его создал разработчик сайта) указать сами.
Меняем адрес на 127.0.0.1, что делает наш запрос якобы от лица самого сервера у которого точно есть права для входа в админскую панель.
Теперь можем завершить и эту таску, удалив пользователя carlos.
Раскрытие информации в истории контроля версий
Бывает и такое, что на хостах можно найти .git и скачать себе на хост для изучения. Так и произошло в следующем примере:
При помощи git-dumper забираем директорию (можно и при помощи wget).
При помощи команды git log смотрим какие изменения были в коде:
Команда git diff показывает, что было изменено в прошлой версии кода, и подсвечивает это красным. Так мы находим креды от админа:
Логинимся и завершаем задание:
Ещё полезные команды для изучения .git:
git log -S "secret" --oneline - Поиск по всей истории коммитов ключевой фразы
git show <commit_hash> - Просмотр конкретного коммита
git diff <commit1> <commit2> - Показать изменения между коммитами
git blame config.php - Показать кто менял конкретный файл
Выводы
Хотя последствия могут быть очень серьёзными, раскрытие информации само по себе является проблемой высокой степени серьёзности только при определённых обстоятельствах. Во время тестирования раскрытие технической информации представляет интерес только в том случае, если вы можете продемонстрировать, как злоумышленник может использовать её во вред.
Например, знание о том, что веб-сайт использует определённую версию фреймворка, бесполезно, если эта версия полностью обновлена. Однако эта информация становится важной, если веб-сайт использует старую версию, содержащую известную уязвимость. В этом случае для проведения разрушительной атаки может быть достаточно применения общедоступного эксплойта.
Полностью предотвратить утечку информации сложно из-за огромного количества способов, которыми она может быть раскрыта. Однако есть несколько общих рекомендаций, которые помогут вам свести к минимуму риск появления подобных уязвимостей на ваших сайтах.
- Убедитесь, что все, кто участвует в создании веб-сайта, полностью осведомлены о том, какая информация считается конфиденциальной. Иногда, казалось бы, безобидная информация может оказаться гораздо более полезной для злоумышленника, чем думают люди. Выявление таких опасностей поможет обеспечить более надёжную защиту конфиденциальной информации в вашей организации.
- Проверяйте любой код на предмет возможного раскрытия информации в рамках процессов контроля качества или сборки. Некоторые сопутствующие задачи, например удаление комментариев разработчика, можно относительно легко автоматизировать.
- По возможности используйте общие сообщения об ошибках. Не давайте злоумышленникам лишних подсказок о поведении приложения.
- Убедитесь, что в рабочей среде отключены все функции отладки и диагностики.
- Убедитесь, что вы полностью понимаете настройки конфигурации и последствия для безопасности, связанные с использованием любой сторонней технологии. Уделите время изучению и отключению всех функций и настроек, которые вам на самом деле не нужны.