PHP-RCE: Millionen Angriffsversuche kurz nach Veröffentlichung

Die gestern veröffentlichten kritischen PHP-Sicherheitslücken entwickeln sich offenbar sehr schnell zu einem echten Problem im Netz.
Nach Angaben von Cloudflare ist die Zahl der Angriffsversuche innerhalb weniger Stunden massiv gestiegen. Während vor der öffentlichen Bekanntgabe zunächst nur einige tausend Versuche beobachtet wurden, waren es kurz danach bereits Zehntausende und später Hunderttausende.
Inzwischen spricht Cloudflare von Millionen Exploit-Versuchen.
Wer einen öffentlich erreichbaren PHP-Server betreibt und noch nicht aktualisiert hat, sollte das Thema deshalb nicht mehr auf die lange Bank schieben.
Angreifer haben sehr schnell reagiert
Laut Matthew Prince, CEO von Cloudflare, begann die Aktivität bereits vor der vollständigen öffentlichen Bekanntgabe der Schwachstellen.
In den rund zehn Stunden davor wurden bereits tausende Versuche registriert.
Nach Veröffentlichung der technischen Informationen beschleunigte sich das Ganze deutlich:
nach etwa 45 Minuten: Zehntausende Versuche
nach ungefähr zwei Stunden: Hunderttausende
wenige Stunden später: Millionen Angriffsversuche
Das zeigt ziemlich deutlich, wie wenig Zeit Administratoren bei kritischen Sicherheitslücken inzwischen bleibt.
Früher konnte man vielleicht noch hoffen, ein Update „morgen früh“ einzuspielen.
Bei öffentlich bekannten RCE-Lücken ist „morgen früh“ inzwischen teilweise schon ziemlich spät.
Zwei kritische PHP-Lücken mit CVSS 9,2
Auslöser sind zwei kritische Schwachstellen in PHP, die mit CVSS 9,2 von 10 Punkten bewertet wurden.
Sie ermöglichen unter bestimmten Voraussetzungen eine Remote Code Execution ohne vorherige Anmeldung.
Das bedeutet vereinfacht:
Ein Angreifer kann unter passenden Bedingungen aus der Ferne Code auf einem verwundbaren System ausführen, ohne zuvor ein gültiges Benutzerkonto besitzen zu müssen.
Genau diese Kombination macht die Sicherheitslücken so problematisch.
Exploit-Versuch bedeutet nicht automatisch erfolgreicher Angriff
Bei den genannten Millionen Zahlen ist allerdings eine wichtige Unterscheidung nötig.
Cloudflare spricht von Versuchen, die Schwachstellen auszunutzen.
Das bedeutet nicht automatisch, dass Millionen Server erfolgreich kompromittiert wurden.
Ein erheblicher Teil solcher Angriffe besteht normalerweise aus automatisierten Scans und Exploit-Versuchen, die sehr große Bereiche des Internets abklopfen.
Treffen diese Anfragen auf bereits aktualisierte, geschützte oder nicht verwundbare Systeme, passiert im besten Fall gar nichts.
Die enorme Menge zeigt trotzdem, wie intensiv nach verwundbaren Servern gesucht wird.
Die sicheren PHP-Versionen stehen bereit
Für die unterstützten PHP-Zweige wurden bereits korrigierte Versionen veröffentlicht.
Aktualisiert werden sollte mindestens auf:
| PHP-Zweig | Sichere Version |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Wer eine dieser Versionen noch nicht einsetzt, sollte den Patchstand möglichst schnell kontrollieren.
Gerade bei Shared Hosting oder Managed Servern lohnt sich ein Blick in die Verwaltungsoberfläche beziehungsweise in die Informationen des Hostinganbieters.
PHP 8.1 und älter bekommen keinen Patch
Besonders wichtig ist die Situation bei älteren PHP-Versionen.
Für PHP 8.1 und ältere Versionen stehen laut den aktuellen Informationen keine regulären Sicherheitsupdates für diese Schwachstellen bereit.
Wer noch auf einer solchen Version arbeitet, kann das Problem also nicht einfach durch einen kleinen Patch innerhalb desselben Versionszweigs lösen.
Hier ist der Wechsel auf eine unterstützte PHP-Version notwendig.
Das kann je nach Webseite natürlich unangenehm werden.
Alte CMS-Versionen, Plugins oder selbst entwickelte Anwendungen vertragen einen größeren PHP-Sprung nicht immer ohne Weiteres.
Aus Sicherheitssicht ist eine dauerhaft ungepatchte PHP-Version aber ebenfalls keine besonders attraktive Lösung.
Britisches NCSC empfiehlt im Zweifel Abschalten
Die britische Sicherheitsbehörde NCSC fällt mit ihrer Empfehlung entsprechend deutlich aus.
Wenn ein betroffenes System nicht kurzfristig aktualisiert werden kann, sollte man laut Behörde in Betracht ziehen, die Webseite vorübergehend offline zu nehmen.
Das klingt drastisch.
Bei einer kritischen RCE-Lücke und Millionen automatisierten Exploit-Versuchen ist der Gedanke aber nachvollziehbar.
Ein paar Stunden Nichterreichbarkeit sind unangenehm.
Ein kompromittierter Webserver kann deutlich unangenehmer werden.
Google Cloud veröffentlicht ebenfalls Hinweise
Auch Google Cloud hat auf die Sicherheitslage reagiert.
Kunden sollen prüfen, welche Anwendungen und Dienste PHP verwenden und die betroffenen Systeme aktualisieren.
Welche konkreten Schritte notwendig sind, hängt dabei vom eingesetzten Google-Cloud-Dienst ab.
Das zeigt auch gut, dass ein PHP-Update nicht überall gleich aussieht.
Auf einem selbst verwalteten Linux-Server aktualisiert man möglicherweise direkt die entsprechenden Pakete.
In einer Cloud- oder Managed-Umgebung kann dagegen der Plattformbetreiber einen Teil der Arbeit übernehmen.
Linux-Systeme sollten ihre Paketupdates prüfen
Für viele Linux-Distributionen und LTS-Anbieter standen die notwendigen Patches bereits frühzeitig zur Verfügung.
Wer PHP über die Paketverwaltung seiner Distribution installiert hat, sollte deshalb nicht nur auf die PHP-Webseite schauen.
Je nach System kann das Sicherheitsupdate bereits über die normalen Paketquellen bereitstehen.
Ein klassischer Blick auf verfügbare Systemupdates ist daher durchaus sinnvoll.
Wichtig ist anschließend natürlich auch, zu kontrollieren, welche PHP-Version tatsächlich aktiv verwendet wird.
Ein installiertes Update hilft wenig, wenn der Webserver noch mit einer alten Runtime läuft.
Manche Webseiten gingen vorsorglich offline
Mehrere Webseiten und Hostinganbieter haben während der Aktualisierungsarbeiten Systeme zeitweise abgeschaltet.
Auch Neowin selbst war nach eigenen Angaben kurzzeitig nicht erreichbar, während die Infrastruktur aktualisiert wurde.
Das passt zu den Empfehlungen verschiedener Sicherheitsstellen.
Gerade wenn noch nicht klar ist, ob sämtliche Systeme bereits gepatcht sind, kann eine kontrollierte kurze Downtime die sicherere Variante sein.
Wir haben gestern bereits bei verschiedenen Hostinganbietern gesehen, dass genau solche Schutzmaßnahmen teilweise recht deutlich sichtbar werden können.
Warum die Angriffswelle so schnell kommt
Dass wenige Stunden nach Veröffentlichung bereits Millionen Versuche stattfinden, überrascht mich ehrlich gesagt nicht besonders.
Sobald genügend technische Informationen verfügbar sind, läuft vieles automatisiert.
Scanner suchen nach erreichbaren Servern.
Proof-of-Concept-Code wird angepasst.
Bots durchsuchen riesige IP-Bereiche.
Und irgendwann klopft derselbe Exploit an tausenden Systemen gleichzeitig an.
Das Internet wartet bei kritischen Sicherheitslücken leider nicht höflich darauf, bis jeder Administrator ausgeschlafen hat.
Was Webseitenbetreiber jetzt prüfen sollten
Wer einen eigenen PHP-Server betreibt, sollte zunächst die aktive PHP-Version kontrollieren.
Wichtig sind außerdem:
Betriebssystemupdates installieren
Webserver und PHP-Dienste gegebenenfalls neu starten
überprüfen, ob wirklich die gepatchte PHP-Version aktiv ist
Serverlogs auf ungewöhnliche Aktivitäten kontrollieren
Backups auf Aktualität prüfen
alte oder unnötige Dienste deaktivieren
Wer bei einem Hostinganbieter Kunde ist, sollte zusätzlich prüfen, welche Informationen der Provider zum aktuellen Patchstand veröffentlicht.
Nach dem Patch nicht einfach zur Tagesordnung übergehen
Wer einen Server erst nach Beginn der Angriffswelle aktualisiert hat, sollte nicht ausschließlich den Patch installieren und anschließend davon ausgehen, dass damit automatisch alles erledigt ist.
Wenn ein System eine Zeit lang öffentlich und verwundbar erreichbar war, lohnt sich zumindest ein Blick in die Logs.
Ungewöhnliche Prozesse, veränderte Dateien, neue Benutzer, auffällige Netzwerkverbindungen oder verdächtige Webserver-Aufrufe wären beispielsweise Gründe für eine genauere Untersuchung.
Ob tatsächlich ein erfolgreicher Angriff stattgefunden hat, lässt sich allein aus der Existenz der Schwachstelle natürlich nicht ableiten.
Aber bei einer aktiv gescannten RCE-Lücke würde ich zumindest hinschauen.
Die Lage zeigt, warum Vorwarnungen wichtig sind
Das PHP-Sicherheitsteam hatte die Veröffentlichung der kritischen Updates bereits vorher angekündigt.
Zu diesem Zeitpunkt waren die technischen Details noch nicht öffentlich.
Manche Administratoren dürften diese Zeit genutzt haben, um Wartungsfenster vorzubereiten und Backups zu prüfen.
Im Nachhinein zeigt sich ziemlich deutlich, warum solche Vorankündigungen sinnvoll sind.
Zwischen Veröffentlichung der Details und millionenfachen Exploit-Versuchen lagen offenbar nur wenige Stunden.
Viel Vorbereitungszeit bleibt dann nicht mehr.
Mein Eindruck
Die Geschwindigkeit ist eigentlich die wichtigste Nachricht an dieser Geschichte.
Nicht erst Tage oder Wochen nach Veröffentlichung tauchen erste automatisierte Angriffe auf.
Sie beginnen praktisch sofort.
Wer kritische Webinfrastruktur betreibt, muss deshalb inzwischen damit rechnen, dass öffentlich bekannte RCE-Lücken innerhalb kürzester Zeit breit gescannt werden.
Die gute Nachricht ist:
Die Patches sind vorhanden.
Damit gibt es zumindest bei unterstützten PHP-Versionen einen klaren Weg aus dem Problem.
Fazit
Nur wenige Stunden nach Veröffentlichung der kritischen PHP-Schwachstellen ist die Zahl der beobachteten Exploit-Versuche laut Cloudflare auf Millionen gestiegen.
Das bedeutet nicht, dass Millionen Server erfolgreich übernommen wurden.
Es zeigt aber sehr deutlich, dass Angreifer aktiv und automatisiert nach verwundbaren Systemen suchen.
Betreiber sollten mindestens folgende Versionen einsetzen:
PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35.
PHP 8.1 und ältere Versionen erhalten für diese Sicherheitslücken keinen regulären Patch und sollten auf einen unterstützten Zweig migriert werden.
Wer nicht kurzfristig aktualisieren kann, sollte entsprechend der Empfehlung des britischen NCSC sogar darüber nachdenken, die betroffene Webseite vorübergehend offline zu nehmen.
Bei dieser Sicherheitslage gilt deshalb ziemlich eindeutig:
Erst patchen, dann Kaffee. Nicht andersherum.
Quellen
Neowin:
Millions of PHP exploit attempts surge within hours of critical RCE vulnerability disclosure
https://www.neowin.net/news/millions-of-php-exploit-attempts-surge-within-hours-of-critical-rce-vulnerability-disclosure/
PHP – Downloads und Sicherheitsupdates:
https://www.php.net/downloads.php
UK National Cyber Security Centre – PHP Security Advisory:
https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php