Hace unos 10 días los exploits para Microsoft SharePoint (CVE-2025-53770, CVE-2025-53771) comenzaron a ser abusados públicamente. Escribimos sobre eso en aquí y aquí .
La vulnerabilidad original de SharePoint es una vulnerabilidad de deserialización que permitió a un atacante ejecutar comandos arbitrarios, si bien estos podrían ser literalmente cualquier cosa, la mayoría de las exploits que analizamos dio como resultado que los atacantes dejen caer un archivo ASPX que acaba de revelar la clave de la máquina IIS. Esto me llevó a sumergirme un poco más en cómo se puede abusar de esto.
¿Qué son las teclas de la máquina IIS?
Una clave de máquina en IIS y ASP.NET es una configuración de configuración utilizada para garantizar la seguridad y la integridad de los datos intercambiados entre el servidor y los clientes.
Básicamente, es responsable de validar y encriptar datos confidenciales como ViewState, Cookies y State de Session, protegiéndolos de manipulación o acceso no autorizado. Un administrador de IIS puede definir configuraciones de clave de máquina específicas: hay muchas formas posibles de configurar todo esto, pero para este diario analizaremos la protección ViewState.
ViewState es un mecanismo utilizado en formularios web ASP.NET para persistir el estado de los controles y los datos de la página entre las posteriores (es decir, entre las acciones del usuario que devuelven la página al servidor). Permite al desarrollador almacenar fácilmente los valores de varios controles después de que se haya enviado un formulario. ViewState siempre es utilizado por una aplicación IIS APS.NET.
Dado que ViewState puede contener información confidencial, debe protegerse adecuadamente. Y aquí es donde las teclas de la máquina entran en el juego: son utilizadas por IIS para evitar la manipulación de ViewState y (opcionalmente) cifrar su contenido.
De manera predeterminada, IIS (incluso la última versión en Windows Server 2025) habilitará la validación de ViewState Mac (código de autenticación de mensajes), pero dejará el cifrado en «Auto», lo que significa que no se usa, como se muestra en la figura a continuación:
Esto no es un problema demasiado grande, a menos que un desarrollador decida almacenar algo confidencial en ViewState.
La clave de la máquina, como probablemente pueda adivinar, se usa para realizar la validación; nuevamente, se utiliza por defecto SHA1. Se admiten varios otros algoritmos, con Hmacsha256 como el segundo más utilizado.
Manejo de llaves de la máquina
Dado que la clave de la máquina se utiliza para validar la integridad de ViewState, obviamente es un elemento de seguridad muy importante. Si un atacante obtiene la clave de la máquina de un servidor, puede modificar ViewState (y cookies) a los valores arbitrarios y calcular Mac adecuado, lo que podría permitirles realizar todo tipo de abuso, incluso lograr la ejecución de código remoto, como lo demostraremos más adelante.
Entonces, ¿cómo se maneja esto? Toda la configuración puede ser un poco compleja dependiendo de la cual se esté ejecutando la cuenta II, pero en las configuraciones más comunes, se utiliza uno de los siguientes dos enfoques:
La clave de la máquina es generada automáticamente por IIS. Esta es la configuración predeterminada (una que puede ver en la imagen de arriba) y en este caso la clave de la máquina se almacena en el registro.
La tecla de la máquina es generada por un administrador y se almacena en el web.config archivo. Esto es realmente obligatorio si tiene una granja de servidores detrás de un equilibrador de carga que necesita poder compartir sesiones, ¡así que tal configuración es bastante común!
Robar una tecla de máquina
El premio final de un atacante es robar una clave de máquina utilizada por el servidor IIS objetivo. Entonces, ¿cómo pueden lograr eso?
Si la tecla de la máquina se almacena en un web.config Archivo, ¡en la mayoría de los casos, se almacenará allí en texto plano! Si bien es posible cifrar la sección de configuración, esto rara vez se hace. En otras palabras, un atacante que puede buscar el archivo web.config ¡Básicamente puede PWN todo el servidor!Esto se puede hacer, por ejemplo, a través de vulnerabilidades LFI (inclusión de archivos local) o vulnerabilidades XXE (entidades externas XML) que permiten al atacante obtener contenidos de archivos.
Si la clave de la máquina se genera automáticamente, se almacena en el registro, lo que significa que el atacante necesita la ejecución del código en el servidor para obtener esto, pero se debe enfatizar aquí una cosa importante: No hay nada que se pueda hacer para evitar que lean la clave de la máquina, siempre que obtengan la ejecución del código, ¡incluso a través de archivos ASPX!
Volver a nuestra historia de SharePoint: una vez que los atacantes originales explotaron un servidor vulnerable de SharePoint, cargaron el siguiente archivo ASPX:
< %@ Importación de nombres = "System.DiaGnitalics" %>< %@ Importación de nombres = "System.io" %>
¿Qué hace este script? Intentará leer el web.config archivo y mostrará claves de validación y cifrado, junto con el modo usado. Si se almacenara una tecla de máquina en Web.Config, se filtraría a un atacante, como se muestra en la imagen a continuación:
Con la clave de la máquina disponible, el atacante ahora puede lograr RCE en el servidor afectado, debido a la deserialización de la deserialización de ViewState Works (¡y esta es una característica!), Más sobre eso más abajo, pero veamos el otro caso, cuando la tecla de máquina se genera automáticamente y no se almacena en Web.Config:
¡Oh! No hay suerte para el atacante, este script no pudo obtener la tecla de la máquina. Uf, todo bien, no tenemos que hacer nada … ¿o sí? Recuerde que escribí anteriormente que las claves de la máquina generadas automáticamente se almacenan en el registro. ¿Hay algo que evite que el atacante deje caer un poco mejor el archivo APSX que pueda leer el registro?
Desafortunadamente no, como Soroush Dalili escribió en su fantástico blog aquí – Uno simplemente puede leer la clave, sin importar dónde se almacene. Soroush publicó un pequeño archivo ASPX que pasa por todas las ubicaciones potenciales de una clave de máquina.
Claramente, a los atacantes de SharePoint no les importaba otras ubicaciones (y estaban contentos con los Web.Config), o no sabían sobre esto, pero si usa el script de Soroush, puede obtener la clave de la máquina incluso cuando se genera automáticamente, como se muestra para la misma aplicación que estoy usando como prueba de concepto a continuación:
En pocas palabras, aquí está lo siguiente: si alguien obtiene alguna ejecución de código en un servidor IIS, absolutamente necesita regenerar la clave de la máquina del servidor. Windows no hará esto automáticamente por usted, ¡Y esta clave persiste a través de reinicios!
Ejecución de código remoto
Entonces, ¿qué se puede hacer con la tecla Machine ahora?
Si bien podemos modificar los valores en ViewState (es un poco difícil leerlo ya que está serializado, pero no imposible, por supuesto), también se puede usar Ysoserial.net de Alvaro Muñoz, que tiene soporte integrado para generar objetos ViewState.
Ahora que tenemos una clave de máquina válida, ysoserial.net nos permite crear un objeto que, tras la deserialización en el lado del servidor, ejecutará código. Dado que Mac será válido (e incluso encriptado, si es necesario), IIS intentará deserializarlo con la clase Losformatter que finalmente permitirá la ejecución del código remoto a través de la deserialización, ya que hay dispositivos conocidos que se pueden usar aquí.
Hay dos puntos clave aquí:
Hay nada que un administrador pueda hacer para evitar esto Si un atacante tiene una clave de máquina válida
Un parámetro de vista de vista malicioso se puede usar con * cualquier * script ASPX en el servidorno necesita ser el originalmente vulnerable. Hay algunas advertencias sobre cómo producir un parámetro ViewState válido basado en la ruta de aplicación, pero hay muchos otros recursos que explican cómo hacer esto.
Para reiterar: una vez que un atacante tiene una clave de máquina válida, básicamente tiene una puerta trasera al servidor IIS que puede usar en cualquier momento, ¡siempre que la clave de la máquina no haya cambiado!
POC || Gtfo
Demostrar esto. Tengo una aplicación muy simple que permite que un usuario ingrese su nombre (y también lo usará en un diario en el futuro), que se ve así:
Cuando se hace clic en el botón Enviar, se envía la siguiente solicitud:
Ahora, el servidor IIS que he configurado está utilizando claves de máquina generadas automáticamente, para que la explotación sea un poco más interesante (observe que no dije difícil). Cuando se usa el script que publicó Soroush, se puede volver a ver la siguiente información:
Esto nos deja con toda la información necesaria para explotar este servidor.
Usaremos ysoserial.net para hacer esto, específicamente con las siguientes opciones:
El complemento que utilizaremos será Viewstateque nos permitirá generar un objeto Malicioso ViewState, proporcionado con la tecla de la máquina.
La cadena de gadgets será Formateo de texto – Por lo general, genera la carga útil más corta y admite Losformatter
El comando será nuestro PowerShell, que se conectará con nuestro oyente de Netcat
Finalmente necesitaremos proporcionar lo siguiente:
La clave de validación es la clave de la máquina desde arriba. Usaré una clave de validación específica de la aplicación, ya que podemos ver que, además de la generación de la tecla de la máquina, el servidor está utilizando IsolataApps para que cada aplicación tenga su propia clave de máquina, que se deriva de la inicial
El algoritmo de validación será HMACSHA256
Mi ruta y appPath corresponderán a la aplicación que estoy atacando (ver la publicación de Soroush para obtener más información sobre esto)
Finalmente estoy usando el algoritmo adecuado para .NET 4.0
Todo lo que tenemos que hacer ahora es volver y reenviar la solicitud, pero esta vez con nuestro objeto Malicioso ViewState:
La respuesta será 500 error de servidor interno, pero eso es lo que queremos:
Y obtenemos nuestro baile feliz de Shell Reverse:
Finalmente, el atacante ahora puede usar este objeto Malicioso ViewState en cualquier página que pertenezca a esta aplicación, sin importar qué otros parámetros se envíen, ya que IIS intentará deserializar el objeto ViewState recibido. Y esa es su persistente puerta trasera.
Detección
IIS al menos registrará un evento cuando la verificación de ViewState haya fallado. Falló aquí no significa que Mac fuera incorrecto (que se ignora silenciosamente), pero cuando el proceso de verificación falló, lo que sucederá cuando se explote la deserialización.
El objeto Full ViewState se registra para que también permita inspeccionar lo que sucedió. Si aún no lo hace, asegúrese de monitorear el código de evento 4009 en el código de aplicación de Windows. Tal evento se verá como se muestra a continuación:
-Bojan
?INCÓGNITA | LinkedIn
Infigo es | Un Grupo de Aluricidad miembro