HTTPoxy - Conflito de nome da variável "HTTP_PROXY" em CGI

Foi descoberta uma vulnerabilidade na forma como os scripts CGI são usados pelos produtos Red Hat que utilizam PHP, Go, Python, entre outras linguagens de script.

Alguns servidores web, frameworks para web e linguagens de programação (mais comumente em um ambiente CGI) definem a variável de ambiente “HTTP_PROXY” com base nos dados das solicitações recebidas (ex. um cabeçalho de solicitação chamado "Proxy" com dados fornecidos por usuários). A variável de ambiente “HTTP_PROXY” é usada por diversos pacotes de software de cliente web para especificar que um servidor proxy remoto faça uso do HTTP e, em alguns casos, de solicitações HTTPS. Como consequência, quando um aplicativo web está em execução, é possível que um invasor especifique um servidor proxy utilizado pelo aplicativo para as subsequentes solicitações enviadas, favorecendo um ataque "Man-in-the-Middle". Esta falha recebeu o nome de HTTPoxy .

Informações Gerais

CGI e variáveis de ambiente

O servidor HTTP usa um conjunto de variáveis de ambiente para transmitir informações ao script CGI. Algumas dessas variáveis de ambiente são usadas para comunicar certos aspectos da solicitação HTTP, como o tipo de conteúdo, a porta TCP, o nome do host ou o método de solicitação (por exemplo, GET ou POST). Existe um conjunto diferente de variáveis de ambiente, que o RFC chama de "Protocol-Specific Meta-Variables", usado para passar os valores dos cabeçalhos HTTP para o script CGI. O mapeamento dos cabeçalhos HTTP para as variáveis de ambiente segue um procedimento padrão: o nome do cabeçalho HTTP é convertido para letras maiúsculas, "-" é substituído por "_" e "HTTP_" é prefixado.

Por exemplo, o cabeçalho "Cookie" é passado usando a variável de ambiente "HTTP_COOKIE" e o cabeçalho "Proxy" é passado usando a variável de ambiente "HTTP_PROXY". Por favor, observe que o cabeçalho "Proxy" não é um cabeçalho padrão oficial e não está no registro de cabeçalho provisório. O cabeçalho "Proxy" não deve ser usado por nenhum cliente ou aplicativo compatível com os padrões.

A variável de ambiente do "sistema" HTTP_PROXY

Existe uma variável de ambiente do sistema comum chamada "HTTP_PROXY", que pode ser usada para comunicar as configurações do proxy HTTP (e, às vezes, HTTPS) para um proxy HTTP enviado para um aplicativo. Esta variável possui um objetivo e um contexto completamente diferentes daqueles da variável servidor-script HTTP. Aplicativos, bibliotecas de linguagem ou módulos de script usam esta variável de ambiente para configurar seus proxies para o subsequente tráfego HTTP de saída.

A Interface CGI (Common Gateway Interface) é um padrão desenvolvido para permitir que os servidores web HTTP, como Apache ou nginx, conectem-se com binários ou scripts executáveis usando uma interface para gerar páginas da web dinâmicas. Este padrão está documentado em RFC 3875 . Os scripts CGI podem ser escritos em várias linguagens de scrip, como PHP, Python, Perl, Ruby ou golang, mas também podem ser arquivos binários compilados.

O servidor HTTP e o script CGI interagem da seguinte maneira:

1. O servidor HTTP recebe uma solicitação HTTP, analisa-a e configura as variáveis de ambiente necessárias.
2. O servidor HTTP chama o script CGI e passa todos os dados da solicitação através da entrada padrão do script.
3. O script CGI processa as variáveis de ambiente e suas entradas e envia uma resposta de volta ao servidor HTTP, usando a saída padrão do script.
4. O servidor HTTP envia a resposta gerada pelo script CGI de volta para o cliente.

O problema: conflito de nome HTTP_PROXY

O script CGI não consegue fazer uma distinção entre "Protocol-Specific Meta-Variable" do CGI - contendo o valor do cabeçalho "Proxy" da solicitação HTTP - e a variável de ambiente do "sistema" HTTP_PROXY - contendo as configurações do proxy HTTP. Uma biblioteca, um método ou um script CGI lê a variável de ambiente "HTTP_PROXY" e presume que ela contém as configurações do proxy HTTP do "sistema". O valor mal interpretado muda, assim, a maneira como as solicitações HTTP são tratadas pelo script CGI (e por qualquer outro script ou programa que possa ser chamado) feito durante o processamento da solicitação HTTP.

Intervenções Necessárias

Recomendamos que todos os clientes Red Hat usando scripts CGI com PHP, Go ou Python apliquem mitigações nos seus sistemas. Os detalhes sobre os pacotes impactados e as versões das Imagens, assim como as mitigações sugeridas, podem ser encontrados sob a aba Resolução.

Agradecimentos

A Red Hat gostaria de agradecer Dominic Scheirlinck da VendHQ por notificar este problema e ajudar na sua resolução.

A Red Hat Product Security classificou esta atualização como um impacto de segurança Importante .

Para diagnosticar esta vulnerabilidade no seu ambiente, consulte a aba Resolução.

Produtos Impactados

• Red Hat Enterprise Linux 7.x

• Red Hat Enterprise Application Platform 6.x

• Red Hat Enterprise Web Server 2.x

• Red Hat JBoss Web Server 3.x

• Red Hat Satellite

Descrição e Impacto do Ataque

O Ataque

O ataque é bem simples e direto. Um invasor envia uma solicitação HTTP especialmente elaborada para um script CGI vulnerável. A solicitação contém um cabeçalho "Proxy" com o nome do host ou o endereço IP e a porta de um proxy controlado pelo invasor como seu valor. O servidor HTTP recebe a solicitação e, como parte do processamento habitual, converte o cabeçalho "Proxy" e seu valor na variável de metadados "HTTP_PROXY", antes de continuar chamando o script CGI. O script CGI lê a variável HTTP_PROXY, mas confunde-se com a variável do "sistema" usada para comunicar as configurações para o proxy HTTP de saída e se configura para usar o proxy especificado. Caso o script CGI desempenhe as solicitações HTTP, essas solicitações são, então, enviadas através do proxy controlado pelo invasor, permitindo que ele realize "Man-in-the-Middle" em todas as partes do tráfego HTTP.

O Impacto e a Criticalidade

Os scripts CGI são suscetíveis somente a esta vulnerabilidade se eles interpretarem de modo errôneo a variável HTTP_PROXY E enviarem as solicitações HTTP (ou, em alguns casos, HTTPS). O número de scripts desempenhando ambos será um subconjunto menor dos scripts CGI no geral.

É difícil afirmar o impacto e a criticalidade global, pois isto depende do comportamento do script CGI. Um cenário particularmente ruim seria um script CGI que desempenha tarefas confidenciais (por exemplo, autenticação usando uma API de estilo REST). Neste caso, o invasor poderia redirecionar todas as partes do tráfego HTTP entre o script CGI e o servidor HTTP (estilo REST) através do proxy controlado pelo invasor. Isto poderia resultar na divulgação de informações confidenciais contidas tanto na solicitação quanto na resposta enviada entre o script CGI e o servidor HTTP.

Além disto, o invasor poderia manipular os conteúdos de solicitação e resposta. Se o script CGI envia solicitações a um servidor interno que não pode ser atingido fora da internet, o proxy do invasor pode não conseguir comunicar-se com o servidor interno e o invasor pode não conseguir interceptar as respostas do servidor interno. No entanto, o invasor poderia, mesmo assim, interceptar a solicitação do script CGI e enviar de volta uma resposta falsa.