Das Webmail-Interface der Universität Bonn war/ist¹ unsicher. Schlechtestenfalls können Dritte² das Postfach “übernehmen” und alles tun, was man selbst dort tun kann: E-Mails lesen, löschen, versenden, Filter und Weiterleitungen einrichten. Dieser Beitrag soll erläutern, wo genau das Problem liegt und was dagegen getan werden kann. Denn wenn selbst das Studierendenparlament die Universität tadelt, dass ihre Kommunikation in der Angelegenheit unter aller Sau ist, dann ist das schon ein bemerkenswerter Vorgang.

Direkt zu Beginn: Mir liegen keine geheimen Informationen aus dem HRZ vor. Alles was in diesem Artikel steht weiß ich entweder aus dem Vice-Artikel, aus den Mitteilungen des HRZ, oder habe es geraten.

Liebling, ich habe fremde E-Mails gelesen

Für Aufmerksamkeit sorgte in der letzten Woche ein Artikel der Vice vom 18. Mai. Schwere Sicherheitslücke: 42.000 Postfächer der Uni Bonn ließen sich monatelang von außen übernehmen wird da getitelt. Der Artikel wird in sozialen Netzwerken geteilt, oft mit einem Hinweis à la “Huch! Warum weiß ich davon noch nichts?”. Die Reaktion der Universität Bonn: “Ach ja, das. Ist doch ein alter Hut!”.

Das @hrz_unibonn hat im April eine Sicherheitslücke geschlossen. Derzeit berichten viele Medien darüber. Infos: https://t.co/FV4T739vbj

— Universitaet Bonn (@UniBonn) May 18, 2017

Die Mitteilung der Universität veweist auf eine ältere Mitteilung des Hochschulrechenzentrums. Bevor wir uns der Frage zuwenden, wer wann was wusste und hätte wen informieren müssen, wollen wir zunächst verstehen, worum es hier überhaupt geht, um die möglichen Auswirkungen des “Problems” abschätzen zu können. Der nächste Teil wird jetzt ein kleines bisschen technisch, aber es sollte trotzdem noch verständlich sein.

Woher weiß der Webmailer, wer ich bin?

Die Wurzel allen Übels liegt darin, dass nicht einfach alle jede E-Mail auf den Mailservern der Universität lesen darf. Nutzerinnen und Nutzer erwarten verständlicherweise, dass nur sie ihre eigenen E-Mails angezeigt bekommen. Wenn ich E-Mails in meinem Postfach habe, die nicht an mich adressiert waren, dann ist das vielleicht noch nervig, aber wenn meine E-Mails in fremdem Postfächern auftauchen und dort gelesen werden, hört der Spaß auf.

Der Webmailer muss also wissen, wer ich bin, damit er mir die richtigen E-Mails heraussuchen und anzeigen kann. Indem ich mich mit Nutzernamen und Passwort anmelde, teile ich dem Webmailer mit, wer ich bin.

Durch die Anmeldung im Webmailer starte ich eine Session. Das hat weder mit Jam noch mit Gespenstern zu tun, sondern ist einfach der englische Begriff für eine Sitzung. Solange die Sitzung läuft / aktiv ist, merkt sich der Webmailer, wer ich bin, und ich muss ihm nicht ständig neu Nutzernamen und Passwort mitschicken. Wenn ich mich schließlich abmelde, vergisst der Webmailer die Session wieder. Das tut er in der Regel auch nach einer bestimmten Zeitspanne, eine Stunde oder so.

Leider sind Webserver etwas beschränkt. Ich muss sie bei jedem Klick den ich mache daran erinnern, in welcher Session ich mich befinde. Zum Glück hat die Session einen eindeutigen “Namen”: Die Session-ID. Nach der Anmeldung im Webmailer taucht sie in der Adresszeile auf:

Und alles, was man dann im Webmailer anklickt, führt zu einer Unterseite, die eben diese Session-ID in der Adresse hat.

Die internen Vorgänge in diesem Webmailer hat man sich dann in etwa folgendermaßen vorzustellen:

A: “Yo, da will irgendjemand die Seite https://mail.uni-bonn.de/Session/717825-O8yVqe5Hw1GHgX82Uxq4-aofjcqp/frameset.wssp haben!”

B: “Wat, vun d’r Session 717825-O8yVqe5Hw1GHgX82Uxq4-aofjcqp? Dat es doch *blätter* d’r Zemantek Sven! Däm sing Mails han ich he!”³

Oder so. Die Session-ID ist also mit meinem Account verknüpft. Wer die Session-ID kennt, kann sich als ich ausgeben. Nutzername oder Passwort werden hier nicht benötigt.

Angst bekommen? Dabei fangen wir gerade erst an.

Wer hat uns verraten? Referrer.⁴

Richtig lustig wird diese Session-ID-Sache, wenn man eine ganz bestimmte Funktion moderner Webbrowser kennt. Klickt man auf einen Link, ruft der Browser die verlinkte Seite ab, schickt aber die Adresse der aktuellen Seite mit, von der der Link stammt. Diese Ursprungsadresse heißt “Referrer”. Wozu man das braucht, weiß wohl niemand. Gut, ein Server kann so sehen, von wo aus auf seine Seiten verlinkt wird, aber mir fällt wirklich keine Funktionalität ein, die nichts mit Tracking zu tun hat und nicht ohne diese Referrer auskäme.

Nun senden Webbrowser die aber zumeist mit, und wir müssen damit klarkommen.

Wisst ihr noch, wie wir oben gesagt haben, dass diese Session-ID niemand außer mir kennen sollte, weil man sich damit gegenüber dem Webmailer als ich ausgeben kann?

Jetzt stellt euch mal vor, ich öffne im Webmailer eine E-Mail und klicke darin auf einen Link.

In diesem Fall zeigt der Link auf meinen eigenen Server, und der schreibt jeden Seitenaufruf in eine Logdatei. Etwa so:

So ein Link zeigt aber nicht zwangsläufig auf meinen eigenen Server. Die übertragenen Informationen sind aber die selben.

FUCK.

Und zwar vor allem, da ich bei fremden Servern nicht weiß, ob sie einer Person gehören, die nur darauf wartet, dass jemand aus dem Uni-Webmailer auf ihre Links klickt. Oder ob auf der Webseite so eine Trafficanalyse-Software läuft. Die zeigen die Referrer aus eingehenden Seitenabrufen nämlich auch gern an.

Nun wissen wir also, wie fremde Personen durch einen Klick auf den falschen Link in mein Postfach kommen.

Schlimmer kommt’s immer

Schaut euch mal diese Nachricht an, die eben in meinem Postfach gelandet ist⁵.

Kein Link, also keine Gefahr. Doch halt! Was ist das für ein mysteriöser Eintrag in meiner Webserver-Logdatei?

Stellt sich raus: Die E-Mail enthält ein eingebettetes Bild. Das wird beim Anzeigen der Nachricht aus dem Internet (sprich, von meinem Server) abgerufen. Und zusammen mit diesem Abruf schickt der Webbrowser – natürlich, warum auch nicht! – die aktuelle Seitenadresse als Referrer mit.

Himmelarsch!

Das bedeutet also: Selbst wer nie auf irgendwelche Links geklickt hat, ist nicht sicher. Das Öffnen einer Nachricht reicht.

Gegenmaßnahmen

Es gibt drei Möglichkeiten für den Webmail-Betreiber, das Problem zu beseitigen: Die Session-ID aus der Adresse entfernen, den Versand des Referrers mit der Session-ID verhindern, oder zusätzliche Merkmale mit der Session verknüpfen. Wie würde man das jeweils angehen?

1. Session-ID aus der Adresse entfernen

Kennt ihr diese Cookie-Warnungen auf Webseiten? “Alarm, Alarm, diese Webseite nutzt Cookies! Akzeptieren Sie hier!” Bestimmt schon einmal gesehen.

Ein Cookie ist ein kurzer Text, den der Webbrowser bei jedem Seitenabruf an den Webserver sendet. Hey, wisst ihr, was noch ein kurzer Text ist, der bei jedem Seitenabruf an den Webserver gesendet werden muss? Unsere Session-ID! Wenn wir die in ein Cookie packen, müssen wir sie nicht mehr in die Adresse schreiben. Der Referrer enthält dann auch keine Session-ID mehr. Problem gelöst.

2. Versand des Referrers mit der Session-ID verhindern

Wenn der Webmailer eine E-Mail anzeigt, macht er aus Internetadressen anklickbare Links. Dabei kann er natürlich den einfachen Weg gehen und aus https://example.com den Link auf https://example.com machen. Dann bekommt example.com den Referrer mit der Session-ID wenn geklickt wird, und das ist doof, das wollen wir nicht. Der Webmailer könnte aber auch einen Link auf  (z.B.) https://mail.uni-bonn.de/weiterleitung/https://example.com setzen, und https://mail.uni-bonn.de/weiterleitung/ könnte einfach jeden Aufruf an die Adresse weiterleiten, die dahinter kommt. Wenn man nun so einen Link im Webmailer anklickt, landet man zunächst auf der Weiterleitungsseite, die direkt auf https://example.com weiterleitet. Der Vorteil hierbei: example.com bekommt als Referrer lediglich den Wert https://mail.uni-bonn.de/weiterleitung/https://example.com. Keine Session-ID. Problem gelöst (bis auf dass man dieses Weiterleitungsding implementieren müsste, aber das gibt es sicherlich schon fertig irgendwo).

Facebook nutzt übrigens Vodoo-Magie um den Referer bei angeklickten Links zu setzen. Das könnt ihr zum Beispiel hier ausprobieren. Zum Vergleich.

Gegen das Problem mit den eingebetteten Bildern hilft das natürlich nicht. Da müsste man andere technische Maßnahmen einsetzen, die etwas aufwändiger sind.

3. Zusätzliche Merkmale mit der Session verknüpfen

Problematisch ist, dass “irgendjemand” diesen Referrer-Link aufrufen kann und dann Zugriff auf mein Webmail-Konto bekommt. Dabei sitzt der bestimmt ganz woanders und hat eine andere IP-Adresse als ich. Man könnte bei der Anmeldung die IP-Adresse in der Session “hinterlegen”. Sobald dann eine andere als die hinterlegte IP-Adresse die Session nutzen möchte, ruft der Webmailer “Halt Stopp” und verlangt eine erneute Anmeldung mit Nutzernamen und Passwort bevor es weitergeht. Vorteil: Die Session-ID muss nicht mehr so geheim gehalten werden. Nachteil: Hilft nichts gegen jemanden, der die gleiche IP-Adresse hat. Was das Ganze in der Regel auf im selben Haushalt lebende Personen einschränkt. Dennoch die am wenigsten sichere Variante.

Was hat die Uni nun gemacht?

Zunächst ja offenbar lange gar nichts. Dafür gibt es den Skipper-Kowalski-Rico-Private-lächeln-und-winken-Award. Glückwunsch!

Die Webmail-Anmeldemaske sieht inzwischen folgendermaßen aus. Interessant sind die beiden Checkboxen über dem Anmelden-Button.

Offenbar wurde ein Mischmasch aus 1 und 3 gewählt: Wenn die IP-Adresse sich ändert, wird man aus der Session gekickt. Außerdem wird ein Cookie gesetzt, ohne das man ebenfalls aus der Session gekickt wird. Die Session-ID bleibt aber weiterhin in der Adresse. Interessant sieht das Ganze aus, wenn man die Session-ID aus der Adresse entfernt:

Doch zurück zur Anmeldemaske. Setzt man bei der Anmeldung beide Haken, so besteht das Problem mit dem Referer weiterhin – jeder angeklickte Link, jedes angezeigte Bild öffnet potenziell das Postfach für Dritte. Man muss sich aber im Gegensatz zu vorher aktiv dafür entscheiden, die eingebauten Schutzmechanismen abzuschalten. Ob diese Checkboxen unbedingt nötig sind sei mal dahingestellt.

Kurzzusammenfassung

Wo Problem? Wer im Webmailer der Uni Bonn in einem unbestimmten Zeitraum bis zum 26. April 2017 eine E-Mail mit Bild geöffnet und/oder einen Link in einer E-Mail angeklickt hat, lief Gefahr, dass Dritte kostenlos und einfach⁶ Zugriff auf das E-Mail-Postfach hatten.

Was konnten diese bösen Dritten alles tun? E-Mails lesen, schreiben, löschen. Einstellungen ändern. Filter einrichten, ändern, löschen. Weiterleitungen einrichten, ändern, löschen. Letztlich alles, wofür man nicht nochmal das Passwort eingeben muss.

Was konnten sie nicht? Das Passwort ändern. Mit der Funktion “Sichere Email” signierte E-Mails verschicken⁷.

Sollte ich jetzt mein Passwort ändern? Nee. Mit Passwörtern hat die ganze Sache ausnahmsweise gar nichts zu tun.

Ich nutze nie den Webmailer, sondern Outlook/Thunderbird/Handyclient/…. Bin ich betroffen? Nein. Diese Clients schicken nämlich prinzipbedingt keine problematischen Referrer.

Kann man im Nachhinein feststellen, wer auf diese Weise “gehackt” wurde? Schwierig. Verdächtig wären erst einmal alle Sessions, bei denen sich mittendrin die IP-Adresse geändert hat. Um das zu prüfen müsste das Hochschulrechenzentrum aber noch Logdateien mit den Session-IDs und den abrufenden IP-Adressen aus dem zu untersuchenden Zeitraum aufbewahren. Das halte ich für nicht sehr wahrscheinlich. Außerdem kann so etwas auch bei normaler Nutzung passieren, zum Beispiel wenn das Handy vom Mobilnetz ins WLAN wechselt. Falls ihr in euren Einstellungen aber plötzlich eine Filterregel findet, die alle eingehenden E-Mails an totallylegit@nsa.gov weiterleitet, wäre das ein Indiz dafür, dass ihr nicht immer allein in eurem Postfach wart.

Kann ich jetzt behaupten, die E-Mail, in der ich meinen Prof beleidige, habe gar nicht ich im Suff geschickt, sondern ein fieser Hacker? Klar. Ob das allerdings glaubwürdiger ist als “Meine Katze ist über die Tastatur gerollt und das kam dabei raus” möchte ich an dieser Stelle nicht beurteilen.

Worst-Case-Annahme

Falls ihr mal im Uni-Bonn-Webmailer eine E-Mail geöffnet habt, kennt irgend jemand da draußen jetzt den Inhalt all eurer Uni-Mails. gg ez.

Das gilt nicht nur für Studierende: WiMis und Profen, Verwaltungsmenschen, der AStA und auch der SP-Wahlausschuss, alle sind betroffen.

Das klingt ja alles sehr schlimm. Warum hat man da nicht schneller etwas gegen unternommen? Warum hat mich noch niemand informiert?

Tja.

Ist das wirklich eine Sicherheitslücke im Webmailer der Uni Bonn?

Also, technisch betrachtet schickt dein Browser den Referrer an den Server… Dafür kann der Webmailer ja nichts.

Und nun?

1. Weinen
2. Das Studierendenparlament hat beim Rektorat nachgehakt⁸, wie das denn alles sein könne und warum man bitteschön nicht schon längst informiert worden sei. Auf die Reaktion der Universitätsverwaltung darf man gespannt sein.