Am Donnerstag haben wir beschrieben, warum unser Server das Sicherheitsupdate für PHP zunächst gar nicht anbot. Seither hat sich die Lage verändert.
Amazon meldet, die beiden Lücken würden inzwischen breit ausgenutzt. Den ersten Versuch hat das Unternehmen in seinen Köder-Systemen schon am 17. Oktober gesehen, vier Tage bevor die Lücken öffentlich wurden. Cloudflare zählte nach Angaben seines Chefs in den zehn Stunden vor der Veröffentlichung Tausende Versuche, in der Dreiviertelstunde danach Zehntausende, inzwischen Millionen.
Mehrere europäische Regierungen haben Websites vorsorglich vom Netz genommen. In Berlin war laut heise die gesamte Website der Charité nicht erreichbar.
Eine Einschränkung gehört dazu: Ob auch nur einer dieser Versuche auf einem echten System erfolgreich war, ist bis heute nicht belegt. Amazon schreibt das ausdrücklich, und mehrere Fachleute weisen darauf hin, dass viele der kursierenden Angriffsskripte gar nicht funktionieren. Versucht wird es massenhaft. Offen ist der Erfolg.
Was wir bei uns gesehen haben
Amazon empfiehlt, die Zugriffsprotokolle ab dem 17. Oktober durchzusehen. Das haben wir für unsere eigene Website getan.
Die sechs Adressen, die Amazon als Absender nennt, tauchen bei uns nicht auf. Das sagt wenig: Sie gehören zu Anonymisierungsnetzen, und wer angreift, wechselt sie.
Aufschlussreicher war etwas anderes. Am Donnerstag kurz nach elf Uhr schickte ein einzelner Absender innerhalb weniger Minuten über 300 Anfragen an unsere Website, mehrere identische in derselben Sekunde. Zum Vergleich: An einem gewöhnlichen Tag sind es insgesamt rund hundert. Vorher hatte er dieselben Seiten der Reihe nach abgerufen, um ihre Adressen zu sammeln.
Das Auffällige ist das Ziel. Die Anfragen gingen nicht an das Kontaktformular, sondern an das Glossar, an Ratgeber, an Seiten, die gar nichts entgegennehmen. Ein Mensch schickt einer solchen Seite keine Daten.
Warum das Ziel keine Rolle spielt
Bei den meisten Angriffen auf Websites braucht es eine Schwachstelle in der Website selbst: ein Formular, das schlecht prüft, ein Plugin mit einer Lücke, ein schwaches Passwort.
Bei PHP2Shell nicht. Die Lücke sitzt eine Ebene tiefer, in PHP selbst, in der Art, wie es hochgeladene Daten entgegennimmt. Das passiert, bevor die Website überhaupt entscheidet, ob sie mit diesen Daten etwas anfangen will. Jede Adresse, hinter der PHP läuft, ist damit ein Eingang. Die Startseite genügt.
Ob unser Absender es tatsächlich auf PHP2Shell abgesehen hatte, können wir nicht beweisen. Was in einer solchen Anfrage steckt, steht nicht im Zugriffsprotokoll. Das Muster passt, mehr lässt sich nicht sagen. Unsere Website lief zu diesem Zeitpunkt bereits auf der korrigierten Version. Und jede PHP-Datei, die sich seit dem 17. Oktober verändert hat, haben wir mit unserem eigenen Stand verglichen: Alle stimmen überein.
Für Betriebe heisst das: «Wir haben ja kein Formular» und «bei uns kann man sich nicht anmelden» sind diesmal keine Entlastung. Und auch ein Update von WordPress oder Joomla schliesst die Lücke nicht, weil sie unterhalb davon liegt. Es kommt allein auf die PHP-Version an, die beim Hoster läuft.
Wenn es kein Update gibt
Für PHP 8.2 bis 8.5 gibt es korrigierte Versionen. Für 7.4, 8.0 und 8.1 liefert das PHP-Projekt nur noch minimale Korrekturen im Quellcode. Ob daraus ein einspielbares Paket wird, entscheidet der Anbieter der jeweiligen Distribution, und das fällt unterschiedlich aus: Auf einem Server mit Ubuntu 20.04 lagen am Mittwoch neue Pakete für alle drei alten Versionen bereit, auf einem mit Ubuntu 22.04 bis heute keine. Ob die neuen Pakete die Korrekturen tatsächlich enthalten, sagt der Anbieter bisher nicht.
Wer auf einer solchen Version ohne Update sitzt, hat drei Möglichkeiten.
Auf eine aktuelle PHP-Version wechseln. Das ist der saubere Weg, aber bei älterer Software nicht ohne Test: Ein Plugin, das seit Jahren nicht gepflegt wird, kann auf PHP 8.3 den Dienst verweigern.
Uploads vorübergehend sperren. Amazon empfiehlt als Notmassnahme, mehrteilige Uploads zu blockieren, wenn ein Update nicht sofort möglich ist. Vorher prüfen, was davon abhängt, etwa ein Formular mit Dateianhang. Das PHP-Projekt sagt dazu deutlich: Solche Massnahmen verringern das Risiko, machen eine Installation aber nicht sicher.
Abschalten. Was die Charité getan hat, klingt drastisch. Für eine Website auf einem ungepatchten Zweig, die keinen laufenden Umsatz trägt, ist es bis zum Wechsel die ehrlichste Option.
Drei Fragen an Ihren Hoster
Welche PHP-Version läuft auf meiner Website? In WordPress steht sie unter Werkzeuge, Website-Zustand, Bericht, im Abschnitt Server. In Joomla unter System, Systeminformationen.
Seit wann ist sie aktualisiert, und wurde der Dienst danach neu gestartet? Ein eingespieltes Update wirkt erst nach dem Neustart, das haben wir im September an uns selbst gemessen.
Was geschieht mit Websites auf PHP 7.4, 8.0 und 8.1? Wenn darauf keine klare Antwort kommt, ist das auch eine Antwort.