Betrieb
TYPO3 gehackt: die ersten Stunden entscheiden
Ein Vorfall ist unangenehm, aber beherrschbar. Was ihn teuer macht, sind die ersten Handgriffe: Wer sofort die Sicherung zurückspielt, löscht die Spuren und holt sich die Lücke zurück, durch die es passiert ist.
Woran ein Vorfall erkennbar wird
Nur die wenigsten Angriffe kündigen sich mit einer Erpressungsnachricht an. Typisch sind unauffälligere Signale: Der Hoster meldet ausgehenden Spam, die Seite erscheint in Suchergebnissen plötzlich mit fremden Texten, der Browser warnt Besucher, oder im Backend tauchen Konten auf, die niemand angelegt hat.
Auch technische Spuren sind verräterisch. Dateien im Verzeichnis für hochgeladene Medien, die auf .php enden, gehören dort grundsätzlich nicht hin. Ein sprunghaft gewachsenes Fehlerprotokoll oder Datenbankeinträge mit eingebettetem Skriptcode weisen in dieselbe Richtung.
Wichtig ist die zeitliche Einordnung: Der Zeitpunkt des ersten auffälligen Verhaltens ist selten der Zeitpunkt des Einbruchs. Zwischen beiden liegen oft Wochen, in denen der Zugang unbemerkt bestand.
Die Reihenfolge, die den Schaden begrenzt
Zustand sichern, bevor irgendetwas verändert wird. Eine vollständige Kopie von Dateibestand und Datenbank, dazu die Server- und Zugriffsprotokolle, soweit sie noch vorhanden sind. Diese Kopie ist die einzige Grundlage für die Ursachensuche und im Zweifel auch für die Versicherung.
Die Seite aus dem Verkehr ziehen. Eine statische Wartungsseite reicht. Die Installation selbst bleibt unangetastet liegen.
Zugänge sperren. Alle Backend-Konten, FTP- und Datenbankzugänge, API-Schlüssel und Zugänge zum Hosting-Panel. Passwörter, die auch anderswo verwendet wurden, gehören überall gewechselt, nicht nur hier.
Den Zeitpunkt eingrenzen. Änderungszeitstempel im Dateisystem und Einträge im Zugriffsprotokoll liefern zusammen meist ein brauchbares Fenster. Erst mit diesem Fenster lässt sich beurteilen, welche Sicherung noch sauber ist.
Das Einfallstor finden. Erst danach wird bereinigt. Wer diesen Schritt überspringt, baut die Installation wieder auf und wartet auf die Wiederholung.
Wo die Ursache meistens liegt
In der Praxis führen drei Wege hinein. Eine veraltete Extension mit bekannter, veröffentlichter Lücke ist der häufigste. Ein kompromittierter Zugang ist der zweite, oft aus einer Kennwortwiederverwendung oder von einem infizierten Arbeitsplatzrechner. Der dritte ist die Serverumgebung selbst, etwa eine veraltete PHP-Version oder ein Nachbarprojekt auf demselben Konto.
Der TYPO3-Core ist selten der Einstiegspunkt. Das liegt an der Arbeit des Security Teams, aber auch daran, dass Angriffe dorthin gehen, wo es leichter ist. Wie man den Bestand vorher klein hält, steht unter Extensions bewerten.
Der Weg zurück in den Betrieb
Sauber ist eine Installation erst, wenn Core und Extensions aus einer vertrauenswürdigen Quelle stammen, die Inhalte aus einer geprüften Datenbank kommen und die Lücke geschlossen ist, durch die der Zugriff möglich war. Ein Abgleich mit einem unveränderten Stand aus der Versionsverwaltung macht diesen Schritt sehr viel schneller.
Danach folgt die unspektakuläre Nacharbeit: Zugänge neu vergeben, zweiten Faktor für Administrationskonten einrichten, Version auf einen Stand mit Support bringen. Welche das sind, zeigt die Versionsübersicht.
Zum Schluss gehört die Sichtbarkeit geprüft. Suchmaschinen und Browser-Warnlisten übernehmen einen als schädlich markierten Zustand nicht von selbst zurück, sondern erst nach erneuter Prüfung. Wer das vergisst, hat eine saubere Seite, die trotzdem niemand aufruft.
Was den nächsten Vorfall unwahrscheinlich macht
Nach dem Aufräumen ist der beste Zeitpunkt für die Fragen, die vorher niemand stellen wollte: Wer bekommt Sicherheitsmeldungen, und wie schnell werden sie eingespielt? Wie oft wird eine Sicherung testweise zurückgespielt? Wer hat Zugriff, und wer bräuchte ihn eigentlich nicht mehr?
Die vorbeugende Seite dieser Fragen behandelt der Ratgeber TYPO3 absichern. Wie laufende Betreuung das im Alltag abdeckt, steht unter TYPO3-Wartung.