Что нового

Article [10.2.1] Burp Suite. Exploiting web cache poisoning vulnerabilities

Vander 0

Vander

Команда форума
10.11.2019
495
1 158
Приветствую уважаемую аудиторию форума Protey!

DNS poisoning header.png

Продолжаем разбирать способы возникновения уязвимостей, отравляющих веб-кеш, и рассматриваем практические примеры, предыдущие статьи цикла можно найти тут:
Использование отравления веб-кэша для использования уязвимостей при обработке файлов cookie

Файлы cookie часто используются для динамического создания содержимого в ответе. Типичным примером может быть файл cookie, который указывает предпочитаемый язык пользователя, который затем используется для загрузки соответствующей версии страницы:

Код:
GET /blog/post.php?mobile=1 HTTP/1.1
Host: innocent-website.com
User-Agent: Mozilla/5.0 Firefox/57.0
Cookie: language=pl;
Connection: close
В этом примере запрашивается польская версия сообщения в блоге. Предположим, что ключ кеша содержит только строку запроса и заголовок хоста. Это означает, что информация о том, какая языковая версия будет использоваться, содержится только в заголовке неиспользованного файла cookie. Если ответ на этот запрос кэшируется, то все последующие пользователи, которые пытались получить доступ к этому сообщению в блоге, также получили бы польскую версию, независимо от того, какой язык они фактически выбрали.

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

Практический пример:

Отравление веб-кэша неключевым файлом cookie

Эта лаборатория уязвима для отравления веб-кэша, потому что куки не включены в ключевые параметры кэша. Пользователь посещает домашнюю страницу примерно раз в минуту. Чтобы решить эту задачу, отравите кэш ответом, который запускает alert (1) в браузере посетителя.
  • Запустив Burp, загрузите домашнюю страницу сайта.
  • В Burp перейдите к «Proxy» > «HTTP history» и изучите сгенерированные вами запросы и ответы. Обратите внимание, что первый полученный вами ответ устанавливает cookie fehost = prod-cache-01.
  • Перезагрузите домашнюю страницу и обратите внимание, что значение из cookie-файла fehost отражено в объекте JavaScript с двойными кавычками в ответе.
1587310046556.png

  • Отправьте этот запрос в Burp Repeater и добавьте параметр cache buster.
  • Измените значение cookie на произвольную строку и повторите запрос. Убедитесь, что эта строка отражена в ответе.
1587310135242.png

  • Поместите подходящую полезную нагрузку XSS в cookie-файл fehost, например: fehost = SomeString "-alert (1) -" SomeString
  • Повторяйте запрос, пока не увидите полезную нагрузку в ответе и попадание X-Cache: в заголовки.
  • Обновите страницу и подтвердите срабатывание alert ().

1587310318142.png

  • Вернитесь к Burp Repeater, удалите cache buster и повторите запрос, чтобы сохранить кеш в ядре, пока жертва не посетит сайт, и лаборатория не будет решена.
Использование нескольких заголовков для использования уязвимостей при отравлении веб-кэша

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

Например, скажем, веб-сайт требует безопасного общения с использованием HTTPS. Для обеспечения этого, если получен запрос, который использует другой протокол, веб-сайт динамически генерирует для себя перенаправление, которое использует HTTPS:

Код:
GET /random HTTP/1.1
Host: innocent-site.com
X-Forwarded-Proto: http

HTTP/1.1 301 moved permanently
Location: https://innocent-site.com/random
Само по себе это поведение не обязательно уязвимо. Однако, сочетая это с тем, что мы узнали ранее об уязвимостях в динамически генерируемых URL-адресах, злоумышленник может использовать это поведение для создания кэшируемого ответа, который перенаправляет пользователей на вредоносный URL-адрес.

Практический пример:

Отравление веб-кэша несколькими заголовками

В этой лабораторной работе содержится уязвимость, приводящая к отравлению веб-кэша, которая может использоваться только при использовании нескольких заголовков для создания вредоносного запроса. Пользователь посещает домашнюю страницу примерно раз в минуту. Чтобы решить эту задачу, отравите кэш ответом, который запускает оповещение (document.cookie) в браузере посетителя.

Примечание: эта лаборатория поддерживает заголовки X-Forwarded-Host и X-Forwarded-Scheme.
  • Запустив Burp, загрузите домашнюю страницу сайта.
  • Перейдите в «Proxy» > «HTTP history» и изучите сгенерированные вами запросы и ответы. Найдите запрос GET для файла JavaScript /resources/js/tracking.js и отправьте его в Burp Repeater.
  • Добавьте параметр cache buster и заголовок X-Forwarded-Host с произвольным именем хоста, например example.com. Обратите внимание, что это не оказывает никакого влияния на ответ.
  • Удалите заголовок X-Forwarded-Host и добавьте вместо него заголовок X-Forwarded-Scheme. Обратите внимание, что если вы включите любое значение, кроме HTTPS, вы получите ответ 302. Заголовок Location показывает, что вы перенаправлены на тот же URL-адрес, который вы запрашивали, но с использованием https://.
  • Добавьте в запрос заголовок X-Forwarded-Host: example.com, но также сохраните X-Forwarded-Scheme: nothttps. Отправьте этот запрос и обратите внимание, что Location header 302 redirect теперь указывает на https://example.com/.
1587315206836.png

  • Перейдите на сервер эксплойтов и измените имя файла в соответствии с путем, используемым уязвимым ответом: /resources/js/tracking.js
  • В теле payload введите alert(document.cookie) и сохраните эксплойт.
  • Вернитесь к запросу в Burp Repeater и установите заголовок X-Forwarded-Host следующим образом, не забывая ввести свой собственный идентификатор сервера эксплойтов: X-Forwarded-Host: your-exploit-server-id.web-security-academy.net
1587315617616.png

  • Убедитесь, что в заголовке X-Forwarded-Scheme установлено любое другое значение, кроме HTTPS.
  • Отправляйте запрос, пока в ответе не отобразится URL вашего сервера эксплойтов, а X-Cache: попадет в заголовки.
  • Чтобы проверить правильность кэширования ответа, щелкните правой кнопкой мыши запрос в Burp, выберите «Copy URL» и загрузите этот URL в браузере. Если кэш был успешно отравлен, вы увидите скрипт, содержащий вашу полезную нагрузку, alert (document.cookie). Обратите внимание, что alert () на самом деле не будет выполняться здесь.
1587315719942.png

  • Вернитесь в «Burp Repeater», удалите cache buster и повторяйте запрос, пока вы снова не отравите кэш.
  • Чтобы смоделировать жертву, перезагрузите домашнюю страницу в вашем браузере и убедитесь, что оповещение () срабатывает.
  • Повторяйте запрос на сохранение кэша отравленным, пока жертва не зайдет на сайт и задание не будет решено.
Спасибо за внимание, материал подготовлен специально для форума protey.net
 
Последнее редактирование:
Верх Низ