Es gibt einen neuen Zero-Day-Exploit in Joomla. Einzelheiten werden in CVE-2015-8562 beschrieben.
Wir empfehlen Ihnen, Joomla umgehend zu aktualisieren. Falls dies jedoch nicht möglich ist oder Sie die Dateien auf Ihren Backend-Servern nicht ändern können, können Sie im Frontend eine Korrektur in NGINX oder NGINX Plus vornehmen.
Hinweis: Wir empfehlen Ihnen dringend, Ihre Joomla-Installationen so schnell wie möglich zu aktualisieren, selbst wenn Sie Ihre Website heute mit dieser NGINX-Konfiguration absichern.
Weitere Informationen zum Exploit und zum Patch finden Sie unter anderem im Sucuri-Blog oder bei Ars Technica.
Identifizierung des Angriffs
Die ursprünglichen Angriffe gingen von diesen IP-Adressen aus:
- Am 12. Dezember 2015 – 74.3.170.33
- Am 13. Dezember 2015 – 146.0.72.83 und 194.28.174.106
Der Angriff erfolgt in der Regel durch eine Änderung des User-Agent-Headers und lässt sich anhand der folgenden Werte im Header erkennen: JDatabaseDriverMysqli und O: (Großbuchstabe O gefolgt von einem Doppelpunkt).
Joomla stellt den folgenden beispielhaften Protokolleintrag eines Angriffs bereit.
2015 Dec 12 16:49:07 clienyhidden.access.logSrc IP: 74.3.XX.XX / CAN / Alberta
74.3.XX.XX [12/Dec/2015:16:49:40 -0500] GET /contact/ HTTP/1.1 403 5322 http://google.com/ }__test|O:21:x22JDatabaseDriverMysqlix22:3:..{s:2:x22fcx22;O:17:x22JSimplepieFactoryx22:0:..{}s:21:x22x5C0x5C0x5C0disconnectHandlersx22;a:1:{i:0;a:2:{i:0;O:9:x22SimplePiex22:5:..{s:8:x22sanitizex22;O:20:x22JDatabaseDriverMysqlx22:0:{}s:8:x22feed_urlx22;s:60:..Anwenden einer Korrektur in NGINX oder NGINX Plus
Verwenden Sie diesen Ausschnitt der NGINX-Konfiguration, um die ursprünglichen IP-Adressen sowie alle Anfragen zu blockieren, bei denen der Header User-Agent den Wert O: oder JDatabaseDriverMysqli enthält. Um weitere IP-Adressen zu blockieren, fügen Sie sie der Liste im zweiten map-Block hinzu.
http { map $http_user_agent $blocked_ua {
~(?i)O: 1;
~(?i)JDatabaseDriverMysql 1;
default 0;
}
map $remote_addr $blocked_ip {
74.3.170.33 1;
146.0.72.83 1;
194.28.174.106 1;
default 0;
}
server {
listen 80;
if ($blocked_ua) { return 403; }
if ($blocked_ip) { return 403; }
# ...
}
}Weitere Informationen zur Beschränkung des Zugriffs auf Ihre Website finden Sie im NGINX Plus-Administratorhandbuch.
Teilen Sie Ihre Erfahrungen unten in den Kommentaren.
Über den Autor

Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.