stong/cve-2020-15368CVE-2020-15368, también conocido como "Cómo explotar un controlador vulnerable"
Exploit y Prueba de Concepto (PoC) para CVE-2020-15368. Asrock reempaquetó el driver de rweverything para su herramienta de configuración del controlador RGB y lo firmó. Lo "protegen" cifrando sus ioctls...lol. Encontramos este CVE por accidente el verano pasado, y que yo sepa, el driver todavía no está parcheado. El impacto es, por supuesto, ejecución de código arbitrario en el kernel, etc. Así que disfruta de este "0day" lol.
Si quieres discutir conmigo sobre si es un CVE REAL Y LEGÍTIMO, no dudes en contactarme en Twitter, podemos tener una gran pelea en las redes sociales públicas, ¡y será muy emocionante para todos los involucrados! ¡Incluso compraré un dominio para este bug si así lo deseas. ¡Es todo marketing!!!!
De todos modos, este bug es bastante mierda, así que lo usaré como tutorial sobre cómo pwnear tu típico driver vulnerable. Así que esta publicación está dirigida a principiantes. Aprenderás a explotar un driver vulnerable. Hay muchos otros drivers de mierda como este. El mundo es tuyo. Diviértete
DESCARGO DE RESPONSABILIDAD: Esta publicación se proporciona únicamente con fines educativos. Es responsabilidad del lector cumplir con todas las leyes locales, estatales y federales aplicables. El/los autor(es) de esta publicación no asumen ninguna responsabilidad y no son responsables de ningún uso indebido o daño causado por el software contenido en esta publicación.
Atrapados en cuarentena, mis compañeros de piso (Pear0, Codetector) y yo estábamos jugando con la nueva placa base Asrock de Pear0. Los LED rojos brillantes eran extremadamente molestos y no era posible configurarlos en Linux. Así que nuestro plan era hacer ingeniería inversa al driver de Windows que lo controlaba y replicar las operaciones de E/S en Linux.
En resumen, no tardamos mucho en darnos cuenta de que el driver es literalmente solo un driver genérico que concede acceso arbitrario de lectura/escritura a cualquier cosa. Esto incluye registros de control como CR3, CR4, memoria física, etc. Estos drivers están destinados a usarse como herramienta de depuración y el sitio web del proveedor lo indica claramente.
Pensamos que era extremadamente gracioso. Es bastante emocionante la primera vez que haces que una computadora sufra un triple fallo y se reinicie en seco desde el espacio de usuario. (Quizás menos emocionante la vigésima vez.) De todos modos, reportamos el bug y luego lo olvidamos durante un año.
Como novato en kernel, me preguntaba cómo cargar e interactuar realmente con el driver. Resulta que es extremadamente fácil.
Puedes simplemente crear un servicio para el driver en Process Hacker (obviamente, se requieren privilegios de administrador para cargar drivers). Luego puedes hacer clic derecho e iniciarlo. Sí, es así de simple.
Podemos ver nuestro objeto Device en WinObjEx64.
Incluso podemos jugar con el dispositivo en FileTest.
Estas 3 herramientas son increíbles, especialmente PH y FileTest. Son como una navaja suiza y deberían estar en la caja de herramientas de todo reverser de Windows. Por ejemplo, según tengo entendido, Jonas L ha encontrado innumerables vulnerabilidades de LPE en Windows solo jodiendo con FileTest. Así que Windows realmente tiene grandes herramientas para joder. Ojalá hubiera esta mierda en Linux.
Rweverything tiene un ioctl que recibe otro ioctl como parámetro, que controla qué operación realizar (leer memoria, escribir memoria, leer msr, etc.), y una unión de algunos parámetros específicos de la operación como dirección de origen, dirección de destino, etc. Cuando comparamos el código de los dos drivers:
🤔🤔🤔🤔🤔🤔🤔🤔🤔
No obstante, el driver hace un intento chapucero de seguridad por oscuridad al exigir que todas las llamadas ioctl estén cifradas apropiadamente con una clave AES fija. El código (después de una pequeña limpieza) se ve así:
if ( IoControlCode == 0x22EC00 )
{
char enc_key[32];
memset(enc_key, 0, sizeof(enc_key));
memmove(enc_key, "C110DD4FE9434147B92A5A1E3FDBF29A", 32ui64);
memcpy(enc_key + 13, ioctl_args->key, 16);
size_t cb_decrypted = 0;
my_decrypted_cmd* decryptedCmd = NULL;
DWORD iv_size = ioctl_args->iv_size;
DWORD input_size = *(DWORD*)(ioctl_args + bufferLen - 6);
// really just calls BCrypt API to get an AES implementation
if ( (unsigned int)decrypt_ioctl_params(enc_key, 32, ioctl_args->iv, iv_size, ioctl_args + bufferLen - input_size - 6, input_size, &decryptedCmd, &cb_decrypted) )
{
// Decryption failed
if ( decryptedCmd )
ExFreePoolWithTag(decryptedCmd, 0);
irp->IoStatus.Status = 0xC000000D;
goto Fail_Out;
}
IoControlCode = decryptedCmd->opcode;
Rweverything_Args = &decryptedCmd->args;
}
else // not 0x22EC00
{
if ( IoControlCode != 0x22E858 &&
IoControlCode != 0x22E860 &&
IoControlCode != 0x22E800 &&
IoControlCode != 0x22E804 )// whitelisted control codes
IoControlCode = 0; // block everything else
}
El driver permite algunas operaciones aburridas que hacen algo de PMIO, pero todos los códigos de control "divertidos" están protegidos por esta rutina de descifrado. A pesar de tener esta lista blanca explícita, todavía incluye toda la funcionalidad peligrosa de Rweverything. En lugar de ocultar estas características peligrosas, probablemente deberían haberlas eliminado por completo.
También, curiosamente, permite al usuario especificar parte de la clave (???), por alguna razón que no tengo idea. El código está muy mal escrito.
En fin, es relativamente fácil escribir el código del cliente para usar esta extraña API cifrada y pasarle las llamadas ioctl arbitrarias que queramos. No te aburriré con los detalles de eso.
Abrimos un manejador hacia el driver y usamos DeviceIoControl para llamar al ioctl, algo muy estándar.
HANDLE hDevice = CreateFileA("\\\\.\\GlobalRoot\\Device\\AsrDrv104", GENERIC_READ | GENERIC_WRITE | SYNCHRONIZE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
// ... set up the encrypted ioctl data
BOOL result = DeviceIoControl(hDevice, 0x22EC00, ioctl_data, in_buf_size, out_buf, sizeof(out_buf), &bytes_returned, NULL);
Ahora que podemos hablar con la parte oculta de Rweverything del driver, lo primero que quería hacer era provocar un crash para saber que mi cliente del driver funciona.
La forma más directa de lograrlo es sobrescribir CR3 con basura. Sé que algunos de los que leen esto son novatos y está bien, así que lo explicaré en detalle. Yo también soy tonto, así que tal vez esto te ayude a aprender. Si sabes lo que estás haciendo, puedes saltarte esta parte.