Antes do Windows Vista, a imensa maioria dos usuários no Windows utilizava o perfil de administrador para executar qualquer tarefa. O malware não precisava se preocupar com a elevação de privilégios, salvo em sistemas de empresas sob um Active Directory, por exemplo. Com o Vista se introduziu o conceito de UAC, uma espécie de usuário que tem por padrão uma espécie de dupla personalidade (usuário e administrador) e que se comporta sempre como usuário exceto quando se concedo o privilégio passando pelo UAC. A princípio os ransomware não necessitavam de privilégios para criptografar, mas agora, quando querem apagar as copias de segurança ou ser ainda mais persistentes no sistema, devem de elevar seus privilégios e assim fazem. Mas como? Existem três formas diferentes de se realizar, vejamos algumas.

É necessário esclarecer que existem “dois tipos de possíveis de elevação”. O usuário por padrão no Windows já é um administrado e, neste caso o malware ou atacante o que quer, especificamente, é enganar o UAC, isto é, evitar que apareça a solicitação de credenciais. “Elevar privilégios” da forma mais pura, se trata de conseguir que um usuário sem privilégios, consiga realizar tudo aquilo que um administrado por fazer, sem o UAC de intermediário. Às vezes é possível realizar desta forma, outras vezes o malware simula uma solicitação real, segundo sua sofisticação, tentar uma ou outra aproximação.

Um, iludindo o UAC – a forma “clássica”

O Windows Vista foi um sistema operacional falido para a Microsoft, talvez pela quantidade de mudanças em um ambiente pouco maduro para os usuários com pouca experiência. Uma das queixas mais frequentes era o uso do UAC e a continua confirmação de ações, que iriam se realizar como administrado. No Windows 7 este problema foi corrigido com a introdução do “auto elevação de privilégios” para certos programas do próprio Windows. Não se pedia confirmação para estes programas (dado que os consideravam de confiança) e assim o usuário notava menos a necessidade de interação através deste auto elevação. A final um erro pois, não tardou muito para se abrir uma porta (que segue aberta) para enganar o UAC.

Mas, o que importa que um usuário/administrador possa enganar o UAC? Ele já não é um administrador? Para que elevar? Pois por exemplo para que o malware apague suas “shadow copies” sem que o usuário se dê conta disso. Mesmo assim não são muitos os ransomware que utilizam esta técnica.

Está prova de conceito continua a ser válida.

Pouco depois liberou-se uma prova de conceito que permite aproveitar a auto elevação de certos programas (injetando-se neles), para que qualquer usuário lance um programa como administrador sem passar pelo UAC. Com maiores ou menores diferenças esta forma segue sendo válida para o Windows 8 e versões posteriores, mesmo com as melhorias realizada do UAC.

Dois, Engando o UAC – em memória

Em 2011 foi publicado um método diferente para desabilitar o UAC em memória. Quando se chama o CreateProcess desde o explorer.exe, esta chamada desencadeia outo CreateProcessInternal e que por sua vez o RtlQueryElevationFlags que decide se mostra ou não a caixa de diálogos do UAC. Em uma prova de conceito disponível, é aberto um explorer.exe que “altera como se fosse uma correção” essa função em memória com o ntdll.dll, e assim faz com sempre devolva 0, independentemente do estado do UAC. Assim nunca perguntará.

Eliminando a Caixa de diálogos do UAC em um Windows 7 totalmente atualizado.

Não funcionará se não se realiza a partir do explorer, mas esta aproximação é suficiente para o malware. Em concreto a versão 3 do cryptowall utiliza essa mesma “solução”, não só para desabilitar o UAC, como também para degradar a segurança do sistema em geral, sem que o usuário veja as caixas de diálogo.

Exemplo de um Malware real solicitando a elevação de privilégios. É muito semelhante a uma legitima (uma solicitação real do cmd do Windows) até nos detalhes.

Três: Elevação de privilégios verdadeira, através de vulnerabilidades

Independentemente do UAC, de vez em quando, o Windows pode passar de usuário a administrador, mesmo que o usuário não pertença a este grupo. Habitualmente isto se consegue aproveitando uma vulnerabilidade. A vulnerabilidades normalmente são corrigidas e isso ocorre várias vezes ao ano. As vezes as falhas são corrigidas antes mesmo que se façam públicas e outras, são realizadas sem prévio aviso, como no caso recente “Hot Potato”. Neste caso conta com o problema de se aproveitar de várias falhas do sistema, algumas estruturais que a vai dar muito trabalho a Microsoft para solucionar.

O resto das vulnerabilidades normalmente ocorrem no kernel, surgem e desaparecem a medida que a Microsoft realiza suas correções. Para ser sincero, estas vulnerabilidades normalmente não são aproveitadas pelos malwares, e sim, em ataques realizados manualmente por auditores e pentesters.

Casos Extra: Elevação de privilégios por outras causas

Existem outros métodos, um habitual é quando um programa estabelece permissões de forma errada no sistema e um usuário pode se aproveitar para mudar o executável (ou até mesmo um serviço) e entre como SYSTEM. Isto também é habitual ocorra a cada tempo, mas é mais atribuído a um instalador ou programados que ao próprio sistema operacional, além de somente funcionar se logicamente existir o programa instalado. Sem ir muito longe, temos um exemplo recente aqui: http://x42.obscurechannel.com/?p=263

O que fazer?

Evitar o uso do UAC criando um usuário sem privilégios de verdade. Se utilizar o UAC, elevar sua segurança nos “moldes Windows Vista”. E para o restante de elevações de privilégio… aplicar os Patchs de correção e melhorar a segurança do equipamento em geral pois muitas das vulnerabilidades já estão mitigadas si se tomam as precauções previas necessárias.

Elevar a segurança da UAC. Se não ha mais remédio que utiliza-lo, uma possivel melhoria.

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

[email protected]

@ssantosv

tradução por Leandro Bennaton

[email protected]

@bennaton