Exploit for Session-Fixation-in-Vvveb-CMS-v1.0.6.1

## https://sploitus.com/exploit?id=KITPLOIT:TOOLS-GITHUB-HELLOANDREWPAUL-SESSION-FIXATION-IN-VVVEB-CMS-V1.0.6.1
# Fijación de Sesión en Vvveb CMS v1.0.6.1

  * **Autor:** Andrew Paul

  * **Fecha de Descubrimiento:** 9 de junio de 2025

  * **Vendedor:** Vvveb

  * **URL del Vendedor:** http://vvveb.com

  * **GitHub del Vendedor:** https://github.com/givanz/Vvveb

  * **Versión Afectada:** 1.0.6.1 (y probablemente versiones anteriores)

  * **ID CVE:** CVE-2025-8517




## Resumen

Se descubrió una vulnerabilidad de Fijación de Sesión, clasificada como CWE-384: Session Fixation, en el mecanismo de autenticación de Vvveb CMS versión 1.0.6.1. El sistema no crea ni impone un nuevo identificador de sesión tras un inicio de sesión exitoso. Este fallo fundamental permite dos variantes de ataque: un ataque estándar de Fijación de Sesión usando un ID de sesión emitido por el servidor, y un ataque más severo donde un atacante puede inventar una cadena arbitraria para usarla como ID de sesión. En ambos casos, la vulnerabilidad puede ser explotada para secuestrar la sesión autenticada de un usuario, lo que lleva a una toma de control total de la cuenta.

## Mapeo OWASP Top 10 2021

Esta vulnerabilidad se correlaciona con varias categorías del OWASP Top 10 2021:

  * **A01:2021 - Control de Acceso Roto:** El impacto final del ataque es un fallo completo del control de acceso, ya que el atacante obtiene todos los permisos y derechos de acceso de la cuenta de usuario secuestrada.

  * **A04:2021 - Diseño Inseguro:** El proceso de autenticación es inherentemente inseguro por diseño porque carece de un control de seguridad fundamental: la regeneración de tokens de sesión al producirse un cambio en el nivel de privilegios.

  * **A07:2021 - Fallos de Identificación y Autenticación:** La aplicación no gestiona adecuadamente el ciclo de vida de los identificadores de sesión después del inicio de sesión, permitiendo que un atacante fije una sesión y se haga pasar por un usuario.




## Detalles de la Vulnerabilidad

La causa raíz de esta vulnerabilidad es un fallo completo en la gestión segura del estado de la sesión durante el proceso de autenticación. Esto se manifiesta en dos fallos distintos pero relacionados:

  1. **Fallo al Regenerar IDs de Sesión Legítimos:** La aplicación no genera un nuevo `PHPSESSID` tras un inicio de sesión válido. Esto permite a un atacante visitar la página de inicio de sesión, obtener un ID de sesión legítimo previo a la autenticación, fijarlo en el navegador de la víctima y luego usar ese mismo ID para secuestrar la sesión.

  2. **Aceptación de IDs de Sesión Arbitrarios:** De manera más crítica, el mecanismo de sesión de la aplicación confía ciegamente en los identificadores proporcionados por el cliente. Un atacante no necesita un ID de sesión real del servidor; puede inventar cualquier cadena arbitraria (por ejemplo, 'hacked'), que el servidor aceptará y luego elevará a una sesión autenticada tras el inicio de sesión. Esto elimina un paso para el atacante y resalta la profunda naturaleza del fallo.




## Vectores de Ataque Potenciales

Esta vulnerabilidad puede ser explotada a través de cualquier vector que permita a un atacante establecer o "fijar" una cookie en el navegador de la víctima. Los vectores comunes incluyen:

  * **Cross-Site Scripting (XSS):** Un fallo XSS separado podría permitir la explotación remota.

  * **Acceso Físico (Estación de Trabajo Compartida):** Un atacante puede establecer manualmente la cookie en un ordenador compartido.

  * **Hombre en el Medio (MitM):** Un atacante en una red insegura podría interceptar el tráfico para plantar la cookie.




## Prueba de Concepto (PoC)

Esta PoC demuestra una toma de control total de una cuenta de administrador desde una máquina separada, destacando la ruta de ataque más severa utilizando un identificador inventado por el atacante.

**Pasos:**

  1. **El Atacante Inventa un Identificador:** El atacante elige una cadena arbitraria para que actúe como identificador de sesión, por ejemplo: `session-hijacked-by-andy`.

  2. **El Atacante Planta la Cookie:** En la máquina de la víctima, el atacante utiliza las herramientas de desarrollador del navegador para establecer la cookie `PHPSESSID` en `session-hijacked-by-andy` para el dominio de Vvveb CMS.

  3. **La Víctima (Administrador) Inicia Sesión:** La víctima, usando el mismo navegador, inicia sesión en Vvveb CMS con sus credenciales de administrador.

  4. **Fallo del Sistema:** El CMS valida las credenciales de la víctima pero no genera una nueva cookie de sesión. En su lugar, promueve la cookie del atacante (`session-hijacked-by-andy`) a una sesión de administrador completamente autenticada.

  5. **El Atacante Secuestra la Sesión:** Desde un ordenador separado, el atacante establece la cookie `PHPSESSID` de su navegador en `session-hijacked-by-andy` y navega al panel de administración de Vvveb CMS.




**Resultado:** El atacante obtiene acceso administrativo inmediato y completo al CMS sin necesidad de la contraseña de la víctima.

## Impacto

Una explotación exitosa resulta en un compromiso total de la cuenta del usuario objetivo. Si la víctima es un administrador, el impacto es crítico e incluye:

  * **Control Administrativo Completo:** El atacante obtiene control total sobre el CMS, equivalente al del administrador secuestrado.

  * **Compromiso de Datos:** Capacidad total para leer, modificar, exportar o eliminar todo el contenido del sitio, datos de usuario y detalles de configuración sensibles.

  * **Persistencia en el Sistema:** El atacante puede crear un nuevo usuario con privilegios completos de administrador. Esto le proporciona una puerta trasera persistente en el sistema, incluso después de que la sesión secuestrada original expire o el administrador legítimo cierre sesión.

  * **Ataques Adicionales:** La cuenta de administrador comprometida puede ser utilizada para subir archivos maliciosos (por ejemplo, webshells) o lanzar más ataques contra el servidor subyacente y sus visitantes.




## Mitigación Recomendada

La aplicación debe regenerar el identificador de sesión ante cualquier cambio en el nivel de privilegios, especialmente en la autenticación de usuarios. La implementación estándar en PHP es llamar a `session_regenerate_id(true);` inmediatamente después de validar las credenciales del usuario y antes de conceder acceso a la parte autenticada de la aplicación.

## Cronología de Divulgación

  * **Fecha de Descubrimiento:** 9 de junio de 2025

  * **Fecha de Notificación al Vendedor:** 10 de junio de 2025

  * **Fecha de Acuse de Recibo del Vendedor:** 16 de junio de 2025

  * **Fecha de Publicación del Parche:** 17 de junio de 2025

  * **Fecha de Divulgación Pública:** 26 de julio de 2025