Hay varios tipos de controladores de kernel; lo primero que me viene a la mente son los controladores de dispositivos que proporcionan una interfaz de software para dispositivos de hardware como plug and play interfaces o controladores de filtro. Estos componentes del sistema de bajo nivel tienen un proceso de desarrollo estricto que incluye un escrutinio con respecto a la seguridad. Sin embargo, existen controladores de "software" adicionales que están diseñados para ejecutarse en Ring 0 y brindan funciones específicas no relacionadas con el hardware, como depuración y diagnóstico de software, análisis del sistema, etc. Como puede ver a continuación, estos son propensos a extender el ataque. superficie de manera significativa.

Si bien ya no es posible cargar directamente un controlador malicioso sin firmar en las versiones más recientes de Windows (a menos que la aplicación de la firma del controlador esté explícitamente deshabilitada durante el arranque) y los rootkits del kernel se consideran cosa del pasado, todavía hay formas de cargar código malicioso. en el núcleo. Si bien las vulnerabilidades reales y los exploits que logran eso reciben mucha atención, hay una manera mucho más fácil: abusar de controladores legítimos y firmados. Hay muchos controladores de varios proveedores de hardware y software que ofrecen funcionalidad para acceder completamente al kernel con un mínimo esfuerzo.

Las vulnerabilidades en los controladores firmados son utilizadas principalmente por los desarrolladores de trucos de juegos para eludir los mecanismos anti-trampas, pero también se ha observado que son utilizadas por varios grupos APT y en malware básico por igual.

Este documento analiza los tipos de vulnerabilidades que ocurren comúnmente en los controladores del kernel, proporciona varios estudios de casos de malware que utilizan dichos controladores vulnerables, analiza ejemplos de controladores vulnerables que descubrimos durante nuestra investigación y describe técnicas de mitigación efectivas contra este tipo de explotación. Si bien este problema no es nuevo y se han presentado investigaciones relevantes sobre el tema en el pasado, principalmente durante 2018 y 2019 ([1], [2], [3]), sigue siendo un problema al momento de escribir este artículo.

Tipos comunes de vulnerabilidades de los controladores

Si bien cada vulnerabilidad es diferente, tipos similares de vulnerabilidades parecen ser recurrentes en controladores de kernel no relacionados. Esto puede deberse en parte a Ejemplos de código de controlador (antiguo) que se crearon cuando el acceso al modo kernel no estaba restringido a los controladores firmados y los desarrolladores no tenían en cuenta la seguridad (en su lugar, el malware podría simplemente cargar controladores de rootkit sin firmar). Las siguientes secciones describen las vulnerabilidades observadas con mayor frecuencia en los controladores de una gran variedad de proveedores de hardware y software, e incluso de alto perfil.

MSR lectura/escritura

Registros específicos del modelo (MSR) se introdujeron en las CPU Pentium 80586 en 1993. Los MSR se pueden considerar como "variables globales" de una CPU (o de un núcleo específico). Algunos contienen información diversa sobre el procesador o el núcleo específico de la CPU, como la temperatura, la potencia, etc. Además, también hay muchos MSR que contienen datos críticos para el funcionamiento de un sistema, como IA32_LSTAR (0xC0000082) para LLAMADA AL SISTEMA or IA32_SYSENTER_EIP (0x00000176) para SISTEMA, los cuales contienen punteros a una dirección en el kernel donde la CPU salta cuando un LLAMADA AL SISTEMA or SISTEMA se ejecuta la instrucción. En las plataformas Windows x64 más nuevas, como Windows 10 u 11, LLAMADA AL SISTEMA se utiliza para CPU AMD e Intel donde IA32_LSTAR debe apuntar al KiSystemCall64 función encontrada en ntoskrnl.exe. El mecanismo de la transición al kernel de Windows al ejecutar LLAMADA AL SISTEMA se muestra en la figura 1.

Figura 1. Cómo LLAMADA AL SISTEMA se maneja en Windows x64

Los MSR están indexados por un número y los usuarios privilegiados acceden a ellos. RDMSR y WRMSR instrucciones, que solo se pueden ejecutar en modo kernel. Muchos controladores comerciales implementan funciones para que las aplicaciones en modo usuario accedan a estas instrucciones a través de un mecanismo IOCTL. Por lo general, esto tiene la intención de poder leer o escribir algunos MSR inocentes específicos (como el voltaje de la CPU, la temperatura, etc.), pero a veces los desarrolladores no agregan ninguna verificación adicional para restringir el acceso a los MSR críticos, como el ejemplo que se ve en la Figura 2. Esto brinda a los posibles atacantes la oportunidad de, por ejemplo, parchear el LLAMADA AL SISTEMA/ENTRAR AL SISTEMA MSR de punto de entrada, que son punteros a una función que maneja cualquier llamada del sistema desde el modo de usuario.

Figura 2. Controlador MSR IOCTL vulnerable en el AMDPowerProfiler.sys conductor

Sobrescribir el puntero de llamada del sistema era trivial y muy poderoso en CPU y sistemas más antiguos antes de que se introdujeran mitigaciones como la prevención de ejecución en modo supervisor (SMEP). En tales sistemas, simplemente cambiar el puntero a la dirección de un búfer ejecutable en modo de usuario arbitrario que contiene código malicioso, y luego ejecutar inmediatamente una instrucción de llamada al sistema en un mismo núcleo de CPU, fue suficiente para obtener la ejecución del código a nivel de kernel. Este ya no es el caso con los sistemas más nuevos debido a las modernas mitigaciones de explotación. Dicho esto, con el uso inteligente de varias técnicas, aún es posible eludir la mayoría de estas mitigaciones y lograr la ejecución de código a nivel de kernel en Windows 10 o incluso en los nuevos sistemas Windows 11 (a partir de diciembre de 2021).

Todas las mitigaciones en las siguientes secciones están implementadas en la mayoría de las máquinas modernas y deben omitirse para lograr una explotación exitosa en modo kernel.

SMEP

SMEP es un mecanismo de protección introducido en 2011 en los procesadores Intel basados ​​en la arquitectura Ivy Bridge y habilitado por defecto desde Windows 8.0. Impide la ejecución de código en páginas de modo de usuario desde Ring 0 y se implementa asignando un valor de modo de usuario o de modo kernel a un bit indicador en cada página de memoria virtual en la tabla de páginas. Si un sistema intenta ejecutar código en una página en modo usuario desde el espacio del núcleo, un 0x000000FC error (ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY) se activará y causará un BSOD. SMEP se puede activar y desactivar dinámicamente durante la ejecución con su estado guardado en el CR4 regístrese para cada núcleo de CPU individualmente (consulte la Figura 3).

Figura 3. CR4 registrar banderas de una CPU (crédito de la imagen: Wikipedia)

SMEP mitiga la técnica de explotación ingenua de abusar de un MSR R/W IOCTL para cambiar el LSTAR MSR para apuntar directamente al código de modo de usuario malicioso. Dicho esto, dado que el atacante tiene el control de la pila que se pasa al modo kernel en las llamadas al sistema, puede utilizar una técnica llamada cadena ROP para manipular la pila. Al colocar una cadena de direcciones de retorno en la pila, el atacante puede organizar la ejecución de un conjunto de instrucciones cuidadosamente seleccionadas en modo kernel cambiando el LSTAR MSR a través de un IOCTL vulnerable. Con la pila debidamente preparada, la ejecución de la instrucción de llamada al sistema da como resultado la ejecución del primer "dispositivo" en la cadena ROP y, cuando se completa, su código "regresará" al siguiente dispositivo de la cadena, que se suministró en la pila con el resto de La cadena.

La funcionalidad de una cadena ROP de este tipo está limitada por la disponibilidad de fragmentos de código adecuados, llamados gadgets, disponibles en los módulos del kernel. Dado que un atacante puede leer los módulos del núcleo del sistema de archivos y sabe en qué direcciones se cargan los módulos, los dispositivos se pueden buscar fácilmente y, si existen, se puede construir una cadena ROP que funcione.

Para inicializar correctamente la transición al kernel, la cadena ROP necesita intercambiar el GS regístrese usando el INTERCAMBIOS instrucción. En Windows de 64 bits, el registro GS contiene la dirección del bloque de entorno de subprocesos (TEB) en modo de usuario y la dirección de la región de control del procesador de kernel (KPCR) en modo de kernel. Por lo tanto, es crucial que esas dos direcciones cambien antes de que ocurra cualquier operación en el núcleo. No es de extrañar que el INTERCAMBIOS instrucción es también la primera instrucción en el kernel de Windows KiSystemCall64 función.

El siguiente paso es restaurar el valor original de la LSTAR MSR usando el WRMSR instrucción, con el fin de evitar la ejecución de la cadena ROP en la siguiente ejecución de la LLAMADA AL SISTEMA instrucción.

En este punto, el código malicioso se ejecuta correctamente en el núcleo y el atacante puede ejecutar cualquier carga útil que desee. Estos pueden ser dispositivos ROP adicionales para, por ejemplo, deshabilitar las protecciones SMEP o SMAP sobrescribiendo CR4, o incluso ser llamadas directas a un exportado ntoskrnl Función API.

El atacante puede sobrescribir CR4 utilizando un MOV CR4 gadget para deshabilitar SMEP y también SMAP, que se trata en la siguiente sección. Luego pueden proceder a ejecutar una carga útil en modo usuario directamente. La única dificultad con este enfoque es precalcular un valor válido. CR4 valor. Aunque la mayoría de los CR4 Los valores se pueden adivinar desde el modo de usuario ejecutando el CPUID instrucción, puede haber algunas inconsistencias entre las diferentes versiones de Windows.

Para volver al modo de usuario de forma segura, una vez que se haya ejecutado la cadena ROP del atacante, debe ejecutar el INTERCAMBIOS instrucción de nuevo y luego ejecute la SYSRET instrucción.

Los exploits más antiguos que omiten SMEP se describen en [4], (2015).

SMAP

La prevención de acceso en modo supervisor (SMAP) es una mitigación más reciente que se introdujo para complementar SMEP y restringir aún más el acceso desde el kernel a las páginas en modo usuario: no permite lecturas ni escrituras. Al igual que SMEP, su estado se almacena como un bit en el CR4 registro (ver Figura 3).

SMAP debería hacer que la técnica de la cadena ROP descrita anteriormente sea inútil, ya que la pila que contiene la cadena ROP es, de hecho, una página de modo de usuario. Un sistema con SMAP activo mostrará una pantalla azul en el momento en que intente acceder a la pila después de la transición al kernel a través de la llamada al sistema.

SMAP también se puede deshabilitar temporalmente configurando el AC bandera en el BANDERAS registro de la CPU. Esta característica es también la caída de esta mitigación con respecto a la explotación de MSR: resulta que el AC El indicador se puede configurar desde el modo de usuario, justo antes de la transición al modo kernel, utilizando el Extensión POP y PULSAR instrucciones. Esto es causado por el MÁSCARA MSR que controla qué BANDERAS Los bits de registro se borran cuando el LLAMADA AL SISTEMA se ejecuta la instrucción. Incluso en las máquinas con Windows 11 más nuevas, la máscara no tiene la AC bit de bandera establecido, lo que significa que no se borra al hacer la transición al kernel, por lo que el usuario puede desactivar SMAP.

A este tenor, MÁSCARA está controlado por otro MSR (0xC0000084), incluso si Microsoft cambió MÁSCARA para borrar implícitamente el AC bandera, teóricamente el atacante podría parchear este MSR antes de la explotación de todos modos.

Vale la pena señalar que SMAP se ha habilitado recientemente de forma predeterminada en Windows 10 x64 con hardware más nuevo.

Sombreado de KVA

El sombreado de KVA se introdujo como una mitigación de software para el Fusión de un reactor Vulnerabilidad de CPU descubierta a finales de 2017.

La idea básica de esta mitigación es que el espacio de direcciones virtuales se divide en dos: modo de usuario y modo kernel. El espacio de direcciones en modo usuario solo tiene acceso a partes muy restringidas del ntoskrnl módulo, específicamente una sola sección de código llamada .KVASCODE que es responsable de operaciones de bajo nivel como entrar y salir del núcleo cuando se maneja una llamada al sistema. Esto se maneja implementando equivalentes "Shadow" de las funciones responsables, como KiSystemCall64Sombra que funciona como el original KiSystemCall64, pero contiene diferencias responsables de manejar el sombreado de KVA y cambiar el contexto del espacio de direcciones correctamente (consulte la Figura 4). El resto del kernel está completamente separado y asignado a su propio espacio de direcciones y la CPU no puede acceder a él ni siquiera directamente desde el espacio de direcciones en modo usuario hasta que el contexto se cambie de manera adecuada.

Figura 4. Comparación de KiSystemCall64 y KiSystemCall64Sombra versiones del controlador de llamadas del sistema: se pueden detectar diferencias menores al comienzo de la función

Si bien el sombreado KVA se diseñó como una solución para la vulnerabilidad Meltdown, también puede causar problemas para otros tipos de vulnerabilidades, incluida la MSR.

En general, existen dos enfoques para deshabilitar la mitigación: uno es deshabilitarlo como una configuración en el registro. Esto requiere acceso de administrador y un reinicio posterior para que los cambios surtan efecto.

Alternativamente, al construir una cadena ROP para la explotación de MSR, un atacante intenta encontrar dispositivos exclusivamente en el .KVASCODE sección de la ntoskrnl módulo: dado que esa sección maneja la transición de llamadas al sistema, es posible construir una cadena ROP que funcione.

También se introdujo una mitigación similar en los sistemas Linux, donde se denomina aislamiento de tabla de páginas del kernel (KPTI).

Memoria física lectura/escritura

Ser capaz de leer y escribir directamente en la memoria física parece ser una característica común en muchos controladores de kernel de bajo nivel. Esto se logra asignando un rango específico de memoria física a un búfer de memoria virtual que se puede leer o escribir e incluso pasar a una aplicación de modo de usuario. Hay varias formas de lograr esto, la más común es la capacidad de mapear el DispositivoFísicoMemoria sección a la memoria virtual, como se muestra en la Figura 5.

Figura 5. Vulnerabilidad del mapa de memoria física en Passmark DirectIO64.sys conductor

Un inconveniente potencial para los atacantes es que primero necesitan traducir la dirección virtual a una física. Los controladores que implementan E/S de memoria física a veces también ofrecen un IOCTL para la traducción de direcciones físicas a virtuales, pero incluso si el controlador no tiene dicha conversión de direcciones, todavía hay muchas formas de utilizar esta función.

El caso de uso más sencillo es simplemente recorrer toda la memoria física en busca de artefactos específicos que representen estructuras de datos críticas que el atacante desea encontrar. Por ejemplo, el atacante podría intentar buscar el EPROCESO estructura del proceso malicioso y elevarlo a privilegios de SISTEMA robando un token de un proceso más privilegiado o modificando sus derechos. Algunas de estas estrategias se muestran esta página y esta página.

Dado que las asignaciones de memoria física ignoran las características de protección de la memoria virtual, también es posible escribir en páginas de memoria ejecutables. Esto le da al atacante la oportunidad de buscar módulos de kernel específicos y fragmentos de código, modificarlos cuidadosamente y, si el código parcheado se puede ejecutar a través de una API del sistema o un IOCTL de un controlador, lograr la ejecución de código malicioso a nivel de kernel.

Lectura/escritura de memoria virtual

Los IOCTL de acceso a memoria virtual no se encuentran tan comúnmente en estos controladores como los de memoria física, pero tienen repercusiones muy similares. Utilizarlos es aún más fácil, ya que no se necesita traducción de direcciones y se puede acceder directamente a todas las direcciones de núcleo virtual encontradas desde el modo de usuario. Una posible desventaja es que el acceso está limitado por la protección de memoria de la dirección de destino, por lo que no es posible escribir páginas de memoria de solo lectura sin cambiar primero la protección.

Por lo tanto, esta vulnerabilidad se usa comúnmente para manipular varias estructuras de datos del kernel para lograr cosas como elevar un proceso malicioso a derechos de SISTEMA mediante el robo de tokens de dichas estructuras del kernel.

La forma más común en que surge esta vulnerabilidad es a través de un IOCTL con una simple desreferencia de puntero en modo kernel, por lo que puede ser difícil detectar esta vulnerabilidad mediante métodos heurísticos.

Casos de estudio

Cuando los actores de malware necesitan ejecutar código malicioso en el kernel de Windows en sistemas x64 con aplicación de firma de controlador (DSE), llevar un controlador de kernel firmado vulnerable parece ser una opción viable para hacerlo. Esta técnica se conoce como Traiga su propio controlador vulnerable (BYOVD, por sus siglas en inglés) y se ha observado que los actores de APT de alto perfil y el malware básico la utilizan de forma salvaje.

En las siguientes secciones presentamos algunos ejemplos.

Tirachinas APT

Slingshot es una plataforma de ciberespionaje descubierta por Kaspersky en 2018 [5] y se cree que ha estado activa desde al menos 2012. Los actores detrás de este malware decidieron implementar su módulo principal, llamado Cahnadr, como un controlador en modo kernel. En los sistemas x86 más antiguos, el módulo de modo de usuario cargaría directamente el controlador. En los sistemas más nuevos con DSE activo, decidieron implementar un cargador de controladores personalizado que aprovecha los siguientes controladores de kernel firmados con vulnerabilidades de MSR: Aguijón, Ventilador de velocidad (CVE-2007-5633), sandra (CVE-2010-1592) y Elby CDIO (CVE-2009-0824). La explotación se centró en los sistemas anteriores a Windows 8, por lo que la explotación fue una simple modificación de la LSTAR MSR para apuntar a una carga útil maliciosa en un búfer de modo de usuario.

Tenga en cuenta que los investigadores de Kaspersky estimaron que estos actores de amenazas estuvieron activos entre 2012 y 2018, lo que significa que estos exploits eran bastante antiguos y bien conocidos, pero eso no fue motivo para que los atacantes dejaran de usarlos, ya que los certificados de esos controladores vulnerables eran nunca revocado.

InvisiMole

En 2018, otros investigadores de ESET descubrieron un actor APT sofisticado al que llamaron InvisiMole [6]. El grupo ha sido rastreado por ESET desde entonces y en 2020 una extensa detalles de la moneda sobre el grupo y su conjunto de herramientas fue publicado. En ese libro blanco, nuestros colegas informaron que InvisiMole usó la técnica BYOVD, explotando la vulnerabilidad MSR en el speedfan.sys driver (CVE-2007-5633) para cargar un controlador no firmado malicioso. Si bien esta campaña estaba dirigida a sistemas x86 más antiguos y la explotación con un controlador malicioso era trivial desde el punto de vista moderno, debido al hecho de que no había mitigaciones como SMEP, seguía siendo un caso interesante que mostraba que el grupo detrás de este malware es muy técnicamente capaz.

Más tarde, durante esa investigación, sin embargo, se descubrió una variante más nueva del malware InvisiMole que usaba la técnica BYOVD. Esta variante es el único caso hasta la fecha que hemos observado de explotación de MSR en sistemas Windows 10 x64 que un actor malintencionado utiliza de forma salvaje. Emplea técnicas avanzadas para eludir mitigaciones como SMEP e incluso SMAP. Dicho esto, la explotación se ve mitigada por el ensombrecimiento de KVA, que los autores no se ocuparon. Coincidentemente, la explotación de MSR se utilizó para implementar un controlador malicioso que intentó desactivar nuestros productos de seguridad. Aunque toda la cadena de compromiso es más extensa, nos centraremos en una parte específica del malware que aprovecha la técnica BYOVD y la explotación de MSR que ocurre en el módulo principal de modo de usuario.

Módulo de modo de usuario

Los autores de InvisiMole parecen haber desarrollado un marco de explotación de cadena ROP sofisticado que utilizan para la explotación de MSR; aunque la muestra contiene muchos mensajes de depuración en el código, no pudimos identificarlos ni vincularlos a ningún proyecto conocido. Esto nos lleva a creer que el marco es un trabajo original de estos autores de malware y que se han gastado recursos no despreciables en su desarrollo. El marco es una extensa base de código C++ con varias clases.

Parece que los autores de InvisiMole no conocían la posibilidad de establecer el AC bandera con el PULSAR y Extensión POP instrucciones como se describe en el SMAP sección, y en su lugar eligió un gadget ROP muy complejo que se encuentra en la MiDbgCopiarMemoria función del núcleo que comienza con el privilegiado STAC instrucción, que se dedica a configurar el indicador AC (consulte la Figura 6). Además de eso, InvisiMole utiliza el IREQ instrucción después de cada gadget que establece explícitamente el BANDERA registrarse con el AC conjunto de banderas, lo que estabiliza aún más el exploit.

Figura 6. Dispositivo ROP utilizado por InvisiMole para deshabilitar la mitigación de SMAP

El gadget inicial salta directamente a la STAC instrucción, que deshabilita inmediatamente SMAP configurando el indicador AC. Dado que este gadget aparece en medio de la MiDbgCopiarMemoria función, el malware prepara cuidadosamente la pila y se registra para salir de forma segura de la función. Una vez el MiDbgCopiarMemoria función regresa, la cadena ROP procede a la INTERCAMBIOS gadget [7] para cambiar correctamente al modo kernel, seguido del WRMSR dispositivo para configurar el LSTAR MSR vuelve a su valor original. En este punto, InvisiMole procederá con la ejecución de la carga útil, que puede ser una función del kernel exportada o el punto de entrada de un controlador malicioso cargado.

cargador de conductor

La técnica de carga de controladores es bastante compleja: InvisiMole primero instalará un "cargador de controladores", otro módulo de controlador de kernel que se usa para cargar la carga útil maliciosa (otro controlador más) que se pasa como argumento. Para inicializar el cargador de controladores, InvisiMole ejecuta varias explotaciones MSR separadas, donde cada instancia lleva una cadena ROP dedicada con una sola carga útil de llamada API. El malware comenzará ejecutando ExAlocatePoolWithTag para asignar un búfer de memoria del kernel ejecutable para el cargador, seguido de la preparación de la imagen en modo de usuario para reflejar su dirección futura en el kernel; las secciones se mueven a sus compensaciones virtuales; Se resuelven las importaciones y se arreglan las reubicaciones. Una vez que la imagen está lista, se copia del modo de usuario al búfer del kernel asignado usando memcpy del desplegable ntoskrnl módulo.

Para transferir la ejecución del código al cargador una vez que se copia al kernel, los autores de InvisiMole también aprovechan la vulnerabilidad de MSR y diseñaron varias exportaciones de PE dedicadas en el cargador (consulte la Figura 7 para ver un ejemplo) que están destinadas a manejar las transiciones del sistema en modo usuario. llamadas Funciona de manera muy similar a los dispositivos de la cadena ROP: cambie el GS registrarse, intercambiar las pilas de modo usuario y modo kernel, guardar todos los registros en la pila, restaurar el original LSTAR valor de MSR y luego llame a la función real. Una vez terminado, este proceso se invierte.

Figura 7. Función exportada en el módulo cargador de controladores que se llama al cambiar LSTAR MSR

Cuando el cargador se inicializa correctamente en el kernel, una exportación llamada _Inicio64 se ejecuta cambiando LSTAR MSR a la dirección de exportación en el núcleo. Después de manejar la transición al kernel, _Start64 registra una rutina diferida que se encarga de cargar el controlador de carga útil y vuelve al modo de usuario. La rutina del cargador diferido intentará inicializar el controlador de carga útil de una manera "adecuada", creando claves de registro y objetos del controlador del kernel, realizando todos los pasos necesarios para registrar el controlador en el sistema como si el sistema operativo estuviera cargando el controlador mismo, y eventualmente llamando IoCreateDriver. Se eligió el enfoque de inicialización adecuado para que el controlador de carga útil cargado pueda procesar paquetes de solicitud de E/S y comunicarse con un módulo de modo de usuario mediante IOCTL.

Conductor de carga útil

El controlador de carga útil ofrece la funcionalidad IOCTL para deshabilitar varias devoluciones de llamada de notificación (consulte la Figura 8), principalmente destinadas a desarmar soluciones de seguridad de terceros y la posibilidad de proteger un archivo en el sistema de archivos. Los comandos específicos se pasan desde el módulo de modo de usuario. Curiosamente, el módulo de modo de usuario intentará desactivar varias partes de la protección de ESET en el kernel.

Figura 8. Controlador IOCTL en el controlador de carga útil de InvisiMole

robbinhood

Es raro ver una técnica BYOVD en el malware comercial que tiene como objetivo llegar a la mayor cantidad de personas posible, pero la familia de ransomware RobbinHood muestra que aún puede resultar útil [8].

Este ransomware aprovecha un controlador de placa base GIGABYTE vulnerable GDRV.SYS (CVE-2018-19320; consulte la Figura 9 y la Figura 10) para deshabilitar DSE a fin de instalar su propio controlador malicioso.

Figura 9. Explotación del controlador GIODrv en la muestra de RobbinHood

La forma en que se deshabilita DSE depende de la versión de Windows; en Windows 7 y versiones anteriores, un nt!g_CiEnabled variable se modifica directamente en el módulo ntoskrnl. En los sistemas más nuevos de Windows 8 a Windows 11, la variable ci!g_CiOpciones existentes ci.dll en su lugar, se modifica el módulo. Encontrar esta variable es un poco más complicado y parece que los autores adoptaron un método que se encuentra en un proyecto de código abierto llamado DSEFijo que está disponible en GitHub. Además, desde Windows 8.1, las variables en ci.dll están protegidos por PathcGuard y la manipulación del módulo eventualmente hará que el sistema se vuelva BSOD, incluso si la variable se vuelve a cambiar a un valor original.

Luego, el controlador malicioso se usa para matar una larga lista de procesos y eliminar sus archivos, centrándose principalmente en el software de protección de puntos finales y otras utilidades. Dado que la terminación se realiza desde el modo kernel, la mayoría de los mecanismos de autoprotección empleados por el software de seguridad se eluden y es más probable que la técnica tenga éxito que intentar desarmar las protecciones desde el modo usuario.

Figura 10. EscribirMemoriaVirtual Controlador IOCTL en GIODrv

lojax

En 2018, los investigadores de ESET descubrieron la primer rootkit UEFI utilizado en la naturaleza. Para tener acceso a los módulos UEFI de las víctimas, el malware utiliza una poderosa utilidad llamada RWEverything.

Microsoft deshabilitó recientemente el controlador RWEverything directamente en Windows 10 y 11 mediante la función de integridad de memoria HVCI descrita en el Seguridad basada en virtualización .

Vulnerabilidades descubiertas

Durante nuestra investigación decidimos no solo catalogar las vulnerabilidades existentes, sino también buscar otras nuevas. Configuramos reglas YARA para buscar controladores de kernel con funcionalidad específica e indicadores de ser potencialmente vulnerables. También creamos un marco de explotación de prueba de concepto para probar los controladores recién encontrados y confirmar que son explotables.

Revisamos cientos de controladores de kernel diferentes que coincidían con nuestros criterios y, además de encontrar los controladores ya descubiertos, también encontramos tres controladores que anteriormente no se sabía que eran vulnerables, algunos de los cuales contenían varios errores no relacionados. El hecho de que, incluso después de que varios grupos de investigación independientes abordaran esta área, todavía pudimos encontrar nuevas vulnerabilidades, incluso de proveedores acreditados, muestra que la seguridad de los controladores de Windows sigue siendo un problema.

Mientras buscábamos todo tipo de vulnerabilidades descritas en secciones anteriores, encontrar las que tenían acceso a MSR resultó ser la más fácil, apareciendo más comúnmente debido al uso de instrucciones privilegiadas especiales (RDMSR/WRMSR) que regalan esta funcionalidad. Curiosamente, en muchos casos resultaría que esta clase de controladores también contenía otros tipos de vulnerabilidades, como funciones arbitrarias de lectura y escritura de memoria física o virtual.

AMD µProf (CVE-2021-26334)

Hemos identificado una vulnerabilidad MSR en el AMDPowerProfiler.sys controlador del núcleo, que forma parte de AMD µProf software de perfilado.

Lo que hace que este controlador se destaque es que una vez que se instala el paquete de software subyacente, el controlador se ejecuta en cada arranque del sistema. El acceso MSR IOCTL sin filtrar combinado con la falta de FILE_DEVICE_SECURE_OPEN banderas (consulte la Figura 11) y la presencia en el arranque le da al atacante una buena oportunidad de explotar el controlador incluso como un usuario sin privilegios; esta es una ventaja en comparación con el enfoque BYOVD cuando el atacante necesita cargar el controlador por sí mismo.

Figura 11. Creación de dispositivo de controlador de kernel de AMD uProf sin el FILE_DEVICE_SECURE_OPEN bandera que permite el acceso de no administrador

Por otro lado, el software es una utilidad de nicho para desarrolladores y no un paquete distribuido a una gran cantidad de sistemas. No hemos identificado ninguna otra vulnerabilidad en el controlador.

El IOCTL vulnerable es IOCTL_ACCESS_MSR (0x222030).

AMD reconoció la vulnerabilidad (CVE-2021-26334) y lanzó una solución en noviembre de 2021 Martes de Parches en libertad.

software de marca de paso

Passmark es una empresa que ofrece varias herramientas de diagnóstico y referencia informática. Para lograr dicha funcionalidad en el modo de usuario, es necesario acceder a muchas funciones del sistema de bajo nivel aprovechando un controlador en modo kernel.

Notas de aprobación DirectIo32.sys y DirectIo64.sys Los controladores del kernel son un marco común compartido y distribuido entre varias de las aplicaciones del proveedor, a saber, BurnInTest, PerformanceTest y OSForensics.

El controlador contiene acceso MSR R/W directo y sin filtrar (CVE-2020-15480), la capacidad de mapear la memoria física (CVE-2020-15481) para lectura y escritura, y el controlador IOCTL también contiene un desbordamiento de búfer (CVE-2020-15479) debido a la copia ciega, sin ninguna verificación de tamaño, de un búfer de entrada IOCTL de tamaño arbitrario a una variable local en la pila.

Passmark reconoció estas vulnerabilidades y lanzó una versión corregida poco después.

CVE-2020-15479

Cuando el controlador recibe una solicitud IOCTL de un programa en modo usuario, primero copiará el búfer de entrada solicitado en un búfer local en la pila. el tamaño de la recuerda se basa únicamente en el tamaño del búfer de entrada (consulte la Figura 12) y no tiene en cuenta la capacidad del búfer de pila. Esto puede provocar un desbordamiento del búfer, si se proporciona un búfer IOCTL lo suficientemente grande. Hay varios sin marcar recuerda llamadas en la función del controlador IOCTL y varios IOCTL se pueden utilizar para aprovechar el desbordamiento del búfer.

Figura 12. Desbordamientos de búfer en los controladores Passmark vulnerables

CVE-2020-15480

Este controlador ofrece RDMSR y WRMSR funcionalidad expuesta a través de un IOCTL que permite que un programa en modo de usuario sin privilegios lea y escriba MSR de CPU arbitrarios sin comprobaciones adicionales. Los IOCTL vulnerables son IOCTL_READ_MSR (0x80112060) y IOCTL_WRITE_MSR (0x80112088).

CVE-2020-15481

La funcionalidad de mapeo de memoria física se expone a través de un solo código de control: IOCTL_MAP_PHYSICAL_MEMORY (0x80112044). La implementación se divide en dos partes: la versión principal se realiza a través del ZwMapViewOfSection API; si por alguna razón este método falla, la función también implementa un enfoque secundario como respaldo, a través del MmMapIoEspacio y MmMapLockedPages API del núcleo. Ambos se ilustran en la Figura 13.

Figura 13. Implementación de IOCTL de memoria física en los controladores de Passmark

Analizador de PC Devid Espenschied

PC Analyzer es otra utilidad para inspeccionar varios detalles sobre la máquina. los PCADRVX64.sys El controlador del kernel distribuido con la aplicación contiene dos vulnerabilidades separadas: acceso MSR sin filtrar (CVE-2020-28921) y la capacidad de leer y escribir en direcciones de memoria física arbitrarias (CVE-2020-28922). Al crear el dispositivo controlador, el FILE_DEVICE_SECURE_OPEN la bandera no está especificada, lo que permite a los usuarios sin privilegios recuperar un identificador para el controlador.

Devid Espenschied reconoció las vulnerabilidades y lanzó una versión actualizada.

CVE-2020-28921

Al igual que con los controladores anteriores, el acceso a MSR no está restringido (consulte la Figura 14) y el controlador de código IOCTL contiene ARCHIVO_ANY_ACCESO banderas que permiten incluso a un usuario sin privilegios aprovechar la funcionalidad.

Figura 14. Implementación de MSR IOCTL en el controlador PC Analyzer

CVE-2020-28922

La funcionalidad de lectura y escritura de la memoria física del controlador se implementa con IOCTL independientes según el tamaño de la solicitud de lectura o escritura. Ofrece los siguientes códigos de control, ninguno de los cuales verifica las direcciones de memoria a las que se dirige la solicitud:

IOCTL_READ_PHYSICAL_MEMORY_BYTE (0x82002400)
IOCTL_READ_PHYSICAL_MEMORY_WORD (0x82002500)
IOCTL_READ_PHYSICAL_MEMORY_DWORD (0x82002600)
IOCTL_WRITE_PHYSICAL_MEMORY_BYTE (0x82002700)
IOCTL_WRITE_PHYSICAL_MEMORY_WORD (0x82002800)
IOCTL_WRITE_PHYSICAL_MEMORY_DWORD (0x82002900)

Mitigaciones

Si bien ya hemos mencionado varios mecanismos empleados por la CPU y/o el sistema operativo, la mayoría de ellos se pueden eludir con algunas técnicas inteligentes y no son muy efectivos si el atacante se prepara con anticipación. En esta sección nos gustaría mencionar algunas ideas de mitigación que son realmente efectivas para detener por completo el abuso de los conductores vulnerables.

Seguridad basada en virtualización

Seguridad basada en virtualización o VBS es una característica introducida en Windows 10 que aprovecha la virtualización de hardware y hace que el núcleo esté aislado en un hipervisor para asegurar el sistema operativo con varias protecciones.

VBS ofrece varias funciones de protección, siendo la más destacada la Integridad del código protegido por hipervisor (HVCI), que también viene como una función independiente. HVCI impone la integridad del código en el kernel y permite que solo se ejecute el código firmado. También emplea la función de lista de bloqueo, en la que una pieza de código conocida firmada por una firma válida específica se puede incluir en la lista de bloqueo y no permitir que se ejecute ni se cargue. uno de los conductores que ya ha sido bloqueado a través de este método es la utilidad RWEverything.

HVCI evita de forma eficaz que se abuse de los controladores vulnerables para ejecutar código kernel no firmado o cargar controladores maliciosos (independientemente del método de explotación utilizado) y parece que el malware que abusa de los controladores vulnerables para cargar código malicioso fue uno de los principales motivaciones detrás de la implementación de esta función por parte de Microsoft:

VBS proporciona ganancias de seguridad significativas contra ataques prácticos, incluidos varios que vimos el año pasado, incluidos los operados por humanos. ataques de ransomware como RobbinHood y ataques de malware sofisticados como Trickbot, que emplean controladores y técnicas del kernel que pueden ser mitigados por HVCI. Nuestra investigación muestra que hubo un 60 % menos de informes de malware activo de máquinas que informaron detecciones a Microsoft 365 Defender con HVCI habilitado en comparación con los sistemas sin HVCI. Surface Book 3 se envió en mayo de 2020 y Surface Laptop Go se envió en octubre de 2020, y es posible que los usuarios no hayan notado que están ejecutando VBS y, por lo tanto, están mejor protegidos según el trabajo realizado debajo del capó. [énfasis añadido]

Además de hacer cumplir la integridad del código del kernel, VBS también protege los MSR importantes y no permite ningún cambio en ellos. Como era de esperar, esta protección también afecta al LSTAR MSR y mitiga todas las posibilidades de explotación descritas anteriormente.

Si bien VBS es una protección eficaz contra la explotación de MSR y la ejecución de código malicioso en el kernel en general, la adopción de esta nueva función es bastante limitada, ya que ha varios requisitos de hardware que solo las máquinas más nuevas pueden cumplir. También hay algunos inconvenientes, siendo el más notable un éxito de rendimiento, que puede ser bastante notable dependiendo de la carga de trabajo. Tiempo algunos puntos de referencia estiman que el impacto en el rendimiento puede llegar al 25% en videojuegos específicos, el evaluación comparativa más detallada por Tom's Hardware estima que el impacto en el rendimiento es de alrededor del 5 % según los puntos de referencia específicos y la configuración del hardware (consulte la Figura 15), que aún no es una cantidad insignificante y puede llevar a algunos usuarios a considerar desactivar esta función. También puede haber algunos problemas de compatibilidad con controladores y software heredados. Con el lanzamiento de Windows 11, Microsoft ha decidido habilitar HVCI de forma predeterminada para todos los dispositivos compatibles.

Figura 15. Resultados de referencia de VBS por Hardware de Tom

Hipervisor de terceros

Similar a VBS de Microsoft, con hardware lo suficientemente nuevo, una solución de seguridad de terceros puede implementar su propio hipervisor personalizado. La ejecución del sistema operativo bajo un hipervisor brinda una supervisión detallada del estado de la máquina y brinda la posibilidad de inspeccionar e interceptar cualquier evento, incluida la ejecución de una instrucción específica. Al igual que con VBS, esto tiene un costo, a saber, rendimiento y compatibilidad.

Revocación de certificado

En los sistemas Windows modernos, los controladores deben tener una firma válida basada en un certificado "aceptable". Por lo tanto, revocar el certificado de un conductor vulnerable sería una forma fácil de “desarmarlo” e inutilizarlo en la mayoría de los casos.

Lamentablemente, la revocación rara vez ocurre y de los controladores vulnerables documentados en nuestra investigación anterior, ninguno de ellos ha tenido su firma revocada. Probablemente hay una multitud de razones por las que tales revocaciones no se llevan a cabo, pero es probable que las principales sean el tiempo y el costo. Dado que nadie requiere la revocación, no tiene mucho sentido desde el punto de vista del proveedor solicitar la revocación, ya que será un proceso costoso y lento. Además, un certificado de firma generalmente se comparte entre otros proyectos, por lo que la posible revocación debido a un solo controlador podría dificultar el desarrollo de cada proyecto.

Además, durante nuestra investigación aprendido que los controladores con certificados revocados no siempre se bloquean y que este problema es más complicado de lo que parecía en un principio. Después de todo, la revocación puede no ser la solución más fácil.

Lista de bloqueo de controladores

La lista de bloqueo de controladores es una práctica adoptada tanto por Microsoft como por varios proveedores de productos de seguridad de terceros. Varios de los controladores vulnerables más notorios son detectados por los productos de seguridad de ESET y eliminados cuando se encuentran en un sistema. Microsoft también optó por bloquear los controladores no solo con su solución de seguridad, sino también directamente por el sistema operativo que utiliza su mitigación HVCI, que es parte de la seguridad basada en la virtualización. Si bien la lista de bloqueo es efectiva, no es una solución proactiva: solo los controladores vulnerables descubiertos previamente pueden incluirse en la lista de bloqueo, y cada proveedor debe hacerlo manualmente. Esto significa que esta mitigación no será efectiva contra vulnerabilidades de controladores de día cero previamente desconocidas que pueden usarse en un ataque APT sofisticado.

Probablemente el controlador bloqueado más destacado es el controlador "antitrampas" de Capcom. Capcom.sys, que implementa explícitamente un IOCTL que simplemente ejecuta el contenido del búfer proporcionado en modo kernel (consulte la Figura 16). Para poder ejecutar un búfer proporcionado desde el modo de usuario, ¡incluso deshabilita SMEP temporalmente!

Cuando se descubrió, el controlador apareció en varios titulares y se crearon muchas herramientas de carga de controladores sin firmar basadas en el abuso de esta función del controlador. En consecuencia, el conductor finalmente fue bloqueado por muchos proveedores de productos de seguridad incluyendo Microsoft y ESET.

Figura 16. Fragmento de código del controlador antitrampas de Capcom

Conclusión

Los controladores vulnerables han sido un problema conocido durante mucho tiempo y han sido abusados ​​por la comunidad de trampas de juegos y los autores de malware por igual, y aunque se han hecho algunos esfuerzos para mitigar los efectos, todavía es una batalla en curso. Parece que todas las partes responsables involucradas quieren resolver este problema: los proveedores con los que nos comunicamos fueron increíblemente proactivos durante el proceso de divulgación, ansiosos por corregir las vulnerabilidades que descubrimos. Microsoft está tratando de fortalecer el sistema operativo desde adentro y, por último, pero no menos importante, los proveedores de seguridad de terceros están tratando de encontrar formas inteligentes de detectar y mitigar dichos controladores.

Sin embargo, parece que todavía falta una pieza: una forma común y unificada de manejar estos problemas, incluido un "desarmado" más completo de los controladores, ya sea revocando o bloqueando sus certificados, o algunas listas de bloqueo públicas compartidas adoptadas por las empresas de seguridad. .

Bibliografía

[1] J. Desimone y G. Landau, “BlackHat 2018: Amenazas en modo kernel y defensas prácticas”, 9 de agosto de 2018. [En línea].
[2] R. Warns y T. Harrison, “INFILTRATE 2019: Desenfreno de controladores de dispositivos y locura MSR”, 2 de mayo de 2019. [En línea].
[3] J. Michael y M. Skhatov, “Defcon 27: bájese del kernel si no puede conducir”, 13 de agosto de 2019. [En línea].
[4] N. Economou y E. Nissim, “ekoparty 2015: Omisión SMEP de Windows: U=S”, 2015. [En línea].
[5] A. Shulmin, S. Yunakovsky, V. Berdnikov y A. Dolgushev, “El Slingshot APT”, 6 de marzo de 2018. [En línea].
[6] Z. Hromcová y A. Cherepanov, “InvisiMole: La parte oculta de la historia: descubriendo el conjunto de herramientas de espionaje y las cooperaciones estratégicas de InvisiMole”, 18 de junio de 2020. [En línea].
[7] A. Ionescu, “UMPOwn: Anillo 3 a Anillo 0 en 3 actos”, en PoC||GTFO, vol. 2, No Starch Press, 2018, pág. 768.
[8] A. Brandt y M. Loman, “Viviendo en otra tierra: el ransomware toma prestado un controlador vulnerable para eliminar el software de seguridad”, Sophos, 7 de febrero de 2020. [En línea].

Fuente: https://www.welivesecurity.com/2022/01/11/signed-kernel-drivers-unguarded-gateway-windows-core/