Transcript
00:00:00WordPress hatte in letzter Zeit eine Reihe von Schwachstellen, und die neueste ist so schwerwiegend,
00:00:04dass Hacker die vollständige Kontrolle über das Admin-Panel erlangen können. Wir sprechen hier von SQL-Injektionen, dem Ausführen von
00:00:09Shell-Befehlen – ziemlich übel. Und vielleicht schert Sie WordPress nicht, aber es betreibt immer noch über 44 %
00:00:14aller Websites weltweit. Viele der Websites, mit denen Sie interagieren und denen Sie Ihre Daten anvertrauen,
00:00:19könnten also mit WordPress und dieser anfälligen Version laufen. Es funktioniert im Grunde so:
00:00:25Ich habe lokal eine Standardversion von WordPress installiert und kann dieses
00:00:29erste Skript ausführen, um zu sehen, ob die Schwachstelle vorhanden ist. Wie Sie sehen, erhalten wir die Antwort
00:00:34HTTP 207, was bedeutet: Ja, sie ist tatsächlich anfällig. Das heißt, wir können jetzt die zweite Prüfung ausführen,
00:00:41nämlich das Aufrufen der interaktiven Shell. Dies führt eine SQL-Injektion auf der Seite aus, erstellt einen brandneuen Admin-Benutzer
00:00:47und lädt dann ein bösartiges Plugin hoch, mit dem ich nun mit jeder Datei auf dieser Website interagieren kann.
00:00:52Tauchen wir also in das Problem ein und schauen uns genau an, wie es funktioniert.
00:00:58Dieses Repository, das ich mir hier ansehe, zeigt genau, wie man anfällige WordPress-Seiten per SQL-Injektion angreift. Das betrifft
00:01:06jede Seite zwischen 6.90 und 6.94 oder 7.00 und 7.01. Der gesamte Angriff beginnt mit dem Aufruf eines unauthentifizierten
00:01:14Endpoints batch v1, mit dem Sie andere Anfragen bündeln können, die selbst validiert und auf Berechtigungen
00:01:20geprüft werden. Der Batch-Handler verfügt über zwei parallele Arrays, die synchron bleiben sollten: validation und matches.
00:01:26Ein Fehler führte jedoch dazu, dass bei einem Fehlschlag der Funktion wp pass URL files aufgrund eines ungültigen Pfads nur validation aktualisiert wurde.
00:01:33Derselbe Index, mit dem beide Arrays abgefragt wurden, lieferte nun also nicht übereinstimmende Ergebnisse. Der PoC nutzt dies aus:
00:01:41Er sendet einen Batch, der nur eine Anfrage enthält – einen POST an den v2-POST-Endpoint, der selbst einen Request-Body enthält.
00:01:48Da die übergeordnete Anfrage korrekt als POST-Anfrage validiert wurde, umgehen alle Anfragen im Request-Body schließlich die Method-Allowlist,
00:01:56sodass Sie GET-Anfragen senden können. Innerhalb dieses inneren Batches befindet sich dann eine GET-Anfrage an einen nicht existierenden Beitrag, was die
00:02:02vorherige Desynchronisation auslöst. Dies veranlasst WordPress dazu, dieselbe Anfrage unter einer Funktion namens get items zu verarbeiten, bei der ein Feld author
00:02:10exclude auf author not in abgebildet wird, was der anfällige Build als String in SQL interpoliert. Im Grunde liegt es daran, dass dies alles läuft,
00:02:18dass das SQL nicht escaped wird. Der PoC nutzt eine Reihe von Anfragen, die es letztendlich einer POST-Anfrage an v2 users ermöglichen,
00:02:25ein neues Admin-Konto zu erstellen. Das Repo geht all diese Schritte im Detail durch. Die ersten fünf erfolgen vor der Authentifizierung und nutzen die Schwachstelle aus, aber Schritt sechs ist ganz normales WordPress-Verhalten für
00:02:35authentifizierte Benutzer – nämlich das Hochladen eines bösartigen Pakets. Wie bereits erwähnt, handelt es sich hierbei um die Standardversion von WordPress. Die Schwachstelle wird nicht über ein bösartiges Plugin ausgenutzt,
00:02:46Sie können einfach ein Standard-WordPress installieren. Wir führen zuerst dieses Prüfskript aus, das im Grunde validiert, ob die
00:02:52Schwachstelle ausnutzbar ist. Dann können wir zum Beispiel diesen read-Befehl ausführen, der uns Dinge verrät wie den
00:02:57Datenbankbenutzer und den Datenbanknamen. Wir können jetzt auch SQL-Befehle gegen die Website ausführen, um beispielsweise herauszufinden,
00:03:03welche Version der Datenbank tatsächlich läuft. Und das ist noch gar nicht das Schlimmste – das hier ist der wirklich gefährliche
00:03:07Teil, bei dem wir tatsächlich ein Admin-Konto erstellen, das die Berechtigung hat, ein bösartiges Plugin hochzuladen. In diesem
00:03:15Fall heißt es web shell. Damit erhalten wir Zugriff auf die Shell der Website, was bedeutet, dass wir jetzt Zugriff auf
00:03:22jede beliebige Datei auf dieser Website haben. Und dieser Angriff läuft genau so ab, wie wir es vorhin im Video erklärt haben:
00:03:27Nachdem der Admin erstellt wurde, wird das Plugin hochgeladen und schließlich wird dieser Benutzer gelöscht, sodass die Existenz
00:03:34des Plugins und was passiert ist, unauffälliger bleibt. Um zu demonstrieren, wie schlimm das ist, habe ich ein separates Skript erstellt,
00:03:38das einen Admin erstellt und ihn dann auf dem System belässt.
00:03:40Hier habe ich also einen Benutzernamen und ein Passwort. Ich bin zurück auf der Website, gehe zum wp-login-Pfad, gebe diesen
00:03:47Benutzernamen und das Passwort ein, klicke auf Anmelden und habe jetzt vollen Zugriff auf das Admin-Panel. Wenn das alles verwirrend klingt, keine Sorge –
00:03:54ich habe auch lange gebraucht, um es zu verstehen. Es wird behauptet, dass die resultierende Exploit-Kette so absurd
00:04:00komplex war, dass ein menschlicher Sicherheitsforscher Wochen, wenn nicht Monate gebraucht hätte, um sie zu entdecken und
00:04:05zusammenzufügen. Allein hätte kein Sicherheitsforscher diese Exploit-Kette
00:04:10in 10 Stunden ohne KI finden und fertigstellen können. Das ist ziemlich beängstigend, da Angreifer praktisch Bots einsetzen könnten, die
00:04:17Repos scannen, URLs überprüfen, nur darauf warten, dass Schwachstellen auftauchen, und diese mithilfe von KI in Rekordzeit ausnutzen.
00:04:23Ein Benutzer auf Reddit sagte, dass seine Seite nur zwei Tage nach der Entdeckung kompromittiert wurde.
00:04:27Da sie Updates nur am Wochenende durchführen, konnte ein Angreifer in der Zwischenzeit einen neuen Admin erstellen und sich auf den
00:04:33anfälligen Seiten einloggen. Der Exploit wurde in Version 7.0.2 behoben, Sie können also darauf aktualisieren – aber das ist schon eine verrückte Sache.
00:04:40Sie finden das Repo und den Artikel, den ich für den PoC verwendet habe, in den Kommentaren. Und warum
00:04:46abonnieren Sie nicht Better Stack, um über alle Tech-News auf dem Laufenden zu bleiben? Ich hoffe, es hat euch gefallen, Leute, und
00:04:50wie immer sehen wir uns beim nächsten Mal!