Análisis detallado e implementación de exploit para Windows PrintNightmare (CVE-2021-1675/34527) con escalada de privilegios basada en RPC y ejecución remota de código mediante la instalación de controladores de impresora maliciosos.
= Print Nightmare Informe de análisis :imagesdir: Figures :toc: :icons: font :figure-caption: Fig. :xrefstyle: short :pdf-theme: basic-theme.yml
El 29 de junio de 2021, se expuso una vulnerabilidad muy grave del servicio de impresión de Windows como un 0day, con una puntuación base de 8.8, publicada en GitHub (ya eliminada). Esta vulnerabilidad es la famosa PrintNightmare: CVE-2021-34527, incluso más peligrosa que EternalBlue.
== Información básica de la vulnerabilidad
La vulnerabilidad 34527 afecta a casi todas las versiones posteriores a Windows 7 y Windows Server 2008. Para obtener más información, consulte <>.
Desde el punto de vista del daño, un atacante puede utilizar la autenticación de un usuario normal para ejecutar código arbitrario de forma remota con privilegios de administrador. En cuanto a la dificultad de explotación, esta vulnerabilidad es muy fácil de explotar, por lo que es extremadamente peligrosa.
En cuanto a las características de la vulnerabilidad, la vulnerabilidad 34527 se basa en CVE-2021-1675. La vulnerabilidad 1675 es una vulnerabilidad de escalada de privilegios local y ejecución remota de código, y tiene muchas similitudes con la vulnerabilidad 34527.
Antes de comprender el principio de funcionamiento de la vulnerabilidad, debemos tener una comprensión general de la arquitectura del subsistema de impresión en segundo plano de Windows, lo que nos ayudará a aclarar la relación entre los módulos involucrados en la vulnerabilidad.
== Flujo de llamadas de CVE-2021-1675
=== Arquitectura del subsistema de impresión en segundo plano de Windows
La arquitectura del spooler se puede representar con <<spooler_arch>>:
[[spooler_arch]] .Arquitectura del Spooler de Impresión image::Print Spooler Architecture.png[]
Específicamente, el spooler de impresión se utiliza para gestionar trabajos de impresión y está compuesto por los siguientes componentes:
winspool.drv:: Archivo de biblioteca de vínculos dinámicos proporcionado al usuario. Este archivo define las API de Win32 relacionadas con el spooler para que las llame el usuario. Todas las API dentro utilizan llamadas a procedimientos remotos para obtener el servicio.
spoolsv.exe:: spoolsv.exe actúa como el servidor en el sistema, siendo el primer programa en procesar las llamadas API. Este diseño permite que el spooler de impresión maneje tanto trabajos de impresión locales como remotos sin distinción.
spoolsv.dll:: Programa de enrutamiento. Envía las solicitudes de impresión recibidas por spoolsv.exe a varios proveedores de impresión y decide qué proveedor procesará finalmente la solicitud. Su función es distinguir si el trabajo de impresión es remoto o local. En máquinas remotas, asigna fijamente la tarea al proveedor de impresión local.
localspl.dll:: Proveedor de impresión local. La tarea principal del proveedor de impresión es satisfacer las necesidades de gestión de trabajos de impresión. La mayoría de las API se implementan dentro de este módulo.
Siguiendo la teoría anterior, por ejemplo, cuando llamamos a la función AddPrinterDriverEx (CVE-2021-1675), pasa por el siguiente flujo:
=== Selección de versión de la función
En primer lugar, esta función es en realidad una macro que selecciona la versión Unicode (W) o Ansi (A) según el entorno de compilación local, como en <>:
[[AddPrinterDriverEx]] .AddPrinterDriverEx image::AddPrinterDriverEx.png[]
Pero tanto la versión de caracteres anchos como la de caracteres estrechos no tienen diferencia en el resultado, porque las cadenas del kernel de Windows usan codificación Unicode, por lo que la llamada de la versión Ansi se convertirá en una llamada de la versión Unicode, como en <>:
[[AnsiToUnicode]] .AnsiToUnicode image::AnsiToUnicode.png[]
Cuando los parámetros de la función Ansi se convierten a la versión Unicode, se llama a una función (<>):
[[AnsiCallUnicode]] .AnsiCallUnicode image::AnsiCallUnicode.png[]
Y esta función es en realidad la versión Unicode de AddPrinterDriverEx (<>):
[[GetUnicodeProcAddress]] .GetUnicodeProcAddress image::GetUnicodeProcAddress.png[]
=== La función API envía una solicitud RPC al servidor spooler
Dentro de la función de la versión Unicode, primero se selecciona el tipo de parámetro de la función según el valor de Level:
image::pDriverInfo.png[]
En esta vulnerabilidad, estableceremos Level en 2, es decir, seleccionamos el tipo del parámetro pDriverInfo como la estructura DRIVER_INFO_2. Luego, Windows procesará los parámetros de la función y, después del procesamiento, continuará procesando la API a través de una llamada a procedimiento remoto:
image::set arguments.png[]
image::NdrClientCall3.png[]
=== Mecanismo MSRPC
El mecanismo de llamada a procedimiento remoto de Microsoft se basa en el estándar DCE. Explicado de manera simple, la llamada a procedimiento remoto consiste en ejecutar procesos en un sistema remoto, los cuales están predefinidos por el programador o el sistema.
La forma específica de RPC es serializar la función que se desea llamar de forma remota, transmitirla a través de la red al sistema remoto, donde se deserializa y se ejecuta. En la arquitectura de Microsoft, TCP/IP y SMB son los protocolos comúnmente elegidos para transportar llamadas RPC.
Para usar MSRPC, primero se debe definir la descripción de la interfaz IDL de la función a llamar, y luego usar la herramienta MIDL para generar el stub de serialización correspondiente para el cliente y el servidor. Para algunas API de Win32, el stub del servidor ya está definido, por lo que solo necesitamos generar y usar el stub del cliente.
MSRPC usa UUID para identificar un tipo de protocolo, como MS-RPRN que describe el protocolo de impresión remota. Todas las funciones relacionadas con la impresión remota son parte de este protocolo. MSPRC usa el UUID 12345678-1234-ABCD-EF00-0123456789AB para identificar este protocolo (<<rprn_uuid>>):
[[rprn_uuid]] .UUID de MS-RPRN image::spoolss uuid.png[]
Luego, sobre esta conexión, se puede usar el número de operación (opnum) para identificar las funciones dentro del protocolo y así llamarlas remotamente. Por ejemplo, AddPrinterDriverEx se identifica a sí misma con el número 89 (<<addPrinterDriverEx_opnum>>):
[[addPrinterDriverEx_opnum]] .AddPrinterDriverEx Opnum image::AddPrinterDriverEx Opnum.png[]
Al usar MSRPC, hay dos puntos a tener en cuenta:
"Como puede ver en su salida, los scripts intentan conectarse al puerto 135 (endpoint mapper) para obtener el puerto TCP/IP donde el endpoint DCOM está escuchando (que es un puerto dinámico)." -- SecureAuthCorp/impacket issue #412
=== spoolsv.exe procesa la solicitud API
[[call_flow]] .Flujo de llamadas de RpcAddPrinterDriverEx image::Function Calls.png[]
De <<call_flow>> se puede ver que spoolsv.exe llama a estas funciones, y desde el análisis interno de las funciones, este módulo no realiza ninguna operación aparte de la inicialización. Finalmente, este módulo llama a la función apuntada por pLocalProvidor, que es la función LocalAddPrinterDriverEx dentro del módulo localspl.dll. localspl, como proveedor de impresión local, es el módulo que realmente implementa la funcionalidad de la API.
=== Lógica de implementación de funciones del proveedor de impresión local
[[LocalAddPrinterDriverEx]] .LocalAddPrinterDriverEx image::LocalAddPrinterDriverEx.png[]
Primero, <> explica que este módulo verifica que el spooler esté funcionando correctamente, y luego salta a la función SplAddPrinterDriverEx.
[[SplAddPrinterDriverEx]] .SplAddPrinterDriverEx image::SplAddPrinterDriverEx.png[]
