Laboratorio de investigación CVE-2025-53770

Este repositorio parece ser un proyecto de investigación de prueba de concepto para validar un problema de deserialización y procesamiento de ToolPane de estilo SharePoint en un laboratorio controlado. Incluye un controlador Python, una aplicación vulnerable simulada y recursos de contenedores para pruebas aisladas.

[!WARNING] Este proyecto solo debe utilizarse en sistemas, contenedores o redes que sean de tu propiedad o para los que tengas autorización explícita para realizar pruebas. No ejecutes este código contra infraestructuras públicas, servicios de terceros, entornos de producción ni ningún objetivo sin permiso por escrito. Las pruebas de seguridad no autorizadas pueden violar la ley, contratos, políticas o términos de uso aceptables.

El contenido de este repositorio debe tratarse como material sensible de investigación de seguridad. Si utilizas este proyecto para trabajos de evaluación, mantén la ejecución aislada, registra toda la actividad y coordina con el propietario del sistema antes de realizar las pruebas.

Alcance del proyecto

El repositorio contiene actualmente:

• sploit.py: controlador Python asíncrono que envía solicitudes manipuladas a un endpoint de ToolPane.
• lab/mock_vulnerable_app.cs: aplicación ASP.NET simulada que refleja un marcador de validación y, en su forma actual, puede ejecutar un comando proporcionado dentro del contenedor del laboratorio.
• lab/docker-compose.yml: laboratorio local de dos contenedores que separa el objetivo simulado del terminal del atacante.
• lab/Dockerfile: compilación .NET de varias etapas que publica la aplicación vulnerable simulada en una imagen de runtime ASP.NET más pequeña y la ejecuta como un usuario no root.
• lab/attacker.Dockerfile: definición del contenedor atacante Python que preinstala el conjunto de dependencias del script necesario para el terminal del laboratorio.
• lab/vulnerable.csproj: archivo de proyecto web .NET 6 para la aplicación vulnerable simulada.
• lab/genGadget.py: script auxiliar para generar una carga útil (payload) Base64 comprimida para pruebas de deserialización solo en laboratorio.

Configuración y uso

Este flujo de trabajo está pensado únicamente para el laboratorio local.

Requisitos previos:

• Docker Engine con soporte para Compose
• Un shell local con permiso para ejecutar comandos de Docker

Inicia el laboratorio desde el directorio lab/:

cd lab
docker-compose up --build -d

Si tu configuración de Docker requiere privilegios elevados, ejecuta los mismos comandos con sudo.

Confirma que ambos contenedores están en ejecución:

docker-compose ps

Registro en caso de problemas o validación de exploits:

docker logs sp_attacker
docker logs sp_vulnerable_lab

El laboratorio está aislado intencionadamente:

• el contenedor objetivo se ejecuta en la red interna lab_net;
• no se publican puertos en el host;
• el contenedor del atacante se proporciona como un terminal desechable dentro de la misma red privada.

Abre un shell en el contenedor del atacante:

docker exec -it sp_attacker bash

Desde el interior del contenedor del atacante, puedes realizar comprobaciones seguras para el laboratorio, como confirmar que el objetivo es accesible y probar el script en modo de verificación contra el objetivo simulado:

python3 sploit.py http://sp_vulnerable_lab/
# If service-name DNS resolution fails in your environment, use the lab IP:
# python3 sploit.py http://10.10.10.5
# If you wish to go past base validation you can include wanted commands.
python3 sploit.py http://sp_vulnerable_lab whoami

Comportamiento esperado en el entorno simulado local:

• el objetivo debe ser accesible como http://sharepoint-target desde el contenedor del atacante;
• la aplicación simulada devuelve un marcador determinista para la verificación;
• cualquier artefacto de resultado generado por el script permanece dentro del espacio de trabajo del laboratorio montado.

Notas operativas:

• mantén el laboratorio desconectado de redes externas y no publiques el servicio objetivo en el host;
• no reutilices este entorno para evaluaciones de producción;
• si modificas la aplicación simulada o las definiciones de los contenedores, reconstruye las imágenes antes de volver a probar.

Limpieza

Detén y elimina los contenedores y la red del laboratorio:

cd lab
docker-compose down

Si también quieres eliminar las imágenes construidas:

docker-compose down --rmi local

Si quieres un restablecimiento completo de los artefactos del espacio de trabajo del laboratorio, elimina cualquier archivo de resultados generado después del apagado:

rm -f vuln.lst

Práctica de limpieza recomendada después de cada ejercicio:

1. apaga el laboratorio con docker-compose down;
2. elimina los artefactos de resultados que no deban persistir;
3. reconstruye el laboratorio antes de la siguiente ejecución si cambiaste código, dependencias o configuración de contenedores.

Resumen de validación

El proyecto es estructuralmente válido como laboratorio de investigación local, pero no debe tratarse como un validador seguro para producción en su forma actual.

Lo que funciona:

• La topología del laboratorio es simple y reproducible.
• El controlador Python puede probar un objetivo o una lista de objetivos.
• La aplicación simulada ofrece indicadores de éxito deterministas para la verificación en el laboratorio.

Lo que requiere precaución:

• El script principal incluye un comportamiento explícito de ejecución de comandos cuando se proporciona un segundo argumento.
• La verificación TLS está deshabilitada en las solicitudes salientes.
• Los hallazgos positivos se escriben en vuln.lst, lo que puede generar datos sensibles residuales innecesarios.
• La aplicación simulada ejecuta directamente la entrada del shell y nunca debe exponerse fuera de un laboratorio aislado.

Metodología

Utiliza este proyecto únicamente para la validación controlada de detección y exposición, no para explotación operativa.

Metodología recomendada:

1. Construye un entorno de laboratorio aislado sin exposición externa.
2. Valida los límites de la red para que solo el investigador pueda alcanzar el servicio simulado.
3. Ejecuta el objetivo del laboratorio y confirma que la aplicación responde al endpoint previsto.
4. Usa el controlador solo en modo de verificación no destructiva para confirmar si el objetivo refleja el marcador esperado.
5. Captura los artefactos de solicitud y respuesta para la documentación y, a continuación, destruye el entorno de laboratorio después de las pruebas.

Para trabajos de evaluación en el mundo real, el estándar más seguro es sustituir la validación de tipo exploit por una o más de las siguientes opciones:

• verificación de la versión y del nivel de parche;
• revisión de configuración autenticada;
• análisis de registros de la capa web;
• revisión de telemetría de EDR, SIEM y WAF;
• indicadores de compromiso proporcionados por el proveedor y comprobaciones de estado.

Impacto

Si un objetivo es realmente vulnerable a una falla de deserialización en un componente de aplicación privilegiado, el impacto potencial puede ser grave:

• ejecución remota de código en el contexto de seguridad del servicio afectado;
• pérdida de confidencialidad de los datos de la aplicación, credenciales y secretos;
• pérdida de integridad mediante la manipulación de contenido o configuración;
• degradación de la disponibilidad por comandos destructivos o acciones posteriores;
• oportunidades de movimiento lateral si el host tiene amplios privilegios de red o identidad.

Incluso en un laboratorio, la semántica de ejecución de comandos aumenta significativamente el riesgo porque normaliza flujos de trabajo que deberían reservarse para una investigación autorizada y estrictamente controlada.

Mitigaciones

La vía de mitigación adecuada es defensiva y en capas.

Acciones inmediatas:

1. Aplica las actualizaciones de seguridad del proveedor y las guías de emergencia para la versión del producto afectado.
2. Elimina la exposición pública o restringe el acceso a la superficie de la aplicación vulnerable.
3. Rota las credenciales y revisa las cuentas de servicio privilegiadas si se sospecha un compromiso.
4. Inspecciona los registros, las tareas programadas, los procesos hijo y las conexiones salientes en busca de actividad posterior a la explotación.
5. Preserva las evidencias antes de la limpieza si el entorno podría estar ya comprometido.

Acciones de endurecimiento (hardening):

1. Aplica segmentación de red alrededor de SharePoint o niveles de aplicación equivalentes.
2. Coloca el servicio detrás de un proxy inverso, WAF o control de filtrado equivalente.
3. Reduce el privilegio de las cuentas de servicio y la capacidad de ejecución local siempre que sea posible.
4. Habilita el registro centralizado y las alertas para solicitudes sospechosas a /_layouts/15/ToolPane.aspx y rutas administrativas adyacentes.
5. Supervisa la creación inesperada de procesos desde el contexto del proceso de trabajo de la aplicación.

Mitigaciones específicas para laboratorios de investigación:

1. Mantén el laboratorio en una red puente aislada sin publicar puertos en el host.
2. Elimina el código de ejecución de comandos de la aplicación simulada a menos que sea estrictamente necesario para una demostración controlada.
3. Separa la validación benigna de cualquier funcionalidad peligrosa en diferentes scripts o ramas.
4. Evita almacenar listas de objetivos positivos a menos que exista una necesidad documentada de retención.
5. Destruye y reconstruye el laboratorio después de cada ejercicio.

Descargo de responsabilidad

Este README no proporciona instrucciones para explotar sistemas en producción. Documenta el repositorio como un artefacto controlado de investigación y describe prácticas más seguras de validación y mitigación.

Referencias

• CVE.org: CVE-2025-53770 - registro CVE canónico con metadatos CNA, rangos de versiones afectadas, CVSS y referencias vinculadas.
• NVD: Detalle de CVE-2025-53770 - enriquecimiento de NIST, cobertura CPE, mapeo CWE y agregación de referencias.
• Guía de actualización de seguridad de Microsoft: CVE-2025-53770 - aviso principal del proveedor con información sobre impacto, explotabilidad, mitigaciones y actualizaciones de seguridad.
• Microsoft Learn: Configurar la integración de AMSI con SharePoint Server - guía de endurecimiento de Microsoft referenciada por el aviso del proveedor para mitigación y validación.
• Blog de Microsoft MSRC: Orientación para clientes sobre la vulnerabilidad de SharePoint CVE-2025-53770 - orientación del proveedor y contexto de respuesta para la explotación activa.
• Alerta de CISA: Microsoft publica orientación sobre la explotación de la vulnerabilidad de SharePoint CVE-2025-53770 - alerta del gobierno de EE. UU. y orientación para la respuesta operativa.
• Entrada del catálogo de vulnerabilidades explotadas conocidas de CISA para CVE-2025-53770 - confirmación de que la vulnerabilidad se añadió al KEV junto con plazos de remediación y orientación de acción.

Autor

• J4ck3LSyN
• github