CVE-2018-6389 PoC Node.js Multisite mit Proxy

Dieses Skript basiert auf CVE-2018-6389, einem ziemlich heimtückischen Problem von WordPress, das leider wahrscheinlich nicht vom Team behoben wird, das die Plattform entwickelt, obwohl es seit einiger Zeit bekannt ist.

!!! WICHTIG BEVOR DU WEITERMACHST !!! Das gesamte Repository und die hier geteilten Informationen dürfen in jeder Form frei verwendet werden – Kopieren, Weiterentwickeln, Ändern zum Zwecke der Verbesserung oder für andere Zwecke, sowie Teilen. Die Verwendung der geteilten Informationen für andere als Schulungszwecke, zu Experimentierzwecken und/oder zum Schutz einer eigenen WordPress-basierten Plattform verstößt wahrscheinlich gegen eine Reihe von Gesetzen, mit denen ich nicht vertraut bin. Verwende das Skript nicht zum Angriff auf Websites! Ich übernehme keine Verantwortung für deine Handlungen. Durch die Nutzung stimmst du diesen Bedingungen zu. Ein DDoS-Angriff (Denial-of-Service) gegen eine Website, die dir nicht gehört, kann als terroristischer Angriff angesehen werden. !!! STELLE SICHER, DASS DU ABSOLUT SICHER IN DEINEN HANDLUNGEN BIST UND DENKE GUT NACH, BEVOR DU WEITERMACHST !!!

Das Skript habe ich vor langer Zeit geschrieben, aber da ich weiß, dass ihr sehr cool seid, habe ich beschlossen, es mit euch zu teilen. Benutzt es bestimmungsgemäß! Wirklich...

Worum es geht

Im Netz gibt es viele Informationen zu diesem Thema, sowie mehrere fertige Skripte, meist in Python geschrieben, wie Shiva und dieses, von denen ich viel Inspiration geschöpft habe, als ich es schrieb, mit denen ihr diese 'Schwachstelle' auch in einer isolierten Umgebung testen könnt, aber da ich ein 'Script-Kiddie' bin, habe ich beschlossen, ein paar 'Goodies' hinzuzufügen.

Hier könnt ihr einen interessanten Blog zu diesem Thema lesen.

Kurz gesagt, wenn ihr https://your-wordpress-site.com/wp-admin/load-scripts.php?c=1&load=editor,common,user-profile,media-widgets,media-gallery ladet (wobei ihr natürlich den Link so ändert, dass er auf eure Instanz zeigt) und das, was auf dem Bildschirm erscheint, 'nix als js, Bruder' ist, dann hat die Seite ein Problem. Jeder aufgeführte Parameter im Query-String ist ein Dateiname, der nicht im Cache ist. Das heißt, es wird eine IO-Operation für jede Datei von der Festplatte durchgeführt, sie werden zusammengeführt und an den Client zurückgegeben. Aber die Dateien sind ziemlich viele. Viel mehr, als Ressourcen erforderlich sind, um sie ein paar Mal anzufragen. Sagen wir, mit einem Laptop und einer 50-Mbit-Downlink-Leitung, etwa 30 Websites mittlerer Güte – Hosting, halten 20-30 Sekunden durch, bevor sie endgültig zusammenbrechen.

Weitere Anforderungen

• NodeJS 8.11.2
• Eine funktionierende WordPress-Instanz/en.
• Es ist erforderlich, eine sehr einfache Überprüfung der einzelnen Proxys auf einem über das Internet erreichbaren Rechner durchzuführen. GET-Anfrage, die als String die IP-Adresse zurückgibt, von der euer Server die Anfrage sieht. Nicht alle Proxys sind 'anonym'! Diese Prozedur validiert auch, dass der Proxy funktioniert, bevor der Angriff beginnt.

Struktur:

• Die Datei websites.js enthält eine Liste von Websites – 'Opfer', aus der ich vergessen habe, einige zu entfernen, von denen ich sicher weiß, dass sie bei Kontakt mit dem Skript anfällig sind. Ich schwöre, dass ich es nie ausprobiert habe, ich denke nur so.

• Die Datei userAgents.js enthält eine Liste von User-Agents, die bei jeder einzelnen Anfrage an die Opfer zufällig ausgewählt werden.

• fileList.js enthält eine Liste der einzelnen Dateien, die vom 'Opfer' geladen werden sollen, damit sie bei einem WordPress-Update leicht hinzugefügt oder korrigiert werden können.

• In index.js befindet sich das eigentliche Ausführungsskript.

Parameter

• countries ist ein Array von Ländern, aus denen Proxys gesucht werden sollen. (Aus welchen Ländern die Angriffe über Proxys kommen sollen)
• wanCheckUrl ist die vollständige Adresse, an die das Skript eine Anfrage stellt und prüft, ob es sich nicht um einen transparenten Proxy handelt.
• requestTimeout ist die Zeit in Millisekunden, nach der ein Proxy als nicht funktionsfähig betrachtet wird, wenn er sich nicht verbunden hat.
• maxRequests ist das Limit der Anfragen von der Maschine an die 'Opfer'. Eine zu große Zahl kann eure Maschine erheblich belasten. Etwa 30 parallele Anfragen sind für eine Website auf Mid-Level-Hosting erforderlich.

Vorgehensweise:

• Das Skript fragt die automatische Proxy-Prüfung ab und speichert die IP-Adresse, mit der es im öffentlichen Raum sichtbar ist.
• Es beginnt mit der Suche nach freien Proxys aus allerlei öffentlichen Listen.
• Bei jedem Erscheinen eines Proxys wird eine Anfrage an die automatische Proxy-Prüfung gestellt, und wenn die Adresse, mit der unser Dienst antwortet, sich von der ersten unterscheidet, wird der Proxy in einem Array gespeichert und die Ausführung des Angriffs beginnt.
• Das Skript rotiert die Opfer etwa nach dem Round-Robin-Prinzip durch jeden Proxy und hat nichts Besonderes in der Logik; es macht einfach so viele Anfragen wie möglich über so viele verschiedene funktionierende Proxys wie möglich.

In der Konsole werden farbig Informationen für jedes 'Opfer' einzeln ausgegeben, und diejenigen, die unter DDoS stehen, werden rot eingefärbt.

npm install
//редактирай webstites.js
node index.js

Google Dork für 'Opfer'

inurl: “wp-admin/load-scripts.php”

Ich habe beschlossen, dieses Skript meinem Lieblingsfernsehsender tvsz zu widmen, weil ich weiß, dass sie große 'Fans' von mir sind, und vor allem, weil sie den Link zu ihrer Website in meiner Liste finden werden. Also, ich werde ihre Bewertung ein wenig steigern, um ihnen einen alten 'Gefallen' zurückzuzahlen. Außerdem nutze ich die Gelegenheit, um Papa zu grüßen, der gestern Namenstag hatte, aber ich hatte keine Zeit, ihn anzurufen.