Die PHP-Sicherheitslücke vom 21. Oktober: was wir getan haben und warum

Was los war

Am Mittwochmorgen veröffentlichte das PHP-Projekt zwei kritische Schwachstellen, schon bald “PHP2Shell” genannt, beide mit einer Bewertung von 9,2 von 10. Über diese Lücken konnte jemand von außen eigenen Code auf einem Server ausführen, auf dem PHP läuft, ohne sich anzumelden. Damit gelangt man an Konten, Passwörter und geschützte Bereiche einer Website und im schlimmsten Fall an den Server selbst.

Was es besonders brisant machte: Die Informationen über die Lücken waren bereits einen Tag zuvor durchgesickert und kursierten in den sozialen Medien. Die Lösung war für später in der Woche geplant und wurde auf Mittwoch, 16.00 Uhr, vorgezogen. Bis dahin war jeder aus dem Internet erreichbare Server mit PHP wahrscheinlich anfällig, und das wussten auch Böswillige.

Viele große Organisationen trafen deshalb dieselbe Entscheidung wie wir und nahmen ihre Websites vorsorglich offline, darunter die Zweite Kammer des niederländischen Parlaments, das NCSC, DigiD und MijnOverheid. Das Liveblog von NU.nl gibt einen guten Eindruck von diesem Nachmittag.

Was wir getan haben

Wir haben nicht gewartet, bis etwas schiefgeht. So verlief der Tag auf unseren Servern:

• 13.30 UhrPHP auf allen unseren Servern abgeschaltet. Websites, die auf PHP laufen, zeigten Besuchern eine kurze Erklärung.
• ZwischendurchE-Mails über Ihre Domain wurden ganz normal gesendet und empfangen. Ihre Website und Ihre Daten blieben unversehrt: Es wurde nichts gelöscht oder geändert.
• 16.00 UhrDie aktualisierten PHP-Versionen liefen, und die Websites waren wieder erreichbar.
• DanachDie Server auf Spuren von Missbrauch überprüft. In unseren Protokollen wurden keine Anzeichen für einen Einbruch gefunden.

Dass die aktualisierten Versionen um 16.00 Uhr bereits liefen, liegt daran, dass wir das Update ab dem Mittag durchgehend im Blick behalten und es sofort installiert haben, als es erschien.

Entschuldigung für die Unannehmlichkeiten

Eine Website, die zweieinhalb Stunden lang nicht erreichbar ist, ist ärgerlich, besonders wenn Ihre Kunden Sie gerade an diesem Nachmittag gesucht haben. Einige von Ihnen sahen die Website schon offline, bevor unsere Nachricht ankam. Wegen der Schwere der Lücke haben wir uns entschieden, zuerst die Server abzusichern und erst danach zu mailen. Wir entschuldigen uns für die Unannehmlichkeiten.

Zugleich passt dieser Schritt dazu, wie wir Ihr Hosting verwalten: Wir behalten die Server selbst aktiv im Blick, und wenn es nötig ist, greifen wir schnell ein. Lieber einen Nachmittag lang eine Erklärungsseite als eine Website, die sich später als übernommen herausstellt.

Warum das häufiger passieren wird

Der verwundbare Code steckte schon gut zehn Jahre in PHP und wurde jetzt mit Hilfe von KI gefunden. Dieses Werkzeug steht auch Böswilligen zur Verfügung. Wir erwarten deshalb, dass Lücken in immer schnellerem Tempo aufeinander folgen. Websites mit einem CMS wie WordPress oder Joomla brauchen besondere Aufmerksamkeit: Sie stützen sich sowohl auf PHP als auch auf Plug-ins und Erweiterungen von Dutzenden verschiedener Hersteller, und jeder dieser Bestandteile kann die nächste Lücke enthalten.

Deshalb überführen wir bestehende Websites immer häufiger in statische Websites, ohne PHP, WordPress oder Joomla. Damit entfallen viele mögliche Schwachstellen, und bei einer nächsten PHP-Lücke bleibt eine solche Website einfach online. Nur ein Kontaktformular nutzt dann noch ein kleines PHP-Skript, sofern keine andere Lösung zur Verfügung steht. Wie das funktioniert, lesen Sie unter Website ohne PHP erstellen lassen.

Möchten Sie wissen, ob das eine geeignete Lösung für Ihre Website ist, oder haben Sie Fragen zum Mittwoch? Schreiben Sie an info@innodigi.nl oder nehmen Sie Kontakt auf.