Digitale Zeugnisse + Cyberangriffe auf NGOs + Handysucht + soziale Netzwerk-Alternativen + Gehalts-Check + Passwort-Check beim Bayerischen Digitalministerium + Risiken Datenleck-Meldungen + GI-Arbeitspapiere + Klaus-Tschira-Medaille + Helmut und Heide Balzert-Preis + GI-Webtalk zur Datenspende + 25 Jahre Computermuseum Stuttgart

Risiken und Nebenwirkungen (beim Melden) von Datenlecks. Kaum eine Woche vergeht, in der nicht ein neues Datenleck publik wird. Auf Webseiten wie dem Identity Leak Checker des Hasso-Plattner-Institutes (hpi.de) oder “Have I Been Pwned?” (haveibeenpwned.com) kann man durch die Eingabe der E-Mail-Adresse prüfen, ob und wann die eigenen Daten möglicherweise in die Hände Unbefugter gelangt sind. Neben schwerwiegenden Sicherheitslücken in (Web-)Applikationen kommt es immer wieder dazu, dass Administrator:innen Konfigurationen falsch anpassen oder schlicht das 1x1 der IT-Sicherheit nicht einhalten und es so Angreifer:innen erleichtern, an Daten zu gelangen. Oft liegt es in der Hand freiwilliger, ethischer Hacker:innen, diese Datenlecks oder Offenlegungen frühzeitig zu melden, um möglichen Angreifer:innen zurvor zu kommen. In dieser Ausgabe geben wir einen Einblick in diese Arbeit und mögliche Problemstellungen.

Nicht nur Kriminelle streifen auf der Suche nach Datenlecks durch das Internet, sondern auch Sicherheitsforscher:innen. Sie scannen Listen von Domains oder ganze IP-Adressbereiche nach Daten und Anwendungen mit fehlendem Zugangsschutz. Sie schauen nach sogenannten git-Ordnern oder anderen Werkzeugen zur Versionsverwaltung, nach einzelnen Dateien wie Kernelspeicher- oder Datenbankabbildern, nach zip-Archiven mit Backups oder Dateien mit Metainformationen, die versehentlich offen zugänglich auf Webservern abgelegt wurden. Teilweise finden sich auch offen zugängliche Datenbankschnittstellen. Da die gesuchten Daten oft einer bestimmten Struktur folgen, lässt sich das Scannen leicht automatisieren.

Ein bereits ausführlich beschriebenes Problem sind öffentlich abrufbare Inhalte in git-Ordnern. Werden diese gefunden und listet der Webserver Verzeichnisinhalte auf (sog. directory listings), dann kann der Ordner einfach gespiegelt und das Repository lokal ausgecheckt werden. Aber auch ohne directory listings können Repositories heruntergeladen werden. Das liegt daran, dass git im Kern ein einfacher Key-Value-Speicher ist. Alle versionierten Dateien und auch Informationen über Commits und die Struktur der Repositories werden als Objekte gespeichert und über einen Hash identifiziert. Zusätzliche Dateien, die immer an den gleichen Orten zu finden sind, wie .git/HEAD oder .git/index, referenzieren Objekte, die zum Teil weitere Objekte referenzieren. Mit diesen Informationen können nach und nach ganze Repositories heruntergeladen werden. Diese enthalten unter anderem den Quellcode, auch in früheren Commits gelöschte Dateien, manchmal Zugangsdaten oder API-Keys sowie in Einzelfällen auch Backups. (Internetwache.org, lynt.cz, Meli et al.)

Es gibt aber auch Datenlecks, die deutlich weniger technisches Hintergrundwissen erfordern. So gibt es beispielsweise zahlreiche Anleitungen im Web, die beschreiben, wie man Backups von Dateien oder Datenbanken anfertigen kann. Meist beschreiben diese das Vorgehen mit simplen Befehlen, welche Daten beispielsweise als backup.zip (golem.de) in dem Ordner ablegen, in dem der Befehl aufgerufen wurde. Wenig erfahrene Administrator:innen führen diese Befehle einfach aus und belassen Backups damit in öffentlich erreichbaren Verzeichnissen. 2017 waren so beispielsweise über 200.000 Datensätze der deutschen Post über die URL www.umziehen.de/dump.sql zugänglich (zeit.de).

Weitere Probleme ergeben sich durch unsichere Standardkonfigurationen von Applikationen. So sind zum Beispiel viele Fälle dokumentiert, in denen Datenbanken oder Datenbankschnittstellen ohne Authentifizierung zugreifbar waren. So konnte etwa der IT-Sicherheitsforscher Bob Diachenko 2021 106 Millionen Datensätze über Thailand-Reisende einsehen (comparitech.com). Ursache des Datenlecks war ein Elasticsearch-Cluster, das aus dem Internet und ohne nennenswerte Absicherung erreichbar war.

Zu weiteren Dingen, die auf Webservern vergessen oder versehentlich dort platziert werden, gehören unter anderem: Speicherabbilder (hboeck.de), sog. DS_Store (internetwache.org), temporäre Dateien (int21.de), private Schlüssel (golem.de) oder Dateien mit Umgebungsvariablen (zdnet.com).

Welche konkreten Folgen solche Schwachstellen haben können, hat der Chaos Computer Club (CCC) – unter Beteiligung des Mitautors dieses Artikels, Matthias Marx – in der vergangenen Woche beleuchtet. Der Club hat 50 Datenlecks gefunden und verantwortungsvoll gemeldet (ccc.de). Die Sicherheitsforscher des CCC hatten Zugriff auf mehr als 6,4 Millionen persönliche Datensätze von Kund:innen, Fluggästen, Bewerber:innen, Patient:innen, Versicherten und Nutzer:innen sozialer Netzwerke. Zudem konnten sie in vielen Fällen auf Quellcodes und Logdateien zugreifen.

Wenn Datenlecks rechtzeitig entdeckt, gemeldet und geschlossen werden, wird verhindert, dass Daten in (noch weitere) unbefugte Hände gelangen. Dennoch sind die Verantwortlichen, denen Datenlecks zur Behebung gemeldet werden, nicht immer angetan. Immer wieder wird Strafanzeige gegen Meldende erstattet (taz.de, golem.de). Solche Anzeigen bedeuten ein unkalkulierbares Risiko für Sicherheitsforscher:innen (ccc.de). Sie sind auf den guten Willen der Verantwortlichen angewiesen oder müssen hoffen, dass die Verfahren eingestellt werden (arstechnica.com, spiegel.de).

So werden gefundene Datenlecks unter Umständen gar nicht erst gemeldet, wodurch letztlich das IT-Sicherheitsniveau in Deutschland sinkt. Die Ampelkoalition möchte sich dieses Problems annehmen und verspricht im Koalitionsvertrag: „Das Identifizieren, Melden und Schließen von Sicherheitslücken in einem verantwortungsvollen Verfahren, z.B. in der IT-Sicherheitsforschung, soll legal durchführbar sein.“ (bundesregierung.de). Die Autoren erwarten daher, dass Deutschland bald ein sichereres Umfeld für Sicherheitsforscher:innen wird. Eine Forderung, die von der GI schon zur Einführung des Hackerparagrafen im Jahr 2007 so formuliert wurde (gi.de).

Dieses Thema im Fokus haben die GI Junior-Fellows Tim Philipp Schäfers und Matthias Marx geschrieben, die selbst schon einige Datenlecks verantwortungsvoll gemeldet haben. Welche Daten haben Sie schon einmal verloren? Wer hat Ihre Daten schon einmal verloren? Wir freuen uns über Ihre Einsendungen.