MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

PHP2Shell

Ich war durch PHP2Shell nicht direkt betroffen, weil meine Webhoster der MSXFAQ das erforderliche Update schnell installiert haben und die MSXFAQ komplett mit statisch generierten HTML-Seiten und damit ohne PHP auskommt. Aber natürlich gibt es PHP-Seiten und Produkte und ich war überrascht, wie viele Dienste in meinem Umfeld oder bei Kunden davon abhängen´.

Angriffsvektor vereinfacht beschrieben

Sicher nicht, denn PHP ist nun mal die dominante Skriptsprache für Webseiten aber zum Teil auch lokale Skripte. VBScript und ASP sind ja nicht zu unrecht abgekündigt oder verbrannt. Diesmal war es ja auch kein Fehler in der PHP-Skript-Sprache selbst, sondern im ausführenden Interpreter, der bei einem provozierten PHP-Fehler den Speicher des abgestürzten Prozesses nicht sauber bereinigt und beim nächten Request wohl wieder ausgeführt hat. Ein Angreifer hat also einen vorbereitenden HTTP-Request und dann einen ausnutzenden HTTP-Request senden. Meist braucht es zudem viele Requests, bis gelingt. Auch die Funktion zum Upload von Dateien konnte derart ausgenutzt werden

Als schnelle Gegenmaßnahme konnten Administratoren entsprechende Grenzwerte reduzieren, z.B. maximale Größe von Uploads, und auch eine Web Application Firewall könnte über die die anfragenden URLs einen Teilschutz erreichen. Nachdem die Patches nun verfügbar sind, ist ein Update der richtige Weg.

Zeit ist Sicherheit

Angeblich wurde die PHP2Shell-Lücke durch eine KI (ChatGPT?) gefunden oder zumindest ein Angriff entwickelt und schon Wochen vorher an das PHP-Team gemeldet. Daher wurden auch schon sehr schnell die Patches verfügbar. Soweit ich gelesen habe, war eigentlich der 22. Okt 2026 als abgestimmter Veröffentlichungstermin geplant und die Patches wurden vorab wohl schon an ausgewählte Provider ausgeliefert. Allerdings wurde das Embargo vorher von jemandem gebrochen, so dass die Veröffentlichung dann am 21. Okt sehr schnell erfolgen musste.

Wer nun wann und warum in den erlauchten Kreis aufgenommen wurde, kann ich nicht nachvollziehen. Ich habe aber auch nichts vorab gelesen, dass der 22. Okt ein wichtiger Tag für PHP-Admins sein könnte. Vielleicht bin ich aber einfach nicht in den richtigen Verteilern.

Die meisten Provider haben wohl sehr schnell ihre Updates eingespielt. Ich habe aber auch gesehen, dass einige Hersteller und Hoster ihre Webseite vorsorglich offline genommen haben, bis sie die Patches installiert hatten. Es ist sicher einfacher den Server einige Stunden offline zu lassen anstatt später die Spuren eines erfolgreichen Angriffs zu sichten und zu beseitigen.

Vorbereitet sein

PHP2Shell wird sicher nicht die letzte Lücke sein. Schon in der Vergangenheit gab es ja Hafnium und im Sep/Okt 2026 haben auch Debian, Oracle und Windows jeweils Update-Pakete mit 1000+ Fixes veröffentlicht. Als verantwortliche Personen sollten wir uns daher vorbereiten.

  • Aktuelles Verzeichnis der Server und deren Komponenten
    Wenn wir die Information über eine kritische erhalten, müssen wir sofort wissen, welche Systeme betroffen sind. Ich habe Kunden erlebt, die erst ein paar Tage später bemerkt haben, das ein bislang unauffälliges System auch betroffen war. Angreifer im internen Netzwerk haben solche Informationen schon lange gesammelt
  • Abschaltung/Vorgehensweise abklären
    Wir sollten uns schon vorher die Erlaubnis einholen, bei kritischen Dingen notfalls auch einen Service "offline" zu nehmen. Ich habe einige Kunden erlebt, die erst am Tag drauf nach Freigabe durch den Vorstand das System patchen durften. Das geht nicht.
  • Status-Seite und Kommunikation
    Wenn Sie Dienst offline nehmen, sollten ihre Nutzer keine Fehlermeldung sondern einen Status bekommen. Vielleicht ist jetzt der Zeitpunkt eine externe Webseite bei einem ganz anderen Service und einer anderen Domain vorzuhalten, über welche Sie weiter kommunizieren können.
    Eine vorgeschaltete Web Application Firewall könnte auch eine passende Fehlerseite ausliefern. Vielleicht sollten Sie auch mal den TTL ihrer DNS-Einträge überprüfen, um ggfls. einen Service auf eine anderen Host zu ziehen.
  • Aktuelle Versionen
    Beim Hafnium Exploit hat sich Microsoft genötigt gefühlt auch für sehr viele und alte Versionen von Exchange einen Fix bereitzustellen. Auch für PHP wurden recht umfangreich die Updates bereitgestellt aber wir sollten uns immer bewusst sein, dass nicht alle Produkte so generös sein werden. Achten Sie darauf, dass ihre Systeme immer entsprechend aktuell sind.
    Dabei geht es nicht nur um komplette Programmpakete sondern teilweise einzelne DLLs. Vielleicht erinnern Sie sich noch an die "XZ-Lücke" (CVE-2024-3094), bei der eine kleine Library zur Komprimierung von Daten beinahe zu einer Hintertür auf sehr viele Server geworden wäre, da auch SSH dieses Modul genutzt hat.

Vielleicht ist nach Hafnium XZ-Lücke nun auch PHP2Shell ein weiterer Weckruf hier aktiv zu werden.

Technische Aspekte

Ich habe natürlich auch einige Webserver mit PHP am Start. Da meine ich nun nicht die Webseite hinter der MSXFAQ. Das ist ein "Managed Webhosting" und ich erwarte und bezahle dafür, dass der Provider das darunter liegende Betriebssystem und auch die Module wie MySQL, PHP, Mailserver, Zertifikate etc. für mich aktuell und sicher hält. Aber es gibt natürlich eigene Server und Appliances, die man als Firma noch umso mehr beachten muss:

  • Server (OS + PHP + Applikation)
    Bei einem klassischen Setup ist PHP einfach nur für alle Prozesse nutzbares Modul, welches von verschiedenen Applikationen genutzt wird. Ich kann als Administrator die Version einfach aktualisieren und alles sollte weiter laufen. Das ist aber nicht immer so einfach, denn die verschiedenen Applikationen könnten Versionsabhängigkeiten haben. Wir müssen hier aber zwischen einem Security Updates und einem Versionsupdate unterscheiden. Die Patches für PHP2Shell hat ja die Version nicht grundlegend verändert.
  • Appliances
    Anders sieht es bei so genannten Appliances aus, die als Komplettlösung kommen. Dazu zähle ich NAS-Systeme (bei mir Synology) aber auch Firewalls, Spamfilter, Loadbalancer, Router u.a., die PHP z.B. oft für die Verwaltungsoberfläche (AdminUI) verwenden. Hier kann man nur hoffen, dass der Hersteller schnell ist
  • Container (Docker u.a.)
    Beim Einsatz in Containern ist die PHP-Funktion meist Bestandteil des Containers und nicht des darunter liegenden  Betriebssystem. Das bedeutet, dass wir jeder Docker-Container selbst aktualisieren müssten. Das widerspricht aber der Idee von Containern, bei denen die Daten und Code idealerweise getrennt sind und einfach ausgetauscht werden. Der Maintainer sollte daher möglichst schnell seine Container neu bauen und der Nutzer dann die aktualisierte Version herunterladen und starten.

Der Erfolg und die Zuverlässigkeit ihrer Aktionen stehen und fallen mit Vollständigkeit. Damit kommen wir wieder zum Ausgangspunkt, das wir nicht nur Desktops inventarisieren dürfen, sondern auch ein Inventar über alle Dienste und Produkte auf Servern und Services zeitnah ermittelt werden.

Weitere Links