Processo fantasma – ataque de adulteração de imagem executável
Como membro de uma equipe de segurança, qual a primeira solução que vem a cabeça quando o assunto é proteção contra executáveis maliciosos? Se você atua nessa área a tanto tempo quanto eu, muito provavelmente a sua resposta é antivírus. Se você está mais atualizado e quer ser um pouco menos generalista com relação a definições e terminologias, a resposta provavelmente seria anti-malware, afinal de contas, não é somente vírus que desejamos detectar, existem vários outros tipos de malware.
Para falar sobre esses outros tipos, vamos estabelecer uma linha de base de raciocínio e falar sobre sistemas Microsoft: o fabricante disponibiliza para fornecedores de soluções de segurança a habilidade de registrar chamadas a partir da criação de processos no sistema. Desenvolvedores de drivers podem chamar APIs como PsSetCreateProcessNotifyRoutineEx, uma rotina que registra ou remove a chamada que notifica quando um processo é criado ou já existe, para receber informações sobre esse tipo de evento. No entanto, há uma particularidade na chamada dessa rotina em específico, ela não é feita a partir da criação do processo, mas a partir da criação das primeiras threads do processo. Isso cria uma lacuna entre a criação do processo e a notificação dessa ação para a solução de segurança (o antivírus, por exemplo). Essa lacuna é utilizada por atores maliciosos que adulteram o executável de apoio antes da verificação/scan da sua solução de anti-malware.
Um exemplo de ataque que abusa deste comportamento para evasão de verificação de sistemas de segurança é o “Process Herpaderping“. Com essa técnica, um invasor pode gravar um malware no disco de forma que seja difícil verificá-lo ou excluí-lo, onde ele executa o malware excluído como se fosse um arquivo normal no disco. Essa técnica não envolve injeção de código, esvaziamento de processo ou NTFS transacional (TxF).
Veja uma demonstração abaixo:
É importante observar que processos não são executáveis e os executáveis não são processos. Um processo é basicamente um conjunto de informações necessárias para a concorrência de programas no sistema operacional, com toda informação do seu estado (memória, registradores, contador de programa, status de entrada e saída, etc). Um executável possui a representação binária das instruções de máquina, que executam o código quando aberto. Essas definições podem ser encontradas no famoso Tanenbaum. O executável svchost.exe, por exemplo, pode lançar múltiplos processos, mas para isso acontecer uma série de passos deve acontecer. Em versões mais recentes do Windows, elas são feitas no kernel pelo NtCreateUserProcess, resumidamente através da criação de arquivo, seção de imagem, criação de processo e a thread associada a ele. Os processos são iniciados a partir de executáveis, mas alguns dos dados no arquivo executável são modificados à medida que são mapeados em um processo. Para contabilizar essas modificações, o gerenciador de memória do Windows armazena em cache as seções de imagem no momento de sua criação. Isso significa que as seções da imagem podem diferir de seus arquivos executáveis.
Usando o conceito de TxF, é possível criar uma seção de imagem a partir de um arquivo dentro de uma transação e, em seguida, reverter essa transação. Após criar a seção de imagem, Process Herpaderping, (explicado anteriormente), usa o identificador de arquivo existente para sobrescrever o executável com um PE como isca. Embora isso deixe a isca no disco, difere daquele em execução na memória. A isca permanece no disco durante toda a vida útil do payload do processo.
Podemos construir sobre as técnicas acima, uma forma de rodar executáveis que já foram excluídos, para esta técnica se dá o nome de processo fantasma. O Windows tenta impedir que os executáveis mapeados sejam modificados. Depois que um arquivo é mapeado para uma seção de imagem, as tentativas de abri-lo com FILE_WRITE_DATA (para modificá-lo) vão falhar com o status ERROR_SHARING_VIOLATION. As tentativas de exclusão via FILE_DELETE_ON_CLOSE / FILE_FLAG_DELETE_ON_CLOSE falham com ERROR_SHARING_VIOLATION. NtSetInformationFile (FileDispositionInformation) requer o direito de acesso DELETE, mesmo que o direito de acesso DELETE seja concedido a arquivos mapeados para seções de imagem, NtSetInformationFile (FileDispositionInformation) falha com STATUS_CANNOT_DELETE. As tentativas de exclusão por meio de FILE_SUPERCEDE / CREATE_ALWAYS falham com ACCESS_DENIED.
Uma observação importante, no entanto, é que essa restrição de exclusão só entra em vigor depois que o executável é mapeado em uma seção de imagem. Isso significa ser possível criar um arquivo, marcá-lo para exclusão, mapeá-lo para uma seção de imagem, fechar o identificador de arquivo para concluir a exclusão e, em seguida, criar um processo a partir da seção agora sem arquivo. Esse tipo de adulteração também pode ser aplicado a DLLs, porque as DLLs são seções de imagem mapeadas.
Esta vulnerabilidade foi divulgada ao Microsoft Security Response Center (MSRC) em 17/07/2020 e um caso foi aberto 5 dias após. O MSRC concluiu sua investigação e determinou que os resultados são válidos, mas não atendem aos requisitos de manutenção imediata. No momento, o caso deles está encerrado, sem resolução, e marcado para revisão futura, sem cronograma.
Vários são os motivos que fazem especialistas em segurança discordarem dessa decisão, entre eles:
- Existem vulnerabilidades semelhantes nesta classe (Hollowing e Doppelganging);
- A vulnerabilidade está presente nos recursos de segurança inerentes ao sistema operacional (Windows Defender);
- A vulnerabilidade permite que um ator obtenha a execução de código arbitrário;
- O usuário não é notificado da execução de código indesejado;
- As informações do processo apresentadas ao usuário não refletem com precisão o que está sendo executado,
- Ferramentas para identificar o processo com precisão não são intuitivas ou se mostram imprecisas, mesmo a partir do kernel.
E por todos esses motivos, é de extrema importância uma solução anti-malware com mecanismos de detecção dinâmica, baseado em comportamento. O Cisco Secure Endpoint (anteriormente conhecido como AMP for Endpoints), detecta uma variedade de técnicas de adulteração de imagem de processo, incluindo as supramencionadas. Ele faz isso verificando o FILE_OBJECT quanto a anormalidades durante o retorno de chamada de criação do processo. Um dos motores disponíveis na solução é a “System Process Protection”, ela protege processos críticos do sistema Windows de ataques de injeção de memória por outros processos. Se você quer entender melhor como funciona, veja este link.
O Cisco Secure Endpoint é uma solução completa com várias tecnologias que funcionam juntas para prevenir, detectar e corrigir códigos maliciosos no endpoint. A solução fornece uma camada de segurança preventiva integral para proteger endpoints, servidores e ambientes virtuais de ataques fileless e de injeção de memória, bem como malware ofuscado alterando a natureza estática do cenário de defesa para um estado dinâmico, dificultando para os atores maliciosos planejarem e executarem ataques bem-sucedidos.
Faça um teste da solução hoje mesmo no seu ambiente, clique aqui.
Tags: