News Sofort updaten!: Patches schließen hoch­ris­kante Sicherheitslücken in PHP

[BrollyLSSJ]

Ich bin erst mal froh, dass ich mich zurücklehnen kann. VMware / Broadcom vCenter und Co., also der VCF Stack, sind laut Broadcom KB nicht betroffen, da dort kein PHP zum Einsatz kommt.

 

[.one]

Ich war die ganze Zeit zurückgehlent. Allinkl hat bei meinem manged Server einen guten Job gemacht, auch wenn die Kommunikation ggü. den Kunden diesmal nicht stattgefunden hat und damit scheiße war. Ich glaube aber, dass dass fixen (wie bei allen Hostern) wichtiger war, als die Kommunikation. Man hätte aber zumindest im Nachhinein mal ne Mail rausjagen können. Egal, passt schon.

 

[Mirlo]

Ich versuche, ein paar Punkte zu klären, weil sich hier einige Annahmen eingeschlichen haben.

3. Warum nicht einmal ein existierendes Skript nötig ist

Der Webserver entscheidet anhand der URL (z. B. \.php$ bei nginx), ob ein Request an php-fpm geht

Aha. So ist das also!
Es genügt/e also, dass beim Aufruf einer Url, die auf den Webhost/Server zeigt, eine *.php Datei angesteuert wird. Wie zB bei Wordpress, dass alle Urls auf die /index.php geleitet werden, die in den Urls (SEO Urls) gar nicht sichtbar ist. Und selbst wenn diese /index.php vollkommen leer ist, dann konnte die PHP2Shell-Lücke ausgenutzt werden. Der fürs kompromitieren erforderliche Speicherüberlauf wurde vom Parser erzeugt, der die eingehenden Daten für PHP vorbereitet/parst.

Interessant. Denn manchmal habe ich in einem leeren Verzeichnis eine leere index.php als Platzhalter angelegt. Da wäre es schlauer, eine leere index.html anzulegen.

Es nützte auch nichts, die index.php per .htaccess zu verstecken, oder einen Direktaufruf per Url zu blockieren. Denn intern wird die index.php aufgerufen und somit der Parser ... und somit potentiell kompromitiert.

Na dann, ist ab jetzt praktisch jeder Webhost, der bis Mittwoch im Netz erreichbar war, potentiell kompromitiert. Hetzner hat das dann schon richtig eingeschätzt und an seine Kunden weitergegeben, dass jeder Webmaster jetzt dazu verpflichtet ist, seine Daten auf eine mögliche Kompromitierung zu überprüfen. ... boah ... kein Bock ... Aber ... verdammt ... mir wurde schon einmal eine vollkommen irrelevante Datenbank gehakt, mit so einem vorgefertigten CMS (die ich alle nicht mehr verwende) ... Und der eine Webhoster wurde schon mehrmals gehackt ... und dann gabs massenweise Spam, bis die Hacker aufgeflogen sind.

Internet ... manche Sachen sind bis ins letzte Detail sehr klug durchdacht und andere wiederum gar nicht. Alles Risiko.

 

[Ranayna]

Und selbst wenn diese /index.php vollkommen leer ist, dann konnte die PHP2Shell-Lücke ausgenutzt werden.

Wenn ich es richtig verstanden habe, kann die nicht nur komplett leer sein. Die muss nichtmal existieren.
Wenn PHP installiert ist reicht das schon.

Da sei natuerlich dahingestellt, das es vielleicht keine ideale Einstellung ist, auch unbekannte URLs erstmal an den PHP Parser zu schicken, wenn die nichtmal auf dem Webserver exisitert.

 

[Mirlo]

Die muss nichtmal existieren.
Wenn PHP installiert ist reicht das schon.

Achso, die Sache mit in der .htaccess und dem default weiterleiten an index.html oder index.php - DirectoryIndex (Module mod_dir). Aber, default wird glaube ich Prio 1 = index.html und Prio 2 = index.php geleitet. Verschachtelte if() Logik. Wenn eins vorhanden und das andere nicht, oder umgekehrt, und so weiter. Wenn aber keine index.php vorhanden, dann default index.html, bzw. wenn keine von beiden vorhanden, dann index.html → 404 (Datei nicht vorhanden).

Aber, dass kann manuell verändert werden, so dass immer und auch bei fehlenden Dateien an index.php geleitet und somit der Parser gestartet wird? spekulativ Ausprobieren werde ich das jetzt nicht.
https://httpd.apache.org/docs/current/mod/mod_dir.html

 

[dev/random]

Es genügt/e also, dass beim Aufruf einer Url, die auf den Webhost/Server zeigt, eine *.php Datei angesteuert wird.

Das lässt sich nicht allgemeingültig beantworten sondern hängt stark vom verwendeten webserver und dessen Konfiguration ab.

Hier sind mal zwei Beispiele mit apache, bei dem PHP über fastcgi und php-fpm ausgeführt wird.
1. Die erste, simple Konfiguration auf https://wiki.apache.org/httpd/PHP-FPM reicht alle requests die ein .php enthalten direkt zum php-fpm Prozess weiter:

ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9000/path/to/your/documentroot/$1

Dabei wird nicht geprüft, ob auf dem webserver überhaupt eine PHP Datei existiert. Solange der Angreifer in seiner Anfrage ein ".php" drin hat, wird die Anfrage zum PHP-Prozess weitergereicht und könnte die Schwachstelle triggern. Fehler wegen leerer oder nicht existierender Dateien würde dabei vom PHP-Prozess kommen, nicht vom webserver.

2. Wenn in der Webserver-Konfiguration erst geprüft wird, ob die angefragte Datei existiert bevor der PHP-Prozess aufgerufen wird und vom Webserver mit einem Fehler geantwortet wird, dann kann eine verwundbare PHP-Installation auch geschützt werden, in dem der Zugriff auf alle .php Dateien verhindert wird. So eine Konfiguration ist zum Beispiel im Debian php-fpm Paket enthalten, aber ist per default nicht aktiviert:

<FilesMatch ".+\.ph(?:ar|p|tml)$">
        <If "-f %{REQUEST_FILENAME}">
                SetHandler "proxy:unix:/run/php/php8.4-fpm.sock|fcgi://localhost"
        </If>
</FilesMatch>

Eine leere oder ungültige .php Datei würde dabei aber auch an den PHP-Prozess durchgereicht werden.

 

[brot-0815]

Prüfen, ob die eigene Website betroffen ist (wenn PHP verwendet wird):

1. https://www.unicorn-factory.net/php-version-checker/

Das Ergebnis kann bspw. so sein:

Ein zweiter Online-Scanner (etwas aggressiver als der erste, weil -so weit ich weiß- nicht nur einfach die Version geprüft wird, sondern auch kurz angeklopft wird):

2. https://pentest-tools.com/network-vulnerability-scanning/php2shell-scanner

 

[wagga]

Mein Hoster bietet oder bot Patches für 8.5, 8.4, 8.3, 8.2 und 8.1 und 8.0 sowie 7.4 und 5.6 an.
Durch Duck.ai konnte ich 1 fehlerhaftes Wordpress Plugin wieder reparieren und konnte mein altes Grußkartenskript von 2004 was 6 Jahre nicht mehr lief, wieder heute reaktivieren.Endlich mal einen sinnvollen Einsatzzweck für Duck.ai Mistral 4 gefunden. Ich bin begeistert. Das es so super funktioniert. Schönes Wochenende.

 

[kim88]

Na dann, ist ab jetzt praktisch jeder Webhost, der bis Mittwoch im Netz erreichbar war, potentiell kompromitiert.

Deswegen Einstufung von 9.2 und deswegen war das auch so eine riesige Aufregung.