Noch am Tag der Veröffentlichung wurde die hier genannte Schwachstelle geschlossen. Über die Details liegen derzeit keine Informationen vor.

Ende März diesen Jahres habe ich mehrere Schwachstellen in der Stundenplan- und Klassenbuchsoftware WebUntis in einem Responsible Disclosure Verfahren offengelegt. Neben einer CSRF Schwachstelle war es auch an mehreren Stellen möglich, JavaScript in die Webapplikation einzuschleusen. Gezeigt wurden mehrere Proof-of-Concepts, mit denen sich große Teile der Daten auslesen oder manipulieren ließen. Zudem wurde ein Proof-of-Concept für den Diebstahl des privaten API Tokens eines Benutzers vorgelegt, mit dem der gesamte Account übernommen werden kann.

Im damaligen Reporting hatte man meine Nachrichten zunächst im Spam ignoriert und anschließend versucht eine Veröffentlichung zu verhindern. In umfassenden E-Mails und Screencasts versuchte ich auf immer wieder neue Probleme hinzuweisen und zu verhindern, dass zum Schutz eine technisch ungeeignete Lösung eingesetzt wird. Häufig erhielt ich auf Rückfragen keine Antwort oder syntaktisch und semantisch inkorrekte Aussagen. Für mich ein enormer und selbstverständlich unvergüteter Zeitaufwand, den ich so bisher in keinem meiner Disclosure Verfahren hatte.

Für mich habe ich am Ende der 90-tägigen Veröffentlichungsfrist festgestellt, dass ich viel zu viel meiner Zeit in diese Bugs gesteckt hatte. Man hatte mir bereits im Januar zugesichert, an einem öffentlich dokumentierten Prozess für ein Responsible Disclosure Verfahren zu arbeiten. Es sollte wenige Wochen später veröffentlicht werden, passiert ist bis heute nichts. Aufgrund meiner Erfahrungen in dem letzten Verfahren, habe mich nun erstmalig für ein Full-Disclosure entschieden. Die gezeigte Schwachstelle ist nicht neu und resultiert lediglich auf einer unzureichenden Behebung der bereits durch mich gemeldeten Schwachstelle in der Nachrichtenfunktion von WebUntis. Daher erfolgt die Meldung an die Untis GmbH zeitgleich mit der Veröffentlichung des Bugs.

Was war passiert?

Über eine XSS Schwachstelle in der internen Nachrichtenfunktion von WebUntis konnte JavaScript in die WebApplikation eingeschleust werden. Schickt nun ein Schüler eine kompromittierte Nachricht an einen Lehrer, so kann er JavaScript im Kontext des Lehrers ausführen und alle Daten einsehen oder verändern, auf die der Lehrer Zugriff hat. Da dies erhebliche Auswirkungen für die Betroffenen haben kann, sind derartige Schwachstellen unbedingt zu verhindern.

Zudem fanden sich weitere Schwachstellen, über die sich JavaScript einschleusen ließ. Untis versuchte das Problem mit einem zentralen Filter zu beheben. Dieser sollte offenkundig Tags und Attribute blockieren, die zur Ausführung von JavaScript geeignet sind.

Meine Bedenken diesbezüglich unter Verweis auf OWASP und das XSS Filter Evasion Cheat Sheet trat man bedingt kompetent entgegen:

Ich möchte darauf aufmerksam machen, dass wir nicht nur einen “einfachen” Filter eingebaut haben, sondern auch andere Maßnahmen im Frontend und anderen Stellen eingeführt haben. Ich halte es für problematisch, eine Beurteilung unserer Maßnahmen vorzunehmen, ohne diese Maßnahmen im Detail zu kennen.

[…]

Die Erkennung läuft über bestimmte Heuristiken, die ich jetzt nicht detaillierter aufführen kann, die aber auf Standard-Libraries und Best-Practices basieren.

Untis

Nun, korrekt ist, dass ich die Maßnahmen bis heute nicht im Detail kenne. Jedoch sind sie für meinen aktuellen Proof-of-Concept wirkungslos, sodass ich mir nachfolgend dennoch eine Beurteilung erlaube.

PoC || GTFO

WebUntis implentiert offenbar eine Heuristik, bei der alle Zeichen, die einer öffnenden spitzen Klammer folgen bis zu einer öffnenden oder schließenden spitzen Klammer geprüft werden. So versuchte man ungefährliche HTML Tags und Attribute über eine Whitelist zu erlauben.

Ein klassisches <b>Dieser Text ist fett</b> wäre somit erlaubt. Auch ein <img src=”test.jpg”> ist zulässig. Unter Hinzunahme des onerror-Attributs würde der Filter nun jedoch mit einer bedrohlichen Warnung anschlagen: Your input contains code that does not match the security policy of WebUntis. This incident has been logged.

Damit scheint die Ausführung von JavaScript zunächst unmöglich. Jedoch hat man hier die Rechnung ohne die Webbrowser gemacht. Moderne Webbrowser versuchen kaputtes HTML zu reparieren. Damit gilt aber auch, dass ein derart einfacher Filter nicht ausreicht, da er den Umgang einzelner Browser mit einer scheinbar harmlosen Zeichenkette nicht beeinflussen kann.

Nehmen wir das Beispiel <img src=”test.jpg” onerror=”alert(‘XSS’)”, so stellen wir fest, dass der Browser die schließende Klammer selbstständig ergänzt. Der Filter erkennt hierbei jedoch keine Gefahr. Im konkreten Fall reicht dies nicht zur Ausnutzung aus, da das Einfügen von invalidem HTML in das DOM per JavaScript über das verwendete .innerHTML Attribut nicht möglich ist. Es wird somit nur eine leere und ungefährliche Nachricht angezeigt.

Wer auch immer sich an dieser Stelle nun wieder entspannt zurücklehnt und argumentiert: PoC || GTFO, der möge bitte weiterlesen.

PoC => !GTFO

Die meisten HTML Tags können geöffnet und geschlossen werden. Ein schließender HTML Tag beginnt mit einem vorangestellten Slash: </p>. In einem schließenden HTML Tag sind keine Attribute enthalten, die durch den Browser ausgewertet werden sollten. Daher stoppt der Filter mit der Prüfung, sobald er einen Slash sieht. Dieses Verhalten können wir uns zu Nutze machen:

<img src=”test.jpg” / onerror=”alert(‘XSS’)”>

Der Filter läuft nun bis zum Slash und beendet seine Prüfung. Die Eingabe wird zugelassen. Das nachfolgende Video zeigt einen erfolgreichen Angriff auf den Direktor Goethe durch den Lehrer Newton in den Browsern Firefox und Chrome über die Nachrichtenfunktion.

In einem zweiten Proof-of-Concept konnte auch nachgewiesen werden, dass weiterhin auch andere Formulare betroffen sind. An dieser Stelle reicht die Filterung bei der Eingabe von Noten ebenfalls nicht aus:

Corona

Anfangs wurde seitens Untis argumentiert, dass die Nachrichtenfunktion nur selten verwendet werde. Abgesehen davon, dass dies keinerlei Schutz vor einem Angriff bietet, wird es sich spätentens mit den durch Corona ausgelösten Schulschließungen verändert haben.

Lösungsvorschlag

Sämtliche Nutzereingaben müssen vor ihrer Ausgabe kodiert werden. Werden Sonderzeichen durch ihre HTML Entsprechungen ersetzt, wird der Angriff wirksam verhindert. Natürlich führt dies im konkreten Fall zu weiteren Problemen, denn Nutzer können ihre Nachrichten formatieren. Dabei werden HTML Tags verwendet, die bei einer Kodierung ebenfalls unwirksam würden. Anstatt einer Erweiterung des Filters muss eine zuverlässige und sichere Lösung wie der Einsatz von strikten und vordefinierten Shortcodes für die Formatierung in Betracht gezogen werden.

Auch eine Content-Security-Policy kann die Auswirkungen in Folge eines Injection Angriffs abfedern und sollte für Anwendungen mit sensiblen Daten zusätzlich implementiert werden.

Abschließende Bewertung

Es wird nun endlich Zeit, dass nicht nur die Schüler, sondern auch die Verantwortlichen der Firma Untis ihre Hausaufgaben machen. Eine nun seit fast sechs Monaten bekannte und weiterhin angreifbare Schwachstelle entspricht mit Sicherheit nicht den Anforderungen des Datenschutzes an sensible, personenbezogene Daten. Hier werden Daten vorsätzlich gefährdet und Bedrohungsszenarien ignoriert. Ich verstehe, dass in der aktuellen Zeit die Ressourcen in vielen Firmen knapp sind, doch sollte Sicherheit nicht hinten anstehen, zumal ich die Schwachstellen bereits im Dezember 2019 gemeldet habe. Eine zeitnahe und fachgerechte Behebung hätte das aktuelle Problem verhindert. Sehe ich mir diesen Vorfall an, so scheint es bisher keine unabhängigen Penetrationstests oder konstruktive Rücksprache mit Fachleuten aus den Bereichen Datenschutz oder Informations- und Anwendungssicherheit gegeben zu haben.

Ein derartiges Vorgehen ist verantwortungslos!