LoJax: o primeiro rootkit UEFI conhecido usado em uma campanha maliciosa

O Sednit Cybergroup, também conhecido como ART28, Strontium e Fancy Bear, opera desde pelo menos 2004. Acredita-se que o grupo esteja por trás de uma série de ataques cibernéticos ressonantes. Algumas empresas do IB e o Departamento de Justiça dos EUA chamaram Sednit responsável por invadir o Comitê Nacional Democrata antes das eleições de 2016 nos EUA. O grupo é acusado de hackear a rede global de televisão TV5Monde, vazamento de e-mails da Agência Mundial Antidopagem (WADA) e outros incidentes. Sednit tem muitos objetivos e uma ampla gama de ferramentas, algumas das quais já documentamos anteriormente, mas pela primeira vez neste trabalho descreveremos em detalhes o uso do rootkit UEFI.

Breve revisão

Descobrimos que, pelo menos desde o início de 2017, a Sednit usa uma versão trojanizada do antigo agente de usuário do programa para proteger os dispositivos contra roubo pelo desenvolvedor do Absolute Software - LoJack. A ferramenta atraiu a atenção dos profissionais de segurança da informação devido ao uso do módulo UEFI / BIOS como mecanismo para garantir a persistência. Chamamos a versão trojanizada deste programa de LoJax .

A presença de ferramentas Sednit conhecidas em sistemas infectados, juntamente com amostras LoJax, bem como o fato de que alguns servidores de comando usados ​​por agentes trojanizados faziam parte da infraestrutura Sednit, permite associar de forma confiável um rootkit UEFI a esse grupo.

Juntamente com os agentes LoJax, foram descobertas ferramentas para ler o firmware do sistema UEFI e, em um dos casos, essa ferramenta poderia despejar, corrigir e reescrever parte da memória flash SPI do sistema. O objetivo final da ferramenta é instalar um módulo UEFI mal-intencionado em um sistema cuja proteção SPI flash é vulnerável ou configurada incorretamente.

O módulo UEFI é responsável pela implementação do agente LoJax no sistema; este é o primeiro rootkit identificado pela UEFI do grupo Sednit. Como está no firmware do sistema, ele pode sobreviver à reinstalação do Windows e à substituição do disco rígido.

Houve pelo menos um caso em que este rootkit foi instalado com sucesso na memória flash SPI do sistema. De acordo com nossas informações, este é o primeiro rootkit UEFI descoberto in-the-wild.

1. Introdução

O Sednit usa várias famílias de malware. Uma descrição detalhada das ferramentas de grupo usadas com freqüência que fornecemos no relatório .

Temos acompanhado a atividade da Sednit há vários anos e divulgamos muitos relatórios sobre o trabalho do grupo, desde descrições de vulnerabilidades de dia zero até programas personalizados como o Zebrocy . Os componentes descritos neste relatório formam um grupo separado.

Os rootkits UEFI foram descritos em relatórios de empresas de segurança da informação anteriormente. Por exemplo, o rkloader, que apareceu em uma apresentação sobre vazamento de dados na equipe de hackers, e o DerStarke, um implante no macOS EFI / UEFI download, dos documentos do Vault7 , são conhecidos . Estamos cientes da existência dessas ferramentas, no entanto, nenhum relatório de comprometimento da UEFI foi emitido pelos rootkits.

Agora, não apenas provamos o uso de firmware in-the-wild com o mal-intencionado módulo LoJax UEFI, mas também encontramos toda a gama de ferramentas que provavelmente foram usadas para instalá-lo. É interessante notar que o Sednit usa o kit de inicialização DownDelph, que foi usado em 2013 e 2014 para manter o Downdelph, um dos primeiros backdoors do Sednit em estágio inicial. A idéia é semelhante, mas na nova versão do UEFI, o uso de bootkits não é mais possível. Assim, esses dois componentes diferem significativamente no comportamento.

Este trabalho está dividido em três seções. No primeiro, analisaremos os primeiros estudos de segurança LoJack / Computrace e o potencial de uso malicioso do programa. A segunda seção é dedicada ao processo de pesquisa, que finalmente nos levou ao UEFI rootkit. Finalmente, na terceira seção, descrevemos em detalhes os vários componentes LoJax e como eles fornecem persistência no sistema, mesmo após a reinstalação do Windows e a substituição do disco rígido.

Atribuição

Embora muitos fornecedores já tenham feito declarações sobre o grupo Sednit no passado, a ESET de forma alguma determina sua afiliação geopolítica. Desde a publicação do estudo de 2016, nossa posição não mudou. Determinar a fonte de um ataque cibernético com base em uma abordagem científica é uma tarefa complexa que está além do escopo de competências dos especialistas da ESET. O que chamamos de "grupo Sednit" é apenas um conjunto de software e uma infraestrutura de rede associada que não podemos associar autoritariamente a nenhuma organização em particular.

Objetivos

Durante o estudo, encontramos um pequeno número de imagens LoJax diferentes. Com base em nossos dados de telemetria e em um estudo de outros programas Sednit descobertos na natureza, estamos confiantes de que esse módulo específico raramente foi usado em comparação com outras ferramentas. Os objetivos, principalmente, eram organizações estatais localizadas nos Balcãs, na Europa Central e Oriental.

Pesquisa sobre Computertrace / LoJack

LoJack - software para proteger computadores contra roubo e perda, desenvolvido pela Absolute Software Corporation. As versões anteriores do agente são conhecidas como Computrace. Como o nome anterior indica, após a ativação do serviço, o computador pode acessar seu servidor de comando - o proprietário será notificado sobre a localização do dispositivo em caso de perda ou roubo.

A seção abaixo descreve a arquitetura anterior do LoJack. Somente a versão antiga do software foi Trojaned por criminosos cibernéticos, portanto, focaremos nisso. Além disso, a Absolute Software lançou em maio de 2018 uma declaração informando que as vulnerabilidades descritas abaixo não afetam a operação das versões mais recentes de seus agentes.

O programa Computrace atraiu a atenção dos profissionais de segurança da informação porque usava um método incomum de garantir persistência. Seu objetivo é proteger contra roubo, portanto, é importante que seja resistente à reinstalação do SO e à substituição do disco rígido - tudo isso é implementado no módulo UEFI / BIOS que pode sobreviver após essas ações. A solução é pré-instalada no firmware de uma parte significativa de laptops de diferentes fabricantes, o usuário precisa apenas ativar esta função. A ativação pode ser feita no BIOS, como mostrado na figura abaixo.


Figura 1. Ativando o Computrace no BIOS

Um dos primeiros relatórios de implementação do LoJack / Computrace foi publicado em 2009. A arquitetura global do produto, a liberação do módulo UEFI / BIOS do agente do usuário em disco e a maneira como o agente se comunica com um servidor da Web controlado pela Absolute Software foram divulgadas. O diagrama pode ser entendido na figura abaixo.


Figura 2. Mecanismo de persistência LoJack (aproximadamente 2008)

A seguir, é apresentada uma descrição das etapas listadas acima:

1. Se ativado, o módulo UEFI / BIOS é executado no momento da inicialização. Ele está tentando encontrar a partição FAT / FAT32 / NTFS. Em seguida, usando o driver NTFS, ele cria um backup do arquivo autochk.exe e sobrescreve seu conteúdo com o conta-gotas, responsável pela instalação do componente do agente do usuário. O arquivo autochk.exe é um arquivo executável do Windows iniciado no estágio inicial da inicialização do sistema para verificar possíveis danos ao disco rígido.

2. Quando o autochk.exe modificado autochk.exe iniciado, seu objetivo principal é implementar o mini-agente rpcnetp.exe e adicioná-lo como um serviço, para que ele seja iniciado sempre que for reiniciado. A etapa final neste componente é restaurar a versão original do autochk.exe .

3. Mini-agente rpcnetp.exe - um pequeno arquivo executável, cujo objetivo é garantir a operação do agente principal. Se o agente primário não funcionar, o rpcnetp.exe tentará se conectar ao servidor de comando Absolute Software C&C para fazer o download e executá-lo. Primeiro, o mini-agente fará uma cópia de si mesmo e, em seguida, fará alterações no cabeçalho do PE para converter em uma DLL. Esta biblioteca é então carregada na memória, chama o processo svchost.exe e injeta a DLL lá. Em seguida, o processo do Internet Explorer iexplore.exe é iniciado e a DLL é injetada nele. O último processo será usado para comunicação pela Internet. A injeção de mini-agentes da Computrace em processos de terceiros geralmente é encontrada em malware e raramente é associada a software legítimo.

4. Agora, um agente totalmente funcional está em execução no sistema e pode usar as funções do Computrace para rastreamento e recuperação.

Uma descrição desse processo e o protocolo de rede envolvido entre o miniagente e o servidor C&C foi publicado em 2014. Devido à falta de um mecanismo de autenticação, se os invasores controlarem o servidor com o qual o mini-agente se comunica, eles podem forçá-lo a baixar código arbitrário. Existem vários mecanismos que permitem que os atacantes entrem em contato diretamente com o mini-agente. O mais importante para nós usa o método de obter o endereço do servidor C&C pelo mini-agente. De fato, essas informações são armazenadas no arquivo de configuração no próprio arquivo executável.


Figura 3. Arquivo de configuração de descriptografia parcial LoJack criptografada à direita

A figura mostra o arquivo de configuração do mini-agente LoJack. O método de "criptografia" usado é um XOR simples com uma chave de byte único. A tecla 0xB5 é a mesma para todos os mini-agentes estudados. Como pode ser visto na figura, o domínio C&C é especificado no arquivo Os quatro bytes anteriores contêm o endereço IP do servidor C&C. Na ausência de validação do conteúdo do arquivo de configuração, os invasores com permissões de gravação em %WINDIR% podem alterar seu conteúdo para que o mini-agente se comunique com seu servidor de comandos, em vez de legítimo. Compreendendo o protocolo de rede, você pode fazer o mini-agente baixar e executar código arbitrário. Esses riscos são conhecidos há muito tempo, mas até recentemente, o mecanismo não era usado na prática.

LoJack se transforma em LoJax

Em maio de 2018, as amostras Trobor do mini-agente LoJack, rpcnetp.exe, foram descritas no blog da Arbor Network. Suas configurações de rede codificadas foram alteradas para que amostras maliciosas estabelecessem uma conexão com o servidor C&C do invasor, em vez do servidor legítimo da Absolute Software. Alguns dos domínios encontrados nas amostras Trojanized foram atendidos anteriormente - eles foram usados ​​no final de 2017 como domínios de servidor C&C para o SedUploader, a porta dos fundos do primeiro estágio do cibergrupo Sednit. A figura abaixo mostra um exemplo de configuração modificada em um dos mini-agentes LoJax.


Figura 4. À esquerda, há um arquivo de configuração legítimo, à direita, um arquivo modificado

As diferenças entre agentes legítimos e trojanizados são extremamente pequenas, quase todas apresentadas acima. As amostras de mini-agentes LoJax que conseguimos encontrar são versões trojanizadas da mesma amostra de mini-agentes Computrace, rpcnetp.exe . Todos eles têm registros de data e hora de compilação idênticos e apenas algumas dezenas de bytes diferem do original. Além das alterações no arquivo de configuração, há diferenças nas variáveis ​​do cronômetro que determinam os intervalos entre as conexões com o servidor C&C.

No momento da publicação, descobrimos vários mini-agentes LoJax usados ​​em ataques a várias organizações nos Balcãs, na Europa Central e Oriental, mas não tínhamos idéias sobre como instalá-los. Uma explicação óbvia seria instalar usando um dos famosos backdoors Sednit. Não se esqueça que o LoJack, como uma ferramenta bem estabelecida, foi incluído na lista de permissões por muitos fornecedores de antivírus. Portanto, mesmo nesta campanha, apenas um miniagente foi usado e não sobreviveu após a reinstalação do Windows, ainda tinha uma vantagem - era menos provável que fosse detectado como malware. Mas e se o comprometimento fosse ainda mais profundo e os invasores tentassem copiar o LoJack para acessar o firmware do sistema?

Busca pelo componente de nível inferior

Registramos ataques LoJax destinados a várias organizações nos Balcãs, na Europa Central e Oriental. Em todos eles, conseguimos encontrar traços de malware Sednit, incluindo:

• SedUploader, backdoor do primeiro estágio
• XAgent, o principal backdoor de Sednit
• Xtunnel, uma ferramenta de proxy de rede que pode transferir qualquer tráfego de rede entre um servidor C&C na Internet e um computador de destino em uma rede local

Encontramos vestígios de ferramentas Sednit na maioria dos sistemas estudados que se tornaram alvos LoJax, bem como em alguns sistemas em que apenas LoJax estava presente. Pode-se supor que, em alguns casos, o LoJax tenha sido usado como uma ferramenta separada, provavelmente como um backdoor adicional para restaurar o acesso dos operadores Sednit à rede.

O backdoor do XAgent geralmente coloca módulos adicionais em um sistema comprometido, de modo que imediatamente se lembra que as amostras LoJax foram entregues da mesma maneira, sem outros mecanismos. Pode-se supor que a Sednit emprestou apenas um mini-agente da solução LoJack. No entanto, logo após o início da análise, encontramos várias evidências indicando que a fonte de inspiração era um pouco mais extensa.

Driver RWEverything (RwDrv) e info_efi.exe

A primeira evidência foi encontrada graças a uma ferramenta personalizada de cibercriminosos, que, quando executados, descarregavam informações sobre as configurações do sistema de nível inferior em um arquivo de texto. A ferramenta foi descoberta junto com algumas amostras de LoJax. A figura a seguir mostra um fragmento do arquivo de info_efi.exe desta ferramenta com o nome lógico info_efi.exe .


Figura 5. Trecho dos logs de arquivo gerados por info_efi .exe

Para ler esse tipo de informação, a ferramenta inclui um driver chamado RwDrv.sys . O driver do kernel vem com o RWEverything , um utilitário gratuito disponível na rede que pode ser usado para ler informações em quase todas as configurações de nível inferior, incluindo a interface PCI Express, memória, ROMs de opção PCI, etc. O driver do kernel é um software legítimo e é assinado com um certificado válido.


Figura 6. Certificado de assinatura de código RwDrv.sys

O RWEverything vem com uma interface gráfica do usuário que permite acessar todas essas informações.


Figura 7. Captura de tela da interface RWEverything

A descoberta da ferramenta info_efi foi o primeiro sinal de que um módulo UEFI LoJax poderia existir. Ao tentar atualizar o firmware do sistema, é importante ter informações sobre seu fornecedor, versão etc. Dadas as vulnerabilidades que permitem aos processos do usuário acessar e modificar o conteúdo da memória flash SPI onde os módulos UEFI estão armazenados, a obtenção de dados de firmware do sistema é o primeiro passo para um ataque bem-sucedido.

A pista final que nos permitiu encontrar o primeiro rootkit UEFI do grupo Sednit foram duas ferramentas - para descarregar a memória flash SPI e gravá-la.

Despejar o SPI Flash

A primeira peça do quebra-cabeça foi um arquivo chamado ReWriter_read.exe . Ele continha todo o código necessário para despejar o flash SPI do sistema usando o driver RwDrv.sys , RwDrv.sys . Para que o driver do dispositivo execute as operações necessárias, a ferramenta de despejo deve enviar os códigos de controle de E / S corretos (IOCTL). Enquanto o RwDrv.sys suporta muitos códigos IOCTL diferentes, a ferramenta de dumper e a ferramenta de RwDrv.sys descritas nesta e na próxima seção usam apenas quatro delas.

RwDrv.sys: códigos IOCTL suportados:

0x22280c - grava na área de memória alocada para E / S
0x222808 - lê a área de memória alocada para entrada e saída
0x222840 - lê o dword do registro de configuração PCI especificado
0x222834 - grava um byte no registro de configuração PCI especificado

ReWriter_read primeiro cria um serviço com o RwDrv.sys kernel RwDrv.sys e grava as informações de configuração UEFI / BIOS, os valores correspondentes dos três campos contidos no registro de gerenciamento do BIOS (BIOS_CNTL): BIOS Lock Enable (BLE), BIOS Write Enable (BIOSWE) e SMM BIOS Desativar proteção contra gravação (SMM_BWP). Embora ReWrite_read não use esses valores, nas seções a seguir explicaremos por que esses campos são de interesse para esta ferramenta.

A próxima tarefa da ferramenta é obter o endereço base da área de memória do BIOS no SPI e seu tamanho. Esta informação está contida no registro da interface SPI principal como região principal do BIOS Flash. Todos os registros são exibidos na memória no RCRB (Root Complex Register Block), cujo endereço base pode ser obtido através da leitura do registro de configuração PCI desejado. ReWriter_read obtém esse endereço usando RwDrv IOCTL 0x22840 e lendo o recuo correto (no nosso caso, 0xF0). Assim que o endereço base da área do BIOS e seu tamanho são conhecidos, a ferramenta de despejo lê o conteúdo correspondente da memória flash SPI e o grava em um arquivo no disco. O processo de leitura da memória flash SPI é ilustrado na figura a seguir. Definições de abreviações são fornecidas no glossário abaixo.


Figura 8. A sequência de leitura da memória flash SPI

Além das duas primeiras etapas, executadas apenas uma vez, as operações são repetidas em um ciclo até que todos os dados da memória flash SPI tenham sido lidos. O processo também é bem descrito aqui . Em seguida, ReWriter_read valida o tamanho da imagem mesclada. Ele analisa o descritor de memória de imagem para obter uma variedade de áreas BIOS, Gigabit Ethernet (GbE) e Management Engine (ME). A adição das dimensões dessas três áreas permite que a ferramenta de dumper calcule todo o conteúdo do SPI do flash. Se o tamanho corresponder ao tamanho obtido da leitura da área de registro do BIOS primário do Flash, a imagem será considerada correta.

Patch de firmware UEFI

A segunda peça do quebra-cabeça era um arquivo chamado ReWriter_binary.exe . Este arquivo contém evidências de que o Sednit chegou ao firmware. O arquivo contém código para aplicar o patch da imagem UEFI baixada e gravar a versão trojanizada na memória flash SPI. Nesta seção, descrevemos como esse arquivo binário está estruturado.

Depois que o conteúdo da memória flash é descarregado e verificado pela ferramenta acima, um módulo UEFI malicioso é adicionado à imagem. Para fazer isso, a imagem UEFI deve ser analisada para destacar as informações necessárias.

Os dados armazenados na imagem UEFI são decompostos em volumes por meio do sistema de arquivos (FFS). Como o nome indica, este é um sistema de arquivos especial para armazenar imagens de firmware. Os volumes contêm arquivos com GUIDs. Cada arquivo geralmente consiste em várias seções, uma das quais contém o PE / COFF executável real, que é uma imagem UEFI. Abaixo está uma captura de tela do UEFITool , um projeto de código aberto para trabalhar com imagens de firmware UEFI, para uma compreensão mais simples do circuito.


Figura 9. Exemplo de uma imagem de firmware UEFI carregada no UEFITool

ReWriter_binary analisa todos os volumes de firmware encontrados na área do BIOS SPI da memória flash e procura por arquivos específicos:

• IP4Dxe (8f92960f-2880-4659-b857-915a8901bdc8)
• NtfsDxe (768bedfd-7b4b-4c9f-b2ff-6377e3387243)
• SmiFlash (bc327dbd-b982-4f55-9f79-056ad7e987c5)
• Dxe core

Figura 10. O resultado do uso do descompilador Hex-Rays nos volumes de firmware

Ip4Dxe e NtfsDxe são drivers DXE. No firmware UEFI, os drivers DXE são imagens PE / COFF criadas para abstração de hardware ou para serviços de organização para uso por outros drivers DXE ou aplicativos UEFI. Esses drivers são detectados e baixados pela DXE Foundation por meio do DXE Manager (kernel DXE) em um estágio inicial do processo de inicialização. Após concluir esta fase, todos os serviços, como o carregador do SO, estão disponíveis para trabalhar com aplicativos UEFI. Normalmente, os drivers DXE são armazenados no mesmo volume. No entanto, o distribuidor DXE pode ser separado.

ReWriter_binary procura Ip4Dxe apenas para descobrir se um determinado volume contém drivers DXE. Como descrevemos mais adiante, esse volume se torna um candidato à instalação do driver DXE mal-intencionado. Ele também procura o kernel DXE e adiciona o volume no qual está localizado como outro candidato a um local para gravar um rootkit. O espaço disponível livre em cada um desses volumes é armazenado e posteriormente usado para verificar a suficiência para adicionar um driver mal-intencionado.

NtfsDxe - driver AMI NTFS DXE. Se ele estiver presente no volume do firmware, seu local será salvo e posteriormente usado para remover esse arquivo do volume. Na seção UEFI rootkit, veremos por que ele exclui este arquivo.

Quanto à imagem SmiFlash, as informações relacionadas a ela são armazenadas, mas não são usadas em nenhum lugar em Malvari. Curiosamente, a imagem é vulnerável . Portanto, acreditamos que os operadores da Sednit podem trabalhar para explorar essas vulnerabilidades. Isso pode permitir que eles gravem até sistemas configurados corretamente na memória flash SPI. Como veremos mais adiante, em sua forma atual, a ferramenta só pode gravar na área do BIOS de sistemas incorretamente configurados ou relativamente antigos (em placas-mãe com chipsets mais antigos que o Platform Controller Hub, lançado em 2008).

Depois que os metadados necessários são alocados, ReWriter_binary corrige o despejo da imagem UEFI e adiciona o driver DXE mal-intencionado. Primeiro, ele cria o cabeçalho do arquivo (EFI_FFS_FILE_HEADER). Ele então seleciona o volume de destino com base na localização do Ip4Dxe e no kernel DXE, bem como no espaço livre disponível nesses volumes. ReWriter_binary incorpora uma seção compactada que contém uma imagem do PE e uma seção da interface do usuário que define um nome de arquivo legível por humanos: SecDxe. A seção compactada é adicionada ao cabeçalho do arquivo e é gravada no final do volume, em espaço livre. A figura abaixo mostra a estrutura - sua exibição no UEFITool.


Figura 11. Visualização do arquivo SecDxe no UEFITool

Por fim, se o driver NtfsDxe estiver presente na imagem, ele será removido. O sistema de arquivos do firmware armazena arquivos e seu conteúdo sequencialmente, portanto, o processo é bastante simples:

• recuar para um espaço livre no final do volume
• Bytes 0xFF gravados na parte superior da imagem NtfsDxe
• a próxima parte do volume do firmware é copiada, começando com o recuo onde o NtfsDxe estava localizado
• o restante do sistema de arquivos é preenchido com 0xFF bytes, ou seja, espaço livre

Gravando firmware corrigido de volta na memória flash SPI

Após fazer alterações na imagem do firmware, a próxima etapa é gravá-la na memória flash SPI. Antes de mergulhar nesse processo, precisamos caracterizar parte da proteção contra gravação do BIOS que é importante nesse caso. Outros mecanismos existentes, como o BIOS Range Protection Protection, permanecem distantes porque o ReWriter_binary não os verifica.

A plataforma usa vários mecanismos de segurança para bloquear tentativas não autorizadas de gravar na área do BIOS. Devo dizer que esses mecanismos não estão habilitados por padrão. O firmware é responsável por sua configuração correta. Essas configurações são apresentadas no registro de controle do BIOS (BIOS_CNTL). Ele contém o bit BIOS Write Enable (BIOSWE), que deve ser alternado para "1" para gravar na área do BIOS da memória flash SPI. Como a plataforma não deve permitir nenhuma tentativa de gravação na área do BIOS, há mais um bit no BIOS_CNTL para proteger o BIOSWE - este é o BIOS Lock Enable (BLE). Quando definido, o mecanismo deve bloquear o bit BIOSWE e deixar o valor igual a "0". No entanto, a solução tem uma vulnerabilidade. Quando chega a solicitação de alterar o bit BIOSWE para "1", o bit BIOSWE para "1" e somente depois que a plataforma interrompe a tarefa usando SMI (System Management Interrupt), o código desse SMI altera o bit BIOSWE de volta para "0".

Existem muitos problemas nesta versão da solução.Em primeiro lugar, o processador SMI é deixado para os desenvolvedores de firmware. Portanto, se esse código não for implementado no firmware, o bit BLE será inútil, pois o bit BIOSWE não será definido como "0". Em segundo lugar, nesse caso, temos uma " vulnerabilidade de condição de corrida " que nos permite contornar completamente esse mecanismo, mesmo que o manipulador SMI seja implementado corretamente. Para explorar essa vulnerabilidade, um invasor precisa executar um thread que define continuamente o BIOSWE como "1", enquanto outro thread deve gravar dados na memória flash do SPI. De acordo com o trabalho de Kallenberg e Wojtchuk, esse ataque funciona em processadores com vários núcleos e também pode ser usado com sucesso em processadores de núcleo único com a tecnologia Hyper-Threading ativada.

Para resolver esse problema, um novo mecanismo de proteção configurado através do BIOS_CNTL foi adicionado à plataforma. É introduzido na família de chipsets do Intel Platform Controller Hub (PCH). Se o bit de configuração estiver definido, o SMM BIOS Write Protect Disable (SMM_BWP) somente permitirá a gravação na área do BIOS se todos os núcleos estiverem no Modo de Gerenciamento do Sistema (SMM) e o BIOSWE estiver definido como "1". Isso protege efetivamente o sistema da “vulnerabilidade de condição de corrida” descrita acima. No entanto, como no caso do BLE, o SMM_BWP deve ser ativado no lado do firmware. Portanto, o firmware no qual esses mecanismos estão configurados incorretamente deixa o sistema em risco de conceder direitos de gravação não autorizados à área do BIOS.

ReWriter_binarylê o conteúdo do registro de controle do BIOS para selecionar o caminho correto.

Ele primeiro verifica se o BIOSWE está configurado. Nesse caso, entra na fase de gravação. Se o BIOSWE estiver desativado, ele verifica o valor do bit BLE. Se não estiver instalado, ele altera o valor do bit BIOSWE e começa a gravar o firmware corrigido. Se o bit BLE estiver definido, ele verifica o estado desabilitado SMM_BWP e aplica a "vulnerabilidade de condição de corrida" descrita acima. Se o bit SMM_BWP estiver definido, a operação falhará. A figura abaixo ilustra o processo.


Figura 12. A árvore de decisão durante o processo de gravação

Supondo que o arquivo analisado específico foi ReWriter_binaryusado para implantar o UEFI rootkit, podemos concluir que o firmware configurou incorretamente a proteção contra gravação do BIOS ou o chipset da máquina vítima é mais antigo que o Platform Controller Hub.

ReWriter_binaryNão pude substituir o firmware UEFI em um sistema moderno bem ajustado. No entanto, ao procurar uma imagem vulnerável do SmiFlash UEFI, a análise dos volumes de firmware UEFI sugere que os invasores também podem trabalhar com técnicas mais avançadas de proteção contra gravação do BIOS .

De maneira muito semelhante ao procedimento de leitura, ocorre a gravação na memória flash SPI:


Figura 13. Sequência de gravação na memória flash SPI

Além das duas primeiras etapas, que são executadas apenas uma vez, essas operações são repetidas em um ciclo até que todas as informações sejam gravadas na memória flash SPI .

Quando o processo de gravação é concluído, o conteúdo da memória flash SPI é descarregado novamente em um arquivo image.bin. A mesma verificação de integridade que foi realizadaReWriter_read, é executado em uma nova imagem mesclada. Em seguida, a imagem lida na memória flash SPI é comparada com a imagem corrigida na memória.

Se algum bytes for diferente, seu endereço será gravado no log. A presença ou ausência de diferenças não afeta o progresso do malware. Essas informações são registradas apenas para que os operadores entendam o que está acontecendo.

No estágio final, a chave do Registro é definida como:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute = “autocheck autochk *”

Em seguida, o serviço RwDrv é parado e excluído. É importante que o valor dessa linha seja atribuído à chave de registro do Windows, pois o UEFI rootkit está procurando exatamente essa linha para alterá-la e executar seu componente durante a inicialização do Windows. Falaremos sobre isso com mais detalhes quando descrevermos o UEFI rootkit e seus componentes.

Análise Técnica LoJax

A ferramenta para descarregar, aplicar patches e gravar na memória flash SPI é personalizada para uma imagem de firmware específica e não pode ser usada em nenhum sistema. Nesse caso, o módulo UEFI completo pode ser alocado. A primeira coisa que fizemos após o recebimento deste módulo foi estudar os dados de telemetria para descobrir se já haviam sido vistos antes. Nisso, tivemos que confiar no novo scanner UEFI, que pode digitalizar o firmware do sistema. Descobrimos que o módulo UEFI do grupo Sednit foi instalado pelo menos uma vez no sistema, o que significa que esse rootkit é realmente usado in-the-wild.

Ainda não está estabelecido como as ferramentas maliciosas foram entregues aos sistemas comprometidos. Provavelmente, outros programas foram usados ​​para isso - por exemplo, XAgent. As ferramentas de despejo e gravação foram encontradas no mesmo sistema, mas em momentos diferentes - provavelmente, os operadores trabalharam em várias etapas. Primeiro, eles descarregaram o firmware na máquina de destino, certificaram-se de que a ferramenta para fazer ajustes no programa funcionasse sem falhas e, em seguida, recarregaram e, na verdade, corrigiram o firmware. Encontramos apenas uma versão da ferramenta para despejo e gravação, mas existe a possibilidade de existirem outras versões para outro firmware com vulnerabilidades que eles possam encontrar.

A figura abaixo fornece uma visão geral da operação do UEFI rootkit até a inicialização do SO. Primeiro, o driver SecDxe DXE é carregado pelo DXE Manager. Dessa forma, a função de notificação para o grupo de eventos está configurada EFI_EVENT_GROUP_READY_TO_BOOT. Quando o firmware estiver pronto para selecionar o dispositivo de inicialização e iniciar o carregador de inicialização, a função de notificação será chamada. Ela realiza três ações:

• carrega o driver NTFS DXE interno para fornecer acesso e capacidade de gravação para partições NTFS
• grava dois arquivos na partição NTFS do Windows: rpcnetp.exe e autoche.exe
• altera a chave do Registro 'HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ BootExecute': para: 'autocheck autochk *'; depois: 'autocheck autoche *'.

Figura 14. Processo de inicialização de um sistema infectado com um rootkit UEFI

SecDxe: Driver DXE malicioso

Nesta seção, revelaremos a sequência de eventos que ocorrem em um sistema comprometido. Começamos com uma descrição do rootkit e seguimos a cadeia de eventos até que os componentes finais sejam implementados no nível do sistema operacional.

O UEFI rootkit da Sednit é um driver DXE com um GUID 682894B5-6B70-4EBA-9E90-A607E5676297.

Como não está assinado, não pode ser executado em um sistema com a proteção de Inicialização Segura ativada. Após a implantação em um dos volumes de firmware, o DXE Foundation o baixa sempre que o sistema é iniciado.

O SecDxe é um pequeno driver DXE que basicamente faz duas coisas. Ele configura um protocolo específico para GUID.832d9b4d-d8d5-425f-bd52-5c5afb2c85dcque nunca é usado. Em seguida, ele cria um evento associado à função de notificação. A função de notificação está configurada para chamar um sinal por grupo EFI_EVENT_GROUP_READY_TO_BOOT. O sinal para esse grupo de eventos vem do gerenciador de inicialização quando estiver pronto para selecionar o dispositivo a ser inicializado.


Figura 15. O resultado do descompilador Hex-Rays passando pelo processo de criação de eventos

O recurso de notificação explora o comportamento mal-intencionado do UEFI Sednit rootkit. Ela grava componentes no sistema de arquivos NTFS Windows. Como regra, o firmware UEFI sozinho funciona com a partição do sistema EFI; portanto, o driver NTFS geralmente não está incluído. Somente sistemas de arquivos FAT são suportados como partições para download. Portanto, o firmware UEFI não vem necessariamente com os drivers NTFS. Por esse motivo, o SecDxe possui seu próprio driver NTFS interno. Este driver inicializa primeiro e se conecta ao dispositivo de disco. Ou seja, ele é instalado EFI_SIMPLE_FILE_SYSTEM_PROTOCOLem dispositivos de disco com partições NTFS, incluindo acesso a arquivos.

Agora que tudo está pronto para gravar arquivos nas partições do Windows, o SecDxe redefine rpcnetp.exee autoche.exe. Em seguida, é rpcnetp.exeinstalado %WINDIR%\SysWOW64nas versões de 64 bits do Windows ou%WINDIR%\System32nas versões de 32 bits. A está autoche.exedefinido como %WINDIR%\SysWOW64. A figura a seguir mostra o processo responsável por gravar esses arquivos no disco.


Figura 16. O resultado do descompilador Hex-Rays passando pelo processo de gravação de arquivos no disco e, em

seguida, o SecDxe abre um %WINDIR%\System32\config\SYSTEMarquivo com um backup de um conjunto de chaves do Registro HKLM\SYSTEM. Ele analisa o arquivo até encontrar 'autocheck autochk *'e substitui 'k'em 'autochk'on 'e'. Como resultado, ele 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ BootExecute'muda para 'autocheck autoche *'. Na próxima vez que o Windows inicializar, o autoche.exe será iniciado autochk.exe.

Driver NTFS da equipe de hackers

Como discutido anteriormente, o driver NTFS está embutido no módulo SecDxe. Há fortes evidências de que os operadores da Sednit não escreveram seu próprio driver, mas compilaram uma cópia do driver NTFS DXE anunciado da Equipe de Hacking.
O driver NTFS deles usa o projeto ntfs-3g como um kernel. Este é apenas um invólucro para fazê-lo funcionar como um driver UEFI DXE. O próprio arquivo INF do conjunto do driver da Hacking Team lista os nomes dos arquivos do projeto ntfs-3g. As linhas de código do driver SecDxe NTFS também listam muitos desses nomes de arquivo: É interessante observar que o caminho do projeto é o mesmo encontrado no vetor-edk, o projeto de desenvolvimento do Hacking Team EFI. Existe um subprojeto no vetor-edk

- c:\edk2\NtfsPkg\NtfsDxe\ntfs\inode.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\volume.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\bootsect.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\unistr.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\attrib.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\mft.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\index.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\cache.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\misc.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\dir.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\runlist.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\logfile.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\uefi_io.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\ntfsinternal.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\mst.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\lcnalloc.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\compress.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\bitmap.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\collate.c
- c:\edk2\NtfsPkg\NtfsDxe\ntfs\security.c

NtfsPkgcom um layout de diretório absolutamente idêntico. Os arquivos de origem do projeto ntfs-3g estão localizados no mesmo caminho de endereço. E embora os caminhos em si não sejam dignos de nota, acreditamos que isso não é uma mera coincidência.

Comparando o código fonte vazado para a rede com o que obtivemos na saída do descompilador Hex-Rays, torna-se óbvio que esse é o mesmo projeto. A figura abaixo mostra um exemplo de comparação de uma função NtfsDriverBindingStartretirada vector-edk/NtfsPkg/NtfsDxe/Ntfs.c. Os comentários do código HT original são removidos para melhor percepção. A lógica e a sequência de chamadas de função são as mesmas. Ambos os projetos ainda usam uma variável (LockedByMe) para salvar um estado bloqueado.


Figura 17. Comparação dos resultados na saída do driver Sednit do descompilador NTFS Hex-Rays (à esquerda) e do driver NTFS HT (à direita)

O código acima mostra os desenvolvedores da equipe de hackers, que não está no código aberto ntfs-3g. Conforme mencionado na seção ReWriter_binary, durante a análise do sistema de arquivos do firmware, o arquivo executável tenta remover o driver NTFS da AMI. Queríamos descobrir por que ele está sendo removido em vez de usado.

Analisamos o driver e descobrimos que ele só pode executar operações de leitura. Como a gravação no sistema de arquivos não está disponível, os desenvolvedores não puderam usá-lo para seus próprios fins. Também é provável que os operadores do Sednit tenham encontrado dificuldades devido ao fato de já haver outro driver NTFS no firmware, então eles decidiram simplesmente removê-lo. Além de implementar os recursos de leitura e gravação, o driver da Equipe de hackers não respeita as permissões de arquivo. Por exemplo, ele pode substituir um arquivo somente leitura sem causar nenhum erro.

Neste ponto, já descrevemos várias operações de comprometimento do sistema executadas pelo UEFI rootkit. Também discutimos as razões pelas quais os operadores Sednit usaram o código-fonte vector-edk da Hacking Team para desenvolver seu driver NTFS para gravar arquivos em partições NTFS no Windows. Mais adiante neste artigo, apresentaremos uma análise dos componentes fornecidos pelo SecDxe.

autoche.exe vs. autochk.exe

Mal-intencionado é autoche.exeusado para garantir a persistência do mini-agente rpcnetp.exe. Como você pode ver na figura a seguir, ele usa chamadas nativas para a API do Windows para criar um serviço.


Figura 18. O autoche malicioso .exe configura a persistência do rpcnetp.exe.

Observe que o nome do serviço é igual ao usado pelo agente legítimo do Computrace. Após criar o serviço, ele restaura o valor anterior da chave do Registro BootExecute.


Figura 19. O malicioso autoche.exe restaura o valor original da chave de registro BootExecute.Como

o processo ocorre durante a inicialização do Windows, é improvável que o usuário note uma alteração no valor da chave.BootExecute. Deve-se observar que no autoche .exe são visíveis algumas semelhanças com o módulo autochk.exe no Computrace, por exemplo, as chamadas de API aplicadas e o registro de serviços, mas o restante é bem diferente. O módulo Computrace é maior e restaura o arquivo executável original em autochk.exevez de alterar a chave do Registro. Ele também é responsável pela implantação do mini-agente em disco, enquanto LoJax faz isso com o UEFI rootkit.

rpcnetp.exe

Embora o mini-agente rpcnetp.exepossa ser implementado pelo UEFI rootkit, é provável que, na maioria dos casos, quando encontramos uma versão trojanizada do LoJack, o mini-agente não tenha usado esse componente. É provável que eles tenham procedido de considerações oportunistas e instalado o UEFI rootkit somente quando tiveram essa oportunidade e nas organizações mais interessantes para eles.

Durante a investigação, descobrimos várias versões do mini-agente LoJax. A lista de indicadores de comprometimento mostra seus hashes e os domínios / endereços IP correspondentes. Como já dissemos, todas as amostras encontradas foram uma versão trojanizada do mesmo antigo agente Computrace, compilado em 2008.

Nunca vimos um agente LoJax baixar e instalar módulos adicionais, mas sabemos que essa funcionalidade existe. Como as melhores qualidades do LoJax são discrição e persistência, ele pode definitivamente ser usado para fornecer acesso aos principais recursos.

Prevenção e recuperação de ataques

Para evitar um ataque, é necessário um ecossistema complexo que consiste em muitos componentes ativos. O primeiro mecanismo de segurança que pode bloquear esse ataque é a Inicialização segura. Quando a Inicialização segura está ativada, cada componente do firmware baixado mediante solicitação do firmware deve ser assinado corretamente, garantindo assim sua integridade. Recomendamos que você ative a função Inicialização segura, esta é a proteção básica contra ataques no firmware UEFI.

Como no software, o firmware UEFI sempre deve ser atualizado em tempo hábil. Visite o site do fabricante da placa-mãe para verificar se você possui a versão mais recente disponível.

Você também deve certificar-se de que todos os seus sistemas estejam equipados com chipsets modernos com o Platform Controller Hub (começando com os chipsets Intel Series 5 e além). Isso garantirá que os mecanismos de segurança funcionem contra a “vulnerabilidade das condições de corrida”, que, como indicamos , está presente na plataforma.

Outra parte da segurança do firmware está nas mãos dos fornecedores da UEFI / BIOS. Os mecanismos de segurança fornecidos pela plataforma devem ser corretamente configurados pelo firmware do sistema para garantir realmente sua proteção. Portanto, o firmware deve ser construído inicialmente com um entendimento das medidas de segurança. Felizmente, mais e mais pesquisadores de segurança estão prestando atenção à segurança do firmware, atraindo a atenção dos fornecedores. Também vale a pena mencionar a CHIPSEC, uma estrutura de código aberto que executa uma avaliação de segurança de baixo nível para determinar se a plataforma está configurada corretamente.

Eliminar as consequências do comprometimento via firmware UEFI é uma tarefa difícil. Não há maneiras fáceis de limpar o sistema contra essas ameaças e não há produtos de segurança especiais que possam corrigir tudo. No caso descrito aqui, para remover o rootkit, é necessário atualizar novamente a memória flash SPI. Esta é uma tarefa não trivial; não é adequada para o usuário médio. A atualização do firmware UEFI pode remover o rootkit se toda a área SPI da memória flash for reescrita. Se a interferência UEFI não for possível, a única solução é substituir a placa-mãe do sistema infectado.

Conclusões

O UEFI rootkit é uma das ferramentas mais perigosas e poderosas dos cibercriminosos devido à sua alta persistência e imunidade à reinstalação do sistema operacional e à substituição de um disco rígido, além da excepcional dificuldade de detecção e remoção. Embora a imagem UEFI do sistema seja difícil de alterar, poucas soluções permitem que você varra os módulos UEFI e identifique entre eles os maliciosos. Além disso, limpar o firmware UEFI significa atualizá-lo, o que não é uma operação comum que um usuário normal não possa executar. Esses benefícios explicam por que os cibergrupos com recursos ilimitados continuarão atacando os sistemas UEFI.

Para qualquer dúvida sobre este trabalho, entre em contato com ameaintel@eset.com

e queremos agradecer àqueles que estão trabalhando no projeto opensecuritytraining.info. CursoA introdução ao BIOS e SMM realmente nos ajudou quando analisamos as interações com o chip flash SPI.

Glossário

Consulte as especificações da Intel para obter uma descrição mais detalhada das abreviações.
- BIOS_CNTL: Registro de controle do BIOS
- BIOSWE: Gravação do BIOS ativada
- BLE: Bloqueio do BIOS ativado
- FADDR: Endereço do Flash
- FDATAX: Dados do Flash do FDATA0 ao FDATAN
- FDBC: Contagem de bytes de dados do Flash
- FGO: Ciclo de Flash Go
- HSFC: Sequência de hardware Controle de Flash
- HSFS: Status do Flash de Sequenciamento de Hardware
- IOCTL: Controle de Entrada / Saída
- PCH: Hub do Controlador de Plataforma
- RCBA: Registro de Endereço Base do Complexo Raiz
- RCRB: Bloco de Registro do Complexo Raiz
- SCIP: Ciclo de Registro do Complexo Raiz - SCIP: Ciclo SPI em andamento
- SMI: Interrupção de gerenciamento do sistema
- SMM: Modo de Gerenciamento do Sistema
- SMM_BWP: Desabilitação de proteção contra gravação de BIOS do SMM
- SPI: Interface Periférica Serial

Indicadores de compromisso

ReWriter_read.exe

Detecção ESET
Win32/SPIFlash.A
SHA-1
ea728abe26bac161e110970051e1561fd51db93b

ReWriter_binary.exe

Detecção ESET
Win32/SPIFlash.A
SHA-1
cc217342373967d1916cb20eca5ccb29caaf7c1b

Secdexe

Detecção ESET
EFI/LoJax.A
SHA-1
f2be778971ad9df2082a266bd04ab657bd287413

info_efi.exe

Detecção ESET
Win32/Agent.ZXZ
SHA-1
4b9e71615b37aea1eaeb5b1cfa0eee048118ff72

autoche.exe

Detecção ESET
Win32/LoJax.A
SHA-1
700d7e763f59e706b4f05c69911319690f85432e

EXE Mini Agent

Detecção ESET SHA-1
Win32/Agent.ZQE
Win32/Agent.ZTU

1771e435ba25f9cdfa77168899490d87681f2029
ddaa06a4021baf980a08caea899f2904609410b9
10d571d66d3ab7b9ddf6a850cb9b8e38b07623c0
2529f6eda28d54490119d2123d22da56783c704f
e923ac79046ffa06f67d3f4c567e84a82dd7ff1b
8e138eecea8e9937a83bffe100d842d6381b6bb1
ef860dca7d7c928b68c4218007fb9069c6e654e9
e8f07caafb23eff83020406c21645d8ed0005ca6
09d2e2c26247a4a908952fee36b56b360561984f
f90ccf57e75923812c2c1da9f56166b36d1482be

Nomes de domínio do servidor de comando

secao[.]org
ikmtrust[.]com
sysanalyticweb[.]com
lxwo[.]org
jflynci[.]com
remotepx[.]net
rdsnets[.]com
rpcnetconnect[.]com
webstp[.]com
elaxo[.]org

Endereços IP do servidor de comandos

185.77.129[.]106
185.144.82[.]239
93.113.131[.]103
185.86.149[.]54
185.86.151[.]104
103.41.177[.]43
185.86.148[.]184
185.94.191[.]65
86.106.131[.]54

Mini agente DLL

Nomes de domínio do servidor de comando ESET
Win32/Agent.ZQE
SHA-1 Endereços IP do
397d97e278110a48bd2cb11bb5632b99a9100dbd
servidor de comando
elaxo.org

86.106.131[.]54