.NET and Visual Studio Denial of Service Vulnerability

Falha de negação de serviço no Kestrel, o servidor web embutido do ASP.NET Core, explorável por ataques de "slow read" — conexões que mantêm o envio ou consumo de dados extremamente lentos para esgotar recursos do servidor. Afeta .NET 6.0, .NET 7.0, ASP.NET Core 2.1 e as versões do Visual Studio 2022 que empacotam esses SDKs. Está no catálogo KEV da CISA com confirmação de exploração ativa, mas o impacto é limitado a disponibilidade — não há comprometimento de confidencialidade ou integridade.

O problema fica no Kestrel, o servidor HTTP nativo do ASP.NET Core usado tanto em produção quanto embutido no IIS via módulo de proxy reverso. A classe de falha é consumo de recursos não controlado (CWE-400): um cliente que envia ou lê dados de uma requisição/resposta de forma anormalmente lenta consegue manter conexões e threads do Kestrel ocupadas por muito mais tempo do que o esperado, degradando a capacidade do servidor de atender novas conexões — o padrão clássico de ataques do tipo Slowloris, adaptado ao pipeline de processamento de requisições do Kestrel.

O atacante não precisa controlar nenhum parâmetro de aplicação específico: o vetor é a própria camada de transporte HTTP, então qualquer serviço ASP.NET Core exposto que use Kestrel (diretamente ou atrás de um proxy que não normaliza o comportamento de conexões lentas) está potencialmente exposto, independente da lógica de negócio da aplicação.

A Microsoft não publicou detalhes de código-fonte ou commit específico nas fontes analisadas aqui; a caracterização mais precisa disponível vem dos bugs internos referenciados pelos advisories do Fedora, que descrevem o problema exatamente como 'Kestrel vulnerability to slow read attacks leading to Denial of Service attack'. O advisory oficial da MSRC trata o texto público como genérico ('.NET and Visual Studio Denial of Service Vulnerability'), sem detalhar o mecanismo — reforçando que a fonte mais concreta sobre a mecânica exata é o rastreamento de bug do Red Hat/Fedora, não a descrição do fornecedor.

O vetor é de rede (AV:N), sem necessidade de autenticação ou interação do usuário (PR:N, UI:N), e com baixa complexidade de ataque (AC:L) — qualquer cliente capaz de abrir conexões TCP contra um endpoint Kestrel exposto pode tentar a exploração. Não há indicação, nas fontes analisadas, de que a falha dependa de configuração não padrão do Kestrel ou de features específicas habilitadas na aplicação; o requisito prático é apenas que o serviço rode sobre uma versão vulnerável do runtime .NET e aceite conexões HTTP.

O resultado da exploração é indisponibilidade do serviço (C:N/I:N/A:H no vetor CVSS): o atacante não lê nem altera dados, apenas degrada ou interrompe a capacidade do servidor de responder a requisições legítimas, provavelmente por esgotamento de conexões/threads mantidas artificialmente abertas.

O CVE está no catálogo KEV da CISA desde 09/08/2023, o que confirma exploração observada em ambiente real, mas a entrada da CISA não detalha campanha, ator ou contexto de uso — o campo 'Known To Be Used in Ransomware Campaigns' está marcado como 'Unknown'. Não há writeup técnico público detalhado disponível nas fontes consultadas sobre a exploração real, apenas a confirmação de uso ativo.

A correção definitiva é atualizar o runtime/SDK .NET para as versões corrigidas: .NET 7 Runtime 7.0.10 / SDK 7.0.110, e .NET 6 Runtime 6.0.21 / SDK 6.0.121 — confirmado pelos advisories de agosto de 2023 do Fedora para os pacotes dotnet6.0 e dotnet7.0. Para quem usa Visual Studio 2022 (17.2, 17.4 ou 17.6), a atualização correspondente do Visual Studio traz o SDK corrigido embutido; o número exato de build do VS que resolve a falha não está confirmado nas fontes analisadas aqui — consulte o Release Notes/Update History do Visual Studio 2022 para a versão específica.

Para ASP.NET Core 2.1, listado como afetado pela Microsoft, não há nas fontes consultadas uma versão de correção específica documentada — essa branch está fora do ciclo de suporte padrão, e organizações que ainda a operam sob suporte estendido devem confirmar o patch aplicável diretamente com o canal de suporte da Microsoft.

Se a atualização imediata não for viável, não há mitigação de configuração confirmada nas fontes lidas que neutralize completamente o problema — reduzir timeouts de conexão e limites de taxa mínima de dados no Kestrel é hardening genérico contra ataques de conexão lenta, mas não substitui o patch, já que a falha em si está na forma como o Kestrel processa esse tipo de tráfego, não em uma configuração exposta pelo operador. Colocar o serviço atrás de um proxy/WAF com timeouts agressivos e limites de conexões concorrentes por IP reduz a superfície de exposição, mas é controle compensatório, não correção.

Como o vetor é de rede e o ataque se caracteriza por padrão de conexão lenta (estilo Slowloris), o sinal a procurar é volume anormal de conexões HTTP de longa duração com taxa de transferência de dados muito abaixo do normal, especialmente múltiplas conexões desse tipo originadas do mesmo IP ou faixa de IPs, seguidas de degradação de latência ou esgotamento do pool de threads/conexões do Kestrel. Não há assinatura ou indicador de comprometimento específico publicado pela Microsoft ou pelos advisories consultados; a detecção depende de monitoramento de métricas de conexão e desempenho do próprio Kestrel/ASP.NET Core, não de um payload identificável em log de aplicação.