BLOG

Ataque de redefinição rápida HTTP/2 impactando produtos F5 NGINX

Publicado em 10 de outubro de 2023

Esta postagem do blog se concentra em uma vulnerabilidade descoberta recentemente relacionada ao protocolo HTTP/2. Sob certas condições, essa vulnerabilidade pode ser explorada para executar um ataque de negação de serviço no NGINX Open Source, NGINX Plus e produtos relacionados que implementam a parte do lado do servidor da especificação HTTP/2. Para proteger seus sistemas desse ataque, recomendamos uma atualização imediata da configuração do NGINX.

O problema com redefinições de fluxo HTTP/2

Depois de estabelecer uma conexão com um servidor, o protocolo HTTP/2 permite que os clientes iniciem fluxos simultâneos para troca de dados. Diferentemente das iterações anteriores do protocolo, se um usuário final decidir sair da página ou interromper a troca de dados por qualquer outro motivo, o HTTP/2 fornece um método para cancelar o fluxo. Ele faz isso emitindo um quadro RST_STREAM para o servidor, evitando que ele execute trabalho desnecessariamente.

A vulnerabilidade é explorada iniciando e cancelando rapidamente um grande número de fluxos HTTP/2 em uma conexão estabelecida, contornando assim o máximo de fluxo simultâneo do servidor. Isso acontece porque os fluxos de entrada são redefinidos mais rapidamente do que os fluxos subsequentes chegam, permitindo que o cliente sobrecarregue o servidor sem nunca atingir seu limite configurado.

Impacto no NGINX

Por motivos de desempenho e consumo de recursos, o NGINX limita o número de fluxos simultâneos a um padrão de 128 (consulte http2_max_concurrent_streams ). Além disso, para equilibrar de forma ideal o desempenho da rede e do servidor, o NGINX permite que o cliente persista conexões HTTP para até 1.000 solicitações por padrão usando um HTTP keepalive (consulte keepalive_requests ).

Ao confiar no limite padrão de keepalive, o NGINX previne esse tipo de ataque. A criação de conexões adicionais para contornar esse limite expõe agentes mal-intencionados por meio de ferramentas de monitoramento e alerta padrão da camada 4.

No entanto, se o NGINX estiver configurado com um keepalive substancialmente maior que a configuração padrão e recomendada, o ataque poderá esgotar os recursos do sistema. Quando ocorre uma redefinição de fluxo, o protocolo HTTP/2 exige que nenhum dado subsequente seja retornado ao cliente naquele fluxo. Normalmente, a redefinição resulta em sobrecarga insignificante do servidor na forma de tarefas que lidam com o cancelamento com elegância. No entanto, contornar o limite de fluxo do NGINX permite que um cliente aproveite essa sobrecarga e a amplifique iniciando rapidamente milhares de fluxos. Isso força a CPU do servidor a atingir picos, negando serviço a clientes legítimos.

Negação de serviço por meio do estabelecimento de fluxos HTTP/2, seguidos por cancelamentos de fluxo sob limites de keepalive anormalmente altos

Passos para mitigar a exposição a ataques

Como um servidor e proxy completo, o NGINX fornece aos administradores ferramentas poderosas para mitigar ataques de negação de serviço. Para aproveitar esses recursos, é essencial que as seguintes atualizações sejam feitas nos arquivos de configuração do NGINX, minimizando a superfície de ataque do servidor:

Também recomendamos que estas medidas de segurança sejam adicionadas como uma prática recomendada:

  • limit_conn impõe um limite no número de conexões permitidas de um único cliente. Esta diretiva deve ser adicionada com uma configuração razoável que equilibre o desempenho e a segurança do aplicativo.
  • limit_req impõe um limite no número de solicitações que serão processadas dentro de um determinado período de tempo de um único cliente. Esta diretiva deve ser adicionada com uma configuração razoável que equilibre o desempenho e a segurança do aplicativo.

Como estamos respondendo

Experimentamos diversas estratégias de mitigação que nos ajudaram a entender como esse ataque poderia impactar nossa ampla gama de clientes e usuários. Embora esta pesquisa tenha confirmado que o NGINX já está equipado com todas as ferramentas necessárias para evitar o ataque, queríamos tomar medidas adicionais para garantir que os usuários que precisam configurar o NGINX além das especificações recomendadas consigam fazê-lo.

Nossa investigação produziu um método para melhorar a resiliência do servidor sob várias formas de ataques de inundação que são teoricamente possíveis no protocolo HTTP/2. Como resultado, lançamos um patch que aumenta a estabilidade do sistema nessas condições. Para se proteger contra tais ameaças, recomendamos que os usuários do NGINX Open Source reconstruam os binários a partir da base de código mais recente e que os clientes do NGINX Plus atualizem para os pacotes mais recentes (R29p1 ou R30p1) imediatamente.

Como o Patch funciona

Para garantir a detecção precoce de ataques de inundação no NGINX, o patch impõe um limite no número de novos fluxos que podem ser introduzidos em um loop de eventos. Este limite é definido como o dobro do valor configurado usando a diretiva http2_max_concurrent_streams . O limite é aplicado mesmo que o limite máximo nunca seja atingido, como quando os fluxos são redefinidos logo após o envio da solicitação (como no caso deste ataque).

Produtos afetados

Esta vulnerabilidade afeta o módulo NGINX HTTP/2 ( ngx_http_v2_module ). Para obter informações sobre seu produto NGINX ou F5 específico que pode ser afetado, visite: https://my.f5.com/manage/s/article/K000137106

Para obter mais informações sobre CVE-2023-44487 - Ataque de redefinição rápida HTTP/2, consulte: https://www.cve.org/CVERecord?id=CVE-2023-44487

Agradecimentos

Gostaríamos de reconhecer a Cloudflare, a Amazon e o Google por sua participação na descoberta e colaboração na identificação e mitigação dessa vulnerabilidade.

Esta postagem do blog foi atualizada com detalhes adicionais de correção e para maior clareza após sua data de publicação original.