Cloudflare corrigiu uma vulnerabilidade de smuggling HTTP/2

Views: 602

Em 14 de julho, Emil Lerner encontrou e explorou novas formas de exploração de dessincron/smuggling http com base em problemas de processamento de solicitações HTTP/2. Ele enviou o bug para a equipe de segurança da Cloudflare através do programa de recompensa de bugs.

Este problema de segurança levou uma semana para a Cloudflare ser corrigido e foi concluído em 24 de julho. Emil foi premiado com uma recompensa de $1.000, e em 15 de agosto, a empresa aceitou este bug para divulgação pública. Aqui vamos nós.

A natureza e o impacto do smuggling de pedidos http/2

Quando alguém realiza uma solicitação ao site de um cliente da Cloudflare via HTTP/2, o Cloudflare aplica validação mais fraca após o 100º cabeçalho antes de encaminhar a solicitação para um upstream. Se o servidor HTTP do cliente Cloudflare aceitar e analisar os cabeçalhos HTTP que terminam com uma guia ou um caractere de espaço, isso pode levar à dessincronização de solicitação/resposta no HTTP/1.1 causado pela solicitação inicial do invasor HTTP/2.

O problema é reprodutível no domínio www.cloudflare.com, que provavelmente usa a mesma infraestrutura que o proxy para os clientes. Mais uma vez, a exploração prática deste bug depende tanto da questão do proxy cloudflare quanto do servidor do cliente.

O impacto do smuggling de solicitação HTTP inclui envenenamento por cache HTTP, sequestro de contas e muito mais.

Recomendamos olhar os slides blackhat 2019 para melhor estimar o risco potencial.

Reprodução

Como o PoC precisa enviar solicitações HTTP/2 que não são consideradas válidas pela maioria das bibliotecas HTTP, ou seja, libcurl, Emil escreveu um pequeno programa Go que envia tais solicitações usando uma API de nível ligeiramente mais baixo, disponível aqui: https://github.com/neex/http2smugl 

Para executar o código PoC, temos que instalar golang versão 1.13.0 ou superior e dois pacotes dependentes: instalados por go get.github.com/spf13/cobra and golang.org/x/net

O programa PoC cfsmulg envia uma solicitação HTTP/2 com mais de 100 cabeçalhos HTTP. Ele aceita a lista de cabeçalhos adicionais como argumentos de linha de comando e os adiciona após o 100º cabeçalho. Por causa desta questão, eles serão encaminhados inalterados para o rio acima.

Para reproduzir a questão subjacente, temos que executar o PoC da seguinte maneira:

go run cfsmugl.go request <https://some-cloudflare-customer.com/> "a man, a plan, a canal : panama"

Como resultado, a seguinte solicitação HTTP será recebida pelo backend do cliente Cloudflare do Cloudflare upstream:

GET / HTTP/1.1Host: some-cloudflare-customer.comConnection: Keep-AliveAccept-Encoding: gzipCF-IPCountry: USX-Forwarded-For: <your-ip>CF-RAY: 5a2e0232ebd87b87-DMEX-Forwarded-Proto: httpsCF-Visitor: {"scheme":"https"}user-agent: Mozilla/5.0a man, a plan, a canal : panamaCF-Request-ID: 03509fb3ce00007b87699e2200000001CF-Connecting-IP: <your-ip>CDN-Loop: cloudflare

Como você pode ver, HTTP cabeçalho um homem, um plano, um canal : panamá está aqui de uma maneira inalterada.

Observe que o cabeçalho especificado na linha de comando contém espaços, incluindo um no final de seu nome, e é encaminhado inalterado. Os cólons, linhas novas e A-Z ainda são proibidos nos cabeçalhos contrabandeados, mas espaços e guias são suficientes para realizar o ataque em alguns casos.

Exploração

A fim de desencadear a dessincronização HTTP na conexão HTTP manter viva entre o Cloudflare e seus clientes, um invasor pode usar algo como codificação de transferência : em pedaços (observe o espaço antes do cólon). Cloudflare irá encaminhá-lo como está, e o software do cliente ainda pode interpretá-lo. De acordo com a especificação HTTP, a codificação de transferência tem precedência sobre o comprimento do conteúdo, o que significa que é possível realizar o tipo de smuggling de solicitação HTTP CL.TE. No entanto, em vez de Content-Length, é o comprimento do fluxo http2.

Vamos demonstrar o problema no caso de www.cloudflare.com:

Se corrermos

go run cfsmugl.go request <https://www.cloudflare.com/> "transfer-encoding : pizza"

receberemos um erro 503, porque o upstream provavelmente é confundido com o pedido de decodificação da codificação imaginária de transporte de pizza.

Se corrermos

go run cfsmugl.go request <https://www.cloudflare.com/> "transfer-encoding : chunked"

então o pedido será pendurado, pois o rio acima espera um corpo que nunca chegará.

Se desativarmos o envio de 100 cabeçalhos adicionais usando -skip-magic-headers, então mude para o programa

go run cfsmugl.go request <https://www.cloudflare.com/> "transfer-encoding : chunked" --skip-magic-headers

Receberemos as 200 respostas habituais, pois o problema não é acionado.

Há um subcomand detectável no utilitário, que fornece diferentes maneiras de detectar que um cliente de fato analisa e usa um cabeçalho com um espaço no final.

Mitigação e mais pesquisas

Este bug foi corrigido pela equipe cloudflare em uma semana. Ao mesmo tempo, podemos esperar encontrar problemas semelhantes em diferentes balanceadores de carga, CDNs e provedores de hospedagem com suporte a HTTP/2. Além disso, recentemente houve outra forma de smuggling de solicitação HTTP/2 com base em uma atualização para h2c https://labs.bishopfox.com/tech-blog/h2c-smuggling-request-smuggling-via-http/2-cleartext-h2c foi publicada.

Resumindo, os ataques de smuggling, incluindo o desync, são importantes para a web moderna e são relevantes tanto para HTTP/1.1 quanto para HTTP/2.

Se você está procurando por NGWAF com um suporte nativo http/2, REST, gRPC, GraphQL e WebSockets, recomendamos considerar wallarm.

FONTE: WALLARM