PHP2Shell – begrenzen Sie, was ein kompromittierter Server erreichen kann

Bei PHP2Shell wurden Angriffsversuche beobachtet, bevor die Schwachstellen öffentlich bekannt waren und bevor ein Patch bereitstand. Das zeigt, warum allein die Geschwindigkeit des Patchens nicht über das mögliche Schadensausmaß entscheidet: Ein kompromittierter Webserver ist besonders gefährlich, wenn seine Zugangsdaten weitreichende Rechte eröffnen.

Ein kompromittierter PHP-⁠Prozess kann mehr preisgeben als seine Dateien

Codeausführung auf einem Server ist nicht automatisch gleichbedeutend mit Zugriff auf die gesamte Unternehmensumgebung. Entscheidend ist, welche Ressourcen der kompromittierte Prozess erreichen darf. PHP-⁠Anwendungen können beispielsweise Umgebungsvariablen und Konfigurationsdateien lesen, in denen Zugangsdaten für Cloud-⁠Dienste oder andere Systeme liegen. Auch Arbeitsspeicher von PHP-⁠Prozessen kann Passwörter, Tokens oder API-⁠Schlüssel enthalten.

Damit wird aus einer Schwachstelle in einer Webanwendung unter Umständen ein Zugang zu weiteren Diensten. Das Risiko entsteht nicht nur im anfälligen Prozess selbst, sondern auch durch die Berechtigungen und Geheimnisse, die ihm zur Verfügung stehen. Ein Server mit eng begrenzten Rechten kann den Schaden begrenzen. Ein Dienstkonto mit Zugriff auf viele Systeme macht denselben Einstieg deutlich folgenreicher.

Das ist keine Begründung, Updates aufzuschieben. Ein erfolgreicher Angriff bleibt ein Sicherheitsvorfall. Die Reichweite seiner Folgen hängt aber auch davon ab, wie viel ein Angreifer nach der ersten Ausführung erreichen kann.

Ein CVSS-⁠Wert zeigt nicht die Reichweite im eigenen Netz

CVSS-⁠Werte helfen dabei, Schwachstellen nach technischen Merkmalen zu vergleichen. Sie zeigen jedoch nicht, welche Rechte der betroffene Server in Ihrer konkreten Umgebung besitzt, welche Zugangsdaten dort verfügbar sind oder welche Systeme diese Identitäten erreichen können.

Deshalb sollte die Priorisierung nicht beim höchsten Wert auf einer Liste enden. Ein technisch weniger auffälliger Zugang kann für ein Unternehmen dringlicher sein, wenn er weitreichende Berechtigungen besitzt. Umgekehrt kann eine schwerwiegende Schwachstelle auf einem System, dessen Identität kaum Zugriff auf andere Ressourcen hat, ein kleineres Folgeschadenspotenzial haben. Das ist kein Grund, die Schwachstelle zu ignorieren. Es ist ein Grund, technische Schwere und mögliche Reichweite getrennt zu betrachten.

Bei PHP2Shell ist diese Unterscheidung besonders praktisch: PHP steckt nicht nur in selbst verwalteten Webservern, sondern auch in Appliances und Hosting-⁠Kontrollsystemen. Bei solchen Komponenten können Betreiber den Patch möglicherweise nicht selbst einspielen. Die Kontrolle über die eigenen Dienstidentitäten bleibt dagegen eine eigene Aufgabe.

Dienstkonten und Schlüssel auf ihre Reichweite prüfen

Beginnen Sie bei den Identitäten, die von öffentlich erreichbaren Anwendungen und Servern verwendet werden. Dazu zählen Dienstkonten, API-⁠Schlüssel, Cloud-⁠Rollen und Tokens. Für jede Identität sollte klar sein, wer dafür verantwortlich ist und welche konkrete Aufgabe ihre Rechte erfordern.

Gehen Sie dabei gezielt vor:

• Ermitteln Sie, welche nicht-⁠menschlichen Identitäten Anwendungen und Server verwenden.
• Prüfen Sie, auf welche Systeme und Daten jede Identität zugreifen kann.
• Begrenzen Sie Berechtigungen auf den Zweck des jeweiligen Dienstes.
• Entfernen Sie nicht mehr benötigte Zugangsdaten und Zugriffe.
• Ordnen Sie jeder Identität eine verantwortliche Person oder Stelle zu.

Bei KI-⁠Agenten gilt dieselbe Prüfung. Ein Agent sollte keine pauschalen Rechte erhalten, nur weil sie die Einrichtung erleichtern. Seine Zugriffe müssen zu seinem konkreten Auftrag passen. Das gilt auch dann, wenn ein Agent von einer Anwendung aus gestartet wird: Die Anwendung und der Agent dürfen nicht stillschweigend zum gemeinsamen Generalschlüssel werden.

Updates und Begrenzung des Schadens gehören zusammen

Die Schwachstelle zu beheben bleibt notwendig. Wo PHP von einem Hersteller oder Anbieter innerhalb einer Appliance bereitgestellt wird, muss der zuständige Updateweg geklärt sein. Für nicht mehr unterstützte PHP-⁠Zweige ist ein Wechsel auf eine unterstützte Version der richtige Weg; auf einen nicht verfügbaren offiziellen Patch zu warten, behebt das Problem nicht.

Parallel sollten Sie prüfen, welche Geheimnisse ein kompromittierter Dienst erreichen könnte. Werden Zugangsdaten in Konfigurationsdateien oder Umgebungsvariablen abgelegt, braucht der Zugriff darauf eine klare Begrenzung. Lassen sich sensible Schlüssel ersetzen oder widerrufen, sollte außerdem feststehen, wer dies im Vorfall veranlasst.

PHP2Shell macht den Wettlauf zwischen Angriff und Patch sichtbar. Für die eigene Risikobewertung zählt deshalb beides: die Schwachstelle schließen und die Rechte der betroffenen Systeme so begrenzen, dass ein erfolgreicher Einstieg nicht automatisch weitere Türen öffnet.

Quellen: BleepingComputer, „Even after PHP2Shell, blast radius matters more than a CVSS score“ — https://www.bleepingcomputer.com/news/security/even-after-php2shell-blast-radius-matters-more-than-a-cvss-score/