WordPress Pingback-Angriff
WordPress ist ein Inhaltsverwaltungssystem (CMS), das es einem Autor ermöglicht, seinen Blog auf einer bestimmten Website über eine einfach zu bedienende, in die Seite eingebettete grafische Oberfläche direkt zu bearbeiten. Das System selbst ist sehr funktionsreich und ermöglicht es, eine Reihe von Aufgaben zu automatisieren. Eine solche Aufgabe ist die "Pingback-Funktion", die es dem Autor eines Blogs (nennen wir ihn R) ermöglicht, benachrichtigt zu werden, wenn der Autor eines anderen Blogs (nennen wir ihn T) einen Link zu seinem früheren Blog (R) setzt. In diesem Beitrag geht es um den WordPress-Pingback-Angriff, der nach dieser besonderen Funktion benannt ist.
Wenn T also einen Link zu Rs Blog hinzufügt, sendet Ts Blog eine Nachricht an Rs Blog, die ihn über das Ereignis informiert und Informationen über den Standort des verlinkenden Blogs liefert. Daraufhin lädt R das Blog von T herunter, um zu überprüfen, ob die Anfrage legitim ist. Dies löst eine Rückrufanforderung an T aus.
An Pingback beteiligte Benutzer
Dieses Problem ergibt sich aus der Tatsache, dass es für einen Angreifer A möglich ist, sich als das Blog von T auszugeben, indem er sich mit dem Blog von R verbindet und eine Link-Benachrichtigung sendet, die das Blog von T als Ursprung der Benachrichtigung angibt. In diesem Fall versucht K automatisch, eine Verbindung zu T herzustellen, um den Blogbeitrag herunterzuladen. Dies wird als Reflexion bezeichnet.
Wenn der Angreifer darauf achtet, eine URL auszuwählen, die viele Informationen enthält, würde dies zu einer Verstärkung führen. Mit anderen Worten: Bei einer relativ kleinen Anfrage des Angreifers (A) an den Reflektor wird der Reflektor (R) eine Verbindung zum Ziel (T) herstellen und eine große Menge an Datenverkehr verursachen.
Missbrauch von Pingback zur Durchführung eines Angriffs
Unterm Strich haben wir also sowohl Reflexion als auch Verstärkung, was eine unangenehme Kombination ist. Erinnern Sie sich an all die reflektierten und verstärkten NTP- und DNS-Angriffe, die wir in den letzten drei Jahren erlebt haben?
Das Gute daran ist, dass dieser Angriff über TCP ausgeführt wird, was ihn einigermaßen nachvollziehbar macht, wenn der "X-Pingback-Forwarded-For"-Header nicht deaktiviert ist - oder er kann zurückverfolgt werden, wenn der Ermittler Zugang zu den Protokollen der Reflektoren erhält. TCP erfordert einen 3-Wege-Handshake zwischen den Parteien, damit eine Verbindung hergestellt werden kann, so dass der Rechner, der den Pingback anfordert, zuverlässig in den Protokollen des Reflektors aufgezeichnet wird.
Dies steht im Gegensatz zu NTP und DNS, die UDP als Transportmedium verwenden. Bei UDP ist eine Verhandlung zwischen den Parteien nicht erforderlich; stattdessen kann ein einziges Datagramm eine vollständige Nachricht (Anfrage) transportieren. Dies ermöglicht es dem Angreifer, die Quell-IP-Adresse mit der des Opfers zu verwechseln, was wiederum dazu führt, dass der Reflektor dem Opfer antwortet (dies ist der Teil der Reflexion ). Normalerweise liefern NTP und DNS eine viel größere Antwort als die Anfrage selbst, was die Verstärkung bewirkt.
Schauen wir uns nun genauer an, was tatsächlich passiert. Dieser Abschnitt ist in drei Teile gegliedert: (1) Beschreibung der Kommunikation zwischen dem Angreifer (A) und dem Reflektor (R), (2) der Verkehr zwischen dem Reflektor und dem Ziel (T) und (3) Betrachtung der Ergebnisse.
Angreifer-Reflektor-Verkehr (Trigger-Muster)
Das Auslösemuster ist recht einfach: Es handelt sich um eine einfache POST-Anfrage mit bestimmten Kopfzeilen. Die Nutzlast ist lediglich eine XML-kodierte Anfrage. Im folgenden Screenshot können Sie die Ziel-IP-Adresse 100.74.102.99 und das angeforderte Objekt 1000.html sehen. Beachten Sie auch, dass die Länge der Anfrage unabhängig von ihrer Länge konstant ist, mit einer kleinen Abweichung, wenn die URL länger ist.
Auch die Antwort ist XML-kodiert und hat eine feste Länge.
Zusammengefasst: Die gesamte Konversation umfasst 1076 Bytes - 483 vom Angreifer zum Reflektor und 593 als Antwort. Wie bereits erwähnt, können diese Werte je nach URL-Länge leicht variieren. Auch paketweise sind es 5 bzw. 4 Pakete.
Datenverkehr vom Reflektor zum Ziel (Angriff)
Betrachtet man die Auswirkungen des oben genannten Ersuchens aus der Sicht der Zielperson, so stellt sich die Situation ganz anders dar.
Es beginnt mit einer GET-Anfrage mit relativ konstanter Länge und ihren Headern vom Reflektor (R) zum Ziel (T). Im Gegensatz zu der Antwort mit fester Länge, die wir vom Reflektor zum Angreifer gesehen haben, ist die Größe der Antwort variabel und hängt von der Größe des vom Zielsystem angeforderten Objekts ab.
Die folgenden beiden Screenshots zeigen Anfragen gegen Objekte von 1.000 und 3.000 Bytes.
Anfrage für 1.000-Byte-Objekt
...bzw. 3.000-Byte-Objekt.
Anfrage für 3.000 Byte Objekt
Beachten Sie, dass die Reaktion hier nicht konstant ist und ausschließlich von der Wahl des abzurufenden Objekts abhängt. Dies kann bei einem einzigen Reflektor zu einer starken Verstärkung führen. Wenn mehrere Reflektoren beteiligt sind, skaliert der Angriff ziemlich gut zum Nachteil des Ziels.
Bei näherer Betrachtung der Antworten zeigt sich, dass der Reflektor eine Anfrage mit relativ konstanter Länge stellt - 195 Byte, mehr oder weniger, je nach Reflektor-URL. Die Antwort ist proportional zum Inhalt des angeforderten Objekts und beträgt für ein 1.000-Byte-Objekt 1271, für ein 3.000-Byte-Objekt 3.271 Byte. Grob gesagt, lautet die Formel 271 + Objektgröße. Es handelt sich um eine grobe Formel, da die Fragmentierung von Paketen und einige andere Zusatzkosten eine Rolle spielen.
Das Ergebnis ist jedoch offensichtlich. Auf der Reflektorseite kann die Antwort auf eine 200-Byte-Anfrage leicht Tausende von Bytes umfassen, was zu einer Vervielfachung um das 10-, 20- und mehrfache führt.
Unterm Strich
Unterm Strich muss der Angreifer etwa 500 Bytes an einen Reflektor senden, was weitere 200 Bytes vom Reflektor zum Ziel generiert - aber dann antwortet das Ziel mit einer sehr großen und potenziell rechenintensiven Antwort an den Reflektor, in der Größenordnung von Tausenden von Bytes.
Um eine Überlastung des Reflektors zu vermeiden, können mehrere Reflektoren eingesetzt werden, um den Umfang zu erhöhen. Dadurch werden die ausgehende Bandbreite und möglicherweise die Rechenressourcen des Ziels erschöpft.
Pingback wird mit vielen Reflektoren missbraucht
A → 500 → R1 → 195 → Ziel
A ← 600 ← R1 → X x 1.000 → Ziel
A → 500 → R2 → 195 → Ziel
A ← 600 ← R2 → X x 1.000 → Ziel
A → 500 → R3 → 195 → Ziel
A ← 600 ← R3 → X x 1.000 → Ziel
Ein weiterer zu berücksichtigender Punkt sind die Rechenressourcen, die auf der Zielseite gebunden sind. Bei einer rechenintensiven Seite kann es für den Angreifer effizienter sein, die CPU eines Systems zu überlasten als die Bandbreite der Verbindung.
Milderung
Die Entschärfung ist ziemlich trivial, wenn die richtigen Tools vorhanden sind. In der Angriffsanforderung (Reflektor an Ziel) kann der Benutzer den "User-Agent"-Header sehen, der eindeutig "WordPress" angibt. Unter normalen Umständen sollte dieser User-Agent keine Anfragen stellen, zumindest nicht in hoher Frequenz.
Außerdem fügt WordPress einen Header ein. Dies ist der "X-Pingback-Forwarded-For". Dieser Header verrät die wahre Identität des Angreifers. Wenn eine größere Anzahl von Anfragen von der gleichen IP-Adresse stammt, wäre dies ebenfalls ein guter Grund, diese Anfragen abzulehnen.
Werkzeuge
Abgesehen von den Tools, mit denen eine Dienstverweigerung herbeigeführt werden kann, ist eines von besonderem Interesse, da es dazu verwendet werden kann, einen Host über mehrere Proxys zu scannen, wodurch er für ein IPS möglicherweise weniger sichtbar wird:
https://github.com/FireFart/WordpressPingbackPortScanner
Wenn Sie andere Instrumente kennen, lassen Sie es uns bitte wissen und schicken Sie uns nach Möglichkeit Kopien.
Schlussfolgerung
Dies ist nicht das erste Mal, dass ein CMS, insbesondere WordPress, für DDoS oder andere bösartige Aktivitäten verwendet wird. Das liegt zum großen Teil daran, dass WordPress Nutzer anspricht, die nicht über die Ressourcen für die Verwaltung ihrer Websites verfügen, und diese nutzen WordPress oft, um sich die Arbeit zu erleichtern. Infolgedessen verfügen viele Benutzer nicht über ein angemessenes Patch-Management-Programm oder eine angemessene Überwachung, um Unregelmäßigkeiten in ihrem Datenverkehr zu beobachten.
Sehen ist Glauben.
Vereinbaren Sie noch heute eine Live-Demo.