Mitigando a vulnerabilidade HTTPoxy com NGINX

Em 18 de julho de 2016, uma vulnerabilidade chamada ‘HTTPoxy’ foi anunciada, afetando alguns aplicativos da web do lado do servidor que são executados em ambientes CGI ou semelhantes a CGI, como algumas configurações FastCGI. As linguagens que foram afetadas até agora incluem PHP, Python e Go.

Vários CVEs foram atribuídos, abrangendo linguagens específicas e implementações CGI:

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

Há um novo site descrevendo a vulnerabilidade , uma nota de vulnerabilidade do CERT e uma descrição da descoberta da vulnerabilidade . Há informações adicionais no site pessoal de Dominic Scheirlinck , um desenvolvedor web de código aberto na Vend.

Esta postagem descreve a vulnerabilidade e explica como usar o NGINX ou o NGINX Plus para derrotar tentativas de exploração em seus servidores.

A vulnerabilidade existe devido a um conflito de namespace. Uma interface semelhante a CGI ou FastCGI define variáveis de ambiente com base em parâmetros de solicitação HTTP, e estas podem substituir variáveis internas usadas para configurar o aplicativo.

Atualmente, a única exploração conhecida dessa vulnerabilidade é em aplicativos da web executados 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 solicitações internas geradas pelo aplicativo para um servidor de sua escolha e, assim, capturar quaisquer dados secretos contidos nas solicitações, conforme mostrado abaixo.

Você pode usar o NGINX ou o NGINX Plus para identificar e derrotar tentativas de exploração dessa vulnerabilidade. Fazer isso fornece uma maneira eficaz de prevenir qualquer ataque, dando a você tempo para auditar e atualizar qualquer código afetado.

Como a vulnerabilidade HTTPoxy é explorada

Entender como essa vulnerabilidade funciona – e como proteger seu site contra ela – requer uma compreensão de 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 denominadas HTTP_*

Muitas plataformas de aplicativos web usam interfaces CGI ou semelhantes a CGI para conectar aplicativos a um servidor web. Essas interfaces convertem os cabeçalhos de uma solicitação HTTP em variáveis de ambiente prefixadas com HTTP_ . Um aplicativo pode então procurar o valor dos cabeçalhos de solicitação (como o User-Agent ) inspecionando seu ambiente.

Um cliente pode criar variáveis de ambiente arbitrárias (começando com HTTP_ ) no ambiente do aplicativo enviando solicitações com o cabeçalho apropriado. Por exemplo, o cabeçalho da solicitaçã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 de CGI e FastCGI de definir variáveis de ambiente.

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

// ambos os métodos retornam o mesmo resultado$useragent = getenv( 'HTTP_USER_AGENT' );
$useragent = $_SERVER['HTTP_USER_AGENT'];

2 – Algumas bibliotecas de aplicativos são configuradas a partir de variáveis de ambiente

Um aplicativo web complexo extrai funcionalidades de bibliotecas externas. Por exemplo, às vezes os aplicativos precisam fazer solicitações HTTP para outros serviços (como microsserviços) e podem usar uma das bibliotecas comuns de terceiros para fazer isso. Essas bibliotecas geralmente oferecem suporte a um recurso chamado Proxy HTTP , que é um servidor intermediário usado para retransmitir 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 biblioteca PHP Guzzle amplamente utilizada é configurada em parte por uma variável de ambiente chamada HTTP_PROXY , que é definida como o endereço de um servidor proxy. Se HTTP_PROXY for definido dessa forma, a biblioteca retransmitirá todas as solicitações HTTP geradas para o endereço do servidor proxy. O pacote net/http do Go e o módulo Requests do Python também confiam e interpretam a variável de ambiente HTTP_PROXY da mesma maneira.

3 – A Natureza da Vulnerabilidade

As bibliotecas descritas no item 2 não foram projetadas com interfaces CGI ou semelhantes a CGI em mente, 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 para 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, e podem 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 , e a interface CGI ou FastCGI obedientemente cria uma variável de ambiente chamada HTTP_PROXY para essa invocação do aplicativo. Observe que apenas solicitações que contêm o cabeçalho Proxy falso são diretamente afetadas.

Derrotando o ataque usando NGINX e NGINX Plus

A vulnerabilidade HTTPoxy não afeta diretamente o NGINX, mas o NGINX e o NGINX Plus podem ser usados para interromper ataques baseados nessa vulnerabilidade.

Conversando com um aplicativo FastCGI upstream

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

fastcgi_param HTTP_PROXY "";

Balanceamento de carga e proxy de tráfego HTTP

Ao fazer proxy de solicitações HTTP para um aplicativo upstream, é aconselhável definir qualquer cabeçalho Proxy como uma string vazia, caso o aplicativo upstream esteja sendo executado em uma plataforma vulnerável:

proxy_set_header Proxy "";

Detectando tentativas de exploração da 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 badactor.log :

# define o formato 'proxylog' no contexto http{}:log_format proxylog '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$http_proxy"';

# registra solicitações com um cabeçalho Proxy usando o formato 'proxylog'
access_log /var/log/nginx/badactor.log proxylog if=$http_proxy;

Observação : No contexto de configuração onde você coloca esta diretiva access_log , ela substitui qualquer registro de acesso definido em um nível mais alto na configuração do NGINX.

Fique seguro

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

Caso tenha alguma dúvida, comente nesta postagem ou, se você for assinante do NGINX Plus, não hesite em entrar em contato com nossa equipe de suporte para obter assistência.