Lo bueno (o lo malo) es que con este Windows Downdate se logra degradar componentes críticos del sistema operativo, incluidas DLLs, drivers e incluso el kernel y, después de estos downgrades, el sistema operativo informa que está completamente actualizado y no puede instalar actualizaciones futuras, mientras que las herramientas de recuperación y escaneo no pueden detectar problemas.
¿Cómo funciona esto?
Empezamos entendiendo a grandes rasgos como funciona el flujo en una actualización en Windows:
- En primer lugar, el cliente solicita al servidor que realice la actualización contenida en una carpeta de actualización que proporciona.
- A continuación, el servidor valida la integridad de la carpeta de actualización.
- Tras la verificación, el servidor opera sobre la carpeta de actualización para finalizar los archivos de actualización. Estos se guardan en una carpeta controlada por el servidor, a la que no tiene acceso el cliente.
- El servidor guarda una lista de acciones en la carpeta controlada por el servidor, a la que no tiene acceso el cliente. La lista de acciones se denomina Pending.xml y contiene las acciones de actualización que se deben realizar. Por ejemplo, especifica qué archivos se deben actualizar, los archivos de origen y destino, etc.
- Por último, cuando se reinicia el sistema operativo, se opera sobre la lista de acciones y las acciones de actualización se realizan durante el reinicio.
El cliente solo controla la carpeta de actualización inicial. Por lo tanto, el research se centró al principio en si se podía modificar, lo que resultó en archivos de actualización de downgrading personalizados.
¿Cómo es esa carpeta de update?
La carpeta de actualización contiene componentes de actualización y cada componente de actualización contiene archivos MUM, de manifiesto, diferenciales y de catálogo, como se muestra a continuación.
- Los archivos MUM son metadatos de Microsoft Update y contienen información de metadatos, dependencias de componentes, orden de instalación, etc.
- Los archivos de manifiesto contienen información específica de la instalación, como rutas de archivo, claves de registro, qué instaladores ejecutar como parte de la instalación y más.
- Los archivos diferenciales son archivos delta de archivos base. Un archivo base más un archivo delta daría como resultado el archivo de actualización completo.
- Los archivos de catálogo son las firmas digitales de los archivos MUM y de manifiesto. Los catálogos permiten firmar varios archivos a la vez, en lugar de que el archivo que queremos firmar incorpore su firma digital. Además, los archivos del catálogo están firmados digitalmente, lo que hace imposible modificarlos ni a ellos ni a los archivos que firman.
En resumen:
- Solo los archivos de catálogo están firmados digitalmente.
- El manifiesto y los MUM no están firmados explícitamente, sino que están firmados por los catálogos.
- Los archivos diferenciales no están firmados. También controlan el contenido del archivo de actualización final.
Pensarás.. está claro, ¡a por los ficheros diferenciales! Pero no... porque el hash del archivo de actualización esperado está hardcodeado en el manifiesto. Y el manifiesto no se puede cambiar, ya que eso rompería su firma en el catálogo.
¡A por el Action List!
Sabemos que no se puede cambiar el contenido, porque está forzado para el Trusted Installer. Pero también que el proceso de actualización se realiza en varios reinicios, por lo que se supone que el estado de la lista se guarda en algún lugar.
Hay un path interesante en el registro PoqexecCmdline que contiene el ejecutable que analiza la lista y la ruta de la lista:
Esa clave de registro no está sin embargo forzada para el Trusted Installer. ¡Bingo! Esto permite controlar todas las acciones de actualización.
La lista de acciones (pending.xml) es un archivo XML que proporciona la funcionalidad de crear archivos, eliminar archivos, mover archivos, crear enlaces duros a archivos, crear claves y valores de registro, eliminar claves y valores, ¡y mucho más!
<POQ postAction=”reboot”>
<CreateFile path=”C:\Windows\System32\Create.exe” fileAttributes=”0x00000000″/>
<MoveFile source=”C:\UpdateDir\Source.exe“ destination=”C:\Windows\System32\Destination.exe”/>
<HardlinkFile source=”C:\UpdateDir\Source.exe“ destination=”C:\Windows\System32\Destination.exe”/>
<SetFileInformation path=”C:\UpdateDir\Source.exe“ securityDescriptor=”binary base64:[BASE64-BLOB]” flags=”0x00000040″/>
<DeleteFile path=”C:\Windows\System32\Delete.exe”/>
<CreateDirectory path=”C:\Windows\System32\Directory” fileAttribute=”0x00000080“ securityDescriptor=”binary base64:[BASE64-BLOB]”/>
<CreateKey path=”\Registry\Machine\Key”/>
<SetKeyValue path=”\Registry\Machine\Key” name=”Name” type=”0x00000001“ encoding=”base64″ value=”[BASE64-BLOB]”/>
<SetKeySecurity path=”\Registry\Machine\Key“ securityDescriptor=”binary base64:[BASE64-BLOB]” flags=”0x00000001″/>
<DeleteKeyValue path=”\Registry\Machine\Key” name=”Value”/>
<DeleteKey flags=”0x00000001″ path=”\Regsitry\Machine\Key”/>
</POQ>Para hacer el downgrade se pude usar un file action de hadr-lib para reemplazar el destino:
<HardlinkFile source=”C:\UpdateDir\Source.exe“ destination=”C:\Windows\System32\Destination.exe”/>La "des-actualización"
Para iniciar una actualización, "todo" lo que se tiene que hacer es:
El identificador es un número dinámico que se compara con el identificador de la lista de acciones para fines de integridad. Ninguna de las tres acciones anteriores se aplica mediante Trusted Installer. Esto permite actualizar el sistema con una lista de acciones personalizada que hace downgrade el sistema. Se pasaron por alto todas las verificaciones de integridad, ya que se supone que la lista de acciones está verificada porque se crea después de la verificación.
Como resultado, no es necesario realizar la elevación maliciosa a Trusted Installer. En cambio, Windows Updates hizo todo el trabajo sucio.
Por lo tanto se puede lograr un compromiso completo de Windows Update con un ataque de degradación que es:
- Totalmente indetectable. Dado que se realiza de manera legítima, no se detecta ninguna actividad maliciosa.
- Invisible. Debido a que técnicamente "actualiza" el sistema, y parece completamente actualizado.
- Persistente. El analizador de la lista de acciones poqexec.exe además no está firmado digitalmente. Como resultado, pude aplicarle un parche para instalar actualizaciones vacías, lo que significa que cualquier actualización nueva disponible se instalará incorrectamente.
- Irreversible. También se descubrío que la utilidad de integridad y reparación SFC.exe no está firmada digitalmente. También pude aplicarle un parche, lo que significa que ya no detectará ninguna corrupción. También encontró DISM.exe, pero detecta corrupciones en el almacén de componentes, que no hay razón para modificar.
La herramienta PoC
Pues la tenéis en https://github.com/SafeBreach-Labs/WindowsDowndate, en Python y hasta con su binarios para los más vagos.
Su uso es muy sencillo:
windows_downdate.py --config-xml <CONFIG XML PATH> <ADDITIONAL ARGS>
Windows Downdate tiene ejemplos de uso integrados con archivos XML de configuración listos y módulos vulnerables. Los ejemplos de uso a fecha de este post se enumeran a continuación:
- CVE-2021-27090 Secure Kernel Elevation of Privilege Patch Downgrade
- CVE-2022-34709 Credential Guard Elevation of Privilege Patch Downgrade
- CVE-2023-21768 AFD Driver Elevation of Privilege Patch Downgrade
- Hyper-V Hypervisor Downgrade
- Kernel Suite Downgrade
- PPLFault Patch Downgrade
- VBS UEFI Lock Bypass
¡Sed buenos!
Comentarios
Publicar un comentario