Support portal abuse (osTicket)

Los sistemas de tickets de soporte como osTicket (PHP + MySQL, muy extendido en empresas, universidades y administraciones) rara vez son vulnerables por un CVE, pero su funcionalidad legítima basta para dar un pie dentro. Dos abusos destacan: al abrir un ticket, el portal asigna una dirección de correo interna del dominio que sirve para registrarse en otros servicios de la empresa; y el panel de agentes, si reutilizamos credenciales filtradas, deja leer conversaciones donde el soporte manda contraseñas de restablecimiento en claro. No es un fallo de código, es diseño mal usado.

Mecanismo

Primero se identifica la instancia: la cookie OSTSESSID, el pie "powered by osTicket" o un "Support Ticket System" delatan la aplicación aunque Nmap solo muestre Apache o IIS. Al abrir un ticket en /open.php, el sistema asigna un número y una dirección de correo interna del tipo:

940288@<domain>

Si el helpdesk correlaciona números de ticket con correo, cualquier mensaje enviado a esa dirección aparece en el ticket. Con esa dirección "de la empresa" podemos registrarnos en portales externos (GitLab, wikis, chats) que exigen un correo corporativo y recibir el correo de verificación en el propio ticket.

El segundo abuso es contra el panel de agentes (/scp/login.php). Con credenciales filtradas por OSINT (por ejemplo, un volcado de Dehashed), se prueban usuario y contraseña; conviene probar también el correo como identificador de acceso, no solo el nombre de usuario:

usuario: kevin           -> falla
correo:  kevin@<domain>  -> acceso concedido

Dentro, los tickets cerrados suelen guardar oro: un agente que restablece la VPN de un empleado y le envía la contraseña estándar de nuevos empleados por el portal. Esa contraseña se reutiliza contra la VPN o se lanza en una pulverización contra otros usuarios.

Requisitos

Acceso al portal de soporte (a menudo expuesto externamente) y, para el panel de agentes, credenciales previas (filtraciones, OSINT, reutilización). El primer abuso no necesita credenciales: basta con poder abrir un ticket. El valor depende de si la organización reutiliza contraseñas y de si el portal está accesible desde fuera.

Cómo detectarlo. Delatan el abuso el alta de tickets con datos de contacto extraños seguida del uso de la dirección asignada para registrarse en otros servicios, los inicios de sesión en el panel de agentes desde IP externas o cuentas inactivas, y la lectura masiva de tickets cerrados. En los portales externos, un registro verificado con un correo NNN@dominio del helpdesk es una pista clara.

Defensa. Limitar qué aplicaciones se exponen a Internet, exigir MFA en todos los portales, formar a los empleados para que no usen el correo corporativo en servicios de terceros, aplicar una política de contraseñas robusta en AD y en las aplicaciones, y forzar el cambio de contraseña tras el primer inicio de sesión. Encaja con la reutilización de credenciales, la pulverización de contraseñas, la enumeración de usuarios por correo y la enumeración de usuarios.