Hot Potato: Mais do que uma elevação de privilégio no Windows, um compêndio de falhas bem aproveitadas

terça-feira, 26 de janeiro de 2016

Esquema de funcionamiento de Hot Potato


Há poucos dias se tornou pública uma elevação dos privilégios, previamente desconhecido e com prova pública de conceito em todas as versões de Windows. Este é um caso especial porque consegue elevação de privilégios através de um compêndio de falhas de projeto do Windows, além de "abrir a porta" a um novo tipo de ataque. Veja os detalhes e como podemos tentar combatê-la.

Três ataques em um

Isso acontece de vez em quando. Uma prova de conceito é publicada para elevar privilégios sem nenhum patch aplicado. A verdadeira dor de cabeça para um administrador de rede se você quiser mantê-la sob controle. Sem ser muito rigoroso, nos veio a cabeça que no final de 2014 ocorreram várias vezes seguidas afetando o Windows e uma mais uma em agosto de 2015. No kernel Linux, o mais recente ocorreu em março de 2015. Mas este caso é especial, porque na realidade é uma combinação de falhas com base em outros históricos conhecidos e um mais moderno dos mencionados em 2014.

Esta última frase (de https://code.google.com/p/google-security-research/issues/detail?id=222) parece que foi a ideia...

NTLM é um protocolo de autenticação inventado pela Microsoft que tem duas versões. O primeiro está obsoleta e desatualizada e tem um problema de reflexão ou de "pass the hash", que trouxe Microsoft dores de cabeça desde que foi descoberto faz alguns anos. Se trata de que alguém tente autenticar com o equipamento do atacante por NTLM, que a informação se faça passar pela vítima ainda que a senha não seja conhecida. Antes se podia aproveitar para passar os hashes para a própria máquina, mas foi mitigado com o patch MS08-068. Uma vez que eles não poderiam usar a autenticação (desafio) que estavam sendo usados nesse momento. Este foi um pequeno golpe para os atacantes, mas o patch jamais impediu ataques entre protocolos. Em outras palavras, a autenticação de WebDAV para SMB (como fizeram no Google) ou de HTTP para SMB, como tem sido feito agora.


A coisa interessante sobre a batata quente é o uso combinado de falhas que são provavelmente nunca serão corrigidos ou que vai custar para serem consertadas, será muito complicado no Windows por conta da compatibilidade. Três tipos de ataques são usados, vejamos:

Falsificar NBNS

Quando um nome ou domínio não responde por DNS ou por resolução direta do arquivo host, ele pede para outros sistemas na rede, através do protocolo de NBNS, questionando quem conhece o IP de que se está buscando. O ataque faz com que seja sempre responda a todos os processos do próprio equipamento (127.0.0.1) para todas as perguntas. Mas eles não se importam se ele não responder com a mesma ID que foi perguntado, então ele responde a todos com o ID gerado pela força bruta (eles são apenas 65536 valores). Como vai por UDP, é rápido e eficaz. E se não for solicitado por NBNS por que ele resolve para DNS? No computador, você pode monopolizar todas as portas UDP. Com eles responde se ao DNS e se não houver livre, o DNS não funciona ... então NBNS vai ser usado como uma tentativa desesperada.

Embora ele não tenha nada a ver com este ataque em particular, o criador deixa a porta aberta a um ataque à internet NBNS (se a vítima tenha a porta UDP 137 aberta, é claro!).

Un WPAD falso

Por outro lado, temos um outro ataque já conhecido. O Windows tenta automaticamente para lhe dizer que proxy deve usar. Ou seja, se espera que um sistema com nome "WPAD" para resolver, conectar e dar a configuração (um arquivo .dat). Eles fazem inclusive serviços essenciais do Windows.

Com esta opção marcada, o computador irá buscar sempre um WPAD
 
Agora, usando o ataque NBNS já descrito, é dito ao equipamento que o wpad esta em 127.0.0.1. E é devolvido .DAT (se configura o proxy ) também com 127.0.0.1. Em que consiste? Que a máquina de destino se converta no seu próprio proxy local e, portanto, observar o seu tráfego. E, para todos os usuários do computador aparecerá que o proxy é 127.0.0.1.

O ataque, abre proxies locais para todos os processos

Levando a autenticação NTLM de HTTP para SMB

Esta é a parte que é uma novidade (embora a ideia tenha sido por conta do Google). O path anteriormente mencionado, MS08-068, corrigiu um ataque típico, mas não a causa raiz do problema. Ninguém conseguiu parar o ataque NTLM entre os protocolos. Se são capturadas as credenciais NTLM através de HTTP e são encaminhadas a um processo SMB do computador, podemos enviar mensagens que serão executados como SYSTEM, porque eles parecem autenticado. Veja aqui a elevação.

O ataque em ação, um usuário comum é adicionado ao grupo de administradores

Agora só precisamos esperar uma solicitação HTTP gerada a partir de um serviço com alto privilegio tentando autenticar por NTLM em algum lugar. Como temos um proxy HTTP no seu computador, capturamos as credenciais e injetamos um comando. Tudo é enviado para o serviço que escuta o SMB interno. Lá está, o comando será lançado com privilégios máximos. Quais os serviços geram solicitações HTTP autenticadas com NTLM privilegiado? Windows Update, ou Windows Defender ... O ataque aqui varia de versão para versão, mas é bastante confiável.

Poderá ser corrigida? Como? O que a Microsoft tem que fazer agora?

Normalmente, uma falha de elevação de privilégio ocorre em algum ponto do sistema por má programação (buffer overflow, configuração inadequada ...). Corrigindo esta parte, a porta é fechada. Mas este problema é especial porque três problemas conhecidos há anos e nunca foram eliminados, alias a experiência nos diz que a Microsoft trabalha de forma lenta para eliminar as elevações de privilégio.

O mais provável é que a Microsoft se veja obrigada a corrigir de alguma forma utilizando hashes NTLM (com desafios em uso) que variam de protocolo para protocolo. Corrigiram o problema "canônica" de “pass the hash” evitando que o servidor SMB envie ao próprio servidor SMB, mas agora afeta a outros protocolos. Fato: O patch foi emitido em 2008 e o problema era conhecido desde 2000. Haviam formas de mitigar-los, mas o ataque existiu por oito anos. E agora, será que vai demorar muito? Outro fato: A elevação de privilégios mencionado no início do artigo e trazidas à luz pelo Google, foram relatados em público porque a Microsoft não corrigiu no prazo de 90 dias, um período de cortesia concedidos aos fabricantes. De qualquer modo, parece que se fechar qualquer uma das portas, abrirão outras formas de combinar outros métodos em um futuro próximo.

O que deve o administrador fazer?

Você não pode ficar à espera do patch. Como qualquer falha pode (e deve) atacar o problema de várias frentes. Aqui estão algumas dicas. Aviso: há muito a fazer, e se não forem feitas corretamente, poderá ser problemático:
  • Para o ataque NBNS: Identificar mal formados ou "floods" deste tipo de pacotes na rede. Existem programas específicos e também os IDS deveriam detectá-los. Tendo registros de DNS para todos os nomes de NetBIOS e evitar resolução. Especialmente para WPAD ou WPAD.dominio.
  • Contra o ataque WPAD, impedir que o Windows localize este arquivo. Parar o serviço "Detecção automática WinHTTP Web Proxy" em computadores e impedir que o Internet Explorer o procurem. By the way, um truque pode ser incorporado WPAD no arquivo de hosts, e configurá-lo para qualquer valor.
  • Forçar o uso de NTLMv2
  • Contra a autenticação NTLM. Forçar o uso de Kerberos e NTLMv2 (se você tiver o equipamento relativamente moderno) e aplicar esta melhoria publicado pela Microsoft há algum tempo. Além disso, a assinatura SMB todas as comunicações.

Opções de segurança relacionadas com a assinatura de comunicações SMB
Mas são parâmetros muito sensíveis, se você tem o equipamento antigo na rede. Você pode quebrar as coisas.
 
E, em geral, para usar o firewall de saída para impedir que qualquer programa desconhecido acesse à rede. Evite executar programas de usuários desconhecidos.... como de costume.
Finalmente, note que é engraçado como esta prova de conceito não está sendo detectado pelo antivírus imediatamente. Embora seja inútil, muitas vezes, detectar rapidamente esses binários para evitar o primeiro ataque de invasores que tentam lançar como é o binário.


Sergio de los Santos
ssantos@11paths.com


tradução por Leandro Bennaton
Leandro.bennaton@11paths.com

Nenhum comentário:

Postar um comentário