Horrorgeschichte aus der Security: Versehentliche Offenlegung personenbezogener Daten

Nichts geht über eine gute Horrorgeschichte … besonders, wenn es um Softwareentwicklung und Security geht. Ich meine: Was kann bei der Softwareentwicklung schon schiefgehen??? Und noch wichtiger: Was kann schiefgehen, wenn Sie und Ihr Team an einer kleinen F&E-Anwendung arbeiten und die Finanzierung des Projekts noch nicht gesichert ist …

Sie können sich vorstellen, dass die Arbeit unter enormem Druck, Funktionen in Höchstgeschwindigkeit bereitzustellen, damit die Finanzierung für den nächsten Zeitraum gesichert ist, den idealen Nährboden für eine Katastrophe bildet. Vor allem, wenn es keine klare Vorstellung vom Endziel des Projekts gibt und sich die Ideen täglich ändern.

Ich möchte Sie in meine Geschichte mitnehmen, in der aus Security-Sicht einiges schiefging. Da dieses kleine F&E-Projekt nach Cowboy-Manier Teil einer größeren Institution war, ähnlich einer Bank oder Versicherung, stand mehr auf dem Spiel als nur ein kleines Projekt.

Das Projekt

Das Projekt begann als mobile App, mit der sich Immobilien wie Gebäude und Häuser erkunden ließen. Da der Großteil der Systemlogik serverseitig lag, entwickelten wir eine hervorragende serviceorientierte (Microservice-)Lösung in Java.

Einer der Services war der Profilserver. Jedes Profil enthielt eine zufällig generierte UUID und eine Liste von Präferenzen. Eine der wichtigsten Funktionen war die anonyme Nutzung der App. Deshalb speicherten wir die UUID im lokalen Speicher des Geräts und verwendeten sie, um das Profil vom Server abzurufen. Kurz gesagt sah der Service ungefähr so aus.

Irgendwann kam die Idee auf, dass Nutzer:innen eine Immobilie im System für sich beanspruchen können sollten. Das ist vor allem dann der Fall, wenn jemand das Haus oder Gebäude besitzt. Die Eigentümer:innen konnten die Immobilie nun mit Bildern und einer Beschreibung ergänzen. Ein Haus konnte nur von einer Person beansprucht werden.

Diese neue Funktion führte zu zwei entscheidenden Änderungen im Zusammenhang mit dieser Geschichte.

• Wir erstellten einen neuen Service namens „MyHouse“, damit Nutzer:innen ein Haus für sich beanspruchen können.

• Der Profilservice musste erweitert werden. Nutzer:innen sollten sich nun anmelden und ein Haus beanspruchen können. Deshalb ergänzten wir den bestehenden Profilservice um eine Registrierungsoption.

Die Services sahen ungefähr wie unten dargestellt aus: Ein MyHouse-Objekt war mit einem Nutzerprofil verknüpft, das die UUID enthielt, und das Profil konnte nun auch eine E-Mail-Adresse enthalten.

Wichtig ist, dass wir angewiesen waren, die anonyme Nutzung wie bisher weiterhin zu unterstützen und diese Funktion zusätzlich zu den bereits vorhandenen Funktionen anzubieten.

Das Problem

Der neue MyHouse-Service hatte einen Endpunkt, über den alle beanspruchten Immobilien aufgelistet werden konnten. Dabei wurde das vollständige MyHouse-Objekt als JSON offengelegt, einschließlich der UUID des Profils. Da wir die bisherige Funktionalität weiterhin unterstützen mussten, ließ sich ein Profil nach wie vor allein anhand seiner UUID finden.

Kurz gesagt: Das mobile Frontend benötigte die UUID überhaupt nicht. Doch mit einer einfachen HTTP-Anfrage und dem MyHouse-Objekt ließ sich die UUID in einem zweiten Aufruf verwenden, um das Profil zu finden. Von da an konnten Personen die physische Adresse einer Immobilie mit einer E-Mail-Adresse verknüpfen. Da E-Mail-Adressen häufig aus firstname.lastname@provider.com (oder ähnlich) bestehen, kam es zu einem Datenleck: Eine Person ließ sich einer physischen Adresse zuordnen. Hoppla – offengelegt wurden personenbezogene Daten, also PII.

Die Lösung und die Folgen

Der Vorfall wurde anonym der Security-Abteilung des Unternehmens gemeldet. Glücklicherweise übernahm eine verantwortungsbewusste Person Verantwortung und meldete die Sicherheitslücke auf verantwortungsvolle Weise. Nachdem wir das Problem verstanden hatten, war die Behebung in fünf Minuten erledigt – einschließlich des Deployments in die Produktionsumgebung. Indem wir dem UUID-Feld des MyHouse-POJO eine @JsonIgnore-Annotation hinzufügten, verhinderten wir, dass das Feld als JSON serialisiert wurde. Damit ließ sich ein Profil nicht mehr mit einer physischen Adresse verknüpfen.

Aus technischer Sicht könnten Sie den Beitrag hier beenden. Doch auch wenn die Behebung einfach war, waren die Folgen eines solchen Vorfalls äußerst belastend. Alles begann mit einer Flut von Fragen zum Vorfall:

• Wessen Daten wurden offengelegt?

• Wie lange war die Lücke vorhanden?

• Welche Folgen hat dieses Datenleck?

• Welche Daten wurden offengelegt?

• Wer wurde durch dieses Datenleck zum Opfer?

• Warum haben wir das nicht verhindert?

• Und so weiter und so fort.

All diese Fragen bedeuteten einen enormen Papieraufwand, den mein Team und ich bewältigen mussten. Einige Antworten lagen auf der Hand, doch da es ein F&E-Projekt mit hohem Zeitdruck war, hatten wir noch keine geeignete Protokollierung eingerichtet. Herauszufinden, wer betroffen war, war unmöglich. Vielleicht hatten böswillige Personen die Sicherheitslücke gar nicht ausgenutzt. Wir wussten es schlicht nicht.

Am schlimmsten war, dass das höhere Management uns nun Vorwürfe machte, etwa mit Aussagen wie: „Es ist eine Schande, dass unsere Engineers überhaupt kein Security-Bewusstsein haben“ oder „Dieses Team ist inkompetent, das hätten Sie erkennen müssen“. Zusätzlich zum enormen Papieraufwand begannen Manager, alles bis ins Kleinste zu kontrollieren, ohne fundierte Kenntnisse in Entwicklung oder Security zu haben.

Was wir daraus gelernt haben

Als Erstes protokollierten wir alles. Ein Security-Problem zu bewältigen ist das eine; die Folgen und die vielen Fragen sind etwas völlig anderes. Anschließend überprüften wir unser Datenmodell gründlich, um herauszufinden, ob unser REST-Endpunkt Daten offenlegte, die das Frontend gar nicht benötigte.

Das Engineering-Team nutzte den Vorfall auch, um sich gegen die hohen Anforderungen und den Druck der Produktmanager:innen zu wehren. Doch Security-Bewusstsein sollte bedeuten, Security in den Entwicklungsprozess zu integrieren – nicht, Menschen die Schuld zu geben. Meiner ehrlichen Meinung nach wäre die richtige Lösung gewesen, in die Unternehmenskultur zu investieren und geeignete Tools auszuwählen, die den Entwicklungsprozess unterstützen. Nicht lange danach entschied ich mich, das Unternehmen zu verlassen …

Folgen Sie uns auf Twitter (@snyksec), um weitere Horrorgeschichten aus der Security wie diese zu lesen! #31DaysOfSecurity