LoJax: el primer rootkit UEFI conocido utilizado en una campaña maliciosa

Sednit Cybergroup, también conocido como ART28, Strontium y Fancy Bear, ha estado operando desde al menos 2004. Se cree que el grupo está detrás de una serie de ciberataques resonantes. Algunas empresas del IB y el Departamento de Justicia de EE. UU. Han llamado a Sednit responsable de piratear el Comité Nacional Demócrata antes de las elecciones estadounidenses de 2016. Al grupo se le atribuye el pirateo de la red de televisión global TV5Monde, la filtración de correos electrónicos de la Agencia Mundial Antidopaje (AMA) y otros incidentes. Sednit tiene muchos objetivos y una amplia gama de herramientas, algunas de las cuales ya hemos documentado anteriormente, pero por primera vez en este trabajo describiremos en detalle el uso del rootkit UEFI.

Breve reseña

Descubrimos que, al menos desde principios de 2017, Sednit ha estado utilizando una versión troyanizada del antiguo agente de usuario del programa para proteger los dispositivos contra el robo por parte del desarrollador de Absolute Software - LoJack. La herramienta atrajo la atención de los profesionales de seguridad de la información debido al uso del módulo UEFI / BIOS como mecanismo para garantizar la persistencia. Llamamos a la versión trojanizada de este programa LoJax .

La presencia de herramientas Sednit bien conocidas en sistemas infectados junto con muestras de LoJax, así como el hecho de que algunos servidores de comando utilizados por agentes trojanizados anteriormente formaban parte de la infraestructura de Sednit, nos permiten asociar el rootkit UEFI con este grupo con gran confianza.

Junto con los agentes de LoJax, se encontraron herramientas para leer el firmware del sistema UEFI, y en uno de los casos esta herramienta podría volcar, parchear y reescribir parte de la memoria flash SPI del sistema. El objetivo final de la herramienta es instalar un módulo UEFI malicioso en un sistema cuya protección SPI flash es vulnerable o está configurada incorrectamente.

El módulo UEFI es responsable de implementar el agente LoJax en el sistema; este es el primer rootkit identificado por UEFI del grupo Sednit. Como está en el firmware del sistema, puede sobrevivir reinstalando Windows y reemplazando el disco duro.

Hubo al menos un caso cuando este rootkit se instaló correctamente en la memoria flash SPI del sistema. Según nuestra información, este es el primer rootkit UEFI descubierto en la naturaleza.

Introduccion

Sednit utiliza una serie de familias de malware. Una descripción detallada de las herramientas grupales de uso frecuente que proporcionamos en el informe .

Hemos estado siguiendo la actividad de Sednit durante varios años y hemos publicado muchos informes sobre el trabajo del grupo, desde descripciones de vulnerabilidades de día cero hasta programas personalizados como Zebrocy . Los componentes descritos en este informe forman un grupo separado.

Los rootkits UEFI han sido descritos en informes de compañías de seguridad de la información anteriormente. Por ejemplo, se conoce rkloader, que apareció en una presentación sobre la fuga de datos en el Equipo de Hacking, y DerStarke, un implante en la descarga macFI EFI / UEFI, de documentos Vault7 . Somos conscientes de la existencia de estas herramientas, sin embargo, los rootkits no han emitido informes de compromiso UEFI.

Ahora no solo probamos el uso del firmware in-the-wild con el módulo malicioso LoJax UEFI, sino que también encontramos toda la gama de herramientas que probablemente se usaron para instalarlo. Es interesante observar que Sednit usa el kit de arranque DownDelph, que se usó en 2013 y 2014 para mantener Downdelph, una de las puertas traseras Sednit de la primera etapa. La idea es similar, pero en la nueva versión de UEFI, el uso de bootkits ya no es posible. Por lo tanto, estos dos componentes difieren significativamente en el comportamiento.

Este trabajo se divide en tres secciones. En el primero, analizaremos los primeros estudios sobre la seguridad de LoJack / Computrace y el potencial uso malicioso del programa. La segunda sección está dedicada al proceso de investigación, que finalmente nos llevó al rootkit UEFI. Finalmente, en la tercera sección, describimos en detalle los diversos componentes de LoJax y cómo proporcionan persistencia en el sistema incluso después de reinstalar Windows y reemplazar el disco duro.

Atribución

Si bien muchos proveedores ya han hecho declaraciones sobre el grupo Sednit en el pasado, ESET de ninguna manera determina su afiliación geopolítica. Desde la publicación del estudio de 2016, nuestra posición no ha cambiado. Determinar la fuente de un ciberataque basado en un enfoque científico es una tarea compleja que está más allá del alcance de las competencias de los especialistas de ESET. Lo que llamamos el "grupo Sednit" es solo un conjunto de software y una infraestructura de red asociada que no podemos asociar con autoridad con ninguna organización en particular.

Objetivos

Durante el estudio, encontramos una pequeña cantidad de diferentes imágenes de LoJax. Según nuestros datos de telemetría y un estudio de otros programas de Sednit descubiertos en la naturaleza, estamos seguros de que este módulo en particular rara vez se usó en comparación con otras herramientas. Los objetivos, principalmente, eran organizaciones estatales ubicadas en los Balcanes, en Europa Central y Oriental.

Early Computertrace / LoJack Research

LoJack: software para proteger las computadoras del robo y la pérdida, desarrollado por Absolute Software Corporation. Las primeras versiones del agente se conocen como Computrace. Como lo indica el nombre anterior, después de activar el servicio, la computadora puede acceder a su servidor de comandos: se notificará al propietario sobre la ubicación del dispositivo en caso de pérdida o robo.

La siguiente sección describe la arquitectura anterior de LoJack. Solo la versión anterior del software fue troyada por ciberdelincuentes, por lo que nos centraremos en ello. Además, Absolute Software lanzó en mayo de 2018 una declaración que indica que las vulnerabilidades descritas a continuación no afectan el funcionamiento de las últimas versiones de sus agentes.

El programa Computrace atrajo la atención de los profesionales de seguridad de la información porque utilizaba un método inusual para garantizar la persistencia. Su propósito es proteger contra el robo, por lo tanto, es importante que sea resistente a reinstalar el sistema operativo y reemplazar el disco duro; todo esto se implementa en el módulo UEFI / BIOS que puede sobrevivir después de estas acciones. La solución está preinstalada en el firmware de una parte importante de las computadoras portátiles de diferentes fabricantes, el usuario solo necesita activar esta función. La activación se puede hacer en el BIOS, como se muestra en la figura a continuación.


Figura 1. Activando Computrace en el BIOS

Uno de los primeros informes de implementación de LoJack / Computrace se publicó en 2009. Se reveló la arquitectura global del producto, el vaciado del módulo UEFI / BIOS del agente de usuario en el disco y la forma en que el agente se comunica con un servidor web controlado por Absolute Software. El diagrama se puede entender a partir de la figura a continuación.


Figura 2. Mecanismo de persistencia LoJack (aproximadamente 2008)

La siguiente es una descripción de los pasos enumerados anteriormente:

1. Si está activado, el módulo UEFI / BIOS se ejecuta en el momento del arranque. Él está tratando de encontrar la partición FAT / FAT32 / NTFS. Luego, utilizando el controlador NTFS, crea una copia de seguridad del archivo autochk.exe y sobrescribe su contenido con el cuentagotas, que es responsable de instalar el componente de agente de usuario. El archivo autochk.exe es un archivo ejecutable de Windows que se inicia en una etapa temprana del arranque del sistema para verificar posibles daños en el disco duro.

2. Cuando se inicia el autochk.exe modificado, su objetivo principal es implementar el mini agente rpcnetp.exe y agregarlo como un servicio para que se inicie cada vez que se reinicie. El último paso en este componente es restaurar la versión original de autochk.exe .

3. Mini-agente rpcnetp.exe : un pequeño archivo ejecutable cuyo propósito es garantizar el funcionamiento del agente principal. Si el agente primario no funciona, rpcnetp.exe intenta conectarse al servidor de comandos de Absolute Software C&C para descargarlo y ejecutarlo. Primero, el mini agente hará una copia de sí mismo, luego realizará cambios en el encabezado PE para convertirlo a un archivo DLL. Esta biblioteca se carga en la memoria, llama al proceso svchost.exe e inyecta la DLL allí. A continuación, se inicia el proceso iexplore.exe Internet Explorer y se inyecta el archivo DLL. Este último proceso se utilizará para la comunicación a través de Internet. La inyección de miniagente de Computrace en procesos de terceros a menudo se encuentra en malware y rara vez se asocia con software legítimo.

4. Ahora se está ejecutando un agente completamente funcional en el sistema y puede usar las funciones de Computrace para el seguimiento y la recuperación.

En 2014 se publicó una descripción de este proceso y el protocolo de red involucrado entre el mini agente y el servidor C&C. Debido a la falta de un mecanismo de autenticación, si los atacantes controlan el servidor con el que se comunica el mini agente, pueden obligarlo a descargar código arbitrario. Existen varios mecanismos que permiten a los atacantes contactar al mini agente directamente. El más importante para nosotros utiliza el método de obtención de la dirección del servidor C&C por parte del mini agente. De hecho, esta información se almacena en el archivo de configuración en el archivo ejecutable.


Figura 3. Archivo de configuración de descifrado parcial LoJack cifrado a la derecha

La figura muestra el archivo de configuración del mini agente LoJack. El método de "cifrado" utilizado es un XOR simple con una clave de un solo byte. La tecla 0xB5 es la misma para todos los mini agentes estudiados. Como se puede ver en la figura, el dominio C&C se especifica en el archivo. Los cuatro bytes anteriores contienen la dirección IP del servidor C&C. En ausencia de validación en el contenido del archivo de configuración, los atacantes con permisos de escritura en %WINDIR% pueden cambiar su contenido para que el mini agente se comunique con su servidor de comandos, en lugar de ser legítimo. Al comprender el protocolo de red, puede hacer que el mini agente descargue y ejecute código arbitrario. Estos riesgos se conocen desde hace mucho tiempo, pero hasta hace poco, el mecanismo no se usaba en la práctica.

LoJack se convierte en LoJax

En mayo de 2018, las muestras de Trobor del mini agente LoJack, rpcnetp.exe, se describieron en el blog de Arbor Network. Su configuración de red codificada se cambió para que las muestras maliciosas establecieran una conexión con el servidor C&C del atacante en lugar del servidor legítimo Absolute Software. Algunos de los dominios encontrados en las muestras troyanizadas se conocieron antes; se usaron a fines de 2017 como dominios de servidor C&C para SedUploader, la puerta trasera de la primera etapa del cibergrupo Sednit. La figura a continuación muestra un ejemplo de una configuración modificada en uno de los mini agentes LoJax.


Figura 4. A la izquierda hay un archivo de configuración legítimo, a la derecha hay un archivo modificado.

Las diferencias entre agentes legítimos y troyanizados son extremadamente pequeñas, casi todas se mencionan anteriormente. Las muestras de miniagente de LoJax que pudimos encontrar son versiones troyanizadas de la misma muestra de rpcnetp.exe Computrace, rpcnetp.exe . Todos tienen marcas de tiempo de compilación idénticas y solo unas pocas docenas de bytes difieren del original. Además de los cambios en el archivo de configuración, existen diferencias en las variables del temporizador que determinan los intervalos entre las conexiones al servidor C&C.

En el momento de la publicación, descubrimos varios mini-agentes LoJax utilizados en ataques contra varias organizaciones en los Balcanes, en Europa Central y Oriental, pero no teníamos ideas sobre cómo instalarlos. Una explicación obvia sería instalar usando una de las famosas puertas traseras de Sednit. No olvide que LoJack, como herramienta bien establecida, ha sido incluido en la lista blanca por muchos proveedores de antivirus. Por lo tanto, incluso si en esta campaña solo se utilizó un mini agente que no sobrevivió después de reinstalar Windows, todavía tenía una ventaja: era menos probable que se detectara como malware. Pero, ¿qué pasaría si el compromiso fuera aún más profundo y los atacantes intentaran copiar LoJack para acceder al firmware del sistema?

Caza para el componente de nivel inferior

Grabamos ataques LoJax dirigidos a varias organizaciones en los Balcanes, en Europa Central y Oriental. En todos ellos, logramos encontrar rastros de malware Sednit, que incluyen:

• SedUploader, puerta trasera de primera etapa
• XAgent, la puerta trasera insignia de Sednit
• Xtunnel, una herramienta de proxy de red que puede transferir cualquier tráfico de red entre un servidor C&C en Internet y una computadora de destino en una red local

Encontramos rastros de herramientas Sednit en la mayoría de los sistemas estudiados que se convirtieron en objetivos LoJax, así como en un par de sistemas donde solo estaba presente LoJax. Se puede suponer que en algunos casos LoJax se usó como una herramienta separada, probablemente como una puerta trasera adicional para restaurar el acceso de los operadores de Sednit a la red.

La puerta trasera de XAgent generalmente coloca módulos adicionales en un sistema comprometido, por lo que inmediatamente viene a la mente que las muestras de LoJax se entregaron de la misma manera, sin ningún otro mecanismo. Se podría suponer que Sednit tomó prestado solo un mini agente de la solución LoJack. Sin embargo, poco después del inicio del análisis, encontramos varias pruebas que indican que la fuente de inspiración era algo más extensa.

Controlador RWEverything (RwDrv) e info_efi.exe

La primera evidencia se encontró gracias a una herramienta personalizada de ciberdelincuentes, quienes, cuando se ejecutaron, descargaron información sobre la configuración del sistema de nivel inferior en un archivo de texto. La herramienta fue descubierta junto con algunas muestras de LoJax. La siguiente figura muestra un fragmento del archivo de info_efi.exe de esta herramienta con el nombre lógico info_efi.exe .


Figura 5. Extracto de los registros de archivos generados por info_efi .exe

Para leer este tipo de información, la herramienta incluye un controlador llamado RwDrv.sys . El controlador del kernel viene con RWEverything , una utilidad gratuita disponible en la red que se puede usar para leer información en casi todas las configuraciones de nivel inferior, incluida la interfaz PCI Express, memoria, ROM de opciones PCI, etc. El controlador del núcleo es un software legítimo y está firmado con un certificado válido.


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

RWEverything viene con una interfaz gráfica de usuario que le permite acceder a toda esta información.


Figura 7. Captura de pantalla de la interfaz RWEverything

El descubrimiento de la herramienta info_efi fue la primera señal de que podría existir un módulo UEFI LoJax. Al intentar actualizar el firmware del sistema, es importante tener información sobre su proveedor, versión, etc. Dadas las vulnerabilidades que permiten que los procesos del usuario accedan y modifiquen el contenido de la memoria flash SPI donde se almacenan los módulos UEFI, la obtención de datos de firmware del sistema es el primer paso para un ataque exitoso.

La pista final que nos permitió encontrar el primer rootkit UEFI del grupo Sednit fueron dos herramientas: descargar la memoria flash SPI y escribir en ella.

Volcar SPI Flash

La primera pieza del rompecabezas fue un archivo llamado ReWriter_read.exe . Contenía todo el código requerido para volcar el flash SPI del sistema utilizando el controlador RwDrv.sys , RwDrv.sys . Para que el controlador del dispositivo realice las operaciones necesarias, la herramienta de volcado debe enviar los códigos de control de E / S (IOCTL) correctos. Si bien RwDrv.sys admite muchos códigos IOCTL diferentes, la herramienta de volcado y la herramienta de RwDrv.sys descritas en esta y en la siguiente sección usan solo cuatro de ellas.

RwDrv.sys: códigos IOCTL admitidos:

0x22280c : escribe en el área de memoria asignada para E / S
0x222808 : lee el área de memoria asignada para entrada-salida
0x222840 : lee dword del registro de configuración PCI especificado
0x222834 : escribe un byte en el registro de configuración PCI especificado

ReWriter_read primero crea un servicio con el RwDrv.sys kernel RwDrv.sys y escribe la información de configuración UEFI / BIOS, los valores correspondientes de los tres campos contenidos en el registro de administración del BIOS (BIOS_CNTL): BIOS Lock Enable (BLE), BIOS Write Enable (BIOSWE) y SMM BIOS Protección contra escritura deshabilitada (SMM_BWP). Aunque ReWrite_read no utiliza estos valores, en las siguientes secciones explicaremos por qué estos campos son de interés para esta herramienta.

La siguiente tarea de la herramienta es obtener la dirección base del área de memoria del BIOS en SPI y su tamaño. Esta información está contenida en el registro de la interfaz SPI principal como BIOS Flash Primary Region. Todos los registros se muestran en la memoria en el Root Complex Register Block (RCRB), cuya dirección base se puede obtener leyendo el registro de configuración PCI deseado. ReWriter_read obtiene esta dirección utilizando RwDrv IOCTL 0x22840 y leyendo la sangría correcta (en nuestro caso, 0xF0). Tan pronto como se conoce la dirección base del área del BIOS y su tamaño, la herramienta de volcado lee el contenido correspondiente de la memoria flash SPI y lo escribe en un archivo en el disco. El proceso de lectura de la memoria flash SPI se ilustra en la siguiente figura. Las definiciones de abreviaturas se dan en el glosario a continuación.


Figura 8. La secuencia de lectura de la memoria flash SPI

Además de los dos primeros pasos, ejecutados solo una vez, las operaciones se repiten en un ciclo hasta que se hayan leído todos los datos de la memoria flash SPI. El proceso también está bien descrito aquí . Luego ReWriter_read valida el tamaño de la imagen fusionada. Analiza el descriptor de memoria de imagen para obtener una variedad de áreas de BIOS, Gigabit Ethernet (GbE) y Management Engine (ME). Agregar las dimensiones de estas tres áreas permite que la herramienta de volcado calcule todo el contenido del SPI flash. Si el tamaño coincide con el tamaño obtenido al leer el área de registro del BIOS primario Flash, la imagen se considera correcta.

Parche de firmware UEFI

La segunda pieza del rompecabezas era un archivo llamado ReWriter_binary.exe . Este archivo contiene evidencia de que Sednit llegó al firmware. El archivo contiene código para aplicar el parche de la imagen UEFI descargada y volver a escribir la versión trojanizada en la memoria flash SPI. En esta sección, describimos cómo está estructurado este archivo binario.

Una vez que la herramienta anterior descarga y verifica el contenido de la memoria flash, se agrega un módulo UEFI malicioso a la imagen. Para hacer esto, la imagen UEFI debe analizarse para resaltar la información necesaria.

Los datos almacenados en la imagen UEFI se descomponen en volúmenes a través del sistema de archivos (FFS). Como su nombre lo indica, este es un sistema de archivos especial para almacenar imágenes de firmware. Los volúmenes contienen archivos con GUID. Cada archivo generalmente consta de muchas secciones, una de las cuales contiene el PE / COFF ejecutable real, que es una imagen UEFI. A continuación se muestra una captura de pantalla de UEFITool , un proyecto de código abierto para trabajar con imágenes de firmware UEFI, para una comprensión más simple del circuito.


Figura 9. Ejemplo de una imagen de firmware UEFI cargada en UEFITool

ReWriter_binary analiza todos los volúmenes de firmware encontrados en el área BIOS SPI de la memoria flash y busca archivos específicos:

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

Figura 10. El resultado del uso del descompilador Hex-Rays en los volúmenes de firmware

Ip4Dxe y NtfsDxe son controladores DXE. En el firmware UEFI, los controladores DXE son imágenes PE / COFF creadas para abstracción de hardware o para organizar servicios para su uso por otros controladores DXE o aplicaciones UEFI. DXE Foundation detecta y descarga dichos controladores a través del Administrador de DXE (núcleo DXE) en una etapa temprana del proceso de arranque. Después de completar esta fase, todos los servicios, como el cargador del sistema operativo, están disponibles para trabajar con aplicaciones UEFI. Por lo general, los controladores DXE se almacenan en el mismo volumen. Sin embargo, el despachador DXE puede estar separado.

ReWriter_binary busca Ip4Dxe solo para averiguar si un volumen dado contiene controladores DXE. Como describimos más adelante, este volumen se convierte en candidato para instalar el controlador DXE malicioso. También busca el núcleo DXE y agrega el volumen en el que se encuentra como otro candidato para un lugar donde registrar un rootkit. El espacio libre disponible en cada uno de estos volúmenes se almacena y luego se utiliza para verificar la suficiencia para agregar un controlador malicioso.

NtfsDxe: controlador AMI NTFS DXE. Si está presente en el volumen del firmware, su ubicación se guarda y luego se utiliza para eliminar este archivo del volumen. En la sección UEFI rootkit, veremos por qué elimina este archivo.

En cuanto a la imagen SmiFlash, la información relacionada con ella se almacena, pero no se usa en ningún lugar de Malvari. Curiosamente, la imagen es vulnerable . Por lo tanto, creemos que los operadores de Sednit pueden trabajar para explotar estas vulnerabilidades. Esto puede permitirles escribir incluso sistemas configurados correctamente en la memoria flash SPI. Como diremos más adelante, en su forma actual, la herramienta solo puede escribir en el área de BIOS de sistemas configurados incorrectamente o bastante antiguos (en placas base con conjuntos de chips más antiguos que el Platform Controller Hub, introducido alrededor de 2008).

Después de asignar los metadatos necesarios, ReWriter_binary parchea el volcado de la imagen UEFI y agrega el controlador DXE malicioso. Primero, crea el encabezado del archivo (EFI_FFS_FILE_HEADER). Luego selecciona el volumen de destino en función de la ubicación de Ip4Dxe y el núcleo DXE, así como el espacio libre disponible en estos volúmenes. ReWriter_binary incorpora una sección comprimida que contiene una imagen PE y una sección de interfaz de usuario que define un nombre de archivo legible para humanos: SecDxe. La sección comprimida se agrega al encabezado del archivo y se escribe al final del volumen, en el espacio libre. La siguiente figura muestra la estructura, su visualización en UEFITool.


Figura 11. Vista del archivo SecDxe en UEFITool

Finalmente, si el controlador NtfsDxe está presente en la imagen, se eliminará. El sistema de archivos de firmware almacena los archivos y su contenido secuencialmente, por lo que el proceso es bastante simple:

• sangría a un espacio libre al final del volumen
• 0xFF bytes escritos encima de la imagen NtfsDxe
• se copia la siguiente parte del volumen del firmware, comenzando con la sangría donde se encontraba NtfsDxe
• el resto del sistema de archivos está lleno de bytes 0xFF, es decir, espacio libre

Escribir firmware parcheado en la memoria flash SPI

Después de realizar con éxito los cambios en la imagen del firmware, el siguiente paso es volver a escribirla en la memoria flash SPI. Antes de sumergirnos en este proceso, debemos caracterizar algunas de las protecciones de escritura del BIOS que son importantes en este caso. Otros mecanismos existentes, como el BIOS Range Protection Protection, permanecen distantes porque ReWriter_binary no los verifica.

La plataforma utiliza varios mecanismos de seguridad para bloquear los intentos no autorizados de escribir en el área del BIOS. Debo decir que estos mecanismos no están habilitados por defecto. El firmware es responsable de su configuración correcta. Estas configuraciones se presentan en el registro de control del BIOS (BIOS_CNTL). Contiene el bit de habilitación de escritura de BIOS (BIOSWE), que debe cambiarse a "1" para escribir en el área de BIOS de la memoria flash SPI. Dado que la plataforma no debe permitir ningún intento de escribir en el área de BIOS, hay un bit más en BIOS_CNTL para proteger BIOSWE: esto es BIOS Lock Enable (BLE). Cuando se establece, el mecanismo debe bloquear el bit BIOSWE y dejar el valor igual a "0". Sin embargo, la solución tiene una vulnerabilidad. Cuando la solicitud llega a cambiar el bit BIOSWE a "1", el bit BIOSWE a "1", y solo después de que la plataforma interrumpe la tarea mediante la interrupción de administración del sistema (SMI), el código para este SMI cambia el bit BIOSWE a "0".

Hay muchos problemas en esta versión de la solución.En primer lugar, el procesador SMI se deja para los desarrolladores de firmware. Por lo tanto, si este código no se implementa en el firmware, el bit BLE es inútil, ya que el bit BIOSWE no se volverá a establecer en "0". En segundo lugar, en este caso, tenemos una " vulnerabilidad de condición de carrera " que nos permite eludir completamente este mecanismo, incluso si el controlador SMI se implementa correctamente. Para aprovechar esta vulnerabilidad, un atacante debe ejecutar un subproceso que establece continuamente el BIOSWE en "1", mientras que otro subproceso debe escribir datos en la memoria flash SPI. Según el trabajo de Kallenberg y Wojtchuk, este ataque funciona en procesadores multinúcleo y también se puede utilizar con éxito en procesadores de un solo núcleo con tecnología Hyper-Threading habilitada.

Para resolver este problema, se agregó a la plataforma un nuevo mecanismo de protección configurado a través de BIOS_CNTL. Se introduce en la familia de conjuntos de chips del Intel Platform Controller Hub (PCH). Si se establece el bit de configuración, el SMM BIOS Write Protect Disable (SMM_BWP) solo permitirá escribir en el área del BIOS si todos los núcleos están en Modo de administración del sistema (SMM) y el BIOSWE está configurado en "1". Esto protege eficazmente el sistema de la "vulnerabilidad de condición de carrera" descrita anteriormente. Sin embargo, como en el caso de BLE, SMM_BWP debe activarse desde el lado del firmware. Por lo tanto, el firmware en el que estos mecanismos están configurados incorrectamente deja al sistema en riesgo de otorgar derechos de escritura no autorizados al área del BIOS.

ReWriter_binarylee el contenido del registro de control del BIOS para seleccionar la ruta correcta.

Primero verifica si BIOSWE está configurado. Si es así, entra en la fase de grabación. Si BIOSWE está deshabilitado, verifica el valor del bit BLE. Si no está instalado, cambia el valor del bit BIOSWE y comienza a grabar el firmware parcheado. Si se establece el bit BLE, comprueba el estado deshabilitado SMM_BWP y aplica la "vulnerabilidad de condición de carrera" descrita anteriormente. Si se establece el bit SMM_BWP, la operación falla. La siguiente figura ilustra el proceso.


Figura 12. El árbol de decisión durante el proceso de grabación

Suponiendo que el archivo analizado en particular se ReWriter_binaryutilizó para implementar el rootkit UEFI, podemos concluir que el firmware configuró incorrectamente la protección de escritura del BIOS o que el conjunto de chips de la máquina víctima es más antiguo que el Hub del controlador de plataforma.

ReWriter_binaryNo pude reemplazar el firmware UEFI en un sistema moderno bien ajustado. Sin embargo, al buscar una imagen vulnerable de SmiFlash UEFI, analizar los volúmenes de firmware UEFI sugiere que los atacantes también podrían trabajar con técnicas de protección de omisión de escritura de BIOS más avanzadas .

De manera muy similar al procedimiento de lectura, se escribe en la memoria flash SPI:


Figura 13. Secuencia de escritura en la memoria flash SPI

Además de los dos primeros pasos, que se realizan solo una vez, estas operaciones se repiten en un ciclo hasta que toda la información se escriba en la memoria flash SPI .

Cuando se completa el proceso de grabación, los contenidos de la memoria flash SPI se descargan nuevamente a un archivo image.bin. La misma verificación de integridad que se realizóReWriter_read, se ejecuta en una nueva imagen combinada. Luego, la imagen leída de la memoria flash SPI se compara con la imagen parcheada en la memoria.

Si alguno de los bytes es diferente, su dirección se escribe en el registro. La presencia o ausencia de diferencias no afecta el progreso del malware. Esta información solo se registra para que los operadores entiendan lo que está sucediendo.

En la etapa final, la clave de registro se establece en:

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

Luego, el servicio RwDrv se detiene y se elimina. Es importante que el valor de esta línea se asigne a la clave de registro de Windows, ya que el rootkit UEFI está buscando exactamente esta línea para cambiarla y ejecutar su componente durante el inicio de Windows. Hablaremos de esto con más detalle cuando describamos el rootkit UEFI y sus componentes.

Análisis Técnico LoJax

La herramienta para descargar, parchar y escribir en la memoria flash SPI está personalizada para una imagen de firmware específica y no se puede usar en ningún sistema. En este caso, se puede distinguir el módulo UEFI completo. Lo primero que hicimos después de recibir este módulo fue estudiar los datos de telemetría para averiguar si se habían visto antes. En esto, tuvimos que confiar en el nuevo escáner UEFI, que puede escanear el firmware del sistema. Descubrimos que el módulo UEFI del grupo Sednit se instaló al menos una vez en el sistema, lo que significa que este rootkit se usa realmente en la naturaleza.

Todavía no se ha establecido cómo se entregaron herramientas maliciosas a los sistemas comprometidos. Lo más probable es que se hayan utilizado otros programas para esto, por ejemplo, XAgent. Las herramientas de volcado y grabación se encontraron en el mismo sistema, pero en diferentes momentos, probablemente, los operadores trabajaron en varias etapas. Primero, descargaron el firmware en la máquina de destino, se aseguraron de que la herramienta para realizar ajustes en el programa funcionara sin fallas, y luego lo volvieron a cargar y ya parchearon el firmware. Encontramos solo una versión de la herramienta para volcar y grabar, pero existe la posibilidad de que existan otras versiones para otro firmware con vulnerabilidades que puedan encontrar.

La figura siguiente proporciona una descripción general del funcionamiento del rootkit UEFI hasta que se inicia el sistema operativo. Primero, el DXE Manager carga el controlador SecDxe DXE. De esta forma, se configura la función de notificación para el grupo de eventos EFI_EVENT_GROUP_READY_TO_BOOT. Cuando el firmware está listo para seleccionar el dispositivo de arranque e iniciar el cargador de arranque, se llama a la función de notificación. Ella realiza tres acciones:

• carga el controlador NTFS DXE incorporado para proporcionar acceso y capacidad de escritura a particiones NTFS
• escribe dos archivos en la partición NTFS de Windows: rpcnetp.exe y autoche.exe
• cambia la clave de registro 'HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ BootExecute': a: 'autocheck autochk *'; después: 'autocheck autoche *'.

Figura 14. Proceso de arranque de un sistema infectado con un rootkit UEFI

SecDxe: controlador malicioso DXE

En esta sección, revelaremos la secuencia de eventos que ocurren en un sistema comprometido. Comenzamos con una descripción del rootkit, y luego seguimos la cadena de eventos hasta que los componentes finales se implementan a nivel del sistema operativo.

El rootkit UEFI de Sednit es un controlador DXE con un GUID 682894B5-6B70-4EBA-9E90-A607E5676297.

No está firmado, por lo que no se puede ejecutar en un sistema con la protección de arranque seguro habilitada. Después de implementar en uno de los volúmenes de firmware, DXE Foundation lo descarga cada vez que se inicia el sistema.

SecDxe es un pequeño controlador DXE que básicamente hace dos cosas. Configura un protocolo específico de GUID.832d9b4d-d8d5-425f-bd52-5c5afb2c85dcque nunca se usa Luego crea un evento asociado con la función de notificación. La función de notificación está configurada para invocar una señal por grupo EFI_EVENT_GROUP_READY_TO_BOOT. La señal a este grupo de eventos proviene del administrador de arranque cuando está listo para seleccionar el dispositivo a arrancar.


Figura 15. El resultado del descompilador Hex-Rays que pasa por el proceso de creación de eventos

La función de notificación explota el comportamiento malicioso del rootkit UEFI Sednit. Ella escribe componentes en el sistema de archivos NTFS de Windows. Como regla general, el firmware UEFI solo funciona con la partición del sistema EFI, por lo que el controlador NTFS generalmente no está incluido. Solo los sistemas de archivos FAT son compatibles como particiones para descargar. Por lo tanto, el firmware UEFI no necesariamente viene con controladores NTFS. Por esta razón, SecDxe tiene su propio controlador NTFS incorporado. Este controlador se inicia primero y se conecta al dispositivo de disco. Es decir, se instala EFI_SIMPLE_FILE_SYSTEM_PROTOCOLen dispositivos de disco con particiones NTFS, lo que incluye el acceso a los archivos.

Ahora que todo está listo para escribir archivos en particiones de Windows, SecDxe se reinicia rpcnetp.exey autoche.exe. Luego se rpcnetp.exeinstala %WINDIR%\SysWOW64en versiones de 64 bits de Windows o%WINDIR%\System32en versiones de 32 bits. A se autoche.exeestablece en %WINDIR%\SysWOW64. La siguiente figura muestra el proceso responsable de escribir estos archivos en el disco.


Figura 16. El resultado del descompilador Hex-Rays que pasa por el proceso de escribir archivos en el disco.

Luego SecDxe abre un %WINDIR%\System32\config\SYSTEMarchivo con una copia de seguridad de un conjunto de claves de registro HKLM\SYSTEM. Se analiza el archivo hasta que encuentra 'autocheck autochk *'y reemplaza 'k'en 'autochk'el 'e'. Como resultado, 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\ BootExecute'cambia a 'autocheck autoche *'. La próxima vez que arranque Windows, se ejecutará autoche.exe en su lugar autochk.exe.

Hacking Team NTFS Driver

Como se discutió anteriormente, el controlador NTFS está integrado en el módulo SecDxe. Existe una fuerte evidencia de que los operadores de Sednit no escribieron su propio controlador, sino que compilaron una copia del anunciado controlador NTFS DXE del Equipo de Hacking.
Su controlador NTFS utiliza el proyecto ntfs-3g como núcleo. Esto es solo un contenedor para que funcione como un controlador UEFI DXE. El archivo INF del ensamblaje del controlador del Equipo de Hacking enumera los nombres de archivo de proyecto ntfs-3g. Las líneas de código del controlador SecDxe NTFS también enumeran muchos de estos nombres de archivo: Es interesante observar que la ruta del proyecto es la misma que se encuentra en vector-edk, el proyecto de desarrollo EFI del Hacking Team. Hay un subproyecto en vector-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

NtfsPkgcon un diseño de directorio absolutamente idéntico. Los archivos fuente del proyecto ntfs-3g se encuentran en la misma ruta de dirección. Y aunque los caminos en sí no son notables, creemos que esto no es una mera coincidencia.

Al comparar el código fuente filtrado a la red con lo que obtuvimos en la salida del descompilador Hex-Rays, resulta obvio que este es el mismo proyecto. La siguiente figura muestra un ejemplo de una comparación de una función NtfsDriverBindingStarttomada de vector-edk/NtfsPkg/NtfsDxe/Ntfs.c. Los comentarios del código HT original se eliminan para una mejor percepción. La lógica y la secuencia de las llamadas a funciones son las mismas. Ambos proyectos incluso usan una variable (LockedByMe) para guardar un estado bloqueado.


Figura 17. Comparación de los resultados a la salida del descompilador Hex-Rays NTFS controlador Sednit (izquierda) y controlador NTFS HT (derecha)

El código anterior muestra a los desarrolladores del Hacking Team, que no está en el código abierto ntfs-3g. Como se menciona en la sección ReWriter_binary, durante el análisis del sistema de archivos de firmware, el archivo ejecutable intenta eliminar el controlador AMI NTFS. Queríamos descubrir por qué se está eliminando en lugar de usarse.

Analizamos el controlador y descubrimos que solo puede realizar operaciones de lectura. Dado que la escritura en el sistema de archivos no está disponible, los desarrolladores no pudieron usarla para sus propios fines. También es probable que los operadores de Sednit encuentren dificultades debido al hecho de que ya hay otro controlador NTFS en el firmware, por lo que decidieron simplemente eliminarlo. Además de implementar capacidades de lectura y escritura, el controlador del Equipo de Hacking no respeta los permisos de archivo. Por ejemplo, puede sobrescribir un archivo de solo lectura sin causar ningún error.

En este punto, ya hemos descrito varias operaciones de compromiso del sistema realizadas por el rootkit UEFI. También discutimos las razones por las cuales los operadores de Sednit usaron el código fuente edk del vector de Hacking Team para desarrollar su controlador NTFS para escribir archivos en particiones NTFS en Windows. Más adelante en este documento, presentaremos un análisis de los componentes entregados por SecDxe.

autoche.exe vs. autochk.exe

Malicioso se autoche.exeutiliza para garantizar la persistencia del mini agente rpcnetp.exe. Como puede ver en la siguiente figura, utiliza llamadas nativas a la API de Windows para crear un servicio.


Figura 18. Autoche .exe malicioso configura la persistencia de rpcnetp.exe.

Debe tenerse en cuenta que el nombre del servicio es el mismo que el utilizado por el agente legítimo de Computrace. Después de crear el servicio, restaura el valor de la clave de registro anterior BootExecute.


Figura 19. El archivo malicioso autoche.exe restaura el valor original de la clave de registro BootExecute.

Dado que el proceso ocurre durante el inicio de Windows, es poco probable que el usuario note un cambio en el valor de la clave.BootExecute. Cabe señalar que en autoche .exe algunas similitudes con el módulo autochk.exe en Computrace son notables, por ejemplo, las llamadas API aplicadas y el registro de servicios, pero el resto es bastante diferente. El módulo Computrace es más grande y restaura el archivo ejecutable original en autochk.exelugar de cambiar la clave del registro. También es responsable de implementar el mini agente en el disco, mientras que LoJax lo hace con el rootkit UEFI.

rpcnetp.exe

Si bien el mini agente rpcnetp.exepuede ser implementado por el rootkit UEFI, es probable que en la mayoría de los casos cuando encontramos una versión troyanada de LoJack, el mini agente no haya utilizado este componente. Es probable que procedieran de consideraciones oportunistas e instalaran el rootkit UEFI solo cuando tenían esa oportunidad, y en las organizaciones que más les interesaban.

Durante la investigación, descubrimos varias versiones del mini agente LoJax. La lista de indicadores de compromiso muestra sus valores hash y los dominios / direcciones IP correspondientes. Como ya dijimos, todas las muestras encontradas eran una versión troyanizada del mismo antiguo agente de Computrace, compilada en 2008.

Nunca hemos visto a un agente de LoJax descargar e instalar módulos adicionales, pero sabemos que dicha funcionalidad existe. Dado que las mejores cualidades de LoJax son el sigilo y la persistencia, definitivamente se puede usar para proporcionar acceso a recursos clave.

Prevención de ataques y recuperación

Para evitar un ataque, se necesita un ecosistema complejo que consta de muchos componentes activos. El primer mecanismo de seguridad que podría bloquear dicho ataque es el arranque seguro. Cuando el arranque seguro está habilitado, cada componente del firmware descargado a pedido del firmware debe estar correctamente firmado, asegurando así su integridad. Recomendamos que habilite la función de arranque seguro, esta es la protección básica contra ataques en el firmware UEFI.

Al igual que con el software, el firmware UEFI siempre debe actualizarse de manera oportuna. Visite el sitio web del fabricante de la placa base para asegurarse de tener la última versión disponible.

También debe asegurarse de que todos sus sistemas estén equipados con modernos conjuntos de chips con el Hub de controlador de plataforma (comenzando con los conjuntos de chips Intel Serie 5 y posteriores). Esto asegurará que los mecanismos de seguridad funcionen contra la "vulnerabilidad de condición de carrera", que, como indicamos , está presente en la plataforma.

Otra parte de la seguridad del firmware está en manos de los proveedores de UEFI / BIOS. Los mecanismos de seguridad proporcionados por la plataforma deben estar configurados correctamente por el firmware del sistema para garantizar realmente su protección. Por lo tanto, el firmware debe construirse inicialmente con una comprensión de las medidas de seguridad. Afortunadamente, cada vez más investigadores de seguridad están prestando atención a la seguridad del firmware, atrayendo la atención de los proveedores. También vale la pena mencionar es CHIPSEC, un marco de código abierto que realiza una evaluación de seguridad de bajo nivel para determinar si la plataforma está configurada correctamente.

Eliminar las consecuencias del compromiso a través del firmware UEFI es una tarea difícil. No hay formas fáciles de limpiar el sistema de tales amenazas, y no hay productos de seguridad especiales que puedan arreglarlo todo. En el caso descrito aquí, para eliminar el rootkit, es necesario volver a actualizar la memoria flash SPI. Esta es una tarea no trivial; no es adecuada para el usuario promedio. La actualización del firmware UEFI puede eliminar el rootkit si se reescribe toda el área SPI de la memoria flash. Si el flasheo UEFI no es posible, la única solución es reemplazar la placa base del sistema infectado.

Conclusiones

El rootkit UEFI es una de las herramientas más peligrosas y poderosas de los ciberdelincuentes debido a su alta persistencia e inmunidad para reinstalar el sistema operativo y reemplazar un disco duro, así como la dificultad excepcional de detección y eliminación. Aunque la imagen UEFI del sistema es difícil de cambiar, pocas soluciones le permiten escanear módulos UEFI e identificar entre ellos los maliciosos. Además, limpiar el firmware UEFI significa flashearlo, lo cual no es una operación normal que un usuario normal no podrá realizar. Estos beneficios explican por qué los cibergrupos con recursos ilimitados continuarán atacando los sistemas UEFI.

Para cualquier pregunta sobre este trabajo, comuníquese con hazardintel@eset.com.

Queremos expresar nuestro agradecimiento a quienes están trabajando en el proyecto opensecuritytraining.info. CursoLa introducción a BIOS y SMM realmente nos ayudó cuando analizamos las interacciones con el chip flash SPI.

Glosario

Consulte las especificaciones de Intel para obtener una descripción más detallada de las abreviaturas.
- BIOS_CNTL: Registro de control de BIOS
- BIOSWE: Escritura de BIOS habilitada
- BLE: Bloqueo de BIOS habilitado
- FADDR: Dirección de flash
- FDATAX: Datos de Flash de FDATA0 a FDATAN
- FDBC: Conteo de bytes de datos de Flash
- FGO: Flash Cycle Go
- HSFC: Secuencia de hardware Control de flash
- HSFS: Secuencia de hardware Estado de flash
- IOCTL: Control de entrada / salida
- PCH: Hub de controlador de plataforma
- RCBA: Registro de dirección de base compleja de raíz
- RCRB: Bloque de registro de complejo de raíz
- SCIP: Ciclo de SPI en curso
- SMI: Interrupción de administración del sistema
- SMM: Modo de gestión del sistema
- SMM_BWP: SMM BIOS Write Protect Disable
- SPI: interfaz de periféricos en serie

Indicadores de compromiso

ReWriter_read.exe

Detección ESET
Win32/SPIFlash.A
SHA-1
ea728abe26bac161e110970051e1561fd51db93b

ReWriter_binary.exe

Detección ESET
Win32/SPIFlash.A
SHA-1
cc217342373967d1916cb20eca5ccb29caaf7c1b

Secdexe

Detección ESET
EFI/LoJax.A
SHA-1
f2be778971ad9df2082a266bd04ab657bd287413

info_efi.exe

Detección ESET
Win32/Agent.ZXZ
SHA-1
4b9e71615b37aea1eaeb5b1cfa0eee048118ff72

autoche.exe

Detección ESET
Win32/LoJax.A
SHA-1
700d7e763f59e706b4f05c69911319690f85432e

Agente Mini EXE

Detección ESET SHA-1
Win32/Agent.ZQE
Win32/Agent.ZTU

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

Nombres de dominio del servidor de comandos

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

Direcciones IP del 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

Agente mini DLL

Detección ESET
Win32/Agent.ZQE
SHA-1
397d97e278110a48bd2cb11bb5632b99a9100dbd
Servidor de comandos Nombres de dominio
elaxo.org
Direcciones de IP del servidor de comandos
86.106.131[.]54