Was hatten wir diese Woche nicht alles Schönes? Eine kritische Sicherheitslücke in der Infrastruktur, hektische Reaktionen bei Hosting-Anbietern, verunsicherte Webseitenbetreiber und die alte Frage, ob zwischen theoretischer Verwundbarkeit und praktisch ausnutzbarem Risiko noch jemand sauber unterscheidet, das war genau das, was es sogar als Schlagzeile in die großen Boulevard-Medien geschafft hat. PHP2Shell hat zudem einige unangenehme Wahrheiten über die Sicherheit moderner Webanwendungen offengelegt, aber längst nicht jede denkbare Angriffskette war für jeden erreichbar und nicht jede drastische Gegenmaßnahme war deshalb automatisch sinnvoll.

Ja, es gibt Sicherheitsprobleme, die zunächst unscheinbar wirken und sich bei genauerer Betrachtung als gefährlich herausstellen. Und es gibt solche, deren öffentliche Wahrnehmung innerhalb kürzester Zeit derart eskaliert, dass zwischen tatsächlicher technischer Gefahr, theoretischen Angriffsszenarien und allgemeiner Betriebsamkeit kaum noch unterschieden wird. PHP2Shell gehört zumindest in Teilen zur zweiten Kategorie, ohne dass man daraus im Umkehrschluss eine Entwarnung ableiten dürfte.

Denn das grundsätzliche Problem ist ernst. PHP gehört zu den wichtigsten Grundlagen des dynamischen Internets. WordPress, XenForo, zahlreiche Shopsysteme, Verwaltungsoberflächen und unzählige individuell entwickelte Webanwendungen hängen direkt oder indirekt an dieser Laufzeitumgebung. Eine kritische Schwachstelle in einem so weit verbreiteten Baustein betrifft deshalb nicht nur einzelne Webseiten, sondern potenziell ganze Hosting-Infrastrukturen. Wie groß der tatsächlich ausnutzbare Anteil ist, hängt allerdings von weit mehr ab als einer Versionsnummer. Genau an diesem Punkt begann aus meiner Sicht auch ein Teil der öffentlichen Verwirrung. Eine verwundbare PHP-Version, eine gefährliche Konfiguration, eine von außen erreichbare Angriffsoberfläche und eine praktisch funktionierende Angriffskette sind vier verschiedene Dinge. Wer sie gedanklich zusammenwirft, kommt zwangsläufig zu einer überzeichneten Risikobewertung. Wer sie hingegen sauber auseinanderhält, kann sehr viel gezielter reagieren. 

Ich muss eine Einschränkung ausdrücklich voranstellen: Die nachfolgende Betrachtung unterscheidet zwischen den diskutierten PHP2Shell-Angriffsklassen und allgemein bekannten Mechanismen von PHP-Webanwendungen. 

PHP ist im klassischen Webbetrieb auch kein isoliertes Programm, das bei einem Fehler einfach eine Fehlermeldung ausgibt und anschließend wieder verschwindet. In typischen Linux-Hostingumgebungen nimmt zunächst ein Webserver wie Nginx oder Apache die HTTP-Anfragen entgegen. Dynamische Anfragen werden über eine entsprechende Schnittstelle an PHP weitergeleitet, häufig an einen PHP-FPM-Pool mit mehreren Worker-Prozessen. Diese Worker führen die Anwendung aus, greifen auf Datenbanken zu, lesen Dateien, verwalten Sitzungen und erzeugen schließlich die dynamischen Inhalte, die der Webserver an den Besucher zurückliefert. Ein erfolgreicher Angriff auf diese Verarbeitungsebene kann deshalb ganz unterschiedliche Auswirkungen haben. Im vergleichsweise begrenzten Fall fällt ein Worker aus, wird vom Prozessmanager neu gestartet oder steht vorübergehend nicht mehr zur Verfügung. Im schweren Fall gelingt es einem Angreifer, über die verwundbare Verarbeitung auf Ressourcen zuzugreifen, die ihm eigentlich nicht offenstehen sollten. Und genau diese Unterscheidung ist dann auch entscheidend!

Wenn ein einzelner PHP-Worker kontrolliert zum Absturz gebracht oder anderweitig blockiert werden kann, ist das zunächst ein Verfügbarkeitsproblem. Wenn ein Angreifer hingegen Daten auslesen, fremde Befehle ausführen, privilegierte Funktionen erreichen oder die Grenzen zwischen verschiedenen Hosting-Kunden überwinden kann, reden wir über eine qualitativ andere Bedrohung. Beides kann seinen Ursprung in derselben allgemeinen Problemklasse haben. Es ist aber keineswegs dasselbe Schadenspotenzial. Ein Server, der eine einzelne Anfrage nicht überlebt, ist schlecht abgesichert. Ein Server, der dabei auch noch seine Geheimnisse preisgibt oder fremden Code ausführt, hat ein sehr viel grundlegenderes Problem.

Zu den besonders unangenehmen Eigenschaften bestimmter Fehler in Laufzeitumgebungen gehört, dass die Verfügbarkeit bereits durch relativ einfache Anfragen beeinträchtigt werden kann. Dafür benötigt ein Angreifer nicht einmal zwingend Administratorrechte, Zugangsdaten oder eine ausgefeilte Angriffskette. Wenn eine von außen erreichbare Verarbeitung einen reproduzierbaren Prozessabsturz oder einen dauerhaft blockierenden Zustand auslöst, kann es unter ungünstigen Bedingungen genügen, diese Verarbeitung wiederholt anzusprechen. Das bedeutet allerdings nicht automatisch, dass dann der gesamte Server sofort ausfällt. PHP-FPM ist gerade dafür ausgelegt, mehrere Worker zu verwalten und ausgefallene Prozesse zu ersetzen. Stirbt ein einzelner Worker, kann der Pool ihn grundsätzlich neu starten. Solange die Anzahl der fehlerhaften Anfragen gering bleibt und genügend Kapazität verfügbar ist, fällt der Vorfall im regulären Betrieb womöglich sogar nicht einmal auf.

Problematisch wird es erst dann, wenn die Ausfallrate höher ist als die Wiederherstellungsrate oder wenn die Verarbeitung eines Angriffs dauerhaft Ressourcen bindet. Dann geraten zunächst einzelne Worker und schließlich möglicherweise der gesamte Pool unter Druck. Normale Besucher warten auf freie Verarbeitungskapazität, Anfragen laufen in Timeouts und der Webserver antwortet irgendwann mit Fehlern. Besonders ärgerlich ist dabei, dass ein vergleichsweise kleiner Datenverkehr erhebliche Auswirkungen haben kann, wenn die angegriffene Operation auf der Serverseite einen überproportional hohen Aufwand verursacht. Das ist dann eine Form asymmetrischer Ressourcenbelastung und der Angreifer investiert wenig, der Betreiber zahlt hingegen mit Rechenzeit, Speicher, Prozessneustarts und Verfügbarkeit. Dumm gelaufen. Allerdings sollte man auch hier nicht übertreiben. Ein Absturz eines PHP-Workers ist nicht gleichbedeutend mit dem Absturz des Betriebssystems und der Ausfall eines PHP-FPM-Pools ist nicht zwangsläufig ein Ausfall sämtlicher auf einem Host betriebener Anwendungen. Die tatsächlichen Folgen hängen von Prozessisolation, Poolkonfiguration, Ressourcenbegrenzungen und Architektur ab. 

Für opportunistische Angreifer ist eine leicht auslösbare Störung trotzdem attraktiv. Man muss nicht verstehen, wie die gesamte Infrastruktur funktioniert, wenn man bereits mit einer einzigen reproduzierbaren Fehlersituation genügend Schaden anrichten kann.

Deutlich komplexer wird die Lage dann dort, wo sich eine Schwachstelle nicht nur zur Störung der Verarbeitung, sondern zur Manipulation von Speicherzuständen, zur Umgehung von Sicherheitsgrenzen oder zur Ausführung nicht vorgesehener Operationen nutzen lässt. Genau an dieser Stelle trennen sich die Möglichkeiten einfacher Nachahmer von denen erfahrener Sicherheitsforscher und professioneller Angreifer. Ein reproduzierbarer Prozessabsturz ist noch kein Beweis dafür, dass beliebige Befehle ausgeführt werden können, denn zwischen beidem können erhebliche technische Hürden liegen. Speicherlayout, Schutzmechanismen, Prozessrechte, Zufallsadressierung und die konkrete Laufzeitumgebung bestimmen mit darüber, ob aus einem Fehler mehr werden kann als ein kontrollierter Absturz. 

Professionelle Angreifer untersuchen deshalb nicht allein, ob eine bestimmte Anfrage einen Fehler auslöst. Sie versuchen zu verstehen, welche internen Zustände verändert werden können, ob sich diese Zustände gezielt beeinflussen lassen und ob daraus ein verlässlicher weiterer Zugriff entsteht. Selbst erfolgreiche Codeausführung innerhalb eines PHP-Workers bedeutet aber nicht automatisch vollständige Kontrolle über den Server. Zunächst gelten normalerweise die Berechtigungen des jeweiligen Prozesses. Ob daraus ein größerer Einbruch wird, hängt von zusätzlichen Voraussetzungen ab. Kritisch sind insbesondere zu weitreichende Dateirechte, gemeinsam verwendete Zugangsdaten, unsichere Trennung zwischen Hosting-Kunden, unnötige Betriebssystemberechtigungen oder erreichbare Verwaltungsdienste. Eine sauber getrennte Hostingumgebung kann den Schaden deshalb erheblich begrenzen. Eine schlecht konfigurierte Umgebung kann aus einer ursprünglich lokalen Schwachstelle dagegen ein Infrastrukturproblem machen.

Der Begriff PHP2Shell sollte deshalb nicht dazu verleiten, jedes denkbare Ergebnis bereits als tatsächlich erreichbare Shell auf jedem betroffenen Server zu interpretieren.

Ob und auf welchem Weg eine solche Eskalation möglich ist, muss für die konkrete Schwachstelle und die konkrete Betriebsumgebung nachgewiesen werden. Das ist jetzt auch keine akademische Wortklauberei von mir, sondern der Unterschied zwischen technischer Risikoanalyse und der üblichen Sicherheitsfolklore.

Im Zusammenhang mit PHP2Shell wurde auch darüber diskutiert, ob eine aktualisierte PHP-Version bereits ausreichenden Schutz bietet. Auf unserem System lief beispielsweise nach dem Patch statt PHP 8.3.35 dann PHP 8.3.36. Eine solche Versionsangabe ist für die Bestandsaufnahme wichtig, beantwortet aber für sich genommen noch nicht sämtliche Sicherheitsfragen. Bei Linux-Distributionen und Managed-Hosting-Umgebungen wie meiner kommt hinzu, dass Sicherheitskorrekturen teilweise als Backports bereitgestellt werden. Ein Anbieter kann also relevante Änderungen in ein bestehendes Paket übernehmen, ohne dass dessen sichtbare Versionsbezeichnung zwingend der neuesten offiziellen PHP-Ausgabe entspricht. Umgekehrt wäre es falsch, allein aus einer höheren Versionsnummer abzuleiten, dass auch alle notwendigen Änderungen an Webserverkonfiguration, PHP-FPM, Erweiterungen und vorgeschalteter Infrastruktur vorgenommen wurden. 

Entscheidend sind die tatsächlich eingesetzten Binärdateien, deren Patchstand und die Bedingungen, unter denen eine Schwachstelle ausgenutzt werden kann.

Bei einem Managed Server liegt ein wesentlicher Teil dieser Verantwortung beim Hosting-Anbieter, in meinem Fall also Hetzner. Als Kunde kann und sollte man jedoch auch seine eigenen Anwendungen absichern, verdächtige Zugriffe überwachen und die Angriffsfläche reduzieren. Änderungen an zentral verwalteten Laufzeitkomponenten müssen stets kontrolliert durch denjenigen erfolgen, der diese Komponenten tatsächlich betreibt. Ein vermeintlich schneller Eingriff außerhalb dieser Zuständigkeiten kann sogar zusätzliche Probleme verursachen.

Auch bei igor’sLAB stellte sich die Frage, wie weit man angesichts der diskutierten Bedrohung gehen sollte. Schließlich betreibe ich mit WordPress und XenForo zwei komplexe PHP-basierte Systeme, die öffentlich erreichbar sind und täglich eine erhebliche Anzahl von Anfragen verarbeiten müssen. Ich habe mich trotzdem bewusst dagegen entschieden, die Webseite vor der Bereitstellung der notwendigen Korrekturen durch Hetzner vorsorglich vollständig abzuschalten. Das war jetzt auch keine Entscheidung nach dem Motto, es werde schon nichts passieren, sondern ich hatte vielmehr bereits präventive Gegenmaßnahmen ergriffen und die vorhandenen Cloudflare-Regeln entsprechend berücksichtigt beziehungsweise ergänzt, um verdächtige und potenziell problematische Zugriffe möglichst früh abzufangen. Ergänzend ging es darum, öffentlich erreichbare Verarbeitungspfade kritisch zu betrachten und unnötige Angriffsflächen nicht länger offen zu halten als erforderlich.

Die genaue Ausgestaltung solcher Schutzmaßnahmen muss sich immer an der tatsächlichen Schwachstelle orientieren. Eine pauschale Firewall-Regel kann zwar bestimmte Angriffsmuster erkennen oder deren Ausführung erschweren, sie repariert jedoch keinen Fehler in der PHP-Laufzeitumgebung. Cloudflare war deshalb für mich dann eine vorgeschaltete Schutzebene, aber natürlich auch kein Ersatz für den Patch durch Hetzner. Hinzu kommt, dass ein vorgeschalteter Schutz nur für den darüber geführten Datenverkehr wirkt. Wenn ein Angreifer den Origin-Server direkt erreichen kann, helfen Regeln am Cloudflare-Eingang gegen diesen direkten Zugriff nicht. Ebenso wenig lassen sich sämtliche denkbaren Exploitvarianten mit einfachen Zeichenkettenfiltern zuverlässig erkennen. 

Eine vorsorgliche Komplettabschaltung hätte dagegen einen sicheren Effekt gehabt: igor’sLAB wäre für sämtliche Leser nicht mehr erreichbar gewesen. Der mögliche Angriff auf die Verfügbarkeit wäre damit durch einen selbst herbeigeführten vollständigen Ausfall ersetzt worden. Genau das habe ich angesichts meiner damaligen Risikobewertung für unverhältnismäßig gehalten und so darauf verzichtet. Natürlich ist eine solche Entscheidung keine allgemeingültige Empfehlung. Hätte es belastbare Hinweise auf einen erfolgreichen Angriff, eine akut ausnutzbare kritische Angriffskette ohne ausreichende Gegenmaßnahmen oder eine bereits laufende Kompromittierung gegeben, hätte die Bewertung sicher anders ausfallen müssen. Ebenso wäre die vorübergehende Sperrung einzelner Funktionen eine mögliche Zwischenlösung gewesen. Eine vollständige Abschaltung sollte aber das Ergebnis einer konkreten Gefahrenabwägung sein und nicht allein die reflexartige Reaktion auf eine besonders drastische Schlagzeile. Denn Sicherheit bedeutet nicht, aus Angst vor einem möglichen Ausfall vorsorglich jede Verfügbarkeit aufzugeben. Man kann das Ganze ja auch akktiv überwachen:

Der Vorteil eines vorgeschalteten Dienstes wie Cloudflare liegt darin, dass sich ein Teil der problematischen Anfragen bereits abweisen lässt, bevor sie überhaupt den eigentlichen Webserver erreichen, denn gezielt gestaltete Regeln für verdächtige Anfragemuster, Zugriffsbeschränkungen auf empfindliche Endpunkte, geeignete Ratenbegrenzungen und weitere Filtermöglichkeiten können die praktische Angriffsfläche deutlich reduzieren und besonders gegen automatisierte Massenanfragen und triviale Wiederholungsangriffe ist das wirklich sinnvoll. Allerdings hat auch diese Schutzschicht natürlich Grenzen.

Eine Anfrage, die formal wie ein vollkommen legitimer Seitenaufruf aussieht und erst durch einen bestimmten internen Verarbeitungszustand einen Fehler auslöst, lässt sich nicht zwangsläufig zuverlässig anhand äußerer Merkmale erkennen. Zu aggressive Filter treffen außerdem irgendwann normale Besucher, Suchmaschinen oder legitime API-Aufrufe. Wer dann seine Schutzregeln noch so weit verschärft, dass am Ende kaum noch jemand die Seite erreichen kann, hat das eigentliche Verfügbarkeitsproblem lediglich an eine andere Stelle verschoben. Bei komplexeren Webseiten wie meiner kommt dann noch hinzu, dass WordPress, XenForo und ihre Erweiterungen zahlreiche legitime dynamische Anfragen erzeugen. Eine pauschale Blockierung aller ungewöhnlich aussehenden PHP-Zugriffe mag einfach klingen, kann aber Funktionen beschädigen, deren Zusammenhang mit diesen Anfragen für den Administrator zunächst gar nicht offensichtlich ist. Deshalb ist wirklich eine saubere Differenzierung wichtig.

Schutzmaßnahmen müssen auf konkrete Angriffsflächen zugeschnitten werden. Sie sollten messbar sein, möglichst wenige Kollateralschäden verursachen und sich im Fehlerfall wieder zurücknehmen lassen.

Im Idealfall kann man anschließend anhand der Protokolle nachvollziehen, welche Anfragen blockiert wurden und ob es sich tatsächlich um Angriffsversuche handelte. Eine hohe Zahl geblockter Requests ist für sich genommen übrigens noch kein Sicherheitsnachweis. Sie kann ebenso gut zeigen, dass eine Regel großzügig oder schlicht unpräzise formuliert wurde. Grund zur Panik ist sowas natürlich nicht, sondern ein Indikator für mögliche eigene Versäumnisse.

Ein Fehler in der PHP-Laufzeitumgebung ist grundsätzlich von einer Schwachstelle im selbst geschriebenen PHP-Code zu unterscheiden. Trotzdem lohnt sich ein Blick darauf, wie unsichere Anwendungen Angriffsflächen schaffen und warum eine sorgfältige Programmierung mindestens genauso wichtig ist wie ein aktueller Server. Nehmen wir als einfaches Beispiel mal so etwas Triviales wie ein Eingabefeld, über das ein Besucher nach einem bestimmten Produkt suchen kann. Ein hastig geschriebenes PHP-Skript könnte versuchen, den eingegebenen Suchbegriff direkt an ein externes Systemkommando weiterzureichen. Das wäre beispielsweise dann gefährlich, wenn die Eingabe ohne ausreichende Trennung zwischen Daten und ausführbarer Kommandozeile verarbeitet wird. Dabei muss man sich nicht einmal einen besonders raffinierten Angreifer vorstellen. Das grundlegende Problem besteht bereits darin, dass Benutzereingaben in einem Kontext landen, in dem sie nicht mehr ausschließlich Daten sind, sondern möglicherweise die Bedeutung einer Anweisung verändern können. Eine robustere Lösung verzichtet deshalb nach Möglichkeit vollständig darauf, für eine einfache Suchfunktion überhaupt ein Betriebssystemkommando aufzurufen. Stattdessen verwendet sie eine Datenbankabfrage mit gebundenen Parametern:

<?php
declare(strict_types=1);

$query = $_GET['q'] ?? '';

if (!is_string($query)) {
    http_response_code(400);
    exit('Ungültige Eingabe');
}

$query = trim($query);

if (
    $query === '' ||
    mb_strlen($query, 'UTF-8') > 100
) {
    http_response_code(400);
    exit('Ungültiger Suchbegriff');
}

$pdo = new PDO(
    'mysql:host=localhost;dbname=example;charset=utf8mb4',
    $dbUser,
    $dbPassword,
    [
        PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
        PDO::ATTR_EMULATE_PREPARES => false
    ]
);

$stmt = $pdo->prepare(
    'SELECT name, description
     FROM products
     WHERE name LIKE :search
     LIMIT 20'
);

$stmt->execute([
    'search' => '%' . $query . '%'
]);

$results = $stmt->fetchAll(PDO::FETCH_ASSOC);

foreach ($results as $product) {
    echo '<h3>' .
        htmlspecialchars(
            $product['name'],
            ENT_QUOTES | ENT_SUBSTITUTE,
            'UTF-8'
        ) .
        '</h3>';

    echo '<p>' .
        htmlspecialchars(
            $product['description'],
            ENT_QUOTES | ENT_SUBSTITUTE,
            'UTF-8'
        ) .
        '</p>';
}

Dieses Beispiel ist jetzt bewusst einfach gehalten. Die Datenbankzugangsdaten müssen selbstverständlich außerhalb des öffentlich erreichbaren Anwendungscodes verwaltet und mit möglichst wenigen Berechtigungen versehen werden. Eine öffentlich eingesetzte Implementierung benötigt außerdem ein geeignetes Fehlerhandling, gegebenenfalls Ratenbegrenzungen und weitere anwendungsspezifische Kontrollen. Trotzdem zeigt es bereits einige wesentliche Unterschiede zu einer nachlässigen Umsetzung, denn die Eingabe wird zunächst auf ihren erwarteten Typ geprüft. Anschließend werden leere oder übermäßig lange Suchbegriffe zurückgewiesen. Die Datenbankabfrage wird vorbereitet und der Suchbegriff wird als Parameter übergeben, statt ihn unmittelbar in die SQL-Syntax einzubauen. Die Ausgabe wird wiederum mit htmlspecialchars() für den HTML-Kontext behandelt, damit vom Benutzer oder aus der Datenbank stammende Zeichen nicht unbeabsichtigt als HTML interpretiert werden.

Das sind jetzt natürlich unterschiedliche Schutzmaßnahmen gegen unterschiedliche Problemklassen, denn die parametrisierte Datenbankabfrage schützt die Struktur der SQL-Abfrage und die HTML-Kodierung schützt den Ausgabekontext. Die Eingabeprüfung reduziert zudem unerwartete Zustände und begrenzt den Umfang der Verarbeitung. Keine dieser Maßnahmen repariert natürlich eine verwundbare PHP-Laufzeitumgebung, aber sie verhindern, dass die Anwendung zusätzlich eigene, vermeidbare Schwachstellen eröffnet. Genau diese Trennung wird in der Praxis erstaunlich häufig übersehen. Leider. Und dann kommt die Angst…

Viele Sicherheitsprobleme entstehen nicht durch ein einfaches Textfeld, sondern dadurch, dass eine Anwendung Benutzereingaben an besonders empfindliche Funktionen weiterreicht. Dazu gehören dynamische Dateipfade, frei zusammensetzbare SQL-Abfragen, Betriebssystemkommandos, unkontrollierte Deserialisierung und in bestimmten Zusammenhängen auch die dynamische Einbindung von PHP-Dateien. Besonders problematisch ist es dann, wenn eine Anwendung Eingaben nicht als Daten behandelt, sondern daraus entscheidet, welcher Code ausgeführt werden soll. 

Ein häufiger Fehler in individuell entwickelten Systemen ist beispielsweise eine dynamische Dateieinbindung, bei der ein vom Benutzer gelieferter Wert unmittelbar zur Auswahl einer PHP-Datei verwendet wird.

Stattdessen sollte die Anwendung nur ausdrücklich vorgesehene Seiten zulassen, nur sind diese programmiertechnischen Basics in den letzten Jahre leider immer weiter aus den Augen verloren worden:

<?php
declare(strict_types=1);

$allowedPages = [
    'home'    => __DIR__ . '/pages/home.php',
    'contact' => __DIR__ . '/pages/contact.php',
    'about'   => __DIR__ . '/pages/about.php'
];

$page = $_GET['page'] ?? 'home';

if (
    !is_string($page) ||
    !array_key_exists($page, $allowedPages)
) {
    http_response_code(404);
    exit('Seite nicht gefunden');
}

require $allowedPages[$page];

Der entscheidende Unterschied besteht darin, dass der Besucher keine beliebigen Dateipfade übergeben kann. Er wählt lediglich einen bekannten Bezeichner, den die Anwendung intern auf eine fest hinterlegte Datei abbildet. Das ist in aller Regel sicherer als der Versuch, beliebige Pfadangaben nachträglich mit immer umfangreicheren Zeichenfiltern zu entschärfen, denn Sicherheitsprobleme lassen sich besonders zuverlässig vermeiden, wenn man gefährliche Zustände konstruktiv von vornherei ausschließt, statt sie später mit einer wachsenden Sammlung von Sonderfällen erkennen zu wollen. Daraus folgt allerdings nicht, dass eine solche Whitelist allein jede Anwendung sicher macht. Auch die eingebundenen Dateien müssen sicher implementiert sein und vor dem Zugriff auf geschützte Funktionen bleiben Authentifizierung und Berechtigungsprüfungen notwendig. Aber es ist schon mal ein Anfang.

Ein großer Teil sicherer Webentwicklung besteht natürlich nicht darin, möglichst viele Sicherheitsfilter zu programmieren sondern er besteht zunächst erst einmal darin, die Zahl der Stellen zu reduzieren, an denen gefährliche Operationen überhaupt möglich sind. Ein gut aufgebautes System trennt HTTP-Eingaben von der Geschäftslogik, Datenbankzugriffe von der Ausgabe und administrative Funktionen von öffentlich erreichbaren Endpunkten und jede Komponente erhält nur die Berechtigungen, die sie tatsächlich benötigt. Datei-Uploads landen nicht einfach in einem beliebigen ausführbaren Verzeichnis, Datenbankkonten besitzen keine unnötigen administrativen Rechte und temporäre Dateien sind nicht unkontrolliert öffentlich zugänglich. Besonders empfindliche Aktionen verlangen nun einmal eine nachvollziehbare Berechtigungsprüfung. Bei WordPress kommt die Besonderheit hinzu, dass das Gesamtsystem aus Core, Theme und zahlreichen Plugins besteht. Jede Erweiterung kann eigene AJAX-Aktionen, REST-Endpunkte, Upload-Verarbeitungen und Datenbankoperationen bereitstellen.

Ein aktueller WordPress-Core schützt deshalb nicht automatisch vor einem schlecht programmierten Plugin.

Dasselbe Prinzip gilt für XenForo und dessen Erweiterungen. Und genau deshalb habe ich fast alle Fremd-Plugins rausgeworfen und Schritt für Schritt gegen eigene Lösungen ersetzt, die unter der Prämisse Safetity first entwickelt wurden, denn die Qualität einer Webanwendung bestimmt sich am Ende nicht nach der Zahl ihrer Funktionen und Features, sondern nach der Gesamtheit ihrer erreichbaren Verarbeitungspfade und deren Absicherung. 

Ein einziges schlecht geschütztes Eingabefeld kann mehr Schaden anrichten als hundert korrekt konfigurierte Firewall-Regeln verhindern können.

Genau hier schließt sich dann auch wieder der Kreis zum aktuellen PHP-Problem, denn um überhaupt schaden anrichten zu können, müssen Schwachstellen erst einmal zugänglich sein. Allerdings schrieb ich ja auch über die Differenzierung zwischen einfachem Zugriff und professioneller Schwachstellenausnutzung, doch darauf komme ich gleich noch einmal zurück.

An dieser Stelle muss man auch über die zunehmende KI-gestützte Softwareentwicklung sprechen und ernsthafte Grenzen definieren. Ich nutze KI selbst intensiv bei der Entwicklung eigener Werkzeuge und Erweiterungen und gerade deshalb halte ich es für gefährlich, aus der beeindruckenden Geschwindigkeit moderner Codegeneratoren auf eine ebenso beeindruckende Zuverlässigkeit zu schließen. Eine KI kann innerhalb weniger Sekunden PHP-Code erzeugen, für den ein Entwickler früher deutlich länger gebraucht hätte. Das Ergebnis kann syntaktisch korrekt sein, auf Anhieb funktionieren und trotzdem grundlegende Sicherheitsprobleme enthalten.

Besonders kritisch wird es aber, wenn der Anwender selbst kaum oder gar nicht versteht, was der erzeugte Code eigentlich tut.

Dann wird aus einer fehlerhaften Implementierung schnell ein scheinbar fertiges Produkt, weil die sichtbare Funktion stimmt. Das Formular nimmt brav die Eingaben entgegen, die Datenbank liefert nette Ergebnisse, die Administrationsoberfläche speichert ihre Einstellungen und die Webseite zeigt dann die erwarteten Inhalte an. Ob sich mit manipulierten Eingaben Berechtigungsgrenzen umgehen lassen, ob ein REST-Endpunkt ohne ausreichende Authentifizierung erreichbar ist oder ob eine dynamische Dateiverarbeitung unerwartete Pfade akzeptiert, bleibt dabei unter Umständen völlig ungeprüft. Wie auch, wenn man als Vibe-Coder noch nicht einmal den generierten Code kapiert. Und genau darin liegt eine der großen Schwächen des sogenannten Vibe-Codings: Es verlagert einen erheblichen Teil der Entwicklungsarbeit auf ein System, das zwar plausiblen Code erzeugen kann, aber die Verantwortung für dessen sicheren Betrieb nicht übernimmt. Im Zweifellswar waren dann Claude oder ChatGPT schuld, nur dass die weder auf der Lohnliste stehen, noch in Haftung genommen werden können.

Das Problem ist natürlich  nicht die KI allein. Ein unerfahrener menschlicher Programmierer kann nämlich dieselben Fehler machen, Hauptsache schnell fertig. Die KI spart Tokens, der eilige Mensch die fünfte Tasse Kaffee. Der Unterschied besteht in der Geschwindigkeit und der Menge, mit der heute funktional überzeugender, aber unzureichend geprüfter Code entsteht und das ist wirklich erschreckend. Wer früher in einer Woche eine problematische Erweiterung geschrieben hat, kann heute unter Umständen zehn davon produzieren. Deshalb gehören Sicherheitsprüfungen bereits in den Entwicklungsprozess und nicht erst in die hektische Schadensbegrenzung nach der Veröffentlichung. Das bedeutet dann aber auch, dass KI-generierter Code grundsätzlich denselben Prüfungen unterliegen sollte wie jeder andere Code: Berechtigungen, Eingabeverarbeitung, Datenbankzugriffe, Dateisystemoperationen, Fehlerbehandlung, Abhängigkeiten und die Frage, welche Funktionen tatsächlich öffentlich erreichbar sind. Ein bestandener Funktionstest ist eben noch kein bestandener Sicherheitstest und leider endet die Prüfung neuer Software vor der  Frage nach deren Sicherheit. Läuft? Ok, dann weiter zur nächsten Aufgabe…

Wer eine KI nur so lange korrigieren lässt, bis keine Fehlermeldung mehr erscheint, hat damit möglicherweise ein Programm fertiggestellt, aber noch lange kein sicheres.

Die Diskussion um PHP2Shell hat meines Erachtens auch eine unangenehme Nebenwirkung offengelegt: Manche Akteure entdeckten die Bedeutung grundlegender Sicherheitsmaßnahmen offenbar erst in dem Moment, als eine neue kritische Schwachstelle öffentlich diskutiert wurde. Plötzlich wurden Konfigurationen hinterfragt, PHP-Versionen geprüft, Firewall-Regeln eingerichtet und administrative Endpunkte gesperrt, die teilweise schon lange vorher hätten abgesichert sein müssen. Grundsätzlich ist daran ja nichts auszusetzen und besser eine verspätete Verbesserung als gar keine. Problematisch wird es allerdings dann, wenn diese Maßnahmen ohne ausreichende Bestandsaufnahme und ohne Verständnis ihrer Auswirkungen erfolgen. Dann werden Funktionen abgeschaltet, weil sie theoretisch gefährlich sein könnten. Ganze Webseiten verschwinden vorsorglich vom Netz, obwohl die konkrete Angreifbarkeit möglicherweise noch gar nicht geprüft wurde. Andernorts wird eine neue Firewall-Regel als vollständige Lösung präsentiert, obwohl der eigentliche Fehler weiterhin in der Laufzeitumgebung existiert. Beides ist keine besonders überzeugende Sicherheitsstrategie sondern ein Eingeständnis der eigenen Unfähigkeit.

Wer aus einer plötzlich bekannt gewordenen Schwachstelle die Notwendigkeit ableitet, längst überfällige Wartungsarbeiten nachzuholen, sollte das ruhig tun, er muss es sogar. Nur sollte man das Ganze dann nur nicht mit einer besonders vorausschauenden Sicherheitsarchitektur verwechseln, denn diese besteht schließlich nicht darin, alle paar Monate auf den nächsten Alarm zu reagieren. Sie ermöglicht es bereits vorher zu wissen, welche Systeme betrieben werden, welche Komponenten davon abhängen, welche Angriffsflächen öffentlich erreichbar sind und welche Maßnahmen im Ernstfall tatsächlich helfen. Dazu gehört natürlich am Ende auch ein geordneter Patchprozess mit klaren Zuständigkeiten, nur sollte vorher schon eine Menge passsiert sein. Ein Managed-Hosting-Kunde wie ich muss sich darauf verlassen können, dass sein Anbieter sicherheitsrelevante Änderungen zeitnah und nachvollziehbar bereitstellt, aber gleichzeitig muss ich als Kunde meine Anwendungen so betreiben, dass ein Fehler in einer einzelnen Komponente nicht unmittelbar die gesamte Umgebung kompromittiert. Das ist übrigens keine neue Erkenntnis, nein, sie wird nur bei jedem größeren Sicherheitsvorfall erstaunlich zuverlässig wiederentdeckt. 😀

Eine der schwierigsten Entscheidungen während eines Sicherheitsvorfalls betrifft das Verhältnis zwischen Verfügbarkeit und Schutz. Aus der Perspektive eines Sicherheitsverantwortlichen kann eine sofortige Abschaltung zunächst attraktiv erscheinen. Ein nicht erreichbarer Dienst kann über seine abgeschalteten Schnittstellen schließlich auch nicht weiter angegriffen werden und das Ganze ist zudem auch reichlich bequem. Diese Logik ist allerdings nur dann vollständig, wenn man die Folgen einer Abschaltung ignoriert. Für eine Medien-Webseite, einen Shop oder eine andere öffentlich erreichbare Plattform ist Verfügbarkeit keine nebensächliche Komfortfunktion, denn sie gehört zu den zentralen Eigenschaften des Dienstes. Eine vollständige Abschaltung bedeutet möglicherweise wirtschaftlichen Schaden, unterbrochene Geschäftsprozesse oder den Verlust einer wichtigen Informationsquelle und genau deshalb muss das Verhältnis zwischen Eintrittswahrscheinlichkeit, Schadenshöhe und Wirksamkeit der verfügbaren Gegenmaßnahmen beurteilt werden.

Wenn ein Angriff ohne besondere Voraussetzungen zuverlässig zur vollständigen Übernahme eines Systems führt und keine wirksame Zwischenmaßnahme verfügbar ist, kann eine Abschaltung selbstverständlich notwendig sein.

Wenn dagegen eine konkrete Angriffsmöglichkeit noch nicht bestätigt ist, mehrere Schutzschichten greifen und kurzfristig ein Herstellerpatch erwartet wird, kann der kontrollierte Weiterbetrieb, so wie bei mir, völlig angemessen sein. Dazwischen liegen zahlreiche Möglichkeiten: die temporäre Sperrung einzelner Funktionen, die Einschränkung bestimmter Eingabepfade, eine strengere Zugriffskontrolle oder das Deaktivieren besonders gefährdeter Erweiterungen. Entscheidend ist, dass die Maßnahme zur tatsächlichen Gefahr passt. Ein pauschales Herunterfahren sämtlicher PHP-Anwendungen mag besonders konsequent aussehen., aber es ist definitiv kein Ersatz für die technische Frage, welche Systeme überhaupt unter welchen Voraussetzungen angreifbar sind.

Ein weiterer Punkt wird in der öffentlichen Diskussion gerne vernachlässigt: Die Installation eines Sicherheitsupdates beendet zunächst die Verwundbarkeit, die durch dieses Update tatsächlich behoben wird, aber sie beweist nicht, dass ein System zuvor unberührt geblieben ist. Gerade bei schwerwiegenden Sicherheitslücken gehört deshalb eine angemessene Nachkontrolle dazu. Dabei sind die Zeiträume vor und nach der Veröffentlichung der Schwachstelle besonders interessant. Auffällige Häufungen bestimmter Fehlermeldungen, ungewöhnliche PHP-FPM-Prozessneustarts, unerklärliche Änderungen an Dateien oder neue administrative Konten können Hinweise liefern, die näher untersucht werden sollten. Auch ausgehende Netzwerkverbindungen und ungewöhnliche Datenbankzugriffe verdienen Aufmerksamkeit, sofern entsprechende Protokolle vorhanden sind, allerdings sind solche Beobachtungen zunächst Indizien und keine Beweise.

Ein einzelner PHP-FPM-Absturz kann zahlreiche harmlose Ursachen haben. Eine ungewöhnliche HTTP-Anfrage ist noch keine erfolgreiche Kompromittierung. Selbst das wiederholte Ansprechen einer bestimmten URL beweist zunächst nur einen Versuch oder eine auffällige Nutzung, nicht dessen Erfolg. Umgekehrt schließt das Fehlen offensichtlicher Anzeichen einen erfolgreichen Angriff nicht mit Sicherheit aus, besonders dann nicht, wenn Protokolle unvollständig sind oder nur kurze Zeit aufbewahrt werden.Deshalb ist eine nüchterne forensische Bewertung sinnvoller als die ebenso bequeme wie unbegründete Aussage, man habe keine Auffälligkeiten gesehen und sei folglich sicher.

Eine solche Nachkontrolle ist übrigens nicht erst seit PHP2Shell eine gute Idee. Sie sollte bei öffentlich erreichbaren Systemen zum regulären Betrieb gehören.

Die eigentliche Lehre aus dem Vorfall liegt für mich weniger darin, dass auch eine weit verbreitete Laufzeitumgebung einen kritischen Fehler enthalten kann, denn das ist nun wahrlich keine Überraschung. Komplexe Software wird von Menschen (oder zunehmend der KI) entwickelt, ständig erweitert und unter immer neuen Bedingungen eingesetzt. Fehler lassen sich reduzieren, aber nicht vollständig ausschließen. Interessanter ist dann aber, wie unterschiedlich die Betreiber auf dieselbe Ausgangssituation reagieren. Gut gewartete Systeme verfügen über aktuelle Komponenten, nachvollziehbare Zuständigkeiten, möglichst geringe Berechtigungen und eine zumindest grundlegende Überwachung. Sie sind dadurch nicht unangreifbar, können aber Risiken besser begrenzen. Anders sieht es jedoch bei historisch gewachsenen Installationen aus, deren tatsächliche Abhängigkeiten niemand mehr vollständig kennt. Dort kann bereits ein reguläres PHP-Update zum Problem werden, weil irgendeine längst vergessene Erweiterung nur mit einer bestimmten Version funktioniert. Sicherheitsmaßnahmen werden verschoben, weil ihr Einbau unbequem ist. Kritische Funktionen bleiben erreichbar, weil sie irgendwann einmal benötigt wurden. 

Und wenn schließlich eine neue Schwachstelle öffentlich wird, muss in kürzester Zeit nachgeholt werden, was sich über Jahre angesammelt hat. Genau dort entsteht ein großer Teil des vermeidbaren Risikos, vor allem auch dann, wenn Personalwechsel individuelles Wissen der Verfügbarkeit entziehen. Kollege weg, unkommentiertes Chaos in den Scripten und keinerlei saubere Dokumentationen sind der Sargnagel jelkicher IT-Struktur. PHP2Shell ist deshalb auch ein Anlass, über technische Schulden nachzudenken. Denn veraltete Komponenten, unzureichend dokumentierte Abhängigkeiten und fehlende Prüfprozesse sind keine abstrakten Managementprobleme. Sie können im Ernstfall unmittelbar die Sicherheit und Verfügbarkeit eines Systems beeinträchtigen und ganze Firmen galant hinrichten.

Die Antwort liegt, wie so häufig bei Sicherheitsfragen, zwischen den beiden Extremen. Von einem bloßen Sturm im Wasserglas würde ich definitiv nicht sprechen. Eine potenziell schwerwiegende Schwachstelle in einer der verbreitetsten Weblaufzeitumgebungen verdient definitiv Aufmerksamkeit, schnelle Sicherheitsupdates und eine gründliche Untersuchung der tatsächlich betroffenen Systeme. Gleichzeitig wäre es aber auch falsch, jede verwundbare Installation pauschal als bereits kompromittiert oder unmittelbar übernehmbar darzustellen. Ein relativ einfach erreichbarer Ausfall einzelner Worker, eine daraus unter bestimmten Bedingungen entstehende Dienststörung und eine technisch anspruchsvolle Kompromittierung mit weitergehenden Berechtigungen sind grundverschiedene Risiken und sie unterscheiden sich hinsichtlich der erforderlichen Fähigkeiten des Angreifers, der Voraussetzungen, der Zuverlässigkeit und vor allem der möglichen Folgen. 

Die Bedeutung einer Sicherheitslücke ergibt sich deshalb nicht allein aus dem denkbar schlimmsten Ergebnis, sondern auch daraus, unter welchen realistischen Bedingungen dieses Ergebnis erreicht werden kann.

Für igor’sLAB habe ich mich unter den gegebenen Umständen für einen kontrollierten Weiterbetrieb entschieden, mit präventiven Maßnahmen auf Anwendungsebene und vorgeschalteten Cloudflare-Regeln, während die notwendigen Korrekturen bei Hetzner noch ausstanden. Ich halte diese Abwägung angesichts der mir zu diesem Zeitpunkt bekannten Situation weiterhin für vertretbar. Daraus folgt allerdings weder eine Garantie, dass sämtliche Angriffswege ausgeschlossen waren, noch eine allgemeine Empfehlung für andere Betreibe, denn jede Infrastruktur besitzt andere Voraussetzungen, andere Schutzmechanismen und andere Risiken.

Was mir an der gesamten Angelegenheit besonders aufgefallen ist, war deshalb weniger die bloße Existenz einer schwerwiegenden Schwachstelle als der Umgang damit. Zwischen sachlicher Gefahrenanalyse, notwendiger Vorsicht und demonstrativem Aktionismus lagen teilweise Welten. Sicherheit ist keine Frage der Lautstärke, mit der man vor einer Gefahr warnt sondern sie ist eine Frage der technischen Substanz der eigenen Maßnahmen. Und manchmal verrät die Hektik, mit der ein Problem plötzlich bekämpft wird, auch etwas darüber, wie lange man es sich zuvor bequem gemacht hat. 

PHP2Shell sollte weder verharmlost noch zum universellen Beweis für die Unsicherheit des gesamten Internets erklärt werden, denn ein Sicherheitsvorfall dieser Größenordnung ist ein ernst zu nehmender Anlass, die eigenen Systeme zu überprüfen, Updates zeitnah einzuspielen und die Grenzen der bestehenden Schutzmaßnahmen zu verstehen. Er ist aber kein Freibrief dafür, technische Unterschiede zu ignorieren, jede theoretische Angriffsmöglichkeit als praktisch bestätigte Katastrophe darzustellen oder durch unüberlegte Abschaltungen zusätzlichen Schaden zu verursachen. Besonders nachdenklich stimmt mich dabei die Entwicklung der Softwareproduktion selbst. Wir können heute mit KI-Unterstützung in erstaunlicher Geschwindigkeit Programme erzeugen, die auf den ersten Blick hervorragend funktionieren. Aber Softwarequalität besteht nicht nur darin, dass ein Programm das Richtige tut. Sie besteht ebenso darin, dass es unter fehlerhaften, manipulierten und unerwarteten Bedingungen möglichst nichts Falsches tut. Genau diese zweite Hälfte wird beim schnellen Entwickeln gerne vergessen.

Ein funktionierendes Programm ist noch kein sicheres Programm. Und ein gepatchter Server ist noch keine sichere Infrastruktur.

Wenn PHP2Shell dazu beiträgt, dass sich diese Erkenntnis wieder stärker durchsetzt, hätte die ganze Aufregung wenigstens einen nachhaltigen Nutzen, denn das größte Risiko für das Internet ist häufig nicht die eine neu entdeckte Sicherheitslücke. Es ist die bequeme Gewissheit, dass bisher ja immer alles funktioniert hat.