Zum Hauptinhalt Zur Navigation Zur Suche

Sicherheitslücken: Datenflut am Meer

Eine digitale Kurkarte kann viel über Urlauber verraten, wenn sie nicht sicher ist. Wir haben ein solches Datenleck in einem Urlaubsort im Norden entdeckt.
/ Marco Wiorek
8 Kommentare Auf Google folgen (öffnet im neuen Fenster)
Datenschutz kennt keine Gezeiten. (Bild: Pixabay / Montage: Golem.de)
Datenschutz kennt keine Gezeiten. Bild: Pixabay / Montage: Golem.de

Sicherheitslücken gibt es überall und so kann es passieren, dass man im Urlaub aus reiner Neugier auf etwas stößt, das viele Menschen betrifft, die sich in einem entspannten Umfeld befinden und vielleicht nicht so genau hinsehen. In diesem Fall handelt es sich um ein Datenleck, das alle Urlaubsgäste eines vielbesuchten Ortes in Schleswig-Holstein betrifft und Daten preisgibt, die die Betroffenen vermutlich nicht erahnen können.

Aber erst einmal zur Vorgeschichte: Ich buche eine Ferienunterkunft in einer schönen Gemeinde an der Nordsee und bekomme zur Ankunft neben dem Informationsmaterial meine Gästekarte. Diese stellt den Nachweis der bezahlten Kurabgabe dar und sollte jederzeit mitgeführt werden. Denn bei Kontrollen durch das Ordnungsamt in der Deichregion gilt es nachzuweisen, dass man einen Beitrag zur lokalen Entwicklung der Tourismusinfrastruktur leistet.

Auf dieser Gästekarte befinden sich – neben den persönlichen Daten und einem Voucher für vergünstigte Küstenfahrten – zwei QR-Codes. Einer beinhaltet die Identifikationsnummer der Gästekarte und ein weiterer wird damit beworben, die Gästekarte als Web-App öffnen zu können.

Folgt man dem zweiten QR-Code, landet man auf einer Webseite mit einem 16-Byte-Hash als URL-Parameter, der die jeweilige Gästekarte darstellt, und sieht seinen Namen, Vornamen, Anreisedatum, Abreisedatum sowie die entrichtete Summe der Kurabgabe. Tatsächlich finden sich im Quelltext der Seite, auch wenn in der Oberfläche nicht angezeigt, zudem der Aufenthaltsort in Form der Betreiberidentifikationsnummer und der Unterkunftsname.

Dazu gibt es noch allerhand Informationen über die Sehenswürdigkeiten und am Fuß der Seite noch einen weiteren QR-Code, mit dem man die Seite aufrufen kann. Dieser QR-Code entstammt einem URL-Shortener eines Dienstleisters und wird auf jeder Seite eingebunden – somit auch auf jeder personalisierten Gästekartenseite.

Die eigentliche Ansicht der Gästekarte ist mit dem erwähnten 16-Byte-Hash vermeintlich sicher gegen Brute-Force-Attacken, da der Link nach Ablauf des Aufenthalts anscheinend deaktiviert beziehungsweise gelöscht wird. Kritisch zu betrachten ist hingegen die verkürzte URL, die auf jeder Seite angezeigt wird, da sie nur fünfstellig und alphanumerisch ist.

Der Link zum URL-Shortener wird dynamisch in die Webseite geladen und kann somit als isolierter Webrequest analysiert werden. Dabei zeigt sich, dass ein ungültiger Parameter, wie "*" eine Ausgabe produziert, die auf die darunterliegende URL-Shortener-Software "Jobping" schließen lässt.

Anzeige

Hacking & Security: Das umfassende Hacking-Handbuch mit über 1.000 Seiten Profiwissen. 3., aktualisierte Auflage des IT-Standardwerks (Gebundene Ausgabe)

Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.

Veraltetes Open Source

Mit etwas Recherche kommt man darauf, dass Jobping nicht mehr existiert. Kurz vor dem Ableben entschieden jedoch die Macher, dass man den Quelltext veröffentlichen möchte. Das haben sie: auf Codeplex, das nun ebenfalls nicht mehr existiert. Mithilfe der Waybackmachine ließe sich jedoch ein Abbild des Quelltextes finden(öffnet im neuen Fenster).

Was fängt man nun mit diesem Quelltext an? Es gilt festzustellen, ob die Zeichenfolge zufällig erstellt wird. Oder ob man die Möglichkeit hat, sie vorherzusagen, um relativ zu einem Startpunkt vorherige oder nachfolgende Einträge zu finden, anstatt die eventuell zufällig generierte Zeichenfolge zu bruteforcen.

Nahezu 1:1 nach Python übersetzt, sieht der Algorithmus wie folgt aus:

URL_CHARS = 'bcdfghjklmnpqrstvwxyzBCDFGHJKLMNPQRSTVWXYZ1234567890_-' reverse = {} for c in URL_CHARS:    reverse[c] = URL_CHARS.index(c) def encode(number):    result = ""    while number > 0:        remainder = int(number % len(URL_CHARS))        number = int(number / len(URL_CHARS))        result += URL_CHARS[remainder]    return result

Daraus wird ersichtlich, dass die Short-URL im Wesentlichen auf der fortlaufenden ID des Datenbankeintrags basiert, die der Funktion encode übergeben wird und, wenn sie fünfstellig bleiben soll, regelmäßig wiederverwendet werden muss. Kennt man die Spanne der IDs, die einen fünfstelligen Parameter ergeben, hat man einen deutlich kleineren Raum, den man über reines Iterieren durchlaufen kann. Wenn man noch einen Ausgangswert durch die eigene Gästekarte hat, ist das Überprüfen der unmittelbaren Nachbarwerte recht einfach.

Beschleunigend wirkt dabei die prinzipbedingte Eigenschaft eines URL-Shorteners, dass es sich nur um eine Weiterleitung des Webservers handelt und man ausschließlich den Header "Location" auslesen muss, ohne der Weiterleitung folgen zu müssen. Das produziert trotz der vielen Verbindungen keinen alarmierend hohen Netzwerkverkehr auf den Zielseiten.

Das Angriffsszenario und die Gegenmaßnahmen

Hat man keinen Ausgangspunkt, weil man keine Gästekarte besitzt, kann man den Zahlenbereich des fünfstelligen Parameters mittels Aufrufen grob durchlaufen, bis man auf eine Adresse mit der entsprechenden Domain stößt und von da aus in feineren Schritten iteriert. In Testläufen, deren Daten restlos gelöscht wurden, war es somit möglich, pro 2.000 Aufrufen etwa 35 valide Gästekarten abzurufen und Name, Vorname, Unterkunftsname und mehr zu erhalten. Das klingt zunächst nicht viel, aber mit entsprechendem Aufwand kann man mehrere Tausend Aufrufe pro Minute ausführen.

Die generelle Verwendung eines URL-Shorteners, auch bei bekanntem Algorithmus, ist nicht bedenklich, wenn es sich um nicht-personalisierte Daten handelt. In diesem Fall traf der unglückliche Umstand ein, dass durch das Seitendesign ein vergleichsweise schwacher Hash auf eine Seite verwies, die durch einen stärkeren geschützt war.

Melden der Schwachstelle

Gerade wenn man Betroffener ist, möchte man, dass die Schwachstelle so schnell wie möglich beseitigt wird, und das geht nur, wenn man den Betreiber direkt informiert. Das kann gewisse Risiken nach sich ziehen, weil Betreiber mitunter abwinkend oder herunterspielend reagieren und im schlechtesten Fall den Einreicher rechtlich belangen wollen – auch wenn das zum Glück selten vorkommt.

Als Einreicher einer Schwachstelle ist es sinnvoll, alle beteiligten Parteien anzuschreiben, um einen möglichst offenen und transparenten Diskurs zu ermöglichen. Denn ich bin der Überzeugung, dass die Beteiligten nur so eine sinnvolle Einschätzung der Dringlichkeit vornehmen können.

Schickt man es beispielsweise nur an die inhaltlich verantwortliche Person, schätzt sie unter Umständen die technische Brisanz nicht richtig ein. Umgekehrt kann die technisch verantwortliche Person vielleicht nicht einschätzen, wie hoch der potenzielle Imageschaden ist.

Also habe ich sowohl den Dienstleister als auch die Tourismusgesellschaft in einer Mail angeschrieben und einen ausführlichen Bugreport angehängt. Drei Tage später kam die Mail vom Dienstleister, dass sie sich für die Meldung bedanken, in interner Abstimmung zwischen Entwicklungsabteilung und dem Datenschutzbeauftragten seien und mich auf dem Laufenden hielten.

Tatsächlich bekam ich tags darauf die Mitteilung, dass Maßnahmen zur Schadensbegrenzung und zur Verhinderung weiterer Vorfälle getroffen wurden. Auch die Tourismusgesellschaft schickte mir eine Mail, in der man sich ausführlich bedankt und mitteilt, dass die Datenschutzbeauftragten aller Parteien informiert wurden.

Anzeige

Hacking & Security: Das umfassende Hacking-Handbuch mit über 1.000 Seiten Profiwissen. 3., aktualisierte Auflage des IT-Standardwerks (Gebundene Ausgabe)

Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.

Gegenmaßnahmen

Doch wie können solche Lecks vermieden werden? Sicher könnte man den Parameter des URL-Shorteners deutlich verlängern, um eine ähnliche Kombinationsanzahl zu erreichen, aber der Nutzen ist an der Stelle in Frage zu stellen. Besser wäre der Verzicht auf den Shortener auf personalisierten Seiten. Zusätzlich wäre eine Intrusion Detection hinsichtlich Iterierungsversuchen angebracht. Sie würde das reine Durchprobieren signifikant erschweren, könnte aber durch die Verwendung großer Bot-Netzwerke umgangen werden, wenn man Aufwand und Nutzen gewinnbringend gegenüberstellen kann.

Vorbildlich gehandelt

In unserem Fall haben die Verantwortlichen vorbildlich gehandelt. Die Schwachstelle wurde in annehmbarer Zeit beseitigt, indem der URL-Shortener nicht mehr auf den Seiten mit persönlichen Daten angezeigt wurde. Nach Stichproben ist auch davon auszugehen, dass bisher erfasste Seiten gelöscht wurden.

Das war auch dringend nötig. Denn eine Schwachstelle, die durchaus als "Datenleck" bezeichnet werden kann und es ermöglicht festzustellen, wo und für wie lange alle aktuellen Gäste eines Ortes unterkommen, hat erhebliches Missbrauchspotenzial und sollte entsprechend behoben werden.


Relevante Themen