Cache Poisoning and Cache Deception
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Яка різниця між отруєнням кешу веб-додатків та обманом кешу веб-додатків?
У отруєнні кешу веб-додатків зловмисник змушує додаток зберігати деякий шкідливий контент у кеші, і цей контент надається з кешу іншим користувачам додатка.
У обмані кешу веб-додатків зловмисник змушує додаток зберігати деякий чутливий контент, що належить іншому користувачу, у кеші, а потім зловмисник отримує цей контент з кешу.
Отруєння кешу спрямоване на маніпулювання кешем на стороні клієнта, щоб змусити клієнтів завантажувати ресурси, які є несподіваними, частковими або під контролем зловмисника. Ступінь впливу залежить від популярності ураженої сторінки, оскільки забруднена відповідь надається виключно користувачам, які відвідують сторінку під час періоду забруднення кешу.
Виконання атаки отруєння кешу включає кілька етапів:
Ідентифікація незахищених вхідних даних: Це параметри, які, хоча й не є обов'язковими для кешування запиту, можуть змінити відповідь, що повертається сервером. Ідентифікація цих вхідних даних є критично важливою, оскільки їх можна використовувати для маніпуляції кешем.
Експлуатація незахищених вхідних даних: Після ідентифікації незахищених вхідних даних наступним кроком є з'ясування, як зловживати цими параметрами, щоб змінити відповідь сервера на користь зловмисника.
Забезпечення кешування отруєної відповіді: Останній крок полягає в тому, щоб переконатися, що маніпульована відповідь зберігається в кеші. Таким чином, будь-який користувач, який отримує доступ до ураженої сторінки під час отруєння кешу, отримає забруднену відповідь.
Зазвичай, коли відповідь була збережена в кеші, буде заголовок, що це вказує, ви можете перевірити, на які заголовки слід звернути увагу в цьому пості: HTTP Cache headers.
Якщо ви думаєте, що відповідь зберігається в кеші, ви можете спробувати надіслати запити з неправильним заголовком, на які має бути відповідь з кодом статусу 400. Потім спробуйте отримати доступ до запиту нормально, і якщо відповідь має код статусу 400, ви знаєте, що це вразливо (і ви навіть можете виконати DoS).
Ви можете знайти більше варіантів у:
Cache Poisoning to DoSОднак зверніть увагу, що іноді такі коди статусу не кешуються, тому цей тест може бути ненадійним.
Ви можете використовувати Param Miner для грубої сили параметрів і заголовків, які можуть змінювати відповідь сторінки. Наприклад, сторінка може використовувати заголовок X-Forwarded-For, щоб вказати клієнту завантажити скрипт звідти:
З ідентифікованим параметром/заголовком перевірте, як він санітується і де він відображається або впливає на відповідь з заголовка. Чи можете ви зловживати цим (виконати 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:
Зверніть увагу, що це отруїть запит до /en?region=uk, а не до /en
Куки також можуть бути відображені у відповіді сторінки. Якщо ви зможете зловживати цим, щоб викликати XSS, наприклад, ви зможете експлуатувати XSS у кількох клієнтах, які завантажують шкідливу відповідь кешу.
Зверніть увагу, що якщо вразливий cookie дуже часто використовується користувачами, регулярні запити очищатимуть кеш.
Перевірте:
Cache Poisoning via URL discrepanciesЦей звіт пояснює як було можливим викрасти API ключ OpenAI за допомогою URL на кшталт https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123, оскільки все, що відповідає /share/*, буде кешуватися без нормалізації URL Cloudflare, що було зроблено, коли запит досяг веб-сервера.
Це також краще пояснюється в:
Cache Poisoning via URL discrepanciesІноді вам потрібно буде експлуатувати кілька неключових вхідних даних, щоб мати можливість зловживати кешем. Наприклад, ви можете знайти Відкритий редирект, якщо ви встановите X-Forwarded-Host на домен, що контролюється вами, а X-Forwarded-Scheme на http. Якщо сервер пересилає всі HTTP запити на HTTPS і використовує заголовок X-Forwarded-Scheme як ім'я домену для редиректу. Ви можете контролювати, куди вказується сторінка за допомогою редиректу.
Vary заголовкомЯкщо ви виявили, що X-Host заголовок використовується як ім'я домену для завантаження JS ресурсу, але Vary заголовок у відповіді вказує на User-Agent. Тоді вам потрібно знайти спосіб ексфільтрувати User-Agent жертви та отруїти кеш, використовуючи цей User-Agent:
Відправте GET запит з запитом в URL та в тілі. Якщо веб-сервер використовує той, що в тілі, але сервер кешу кешує той, що в URL, будь-хто, хто отримує доступ до цього URL, насправді використовуватиме параметр з тіла. Як вразливість, яку знайшов Джеймс Кеттл на сайті Github:
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
Дізнайтеся тут, як виконати атаки Cache Poisoning, зловживаючи HTTP Request Smuggling.
Web Cache Vulnerability Scanner може бути використаний для автоматичного тестування на вразливість до web cache poisoning. Він підтримує багато різних технік і є високонастроюваним.
Приклад використання: wcvs -u example.com
ATS переслав фрагмент всередині URL без його видалення і згенерував ключ кешу, використовуючи лише хост, шлях і запит (ігноруючи фрагмент). Тому запит /#/../?r=javascript:alert(1) був надісланий на бекенд як /#/../?r=javascript:alert(1) і ключ кешу не містив payload, лише хост, шлях і запит.
Відправка неправильного значення в заголовку content-type викликала кешовану відповідь 405. Ключ кешу містив cookie, тому було можливо атакувати лише неавторизованих користувачів.
GitLab використовує GCP buckets для зберігання статичного контенту. GCP Buckets підтримують заголовок x-http-method-override. Тому було можливо надіслати заголовок x-http-method-override: HEAD і отруїти кеш, щоб він повертав порожнє тіло відповіді. Це також могло підтримувати метод PURGE.
У додатках Ruby on Rails часто використовується Rack middleware. Мета коду Rack полягає в тому, щоб взяти значення заголовка x-forwarded-scheme і встановити його як схему запиту. Коли надсилається заголовок x-forwarded-scheme: http, відбувається перенаправлення 301 на те ж місце, що може призвести до відмови в обслуговуванні (DoS) цього ресурсу. Крім того, додаток може визнати заголовок X-forwarded-host і перенаправити користувачів на вказаний хост. Ця поведінка може призвести до завантаження JavaScript файлів з сервера зловмисника, що становить загрозу безпеці.
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, які відповідають інструментам з високим трафіком, таким як FFUF або Nuclei, щоб управляти навантаженням на сервер. Іронічно, цей підхід може ввести вразливості, такі як отруєння кешу та DoS.
RFC7230 визначає прийнятні символи в іменах заголовків. Заголовки, що містять символи поза вказаним діапазоном tchar, повинні ідеально викликати відповідь 400 Bad Request. На практиці сервери не завжди дотримуються цього стандарту. Помітним прикладом є Akamai, який пересилає заголовки з недійсними символами і кешує будь-яку помилку 400, якщо заголовок cache-control відсутній. Було виявлено експлуатовану схему, де надсилання заголовка з недійсним символом, таким як \, призводило до кешованої помилки 400 Bad Request.
https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6
Мета 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.
toxicache: сканер на Golang для виявлення вразливостей web cache poisoning у списку URL-адрес і тестування кількох технік ін'єкції.
Використовуйте Trickest, щоб легко створювати та автоматизувати робочі процеси, що базуються на найсучасніших інструментах спільноти. Отримайте доступ сьогодні:
Дізнайтеся та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Дізнайтеся та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
