Risikofaktor WordPress Schwachstelle CVE-2022-3590

Es war heute eigentlich ein Montagmorgen wie jeder andere, als ich plötzlich einen unerwarteten Hilferuf erhielt und im Anschluss über den Risikofaktor WordPress Schwachstelle CVE-2022-3590 stolperte. Ein von einem externen Dienstleister gehostetes Unternehmen war gehackt worden, und der Hack hatte dazu geführt, dass es begann, große Mengen an Spam zu versenden. Während ich in der Folge darauf wartete, den formalen Sicherheitsauftrag schriftlich zu erhalten, überprüfte ich zunächst die Website über einen externen Scan und fand eine ungepatchte WordPress Sicherheitslücke. Binnen Minuten stieß ich auf drei Dinge, die fürchterlich schief laufen, ohne Zugriff auf das kompromittierte System zu haben. Da ich es mag, wenn komplexe Sachverhalte möglichst kleinteilig aufbegröselt und somit verständlich werden, dachte ich mir, ich erkläre das was falsch läuft, in einem Blogbeitrag. Doch der Reihe nach:

Risikofehler: Falscher Umgang mit Spam

Ein Hack ist zunächst einmal ein ernstes Problem, nicht nur wegen der potenziellen Rufschädigung des Unternehmens, sondern auch wegen des Risikos für andere Organisationen. In solchen Fällen müssen die Auswirkungen der Sicherheitsverletzungen schnell bewertet und behoben werden, bevor weiterer Schaden angerichtet werden kann. Seitens des externen Dienstleisters bestand die Schadensbegrenzung leider nur darin, alle ausgehenden Mails zu blockieren und die betroffene Webseite weiter online zu halten.

Die Blockierung ausgehender E-Mails und die gleichzeitige Aufrechterhaltung des Betriebs einer kompromittierten Website können allerdings gleich aus mehreren Gründen problematisch sein:

• Datenverlust: Wenn eine Website kompromittiert wurde und der Angreifer Zugang zu sensiblen Daten wie Kundeninformationen oder geschützten Unternehmensdaten erlangt hat, kann er versuchen, diese Daten per E-Mail zu exfiltrieren. Das Blockieren ausgehender E-Mails kann den Angreifer zwar daran hindern, die Daten erfolgreich zu verschicken, aber das zugrunde liegende Problem der kompromittierten Website wird dadurch nicht behoben. Solange die Website online bleibt, kann der Angreifer weiterhin auf die Daten zugreifen und möglicherweise weitere Daten stehlen.
• Schädigung des Rufs: Wenn die Website eines Unternehmens kompromittiert wurde und der Angreifer in der Lage ist, auf sensible Daten zuzugreifen und diese zu exfiltrieren, kann dies den Ruf des Unternehmens ernsthaft schädigen und zu einem Vertrauensverlust bei den Kunden führen. Selbst wenn ausgehende E-Mails blockiert werden, könnte die Tatsache, dass die Website kompromittiert und möglicherweise ausgenutzt wurde, öffentlich bekannt werden, was zu negativer Publicity und möglichen finanziellen Verlusten führt.
• Rechtliche Konsequenzen: Je nach Art der Daten, die kompromittiert wurden, kann ein Unternehmen rechtliche Konsequenzen ziehen, wenn es seine Website nicht ordnungsgemäß sichert und sensible Informationen nicht schützt. Wenn beispielsweise auf der Website eines Unternehmens personenbezogene Daten von Kunden, wie Namen, Adressen und Kreditkartennummern, gespeichert sind und diese Daten kompromittiert werden, kann das Unternehmen haftbar gemacht werden, weil es die Daten nicht angemessen geschützt hat.

Daher ist es für Unternehmen wichtig, im Falle einer Kompromittierung nicht nur ausgehende E-Mails zu blockieren, sondern auch Maßnahmen zu ergreifen, um ihre Website zu sichern und zukünftige Angriffe zu verhindern. Dazu gehören die Behebung von Schwachstellen, die Einführung strenger Sicherheitsmaßnahmen und die regelmäßige Überwachung verdächtiger Aktivitäten.

Risikofehler: Offene Schwachstellen

Während des Scans stieß ich auf eine Sicherheitslücke, die WordPress an sich schon seit Jahren bekannt war, aber nie wichtig genug, um sie zu schließen. Nun ist dieser Sicherheitslücke allerdings eine CVE (CVE-2022-3590) zugewiesen. Computerschwachstellen oder „CVEs“ (Common Vulnerabilities and Exposures) sind Schwachstellen in Software oder Hardware, die von Angreifern ausgenutzt werden können, um sich unbefugten Zugang zu einem System zu verschaffen oder vertrauliche Informationen zu stehlen. Wenn eine Schwachstelle entdeckt wird, wird sie mit einer eindeutigen Kennung versehen und in die CVE-Datenbank aufgenommen, die von der MITRE Corporation verwaltet wird.

Offene und nicht gepatchte Schwachstellen können ein ernsthaftes Problem für den Ruf eines Unternehmens darstellen, da sie von Angreifern ausgenutzt werden können, um die Sicherheit der Produkte oder Dienstleistungen des Unternehmens zu gefährden. Die kompromittierten Daten tauchen dann regelmäßig im Dark Web. Dies kann schwerwiegende Folgen haben, z. B. Datenverletzungen, Identitätsdiebstahl und finanzielle Verluste. Wenn sich herausstellt, dass die Produkte oder Dienstleistungen eines Unternehmens offene und nicht gepatchte Schwachstellen aufweisen, kann dies dem Ruf des Unternehmens schaden und zu einem Vertrauensverlust bei den Kunden führen.

Offene Schwachstellen und WordPress

Risikofaktor WordPress Schwachstelle CVE-2022-3590

Risikofaktor WordPress Schwachstelle CVE-2022-3590[/caption]WordPress wird von mittlerweile knapp 40% aller Websites im Internet genutzt und die Software ist eine riesige Open Source Erfolgsgeschichte. Eine offene Schwachstelle in einem solch beliebten System führt jedoch zu einem interessanten Dilemma. Um ihren Ruf und die Sicherheit ihrer Produkte und Dienstleistungen zu schützen, verfügen einige Unternehmen über Sicherheitsregeln, die Anwendungen mit offenen CVEs blockieren, unabhängig davon, wie schwerwiegend die Sicherheitslücken tatsächlich sind. Diese Sicherheitsregeln sollen die Verwendung von potenziell anfälligen Anwendungen innerhalb des Unternehmens verhindern, um das Risiko von Angriffen zu verringern. Durch das Blockieren von Anwendungen mit offenen CVEs können Unternehmen sicherstellen, dass ihre Mitarbeiter und Systeme vor bekannten Sicherheitslücken geschützt sind, die von Angreifern ausgenutzt werden könnten.

Wie wird es weiter gehen, wenn WordPress die Sicherheitslücke nicht schließt?

Risikofaktor WordPress Sicherheitslücke CVE-2022-3590: Unauthentifiziertes blindes SSRF über DNS Rebinding

Nun zu den eigentlichen technischen Aspekten. Die WordPress Sicherheitslücke CVE-2022-3590 ist klassifiziert als unauthentifiziertes Blindes SSRF über DNS Rebinding. Doch was sind DNS Rebinding Attacken und was ist ein unauthentifiziertes blindes SSRF?

DNS Rebinding Attacken

Bei der Sicherheitslücke CVE-2022-3590 handelt es sich um eine DNS (Domain Name System) Rebinding Attacke. DNS (Domain Name System) Rebinding ist eine Art von Cyberangriff, bei dem Schwachstellen in der Art und Weise ausgenutzt werden, wie Webbrowser und andere internetbasierte Anwendungen Domänennamen in IP-Adressen auflösen. Bei einem DNS-Rebinding-Angriff nutzt der Angreifer die Tatsache aus, dass diese Anwendungen so konzipiert sind, dass sie DNS-Antworten von dem Server vertrauen, mit dem sie ursprünglich kommuniziert haben.

Um zu verstehen, wie DNS-Rebinding funktioniert, lassen Sie uns eine Analogie verwenden:

Stellen Sie sich vor, Sie versuchen, einen Brief an einen Freund zu schicken, der in einer anderen Stadt lebt. Sie kennen den Namen Ihres Freundes, aber Sie kennen seine Adresse nicht. Also bitten Sie das örtliche Postamt um Hilfe. Das Postamt sucht den Namen Ihres Freundes in einem Verzeichnis und gibt Ihnen die richtige Adresse. Mit dieser Adresse schicken Sie dann den Brief an Ihren Freund.
Ähnlich verhält es sich, wenn Sie den Domänennamen einer Website (z. B. „google.com“) in Ihren Webbrowser eingeben: Ihr Computer sendet eine Anfrage an einen DNS-Server, um die entsprechende IP-Adresse zu ermitteln. Der DNS-Server antwortet mit der richtigen IP-Adresse, und Ihr Browser verwendet diese Adresse, um eine Verbindung mit der Website herzustellen.

Bei einem DNS-Rebinding-Angriff bringt der Angreifer Ihren Computer dazu, eine Anfrage an einen DNS-Server zu senden, den er kontrolliert. Der DNS-Server des Angreifers antwortet mit einer gefälschten IP-Adresse, die auf einen anderen Server zeigt, den der Angreifer ebenfalls kontrolliert. Dieser Server kann dann bösartige Anweisungen an Ihren Computer senden und vorgeben, die legitime Website zu sein, auf die Sie zugreifen wollten.

Unauthentifiziertes blindes SSRF

Server-seitige Anforderungsfälschung (Server-side request forgery, SSRF) ist eine Art von Cyberangriff, bei dem ein Angreifer Schwachstellen in einem Server oder einer Anwendung ausnutzt, um böswillige Anfragen im Namen des Servers oder der Anwendung zu senden. SSRF-Angriffe können dazu verwendet werden, sich Zugang zu internen Netzwerken zu verschaffen, sensible Daten zu stehlen und andere bösartige Aktionen durchzuführen.

Unauthentifiziertes blindes SSRF ist eine spezielle Art von SSRF-Angriff, bei dem sich der Angreifer nicht authentifizieren muss (d. h. einen Benutzernamen und ein Kennwort angeben muss), um den Angriff durchzuführen, und der Angriff ist „blind“, da der Angreifer keine Antwort vom Server oder der Anwendung erhält. Dadurch ist es für den Angreifer schwieriger, den Erfolg oder Misserfolg des Angriffs festzustellen, und auch für die Verteidiger ist es schwieriger, den Angriff zu erkennen.

Unauthentifizierte blinde SSRF-Angriffe können besonders gefährlich sein, weil sie von jedem beliebigen Ort im Internet aus gestartet werden können und weil sie möglicherweise keine sichtbaren Zeichen des Angriffs (z. B. Protokolleinträge oder Fehlermeldungen) hinterlassen. Daher ist es für Unternehmen wichtig, strenge Sicherheitsmaßnahmen zum Schutz vor dieser Art von Angriffen zu ergreifen, wie z. B. die Validierung und Filterung von Eingaben sowie die regelmäßige Prüfung und Überwachung ihrer Server und Anwendungen.

Eine Zwischenlösung für WordPress CVE-2022-3590

Im Fall des Risikofaktor WordPress Schwachstelle CVE-2022-3590 gibt es übrigens einen Fix, der zwar nicht auf besserem Coding beruht, aber zumindest das Symptom abstellt. Das Problem liegt einmal mehr in XML-RPC.

XML-RPC (Extensible Markup Language Remote Procedure Call) ist ein Protokoll, das es Anwendungen ermöglicht, über das Internet miteinander zu kommunizieren. XML-RPC wird von vielen beliebten Softwareanwendungen verwendet, darunter eben auch WordPress.

XML-RPC-Angriffe sind eine Art von Cyberangriffen, die Schwachstellen in der Art und Weise ausnutzen, wie XML-RPC in WordPress und anderen Anwendungen implementiert ist. Diese Angriffe können dazu verwendet werden, eine Vielzahl bösartiger Aktionen durchzuführen, wie z. B. das Anlegen neuer Benutzer, das Löschen von Inhalten und sogar die Übernahme der gesamten Website.

XML-RPC-Angriffe auf WordPress haben eine lange Geschichte. Bei diesen Angriffen nutzten Hacker automatisierte Tools, um das Internet nach WordPress-Websites mit offenen XML-RPC-Schnittstellen zu durchsuchen, und nutzten dann Schwachstellen in diesen Schnittstellen aus, um unbefugten Zugriff auf die Websites zu erhalten.

In den Jahren seit diesen ersten Angriffen hat WordPress eine Reihe von Sicherheitsmaßnahmen zum Schutz vor XML-RPC-Angriffen ergriffen, wie z. B. die standardmäßige Deaktivierung der XML-RPC-Schnittstelle und die Aufforderung an die Benutzer, sie bei Bedarf manuell zu aktivieren. WordPress-Websites, die ihre XML-RPC-Schnittstellen nicht ordnungsgemäß gesichert haben, können jedoch immer noch für diese Art von Angriffen anfällig sein.

Um sich vor XML-RPC-Angriffen zu schützen, ist es für WordPress-Benutzer wichtig, ihre Software mit den neuesten Sicherheits-Patches auf dem neuesten Stand zu halten und bei der Aktivierung und Verwendung der XML-RPC-Schnittstelle vorsichtig zu sein. Außerdem sollten Sie Ihre Website regelmäßig auf verdächtige Aktivitäten überwachen und strenge Sicherheitsmaßnahmen wie sichere Passwörter und eine Zwei-Faktor-Authentifizierung einführen.

Im konkreten Fall liegt die Schwachstelle auf der XMLRPC Pingback Funktion.

Schwachstelle: XML-RPC Pingback Funktion

In WordPress ist ein Pingback eine Art von Linkback, der automatisch generiert wird, wenn ein WordPress-Blog auf ein anderes WordPress-Blog verlinkt. Wenn ein WordPress-Blog einen Link zu einem anderen WordPress-Blog postet, erhält das verlinkte Blog eine Benachrichtigung, ein sogenanntes Pingback, das ihm mitteilt, dass der Link hinzugefügt wurde. Der verlinkte Blog kann dann entscheiden, ob er den Pingback als Kommentar oder Link auf seiner Website anzeigen möchte, um den Link zu würdigen und die Diskussion anzuregen.

Pingbacks können eine nützliche Funktion für WordPress-Benutzer sein, da sie es Bloggern ermöglichen, Links zu ihrer Website einfach zu verfolgen und sich an Diskussionen mit anderen Bloggern zu beteiligen. Pingbacks können jedoch auch von Angreifern für Pingback-Spam-Angriffe genutzt werden, bei denen sie eine große Anzahl von Pingbacks an einen WordPress-Blog senden, um die Website mit Spam-Kommentaren oder Links zu überschwemmen.

Zum Schutz vor Pingback-Spam-Angriffen bietet WordPress eine Reihe integrierter Sicherheitsmaßnahmen, wie z. B. die Ratenbegrenzung (die die Anzahl der Pingbacks begrenzt, die von einer einzigen Quelle empfangen werden können) und die Spam-Filterung. WordPress-Benutzer können auch zusätzliche Maßnahmen ergreifen, um ihre Website vor Pingback-Spam zu schützen, z. B. die Deaktivierung von Pingbacks und Trackbacks oder die Verwendung eines Plugins zur weiteren Filterung und Überwachung eingehender Pingbacks.

Für die dritte Januarwoche ist ein Proof of Concept (PoC) angekündigt. Ein PoC)in der IT-Sicherheit ist eine Demonstration, die zeigt, wie eine Schwachstelle oder ein Exploit genutzt werden kann, um ein Computersystem oder Netzwerk zu kompromittieren. Auf diese Weise können Forscher beweisen, dass eine bestimmte Schwachstelle oder ein Exploit existiert und ausgenutzt werden kann, ohne tatsächlich einen Angriff durchzuführen.

Somit liegt der einfachste Fix in der Zwischenzeit übrigens leider erstmal darin, den sehr hilfreichen pingback.ping auf dem XMLRPC Endpunkt abzuschalten, etwa indem wir im Theme Verzeichnis der Datei functions.php folgenden Code hinzufügen:

add_filter('xmlrpc_methods', function($methods) {

});
Mittlerweile ist es Montag Abend, die Vertragsunterlagen sind immer noch nicht durch, aber ich hoffe zumindest, dem ein oder anderen Leser ein paar Einblicke gegeben zu haben und auch dazu beigetragen zu haben, dass nicht noch eine weitere XML-RPC Schwachstelle demnächst massenhaft ausgenutzt wird.