¿Sabía que un controlador completamente legítimo puede darle a un atacante la oportunidad de registrarse en su sistema durante mucho tiempo, permaneciendo dentro incluso después de reinstalarlo? ¿O convertir tu computadora en un ladrillo? Por ejemplo, algunos controladores inofensivos aparentemente confiables (firmados) son herramientas incidentales para sobrescribir el BIOS. Después de tal ataque, solo el programador guardará.
En Windows, hay aplicaciones / scripts / bibliotecas confiables con adicionales interesante funcionalidad peligrosa como ejecutar código arbitrario, descargar archivos, omitir UAC, etc. Si dicha funcionalidad adicional se encuentra en un componente del núcleo, se vuelve aún más interesante.
A partir de Windows Vista x64, se aplica la política de cumplimiento de firma de controlador (DSE): todos los controladores de nivel de núcleo deben estar firmados. Si un atacante (con derechos de usuario / administrador) después de penetrar en el sistema desea obtener el nivel máximo de acceso (instalar kernel rootkit / bootkit / SMM-rootkit / BIOS-rootkit), tendrá que omitir de alguna manera el requisito de firma para el controlador. La capacidad de llamar a ciertas funciones o instrucciones desde el modo kernel en modo kernel puede brindarle al atacante una herramienta para elevar privilegios, revelar información o causar una denegación de servicio. Llamamos a esta funcionalidad una funcionalidad de doble propósito (en algunos casos, esto puede llamarse vulnerabilidades o puertas traseras, sin embargo, la discusión sobre la definición correcta está más allá del alcance de este artículo).
Soluciones alternativas de DSE
Veamos qué opciones tiene generalmente un atacante para evitar DSE (de alguna manera debe penetrar ring0). La siguiente tabla resume las formas de eludir DSE con sus ventajas y desventajas (para el atacante y los guardias de seguridad tomen nota). Vale la pena señalar que esta información se aplica a Windows x64, comenzando con Vista.
Como puede ver en la tabla, un controlador firmado con funcionalidad de doble propósito es la forma más atractiva de evitar DSE para un atacante.
Funcionalidad peligrosa o de doble propósito.
Veamos ejemplos de capacidades maliciosas en las que aparece un atacante en presencia de un controlador con funciones peligrosas de doble propósito.
- Escalada de privilegios a nivel de administrador / SISTEMA. Lectura / escritura de memoria física requerida. Este ataque puede llevarse a cabo, por ejemplo, utilizando el controlador ASMMAP de ASUS. Para hacer esto, lea la memoria física y encuentre la estructura EPROCESS (es un elemento de una lista enlazada), luego revise la lista en busca del proceso cuyo nivel de privilegio queremos aumentar, así como algún proceso conocido con el nivel SYSTEM (por ejemplo, lsass, wininit). Luego copie el valor del campo Token de la estructura del proceso del sistema en la estructura del proceso de destino. Aquí se da una descripción más detallada del ataque.
- Desactivar SMEP. Para hacer esto, debe escribir en el registro de control cr4 (más precisamente, restablecer su bit 20). Por ejemplo, el controlador bandainamcoonline.sys no solo deshabilita SMEP, sino que también ejecuta útilmente el código de acuerdo con el puntero que le pasó el usuario. Para aquellos interesados, hay un artículo con una descripción detallada del controlador.
Ejecución de código arbitrario en modo kernel. Se requiere memoria física de lectura / escritura y MSR. El significado es reemplazar la dirección (ubicada en uno de los MSR), a la que se realizará la transición al hacer una llamada al sistema, a la dirección de la ubicación del código del atacante. Aquí puede encontrar más información sobre esto. PatchGuard interferirá en el camino, pero puedes resolverlo si lo deseas.
Dado que el controlador y PatchGuard se ejecutan en el Anillo 0, nada impide que el controlador desactive las revisiones de PatchGuard (hasta, por supuesto, hasta que Microsoft escuche a Intel y vaya más allá del modelo con dos anillos de protección). Los desarrolladores del kernel de Microsoft son conscientes de este hecho y realizan diversas acciones para ocultar la ubicación de este código, ofuscar sus acciones y las estructuras internas utilizadas. En otras palabras, debido a la incapacidad de evitar que modifiques el código PatchGuard, hacen todo lo posible para ocultarlo.
- Blunden B. El arsenal de Rootkit: escape y evasión en los rincones oscuros del sistema.
El originalDado que el código del controlador y el código de PatchGuard se ejecutan en el Anillo 0, no hay nada que evite que un KMD desactive las comprobaciones de PatchGuard (a menos, por supuesto, que Microsoft siga el ejemplo de Intel y vaya más allá de un modelo de privilegio de dos anillos). Los ingenieros de kernel de Microsoft son muy conscientes de este hecho y realizan todo tipo de acrobacias de programación para ofuscar dónde reside el código, qué hace y las estructuras internas de datos que manipula. En otras palabras, no pueden evitar que modifiques el código de PatchGuard, por lo que intentarán ocultarlo.
- Blunden B. El arsenal de Rootkit: escape y evasión en los rincones oscuros del sistema.
- Entrada de BIOS. Un ejemplo en la naturaleza es Lojax . Los atacantes tomaron el conocido RwDrv.sys y lo usaron para sus propósitos sucios: leyeron el BIOS, modificaron y escribieron de nuevo. Reinstalar Windows no ayudará aquí, ya que el código malicioso se encuentra en el firmware en SPI-flash. Si la sobrescritura del BIOS no tiene éxito (o se sobrescribe especialmente), entonces también será desagradable. En cualquier caso, tendrá que conducir después del programador para solucionar las molestas consecuencias.
- Llame al manejador de SMI. En primer lugar, no todos los BIOS son igualmente indefensos contra el código en modo ring0: existen varios mecanismos para la protección de lectura / escritura, por lo que puede haber una situación en la que deba descender al modo SMM (el más privilegiado). Una forma de llegar desde el modo kernel es extraer el controlador SMI (a menudo hay algunos vulnerables entre ellos). Para llamar al controlador SMI, debe poder escribir en el puerto de E / S, y esto solo se puede hacer con privilegios ring0. Es decir, un controlador con la capacidad de escribir en puertos de E / S puede detectar un controlador SMI vulnerable que puede permitir que un atacante ejecute código en modo SMM. En el ejemplo, el autor usa el controlador RwDrv.sys.
- Información sobre el sistema. Lectura de la memoria del núcleo (a través de la lectura de la memoria física), lectura del BIOS, información sobre la configuración del sistema, dispositivos conectados y mecanismos de protección habilitados / deshabilitados (a través de la lectura de MSR, registros de control, acceso a puertos de entrada / salida), en algunos casos, se puede detectar un hipervisor conocido ( como VirtualBox a través de MSR ). Para esta tarea, incluso un controlador que solo puede leer, no necesariamente escribir, a menudo es adecuado. Por ejemplo, RamCaptureDriver64.sys de Belkasoft es adecuado para leer memoria física.
Si analizamos varios artículos y notas sobre CVE, podemos distinguir algunas clasificaciones de potencialmente peligrosas al acceder desde las funciones ring3 en los controladores. La siguiente tabla enumera las funciones peligrosas y las fuentes de información sobre ellas.
Y esta no es la lista completa de posibles funciones peligrosas. También puede hablar sobre lectura / escritura de memoria virtual del núcleo, lectura / escritura de MMIO, acceso a dispositivos PCI, etc.
Las tres primeras funciones son de gran interés, así como el mayor peligro (y es más probable que encuentre un controlador con tales funciones): leer / escribir registros MSR, leer / escribir puertos de E / S, leer / escribir memoria física. Al usar los registros de control, puede omitir algunos mecanismos de protección, escribir en el registro de banderas le permite habilitar los puertos de entrada / salida de lectura / escritura en ring3 (por cierto, se menciona en este artículo en Habré), el éxito de los ataques en canales de terceros (accediendo a la caché, monitoreando contadores rendimiento / ciclos) es muy poco probable.
En el proceso de creación de este material en la conferencia DEFCON 27 en Las Vegas, los investigadores Jesse Michael y Mickey Shkatov presentaron el trabajo "Salga del núcleo si no puede conducir" , que también analiza este problema, y le recomendamos que estudie este material para completar la imagen. Los escenarios para usar dichos controladores son muy simples y claros, y se presentan ejemplos de secciones de código responsables de la funcionalidad más crítica. Y también proporciona código para trabajar y encontrar controladores similares.
En general, vale la pena señalar que este tema siempre ha estado preocupado por los investigadores de seguridad. En 2018, el investigador Alexander Matrosov en su artículo "¿Qué hace que los controladores del sistema operativo sean peligrosos para el BIOS?" planteó esta pregunta y demostró lo simple que es explotar el BIOS.
Controladores de doble función
A continuación se muestran los representantes más famosos de controladores con funciones de doble propósito.
RwDrv.sys es un controlador muy popular (viene con la utilidad RWeverything ). Lee y escribe memoria física, puertos de E / S, MSR y registros de control. Se usó repetidamente en varios PoC y luego en el rootkit Lojax mencionado anteriormente. Se escribe una interfaz para él en C ++, y también se usa en chipsec .
cpuz / gpuz
Lee y escribe memoria física, puertos y MSR. Hay varias utilidades de PoC que lo usan ( aquí y aquí ).
pcdsrvc_x64: controlador de Dell; para obtener más información, comuníquese con esta publicación. Le permite leer / escribir memoria física en puertos de E / S.
AsIO64.sys
Proporciona la capacidad de leer / escribir memoria física y puertos de E / S, y también viene con un dll conveniente para realizar estas solicitudes.
Asmmap64.sys es otro controlador de ASUS que le permite leer / escribir memoria física, puertos de E / S y MSR. Sería especialmente agradable para un atacante, ya que el acceso al controlador puede hacerse desde un usuario normal sin derechos de administrador. Las personas curiosas pueden recurrir a la fuente .
ntiolib_x64.sys / winio64.sys: controladores de MSI, se describen en detalle en el artículo mencionado anteriormente. Usando ntiolib_x64.sys puede leer / escribir memoria física, puertos de E / S y MSR, winio64.sys proporciona todas estas funciones excepto MSR.
Por lo general, las funciones peligrosas descritas se reconocen como vulnerabilidades si el usuario puede acceder al controlador sin derechos de administrador (ACL incorrecta) o cuando permite ejecutar código arbitrario directamente (como en bandainamcoonline.sys). En otros casos, esto es solo funcionalidad, y dado que el usuario tiene derechos de administrador, puede usar todas las funciones del controlador y esta es la norma.
Si crees que no hay más de una docena de esos controladores, estás muy equivocado. Puedes ver esta selección de controladores interesantes. Esta lista contiene controladores de ASUS, AVAST, Razer, LG, American Megatrends y otras compañías conocidas. Así que hay muchos, solo necesitas buscar. Por lo tanto, representan una amenaza real.
Los empleados de Microsoft también entienden esta amenaza. Y estarán agradecidos por la información sobre tales controladores;)
Recomendaciones
Para usuarios:
- No debe sentarse innecesariamente bajo la cuenta de administrador y deshabilitar UAC (aunque no es difícil evitarlo ).
- Puede instalar el detector intentando instalar controladores (por ejemplo, aquí ).
- Si es necesario utilizar utilidades con dichos controladores (diagnóstico, para actualizar el BIOS, etc.), elimine los controladores después de su uso.
- Configure Device Guard (si es un feliz propietario de Windows 10). Con esta tecnología, puede crear su propia política de integridad de código y agregar listas blancas de programas y certificados. Por ejemplo, agregue a la política el requisito de que cualquier controlador en modo kernel debe tener una firma WHQL de Microsoft. En esta publicación, puede familiarizarse mejor con la configuración de Device Guard para este propósito.
Es mejor que los fabricantes no firmen dichos controladores. Si el usuario necesita actualizar el BIOS, verifique si hay vulnerabilidades en el sistema (hola, chipsec), mida el rendimiento o realice otras manipulaciones que requieran la instalación de dichos controladores, entonces muy bien puede ingresar al Modo de prueba, hacer todo esto y luego salir. La usabilidad disminuirá, pero la seguridad aumentará.
Conclusiones
Si algo está firmado, entonces no puedes confiar en él de todos modos. En primer lugar, puede firmar algo así y, en segundo lugar, un atacante puede aprovechar este firmado (incluso si es de un fabricante de confianza).
Los especialistas en seguridad de la información no deben excluir del modelo de amenazas situaciones en las que un atacante requiere un controlador con funcionalidad peligrosa para realizar un ataque. Hay suficientes controladores de este tipo; es bastante simple hacer esto. Si el ataque no se lleva a cabo con un controlador pop como RwEverything, pero con uno menos conocido, será aún más difícil detectarlo. Por lo tanto, debe estar alerta, monitorear tales cosas y no permitir que cada controlador arranque en el sistema.
Autor: Elizaveta Khomenko