Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-20 01:55:46 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cache-deception/README.md

271 lines
21 KiB
Markdown
Raw Blame History

# Cache Poisoning e Cache Deception
{% hint style="success" %}
Aprenda e pratique Hacking AWS:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
Aprenda e pratique Hacking GCP: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>Support HackTricks</summary>
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe truques de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
</details>
{% endhint %}
<figure><img src="../../.gitbook/assets/image (48).png" alt=""><figcaption></figcaption></figure>
\
Use [**Trickest**](https://trickest.com/?utm\_source=hacktricks\&utm\_medium=text\&utm\_campaign=ppc\&utm\_term=trickest\&utm\_content=cache-deception) para construir e **automatizar fluxos de trabalho** facilmente, impulsionados pelas **ferramentas comunitárias mais avançadas** do mundo.\
Acesse hoje:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}
## A diferença
> **Qual é a diferença entre envenenamento de cache web e engano de cache web?**
>
> * No **envenenamento de cache 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 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.
## Envenenamento de Cache
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.
A execução de um ataque de envenenamento de cache envolve várias etapas:
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.
### Descoberta: Verifique os cabeçalhos 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).
### Descoberta: Códigos de erro de cache
Se você está pensando que a resposta está sendo armazenada em um cache, você poderia tentar **enviar solicitações com um cabeçalho inválido**, 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).
Você pode encontrar mais opções em:
{% content-ref url="cache-poisoning-to-dos.md" %}
[cache-poisoning-to-dos.md](cache-poisoning-to-dos.md)
{% endcontent-ref %}
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.
### Descoberta: Identificar e avaliar entradas não chaveadas
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 de lá:
```markup
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### Elicit a harmful response from the back-end server
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?...)
### Get the response cached
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.
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`
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.
Mais um cabeçalho relacionado ao cache é **`Age`**. Ele define o tempo em segundos que o objeto está no cache do proxy.
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 aquele mesmo cabeçalho**. Sempre **teste** um Cache Poisoning com **diferentes navegadores** para verificar se está funcionando.
## Exploiting Examples
### Easiest example
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:
```markup
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`_
### Envenenamento de cache para DoS
{% content-ref url="cache-poisoning-to-dos.md" %}
[cache-poisoning-to-dos.md](cache-poisoning-to-dos.md)
{% endcontent-ref %}
### Usando o envenenamento de cache da web para explorar vulnerabilidades de manipulação de cookies
Os 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.
```markup
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.
### 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:
{% content-ref url="cache-poisoning-via-url-discrepancies.md" %}
[cache-poisoning-via-url-discrepancies.md](cache-poisoning-via-url-discrepancies.md)
{% endcontent-ref %}
### Envenenamento de cache com travessia de caminho para roubar chave de API <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 de API da 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.
Isso também é explicado melhor em:
{% content-ref url="cache-poisoning-via-url-discrepancies.md" %}
[cache-poisoning-via-url-discrepancies.md](cache-poisoning-via-url-discrepancies.md)
{% endcontent-ref %}
### 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>
À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.
```markup
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
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:
```markup
GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
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 um que acessar essa URL usará na verdade o parâmetro do corpo. Como a vulnerabilidade que James Kettle encontrou no site do Github:
```
GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22
report=innocent-victim
```
There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
### 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.
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)
### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling
Aprenda aqui como realizar [ataques de Cache Poisoning abusando de HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-poisoning).
### Automated testing for Web Cache Poisoning
O [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) pode ser usado para testar automaticamente a presença de web cache poisoning. Ele suporta muitas técnicas diferentes e é altamente personalizável.
Exemplo de uso: `wcvs -u example.com`
## Vulnerable Examples
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
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.
### 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.
### GitLab + GCP CP-DoS
GitLab usa buckets GCP para armazenar conteúdo estático. **Buckets GCP** suportam o **cabeçalho `x-http-method-override`**. Assim, era possível enviar o cabeçalho `x-http-method-override: HEAD` e envenenar o cache para retornar um corpo de resposta vazio. Também poderia 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) para 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.
### 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.
### Injecting Keyed Parameters
Os caches frequentemente incluem parâmetros GET específicos na chave de cache. Por exemplo, o Varnish da 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 poderia ser armazenado em cache.
### 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 cache poisoning e DoS.
### 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 poderia ser armazenado em cache.
### Finding new headers
[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
## Cache Deception
O objetivo da Cache Deception é fazer com que os clientes **carreguem recursos que serão salvos pelo cache com suas informações sensíveis**.
Primeiro, note que **extensões** como `.css`, `.js`, `.png`, etc., geralmente são **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.
Outras coisas a 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`
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.
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_).
Aprenda aqui como realizar [ataques de Cache Deceptions abusando de HTTP Request Smuggling](../http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception).
## Automatic Tools
* [**toxicache**](https://github.com/xhzeem/toxicache): Scanner em Golang para encontrar vulnerabilidades de web cache poisoning em uma lista de URLs e testar várias técnicas de injeção.
## 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)
* [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)
* [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/)
<figure><img src="../../.gitbook/assets/image (48).png" alt=""><figcaption></figcaption></figure>
\
Use [**Trickest**](https://trickest.com/?utm\_source=hacktricks\&utm\_medium=text\&utm\_campaign=ppc\&utm\_term=trickest\&utm\_content=cache-deception) para construir e **automatizar fluxos de trabalho** facilmente, impulsionados pelas **ferramentas** da **comunidade mais avançadas** do mundo.\
Acesse hoje:
{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}
{% hint style="success" %}
Aprenda e pratique Hacking AWS:<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../.gitbook/assets/arte.png" alt="" data-size="line">\
Aprenda e pratique Hacking GCP: <img src="../../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>Support HackTricks</summary>
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
</details>
{% endhint %}
Reference in a new issue View git blame Copy permalink