CVE-2015-2291

(1) IQVW32.sys anterior a 1.3.1.0 y (2) IQVW64.sys anterior a 1.3.1.0 en el controlador de diagnóstico de Ethernet de Intel para Windows permite a usuarios locales causar una denegación de servicio o posiblemente ejecutar código arbitrario con privilegios de kernel mediante una llamada IOCTL manipulada (a) 0x80862013, (b) 0x8086200B, (c) 0x8086200F, o (d) 0x80862007.

Descripción general

Este repositorio contiene un análisis de la vulnerabilidad en cuestión, junto con exploits de prueba de concepto funcionales en Windows 7 SP1 de 64 bits y Windows 10 20H2. El archivo del controlador se puede encontrar en el directorio Driver Files. Si encuentra algún error tipográfico en el análisis/documento, o si desea ver ciertos detalles con una descripción más elaborada, ¡cree un issue en el repositorio! Los corregiré lo antes posible.

Motivación

La motivación detrás de escribir un exploit para este controlador de dispositivo en particular se debe únicamente a que actualmente se está utilizando de forma maliciosa en la naturaleza para cargar un rootkit sin firmar de un atacante. Usando el método BYOVD (Bring Your Own Vulnerable Driver), el malware puede verificar si se está ejecutando con privilegios elevados, colocar una copia del controlador vulnerable, cargar el controlador y posteriormente explotarlo para obtener ejecución de código en el kernel y cargar el rootkit. No pude realizar ingeniería inversa con éxito de la muestra de malware, por lo que me tomé la tarea de crear el exploit.

Muestras detectadas en la naturaleza: https://bazaar.abuse.ch/sample/84ed7fec67de5621806dbb43af5167a5fc60ab7f2403448519dc0eca2b8f9022/ https://bazaar.abuse.ch/sample/0925b8985b19d7925d68186d666b0050a4cb3f2a577d64765d770a57a2eab9ae/ https://bazaar.abuse.ch/sample/e8b7f42d544fe8b954c4021315cff2fdd44d67d11704009cdf3037d34e0c0a93/

CVE-2015-2291 - Análisis Técnico de un Exploit

El controlador de dispositivo, llamado iqvw64e.sys, es un controlador diseñado para realizar diagnósticos del adaptador de red. Permite que el componente en modo usuario interactúe con el controlador de dispositivo para realizar una gran cantidad de rutinas del kernel exponiendo algunos códigos de control de E/S (también conocidos como IOCTL), con un código de control "sub" proporcionado en el búfer de entrada del usuario durante la interacción. El código de control IO que se utilizará para alcanzar la ruta de código vulnerable es 0x80862007. Además del código de control principal, los códigos de control "sub" antes mencionados que se cubrirán en este análisis serán el código 0x33 para alcanzar la llamada a la función memmove, y el código 0x30 para alcanzar las rutas de código de la llamada a la función memset. Este análisis no cubrirá ningún detalle sobre la rutina DriverEntry, ya que hay suficiente documentación en la página de documentación de Microsoft para dar una explicación exhaustiva.

Para empezar, queremos saber cómo podemos interactuar con este controlador de dispositivo en particular. La forma más común de comunicarse con un controlador de dispositivo es mediante el uso de una función llamada DeviceIoControl. La idea general detrás de esta función es que podemos pasar un identificador de controlador válido creado por CreateFileA, pasar un código de control IO que corresponda a la rutina del kernel que deseamos, pasar una estructura (o búfer) que espera, y devolverá datos en nuestro búfer de salida. Si bien rutinas como estas pueden ser necesarias en ocasiones (por ejemplo, acceder a registros específicos del modelo para fines de overclocking), también representan un grave riesgo para la seguridad. Pero... ¿cómo?

En el caso de CVE-2015-2291, la vulnerabilidad puede ser desencadenada por un usuario sin privilegios. Debido a que no hay verificaciones de saneamiento presentes, y los privilegios de administrador no son necesarios para explotar la vulnerabilidad, esto representa un riesgo de seguridad. Lo que subyace debajo de estos dos fallos es la capacidad de controlar completamente las llamadas a las funciones memset y memmove expuestas por la interfaz de código de control IO. ¿Recuerdas la función DeviceIoControl mencionada anteriormente, cómo podemos pasar una estructura que se usará en una rutina del kernel? Así es como todo se une.

Retrocedamos un paso. Primero queremos obtener el identificador del controlador relacionado con el controlador de dispositivo vulnerable. Incluso antes de esto, necesitamos localizar el objeto de dispositivo con nombre correspondiente. Estos se exponen al espacio de usuario mediante un enlace simbólico (comúnmente codificado de forma rígida), que se puede encontrar usando WinObj, parte del [conjunto SysInternals]. Si bien podríamos usar una utilidad de volcado de cadenas para volcar el enlace simbólico, o alternativamente realizar ingeniería inversa del controlador de dispositivo, simplemente cargué el controlador de dispositivo y lo localicé usando WinObj. El enlace simbólico encontrado en relación con el controlador de dispositivo es \\.\GLOBALROOT\Device\Nal. Para obtener el identificador del controlador, necesitamos llamar a la función CreateFileA y hacer que devuelva un identificador de controlador válido para usar más adelante en el proceso. El código para este proceso es el siguiente:```C if (h_nal == (HANDLE)-1) { printf("\n[-] Unable to obtain a driver handle to the Nal device driver. Error: %d (0x%x)", GetLastError(), GetLastError()); unused = getchar(); return 1; } printf("\n[+] Obtained a driver handle to the Nal device driver. Handle Value: 0x%p", h_nal);

Usaremos el manejador del controlador más adelante en el proceso de explotación. Por ahora, comenzaremos la preparación de nuestro exploit. El siguiente paso sería cargar la biblioteca `ntdll.dll` usando la función [LoadLibraryA](https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya) para obtener un [manejador de módulo](https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types), de modo que podamos localizar dinámicamente las funciones que necesitamos. Aunque la biblioteca `ntdll.dll` ya pueda estar cargada en nuestro proceso, de todas formas necesitamos obtener un manejador de la biblioteca que podamos usar. Las funciones que necesitamos para la explotación son [NtQuerySystemInformation](https://docs.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-ntquerysysteminformation) para filtrar la dirección base del kernel NT (con integridad de proceso media) para más adelante en el proceso de explotación, y la función [NtQueryIntervalProfile](http://undocumented.ntinternals.net/index.html?page=UserMode%2FUndocumented%20Functions%2FNT%20Objects%2FProfile%2FNtQueryIntervalProfile.html) para desencadenar la vulnerabilidad. En cuanto al código para cargar la biblioteca `ntdll.dll`, es el siguiente:```C
h_ntdll = LoadLibraryA("C:\\Windows\\System32\\ntdll.dll");
if (!h_ntdll)
{
	printf("\n[-] Failed to load the \"ntdll.dll\" API library. Error: %d (0x%x)", GetLastError(), GetLastError());
	unused = getchar();
	return 0;
}
printf("\n[+] Loaded the \"ntdll.dll\" API library. Handle Value: 0x%p", h_ntdll);