Admin-Keys im Frontend: Das Datenleck bei der Manchester Airports Group

Letzte Woche legte die Manchester Airports Group offen, dass Angreifer Systeme kompromittiert hatten, die Daten zu Parkplätzen, Lounges, Fast-Track-Buchungen und Wi-Fi-Anmeldungen im Terminal an den Flughäfen Manchester, London Stansted und East Midlands enthielten. Am 3. September veröffentlichte die Erpressergruppe rund 550 GB an Daten, nachdem MAG die Zahlung abgelehnt hatte. Die offengelegten Datensätze betreffen rund 8,8 Millionen Menschen und umfassen E-Mail-Adressen, Telefonnummern, Fahrzeugkennzeichen und Postleitzahlen. Der Flughafenbetrieb war nicht beeinträchtigt.

Die Angreifer behaupten, administrative Schlüssel für eine Marketingplattform eines Drittanbieters genutzt zu haben, die im clientseitigen JavaScript offengelegt waren. MAG hat bestätigt, dass die Daten in einer bei einem Drittanbieter gehosteten Datenbank lagen, und untersucht, wie die Schlüssel offengelegt wurden. Diese Methode stützt sich auf die Darstellung des Angreifers und nicht auf einen regulatorischen Befund, doch die Behauptung ist konkret und plausibel.

Das Versagen war nicht raffiniert

Clientseitiges JavaScript ist per Definition öffentlich. Jeder Browser jedes Besuchers lädt es herunter, und es zu lesen erfordert nichts weiter als die in diesen Browser eingebaute Entwicklerkonsole. Ein dort platziertes Zugangsdatum ist nicht verborgen, es ist veröffentlicht.

Dies ist ein wiederkehrendes Muster, kein ungewöhnlicher Ausrutscher. Marketingplattformen, Analysetools und Buchungsintegrationen werden unter Zeitdruck von Teams angebunden, deren Auftrag Conversion ist, nicht Sicherheit. Ein Schlüssel landet in einem Frontend-Skript, weil das der schnellste Weg ist, es zum Laufen zu bringen — und es funktioniert einwandfrei, weshalb niemand es je wieder überprüft. Die Folge ist eine Kompromittierung, die vollständig ausserhalb des Perimeters liegt, den die meisten Unternehmen mit ihrem Budget verteidigen. Keine Firewall und kein Endpoint-Agent waren relevant. Das Zugangsdatum stand im Schaufenster.

Die Zahlung zu verweigern war richtig — und es tat trotzdem weh

MAG zahlte nicht, und der Betrieb lief ohne Unterbrechung weiter. Das war die richtige Entscheidung, und sie entzog der Gruppe ihre Einnahmen.

Doch die Veröffentlichung der Daten war selbst die Botschaft. Neun Millionen Datensätze kostenlos freizugeben ist nicht nur Vergeltung an einem Opfer, es ist eine Demonstration an jedes zusehende Unternehmen. Die Konsequenzen tragen Kundinnen und Kunden, die an der Entscheidung keinen Anteil hatten.

Die Lehre für kleinere Unternehmen lautet, dass eine Lösegeldentscheidung nicht dasselbe ist wie ein Notfallplan. MAG konnte ablehnen, weil nur Daten auf dem Spiel standen, nie der Betrieb. Ein Unternehmen, das einer operativen Verschlüsselung gegenübersteht, befindet sich in einer anderen Lage — und der Zeitpunkt, um herauszufinden, in welcher Lage man wäre, ist vor dem Eintreten, nicht danach.

Wo Sie ansetzen sollten

Beginnen Sie mit der Exposition, die MAG hatte. Öffnen Sie Ihre eigene Website, sehen Sie sich den Seitenquelltext und die geladenen Skripte an, und suchen Sie nach allem, was einem Schlüssel, Token oder Secret ähnelt. Das kostet eine Stunde und zeigt Ihnen genau, was ein Angreifer sieht. Alles Gefundene muss rotiert, nicht nur entfernt werden.

Weiten Sie das auf die Plattformen hinter diesen Skripten aus. Marketing-Automatisierung, Buchungssysteme und Analysetools sammeln still personenbezogene Daten an und erscheinen selten im Inventar, das festhält, wo Kundendaten liegen. Stellen Sie fest, welche Drittanbieter die Daten Ihrer Kunden halten, welche Felder, und für wie lange. Planmässig gelöschte Daten können nicht geleakt werden.

Wo Integrationen Zugangsdaten benötigen, beschränken Sie diese auf die minimal nötige Funktion und halten Sie sie serverseitig. Ein Schlüssel, der einen Massenexport erlaubt, sollte nie aus einem Browser erreichbar sein, und die meisten Frontend-Integrationen brauchen ohnehin keinen.

Klären Sie schliesslich Ihre Haltung zu Erpressung im Voraus auf Vorstandsebene: Wer entscheidet, welche regulatorischen Pflichten bestehen, und was Sie Kundinnen und Kunden mitteilen würden. MAGs Ablehnung wirkte klar, weil die operativen Risiken gering waren. Diese Klarheit ist um drei Uhr morgens bei verschlüsselten Systemen weitaus schwerer zu erreichen.

Kernaussage: Angreifer erreichten Berichten zufolge 8,8 Millionen Kundendatensätze mithilfe administrativer Schlüssel, die im eigenen JavaScript einer Website sichtbar waren, und veröffentlichten 550 GB, nachdem das Lösegeld verweigert wurde. Kein Perimeter musste durchbrochen werden, weil das Zugangsdatum bereits öffentlich war. Prüfen Sie Ihr Frontend auf offengelegte Secrets, kartieren Sie, welche Drittanbieter Ihre Kundendaten halten, und klären Sie Ihre Haltung zu Erpressung, bevor Sie sie brauchen.