PHP2Shell verständlich erklärt: was die PHP-Sicherheitslücke im Alltag bedeutet

MManfred

Am 23. Oktober wurde eine schwere Sicherheitslücke in PHP veröffentlicht. PHP ist eine Software, mit der viele Systeme im Internet betrieben werden - WordPress, viele Online-Shops, Buchungssysteme, Vereinswebsites. Die Sicherheitslücke trägt den Namen PHP2Shell und wurde mit 9,2 von 10 Punkten auf der Schweregradskala bewertet - so hoch wird nur eingestuft, was wirklich ernst ist.

Was die Lücke kann

Vereinfacht gesagt: Angreifer können auf einem verwundbaren Server beliebige Befehle ausführen - ohne Passwort, ohne dass irgendjemand auf einen Link klicken muss. Sie müssen die PHP-Instanz nur gezielt ansprechen, wie ein normaler Besucher. Sicherheits-Forscher haben aufgezeigt, dass unveränderte Standard-Installationen von WordPress, Drupal und Joomla und viele andere Lösungen betroffen sind.

Wenn man eine Webseite besucht, verarbeiten Server Anfragen in kurzen Arbeitsschritten. Durch die Lücke kann ein Angreifer diese Schritte so aus der Bahn werfen, dass der Server anschließend tut, was der Angreifer will - einschließlich des Mitlesens von Daten anderer Besucher, etwa Zugangsdaten, die gerade übertragen werden oder Daten, die auf dem Server gespeichert sind.

Was das für kleine Unternehmen bedeutet

Nehmen wir ein typisches Beispiel: ein Handwerksbetrieb mit einer WordPress-Website und einem Kontaktformular.

  • Kundendaten liegen offen. Namen, Adressen, Anfragen, Bestellungen - alles, was die Website speichert, ist erreichbar. Daraus wird schnell ein DSGVO-Problem: Datenpannen sind meldepflichtig, und „wir wussten nichts davon" ist keine Verteidigung, wenn der Patch schon Wochen verfügbar war.
  • Die Website arbeitet für den Angreifer. Übernommene Seiten werden benutzt, um Besucher mit Schadsoftware zu infizieren oder Phishing- Seiten unter dem eigenen Firmennamen zu betreiben. Der Imageschaden trifft den Betrieb, nicht den Angreifer.
  • Ein offenes Loch reicht. Unsere Dienste laufen in Docker- Containern - an sich abgeschlossenen Programmumgebungen, die sich denselben Server, aber nicht die gleiche Umgebung, teilen. Auf dem betroffenen System waren das rund fünfundsiebzig Container, aber nur acht davon enthielten PHP. Auf den ersten Blick mag das harmlos erscheinen, ist es aber nicht: Container, die im selben Netzwerk stehen, können sich untereinander „sehen". Wer in einen verwundbaren Container einbricht, steht schon im Flur - und findet dort typischerweise Zugangsdaten zu Datenbanken und anderen Diensten. Ein unscheinbares Nebenprojekt kann so zum Einfallstor in die Kundendatenbank werden.
  • Auch die Schutztechnik ist betroffen. Dieselbe Lücke steckt in Netzwerkgeräten wie Routern, Firewalls und NAS-Systemen - überall dort, wo eine Verwaltungsoberfläche oder Login-Seite über PHP betrieben wird. Ein konkretes Beispiel ist die pfSense-Firewall: Ihr Web-Interface läuft auf PHP, und ihr „Captive Portal" - die Anmeldeseite, die man etwa aus WLAN-Portalen in Hotels oder Firmen-Gästenetzen kennt - ist bewusst für Fremde erreichbar. Ein Werkzeug, das eigentlich nur dazu da ist, um Fremde fernzuhalten, wird so zum Eingangspunkt für Angreifer.
  • Auch die Analyse ist nicht einfach: Die Versionsnummer kann täuschen. Wer „PHP 8.3.6" installiert hat, ist nicht automatisch verwundbar - Linux-Distributionen bauen teilweise rückwirkend Sicherheitspatches in ältere Versionen ein. Und auch umgekehrt gilt: Einmal aktualisieren reicht nicht dauerhaft; auch die Programme drum herum (Container, Apps) müssen auf einem sicheren Stand sein.

Was wir bei WIT getan haben

Wir haben am selben Tag unsere Systeme durchgeprüft: Ein Programm (Piler, unser Mail-Archiv) bekam eine eigens bereitgestellte korrigierte Version da es noch keinen verfügbaren Fix im offiziellen Release gab. Andere Projekte waren da schneller: Firefly III z.B. war durch die Entwickler bereits gefixt und musste nur aktualisiert und neu gestartet werden. Zwei unwichtigere Dienste haben wir vorerst abgeschaltet, statt sie verwundbar laufen zu lassen, und werten noch aus, ob wir sie weiter einsetzen oder auf alternative Lösungen umsteigen. Ein manuelles Reparieren lohnt sich hier nicht.

Bei der Planung muss pragmatisch sein: Es lohnt sich nicht, jedes Programm selbst flicken zu wollen. Entscheidend ist, Software von Anbietern zu wählen, die in solchen Situationen schnell reagieren - denn damit übernimmt der Anbieter auch künftig die Verantwortung für rechtzeitige Fixes, und man bleibt langfristig geschützt. Ausserdem sollten Server so eingerichtet sein, dass ein erfolgreicher Angriff auf eine Komponente nicht automatisch andere Systeme gefährdet. Zusätzlich kann Geoblocking, das wir auf unseren Servern mit CrowdSec umsetzen, den Angriffsvektor ebenfalls begrenzen: Viele probende Zugriffe kommen aus Ländern, für die ein Zugriff auf die Websites und Plattformenunserer Kunden ohnehin nicht notwendig ist. Mit Geoblocking werden Angreifer aus Russland oder Indien schon ausgesperrt, bevor sie überhaupt nachsehen können, ob Sicherheitslücken vorhanden sind.

Was Website-Betreiber jetzt tun sollten

  1. Beim Hoster fragen, ob PHP aktualisiert wurde - bei gemanagtem Hosting ist das deren Aufgabe, aber Nachfragen schadet nie.
  2. Nach Updates Dienste wirklich neu starten - ein „Reload" reicht nicht; laufende Prozesse behalten den alten, verwundbaren Zustand.
  3. Nicht benötigte Dienste abschalten - was nicht läuft, kann nicht angegriffen werden.
  4. Gäste-WLAN und Verwaltungsoberflächen getrennt behandeln - ein WLAN-Portal für Kunden ist bewusst offen und verdient besondere Aufmerksamkeit.

Die ausführliche, technische Dokumentation mit Quellen hat unser Trurl (Spezialisten-KI) im Beitrag „PHP2Shell, oder: der Tag, an dem sich der Boden als der Bug entpuppte" mit Quellenangaben für die Recherche veröffentlicht.

Manfred Wisniewski ist der Inhaber von WIT. Das technisch ausführliche Original von diesem Beitrag wurde mit Unterstützung von den KI Modellen SWE-2, GPT-6 Astra and Claude Fable 5.1 recherchiert und mit Hilfe von KI aus dem Original ins Deutsche übertragen und vereinfacht.