Segurança do Windows: análise sobre as APIs, parte 2 Artigos

Introdução

No artigo anterior, vimos um pouco sobre o funcionamento das APIs do Windows e as falhas de segurança na relação de um aplicativo com o kernel do sistema. Talvez ainda não tenha ficado bem claro como todo aquele esquema funciona, então nesta segunda parte vamos colocar aqueles conhecimentos em prática.

Pretendo mostrar na prática e passo a passo como interceptar uma chamada de API e alterar o comportamento de um aplicativo. No caso, vamos apenas habilitar um botão em um pequeno aplicativo que eu mesmo programei para este fim, da forma mais simples possível. A princípio, pode ser um pouco complicado, já que vamos trabalhar com ferramentas de “baixo nível” como debbugers e programação em assembly. Recomendo ter um conhecimento básico nas duas, mas caso não tenha, não se preocupe, pois vou tentar explicar o melhor possível como trabalhar nesses programas.

Antes de indicar quais programas vamos usar, gostaria de deixar claro que este artigo e o alvo sobre o qual vamos trabalhar foram feitos para fins estudantis - programados justamente para exemplificar o funcionamento das APIs - e tem o intuito de alertar os usuários sobre o perigo de executar aplicativos e DLLs desconhecidos.

Ferramentas

Para iniciar nosso estudo, precisamos de algumas ferramentas básicas para entender como nosso alvo funciona e como alterar o funcionamento do mesmo.

Segue a lista dos aplicativos que vamos usar. Todos são gratuitos:

• OllyDbg – Este é certamente o melhor debbuger/disassembler gratuito para Windows disponível. É bem completo e organizado.
  www.ollydbg.de

• Ative-me – Nosso “alvo” sobre o qual vamos trabalhar. É apenas uma janela com um botão desativado. Foi programado por eu mesmo utilizando o assembler MASM32.
  www.fergonez.net/download.php?file=fontes_api.rar

• MASM32 – Um dos mais famosos compiladores de assembly para Windows.
  www.masm32.com

• WinAsm – IDE de programação bastante versátil, com editor de recursos, coloração de sintaxe e intellisense. Faz o uso do MASM32 para gerar os binários.
  www.winasm.net

• LordPE – Uma ferramenta muito interessante, que mostra diversas informações técnicas sobre os arquivos .exe, assim como uma lista de todos os processos e dlls carregadas no sistema.
  www.sistemo.com/LordPE/info.htm

A instalação desses aplicativos é bastante simples. Na maioria dos casos basta descompactar o conteúdo em uma pasta qualquer. O único aplicativo que vale ressaltar algumas configurações é o WinAsm, de modo que aponte para os diretórios do MASM32 (libs, includes e bin). Os diretórios podem variar dependendo do local de instalação, então configure o WinAsm (menu “Tools->Options->Files & Paths”) da seguinte maneira, apenas alterando os diretórios conforme necessário (o item marcado em vermelho é opcional):

Um pouco de Assembly e seu funcionamento

Antes de iniciar a parte prática, precisamos nos familiarizar um pouco com a linguagem que vamos usar: assembly. Muitos têm medo desse nome, mas eu diria que não é tão complicado assim, pois em certos casos ela é mais clara e direta que qualquer outra linguagem estruturada. Conhecendo um pouco dos comandos básicos você já é capaz de entender e analisar aplicativos simples, como o nosso alvo.

Não vou explicar cada instrução existente no assembly, mas vou deixar um link com uma lista de cada uma e a explicação do seu funcionamento:

Além da lista de opcodes - como são chamadas as instruções - vou colocar mais algumas referências, que valem a pena serem lidas:

Arquitetura Intel: http://www.numaboa.com.br/informatica/oiciliS/assembler/referencias/arquitetura.php

Funcionamento da Stack (pilha): http://www.numaboa.com.br/informatica/oiciliS/assembler/textos/stack1.php

Outras referências: http://www.numaboa.com.br/informatica/oiciliS/assembler/

Eu recomendo muito a leitura desses textos, pois explicam alguns conceitos sobre a arquitetura dos computadores, que são fundamentais para o entendimento deste artigo.

Agora que temos todas as ferramentas em mãos, creio que possamos dar início ao nosso estudo. Vamos começar analisando o funcionamento do alvo através do OllyDbg.

Análise do alvo

O primeiro passo é dar uma olhada geral no alvo. Execute o arquivo “ative-me.exe”. Nada muito impressionante, apenas um pequeno texto e um botão desabilitado. O nosso objetivo vai ser habilitar esse botão sem alterar sequer um byte do binário.

Para que um controle, como botões e caixas de texto, sejam desabilitados, é usada uma função da API do Windows (User32) chamada EnableWindow.

Ela recebe dois argumentos: hWnd e bEnable. O primeiro é o que chamamos de “handle”, um valor de referência a determinado item, sobre o qual queremos ter o controle para alterar suas propriedades. O segundo é o bEnable. Quando seu valor é 0 (FALSE), o controle indicado pelo Handle vai ter seu estado alterado para “Desativado”. Caso contrário (TRUE), ele fica “Ativado”.

Inicie o OllyDbg. Vá em “File->Open” e selecione o nosso alvo. Assim que ele carregar, você verá uma tela semelhante a essa:

No canto superior esquerdo, encontramos o disassembly do executável. Este seria o código de máquina do nosso aplicativo.

Repare que existem 4 colunas no disassembly. Caso não exista, clique com o botão direito sobre ele, vá em “Appearence->Show Bar”. A mais da esquerda é o Offset, endereço de referência de cada instrução. Entenda como se fossem as “linhas de código” do alvo, generalizando. À direita dela tem o Hex Dump de cada instrução. São esses valores em Hexadecimal que o processador usa para realizar os procedimentos. Cada operação que você realiza possui um determinado código de instrução, chamado opcode. Em seguida vêm a coluna do Disassembly, que nada mais é do que os opcodes traduzidos para uma linguagem mais agradável ao ser humano. Por último vem a coluna de comentários, onde o Olly analisa as instruções e informa dados úteis, como por exemplo as chamadas de APIs e os argumentos que ela recebe.

No canto superior direito está a janela de registradores (EAX, EBX, ECX, EDX, etc.). Registradores são pequenas porções memória localizadas dentro do processador, das quais boa parte das instruções dependem para realizar as operações.

A janela inferior direita contém a Stack (Pilha). Não vou explicar profundamente o que ela é e como funciona, já que indiquei um link explicando sobre isso. Somente para constar, ela também é uma estrutura de memória, mas se comporta de uma forma chamada de LIFO: Last In First Out. Imagine uma pilha de livros, na qual é necessário tirar todos os livros do topo para poder remover algum livro no meio. Os dados da pilha são colocados ou retirados por dois comandos: PUSH e POP. O primeiro é usado para colocar um dado na pilha, e o segundo para removê-lo.

Por último o canto inferior esquerdo, correspondente ao Memory Map. Como o próprio nome já diz, este local mostra os dados armazenados no espaço de memória alocado para a execução do nosso aplicativo.

Agora que estamos um pouco mais familiarizados, podemos realmente começar o nosso estudo. Com o alvo aberto no Olly, vamos olhar as funções da API que o programa utiliza. Aperte CTRL+N para abrir a janela Names. Esta janela mostra uma lista de todas as APIs utilizadas pelo alvo. Um dos itens nessa lista nos chama atenção: user32.EnableWindow. Clique duas vezes sobre este item e o Olly nos leva ao local onde essa API é chamada pelo aplicativo, como na imagem abaixo.

Repare que o Olly identificou a chamada da API, assim como os dois argumentos recebidos - hWnd e Enable - que são colocados na pilha através do comando PUSH. Note também que ele coloca na pilha o valor 0 para a opção Enable, representando o estado do nosso controle, onde 0 = desativado. Em seguida é posto na pilha o EAX, que logicamente contém o Handle do controle. Depois ele simplesmente faz a chamada para a função que vai desabilitar o botão.

Bom, e se eu alterasse o PUSH 0 para PUSH 1? Assim eu alteraria o argumento da API, fazendo com que eu ative o botão ao invés de desativá-lo. Correto, isso funciona. Basta dar um duplo clique sobre o PUSH 0 e alterar para PUSH 1, clicando posteriormente em Assemble. Feche a janela do Assemble at... e clique no botão Play. Voilá! Nosso botão está ativado.

Mas o intuito deste artigo não é esse, pois queremos fazer isso sem mexer no código do executável, mas sim alterar diretamente na memória.

Volte ao Olly e reinicie o alvo através do CTRL+F2 ou pelo File->Open. Vamos adicionar um breakpoint no local onde ele coloca o primeiro valor na pilha (PUSH 0). Clique sobre a linha que contém o PUSH 0 e aperte F2. O endereço do PUSH deve ter ficado vermelho. O que o breakpoint faz? Ele congela a execução do programa assim que a execução atingir o determinado endereço, para que possamos avaliar o estado dos registradores/memória/stack.

Com o breakpoint ativado, clique em “Play”. Instantaneamente o programa congela e retorna para o Olly, indicando que atingimos o nosso breakpoint. O comando PUSH 0 ainda não foi executado. Vamos rodar o programa instrução por instrução agora e ver o que acontece. Aperte F7 uma vez e preste atenção na pilha (canto inferior direito). Assim que você pressionar a tecla, o PUSH 0 vai ser executado e vai adicionar o valor 00000000 na pilha. Aperte F7 novamente, para executar a instrução do PUSH EAX. Repare novamente que o valor de EAX foi adicionado ao topo da stack:

A coluna da esquerda indica o endereço da pilha. A coluna do meio é o valor armazenado naquele endereço. Na terceira coluna, ficam os comentários, como na janela do disasm.

Estamos prestes a realizar a chamada para a API. Veja que o “cursor” (offset colorido de preto) indicando a posição atual do programa está sobre o CALL <JMP.&user32.EnableWindow>. Aperte F7 mais uma vez. Fomos levados até a chamada “Jump Table”. Sempre que o programa chamar a função EnableWindow, o código é redirecionado para essa Jump Table, que por sua vez vai em si chamar a tal função.

Repare na pilha, ela está completa agora, já possui os dois argumentos, assim como o endereço de retorno. Quando a API terminar de executar seu código, ela vai utilizar esse endereço para descobrir a instrução para a qual o fluxo deve ser redirecionado.

Podemos esquematizar a chamada da API da seguinte forma:

Certo, mas como vamos alterar aquele valor 00000000 da stack para 00000001, sem mexer o executável?

Assim que o alvo for iniciado, vamos carregar uma DLL junto a ele, como explicado na primeira parte deste artigo. A DLL, quando for iniciada, vai buscar pela chamada da função EnableWindow e desviar a sua execução para uma rotina que vamos programar na DLL. Essa rotina, por sua vez, vai alterar o valor do bEnable diretamente na stack e em seguida repassar o controle para o executável novamente, de modo que ele execute a chamada para a EnableWindow como se nada tivesse acontecido. É o que chamamos de “API Intercept”.

Voltando ao Olly, você deve estar na JumpTable para o EnableWindow. Aperte F7 mais uma vez e entraremos na rotina dessa API. As suas primeiras instruções são:

É aqui que ocorrerá o desvio. Vamos ter que substituir essas primeiras instruções por um salto - JMP - para a nossa própria rotina, codificada na DLL. Não é possível inserir instruções no executável, pois isso comprometeria toda a integridade e alinhamento de endereços. A única forma é substituir as instruções existentes pelo desejado. Claro que também não podemos simplesmente substituir e esquecer dos dados que estavam naquela posição anteriormente.

Vamos utilizar os seguintes procedimentos:

• Buscar pelo endereço da chamada da EnableWindow, que retornará o endereço daquela instrução “MOV EDI, EDI” da figura mostrada acima.

• Fazer “backup” dos bytes das primeiras instruções dessa API (o suficiente para comportar o nosso comando JMP).

• Substituir essas instruções na memória por um JMP, redirecionando o código para função dentro da nossa DLL.

• Essa função por sua vez, vai alterar o valor do bEnable na pilha, reescrever o “backup” na memória, mantendo a integridade original da API, e retornar o controle para que o alvo continue sua execução.

Agora começa a parte mais complexa, que é escrever a DLL. Infelizmente não poderei explicar a fundo o que cada comando vai realizar, pois tornaria o artigo muito longo (seria mais uma aula de assembly do que um artigo sobre segurança). O código escrito aqui não possui comentários, pois eles quebrariam o layout da página, no entanto o código disponível junto com os arquivos de estudo está devidamente comentado. Caso sinta dificuldade, recomendo ler alguns daqueles links indicados logo no início do artigo.

Programação da DLL

Abra o WinAsm, com os caminhos devidamente configurados, indicados lá no começo do artigo. Com ele aberto, vá em “File->New Project”. Marque a opção “Create a new empty project” e clique em Next. Selecione “Standard DLL” e conclua o assistente. Se for perguntado para salvar, escolha um nome qualquer.

Cole o código abaixo no projeto recém criado. Cuidado ao copiar. Copie em partes e verifique se alguma parte do texto não foi corrompida durante o processo.

Como mencionei alguns parágrafos acima, esse código não está comentado, dificultando um pouco o entendimento. Para visualizar os comentários você pode abrir o código fonte disponibilizado junto com o nosso alvo, dentro do arquivo fontes_api.rar. O nome do arquivo é main.asm e está localizado na pasta “fontes\dll”. Lá tem cada linha comentada.

O código fica da seguinte maneira dentro do WinAsm:

Antes de compilar a DLL precisamos criar um arquivo de definições da mesma, contendo o nome da DLL e as funções que ela possui (no caso, apenas uma). No lado direito, em “Explorer”, clique com o botão direito em qualquer lugar e selecione “Add New Other”. No arquivo que ele adicionou a lista, clique com o botão direito e vá em “Rename”. Na janela para salvar, dê um nome qualquer e, no tipo de arquivo, selecione “Definition Files”.

Após salvar, adicione o seguinte código ao arquivo recém criado:

Salve novamente o projeto, pois podemos finalmente compilar a nossa DLL.

Verifique novamente se está tudo certo, se você tem os arquivos mais ou menos desta forma:

O arquivo main.asm deve conter o código da nossa DLL. O arquivo definições.def , aquelas 2 linhas que eu mencionei logo acima.

Se estiver tudo certo, vá ao menu “Make->Go All”. Caso os caminhos para o MASM32 estejam configurados corretamente, sua DLL deve ter sido compilada com sucesso. Uma mensagem em verde, no rodapé do WinAsm, deve indicar que não houve nenhum erro:

Se essa mensagem não apareceu é porque algo errado aconteceu. Verifique novamente se os arquivos .asm e .def existem na pasta do seu projeto e que o conteúdo de ambos está corretamente escrito. Verifique também nas configurações de “Files & Paths” do WinAsm se o endereço para todas aquelas pastas existem de fato.

Caso tudo tenha ocorrido normalmente, você vai ter uma .dll na pasta do seu projeto, cujo nove varia de acordo com o nome dado ao mesmo. Você deve renomear essa DLL para “redir.dll”, sem aspas, pois foi esse o nome que indicamos no arquivo .def.

Execução da DLL

Temos a DLL, agora só nos resta testá-la. Para facilitar o processo, copie a redir.dll para a raiz de uma partição (C:\ por exemplo). Feito isso, vamos agora forçar a execução dela quando o nosso alvo for executado.

Como mencionado na primeira parte deste artigo, utilizaremos uma chave do registro do Windows, que força o carregamento de uma DLL sempre que qualquer aplicativo for iniciado. Isso significa que, caso essa chave de registro exista e aponte para uma dll, qualquer programa iniciado - não somente o nosso alvo - vai iniciá-la junto, sendo que os efeitos da DLL serão notados em todos os aplicativos.

Vá até o menu “Iniciar->Executar” e digite “regedit” (sem aspas), seguido do Enter. O Editor de registro foi aberto. Navegue até o caminho:

Agora é “a hora da verdade”. Pode-se fechar o regedit e iniciar o nosso alvo. Se tudo foi feito corretamente, o botão do “Ative-me” não está mais desativado:

Se quisermos ter certeza de que a DLL foi carregada, podemos utilizar o LordPE. Selecione o alvo na lista de aplicativos carregados, e no espaço abaixo estarão listadas as DLLs carregadas pelo aplicativo selecionado. A redir.dll vai ser uma delas:

Para voltar ao estado normal, basta fechar o alvo e remover aquela entrada de registro. Recomendo não deixar ela lá, pois alguns programas podem parar de responder devido ao carregamento desta DLL. Utilize-a apenas durante o período de estudo.

Vou aproveitar o final deste capítulo para esclarecer algumas dúvidas que podem surgir durante a análise do código.

1. Porque o nSize é 060000h?
   
   Não há uma razão específica para ter escolhido esse valor, poderia ser qualquer outro desde que não seja menor que o tamanho da DLL gerada. Como ela tem apenas 3.072 bytes, eu poderia diminuir bastante esse número.
   
   

2. Porque o valor do incremento é 0Ch?
   
   Pois esse é o número de bytes (12, em decimal) a partir do topo da pilha, que se encontra o valor do bEnable. Se você for traçando as instruções no Olly com a DLL carregada, verá que no momento que ocorrer o desvio - após o JMP - o topo da stack é no endereço 0012FC94. Somando 0Ch a esse valor, temos 0012FCA0, que é bem o endereço do bEnable. Veja a imagem da stack no capítulo “Análise do Alvo”.
   
   

3. O que são aquelas de subtrações/somas com o valor 4?
   
   Aquelas operações são para deslocar o ponteiro da memória para outras regiões. Por exemplo: quando EAX apontava para a posição do nosso backup, foram pegos 4 bytes a partir daquela posição (DWORD PTR DS:[EAX] sendo que DWORD indica operação com 4 bytes) e colocados no registrador ECX. Para pegar os próximos 4 bytes e colocar no backup 2, eu preciso mover o ponteiro de memória 4 bytes a frente, já que o backup do endereço atual já foi realizado.
   Para entender isso de forma fácil, a melhor coisa é ter o Olly aberto no alvo e traçar instrução por instrução, fazendo um “desenho” da memória em algum papel, anotando o endereço e valor de cada byte, assim como dos registradores.

Conclusão

É isso aí. Aqui se encerra este artigo. Antes de finalizá-lo, vou colocar algumas dicas de como se proteger desse tipo de falha, já que é a maior razão para esse artigo ter sido escrito.

• Não execute arquivos e instaladores que você não sabe a procedência. É uma dica um tanto quanto óbvia, mas muita gente às vezes executa algum arquivo perdido para somente “ver o que é” e sem querer acaba infectando e introduzindo algum arquivo perigoso ao sistema.

• Tenha medo de DLLs. Pelo fato delas não serem executadas via duplo clique, mas sim em conjunto e controlado por outro aplicativo, é nelas que se concentram a maior parte dos códigos que danificam o sistema. Muitas vezes os softwares antivírus não detectam e nem fazem análise das DLLs, mas sim dos programas que as usam. Infelizmente, como acabamos de ver, é possível fazer com que qualquer programa, mesmo sendo o mais inofensivo possível, execute uma DLL que pode conter algoritmos suspeitos.

• Verifique periodicamente por aquela chave do registro e veja se por ventura o valor de seqüência “AppInit_DLLs” está apontando para um arquivo. Por padrão, nem o Windows, nem qualquer outro software necessita usar aquele valor, já que as DLLs são normalmente carregadas pelo próprio programa. Se ele existe, é bom ficar de olho.

• Utilize também programas de monitoramento das DLLs carregadas na memória. Existem programas poderosíssimos, como o LordPE, que conseguem desmembrar um executável e mostrar informações preciosas sobre o comportamento e as dependências dos executáveis.

• Em caso de dúvida sobre .exe ou .dll, use o Olly. Se não possuir experiência em assembly, use para pelo menos verificar pelos nomes das APIs utilizadas pelo arquivo (pelo atalho CTRL+N).

Acho que as principais dicas que eu posso apontar são essas. Não deixe de fazer valer aquelas outras tradicionais:

• Sempre manter um antivírus e firewall ativado.

• Não entrar em sites dos quais não se sabe a procedência e/ou conteúdo.

• Ficar atento para os links que são divulgados nas grandes redes como Orkut, pois em alguns casos eles mascaram links para arquivos .bat/cmd/exe/scr, comumente utilizados para infiltração nos computadores do usuário.

Espero que tenham gostado e aproveitado bastante. Pode ter ficado um pouco confuso, mas fiz o melhor que eu pude para tentar deixar o mais simples possível.

Abraços e até a próxima!

Por Fernando Birck aka Fergo - www.fergonez.net

Agradecimentos especiais:

• Gabri3l, pelo ótimo artigo sobre as APIs do Windows, de onde partiu a idéia de fazer algo semelhante para o nosso idioma.

• Ao site oicìliS, pela ótima referência da linguagem Assembly, assim como algumas explicações sobre a arquitetura e funcionamento de computadores.

• Ao Oleh Yuschuk (OllyDbg), pela criação de um dos melhores debbugers já feitos para a plataforma Windows.

• Aos criadores de todos os outros aplicativos utilizados por este artigo. Certamente foram de muita valia.

» Gostou do texto? Veja nossos livros impressos

... ou use a busca para localizar outros artigos relacionados: