Fazendo a VM acreditar que tem uma ventoinha de CPU para enganar malware

• Malwares verificam a presença de hardware como a ventoinha da CPU para evitar rodar em ambientes virtuais
• As informações da ventoinha da CPU podem ser consultadas pela classe Win32_Fan do WMI, e esses dados ficam armazenados no SMBIOS
• No Xen, para injetar dados SMBIOS personalizados, são necessários patch e configuração adicional, e é preciso configurar tanto as tabelas de Cooling Device (Type 27) quanto de Temperature Probe (Type 28)
• No QEMU/KVM, é possível aplicar um SMBIOS personalizado de forma simples com a opção -smbios, sem necessidade de patch adicional
• Com isso, dá para fazer a máquina virtual parecer ter uma ventoinha de CPU e tentar contornar a detecção do malware

---

Por que fazer isso?

• Alguns malwares verificam a presença de hardware específico (por exemplo, uma ventoinha de CPU) para descobrir se estão sendo executados em um ambiente virtual
• Eles inspecionam o hardware por meio de classes WMI como Win32_Fan; se essas informações não existirem, concluem que se trata de uma máquina virtual e evitam a execução
• A intenção é impedir que analistas consigam analisar o malware
• Existem várias classes WMI, como Win32_CacheMemory e Win32_VoltageProbe, mas este texto foca na ventoinha da CPU

Como o computador reconhece que há uma ventoinha de CPU?

• O computador lê as informações do SMBIOS para identificar a presença de um dispositivo de resfriamento (ventoinha da CPU)
• A instância Win32_Fan é fornecida por cimwin32.dll, e essa DLL lê as informações da ventoinha a partir da entrada type 27 do SMBIOS
• Também seria possível usar técnicas como hooking de DLL, mas manipular diretamente o SMBIOS é uma abordagem melhor

SMBIOS Type 27

• O SMBIOS type 27 significa "Cooling Device"
• É possível verificar diretamente os dados de Cooling Device do SMBIOS com o utilitário dmidecode
• Exemplo:
  • Type: Chip Fan
  • Status: OK
  • Description: CPU Fan
  • Nominal Speed: 5600 rpm etc.

Como configurar dados SMBIOS personalizados no Xen

• No Xen, é possível especificar diretamente dados SMBIOS em formato binário usando a opção smbios_firmware no arquivo de configuração do domain
• Cria-se um arquivo smbios.bin para inserir os dados de Cooling Device (type 27)
• O tamanho da estrutura SMBIOS (por exemplo, 24 bytes) deve ser prefixado como um inteiro little-endian de 32 bits

Problema: limitação de override de estruturas

• O Xen limita a substituição apenas às estruturas 0, 1, 2, 3, 11, 22 e 39
• O type 27 não é permitido por padrão, então é necessário aplicar patch no código-fonte
• Um patch relacionado chegou a ser proposto no fórum de desenvolvedores do Xen, mas não foi aceito oficialmente (é preciso aplicar o patch e compilar)

O Type 28 também é necessário

• O Cooling Device (type 27) está ligado ao Temperature Probe (type 28)
• Se não houver uma entrada type 28 no SMBIOS, a classe Win32_Fan não será exibida corretamente
• É preciso obter os dados type 28 do sistema host e adicioná-los ao smbios.bin para que o reconhecimento funcione corretamente

Estrutura final do smbios.bin

• Inclui tanto os dados do Type 27 quanto do Type 28
• Antes de cada estrutura, insere-se a informação de tamanho em little-endian
• Exemplo: formato como 18 00 00 00 ... (type 27) ... 29 00 00 00 ... (type 28) ...

Aplicação e verificação no Xen

• Depois de iniciar a máquina virtual Windows com o comando de criação de domain, verifica-se no WMI se a classe Win32_Fan é reconhecida corretamente
• A exibição de Description: Cooling Device e Status: OK confirma que a ventoinha da CPU foi reconhecida com sucesso

Configuração de dados SMBIOS no QEMU/KVM

• No QEMU/KVM, é fácil configurar um SMBIOS personalizado com a opção -smbios file=caminho
• Usa-se apenas os dados raw, sem informação de tamanho da estrutura
• Também é possível reutilizar diretamente os dados SMBIOS do host

Referências

• Documentação do arquivo de configuração de domain do Xen, notas de configuração do mcnewton, arquivo do patch rejeitado do Xen, System Management BIOS Reference, patch QEMU Anti Detection etc.

[GN⁺]

Comentários no Hacker News

• Como novo método antimalware, também mencionam comprar um PC com resfriamento passivo e configurar um teclado russo como dica para bloquear malware fraudulento; dá para ver o link relacionado

  • Eu realmente uso um PC Linux com resfriamento passivo Streacom FC8 Evo e um teclado russo, mas ao verificar com o comando dmidecode, as informações do dispositivo de resfriamento ainda existem e o dispositivo de resfriamento é de fato detectado; também é possível confirmar informações de temperatura pelos dados dos sensores

  • Mesmo usando um PC com resfriamento passivo, a placa-mãe normalmente ainda tem conectores para ventoinha, então provavelmente não faz grande diferença mesmo que nada esteja realmente conectado

• Comentam que não deveríamos usar linguagem como “smol pp”, apontando a presença de zombaria com o corpo nesse tipo de expressão

  • Na minha cidade há alguém com uma placa personalizada “SML PP”, não sei o motivo

  • Há também a opinião de que, mesmo usando a expressão “nossa linguagem”, é ambíguo que alguém na seção de comentários de um blog fale em nome de “nós”

• Há a opinião de que fazer o sistema operacional parecer uma máquina virtual pode aumentar a segurança e ajudar pesquisadores; se alguém quiser uma abordagem sem virtualização, deveria precisar obter autorização, e assim o malware talvez deixe de mirar também usuários comuns para evitar a análise por pesquisadores, o que no fim beneficiaria todos exceto os criadores de malware

  • Em vez de fazer um sistema operacional comum parecer uma VM, a ideia seria o oposto: fazer a máquina virtual não perceber de forma alguma que está virtualizada; comentam que os sistemas lpars da IBM funcionam assim

  • Mencionam que, desse jeito, empresas de software anti-cheat também sairiam perdendo; eu quero saber claramente onde meu software está rodando, mas também há muitos jogadores de multiplayer que odeiam mais usuários com cheat do que a própria trapaça, então na prática seria difícil mudar isso

  • Há a opinião de que, no mundo do desenvolvimento mobile, esse modelo já virou realidade

• Eu nunca vi, em placas-mãe de consumo, uma descrição SMBIOS que correspondesse ao hardware real; um malware que checa esse SMBIOS pode falhar em 50% do hardware real, mas se bloquear com certeza 100% das VMs ou depuradores, do ponto de vista do malware isso ainda pode valer muito a pena, embora eu espere que verificar por medição de tempo seja mais confiável do que essa abordagem

  • Esse problema de a descrição SMBIOS não bater com o hardware real é especialmente grave em caixas chinesas baratas; valores em branco como “to be filled in by OEM” aparecem com frequência ao codificar imagens de BIOS reais, então só isso já torna a situação bastante engraçada

  • Malware também tem muitos bugs; assim como já houve casos em que bugs no código de rede fizeram um vírus se espalhar à metade da velocidade originalmente pretendida, um malware pode causar danos enormes mesmo sem infectar todos os dispositivos

  • Hoje em dia fico curioso sobre como o Linux reconhece ventoinhas; não sei se usa ACPI ou EFI, e pergunto isso porque na maioria dos meus dispositivos as ventoinhas/sensores são detectados corretamente

  • Há também a pergunta se essa checagem de SMBIOS é algo que malware real faz, ou se é usada apenas em amostras criadas por pesquisadores

• Pode parecer engraçadinho que malware use truques com API para dificultar a análise, mas na maioria das vezes essas chamadas de API são facilmente detectadas em análise estática e, se o binário não estiver ofuscado, isso pode até sair pela culatra; programas com propósito real normalmente são distribuídos com assinatura de uma CA confiável, então em análise de segurança esse tipo de comportamento costuma ser bem detectado; quando eu era júnior, também já trabalhei capturando esse tipo de uso de API com padrões de regex, e isso era bastante eficaz para pegar malware básico distribuído em massa

  • Mais recentemente, malware também assina arquivos com bastante frequência; já não faz sentido esperar que operadores de malware não assinem binários, certificados de assinatura de código roubados são comuns, e a Microsoft também é relutante em revogar certificados por medo de quebrar software de clientes existentes; muitas vezes o malware também usa drivers vulneráveis para entrar no kernel; por isso, na prática, um pequeno binário suspeito fazendo chamadas WMI desperta mais atenção do que um utilitário de overclock cheio de vulnerabilidades fazendo a mesma consulta; na verdade, a intenção aqui não é tanto evitar detecção, mas impedir que a carga útil do malware seja ativada no PC do analista; se for detectado, o segundo payload não é baixado e o comportamento de C&C capaz de causar um ataque real fica suspenso

  • Do ponto de vista de segurança, surge a proposta de que talvez fosse melhor executar todo software em VM

  • Também é discutível que um antivírus tente inferir se algo é malware apenas com análise estática; nesse caso, o resultado seria praticamente o mesmo que adotar uma lista branca e permitir apenas software confiável, tratando todo o resto como malware

  • A realidade em que empresas como a CrowdStrike conseguem obter assinatura oficial para software malfeito rodando em nível de kernel e fazendo todas as system calls sem que ninguém ligue para isso; independentemente de ser VM ou não, o problema é distribuir em produção código e releases não validados e depois não assumir responsabilidade adequadamente quando o mundo realmente quebra, voos atrasam ou infraestruturas críticas sofrem incidentes; criticam que empresas legítimas às vezes podem causar danos maiores do que hackers ou atores estatais, e que o caso do utilitário xz foi um incidente de segurança grande o bastante para ser comparado a SolarWinds e ClownStrike

• Eu vi um amigo da área de infosec passar a maior parte do tempo tornando um honeypot de malware totalmente parecido com hardware real; é impressionante vê-lo configurar, com enorme riqueza de detalhes, desde termostatos baseados em Windows XP até controladores PLC da Siemens e desktops bancários

  • Espero sinceramente que não existam termostatos funcionando com Windows XP por aí

• Isso me lembrou de como era indispensável ter um SMBIOS apropriado ao configurar um Hackintosh; muitas APIs de PC relativamente obscuras foram introduzidas ao longo das últimas décadas, e elas são usadas com frequência para testar o quão bem software de virtualização ou malware reproduz esses detalhes; indo um passo além, também seria necessária uma simulação de sensor de temperatura que variasse dinamicamente de acordo com a carga real da CPU

• Segundo o Mitre ATT&CK T1497.001 (VM Detection), a checagem de SMBIOS é um vetor conhecido; eu também testei e consegui configurar a fonte de alimentação como HotReplaceable=Yes e Status=OK para fazê-la parecer um servidor bare metal de US$ 5.000; o comando usado foi pip install dmigen depois dmigen -o smbios.bin --type0 vendor="American Megatrends",version="F.1" --type1 manufacturer="Dell Inc.",product="PowerEdge T630" --type39 name="PSU1",location="Bay 1",status=3,hotreplaceable=1

  • Como referência, no Hacker News é preciso inserir duas ou mais quebras de linha reais ou recuar cada linha em dois espaços para escrever em modo de código com a quebra de linha correta