WordPress Brizy Plugin Schwachstelle gefährdet Tausende vor Admin-Übernahme

WordPress betreibt über 43 % aller Websites weltweit und ist daher ein beständiges Ziel für Cyberkriminelle. Im Jahr 2020 führte eine kritische Sicherheitslücke im Brizy Page Builder Plugin – CVE-2020-36714 – dazu, dass Tausende von Websites einem unautorisierten administrativen Zugriff ausgesetzt waren. Dieser Fehler im Berechtigungssystem verdeutlicht, wie scheinbar geringfügige Entwicklungsmängel zu erheblichen Risiken für Unternehmen führen können, die Drittanbieter-Plugins nutzen, mit direkten Auswirkungen auf das Underwriting und die Schadensbearbeitung im Bereich der Cyber-Versicherung.

Was geschah bei CVE-2020-36714

Das Brizy-Plugin war zum Zeitpunkt seiner Entdeckung auf etwa 100.000 WordPress-Seiten installiert und enthielt einen fehlerhaften Autorisierungsmechanismus in der Funktion is_administrator(). Diese Funktion sollte entscheiden, ob ein Nutzer über administrative Rechte verfügt, um auf sensible AJAX-Endpunkte zuzugreifen. Aufgrund einer fehlerhaften Prüfung der Benutzerrechte konnten authentifizierte Nutzer mit minimalen Zugriffsrechten die Autorisierung umgehen und administrative Funktionen nutzen.

Die Sicherheitslücke betraf alle Plugin-Versionen bis einschließlich 1.0.125. Angreifer, die Zugang zu einem gültigen Benutzerkonto erlangten – etwa durch Credential Stuffing, Social Engineering oder durch den Kauf kompromittierter Zugangsdaten auf Dark-Web-Märkten – konnten diesen Fehler ausnutzen, um ihre Berechtigungen innerhalb der WordPress-Umgebung zu erweitern.

Relevanz für die Cyber-Versicherung

Aus Versicherungssicht stellt CVE-2020-36714 ein klassisches Beispiel für die Umwandlung eines Drittanbieter-Risikos in einen Erstschaden dar. Die Sicherheitslücke zeigt, wie Organisationen Cyber-Risiken durch weit verbreitete Softwarekomponenten übernehmen können, selbst wenn ihre Kerninfrastruktur den Sicherheitsstandards entspricht.

Dieser Vorfall trug zur Häufigkeit von Schäden in der Kategorie „Angriffe auf Content-Management-Systeme“ bei, die laut Branchendaten 2021 einen Anteil von 12 % aller Cyber-Versicherungsschäden ausmachten. Die Sicherheitslücke unterstreicht zudem die Bedeutung einer kontinuierlichen Überwachung von Schwachstellen, da Organisationen, die das Brizy-Plugin einsetzten, über Monate hinweg gefährdet blieben, bis entsprechende Patches installiert wurden.

Für Underwriter stellt dies ein Szenario mit Deckungslücke dar, bei dem Standard-Cyber-Policen möglicherweise nicht ausreichend gegen Verluste durch Schwachstellen in Drittanbieter-Plugins absichern. Der Vorfall verdeutlicht die Notwendigkeit umfassender Risikobewertungsrahmen, die nicht nur die Perimetersicherheit, sondern auch die Software-Lieferkette berücksichtigen.

Technische Details im geschäftlichen Kontext

Das Kernproblem lag im Versagen des Plugins, die Benutzerberechtigungen korrekt zu validieren, bevor Zugriff auf sensible administrative Funktionen gewährt wurde. Praktisch bedeutete dies, dass ein Benutzerkonto mit grundlegenden Subscriber-Rechten potenziell Aktionen ausführen konnte, die normalerweise auf Administratoren beschränkt sind.

Die Sicherheitslücke nutzte das WordPress AJAX-System (Asynchronous JavaScript and XML), das es Webseiten ermöglicht, Inhalte zu aktualisieren, ohne die gesamte Seite neu zu laden. Viele administrative Funktionen in WordPress-Plugins basieren auf AJAX-Aufrufen, was sie zu attraktiven Angriffszielen macht, da Angreifer Aktionen ausführen können, ohne direkt auf die Benutzeroberfläche zuzugreifen.

Aus geschäftlicher Sicht konnte eine Ausnutzung der Schwachstelle zu Website-Defacement, Datenexfiltration, Installation von Backdoors oder der Einbettung von Schadcode führen, der Besuchersysteme kompromittiert. Für Unternehmen, die WordPress für kundenorientierte Websites oder E-Commerce-Plattformen nutzen, können solche Vorfälle zu regulatorischen Geldbußen, Markenschäden und Betriebsunterbrechungen führen.

Der CVSS-Score von 7,4 signalisiert eine hohe Schwere, hauptsächlich aufgrund der geringen Komplexität der Ausnutzung und des potenziell erheblichen Schadens. Die Anforderung einer Authentifizierung bietet zwar eine gewisse Absicherung, jedoch macht die weit verbreitete Verfügbarkeit kompromittierter Zugangsdaten dies zu einem realistischen Angriffsszenario.

Folgen für Deckung und Underwriting

CVE-2020-36714 wirft mehrere Herausforderungen für das Cyber-Underwriting auf. Erstens zeigt es die Schwierigkeit, das Drittanbieter-Risiko während des Underwriting-Prozesses vollständig zu erfassen. Traditionelle Sicherheits-Fragebögen erfassen möglicherweise nicht den vollen Umfang der Plugin-Nutzung oder der Aktualisierungspraxis innerhalb der Webpräsenz einer Organisation.

Für die Schadensbearbeitung fällt diese Sicherheitslücke in einen Graubereich zwischen Erst- und Drittschutz. Während die anfängliche Kompromittierung über ein Drittanbieter-Plugin erfolgt, sind die daraus resultierenden Schäden typischerweise Erstschäden, darunter Betriebsunterbrechungen, Kosten für die Reaktion auf Datenschutzverletzungen und Rufschädigung.

Underwriter sollten diese Art von Sicherheitslücke bei der Bewertung von Organisationen mit umfangreicher Webpräsenz berücksichtigen, insbesondere in Branchen wie Einzelhandel, Dienstleistungen oder anderen Bereichen, in denen die Verfügbarkeit und Integrität der Website entscheidend für den Geschäftsbetrieb ist. Die Häufigkeit von WordPress-Plugin-Schwachstellen ist gegenüber dem Vorjahr um 34 % gestiegen, was diese für das Underwriting zu einem relevanten Risikosignal macht.

Überlegungen zur Risikobewertung

Organisationen, die WordPress nutzen, sollten umfassende Prozesse zur Plugin-Verwaltung implementieren, einschließlich regelmäßiger Schwachstellen-Scans, automatisierter Update-Mechanismen, soweit möglich, und regelmäßiger Sicherheitsüberprüfungen installierter Plugins. Im Durchschnitt nutzen Organisationen 23 WordPress-Plugins, von denen jedes eine potenzielle Angriffsfläche darstellt.

Risikoingenieure sollten nicht nur das Vorhandensein anfälliger Plugins prüfen, sondern auch die Patch-Management-Fähigkeiten der Organisation und die Vorfallreaktionsverfahren für webbasierte Assets bewerten. Die Zeitspanne zwischen Bekanntwerden einer Sicherheitslücke und der Installation eines Patches entscheidet oft darüber, ob eine Organisation von einem erfolgreichen Angriff betroffen wird.

Sicherheitsteams sollten ein Inventar aller Webanwendungen und deren Komponenten führen, inklusive Themes und Plugins, mit Versionsverfolgung und automatisierten Warnungen bei bekannten Sicherheitslücken. Diese Transparenz ist entscheidend, um Vorfälle zu verhindern und im Falle eines Schadens die ordnungsgemäße Sorgfalt nachzuweisen.

Organisationen sollten zudem den Einsatz von Web Application Firewalls (WAFs) mit spezifischen Regeln für WordPress-Angriffe in Betracht ziehen, da diese eine zusätzliche Schutzschicht bieten können, während Patches installiert werden.

Handlungsempfehlungen für Risikoprofis

Versicherungsprofis sollten das Risiko von WordPress-Plugins in ihre Underwriting-Rahmenbedingungen einbeziehen, indem sie detaillierte Bestandsaufnahmen von Webanwendungen und deren Komponenten verlangen. Organisationen sollten aktive Patch-Management-Prozesse nachweisen und Belege für regelmäßige Schwachstellen-Scans ihrer Webressourcen vorlegen.

Für bestehende Versicherungsnehmer sollten Risikoingenieure regelmäßig Überprüfungen der Sicherheitspraktiken für Webanwendungen durchführen, insbesondere bei Organisationen mit kundenorientierten Websites oder E-Commerce-Funktionalitäten. Dazu gehört auch die Bewertung von Backup- und Wiederherstellungsverfahren für Webinhalte und Datenbanken.

Organisationen sollten eine kontinuierliche Überwachung bekannter Sicherheitslücken in ihren Webanwendungskomponenten implementieren. Dies kann durch automatisierte Scantools erreicht werden, die mit Schwachstellendatenbanken integriert sind und Echtzeitwarnungen bei Erkennung anfälliger Komponenten liefern.

Sicherheitsteams sollten klare Verfahren für die Auswahl und Genehmigung von Plugins festlegen, einschließlich Sicherheitsprüfungen vor der Implementierung und regelmäßiger Neubewertungen der Notwendigkeit. Nicht mehr genutzte Plugins sollten zeitnah entfernt werden, um die Angriffsfläche zu reduzieren.

Es ist ratsam, Organisationen zur Integration der Webanwendungssicherheit in ihr Gesamt-Cybersicherheitsprogramm zu verpflichten, mit spezifischen Maßnahmen zur Verwaltung von Drittanbieter-Komponenten. Dazu gehören Schulungen der Mitarbeiter zur sicheren Nutzung von Plugins sowie Vorfallreaktionsverfahren für webbasierte Angriffe.

Schließlich sollten Organisationen ihre Vorfallreaktionspläne für Kompromittierungen von Webanwendungen regelmäßig testen, inklusive Verfahren zur Zusammenarbeit mit Strafverfolgungsbehörden, Aufsichtsbehörden und Kunden im Fall eines erfolgreichen Angriffs über ein anfälliges Plugin.

Wesentliche Erkenntnis

CVE-2020-36714 veranschaulicht, wie Sicherheitslücken in Drittanbieter-Software erhebliche Cyber-Risiken für Organisationen und Versicherer darstellen können. Der Vorfall unterstreicht die Bedeutung einer umfassenden Risikobewertung, die die Software-Lieferkette einbezieht, und zeigt die Notwendigkeit eines proaktiven Schwachstellenmanagements als zentrales Kriterium im Underwriting. Organisationen, die WordPress oder vergleichbare Content-Management-Systeme nutzen, müssen robuste Prozesse zur Plugin-Verwaltung implementieren, um ihre Exposition gegenüber dieser Klasse von Sicherheitslücken zu reduzieren. Versicherer sollten das Risiko von Drittanbieter-Komponenten bei der Deckungs- und Prämienkalkulation berücksichtigen.

Für detaillierte Hinweise zur Quantifizierung solcher Risiken im Rahmen des Underwritings steht unser FAIR-basiertes Risikobewertungsmodell zur Verfügung, das strukturierte Methoden zur Bewertung von Risiken in der Software-Lieferkette bietet.