Originalmente publicado em 29 de setembro de 2023 | Atualizado em 10 de outubro de 2023
Por: Dave Andrews, Marcus Hildum, Sergio Ruiz
Atualização: HTTP/2 Rapid Reset Attack – CVE-2023-44487
Após o breve blog inicial abaixo, Edgio se envolveu com colegas de todo o setor na definição e divulgação responsável do CVE-2023-44487 – HTTP/2 Rapid Reset Attack.
O problema subjacente afeta muitas implementações de servidores HTTP/2, o que torna as implicações do ataque muito mais amplas do que Edgio já percebeu. O Edgio aconselha todos os clientes que executam infraestrutura pública a atualizar para versões corrigidas de seus servidores assim que estiverem disponíveis e/ou desativarem temporariamente o HTTP/2.
O Edgio também está disponível para ajudar a mitigar o risco para os nossos clientes através da execução da terminação HTTP/2 e do proxy HTTP/1,1 de volta à infraestrutura dos clientes. Entre em contato conosco para iniciar este processo.
Em 28 de agosto de 2023 às 6:43 horas, PST, os engenheiros da Edgio observaram um aumento na utilização da memória em nossos servidores de borda, taxas de solicitação para várias grandes propriedades da web e o volume de logs sendo gerados na borda.
O tráfego, logo identificado como um ataque, era novo porque só era observável nos logs do nosso balanceador de carga de camada 7. O Edgio executa nosso mecanismo personalizado de cache e proxy HTTP, Sailfish, como nosso balanceador de carga de camada 7 (que chamamos de frontend), e nossa camada de cache e proxy (o “backend”). Isso permite instrumentação e registro comuns em ambas as camadas, tornando as comparações entre elas triviais.
Quando cavamos nos logs do frontend, observamos alguns comportamentos interessantes indicando um ataque:
- A contagem de solicitações para clientes individuais foi muito maior do que o habitual: Durante o ataque vimos instâncias de mais de 20 000 solicitações em um único soquete.
- Nenhum bytes estava sendo enviado para clientes.
- O tempo total de solicitação, do início ao fim, foi entre 1 e 2 milissegundos, tudo gasto iniciando uma nova conexão proxy com os backends.
- Todas as conexões que exibem o comportamento eram conexões HTTP/2.
Com base nessas observações iniciais, teorizamos que o invasor estava abandonando as solicitações usando o quadro RST_STREAM do HTTP/2 e iniciando novas solicitações no mesmo soquete, muito rapidamente.
Depois disso, dividimos nossos esforços em três fluxos de trabalho distintos:
- Investigando quaisquer problemas potenciais que afetem a biblioteca HTTP/2 que usamos, ngttp2, que possam provar a causa raiz.
- Construir variáveis de Sailfish para expor os fundamentos desse comportamento para permitir mitigações.
- Criar novas métricas, painéis e alertas para identificar esse tipo de ataque mais rapidamente.
1. Enviado… mas realmente nghtp2
Depois de uma pequena pesquisa, encontramos neste problema Envoy, um proxy de serviço que o Edgio não utiliza na borda, e o CVE correspondente. Após uma revisão mais profunda do diff, percebemos que esta questão não era apenas em Envoy, mas na verdade em ngtp2, que nós usamos.
Uma solicitação pull e liberação de tag point para ngttp2 foram lançadas logo após a divulgação, abordando o problema subjacente. A falta de um CVE específico alocado em relação ao ngtp2 significava que nosso sistema automatizado de verificação CVE, que usamos para rastrear vulnerabilidades no software-chave que utilizamos, perdeu o problema originalmente.
Iniciamos imediatamente o processo para atualizar essa dependência e implantá-la, que foi concluído há algumas semanas.
2. Percentagem de reposição do pedido
Em paralelo, trabalhamos para identificar o comportamento de ataque programaticamente, dentro da própria Sailfish, a fim de poder agir imediatamente para evitar problemas de desempenho ou confiabilidade. Decidimos implementar uma variável de configuração (h2_remote_reset_percent) dentro do Sailfish, que rastrearia a porcentagem de solicitações em uma determinada conexão que foi redefinida pelo cliente.
A adição, em conjunto com uma variável existente para a contagem de solicitações em uma única conexão, nos permitiu criar uma regra que fecharia imediatamente uma conexão com um cliente que havia excedido um limite de solicitação e redefinia mais do que uma porcentagem configurada de solicitações. Nós envolvemos essa configuração em cofres de falha operacionais normais, que nos permitem desativá-la para locais ou clientes específicos.
Em pseudocode isso se parece com:
if request_count > 1000 and
h2_remote_reset_percent > 99 and
pop ~ ".*" and
customer_id not in () then
connection.silent_close();
fi
Após uma validação cuidadosa para evitar qualquer impactos não intencional no tráfego de nossos clientes, a nova regra foi implementada e os engenheiros da Edgio continuaram a monitorar quaisquer anomalias adicionais.
3. Contagens e rácios
A fim de identificar mais rapidamente quando ataques desse tipo estão ocorrendo, configuramos um novo painel e alerta com base na contagem de quadros HTTP/2 RST_STREAM recebidos de clientes, em um local. Isso, aliado a uma visão singular da disponibilidade de memória e verificações de saúde, nos deu um sinal claro de potencial degradação devido a esse tipo específico de ataque:
No entanto, permanecemos preocupados com outros tipos de ataque potenciais que podem afetar apenas as frontends especificamente. Para dar visibilidade a essa preocupação mais geral, começamos a rastrear a proporção da taxa de transação entre frontends e backends em um determinado local. Os dados subjacentes para esta comparação têm sido uma parte essencial do nosso monitoramento por muito tempo.
Olhando para o comportamento normal, você pode ver a faixa forte em torno de 1, a proporção esperada, como cada solicitação que chega a um front-end se traduz em uma única solicitação de back-end. Também é visível a faixa mais próxima de 0,5 e 0,25, que ocorrem principalmente em locais de teste inativos, onde sistemas como purga e verificação de integridade fazem com que mais transações internas sejam processadas por backends:
No entanto, durante o ataque inicial, você pode ver claramente o efeito sobre essa proporção:
Nosso alerta atual é configurado para disparar quando a relação excede um determinado valor, criando um incidente para engenheiros de suporte do Edgio para triagem e iniciar etapas de mitigação.
Resumo
Este foi um novo tipo de ataque interessante, aproveitando uma vulnerabilidade relativamente divulgada recentemente em uma biblioteca amplamente utilizada. Felizmente, a equipe do Edgio trabalhou rapidamente para melhorar nossa consciência operacional, mitigar a causa raiz específica do ataque, bem como colocar em mitigações genéricas e ajustáveis de propósito geral para esta classe de ataque.
Claro, estamos sempre trabalhando em melhorias como essa, como novas formas de identificar os maus atores por meio da impressão digital, bem como integrar esse trabalho em nosso conjunto de produtos de segurança para permitir bloqueio e limitação de taxa mais persistentes.
Nunca um momento aborrecido no Edgio.
Para saber mais sobre nossa Proteção DDoS de espetro completo, parte da premiada solução de Proteção de Aplicativos Web e API (WAAP) da Edgio, entre em contato com nossos especialistas aqui.
