Vamos a resolver la siguiente máquina.
Enumeration
Para poder explotar un ciclo de vida de un manejo de sesiones vulnerable, necesitamos mapear el ciclo de vida para nosotros mismos y redactar notas detalladas. Una vez que entendamos lo que realiza el ciclo de vida, podemos empezar a buscar debilidades.
- Navegamos al sitio web que nos dan.
Si abrimos las herramientas de desarrollador, podemos ver que de primeras no nos dan ninguna cookie/token, por lo que sabemos que las sesiones no autentificadas no están siento controladas. - Si le damos a Sign Up, vemos que hay dos maneras principales de hacerlo.
- Estudiante
- Profesor Esto nos indica que incluso sin métodos de fuerza bruta, podemos lanzar el ciclo de vida del manejo de sesiones creando una cuenta de estudiante.
- Vamos a crear una cuenta de estudiante.

- Hemos recibido una notificación de que se ha creado la cuenta. Vamos a iniciar sesión.
Esto nos da algo de información:
- Las cookies se usan para el manejo de sesión.
- La flag HTTPOnly esta configurada lo que significa que no deberíamos ser capaces de usar JavaScript para leer el valor de la cookie.
- El tiempo de expiración de la cookie se ve raro ya que el tiempo de creación y de expiración son el mismo.
- Con esta autentificación, tenemos acceso a más funcionalidades.

- Viendo el apartado de red podemos ver que el control de sesión está reforzado por la cookie que está siendo transmitida en cada petición.
Algo interesante en lo que fijarse, es que aunque la fecha de expiración haya sido alcanzada, el mismo header de cookie se usa para refrescar la cookie al mismo valor. Esto puede apuntar a una cookie persistente. Veamos lo que pasa cuando eliminamos la cookie. - Eliminamos la cookie en storage y hacemos la petición de modules otra vez.
Ahora ya no hay cookie en la petición. - Parece que sigue cargando, pero ahora no podemos ver el número de alumnos matriculados en cada uno de los módulos.
Esto requiere más investigación ya que tenemos que ver qué acciones podemos realizar con una cuenta sin autentificar. - Si presionamos el botón de log out podemos ver que nuestra sesión se borra completamente del lado del cliente.
Sin embargo debemos comprobar si también ha sido eliminada del lado del servidor. - Para hacerlo vamos a iniciar sesión y a sustituir la cookie actual por la cookie pasada.
Parece que la terminación de sesión funciona porque recibimos error 500. - Si vamos a local storage, vemos que hay cierta información siendo guardada.

- Cambiaremos el rol de Student a Lecturer.
Parece que ahora tenemos acceso a más opciones, sin embargo no hay más información relevante. - Cambiemos el valor del usuario de 2 a 1.
Nada cambia.
Deberemos volver más adelante pero todo esto nos dice que puede que las sesiones se estén manejando mediante tokens y no mediante cookies.
Echemos un vistazo al mapeo que hemos hecho:
| Fase del Ciclo | Observación |
|---|---|
| Session Creation | Se usa una combinación de cookie y token. |
| Session Creation | Se recibe un valor de sesión nuevo por cada inicio de sesión. |
| Session Creation | El valor de la sesión parece ser suficientemente random. |
| Session Tracking | Las acciones no autentificadas no se trackean vía sesión. |
| Session Tracking | La cookie se manda en cada petición. |
| Session Tracking | Se pueden hacer peticiones sin cookie. |
| Session Tracking | Los valores del token inicial dictan la información visible. |
| Session Expiry | Hay una descordinación entre lo tiempos de expiración del lado del cliente y del servidor. |
| Session Expiry | El tiempo de expiración es muy largo. |
| Session Termination | Los usuarios pueden terminar su sesión forzosamente. |
| Session Termination | Las sesiones se terminan del lado del servidor pero reusar una sesión antigua conlleva a in error interno del servidor. |
Dada toda esta información reportaríamos las siguientes vulnerabilidades en un reporte de seguridad:
- Tiempo de sesión excesivo.
Deberíamos además investigar:
- Controles de acceso en todos los endpoints API.
- Logs de aplicaciones web por la responsabilidad de acciones.
Explotación
- Desde la sesión como "Lecturer" vamos al apartado de estudiantes y miramos el que se llama "X". Podríamos filtrar por nombre con
Contains: X.
CAUTION
Esta flag está buggeada.
- Si cambiamos el rol a "admin" vemos que sólo hay registrado 1.

- Si vamos al apartado de tests podemos ver la mayor nota de Student1.

- Además como en el otro examen no hay intentos también sabemos que los intentos totales fueron 4.
- Miramos las respuestas del examen.

