HTTP Wormable do Windows – o que você precisa saber

HTTP Wormable do Windows – o que você precisa saber. A primeira Patch Tuesday de 2022 trouxe mais de 100 bugs de segurança corrigidos.

Para o bem ou para o mal, uma atualização chamou a atenção da mídia mais do que qualquer outra, a saber, CVE-2022-21907 , mais conhecida como Vulnerabilidade de Execução Remota de Código de Pilha de Protocolo HTTP .

Este bug foi uma das sete falhas de segurança deste mês que podem levar à execução remota de código (RCE), o tipo de bug que significa que alguém fora de sua rede pode enganar um computador dentro de sua rede para executar algum tipo de programa sem pedir permissão primeiro .

Não há necessidade de fazer login; nenhum aviso pop-up no endpoint;  sem perguntas Are you sure (Y/N)?

Basta dar a ordem e o malware é executado.

Essa é a teoria, de qualquer maneira.

Bugs RCE considerados wormable

Uma coisa a ser lembrada sobre a maioria das vulnerabilidades RCE é que, se você puder atacar o computador de outra pessoa de fora e instruí-lo a executar um programa malicioso de sua escolha…

…então é possível, talvez até provável, que você possa dizer a ele para executar o mesmo programa que você acabou de usar para lançar seu próprio ataque.

Em outras palavras, você pode usar a vulnerabilidade para localizar e infectar a Vítima 1 com o programa malicioso W que instrui a Vítima 1 a localizar e infectar a Vítima 2 com o programa malicioso W que instrui a Vítima 2 a localizar e infectar a Vítima 3… e assim por diante , talvez até ao infinito.

Em um ataque como este, damos ao programa W um nome especial: chamamos de worm .

Os worms formam um subconjunto adequado de um tipo de software malicioso (ou malware para abreviar) conhecido geralmente como vírus de computador , o termo abrangente para malware auto-replicante de qualquer tipo.

Isso significa que a maioria dos bugs RCE são, pelo menos em teoria, passíveis de worm , o que significa que eles podem ser explorados para iniciar uma cadeia de infecções de malware automáticas, auto-difundidas e auto-sustentáveis.

O raciocínio aqui é óbvio: se um bug do RCE permite que você execute um programa arbitrário de sua escolha no computador de outra pessoa, como pop-up CALC.EXEou launching NOTEPAD, então é quase certo que ele permite que você execute um programa específico de sua escolha, como um worm.

Alguns bugs são mais wormable ​​do que outros

Como você pode imaginar, algumas classes de bugs RCE são consideradas muito mais wormable do que outras, especialmente bugs que podem ser acionados diretamente por meio de uma simples interação de rede.

Esse foi um risco de preocupação considerável na recente saga Log4Shell , onde uma única solicitação da Web com armadilhas com algum texto ASCII curioso, mas de outra forma imperceptível, poderia desencadear a execução remota de código arbitrário.

Infelizmente, o CVE-2022-21907 é um bug na mesma categoria, com o próprio boletim de segurança da Microsoft dizendo explicitamente o seguinte em sua seção de perguntas frequentes:

*Como um invasor pode explorar essa vulnerabilidade?*

Na maioria das situações, um invasor não autenticado pode enviar um pacote especialmente criado para um servidor de destino utilizando o HTTP Protocol Stack (HTTP.sys) para processar pacotes.

*Isso é wormable?*

?*  sim. A Microsoft recomenda priorizar o patch dos servidores afetados.

Isso tem alguma coisa a ver com o IIS?

Onde e como o HTTP Protocol Stack é ativado?

Esse é um problema exclusivo dos servidores Windows, como o boletim da Microsoft sugere quando fala sobre a correção de “servidores afetados”?

O ataque depende de você ter um servidor web conhecido como o Microsoft IIS ( Internet Information Services ) já instalado e ativado?

As respostas a estas perguntas são as seguintes:

• HTTP.sys faz parte do Windows e está disponível para qualquer programa que use ASP.NET.
• HTTP.sys funciona em clientes Windows 7 e posteriores.
• HTTP.sys funciona em servidores Windows 2008 R2 e posteriores.
• HTTP.sys não faz parte do IIS e não requer a instalação do IIS.

O último ponto acima deixa claro que você pode ter qualquer número de aplicativos em uso – talvez sem perceber – que fornecem uma interface baseada em HTTP via HTTP.sys, tenha você implantado o IIS ou não.

Na verdade, a própria documentação da Microsoft observa que “HTTP.sys é útil […] onde há a necessidade de expor o servidor diretamente à Internet sem usar o IIS”.

De fato, o IIS é baseado em HTTP.sys, e não o contrário, como a Microsoft explica:

HTTP.sys é uma tecnologia madura que protege contra vários tipos de ataques e fornece a robustez, segurança e escalabilidade de um servidor web completo. O próprio IIS é executado como um ouvinte HTTP sobre HTTP.sys.

Simplificando: você poderia, em teoria, ter aplicativos instalados, mesmo em um computador desktop ou laptop, que fornecem algum tipo de interface baseada na web que é atendida pelo código do driver HTTP.sys.

O lado positivo, pelo menos para alguns usuários, é que a parte do HTTP.sys que contém o bug CVE-2022-21907:

• Afeta apenas o Windows 10 e versões de desktop posteriores.
• Afeta apenas o Windows Server 2019 e versões de servidor posteriores.
• Não está habilitado por padrão no Windows Server 2019.
• Pode ser imunizado contra esse bug simplesmente instalando as atualizações do Patch Tuesday de janeiro de 2022.

Até onde sabemos, a razão pela qual essa vulnerabilidade não está presente em versões anteriores do Windows e do Windows Server é que o bug foi encontrado no código que trata dos trailers HTTP (são como cabeçalhos HTTP, exceto que são enviados após os dados HTTP em vez de antes); O suporte ao HTTP Trailer só foi adicionado após o suporte ao HTTP/2; e suporte HTTP/2 só chegaram na era do Windows 10.

O que fazer?

Se você realmente não conseguir corrigir imediatamente e souber que não está executando (ou pelo menos não pretende executar) nenhum software baseado na Web que use HTTP.sys, poderá bloquear temporariamente o HTTP.sys em seu computador definindo a seguinte entrada de registro:

HKLM\SYSTEM\CurrentControlSet\Service\HTTP\Start = DWORD(4)

O valor usual desta entrada de registro é 3, denotando “iniciar sob demanda” ; alterar o valor para 4 marca o driver como “serviço desativado” .

Após uma reinicialização, você pode verificar o status de HTTP.sys em um prompt de comando regular com o comando SC(Service Control):

C:\Users\duck> sc query HTTP
SERVICE_NAME: HTTP 
   TIPO: 1 KERNEL_DRIVER  
   ESTADO: 1 PARADO <--antes de aplicar o hack de registro acima, esta linha dizia: "4 RUNNING"
   WIN32_EXIT_CODE: 1077 (0x435)
   SERVICE_EXIT_CODE: 0 (0x0)
   PONTO DE VERIFICAÇÃO: 0x0
   WAIT_HINT: 0x0
C:\Usuários\pato>

O autor, Paul Ducklin, ao publicar no blog da Sophos, observou que testaram essa solução alternativa apenas da maneira mais superficial. Instalaram o Server 2022, habilitamos o IIS, criaram uma home page e verificaram em outro computador que funcionou. Alteraram o valor inicial do serviço para HTTP para 4, conforme sugerido acima, e reinicializaram. O servidor IIS não estava mais acessível. Reverteram a entrada do registro para 3, reinicializaram mais uma vez e verificaram que o IIS voltou à vida automaticamente. A partir disso, inferiram que desabilitar o serviço HTTP de fato bloqueia o acesso à rede baseada em HTTP para software de nível superior que poderia ser exposto a esse bug, e assumiram então que isso torna a vulnerabilidade temporariamente “não ativável”.

As principais recomendações são:

• Suponha que todas as vulnerabilidades do RCE sejam passíveis de worm. Como mencionado, os bugs que podem ser acionados diretamente por meio de conexões de rede de rotina representam de longe o maior risco de “ser wormed”, mas, em teoria, qualquer bug que permita a execução remota de código arbitrário pode permitir a execução de código worm.
• Suponha que os cibercriminosos já estejam investigando ativamente essa e todas as outras vulnerabilidades RCE anunciadas na patch tuesday. Você provavelmente já ouviu a piada sobre o Patch Tuesday ser seguido pelo Exploit Wednesday. Há mais do que um toque de verdade nisso, já que até mesmo patches de código fechado podem ser frequentemente manipulados para trás – engenharia reversa , no jargão – para revelar os detalhes internos do bug que eles evitam. 
• Corrija cedo, corrija com frequência. Não use soluções alternativas como parte rotineira do seu processo de correção para ganhar tempo extra sempre. Aplique o patch o mais rápido possível e mantenha soluções alternativas para situações em que você realmente precisa atrasar o patch por um tempo. 

Fonte: Sophos

Veja também:

• Kali Linux Cheat Sheet, saiba mais sobre os utilitários do pacote
• Livro infantil promove a cibersegurança dos pequenos exploradores virtuais
• Bug do Safari vaza informações da sua conta do Google
• Principais ferramentas de segurança cibernética de código aberto
• Inteligência artificial e cibersegurança se tornam diferenciais também para o agronegócio
• Informações da ômicron são usadas como isca para roubar dados digitais em 12 países
• Organizações enfrenta desafios na implementação de estratégias Zero Trust
• Ransomware continua sendo a maior ameaça virtual em 2022
• Estrutura de segurança cibernética do NIST
• França multa Google e Facebook em € 210 milhões
• WebSpec revela novo ataque de cookie
• Patches do VMware corrige falha dos produtos ESXi, Workstation e Fusion