Am Dienstag, 20.10., habe ich morgens Mastodon durchgescrollt. Viele der Accounts, denen ich dort folge, sind wie ich im Infosec-Bereich unterwegs. So kam es, dass ich dort zuerst von der Schwachstelle PHP2Shell gelesen habe: unklare Details, aber alle PHP-Installationen betroffen. Pre-auth Remote Code Execution, also absolut kritisch. Noch kein Fix vorhanden, aber angeblich erste Exploits im Umlauf. Patch wird um 16 Uhr veröffentlicht, bis dahin sollte man alles offline nehmen, auf dem PHP läuft und das mit dem Internet verbunden ist. Okay, dachte ich, das könnte ein arbeitsreicher Tag werden. Zur Erinnerung: Ich bin erst kürzlich im Schwachstellen-Management gelandet.
Maßnahme 1: Ich habe herausgefunden, wie man die zwei alten Wordpress-Seiten offline nehmen kann, die ich noch betreibe. Auch den Wordpress-Blog meiner Frau habe ich offline genommen und ihren Vorgesetzten informiert, denn auch ihre Firma läuft (noch) auf Wordpress.
Maßnahme 2 kam dann mit Arbeitsbeginn. Ich habe unter anderem auf der Website von Huntress, Watchtowr und bei PHP selbst recherchiert, welche Empfehlungen zum Umgang mit der Schwachstelle gegeben werden. Parallel habe ich meinen Kunden über die Schwachstelle informiert und bis zum Daily Meeting wenig später einen Plan für das Vorgehen entwickelt. Ich muss meinem Kunden zugutehalten, dass das Thema sofort hoch priorisiert wurde.
Wir sind sofort daran gegangen, die PHP-Installationen zu identifizieren und im ersten Schritt die Einschätzung zu bestätigen, dass in öffentlich zugänglichen Netzbereichen (DMZ) kein PHP-Code lief. Das machte die Sache schon deutlich entspannter.
Interessant an diesem ersten Tag der Arbeit an php2shell war, dass der übliche Prozess zur Schwachstellenbearbeitung in solchen Fällen nicht funktioniert. Der Schwachstellenscanner kannte die Schwachstelle ja noch nicht, da sie noch nicht als CVE veröffentlicht worden war. Entsprechend konnte der Scanner die PHP-Installationen, die betroffen waren, nicht auflisten. Stattdessen bestand für mich ein Teil des Tages daraus, in riesigen CSV-Dateien nach der Zeichenkette “PHP” zu suchen. Der Nachteil an diesen kurzen Namen: Sie kommen häufig auch in Base64-codierten oder anderen entropischen Zeichenketten vor.
Wo wir PHP-Files gefunden haben, sind wir auf die zugehörigen Fachabteilungen zugegangen und haben Details erfragt. So war zum Beispiel nicht in allen Fällen klar, ob es sich um laufende PHP-Installationen handelte oder nur um Software-Module, die eventuell gar nicht aktiviert waren. In einem Fall kam tatsächlich die Rückmeldung, auf der angeblich betroffenen Software würde kein PHP laufen. Erst als ich die gefundenen Installationspfade vorzeigte, erkannte der Ansprechpartner, dass dort offenbar doch PHP lief. Ich fürchte, das ist einer der unangenehmsten Aspekte dieser Schwachstelle: PHP läuft auf so vielfältigen Systemen im Hintergrund, dass das häufig sogar den Betreibenden nicht bewusst ist.
Sobald die PHP-Installationen alle im Wiki aufgelistet waren, hatten die Fachabteilungen im Grunde zwei Optionen: Falls sie die PHP-Installationen selbst betrieben, sollten sie für den Zeitpunkt der Verfügbarkeit des Patches ein Zeitfenster für das Update einplanen - Verfügbarkeit hin oder her, bei einer solchen Schwachstelle muss der Patch unverzüglich installiert werden. Wo die PHP-Instanzen in einem Softwarepaket eines Drittherstellers oder sogar in einer Hersteller-Appliance verpackt waren, sollten die Ansprechpartner sofort auf den Hersteller zugehen und uns mitteilen, wann von diesem ein Patch zur Verfügung gestellt würde. Wo das auf sich warten lässt, werden wir Mitigationen umsetzen, sobald sie bekannt werden, oder den Zugriff auf die betroffenen Server weiter einschränken.
Ich finde es tatsächlich spannend, so einen Prozess einmal Ende-zu-Ende mitzuerleben. Mein Eindruck ist, dass mein Kunde hier einigermaßen gut aufgestellt ist. Niemand ist in den gefürchteten “Headless Chicken Mode” übergegangen; alles sah nach einem geregelten Prozess aus, der für eine so große Organisation im Finanzsektor recht schnell durchlief - nicht ohne Eskalationen an der einen oder anderen Stelle. Was ich daraus gelernt habe? Ich würde sagen, Folgendes:
- Vordefinierte Prozesse verhindern tatsächlich Chaos und Panik
- Schwachstellen behandeln zu müssen, bevor sie formalisiert und veröffentlicht sind, ist ein wichtiger Ausnahmefall, auf den man vorbereitet sein muss
- Um jede Installation von Komponenten wie PHP zu finden, braucht man technische Lösungen, denn auch die Verantwortlichen für die entsprechenden Hosts wissen oft nicht spontan, ob die Komponente bei ihnen läuft.