Am 07.06.2020 gelang der Nachweis, dass die umgesetzten Maßnahmen nicht ausreichnd sind. Mehr dazu hier.
Die vollständige Veröffentlichung aller Details und Proof-of-Concepts ist am 22.03.2020 erfolgt.
Seit dem 31.03.2020 existiert eine offizielle Stellungnahme der Firma Untis. Details dazu hier.
Bei WebUntis handelt es sich um ein elektronisches Klassenbuch, das die Aufgaben eines herkömmlichen Klassenbuchs auf Papierbasis übernimmt und durch zusätzliche Funktionen erweitert. Die Webanwendung wird in den meisten Fällen direkt durch den Hersteller Untis GmbH auf Servern in Österreich betrieben. Nur in Ausnahmefällen betreiben Schulen oder regionale Dienstleister die Installationen selbst. Zusätzlich werden auch Apps für Mobilgeräte angeboten, die die Daten über eine Schnittstelle mit dem Server austauschen. Neben Hausaufgaben, Klassenbucheinträgen und Abwesenheiten können auch Noten erfasst oder private Nachrichten zwischen Lehrern und Schülern ausgetauscht werden.
Es entsteht somit eine Sammlung sensibler Informationen, aus denen sich auch Erkrankungen oder Verhaltensauffälligkeiten ableiten lassen. Gelangen diese Informationen in die falschen Hände, so kann dies für die Schüler auch im weiteren Leben bei Bewerbungsverfahren Nachteile bedeuten. Auch bei Manipulationen von Klassenbucheinträgen oder Noten besteht die Gefahr fehlerhafter Zeugnisse und im schlimmsten Fall einer verwehrten Versetzung. Die dort gespeicherten Daten sollten daher bestmöglich vor dem Zugriff und Manipulation durch Dritte geschützt werden. Die Integrität und Vertraulichkeit der Daten muss gewährleistet sein. Der Erfüllung Anforderungen sieht man sich beim Hersteller und Anbieter Untis verpflichtet:
Untis ist zu 100 % DSGVO konform und steht damit für absolute Sicherheit der sensiblen, personenbezogenen Daten.
https://www.untis.at/warum-untis/ueber-das-produkt/datenschutz-und-sicherheit
Dennoch konnte ich mehrere Schwachstellen in WebUntis nachweisen, die es einem Angreifer ermöglichen, beliebige Daten auszulesen oder zu verändern.
Vorbedingung
Alle Versuche wurden an einer Demoinstallation für das elektronische Klassenbuch [2] durchgeführt. Dabei wurden keine Daten aus Produktivinstallation ausgelesen oder verändert.
Schwachstellen
Nachfolgend werden die identifizierten Schwachstellen grundlegend beschrieben. Zudem werden in Proof-of-Concepts neben der eigentlichen Schwachstelle auch Möglichkeiten zur Ausnutzung gezeigt. Alle Schwachstellen sind mittlerweile behoben.
Cross-Site-Request-Forgery
Über eine Cross-Site-Request-Forgery Schwachstelle war es möglich, private Nachrichten innerhalb einer Schule im Namen eines angemeldeten Benutzers abzuschicken. Vorraussetzung hierfür ist, dass der Benutzer eine entsprechend präparierte Webseite aufruft (z.B. einen Link in einer E-Mail).
Dadurch lassen sich vertrauenswürdig wirkende Nachrichten innerhalb eines geschlossenen Systems (der Schule) verschicken. Die Lücke könnte somit genutzt werden, um die Kommunikation zwischen Lehrern zu manipulieren und Lehrer dadurch bestimmte Aktionen durchführen lassen.
Diese Schwachstelle war zum Zeitpunkt der Veröffentlichung behoben.
Cross-Site-Scripting
Durch Ausnutzung einer Cross-Site-Scripting Lücke in verschiedenen Komponenten in WebUntis (darunter die Nachrichtenfunktion) konnte ein Angreifer JavaScript in die Anwendung einschleusen und im Kontext anderer Benutzer ausführen lassen.
Dadurch ist eine Manipulation oder das Auslesen beliebiger Informationen möglich, auf die der Zielbenutzer Zugriff hat. Es existieren Proof-of-Concepts zur Veränderung von Noten und der Löschung von Klassenbucheinträgen. Darüber hinaus bestehen Nachweise über die Möglichkeit des Diebstahls von Authentifizierungstokens für die interne Dateiablage und den Appzugriff für den jeweiligen Benutzer. Insbesondere durch den Diebstahl der Authentifizierungstokens für den Appzugriff eröffnet sich für einen Angreifer die Möglichkeit eine grafische Oberfläche für den Abruf und die Manipulation der Daten zu verwenden.
Zum Zeitpunkt der Veröffentlichung war nur ein Teil dieser Schwachstellen behoben. Mittlerweile wurden alle gemeldeten Schwachstellen behoben.
Auswirkungen
Durch die Kombination der beiden Schwachstellen verschärft sich die Problematik. So ist es möglich, die Cross-Site-Request-Forgery Schwachstelle zu missbrauchen, um JavaScript in die Anwendung einzuschleusen. Dadurch kann der Angreifer selbst unauthentifiziert agieren. Er muss über keinen gültigen Benutzer verfügen oder kann seine wahre Idendität verschleiern. Selbst bei einer Entdeckung des Angriffs würde der wahre Angreifer verborgen bleiben. Der Angreifer muss einen authentifizierten Benutzer lediglich auf eine entsprechend präparierte Webseite leiten. Dies kann beispielsweise über einen Link in einer E-Mail erfolgen.
Szenario
Neben Schülern oder Eltern, die die persönlichen Noten oder Klassenbucheinträge manipulieren wollen, sind die in WebUntis gespeicherten Daten auch für Außenstehende interessant. Die eingangs erwähnten, personenbezogenen Informationen können langfristig persönliche Konsequenzen für die Betroffen haben. Entsprechend hoch ist der Schutzbedarf.
In diesem Szenario gehe ich von einem größer Angelegten Angriff aus, dessen Ziel der Diebstahl möglichst vieler Informationen von unterschiedlichen Schulen ist. Begünstigt wird der Angriff durch die Tatsache, dass viele Schulen öffentliche Listen mit Kontaktadressen ihrer Lehrer pflegen und WebUntis oft prominent auf der Startseite der jeweiligen Schulwebseite verlinkt ist.
Dadurch könnte ein Angreifer eine Kampagne starten, bei der er einen Link an alle Lehrer zu einer präparierten Webseite verschickt. Diese Webseite würde dann über einen Cross-Site-Request-Forgery Angriff JavaScript in der jeweiligen WebUntis Installation einschleusen. Im Anschluss würden Authentifizierungstokens an den Angreifer übertragen werden, der dann automatisiert einen möglichst großen Datenbestand abruft und kopiert.
Kommunikation & Behebung
Die Schwachstellen wurden am 11.12.2019 an den Hersteller gemeldet. Trotz mehrerer Nachfragen blieb die Anfrage bis zum 02.01.2020 unbeantwortet. Erst die Meldung einer weiteren, bisher unveröffentlichten, Sicherheitslücke in der Desktopanwendung Untis gelangte nach Angaben des Herstellers durch den Spam Filter.
Man teilte mir mit, dass man die Cross-Site-Scripting (XSS) Lücke zwischenzeitlich bereits selbst entdeckt habe und die Cross-Site-Request-Forgery (CSRF) Lücke evaluiere. Die Behebung der CSRF Schwachstelle erfolgte zeitnah.
Zwischenzeitlich versuchte der Hersteller die Veröffentlichung gegen die Zahlung eines “Bug-Bountys” zu verhindern. Dieses Angebot lehnte ich ab. Hierbei gilt: Eine Annahme des Angebots hätte nachträglich als Erpressung gewertet werden können. Die Annahme von Geld sollte grundsätzlich erst am Ende eines erfolgreichen Reports stehen und ausschließlich mit Bedingungen verbunden sein, die bereits im Vorfeld in Bezug auf ein Bug Bounty Programm öffentlich dokumentiert sind.
Vor dem Hintergrund der DSGVO bat ich den Hersteller um eine Stellungnahme zum Thema Meldepflichten. Hierbei wies ich auch auf möglicherweise besonders schützenswerte, personenbezogeneDaten gemäß Art. 34 DSGVO [3] hin. Nach Auffassung des Datenschutzbeauftragten liegen hier keine Meldepflichten vor und die Daten fallen nicht unter Art. 34 DSGVO.
Zunächst versuchte man die XSS Schwachstelle damit zu relativieren, dass ein Angreifer authentifiziert sein müsse und die Nachrichtenfunktion nur selten genutzt werde. Darüber hinaus gebe es keine weitere XSS Lücke. Hierzu sei folgendes erwähnt: In Kombination mit der CSRF Schwachstelle muss der Angreifer nicht authentifiziert sein. Zuden kann die Funktion im Gegensatz zu den meisten anderen Funktionen auch von der am niedrigsten privilegierten Bentzergruppe, den Schülern und Eltern, genutzt werden. Meine Nachfrage, ob die Nachrichtenfunktion deaktiviert werden könne blieb unbeantwortet. Daher kann ich nicht beurteilen, ob es Schulen gibt, die von dem konkreten Szenario nicht betroffen sind. Allgemein gilt aber, dass die seltene Nutzung nicht vor dem Angriff schützt. Ein angemeldeter Benutzer wird auf der Startseite deutlich auf eine vorliegende Nachricht hingewiesen. Daher ist es wahrscheinlich, dass er die Nachricht abrufen und damit das JavaScript ausführen wird.
Am 06.02.2020 konnte ich eine weitere XSS Schwachstelle in der Anhangsfunktion der privaten Nachrichten nachweisen. Dabei lieferte ich auch einen Proof-of-Concept, mit dem sich alle nötigen Authentifzierungstokens entwenden ließen, um über die App zuzugreifen oder die Zwei-Faktor Authentifizierung zu umgehen.
Zusätzlich meldete ich am 21.02.2020 weitere XSS Schwachstellen. Diese bestanden in einem Teil von WebUntis, der nach Aussage von Untis bisher nicht offiziell veröffentlicht war. Deshalb seien diese Schwachstellen nicht relevant. Derzeit wird wohl an einer neuen UI gearbeitet. Dazu scheinen auch neue API Endpunkte für bereits existierende Funktionen erstellt zu werden. Da nicht auszuschließen ist, dass eingeschleustes JavaScript auch in der bisherigen UI ausgeführt wird, ist diese Argumentation falsch. Technisch war der Zugriff bereits möglich und damit auch die Ausnutzung. Man teilte mir zudem mit, dass man an einem “zentralen XSS-Schutz arbeite”.
Am 03.03.2020 erhielt ich die Information, dass nun auch die XSS Schwachstellen behoben seien. Dabei wurde nicht auf eine Kodierung der Nutzereingaben gesetzt. Stattdessen wurde ein Filter implementiert, der im Vorfeld mehrere Wochen lang auf False-Positives getestet wurde. Ziel ist es, JavaScript bei der Übertragung durch den Nutzer zu erkennen und abzulehnen. Die Wirksamkeit derartiger Filter ist umstritten und kann in bestimmten Fällen nicht ausreichend sein. Auf meine Nachfrage dazu wurde ausweichend reagiert. Mir seien nicht alle umgesetzten Maßnahmen bekannt. Daher halte man es für problematisch, wenn ich die Qualität der Umsetzung bewerte.
Fristverlängerung
Mit dieser E-Mail bat mich der Hersteller auch um eine Verlängerung der Veröffentlichungsfrist. Ich hatte im Rahmen eines Responsible-Disclosure Verfahrens eine Frist von 90 Tagen eingeräumt. Zwar habe man die selbst betrieben Server bereits mit dem Patch ausgestattet, auf Installationen bei Dienstleistern habe man aber keinen Einfluss. Zudem habe man meine E-Mails erst am 02.01.2020 aufgrund des eigenen Spam Filters erhalten. Dabei handele es sich nicht um eigenes Verschulden.
Eine Verlängerung würde einem Responsible-Disclosure Verfahren entgegen stehen und dem Zweck widersprechen, dass Betroffene und Verantwortliche die Problematik erkennen und handeln können.
In Absprache mit dem CCC Aachen entschied ich mich Kontakt zu Linus Neumann aufzunehmen. Daraus entstand das aktuelle Angebot an den Hersteller. Zum Verständnis der Schwachstellen ist es nicht erforderlich, dass die existierenden Proof-of-Concepts veröffentlicht werden. Daher hatte ich mich entschlossen weitere Details erst am 04. April 2020 im Rahmen des SecCamp Cologne 2020 zu veröffentlichen. Bedingung war jedoch, dass die Sicherheitspatches in den Release Notes [4][5] klar gekennzeichnet werden. Zudem durfte sich der bisher angewendete Patch nicht als unwirksam herausstellen. Die zusätzliche Zeit sollte sicherstellen, dass auch Installationen das Update erhalten können, die nicht durch die Untis GmbH betrieben werden.
Unbehobene Schwachstellen
Zum Zeitpunkt der Veröffentlichung existierte eine gemeldete, aber nicht behobene Schwachstelle. Betroffen waren die ebenfalls gemeldeten Probleme in der Anhangsfunktion privater Nachrichten. Bei Untis zeigte man sich darüber überrascht. Man habe die Funktion überprüft und sei dort zu dem Schluss gekommen, dass es dort kein XSS Problem gebe. Zudem warf man mir vor, damit gegen das Responsible Disclosure Verfahren zu verstoßen. Offenkundig hatte man die ergänzend gemeldeten Schwachstellen übersehen oder konnte sie nicht nachvollziehen. Daher wurden mir zunächst Vorwürfe entgegengebracht, ich hätte die Schwachstelle nicht gemeldet. In der Nacht vom 11.03.2020 auf den 12.03.2020 wurde diese Schwachstelle mit der Version 2020.9.10 ebenfalls behoben.
Die Firstverlängerung wurde damit obsolet. Ich entschied mich dennoch dafür, jegliche Proof-of-Concepts bis zum 22.03.2020 unveröffentlicht zu lassen.
Drohungen
Die Untis GmbH wollte die Veröffentlichung über die Schwachstelle in der bisher unveröffentlichten UI weiterhin verhindern. Man drohte mir damit, dass man nun weitere Schritte prüfen werde, da die Teilveröffentlichung zu diesem Zeitpunkt bereits erfolgt war.
Zudem könne die Veröffentlichung unveröffentlichten Materials einen “Copyright-Verstoß (sic!) darstellen”. In einer E-Mail an die Untis GmbH legte ich am 11.03.2020 umfassend dar, warum ich in diesem Punkt nicht zustimmte. Die vollständige Nachricht habe ich hier veröffentlicht.
Hätte man mich darum gebeten, keine Screencasts der unveröffentlichten UI zu zeigen, hätte ich diesem vermutlich sogar zugestimmt. Von Drohungen möchte ich mich jedoch nicht einschüchtern lassen – erst recht nicht, wenn im gesamten Verfahren mehr geschlampt und gebastelt als konstruktiv zusammengearbeitet wird. Die Verantwortlichen sollten an dieser Stelle nicht vergessen, dass sie eine kostenlose Schwachstellenanalyse erhalten haben. Ich habe damit die Arbeit einer Firma gemacht, die täglich mit sensiblen Daten umgeht. Sollten bei mir anwaltliche Schreiben eingehen, so werde ich diesen Artikel entsprechend ergänzen.
Abschließende Bewertung
Überlicherweise finalisiere ich derartige Berichte mit einer abschließenden Bewertung. An dieser Stelle würde diese aber wohl wenig positiv, differenziert und sachlich ausfallen. Daher verweise ich an dieser Stelle lediglich auf meine Stellungnahme an Untis. Daraus geht auch meine persönliche Meinung zu dem Gesamtverfahren in ausreichendem Maße hervor.
Was sollten Schulen jetzt beachten?
Schulen sollten zunächst prüfen, ob ihre Installation bereits auf die Version 2020.9.10 aktualisiert wurde. Für die Installationen, die direkt durch die Firma Untis und das KRZN betrieben werden, ist dies meines Wissens der Fall. Bei Schulen, die den Betrieb an andere Dienstleister augelagert haben, sind die Updates bisher unter Umständen nicht installiert. So wurde die Installation der Stadt Hamburg noch einige Wochen mit einer veralteten Version betrieben.
Da nun alle Details zu den Schwachstellen veröffentlicht sind, besteht eine erhöhte Gefahr eines Angriffs!
Speicherung von Noten
Die Speicherung von Noten in elektronischen Klassenbüchern ist in Deutschland nicht einheitlich geregelt. So weist die Landesbeauftragte für den Datenschutz Niedersachsen [6] auf folgendes hin:
Es ist darauf zu achten, dass dabei nur die Daten erhoben werden, die auch für das Klassenbuch in Papierform erforderlich sind. Da dort keine Noten eingetragen werden dürfen, ist dies auch im elektronischen Klassenbuch nicht zulässig.
Die Landesbeauftragte für den Datenschutz Niedersachsen. Hinweise zur Einführung eines elektronischen Klassenbuchs. 03.09.2018
In Schleswig-Holstein gilt dagegen [7]:
(3) In den digitalen Klassen- und Notizbüchern dürfen unter Nutzung einer Zwei-Faktor-Authentisierung folgende personenbezogene Daten der Schülerinnen und Schüler der jeweiligen Klasse oder Lerngruppe verarbeitet werden: […]
Landesverordnung über die Verarbeitung personenbezogener Daten an öffentlichen Schulen (Schul-Datenschutzverordnung – SchulDSVO). 18. Juni 2018. § 13 Digitale Klassen- und Notizbücher
5. persönliche Zwischenbewertungen von Unterrichtsbeiträgen und des allgemeinen Lernverhaltens sowie Zwischennoten für schriftliche Leistungsnachweise
Auch in NRW ist die Speicherung zulässig [8]:
Noten und Verhaltensdaten von Schülerinnen und Schülern sind personenbezogene Daten und unterliegen besonderem Schutz. Die Erhebung und Speicherung dieser Daten ist im Rahmen des Bildungsauftrages der Schule durch das Schulgesetz möglich.
Datenschutz an Schulen in NRW. Handreichung für Schulleitungen. p. 14. 2015
Aufgrund der Unterschiede der einzelnen Bundesländer ist unbekannt, für welche Bundesländer tatsächlich die Manipulation von Noten möglich ist. Jedoch gilt weiterhin, dass durch Ausnutzung der Schwachstellen Zugriff auf personenbezogene Daten erlangt werden kann. Die Manipulation von Noten ist dabei nur ein Aspekt.
Einige Schulen stellen Scans der mit Untis geschlossenen Auftragsverarbeitungsverträge auf ihrer Webseite zur Verfügung [9]. Dabei handelt es sich allerdings eher um einen Blankovertrag, der die maximal mögliche Datenmenge umfasst. Welche Daten die jeweilige Schule tatsächlich erhebt, geht daraus nicht hervor. Betroffene müssten in diesem Fall individuell eine Auskunftsanfrage an ihre Schule stellen.
Auswirkungen
Nach meinen Informationen kann zum heutigen Zeitpunkt nicht zweifelsfrei ausgeschlossen werden, dass es in der Vergangenheit zu erfolgreichen Angriffen gekommen ist. Daraus resultiert die Gefahr, dass die Einträge in elektronischen Klassenbüchern der letzten Jahre anfechtbar werden könnten. Zwar beteuert der Hersteller in den Release Notes
Eine Auswertung der Log Files ergab, dass die Sicherheitslücke nicht missbraucht wurde.
WebUntis Release Notes. 11.03.2020
Bei meinen Nachfragen dazu im Vorfeld wurde jedoch mit Verweis auf die Datenschutzerklärung eine Speicherdauer von Serverlogs von 6 Monaten genannt. Diese Zeitspanne reicht unter Umständen für eine Zweifelsfreie Nachvollziehbarkeit nicht aus. Wie lange die Sicherheitslücken bereits bestanden, ist mir nicht bekannt.
Sollte es in der Vergangenheit in Schulen zu Ungereimtheiten gekommen sein, sollte versucht werden Manipulationen über Sicherheitskopien nachzuvollziehen.
Vorherige Betrachtungen
In der Vergangenheit gab es bereits Betrachtungen und Nachfragen im Hinblick auf die Sicherheit von WebUntis.
Mike Kuketz: Fehlendes Rollenkonzept
In seinem Blog berichtet Mike Kuketz über die Analyse der Untis Mobile App [10]. Dabei handelt es sich um die App, für die sich durch Ausnutzung der XSS Schwachstelle Authentifizierungstoken entwenden lassen.
Er kritisierte, dass Untis Mobile auch Benutzern, die keine Berechtigung zur Einsicht von Informationen über die App hatten, dennoch eine Vielzahl von Informationen über die Schnittstellen zur Verfügung stellt. Er vermutete ein fehlendes Rollen bzw. Rechtesystem.
Zudem kritisierte er, dass sich die Datenschutzerklärung nur auf die Webseite untis.at beziehe. Auch ich habe die Datenschutzerklärung für WebUntis zunächst nicht finden können. Nach einer Nachfrage hierzu wurde ich unter [11] fündig. Was sich zunächst wie eine Werbeseite liest, enthält beim Runterscrollen auch die Datenschutzerklärung für WebUntis bzw. Untis Mobile.
Alexander Röttcher: Bachelorarbeit
Im Rahmen seiner Bachelorarbeit “Entwurf einer sicheren Client-Server-Architektur für ein Notenverwaltungssystem” [12] aus dem Jahr 2015 befragte Alexander Röttcher auch die Untis GmbH (damals Gruber&Petters GmbH) zu verschiedenen Sicherheitsaspekten. Bei Nachfragen zum Schutz von Session Tokens (nachfolgend SID) erhielt er folgende Antwort:
Die SID ist im wesentlichen durch SSL geschützt und könnte nur durch Man-in-the-middle oder CSRF herausgefunden werden. Wir versuchen unsere Applikation gegen CSRF gut zu schützen.
Alexander Röttcher. Entwurf einer sicheren Client-Server-Architektur für ein Notenverwaltungssystem, p. 69, Leibniz Universität Hannover, Institut für theoretische Informatik, 2015
Fachlich ist die Aussage nur teilweise korrekt, zeigt aber, dass man sich den Gefahren eines CSRF Angriffs bewusst war. Bei einem CSRF Angriff gelangt der Angreifer nicht in den Besitz des Session Tokens. Stattdessen nutzt er die fehlende Verifikation der Zielanwendung, ob die Anfrage von einer Vertrauenswürdingen Quelle gestellt wurde, um eigene Informationen an den Server zu senden. Den Token erhält der Angreifer dabei nicht. Allerdings wird der Token als Cookie automatisch durch den Browser an die ursprüngliche Seite übertragen. Dadurch kann der Angreifer authentifizierte Aktionen an der Webseite durchführen und Daten verändern. Dabei gilt jedoch, dass ein Angreifer in den meisten Fällen keine Einsicht in die zurückgelieferten Daten erhält.
Einzelnachweise
[1] https://www.untis.at/produkte/webuntis-das-grundpaket/klassenbuch
[2] https://demo.webuntis.com/WebUntis/?school=demo_kb
[3] https://dsgvo-gesetz.de/art-34-dsgvo/
[4] https://help.untis.at/hc/de/articles/360008456699-WebUntis-Release-Notes
[5] https://help.untis.at/hc/en-150/articles/360008456699
[6] https://www.lfd.niedersachsen.de/download/115587/Hinweise_zur_Einfuehrung_eines_elektronischen_Klassenbuchs_Stand_03.09.2018_.pdf
[7] http://www.gesetze-rechtsprechung.sh.juris.de/jportal/portal/t/iho/page/bsshoprod.psml/action/portlets.jw.MainAction?p1=g&eventSubmit_doNavigate=searchInSubtreeTOC&showdoccase=1&doc.hl=0&doc.id=jlr-SchulDSVSH2018pP13&doc.part=S&toc.poskey=#focuspoint
[8] https://www.medienberatung.schulministerium.nrw.de/Medienberatung-NRW/Publikationen/Broschuere_Datenschutz_Schulen_NRW_Final.pdf_download_web.pdf
[9] https://ebgs.de/home/wp-content/uploads/2019/07/AVV-TOM-UNTIS-WebUntis.pdf
[10] https://www.kuketz-blog.de/untis-mobile-fehlendes-rollenkonzept-und-datenschutzerklaerung/
[11] https://www.untis.at/warum-untis/ueber-das-produkt/datenschutz-und-sicherheit
[12] https://www.thi.uni-hannover.de/fileadmin/thi/abschlussarbeiten/roettcher-ba.pdf
Header Photo by Feliphe Schiarolli on Unsplash