CVE-2020-0753-and-CVE-2020-0754

Writeup y PoC para CVE-2020-0753, CVE-2020-0754 y seis vulnerabilidades DOS sin corregir de Windows

Explotación del bug de condición de carrera en el sistema de archivos: análisis de CVE-2020-0753 y CVE-2020-0754

El servicio de Informes de errores de Windows ha corregido 2 bugs de elevación de privilegios en el último Patch Tuesday; a los dos bugs se les asignaron CVE-2020-0753 y CVE-2020-0754. Ambos bugs aprovechan un bug de condición de carrera en las operaciones del sistema de archivos del servicio. Sin embargo, esos dos bugs no son tan fáciles de explotar debido a las pequeñas ventanas de carrera y a las ubicaciones inciertas de colocación de archivos. Aquí compartimos nuestras técnicas para explotarlos.

La causa raíz de los dos bugs de condición de carrera se explica en nuestros informes; la causa real puede expresarse como Lo predecible es vulnerable. Cuando el servicio WER procesa archivos temporales, manipula la ubicación C:\ProgramData\Microsoft\Windows\WER\Temp, que es un directorio con permisos de lectura/escritura habilitados para Usuarios autenticados. Eso significa que un usuario normal de IL media puede sobrescribir un archivo creado por el servicio WER e incluso convertirlo en un enlace del sistema de archivos para dañar/eliminar otros archivos que de otro modo no podría tocar.

Para mantener seguras las operaciones de archivos, el servicio WER se apoya en una API estándar llamada GetTempFileNameW y la envuelve con wersvc.dll->UtilGetTempFile; esta API ayuda a WerSvc a generar un nombre de archivo aleatorio no ocupado con el formato "WER****.tmp",

la parte aleatoria del nombre de archivo se genera con un número hexadecimal de 4 bytes, de 0000 a FFFF; si un número ya se ha utilizado para crear un archivo, la API tomará otro nombre de archivo aleatorio.

La estrategia claramente tiene un fallo: si uno crea 65535 archivos con nombres de WER0000.tmp a

WERFFFE.tmp, la API elegirá un número aleatorio y comprobará si el nombre de archivo existe; por ejemplo, WERA560.tmp, verá que el archivo ya existe y, por tanto, continuará probando desde WERA560.tmp hasta WERFFFF.tmp. Mientras la prueba continúa, aparece una ventana de preparación, porque hemos encontrado una forma de hacer que WerSvc se quede bloqueado en la llamada a GetTempFileNameW durante 4-5 segundos, lo cual es una brecha de tiempo bastante grande. Mientras tanto, forzamos al servicio a colocar un archivo temporal con un nombre de archivo fijo, que es

WERFFFF.tmp.

Después de que el servicio cree el archivo temporal llamado WERFFFF.tmp, la API automáticamente

cierra el identificador (handle) que mantiene sobre el archivo y devuelve el nombre del archivo al servicio para operaciones posteriores sobre el mismo; este es exactamente el punto que introduce el bug. Se cumplen tres condiciones:

1. El archivo creado por el servicio está en una posición controlable por el usuario normal.

2. El servicio cierra todos los identificadores (handles) del archivo.

3. El servicio utilizará el archivo más tarde (escribir o eliminar).

Aquí el servicio escribirá contenido en el archivo y lo eliminará. Tanto la escritura como la eliminación provocarán una escalada de privilegios aprovechando enlaces del sistema de archivos y ciertas técnicas de explotación.

Para convertir el bug en eliminación arbitraria de archivos, aprovechamos de forma creativa múltiples junctions de directorios para completar la explotación. Nuestro exploit contiene los siguientes pasos:

• colocamos todos los WER***.tmp en $pwd\1\, y hacemos junction $pwd\2\ -> $pwd\1\;
• creamos un proceso que dispara continuamente esta función con la ruta $pwd\2\, y creamos otro proceso que ejecuta continuamente el comando SetOplock $pwd\1\WERFFFF.tmp;
• una vez que se dispara el Oplock, hacemos junction $pwd\2\ -> \RPC CONTROL\, y luego creamos el enlace simbólico de objeto \RPC CONTROL\WERFFFF.tmp -> $target y \RPC CONTROL\WERFFFF.tmp.etl -> $target;
• liberamos el oplock y el archivo objetivo se eliminará con privilegios de sistema.

La explotación detallada y el PoC se proporcionan en WERReport-CVE-2020-0753.

Al explotar el fallo en GetTempFileNameW, obtenemos una ubicación predecible sobre la que operará el servicio; al hacer uso de junctions del sistema de archivos de múltiples niveles, hacemos que la condición de carrera sea explotable de forma fiable.

Mientras tanto, notamos que este tipo de bug de condición de carrera también puede causar un posible problema de sobrescritura de archivos, lo que probablemente conduzca a bugs de escalada de privilegios en determinadas circunstancias.

De la corrupción arbitraria de archivos con control parcial a la escalada de privilegios

Para explicar por qué la corrupción arbitraria de archivos (si puedes controlar una parte muy pequeña del contenido del archivo: menos de 63 bytes) puede convertirse en EoP, debemos prestar atención al mecanismo de funcionamiento de Windows Defender.

Windows Defender tiene una base de datos de firmas de malware. Si un archivo contiene alguna firma de malware, Defender lo considerará malware y lo eliminará. Sin embargo, esta característica genera una superficie de ataque adicional. Por ejemplo, en WCTF2019, @icchy de tokyowesterns diseñó un desafío de CTF de Windows llamado "Gyotaku The Flag", que usa esta característica como un oráculo para filtrar información.

Aquí aprovechamos esta característica de Windows Defender para eliminar archivos arbitrarios si tenemos una corrupción arbitraria de archivos con control parcial del contenido. Podemos simplemente escribir una firma de malware en un archivo y disparar un escaneo predeterminado de Windows Defender; el archivo se colocará en el área de aislamiento de Defender, que puede ser eliminado por un usuario normal no administrador de IL media simplemente disparando la operación de escaneo 2 veces.

Por lo tanto, un bug de corrupción arbitraria de archivos puede convertirse en eliminación arbitraria de archivos siempre que se pueda colocar una cadena de firma de malware en el archivo objetivo usando el bug.

• Paso 1:

Corrompe el archivo objetivo con un bug e introduce en él una cadena de firma reconocible por Windows Defender.

• Paso 2:

Dispara un escaneo de Windows Defender sobre el archivo objetivo, haciendo que el archivo quede aislado.

• Paso 3:

Dispara el escaneo de nuevo y el archivo objetivo se eliminará.

Al aprovechar esta técnica, conseguimos una eliminación arbitraria de archivos con la ayuda de Defender.

La eliminación arbitraria de archivos puede explotarse mucho más fácilmente para obtener mayores privilegios.

Seis vulnerabilidades DOS sin corregir del sistema de archivos en Microsoft OneDrive

Microsoft OneDrive es el paquete de aplicaciones que proporciona el servicio de almacenamiento personal en la nube,

esta aplicación se ha integrado en Windows como opción de instalación predeterminada desde Windows 8. Durante nuestra investigación, se encontraron y enviaron a MSRC 6 vulnerabilidades en las tareas programadas de servicio de OneDrive.

Aquí hay una tabla de vulnerabilidades que vamos a exponer en las tareas programadas relevantes de Microsoft OneDrive:

Los 6 bugs son causados por el manejo inadecuado de hardlinks y symlinks por parte del servicio, mientras opera en ubicaciones que el usuario normal puede controlar. Durante la explotación de estos bugs, una dificultad proviene de que el nombre de archivo suele contener un pid del proceso actual o una marca de tiempo que indica cuándo se opera el archivo. Ambos pueden resolverse estableciendo un oplock sobre un archivo dll exclusivo que el servicio intentará cargar cuando se dispare su ejecución, donde tenemos la capacidad de obtener todo lo necesario para predecir el nombre de archivo que el servicio intentará operar después. Se proporciona un PoC de ejemplo en el directorio FileSyncConfigTemp_hardlink.

Impactos de la vulnerabilidad

Las 6 vulnerabilidades mencionadas anteriormente se proporcionan con informe completo y programa PoC. Aunque la mayoría de los bugs causan corrupción arbitraria de archivos en primer lugar, este tipo de bug también provoca caídas del sistema (al sobrescribir archivos críticos de configuración del sistema), y todos ellos requerirían la reinstalación de Windows. Por lo tanto, cumplen el estándar del tipo de bug de denegación de servicio del sistema Windows.

Además, este tipo de bug puede causar realmente elevación de privilegios en determinados contextos. Hemos discutido la técnica de explotación que puede aprovechar un problema de sobrescritura arbitraria de archivos para lograr la primitiva de eliminación arbitraria de archivos; por lo tanto, la elevación de privilegios es alcanzable.

Créditos de la vulnerabilidad

Fangming Gu

Zhiniang Peng de Qihoo 360 Core Security

Cronología

02 feb 2020: Vulnerabilidades reportadas

08 feb 2020: MSRC investigó y respondió sobre los 6 bugs de OneDrive que enviamos; su conclusión fue no corregirlos debido a Demasiada interacción del usuario requerida/demasiado difícil construir un exploit fiable.

08 feb 2020: Respondimos: No hay necesidad de interacción del usuario. Solo necesitas esperar a que se ejecute la tarea programada. Por lo tanto, este escenario es típico.

11 feb 2020: MSRC respondió: ¿Cómo se obtiene el archivo específico en la máquina del usuario? ¿Y se coloca cada permutación de ese archivo en esa carpeta? ¿Tiene que coincidir exactamente con Fecha/Hora/PID? Es por estas razones que parece que requiere demasiado esfuerzo del usuario.

11 feb 2020: Respondimos: Nuestro PoC es una versión simplificada, para reducir el esfuerzo de predecir el nombre de archivo. En realidad, solo necesitas establecer un oplock. Entonces puedes obtener todos los {pid}, {hora}, {fecha}. Por lo tanto, no hay necesidad de interacción del usuario.

12 feb 2020: Preguntamos si podemos publicar el writeup de esas 6 vulnerabilidades.

13 feb 2020: MSRC respondió: Puedes publicar un writeup.

22 feb 2020: Detalles publicados

Aunque el hardlink ya recibió una corrección en las compilaciones de Windows Insider Preview, no está corregido en la última versión de lanzamiento de Windows. Y parece que no hay planes de hacer backporting a todos los sistemas operativos compatibles :( . Y negarse a corregir esas vulnerabilidades no parece una acción responsable.