Ищем уязвимости на сайте министерства обороны США

Ищем уязвимости на сайте министерства обороны США, используя веб-приложение Jira и ряд других инструментов для анализа уровня безопасности.

Во время сбора информации о военных сайтах в рамках Bug Bounty Department of Defense’s (дальше DoD) одним из специалистов было отмечено, что на нескольких из них используется популярное веб-приложение Jira, отслеживающее проблемы программного обеспечения. Позже внимание привлек твит, в котором активно обсуждали эксплуатацию SSRF в Jira. На базе полученных сведений ищем уязвимости и рассказываем, чем именно они опасны.

Исследование первого веб-сайта началось с посещения google.com с помощью переменной consumerUri.

Благодаря информации из блога Бретта Буэрхауса стало понятно, что любой экземпляр AWS может запрашивать IP и получать информацию, относящуюся к этому AWS, включая информацию об учетной записи, потому сперва было бы уместным проверить имя локального хоста через конечную точку метаданных AWS.

При попытке получить учётные данные для их AWS было обнаружено, что на выполнение такой операции недостаточно прав. В этом случае лучшим решением стало прочтение AWS-документации и попытки запросить другие конфиденциальные данные, которые можно было бы извлечь.

Нарушать правила DoD Bug Bounty не планировалось: «Ищем уязвимости, чтобы их устранить» — таков мотив. Именно поэтому были немедленно прекращены все тесты и отправлен первый репорт о найденных «брешах» в безопасности. Вскоре после этого репорт приняли. Специалист сообщил участнику команды на hackerone о намерении эксплуатировать уязвимость, чтобы доказать максимальную угрозу для безопасности. После краткой оценки репорта уязвимости присвоили среднюю степень угрозы для безопасности. С разрешения разработчиков и началась работа над максимальной эксплуатацией данного бага.

Сперва были просканированы порты, чтобы узнать, есть ли какие-либо протоколы, которые можно вызвать. Протестированными оказались следующие порты:

• 21, (FTP)
• 22, (SSH)
• 80, (Web)
• 443, (SSL Web)
• 8080, (прокси)

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

Эта информация также была добавлена в отчетность для hackerone.

Анализируя выявленные уязвимости, нельзя было не вспомнить о презентации исследователя Джеймса Кетли Cracking the Lens: Targeting HTTP’s Hidden Attack-Surface, в которой шла речь о возможности получить доступ к интрасети DoD и скрытым внутренним службам, доступным только для внутренних IP или из сервиса DoD. В видеопрезентации речь идет о двух таких веб-сайтах, доступ к которым может быть получен, если IP-адрес злоумышленника поступает с DoD сайта.

Проверка обоих веб-сайтов DoD была продолжена, чтобы убедиться, можно ли получить хоть какой-то результат. При запросе URL из упомянутой Кетли статьи на первом испытуемом сайте отобразилось предупреждение USG, в то время как другой веб-сайт не отвечал на этот запрос вообще. В ходе данного теста также обнаружились и другие сервисы интрасети. Благодаря этому и стало возможным получить доступ к NIPRnet — не классифицированной внутренней сети протоколов, которая используется для обработки конфиденциальной информации. Она оказалась слишком чувствительной для работы с Интернета, но все же подтверждение того, что к ней можно получить доступ, уже имелось.

Раскрыть внутренние службы и сайты не представляется возможным, так как они являются полностью конфиденциальными.

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

Тем не менее, после тестирования было обнаружено, что можно узнать о существовании определенных портов внутри локальной сети в зависимости от времени отклика (Blind SSRF). Например: время ответа 22 порта составило 1000 мс, тогда как запрос на 21 порт откликался за 10 000 мс. Кроме того, было непонятно, какие протоколы поддерживаются из-за отсутствия подробных ошибок.

В итоге, сосредоточившись на ключевой цели, пришлось обратиться к NIPRnet. Был задействован Burp Сollaborator (это сервер postswigger), чтобы узнать, какая информация пришла на контролируемый сервер.

Исходя из того, какие http-заголовки были в запросах, было отмечено, что они пропускали конфиденциальную информацию, включая заголовок «X-Forwarded-For», который сливался во внутренний IP-адрес.

Закончив запрашивать все IP адреса, которые взаимодействовали со ссылкой на сервер Burp Collaborator, важно было проверить, произошли ли хоть малейшие изменения. Однако ничего не произошло. В этот момент также было обнаружено, что прочитать метаданные AWS не оказалось возможным, хотя запрос IP-адреса и серверов DoD-сети выполнился, как и на первом веб-сайте.

Все же, специалист поспешил сообщить команде hackerone о своих находках, после чего Impact обоих отчетов увеличился до отметки «критично». Позже, пересматривая обе SSRF-уязвимости с низким Impact, обнаруженные ранее и зарепорченные не так давно, было принято решение привлечь внимание и к ним в надежде на увеличение оценки угрозы для безопасности.

Эти две уязвимости заставляют использовать фильтр веб-приложений, злоупотребляя HTTP-подключением для запроса определенных IP-адресов. Запрос был довольно простым: нужно всего лишь отправить CONNECT IP, после чего можно перечислять службы DoD с помощью этого метода. Также оказалось возможным злоупотреблять заголовком хоста для выполнения запроса на аутентификацию для внутреннего IP или внешнего IP, например: militarywebsite.mil@internal_IP. Вернувшись к старым SSRF, было обнаружено, что можно выполнить Blind SSRF, запрашивая внутренние IP-адреса или службы, в результате чего страница сообщала, что истекло время ожидания, произошла ошибка SSL и др. После просьбы о пересмотре репорта уровень Impact был повышен до среднего.

Лайфхаки для эксплуатации SSRF

Во время исследований вышеперечисленных эксплойтов, специалист обнаружил, что в некоторых случаях эксплуатации возникает ошибка стека и утечка различной конфиденциальной информации. Причину, по которой это происходит, в конечном итоге так и не удалось найти. Обычно увидеть утечку информации можно, используя неполный HTTP-заголовок, например http:// или http://[::]. Конфиденциальная информация включает в себя IP-адрес базы данных, версию базы данных, используемые плагины, ОС, архитектуру ОС, etc.

Также иногда на веб-сайте есть ссылки на другие экземпляры Altassian. Это открылось во время тестирования одного известного ресурса. Там был установлен Altassian на другом поддомене (из меню), на котором перечислены прочие сайты с Altassian, где присутствует данная уязвимость.

Заключение

Две устаревших версии Jira были уязвимы для вышеупомянутых эксплойтов SSRF. Они нужны для того, чтобы предоставлять доступ ко внутренним службам и сетям DoD.

Было также обнаружено, что другой эксплуатируемый сайт позволял злоумышленнику просматривать конфиденциальный контент метаданных на сервисах AWS, содержащих идентификатор учетной записи, частный IP-адрес и другую конфиденциальную информацию, связанную с сервером и учетной записью.

Злоумышленник мог использовать эти уязвимые веб-сайты для доступа ко внутренним AWS Министерства обороны. Хакер также мог использовать ресурсы для доступа к внутренней локальной сети Министерства обороны США. Это вполне могло бы привести к компрометации конфиденциальных данных и возможному сбою критически важных сервисов.

Bug Bounty Министерства обороны имеет большой scope, в котором можно искать уязвимости. К тому же, они готовы работать с исследователями безопасности. В этой статье опубликованы наиболее распространенные проблемы и уникальные уязвимости, найденные в DoD.

И помните: ищем уязвимости, чтобы устранять их, а не использовать в своих целях. Если вы хотите построить карьеру в области информационной безопасности, следуйте этому правилу.