Mittwald ist ein grosser deutscher Hoster, vor allem für Agenturen, die darüber die Websites ihrer Kunden betreiben. Am 5. November hat Mittwald die Anmeldung ins Kundenpanel gesperrt, alle SSH-Verbindungen getrennt, Programmierschnittstellen gesperrt und keine Bestellungen mehr angenommen. Die Websites liefen weiter.
Der Grund: Am 27. Oktober hatte sich jemand Zugang zu Mittwalds MCP-Server verschafft. Bemerkt hat Mittwald es am 4. November, eine Woche später. Der Angreifer hatte seine Spuren laut Mittwald getarnt.
Was ein MCP-Server ist
MCP ist ein Verfahren, über das KI-Assistenten auf andere Dienste zugreifen können. Statt nur Fragen zu beantworten, kann ein Assistent damit Dinge erledigen: ein Projekt anlegen, eine Datenbank einrichten, eine Einstellung ändern. Mittwald bot einen solchen Zugang an, damit Kunden ihr Hosting über einen KI-Assistenten verwalten konnten.
Damit das funktioniert, muss die Schnittstelle im Namen des Nutzers handeln dürfen. Sie hält dafür einen digitalen Schlüssel, einen sogenannten Token, mit genau den Rechten dieses Nutzers.
Was der Angreifer bekam
Genau diese Schlüssel. Laut Mittwald wurden die Tokens der Nutzer ausgelesen, die die Schnittstelle verwendet hatten. Jeder davon öffnete das Kundenpanel mit den Rechten seines Besitzers, also mit Zugriff auf dessen Projekte. Passwörter waren nicht dabei. Die Tokens sind inzwischen ungültig.
Bei einem Teil der Projekte gibt es Spuren, dass Dateien, Datenbanken oder Postfächer abgerufen wurden. Diese Kunden informiert Mittwald persönlich und hat ihre Projekte vorübergehend abgestellt.
Warum der zweite Faktor hier nicht hilft
Mittwald rät allen Kunden, eine Anmeldung mit zweitem Faktor einzuschalten. Das ist richtig, schützt aber vor etwas anderem. Ein Token ist eine Anmeldung, die schon stattgefunden hat. Wer ihn besitzt, muss kein Passwort eingeben und keinen Code bestätigen. Er ist schon drin.
Darum ist die Frage bei jedem KI-Assistenten, den man mit einem Konto verbindet, nicht nur, ob das Konto gut geschützt ist. Die Frage ist auch, wo der Schlüssel liegt, den man dem Assistenten gibt, und wer ausser einem selbst daran kommt.
Das betrifft nicht nur Hosting
KI-Assistenten lassen sich inzwischen mit vielem verbinden: mit dem Mailpostfach, dem Kalender, der Ablage in der Cloud, dem Buchhaltungsprogramm, dem Shop. Jede dieser Verbindungen ist ein Schlüssel mit den Rechten dessen, der sie eingerichtet hat. Nicht selten sind es die Rechte eines Administrators, weil das beim Einrichten am wenigsten Fragen aufwirft.
Wir haben gestern über eine Sicherheitssoftware geschrieben, deren Update-Kanal übernommen wurde. Es ist dieselbe Frage in neuer Form: Wer hat einen Schlüssel, und wie gut ist der Ort, an dem er liegt?
Was jetzt zu tun ist
Wer Mittwald nutzt: Die Hinweise von Mittwald befolgen. Wer den MCP-Server verwendet hat, ändert das Passwort, schaltet den zweiten Faktor ein, prüft Programmierschlüssel und SSH-Schlüssel auf unbekannte Einträge und erneuert die Zugangsdaten von Datenbanken, Mail und angebundenen Diensten.
Eine Liste machen. Welche KI-Assistenten sind im Betrieb mit welchen Konten verbunden, und wer hat das eingerichtet? Oft weiss das niemand vollständig.
Rechte klein halten. Ein Assistent, der Termine lesen soll, braucht keinen Zugriff auf das ganze Postfach. Wo der Dienst es erlaubt, eigene Schlüssel mit begrenzten Rechten und Ablaufdatum verwenden statt des eigenen Administratorkontos.
Ungenutztes trennen. Verbindungen, die einmal ausprobiert und dann vergessen wurden, sind die gefährlichsten. Sie stehen offen, und niemand sieht hin.