Kunden von Zeabur stehen vor zwei dringenden Aufgaben: offengelegte Zugangsdaten ersetzen und ihre Anwendungen verlagern, bevor die Plattform abgeschaltet wird.
Die Entwickler-Hosting-Plattform gab einen am 14.–15. Oktober erfolgten Angriff bekannt, bei dem Informationen zu 321.810 Konten und mehr als 3,2 Millionen Datensätzen mit Umgebungsvariablen offengelegt wurden. Der Vorfall folgte auf einen weiteren Einbruch im August. Zeabur hat angekündigt, den Betrieb bis Ende Dezember einzustellen.
Für Sicherheitsteams geht die Gefahr über Kontodaten hinaus. Bei einem Deployment-Anbieter gespeicherte Zugangsdaten können Angreifern Zugriff auf Datenbanken, Cloud-Ressourcen und kostenpflichtige KI-Dienste bei anderen Anbietern verschaffen.
Was der Angreifer abgerufen hat
Der von Zeabur veröffentlichte vorläufige Incidentbericht bestätigt, dass der Angreifer 3.218.965 Datensätze mit Umgebungsvariablen einschließlich Namen und Werten sowie Kontoinformationen wie E-Mail-Adressen, Benutzernamen und Telefonnummern gelesen hat.
Umgebungsvariablen enthalten Anwendungseinstellungen und können Passwörter oder API-Schlüssel enthalten. Die Zahl der Datensätze bedeutet nicht, dass 3,2 Millionen einzelne Kunden oder nutzbare Zugangsdaten offengelegt wurden. Zeabur erklärte, Variablen, die nach August ausschließlich auf die eigenen Server der Kunden migriert wurden, seien von diesem Datenbankvorfall nicht betroffen gewesen, kompromittierte Hosts könnten sie jedoch weiterhin offengelegt haben.
Zeabur bestätigte außerdem Root-Zugriff auf 101 dedizierte Google-Cloud-Server, die 92 Nutzer bedienten. Auf 50 Servern wurden vom Angreifer kontrollierte SSH-Schlüssel hinzugefügt, wodurch eine Rückkehr nach dem ursprünglichen Eindringen möglich war.
Kontoinhaber sollten sich vor gezieltem Phishing hüten und prüfen, ob ihre persönlichen Daten offengelegt wurden. Besitzer von Anwendungen müssen außerdem ermitteln, welche externen Dienste mit ihren gespeicherten Zugangsdaten erreichbar sind.
Das Risiko ähnelt dem jüngsten API-Schlüssel-Vorfall bei OpenCode: Eine von einer Entwicklerplattform entwendete Zugangsinformation kann direkt bei einem anderen Anbieter Aktivitäten autorisieren.
Nicht rotierte Zugangsdaten ließen den Zugriff offen
Zeabur erklärte, langlebige Administrator-Zugangsdaten seien im Klartext gespeichert gewesen und die Verwaltungsoberfläche für gemeinsam genutzte Cluster sei aus dem öffentlichen Internet erreichbar gewesen. Einige Administrator-Token waren seit Januar 2024 nicht rotiert und wurden bei der Reaktion auf den Vorfall im August übersehen.
Das Unternehmen hat nicht bestätigt, wie der Angreifer ursprünglich an diese Zugangsdaten gelangte. Ein Zusammenhang mit dem Einbruch im August bleibt eine Hypothese.
Der Vorfall unterstreicht den Wert von Netzwerksegmentierung und eingeschränktem Zugriff: Der Besitz einer Zugangsinformation für einen Dienst sollte keinen uneingeschränkten Weg in andere Systeme eröffnen.
Die Abschaltung im Dezember setzt eine Migrationsfrist
In seiner Ankündigung der Abschaltung legte Zeabur zwei Fristen fest:
- 1. Dez.: Verlängerungen dedizierter Server werden eingestellt, wobei die Server an ihren jeweiligen Ablaufdaten abgeschaltet werden. Laufende Dienste in gemeinsam genutzten Clustern werden pausiert, können von Kunden jedoch manuell neu gestartet werden, um Daten zu sichern.
- 31. Dez.: Alle dedizierten Server und gemeinsam genutzten Cluster stellen den Betrieb ein.
Kunden sollten ihre Planung am Ablaufdatum ihres Servers ausrichten. Das Unternehmen hat das Datum der Datenlöschung, die endgültige Exportfrist und das Datum der Einstellung des Supports noch nicht festgelegt.
Was Sicherheitsteams jetzt tun sollten
Die unmittelbaren Prioritäten sind der Widerruf von Zugangsdaten, die Untersuchung und die Wiederherstellung. Zeabur fordert Kunden auf, offengelegte Zugangsdaten zu ersetzen und kompromittierte Google-Cloud-Server neu aufzusetzen.
Eine praktische Reaktion sollte Folgendes umfassen:
- Zugangsdaten beim ausstellenden Anbieter widerrufen. Offengelegte API-Schlüssel, Cloud-Schlüssel, Datenbankpasswörter sowie Signatur- oder Verschlüsselungsschlüssel widerrufen und ersetzen und anschließend abhängige Anwendungen aktualisieren. Das Ändern eines Datenbankpassworts in einer Umgebungsvariablen ändert es nicht innerhalb der Datenbank.
- Aktivitäten und Kosten überprüfen. Prüfprotokolle des Anbieters, Datenbankaktivitäten und Rechnungen für KI-Dienste auf unbekannte Zugriffe oder Kosten prüfen.
- Persistenten Zugriff untersuchen. SSH-Schlüssel, Konten, geplante Aufgaben und die Dienstkonfiguration prüfen. Eine bloße Passwortänderung entfernt keinen vom Angreifer hinzugefügten SSH-Schlüssel.
- Eine saubere Migration vorbereiten. Relevante Protokolle sichern und benötigte Daten sichern, bevor Ersatzdienste neu aufgebaut und getestet werden.
Die Wiederherstellung über verbundene Dienste hinweg überprüfen
Sicherheitsteams sollten die Bereinigung von Zugangsdaten und die Migration als zusammengehörige Aufgaben behandeln. Die Verlagerung einer Anwendung kann die Verfügbarkeit wiederherstellen, während ein gestohlener Schlüssel beim ursprünglichen Anbieter weiterhin gültig ist. Vor dem Abschluss des Vorfalls sollte überprüft werden, dass alte Zugangsdaten nicht mehr funktionieren und Ersatz-Zugangsdaten nur dort funktionieren, wo dies vorgesehen ist.
Jeder betroffenen Integration sollte ein Verantwortlicher zugewiesen werden. Diese Person sollte dokumentieren, worauf die Zugangsdaten Zugriff ermöglichten, wann sie widerrufen wurden, welche Protokolle geprüft wurden und ob verdächtige Änderungen weiter untersucht werden müssen. Zugangsdaten mit Administratorrechten, Zugriff auf sensible Daten oder weitreichender Ausgabenbefugnis sollten priorisiert werden.
Die Wiederherstellung sollte getrennt vom vollständigen Kopieren der alten Umgebung erfolgen. Anwendungscode und Konfiguration validieren, benötigte Daten wiederherstellen und prüfen, dass nicht autorisierte Konten oder Zugriffsmethoden nicht mit der Arbeitslast in ihre neue Umgebung gelangt sind.
Organisationen, die andere Hosting-Anbieter prüfen, sollten aus diesem Fall konkrete Fragen ableiten: Kann der Anbieter jede in einen Vorfall verwickelte Zugangsinformation identifizieren, nachweisen, dass der Widerruf vollständig ist, und Protokolle bereitstellen, die eine ausreichende Untersuchung der Auswirkungen auf Kunden ermöglichen? Die Antworten helfen bei der Entscheidung, ob eine Sicherheitszusage ausreicht, um dem Dienst wieder zu vertrauen.
Mehr lesen: Der ConnectWise-Cloud-Backup-Einbruch zeigt, warum die Deaktivierung kompromittierter Anbieter-Zugangsdaten Administratoren nicht von der weiteren Arbeit entbindet, unbefugte Änderungen und persistierenden Zugriff aufzudecken.