Публикую перевод ресерчей по книге 2021 года от Brandon Wieser
Вся информация предоставлена исключительно в ознакомительных целях. Автор не несет ответственности за любой возможный вред, причиненный с использованием сведений из этой статьи.
Снимок экрана, показывающий результаты поиска GitHub:
Когда запрос возвращается, он нажимает на раздел «Commits». 8 результат сверху имеет заголовок, который бросается в глаза "Предотвращение манипуляций с помощью $_SERVER [‘HTTP_HOST’]".
Открывая коммит, он получает прилив адреналина (настоящий адреналиновый маньяк, прим.ред).
Форма сброса пароля панели управления хостингом была недавно (менее трех месяцев на момент печати статьи) уязвима для уязвимости, связанной с внедрением заголовка хоста (Host Header Injection)!
Что такое Host Header Injection?
Host заголовок (header, хедер) запроса указывает на название хоста и номер порта сервера, с которого отправляется запрос. Эти данные доступны для изменения пользователем и должны рассматриваться как потенциальный вектор атаки.
В случае уязвимости, связанной с Host Header Injection, приложению не удается проверить или обезопасить данные Host хедера, что приводит к дальнейшему использованию его в целях злоумышленника. Во многих случаях, как в примере, который мы рассмотрим дальше, заголовок Host используется в создании ссылки на сброс пароля. В случаях, когда Host изменяется посредством ответа приложения на запрос, может возникнуть ситуация отправки запроса, который вызывает вредоносный ответ = отравление кэша (cache poisoning). Кроме того, с точки зрения тестировщика, стоит протестировать заголовок X-Forwarded-Host , так как некоторые конфигурации сервера будут использовать этот заголовок для перезаписи Host или использовать его аналогично Host заголовку.
При нажатии на вкладку проекта выясняется, что последний релиз не содержит исправления уязвимости. Кроме того, при просмотре главной страницы компании и нажатии кнопки установки приложения выясняем, что версия выпущенного проекта является уязвимой. Кроме того, в настоящее время нет доступных CVE или публичных эксплойтов, в которых упоминается эта уязвимость. Например, exploit-db.com содержит только предыдущие уязвимости, но не упоминает Host Header Injection.
Согласно домашней странице Vestacp (
Юрий покупает дешевый домен vespa.monter и устанавливает последнюю версию ПО с главного веб-сайта проекта (в цифровом океане тысячи таких проектов). После установки он запускает скрипт дефолтной конфигурации и завершает установку. Установка панели VestaCP на VPS:
Как только панель управления установлена и настроена, он начинает использовать уязвимость. Он переходит в веб-браузер на страницу сброса пароля, выполняет сброс пароля с дефолтной учетной записью «admin» и открывает
электронное письмо.
Как показано на скриншоте, ссылка для сброса пароля содержит его доменное имя «vesta.monster», а новый код, указанный в URL-адресе отправляется GET запросом. Хоть это и дополнительная уязвимость, но Юрия (и нас с вами) больше интересует эксплуатация инъекции заголовка хоста.
Он снова переходит на страницу сброса пароля, на этот раз настраивая BurpSuite для перехвата запроса. Поймав запрос, он отправляет запрос во вкладку «Repeater» в котором редактирует значение заголовка хоста
с «vesta.monster» на «attacker.com» и повторяет запрос, как показано на скриншоте ниже:
И снова он открывает свой почтовый клиент, чтобы увидеть содержание письма, показывающее, как Host header (заголовок хоста) был использован для создания ссылки сброса пароля:
Теперь ссылка для сброса пароля использует домен «attacker.com». Если администратор щелкнет на эту ссылку, код сброса пароля будет отправлен на сервер злоумышленника. Затем злоумышленник может изменить пароль администратора и взломать каждый веб-сайт, который администрируется панелью управления.
Чтобы массово поэксплуатировать эту уязвимость, он выполняет следующие шаги:
К другим способам предотвращения атак на Host заголовок относятся:
Защита абсолютных URL
Когда вам нужно использовать абсолютные URL-адреса, вам необходимо, чтобы текущий домен был вручную указан в файле конфигурации и ссылался на это значение вместо заголовка Host. Такой подход, например, устранил бы эксплуатацию при сбросе пароля.
Проверка Host заголовка
Если вы должны использовать заголовок Host, убедитесь, что вы правильно его проверили. Это должно включать проверку его по белому списку разрешенных доменов и отклонение или перенаправление любых запросов на неопознанные хосты. Вы должны проконсультироваться с документацией вашего фреймворка, чтобы узнать, как это сделать. Например, платформа Django предоставляет параметр ALLOWED_HOSTS в файле настроек. Такой подход снизит вашу подверженность атакам путем внедрения заголовка хоста.
Не опирайтесь на заголовки переопределения Host
Также важно убедиться, что вы не поддерживали дополнительные заголовки, которые могут использоваться для создания этих атак, в частности X-Forwarded-Host. Помните, что они могут поддерживаться по умолчанию.
Создайте белый список разрешенных доменов
Чтобы предотвратить атаки на основе маршрутизации на внутреннюю инфраструктуру, вам следует настроить балансировщик нагрузки или любые обратные прокси-серверы для перенаправления запросов только списку разрешенных доменов.
Будьте осторожны со внутренними виртуальными хостами:
При использовании виртуального хостинга следует избегать размещения веб-сайтов и приложений, предназначенных только для внутреннего использования, на том же сервере, что и общедоступный контент. В противном случае злоумышленники могут получить доступ к внутренним доменам через манипуляции с заголовком Host.
Ссылка скрыта от гостей
, потому что сам ничего подобного сотворить пока не могу :*(- Html Injection
- Host Header Injection
- Username Enumeration – SSN
- Same Origin Policy и Exploiting CORS Misconfigurations
- Origin Reflection Attacks
- CSRF
- CSRF Bypass – Clickjacking Drag and Drop
- Redirection Bugs
- XSS – Cross-Site Scripting
- Identifying XSS Vulnerabilities
- JSONP
- Language-Specific XSS
- SOME Attacks
- CSV Injection
- HTTP Desync
- Web Cache Poisoning
Вся информация предоставлена исключительно в ознакомительных целях. Автор не несет ответственности за любой возможный вред, причиненный с использованием сведений из этой статьи.
HOST HEADER INJECTION
В то время пока работает новая схема пассивного дохода Юрия (описанная в предыдущей главе), он решает поискать другую уязвимость на GitHub. На домашней странице GitHub он выполняет поиск «$_SERVER ['HTTP_HOST']». Для тех, кто с PHP не знаком, $_SERVER - это зарезервированная переменная, содержащая массив заголовков HTTP, путей (paths) и местоположений скриптов. Переменная $_SERVER ['HTTP_HOST'] получает заголовок хоста из веб-запроса (request), отправленного в приложение.Снимок экрана, показывающий результаты поиска GitHub:
Открывая коммит, он получает прилив адреналина (настоящий адреналиновый маньяк, прим.ред).
Форма сброса пароля панели управления хостингом была недавно (менее трех месяцев на момент печати статьи) уязвима для уязвимости, связанной с внедрением заголовка хоста (Host Header Injection)!
Что такое Host Header Injection?
Host заголовок (header, хедер) запроса указывает на название хоста и номер порта сервера, с которого отправляется запрос. Эти данные доступны для изменения пользователем и должны рассматриваться как потенциальный вектор атаки.
В случае уязвимости, связанной с Host Header Injection, приложению не удается проверить или обезопасить данные Host хедера, что приводит к дальнейшему использованию его в целях злоумышленника. Во многих случаях, как в примере, который мы рассмотрим дальше, заголовок Host используется в создании ссылки на сброс пароля. В случаях, когда Host изменяется посредством ответа приложения на запрос, может возникнуть ситуация отправки запроса, который вызывает вредоносный ответ = отравление кэша (cache poisoning). Кроме того, с точки зрения тестировщика, стоит протестировать заголовок X-Forwarded-Host , так как некоторые конфигурации сервера будут использовать этот заголовок для перезаписи Host или использовать его аналогично Host заголовку.
При нажатии на вкладку проекта выясняется, что последний релиз не содержит исправления уязвимости. Кроме того, при просмотре главной страницы компании и нажатии кнопки установки приложения выясняем, что версия выпущенного проекта является уязвимой. Кроме того, в настоящее время нет доступных CVE или публичных эксплойтов, в которых упоминается эта уязвимость. Например, exploit-db.com содержит только предыдущие уязвимости, но не упоминает Host Header Injection.
Согласно домашней странице Vestacp (
Ссылка скрыта от гостей
), ежемесячно это ПО устанавливается более 25000 раз. Кроме того, большинство хостинг-провайдеров включая Amazon,
Ссылка скрыта от гостей
.
Юрий покупает дешевый домен vespa.monter и устанавливает последнюю версию ПО с главного веб-сайта проекта (в цифровом океане тысячи таких проектов). После установки он запускает скрипт дефолтной конфигурации и завершает установку. Установка панели VestaCP на VPS:
Как только панель управления установлена и настроена, он начинает использовать уязвимость. Он переходит в веб-браузер на страницу сброса пароля, выполняет сброс пароля с дефолтной учетной записью «admin» и открывает
электронное письмо.
Как показано на скриншоте, ссылка для сброса пароля содержит его доменное имя «vesta.monster», а новый код, указанный в URL-адресе отправляется GET запросом. Хоть это и дополнительная уязвимость, но Юрия (и нас с вами) больше интересует эксплуатация инъекции заголовка хоста.
Он снова переходит на страницу сброса пароля, на этот раз настраивая BurpSuite для перехвата запроса. Поймав запрос, он отправляет запрос во вкладку «Repeater» в котором редактирует значение заголовка хоста
с «vesta.monster» на «attacker.com» и повторяет запрос, как показано на скриншоте ниже:
И снова он открывает свой почтовый клиент, чтобы увидеть содержание письма, показывающее, как Host header (заголовок хоста) был использован для создания ссылки сброса пароля:
Теперь ссылка для сброса пароля использует домен «attacker.com». Если администратор щелкнет на эту ссылку, код сброса пароля будет отправлен на сервер злоумышленника. Затем злоумышленник может изменить пароль администратора и взломать каждый веб-сайт, который администрируется панелью управления.
Чтобы массово поэксплуатировать эту уязвимость, он выполняет следующие шаги:
1. Покупает доменное имя.
2. Настраивает веб-сервер на VPS, который регистрирует все запросы GET на 443 и 80 порты.
3. Создает запись «A», которая указывает на приобретенное доменное имя на шаге 1 и на айпишник VPS на шаге 2.
4. Использует такой инструмент, как masscan, для сканирования всего Интернета по порту 8083 (порт vestacp по умолчанию).
5. Выполняет поиск на shodan.io, чтобы создать список известных IP-адресов, использующих панель управления vestacp.
6. Объединяет IP-адреса, найденные на шагах 4 и 5, в единый список.
7. Создает скрипт на bash или python, который будет выполнять следующие действия:
а. Чтение списка IP-адресов с шага 6.
б. Отправление запроса на сброс пароля с эндпоинтом /reset/ с помощью Host хэдера установленного со значением приобретенного доменного имени.
8. Мониторит логи VPS сервера, настроенные на шаге 2, на наличие попавшихся горе-администраторов, которые нажали ссылку для сброса пароля, отправленную на их электронную почту.
Вывод
Чтобы предотвратить Host Header Injection атаки, самый простой подход - полностью отказаться от использования заголовка Host в коде на стороне сервера. Дважды проверьте, действительно ли каждый URL-адрес должен быть абсолютным, часто оказывается, что вместо этого можете просто использовать относительный URL. Это простое изменение может помочь вам, в частности, предотвратить уязвимости, связанные с web-cache poisoning.К другим способам предотвращения атак на Host заголовок относятся:
Защита абсолютных URL
Когда вам нужно использовать абсолютные URL-адреса, вам необходимо, чтобы текущий домен был вручную указан в файле конфигурации и ссылался на это значение вместо заголовка Host. Такой подход, например, устранил бы эксплуатацию при сбросе пароля.
Проверка Host заголовка
Если вы должны использовать заголовок Host, убедитесь, что вы правильно его проверили. Это должно включать проверку его по белому списку разрешенных доменов и отклонение или перенаправление любых запросов на неопознанные хосты. Вы должны проконсультироваться с документацией вашего фреймворка, чтобы узнать, как это сделать. Например, платформа Django предоставляет параметр ALLOWED_HOSTS в файле настроек. Такой подход снизит вашу подверженность атакам путем внедрения заголовка хоста.
Не опирайтесь на заголовки переопределения Host
Также важно убедиться, что вы не поддерживали дополнительные заголовки, которые могут использоваться для создания этих атак, в частности X-Forwarded-Host. Помните, что они могут поддерживаться по умолчанию.
Создайте белый список разрешенных доменов
Чтобы предотвратить атаки на основе маршрутизации на внутреннюю инфраструктуру, вам следует настроить балансировщик нагрузки или любые обратные прокси-серверы для перенаправления запросов только списку разрешенных доменов.
Будьте осторожны со внутренними виртуальными хостами:
При использовании виртуального хостинга следует избегать размещения веб-сайтов и приложений, предназначенных только для внутреннего использования, на том же сервере, что и общедоступный контент. В противном случае злоумышленники могут получить доступ к внутренним доменам через манипуляции с заголовком Host.
Последнее редактирование:
