Die Localmind GmbH warb mit lokaler KI und höchster Datensicherheit – heute dominiert auf ihrer Website das Thema Sicherheitsvorfälle. Was mit einem harmlosen Werbevideo begann, entwickelte sich zu einer beispiellosen Kette von Fehlkonfigurationen, Versäumnissen und mangelnder Sicherheitskultur. Dieser Beitrag zeigt, wie grundlegende Prinzipien der Informationssicherheit missachtet wurden – und wie ein funktionierendes Informationssicherheitsmanagementsystem (kurz: ISMS) viele dieser Fehler hätte verhindern können.
Offene Türen: Fehlkonfiguration statt Zugangskontrolle
Der Fehler allein lag nicht im Zeigen des Links ("security through obscurity"), sondern in der Konfiguration des Systems dahinter ("security by design"). Wie der Bericht über den „Hack“ detailliert beschreibt, konnte sich über den Zugang zum System jeder beliebige Nutzer ohne jegliche Verifizierung oder E-Mail-Bestätigung registrieren und erhielt automatisch die höchsten Administrationsrechte. Was sich anhört wie ein Prototyp oder eine Demoinstanz, war tatsächlich das Produktivsystem der Localmind GmbH, die zu diesem Zeitpunkt schon mehrere hunderttausend Euro von ihren Kunden eingenommen hatte. Hier hätte bereits das Control A.5.16 (Identity Management) greifen müssen, eine grundlegende Maßnahme in der ISO 27001. Diese fordert einen kontrollierten Prozess für den gesamten Lebenszyklus der Benutzeridentität, von der sicheren Erstellung bis hin zur Löschung. Eine offene Registrierung, die direkt zu Admin-Rechten führt, ist ein direkter Verstoß gegen dieses Control, sowie gegen das Control A.8.2 (privileged access rights). Dieses Control verlangt, dass privilegierte Zugangsrechte restriktiv und nur bei Notwendigkeit vergeben werden dürfen. Eine Umsetzung dieser beiden Controls hätte den Angriff an dieser Stelle beendet.
In der Regel wird es Angreifern nicht so leicht gemacht, aber auch ein Log-in ist in der Regel nicht ausreichend, um einen gezielten Angriff, z. B. per Phishing, abzuwehren. Der Angreifer konnte sich nun in der Produktivumgebung umsehen und weitere Informationen aufdecken. Innerhalb einer als "beta" deklarierten Testumgebung fanden sich Automatisierungs-Workflows mit dem API-Schlüssel zur Notion-Datenbank des Unternehmens. Die Localmind GmbH hat viele Abläufe und Themen vorbildlich dokumentiert, allerdings ihre Informationswerte nicht klassifiziert. Deshalb fand sich in dieser Unternehmensdatenbank auch alles, was es über das Unternehmen zu wissen gibt, sogar Passwörter und administrative Zugänge. Aber hätte so eine Information denn in einem Betasystem stehen dürfen? Ein Schlüssel und somit der zentrale Zugriff zur Wissensdatenbank der gesamten Firma sind unstrittig ein hochkritisches Produktionsgeheimnis und haben als solches nichts in einem Testsystem zu suchen. Eine saubere Trennung von Produktivsystem und Testumgebung hätte den Angreifer mit einer wenig nützlichen Testinstanz der Wissensdatenbank arbeiten lassen, stattdessen hat der Angreifer jedoch den Generalschlüssel für das gesamte Unternehmen erhalten.
Passwortmanager vorhanden – aber ungenutzt
Denn obwohl das Unternehmen mit einem Passwortmanager arbeitet (Vaultwarden), kam dieser nicht zum Einsatz. Hier waren Listen von Kundeninstanzen enthalten, deren initiale Admin-Passwörter für einen universalen Service-Account und zum Rest der Server-Infrastruktur waren. Die Control A.5.17 (Authentication Information) verbietet, dass Zugangsinformationen ungeschützt und im Klartext gespeichert werden. Das systematische Wiederverwenden von Passwörtern, insbesondere für einen privilegierten Service-Account (Control A.8.18, sieht hier eine enge Kontrolle und Überwachung vor), steht diametral zu Control A.8.5 (Secure Authentication). Durch die konsequente Nutzung des Passwortmanagers, wäre auch der Einbruch in die Wissensdatenbank eine Sackgasse gewesen.
An dieser Stelle werden im Bericht noch Screenshots von der Kommunikation zwischen Geschäftsführung und Mitarbeitern gezeigt, wie sie Passwörter und Mehrfaktorschlüssel per Mattermost (Teams-Alternative) austauschen. Der Eingang von Zahlungen wurde durch das CRM-System getrackt. Zu diesem Zeitpunkt ist das gesamte Unternehmen komplett übernommen und jedes System ist als kompromittiert anzusehen.
Technik allein reicht nicht: Die Rolle des ISMS
Am Ende zeigt der Fall, dass gute technologische Grundlagen nutzlos sind, wenn die Prozesse und die Kultur diese ignorieren. Ein funktionierendes ISMS hätte (Control A.5.8 Information Security in Project Management) nicht zuletzt durch Einhalten der einschlägigen Controls, sondern auch durch Einhalten des Managementrahmens (6.1 Actions to address risks and opportunities) diese Fehlerkette verhindert.
Kunden, die ihre wichtigen und sensiblen Daten und Informationen einem Dienstleister anvertrauen, müssen sich über den Sicherheitsprozess des Dienstleisters informieren, denn auch ihnen werden Vorgaben gemacht, durch DORA, NIS2 und die DSGVO.
Es muss nicht zwingend eine Zertifizierung sein, aber die Auseinandersetzung und Einbeziehung des Standes der Technik, haben sowohl das BSI als auch TeleTrusT Dokumente erstellt. Eine Ableitung und Nachweise der Umsetzung von Sicherheitsmechanismen sind dafür gemacht, genau solche Desaster zu verhindern.
Fazit
Lektion mit Ansage: Localmind startet verspätet mit ISMS
Wie das aktuelle Update (13.10.2025) zeigt, beginnt Localmind nun mit einem Sicherheitsprozess, der genau diese Punkte aufgreift und diese zu verhindern versucht (Control A.5.27 learning from incidents). Man kann sich Informationssicherheit nicht sparen. Am Ende ist es nur die Frage, ob dies in einem selbst bestimmten, gelenkten Prozess geschieht, oder jemand Drittes das Handeln diktiert.
Maximilian Kindshofer
