Zugangsdaten können weg sein, ohne dass eine Datei angefasst wurde

Die ganze Aufregung der letzten Tage drehte sich um eine Frage: Hat jemand Code auf meinem Server ausgeführt? Danach sucht jedes Werkzeug, auch unseres. Danach sucht jeder Dienstleister.

Es ist die richtige Frage. Sie ist nur nicht die einzige.

Denn bei dieser Art von Fehler gibt es einen zweiten Weg, der leiser ist: Der Server gibt Inhalte seines Arbeitsspeichers heraus, ohne dass irgendwo Code ausgeführt oder eine Datei verändert wird. Es bleibt keine Webshell zurück, kein veränderter Zeitstempel, kein Eintrag in einer Aufgabenplanung. Auf dem Dateisystem sieht alles aus wie immer.

Warum das überhaupt geht

Ein PHP-Arbeitsprozess bedient nacheinander viele Anfragen. Dazwischen wird der Speicher wiederverwendet – aus Geschwindigkeitsgründen, und das ist normal. In diesem Speicher liegt, was die vorherigen Anfragen gerade gebraucht haben.

Geht bei der Verarbeitung einer manipulierten Anfrage etwas schief, kann der Server Teile dieses Speichers in seine Antwort schreiben. Der Angreifer bekommt also nicht, was er sich aussucht, sondern was gerade danebenlag. Dafür kann er es beliebig oft wiederholen – und jedes Mal liegt etwas anderes daneben.

Was dort typischerweise liegt:

Es ist Zufall, was dabei herauskommt. Aber es ist kein Zufall, dass überhaupt etwas herauskommt.

Was das für Ihren Prüfbericht bedeutet

Hier liegt der unangenehme Teil, und wir schreiben ihn lieber selbst hin, als dass Sie ihn später von einem Prüfer hören:

Ein sauberer Befund auf dem Dateisystem schließt diesen Weg nicht aus. Unser Prüfwerkzeug sucht nach Hintertüren, nachgeladenen Startbefehlen und veränderten Konfigurationen. All das findet es zuverlässig, wenn es da ist. Einen Speicherabfluss findet es nicht – weil es dafür auf dem System nichts zu finden gibt. Genau deshalb steht dieser Punkt seit heute in jedem Bericht, den das Werkzeug ausgibt.

Es gibt genau eine Spur, und sie ist indirekt: gehäufte Serverfehler. Wenn ein Arbeitsprozess beim Verarbeiten abstürzt, steht das im Fehlerprotokoll – als Speicherfehler, als Signal 11, als Abbruch mit Status 500. Einzelne davon sind Alltag. Ein Bündel in kurzer Zeit, zeitlich passend zu ungewöhnlichen Anfragen, ist es nicht. Das Werkzeug meldet diese Häufungen inzwischen gesondert.

Was daraus folgt: austauschen statt suchen

Wenn sich ein Abfluss nicht ausschließen lässt, hilft Suchen nicht weiter. Es hilft nur, das Gesuchte wertlos zu machen.

Das klingt nach viel Arbeit und ist es auch. Deshalb in der Reihenfolge, in der es wirkt – nicht in der Reihenfolge, in der es Ihnen einfällt.

Zuerst: alle Sitzungen beenden

Eine gestohlene Sitzungskennung ist der direkteste Weg zurück ins System, und sie umgeht jedes Passwort und jede Zwei-Faktor-Anmeldung – denn die Anmeldung hat ja schon stattgefunden.

Praktisch bedeutet das: In WordPress, TYPO3 oder Ihrem Shop alle angemeldeten Benutzer abmelden. Die meisten Systeme können das zentral. Das verursacht fünf Minuten Unmut in der Redaktion und schließt den bequemsten Weg.

Dieser Schritt wird fast immer vergessen. Passwörter werden geändert, und die alten Sitzungen laufen weiter.

Dann: die Schlüssel, die Geld bewegen

In dieser Reihenfolge, weil der Schaden so gestaffelt ist:

Wer alles auf einmal tauscht, legt sich lahm. Wer nach dieser Reihenfolge vorgeht, hat nach Punkt zwei schon den größten Teil des möglichen Schadens abgeschnitten.

Und dann die unbequeme Frage

Wo gilt dasselbe Passwort noch? Ein Datenbankpasswort, das auch auf dem Testsystem läuft. Ein API-Schlüssel, der in drei Projekten steckt. Das ist der Punkt, an dem aus einem Website-Vorfall ein Firmenvorfall wird – derselbe Weg, der in Vom Webserver ins Firmennetz beschrieben ist.

Der Teil, der Sie betreffen könnte, auch wenn Ihr Server sauber ist

Drehen Sie es einmal um. Wenn Speicherinhalte anderer Besucher nach außen gelangen können, dann heißt das auch: Wo Sie Kunde sind, kann es Sie treffen, ohne dass Ihre eigene Technik etwas damit zu tun hat.

Haben Sie sich in den letzten Tagen in einem fremden Portal angemeldet, das auf PHP läuft? Bei einem Lieferanten, einem Verband, einer Behörde? Dann lag Ihre Sitzung dort im Speicher.

Das ist kein Grund zur Panik, aber es ist ein Grund, bei den zwei oder drei Portalen, die wirklich zählen, das Passwort zu wechseln und sich einmal überall abzumelden.

Muss das gemeldet werden?

Vorsicht, und zwar in beide Richtungen.

Eine Meldepflicht nach Artikel 33 DSGVO setzt eine Verletzung des Schutzes personenbezogener Daten voraus. Die theoretische Möglichkeit eines Speicherabflusses ist noch keine. Wer jede denkbare Möglichkeit meldet, meldet sich um Kopf und Kragen.

Anders wird es, sobald es Anhaltspunkte gibt: gehäufte Speicherfehler im passenden Zeitfenster, ungewöhnliche Anfragemuster, ein verdächtiger Zugriff. Dann beginnt die Frist von 72 Stunden – gerechnet ab dem Zeitpunkt, an dem Ihnen die Umstände bekannt werden, nicht ab dem Abschluss Ihrer Untersuchung.

Daraus folgt etwas Praktisches: Wer prüft, kann die Frist auslösen. Das ist kein Argument gegen das Prüfen – nicht zu wissen schützt nicht, und die Frist beginnt auch durch den Hinweis eines Dritten. Es ist ein Argument dafür, die Prüfung bewusst zu beginnen und das Ergebnis vom ersten Moment an zu dokumentieren.

Wie Sie das gegenüber Kunden formulieren, steht in Ihr Kunde verlangt einen Nachweis.

Was Sie sich sparen können

Damit die Liste oben nicht ins Uferlose wächst, drei Dinge, die hier nichts bringen:

Den Server neu aufsetzen. Gegen einen Speicherabfluss hilft das nicht – die Daten sind längst woanders. Gegen eine Hintertür hilft es, aber das ist ein anderes Problem.

Alle Benutzerpasswörter Ihrer Kunden zurücksetzen. Massenhafte Zwangsrücksetzungen erzeugen Support-Aufwand und Misstrauen. Sitzungen beenden genügt in aller Regel; Passwörter nur dort, wo es konkrete Anhaltspunkte gibt.

Warten, bis Gewissheit herrscht. Die kommt nicht. Bei diesem Weg gibt es keinen Nachweis, weder dafür noch dagegen.

Checkliste: erste Schritte

Wie DAVINCI unterstützt

Wir gehen mit Ihnen die Liste in der Reihenfolge durch, in der sie wirkt, und sorgen dafür, dass der Austausch dokumentiert ist – das brauchen Sie später gegenüber Kunden und Versicherung. Die technische Prüfung Ihres Servers können Sie selbst vornehmen, mit dem kostenlosen Prüfwerkzeug, das die Häufung von Speicherfehlern inzwischen gesondert ausweist. Bei konkreten Anhaltspunkten übernimmt unser Incident Response. Für eine Einschätzung ohne Zugang gibt es den Quick-Check und den kostenlosen PHP-Sicherheitscheck. Erreichbar über die Kontaktseite.

Verwandte Themen: Wer hier weiterdenkt, liest bei Remote Code Execution, Webserver kompromittiert und PHP2Shell Tool weiter.