La vulnerabilidad de Día Cero sigue sin parchear; vea qué hacer

Aún no hay parches para esta vulnerabilidad de Día Cero en Windows; vea qué hacer

Por Heimdall ISH

El 22 de noviembre se introdujo en el universo de la seguridad una nueva vulnerabilidad de día cero (aún sin parchear). Clasificada erróneamente en las noticias como un bypass de CVE-2021-41379, en realidad se trata de una nueva variante descubierta por el mismo autor de la vulnerabilidad original, Abdelhamid Naceri.

La PoC(prueba de concepto) liberada por Naceri, InstallerFileTakeOver.exe, se basa en un bug de Windows Installer para cambiar permisos arbitrarios de archivos. Este comportamiento anómalo se dirige al servicio de elevación de privilegios de actualización de Microsoft Edge (MicrosoftEdgeElevationService), dando lugar a la elevación de privilegios a SYSTEM.

Cómo funciona el Instalador de Windows

Tanto CVE-2021-41379 como esta vulnerabilidad de día 0 aprovechan Windows Installer para elevar privilegios modificando el acceso a archivos restringidos del sistema. Para explicar cómo funciona la prueba de concepto de Naceri, primero es necesario explicar cómo funciona Windows Installer. El Instalador de Windows consume paquetes deinstalación, que contienen instrucciones para los pasos del proceso de instalación en una base de datos; estos paquetes tienen la extensión .msi. La documentación de Microsoft clasifica estos dos momentos como adquisición y ejecución.

Durante la adquisición, el instalador sigue las instrucciones de la base de datos del archivo msi y genera un script paso a paso para realizar el proceso de instalación. Durante la fase de ejecución, este script se proporciona a un proceso con privilegios elevados, que lo ejecuta para realizar la instalación en el sistema.

En su documentación para la mitigación temporal de esta vulnerabilidad, el autor demuestra cómo debería funcionar la instalación orquestada msi contenida en su PoC (es decir, sin el error que descubrió y empleó):

Fuente: Abdelhamid Naceri (Windows Installer Micro Patch.pdf)
Fuente: Abdelhamid Naceri(Windows Installer Micro Patch.pdf)

En resumen, PoC crea un paquete de instalación (archivo .msi), que se encargará de:

- Cree en el directorio de destino los archivos @AppHelpToast.png, splwow64.exe y la carpeta "microsoft
plz";

- Crea notepad.exe dentro de la carpeta "microsoft plz".

La carpeta Config.Msi, que se muestra en la parte superior izquierda de la imagen, es una carpeta del sistema que existe en la raíz de C:³.

Esta carpeta guarda copias de seguridad de los archivos durante un proceso de instalación. Si el proceso se interrumpe por cualquier motivo, esta ubicación contiene todo lo necesario para revertir el sistema a su estado anterior a la instalación. Una de las herramientas necesarias para ello es el archivo rollback, de extensión .rbf. Se trata de un script que guiará la restauración de todos los ficheros borrados durante la instalación, cuya copia de seguridad se guarda en Config.Msi. Las siguientes imágenes muestran el proceso descrito por el autor (creación de un msi, seguido de la creación de los archivos y carpetas en cuestión).

Creación del paquete de instalación en el directorio temporal de Windows.
Creación del directorio que recibirá los ejecutables y de la carpeta "microsoft plz".
Creación de la carpeta "microsoft plz".
Archivos notepad.exe, @AppHelpToast.png y splwow64.exe

Fallo en la creación del archivo rollback

Puede haber surgido una duda en los lectores más atentos: si el instalador es el responsable de la creación de ficheros en un directorio, ¿por qué el proceso InstallerFileTakeOver.exe se está metiendo con notepad.exe? Los paquetes de instalación se ejecutan en la sesión 0 (reservada para servicios y otros procesos que ejecuta el usuario SYSTEM) a través de msiexec.exe; por lo tanto, este proceso, y no el PoC, debería escribir el contenido de los ejecutables en cuestión.

La elevación de privilegios para este día 0 se basa en un error que se produce cuando el paquete de instalación intenta acceder a un archivo que está bloqueado para compartir.

Violación de la acción recibida por msiexec.exe

Esta situación provoca que el archivo .rbf se cree fuera del directorio Config.Msi. Así lo ilustra el investigador en el siguiente diagrama:

Fuente: Abdelhamid Naceri(Windows Installer Micro Patch.pdf)

Observe en la esquina inferior izquierda la flecha con el mensaje "bloquear notepad.exe". Esta es una acción intencionada de PoC para causar el bug mencionado y la razón de que su proceso interactúe con un archivo que el paquete de instalación quiere leer. Hay una función específica para esto en el código de la prueba de concepto:

Fuente: Abdelhamid Naceri(InstallerFileTakeOver.cpp)

Pero, ¿para qué sirve este fallo? El fichero rollback no sólo se crea donde no debe, sino que se crea sin suplantación. La suplantación es la capacidad de realizar una acción con credenciales distintas a las que tiene el proceso. Lo correcto sería que msiexec.exe escribiera en el directorio de destino con los permisos de un usuario normal, pero esto ocurre como SYSTEM.

Cambio de permisos en el archivo de destino

Llegamos a la última parte de la prueba de concepto, una condición de carrera. Tan pronto como el archivo .rbf se crea en el lugar equivocado, el proceso InstallerFileTakeOver.exe será alertado.

La imagen de la izquierda trae la prueba de concepto, ya compilada, en un desensamblador. La imagen de la derecha es el código proporcionado por el autor del PoC. El punto de atención es el valor dwNotifyFilter pasado a la API ReadDirectoryChangesW(push 1). Este valor es equivalente a FILE_NOTIFY_CHANGE_FILE_NAME, que notifica cuando se crea, elimina o renombra cualquier archivo dentro del directorio de destino. A continuación, el proceso msiexec.exe debe cambiar los permisos del archivo rollback. Es hora de explotar otro fallo, en el que el proceso de instalación no comprueba si hay enlaces simbólicos o uniones (en las que un directorio actúa como alias de otro directorio del sistema). Aquí PoC inicia una serie de transformaciones de archivos y directorios, que combinarán las uniones y un enlace simbólico en el archivo rollback para hacer que msiexec cambie los permisos de un archivo arbitrario. En el caso de esta prueba de concepto, el objetivo es el sistema de elevación de privilegios para actualizar Microsoft Edge. La secuencia de transformaciones que conducen a este comportamiento se describe con más detalle en este análisis de Rapid7.

El primer punto destacado es el intento de acceso al archivo rollback por parte de msiexec. Las siguientes entradas, asociadas con InstallerFileTakeOver, son los cambios de nombre y las creaciones de enlaces simbólicos que constituyen la condición de ejecución. El segundo resaltado muestra un cambio en el mismo archivo al que msiexec intentó acceder.

Finalmente, el tercer resaltado muestra que el proceso de instalación termina accediendo al ejecutable elevation_service.exe, dentro del directorio de instalación de Microsoft Edge. Justo debajo, la operación SetSecurityFile tiene éxito:

El efecto práctico es cambiar los permisos del archivo de destino, como se demuestra a continuación:

Tras la ejecución de InstallerFileTakeOver.exe (la prueba de concepto), los permisos de elevation_service han cambiado. El usuario que ha realizado la acción (DESKTOP-RP7H2UN\dodo) tiene ahora permiso total sobre el fichero en cuestión, como muestra (F)5.

Este nuevo acceso es utilizado por el autor para sobrescribir dicho ejecutable, como se muestra en las siguientes acciones:

Este cambio es la parte final de la prueba de concepto. El nuevo elevation_service será responsable de abrir un símbolo del sistema elevado, completando la elevación de privilegios:

Es interesante observar que el elevation_service modificado tiene el mismo icono que el ejecutable PoC. Su detección por los motores antivirus también es alta, como se muestra a continuación:

Es posible confirmar la eficacia de la prueba de concepto con un simple comando whoami en el prompt generado:

Limitaciones

La prueba de concepto sólo puede aplicarse a archivos que no estén en uso en el momento de su ejecución. Si se ejecuta sin argumentos, el objetivo es el servicio de elevación de Microsoft Edge. El código de la prueba de concepto tiene una rutina que confirma que este servicio no se está ejecutando:

Observe que el código de la derecha busca el retorno ERROR_SERVICE_DOES_NOT_EXIST como confirmación de que el objetivo no se está ejecutando. Si se proporciona un argumento (en forma de un archivo para el que el usuario desea recibir permisos completos), el objetivo tampoco puede estar en uso. En nuestras pruebas, el uso de la prueba de concepto con un archivo arbitrario proporcionado como argumento provoca la pérdida de la información contenida en el objetivo. Ejemplo: cuando se utiliza contra el archivo system.ini, éste se convierte en 0 bytes después de obtener los permisos. Este comportamiento no significa que esta vulnerabilidad sólo sirva para borrar archivos, como demuestra su uso contra el servicio de elevación Edge.

Detección y mitigación

Al informar sobre esta vulnerabilidad, muchas fuentes la asocian exclusivamente con el servicio de ascensor Microsoft Edge. Esto no es cierto. Aunque dicho ejecutable fue el objetivo elegido por su autor, el comportamiento erróneo del Instalador de Windows que permite la elevación de privilegios no depende del objetivo elegido. Por lo tanto, no aconsejamos que la detección de este día 0 se base en interacciones con elevate_service.exe.

Del mismo modo, la comunidad ha producido reglas de detección YARA basadas en componentes PoC como el archivo de prueba pkg.msi. Este modelo de detección tampoco es fiable, ya que los nombres de los componentes cambian con facilidad.

Un indicador más robusto, también señalado por Rapid7, es el ID de evento 1033 en los registros de la aplicación. Se puede utilizar para encontrar momentos en los que MsiInstaller produjo un error de instalación por VIOLACIÓN DE COMPARTICIÓN (condición necesaria para que la vulnerabilidad funcione). Este error se indica con el código 1603. Del mismo modo, el ID de evento 11306 lleva el mensaje de error propiamente dicho. A continuación se proporciona un ejemplo del mismo:

Error 1306. Another application has exclusive access to the file
'C:\Users\dodo\AppData\Local\Temp{1391479E-FCA4-4BB0-BA7D-BBE51017C60B}\microsoft
plz\notepad.exe'. Please shut down all other applications, then click "Retry".

Observe que el mensaje de error proporciona la ruta completa al archivo implicado en la violación del recurso compartido. Este tipo de error MsiInstaller asociado con directorios inusuales para instalaciones (como %TEMP% en el caso anterior) es un indicador de una posible explotación de esta vulnerabilidad.

Recordamos que la prueba de concepto tiene una rutina que borra todos los ejecutables y carpetas que se crearon durante su ejecución. Por lo tanto, no encontrar los archivos señalados en el error no es un indicador de que el fallo no haya sido explotado.

Hasta la fecha, no se han publicado actualizaciones ni parches que mitiguen esta vulnerabilidad.

Dejar un comentario

Su dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *.