PHP2Shell: Warum diesmal am helllichten Tag gepatcht wurde

Sicherheitslücken in PHP gibt es immer wieder. Meistens merkt davon niemand etwas, weil die Updates in der Nacht eingespielt sind, bevor die Angreifer loslegen. Bei PHP2Shell hat das nicht mehr gereicht. Was war diesmal anders?

Am 20. Oktober wurden zwei kritische Lücken in PHP bekannt, Spitzname PHP2Shell. Wer sie ausnutzt, kann auf einem fremden Webserver eigene Befehle ausführen, ohne sich anmelden zu müssen. Betroffen ist PHP selbst, nicht ein einzelnes Plugin oder Theme. Also praktisch jede WordPress-Website, jeder WooCommerce-Shop, jedes Joomla, Drupal oder Nextcloud. Rund sieben von zehn Websites laufen mit PHP.

Kritische Lücken sind an sich nichts Neues. Neu war, wie wenig Zeit diesmal zum Reagieren blieb.

Wie es bisher lief

Normalerweise läuft so etwas in einer festen Reihenfolge ab. Jemand findet eine Lücke und meldet sie still an die Entwickler. Die bauen einen Fix, ebenfalls still. Erst wenn das Update fertig ist, wird beides gleichzeitig veröffentlicht: die Beschreibung der Lücke und der Patch dazu. Fachleute nennen das koordinierte Offenlegung.

Ab diesem Moment beginnt ein Wettlauf. Die Angreifer müssen den Patch zuerst lesen, verstehen, was genau repariert wurde, und daraus einen funktionierenden Angriff bauen. Das braucht Zeit. In meiner Praxis hat diese Zeit fast immer gereicht: Das Update kam am Abend, in der Nacht war es auf den Servern, und am Morgen hat niemand etwas gemerkt.

Dieses Zeitfenster wird allerdings schon seit Jahren kleiner. Mandiant, die Sicherheitsforschung von Google, misst seit Jahren, wie lange es dauert, bis eine bekannte Lücke tatsächlich angegriffen wird. 2018 und 2019 waren es im Schnitt 63 Tage. 2021 und 2022 noch 32 Tage. Für 2023 kam Mandiant auf fünf Tage.

Was diesmal passiert ist

Bei PHP2Shell ist die feste Reihenfolge gekippt. Die Lücken waren seit August bekannt, gefunden von zwei Teams unabhängig voneinander. Die Veröffentlichung war für den 22. Oktober geplant. Doch am 20. Oktober tauchte auf Hacker News ein Beitrag auf, der die Sache vorzeitig ausplauderte. Er wurde gelöscht, die Screenshots waren aber längst unterwegs.

Ab da ging es Schlag auf Schlag, hier in Schweizer Zeit:

• 20. Oktober: Die Lücken sind öffentlich bekannt, aber es gibt noch keinen Patch. Das PHP-Team zieht das Update um einen Tag vor.
• 21. Oktober, 9.34 Uhr: Hoster melden dem Sicherheitsdienst Patchstack erste aktive Angriffe.
• 21. Oktober, 9.43 Uhr: Cloudflare sieht erste Angriffe und schaltet Notfall-Filter auf.
• 21. Oktober, kurz vor 16 Uhr: PHP veröffentlicht die korrigierten Versionen.

Die ersten Angriffsversuche kamen also rund sechs Stunden vor dem Patch. Und für die Zeit danach rechnete der Sicherheitsdienst Sansec mit Massenangriffen innerhalb von 15 Minuten nach dem Release. Wie schnell das geht, zeigten die Entdecker selbst: In einem Video übernahmen sie einen Webserver in 38 Sekunden.

Zur Ehrlichkeit gehört auch: Nicht alle haben dasselbe gesehen. Manche Sicherheitsfirmen meldeten am 21. Oktober noch keine erfolgreichen Einbrüche, nur Versuche. Aber darauf zu wetten, dass es bei Versuchen bleibt, wäre fahrlässig gewesen.

Offline am Nachmittag

Und so geschah etwas, das ich so noch nie gesehen habe. Das britische NCSC riet, Systeme vom Netz zu nehmen, wenn sie sich nicht sofort absichern lassen. In der Schweiz rief das Bundesamt für Cybersicherheit BACS dazu auf, die Updates unverzüglich einzuspielen und bei kritischen Anwendungen eine vorübergehende Trennung vom Internet zu prüfen. Und viele taten genau das, mitten am Arbeitstag. Das niederländische Regierungsportal Overheid.nl ging vorsorglich offline, ebenso die öffentlichen Dienste der finnischen Regierung. Die Wikimedia Foundation schaltete mehrere Dienste ab. Der deutsche Hoster Uberspace legte PHP vorübergehend still.

Das Update in Ruhe in der Nacht einspielen? Diesmal gab es diese Nacht nicht.

Und welche Rolle spielt die KI?

Hier muss ich genauer sein, als es auf den ersten Blick naheliegt. Belegt ist die KI in diesem Fall auf der Seite der Finder, nicht der Angreifer.

Die Sicherheitsfirma Calif hat die erste Lücke Anfang August mit einem KI-Modell von OpenAI aufgespürt. Drei Wochen später fand die Firma Wiz denselben Fehler, unabhängig davon und ebenfalls mit KI. Der Fehler steckt in PHP seit Version 5.4 aus dem Jahr 2012. Über zehn Jahre lang hat ihn niemand bemerkt, und dann finden ihn zwei Teams innerhalb weniger Wochen.

Das ist kein Einzelfall. Im Juli wurde mit «wp2shell» eine kritische Lücke im WordPress-Kern bekannt, ebenfalls mit KI gefunden. Auch sie wurde unmittelbar nach dem Patch angegriffen.

Ob die Angreifer bei PHP2Shell selbst KI eingesetzt haben, weiss niemand. Die Schlussfolgerung ist trotzdem unbequem genug:

• Was gute Leute mit KI in wenigen Wochen finden, finden andere auch. Nur melden sie es nicht.
• Ein Patch ist immer auch eine Anleitung. Er zeigt genau, welche Stelle kaputt war. Werkzeuge, die Code in Minuten lesen, lesen auch einen Patch in Minuten.

Diesmal hat ein Leak das Zeitfenster geschlossen. Beim nächsten Mal braucht es dafür vermutlich gar keinen Leak mehr.

Wie schnell das gehen könnte, zeigt eine einfache Rechnung. Auffällig ist der Knick: Bis 2021/22 sank die Zeit gemächlich, danach brach sie ein, von 32 auf 5 Tage. Das fällt zeitlich mit dem Start von ChatGPT Ende 2022 zusammen. Dass die KI die Ursache ist, belegen die Zahlen allein nicht, aber sie passt ins Bild. Schreibt man das bisherige Tempo fort, bleiben 2029 zwischen vier Stunden und vier Minuten. Zieht man die Linie dagegen von 2023 durch das, was bei PHP2Shell erwartet wurde, sind es 2029 noch rund 25 Sekunden. Das ist eine Hochrechnung, keine Prognose. Ich halte die steile Linie trotzdem für die wahrscheinlichere.

Was das für deine Website heisst

Patchen ist kein Nachtjob mehr, den man irgendwann erledigt. Es ist ein Notfallablauf, der sitzen muss, bevor der Notfall kommt. Ein paar Fragen, die du dir stellen solltest:

• Wer patcht bei dir PHP? Bei einem normalen Hosting-Paket ist das der Hoster, nicht du. Frag nach, wie schnell er bei kritischen Lücken reagiert und wie er dich informiert. Das BACS empfiehlt ausdrücklich, sich die Behebung vom Hoster bestätigen zu lassen.
• Welche PHP-Version läuft? PHP 8.1 und älter bekommen keinen offiziellen Fix mehr. Wer noch darauf sitzt, sollte spätestens jetzt wechseln.
• Kannst du deine Website kurzfristig vom Netz nehmen? Mit einem Wartungsmodus, den du kennst, und mit einem frischen Backup. Improvisieren, während Angriffe laufen, ist der schlechteste Moment dafür.
• Finger weg von Schnelllösungen. Nach jeder grossen Lücke tauchen angebliche Fix-Plugins und kopierte Code-Schnipsel auf. Sie ersetzen das echte Update nicht, im schlimmsten Fall sind sie selbst die Hintertür.
• Ein Update räumt nicht auf. Es schliesst die Lücke, wirft aber niemanden hinaus, der schon drin ist. Lief deine Website am 21. Oktober noch ungepatcht, lohnt sich ein Blick auf veränderte Dateien und ungewöhnliche Einträge in den Logs.

Die gute Nachricht: Die korrigierten PHP-Versionen sind da. Wer jetzt aktualisiert, ist auf der sicheren Seite. Die schlechte: PHP2Shell war vermutlich nicht die letzte Lücke dieser Art, sondern die erste, bei der es alle gemerkt haben.