Drei schwerwiegende Sicherheitslücken in führenden WordPress-Plugins setzen Webseiten nicht authentifizierten XSS-Angriffen aus

Sicherheitsforscher haben drei kritische Sicherheitslücken in beliebten WordPress-Plugins identifiziert, die anfällig für nicht authentifizierte Cross-Site Scripting (XSS)-Angriffe sind.

Diese Sicherheitslücken ermöglichen es Angreifern, bösartige Skripte einzuschleusen und könnten fast 6 Millionen WordPress-Installationen gefährden. Angesichts der weit verbreiteten Nutzung dieser Plugins fordern Cybersicherheitsexperten zu sofortigen Maßnahmen auf, um die Risiken zu mindern.

Überblick über die Sicherheitslücken

Die beobachteten Angriffspayloads beinhalten das Einspeisen eines Script-Tags, das auf eine verschleierte JavaScript-Datei verweist, die auf einer externen Domain gehostet wird. Das bösartige Skript führte eine Reihe schädlicher Aktionen aus, darunter:

Erstellen neuer Administratorkonten
Einschleusen von Hintertüren auf der Website
Einrichten von Tracking-Skripten zur Überwachung infizierter Websites

Jede der drei Sicherheitslücken, die durch eindeutige CVE-Identifikatoren (Common Vulnerabilities and Exposures) identifiziert wurden, betraf ein anderes Plugin, wies jedoch einen ähnlichen Angriffsmechanismus auf.

Detaillierte Aufschlüsselung der Sicherheitslücken

CVE-2024-2194: Diese Sicherheitslücke betrifft das WPStatistics-Plugin, das auf über 600.000 WordPress-Seiten installiert ist. Das Plugin wird zur Verfolgung und Anzeige von Webseiten-Statistiken verwendet und ist somit ein wertvolles Ziel für Angreifer, die dessen Daten und Benutzerbasis ausnutzen möchten.

CVE-2023-6961: Diese Schwachstelle wurde im WP Meta SEO-Plugin gefunden, das mehr als 20.000 Installationen hat. Dieser Fehler ermöglicht es Angreifern, SEO-Metadaten zu manipulieren und potenziell den Traffic umzuleiten oder die SEO-Leistung der Webseite zu beeinträchtigen.

CVE-2023-40000: Die am weitesten verbreitete der drei Schwachstellen betrifft das LiteSpeed Cache-Plugin, das auf über 5 Millionen Wordpress-Webseiten installiert ist. Das Plugin verbessert die Leistung durch Caching, wodurch eine Ausnutzung besonders schädlich sein kann, da sie die Geschwindigkeit und Zuverlässigkeit der Webseite beeinträchtigen könnte.

Wie kann man sich gegen diese Sicherheitslücken schützen?

Um diese Sicherheitslücken zu beheben, werden folgende Schritte für Sicherheitsprofis empfohlen:

Falls Sie eines dieser Plugins verwenden, führen Sie dringend Updates auf Ihren Instanzen durch.

Überprüfung von Administratorkonten:

Führen Sie eine umfassende Überprüfung der Benutzerkonten mit Administratorrechten durch und Entfernen Sie verdächtige und nicht mehr benötigte Konten.

Scannen nach unerwarteten Dateimodifikationen:

Überprüfen Sie regelmäßig die Dateien Ihrer Webseite auf unerwartete Änderungen. Konzentrieren Sie sich dabei auf das Erkennen eingeschleuster Skripte.

Überwachung ausgehender Anfragen:

Seien Sie wachsam gegenüber ungewöhnlichen ausgehenden Anfragen.

Implementierung einer Content Security Policy (CSP):

Um eine Content Security Policy (CSP) zu implementieren und die Sicherheit Ihrer Webseite zu erhöhen, folgen Sie diesen Schritten:

Definieren Sie Ihre Richtlinie:

Bestimmen Sie die Direktiven und Quellen, die Sie für verschiedene Arten von Inhalten (z. B. Skripte, Stile, Bilder) zulassen möchten. Beginnen Sie mit einer grundlegenden Richtlinie und verfeinern Sie sie schrittweise. Ein einfaches Beispiel für eine Richtlinie, die nur Skripte und Stile von derselben Quelle erlaubt, könnte folgendermaßen aussehen:

default-src 'self'; script-src 'self'; style-src 'self'.

Fügen Sie den CSP-Header hinzu:

Implementieren Sie die definierte CSP, indem Sie sie zu Ihren HTTP-Antwort-Headern hinzufügen. Dies kann in der Regel über die Konfiguration Ihres Webservers erfolgen.

In Apache fügen Sie beispielsweise die folgende Zeile zu Ihrer Konfigurationsdatei hinzu:

Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'".

Für Nginx wäre die entsprechende Direktive:

add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'";

Überwachen und Anpassen:

Setzen Sie Ihre CSP zunächst im Report-Only-Modus ein, um ihre Auswirkungen zu überwachen, ohne sie durchzusetzen. Dies kann durch Verwendung des Headers Content-Security-Policy-Report-Only anstelle von Content-Security-Policy erfolgen. Auf diese Weise werden Verstöße gemeldet, aber nicht blockiert, sodass Sie die Richtlinie feinabstimmen können. Beispiel:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; style-src 'self'; report-uri /csp-report-endpoint.

Überprüfen und Verfeinern:

Sammeln und überprüfen Sie die durch Ihre CSP generierten Berichte. Nutzen Sie diese Erkenntnisse, um Ihre Richtlinie anzupassen und zu verfeinern, wobei Sie schrittweise zu einer restriktiveren und präziseren Richtlinie übergehen, die nur die notwendigen Inhaltsquellen zulässt.

Durchsetzen der Richtlinie:

Sobald Sie sicher sind, dass die Richtlinie korrekt abgestimmt ist und keinen legitimen Inhalt stört, wechseln Sie vom Report-Only-Modus in den Durchsetzungsmodus, indem Sie den Header wieder in Content-Security-Policy ändern.

Durch sorgfältiges Definieren, Testen und Verfeinern Ihrer CSP können Sie das Risiko von XSS- und anderen Inhaltsinjektionsangriffen auf Ihrer Webseite erheblich reduzieren.