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.
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.
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.
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:
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.
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).
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
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.