Um, dois, três... maneiras de escalação de privilégios no Windows

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.