Mitigando a vulnerabilidade HTTPoxy com o NGINX

Owen GarrettDiretor Sênior de Gestão de Produtos

Em 18 de julho de 2016, foi anunciada uma vulnerabilidade chamada ‘HTTPoxy’, que afeta algumas aplicações web do lado do servidor executadas em ambientes CGI ou semelhantes a CGI, como determinadas configurações de FastCGI. Até o momento, sabe-se que as linguagens afetadas incluem PHP, Python e Go.

Diversos CVEs foram atribuídos, abrangendo linguagens e implementações de CGI específicas:

• Servidor HTTP Apache (CVE-2016-5387)
• Apache Tomcat (CVE-2016-5388)
• Go (CVE-2016-5386)
• PHP (CVE-2016-5385)

Há um novo site que descreve a vulnerabilidade, uma nota de vulnerabilidade do CERT, além de uma descrição da descoberta da vulnerabilidade. Há mais informações no site pessoal de Dominic Scheirlinck, desenvolvedor web de código aberto na Vend.

Este post descreve a vulnerabilidade e explica como usar o NGINX ou o NGINX Plus para impedir tentativas de explorá-la em seus servidores.

A vulnerabilidade existe devido a um conflito de namespaces. Uma interface semelhante a CGI ou FastCGI define variáveis de ambiente com base nos parâmetros da solicitação HTTP, e essas variáveis podem substituir as variáveis internas usadas para configurar a aplicação.

Atualmente, a única forma conhecida de explorar essa vulnerabilidade afeta aplicações web executadas em ambientes CGI e semelhantes a CGI que usam determinadas bibliotecas de cliente HTTP para fazer solicitações HTTP a outros serviços. Nesse caso, os invasores podem redirecionar as solicitações internas geradas pela aplicação para um servidor de sua escolha e, assim, capturar quaisquer dados confidenciais contidos nas solicitações, conforme mostrado abaixo.

O HTTPoxy usa uma sobreposição de namespaces para acessar o tráfego interno do servidor

Você pode usar o NGINX ou o NGINX Plus para identificar e impedir tentativas de exploração dessa vulnerabilidade. Isso oferece uma maneira eficaz de evitar ataques, dando a você tempo para auditar e atualizar qualquer código afetado.

Como a vulnerabilidade HTTPoxy é explorada

Para entender como essa vulnerabilidade funciona – e como proteger seu site contra ela –, é necessário compreender como as interfaces CGI e semelhantes a CGI definem variáveis de ambiente e como algumas bibliotecas de aplicativos são configuradas por variáveis de ambiente.

1 – Interfaces CGI e semelhantes a CGI definem variáveis de ambiente chamadas HTTP_*

Muitas plataformas de aplicações web usam CGI ou interfaces semelhantes a CGI para conectar aplicações a um servidor web. Essas interfaces convertem os cabeçalhos de uma solicitação HTTP em variáveis de ambiente com o prefixo HTTP_. Assim, uma aplicação pode consultar o valor dos cabeçalhos da solicitação (como o User-Agent) examinando seu ambiente.

Um cliente pode criar variáveis de ambiente arbitrárias (começando com HTTP_) no ambiente da aplicação enviando requisições com o cabeçalho apropriado. Por exemplo, o cabeçalho da requisição Foo: bar se torna a variável de ambiente HTTP_FOO=bar.

Algumas plataformas fornecem uma camada de abstração que oculta as variáveis de ambiente, como a variável global $_SERVER do PHP. No entanto, essas abstrações são construídas sobre a prática padrão do CGI e do FastCGI de definir variáveis de ambiente.

Por exemplo, ao ser executado no modo FastCGI, um aplicativo PHP pode identificar o cabeçalho User-Agent de uma solicitação da seguinte forma:

// both methods return the same result$useragent = getenv( 'HTTP_USER_AGENT' );
$useragent = $_SERVER['HTTP_USER_AGENT'];

2 – Algumas bibliotecas de aplicativos são configuradas por meio de variáveis de ambiente

Uma aplicação web complexa incorpora funcionalidades de bibliotecas externas. Por exemplo, às vezes as aplicações precisam fazer solicitações HTTP a outros serviços (de forma semelhante a microsserviços) e podem usar uma das bibliotecas comuns de terceiros para isso. Essas bibliotecas geralmente oferecem suporte a um recurso chamado proxy HTTP, que é um servidor intermediário usado para encaminhar a solicitação HTTP.

Uma maneira fácil de configurar uma biblioteca como essa é definir a configuração por meio de variáveis de ambiente. A amplamente utilizada biblioteca PHP Guzzle é configurada, em parte, por uma variável de ambiente chamada HTTP_PROXY, que é definida com o endereço de um servidor proxy. Quando HTTP_PROXY é definida dessa forma, a biblioteca encaminha todas as solicitações HTTP que gera para o endereço do servidor proxy. O pacote net/http do Go e o módulo Requests do Python também confiam na variável de ambiente HTTP_PROXY e a interpretam da mesma forma.

3 – A natureza da vulnerabilidade

As bibliotecas descritas no item 2 não foram projetadas levando em consideração interfaces CGI ou semelhantes a CGI, e a variável de ambiente HTTP_PROXY na qual elas confiam se sobrepõe ao namespace HTTP_ usado pelas interfaces CGI e FastCGI, conforme discutido no item 1.

Ao definir o valor da variável de ambiente HTTP_PROXY como um endereço de sua escolha, os invasores podem redirecionar e capturar solicitações HTTP internas geradas pelo aplicativo. Essas solicitações podem conter informações confidenciais, como chaves de autenticação e dados privados, além de revelar informações sobre APIs e endpoints adicionais que podem ser explorados.

Um invasor pode fazer isso enviando uma solicitação com um cabeçalho Proxy, fazendo com que a interface CGI ou FastCGI crie automaticamente uma variável de ambiente chamada HTTP_PROXY para essa execução da aplicação. Observe que apenas as solicitações que contêm o cabeçalho Proxy fraudulento são diretamente afetadas.

Impedindo o ataque com NGINX e NGINX Plus

A vulnerabilidade HTTPoxy não afeta diretamente o NGINX, mas o NGINX e o NGINX Plus podem ser usados para impedir ataques que exploram essa vulnerabilidade.

Comunicação com uma aplicação FastCGI upstream

Você pode usar o NGINX para “sanitizar” a entrada enviada ao aplicativo definindo o parâmetro FastCGI HTTP_PROXY como uma string vazia. Isso remove completamente o parâmetro da solicitação FastCGI:

fastcgi_param HTTP_PROXY "";

Balanceamento de carga e proxy de tráfego HTTP

Ao encaminhar solicitações HTTP por proxy para uma aplicação upstream, é recomendável definir qualquer cabeçalho Proxy como uma string vazia, caso a aplicação upstream esteja sendo executada em uma plataforma vulnerável:

proxy_set_header Proxy "";

Detectando tentativas de explorar a vulnerabilidade

Proxy não é um cabeçalho HTTP padrão, portanto, qualquer solicitação que contenha esse cabeçalho pode ser considerada suspeita. Você pode usar o NGINX ou o NGINX Plus para registrar essas solicitações suspeitas em um log de acesso dedicado, aqui chamado de badactor.log:

# define 'proxylog' format in the http{} context:log_format proxylog '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" '
                    '"$http_proxy"';

# log requests with a Proxy header using the 'proxylog' format
access_log /var/log/nginx/badactor.log proxylog if=$http_proxy;

Observação: no contexto de configuração em que você inserir esta diretiva access_log, ela substituirá qualquer registro de acesso definido em um nível superior da configuração do NGINX.

Mantenha-se seguro

O NGINX e o NGINX Plus oferecem uma maneira eficaz de monitorar e neutralizar o ataque HTTPoxy. Use as técnicas descritas acima para proteger seu aplicativo enquanto você audita, atualiza e testa seu código para eliminar a vulnerabilidade.

Se tiver alguma dúvida, deixe um comentário nesta publicação – ou, se você for assinante do NGINX Plus, entre em contato com nossa equipe de suporte para obter ajuda.

Sobre o autor

Owen GarrettDiretor Sênior de Gestão de Produtos

Mais publicações de Owen Garrett