APT: MIRAI come caso di studio

Transcript

1 APT: MIRAI come caso di studio analisi della botnet responsabile del più grande attacco DDoS della storia di Internet Gruppo Rete Telematica del CNR di PISA IIT Cybersecurity Lab

2 0.1 Obiettivi Analisi della botnet MIRAI analisi del codice analisi architetturale analisi comportamentale Accorgimenti per la sicurezza dei dispositivi IoT

3 0.2 Contenuti 1. Concetti introduttivi a. worm, botnet, DDoS, IoT 2. Evoluzione delle botnets 3. Lo scenario IoT 4. MIRAI: introduzione a. in the news, lo scenario 5. MIRAI: l architettura a. I componenti 6. MIRAI: il processo di infezione 7. MIRAI: analisi del codice a. bot, loader 8. Sicurezza dei dispositivi IoT 9. Riferimenti

4 1.0 Concetti introduttivi worm: un programma standalone, auto replicante ed avente lo scopo di diffondersi verso altri computers. Tipicamente la diffusione avviene tramite Internet; attacco DDoS: è un cyber attacco in cui l attaccante cerca di impedire, agli utenti autorizzati, l accesso ad un nodo o ad una risorsa di rete; Internet of Things (IoT): con Internet delle cose si intende l insieme di tutti quei dispositivi intelligenti (embedded o smart) che, dotati di connettività Internet, sono capaci di scambiare le informazioni da essi collezionate con altri dispositivi.

5 1.1 Concetti introduttivi master-slaves botnet: un numero di nodi (chiamati bots, slaves o zombies), connessi via Internet ad un nodo centrale (il master) il quale è in grado di comunicare contemporaneamente con tutti i bots al fine di coordinare le loro azioni (CNC, C&C o C2).

6 2.0 Evoluzione delle botnets Proto botnet C++ staged CC & home banking fast-flux GM-Bot 1989 Sub7 & Pretty Park 1999 SDBot & Agobot 2002 ZeuS 2006 Conficker 2008 Ramnit IRC 1993 EGGDROP 2000 GT-Bot 2003 Spybot & Beagle 2007 Cutwail 2009 KOOBFACE 2014 Neutrino 2017 Delta Charlie Management & Gaming IRC mirc botnet IRC war & DDoS keylogging data mining spamming social network RAT

7 2.1 Evoluzione delle botnets GM-Bot 1989 Sub7 & Pretty Park 1999 SDBot & Agobot 2002 ZeuS 2006 Conficker 2008 Ramnit 2011 MIRAI IRC 1993 EGGDROP 2000 GT-Bot 2003 Spybot & Beagle 2007 Cutwail 2009 KOOBFACE 2014 Neutrino 2017 Delta Charlie

8 3.0 Lo scenario IoT È uno scenario in continua espansione: in tutto il mondo, 3.9 miliardi di IoT consumer devices erano in uso nel 2016 ed è previsto che nel 2020 si arriverà a 12.8 miliardi! Terreno fertile per malware che bersaglia IoT consumer devices!

9 3.1 Lo scenario IoT Focus sull evoluzione di botnet IoT 2012 Carna 2014 BASHLITE 2016 MIRAI 2012, Carna: botnet creata per censire IoT devices con password deboli 2014, BASHLITE: botnet che, per propagarsi, combinava sfruttava la debolezza delle credenziali dei dispositivi IoT e la vulnerabilità di Bash, Shellshock.

10 3.2 Lo scenario IoT MIRAI (futuro, in Giapponese) è un esempio recente di IoT malware. È comparso per la prima volta su Internet a Settembre Tweets di Octave Klaba il CTO di OVH che annunciavano un DDoS > 1TBps. Il codice sorgente è stato reso pubblico da Ottobre 2016.

11 3.3 Lo scenario IoT MIRAI trasforma i sistemi Linux (con BusyBox, tipici dei dispositivi IoT) in bots controllati da remoto al fine di far parte di una botnet per attacchi di rete su larga scala.

12 4.1 In the news

13 4.2 Lo scenario Dispositivi infetti rilevati tra il 2 ed il 3 Aprile 2017

14 5.0 MIRAI: l architettura CNC (*): è il command & control server attraverso il quale i botnet masters possono coordinare i bots. (Scritto in: Go Programming Language) Non è stato oggetto della nostra analisi! (*) fast-fluxed

15 5.1 MIRAI: l architettura Bot: i dispositivi embedded infetti in attesa di comandi (provenienti dal CNC) e che allo stesso tempo scansionano l Internet (*) alla ricerca di nuovi dispositivi vittima. Scritto in: Linguaggio C

16 5.2 MIRAI: l architettura Loader (*): può proattivamente infettare dispositivi (aspetta stringhe del tipo ip:port user,pass, fornitegli attraverso lo standard input). Riceve connessioni provenienti da quei bots che riportano al loader l individuazione di una nuova vittima. Scritto in: Linguaggio C (*) anch esso è fast-fluxed!

17 6.0 MIRAI: il processo di infezione Step 1 Il loader, già in possesso delle informazioni di contatto, prova a connettersi al dispositivo vittima... 1

18 6.1 MIRAI: il processo di infezione Step 2...il loader cerca di determinare se il dispositivo vittima è effettivamente infettabile

19 6.2 MIRAI: il processo di infezione Step 3...avendo appurato che il dispositivo è infettabile, il loader fa scaricare alla vittima l eseguibile MIRAI che una volta eseguito trasformerà il dispositivo in un bot

20 6.3 MIRAI: il processo di infezione Step 4...il nuovo bot, si collega al CNC in attesa di comandi. 4 3

21 6.4 MIRAI: il processo di infezione Un nuovo bot è ora connesso al CNC. Da parte sua, il nuovo bot comincia a scansionare Internet per individuare nuovi dispositivi vulnerabili...

22 6.5 MIRAI: il processo di infezione Step 1...il bot individua un nuovo dispositivo vulnerabile... 1

23 6.6 MIRAI: il processo di infezione Step 2...riporta al loader le informazioni di contatto del nuovo dispositivo vittima

24 6.7 MIRAI: il processo di infezione Step 3...il loader completa l infezione del nuovo dispositivo vittima

25 6.8 MIRAI: il processo di infezione

26 7.0 MIRAI: analisi del codice del bot Auto cancellazione: alla prima esecuzione, il bot elimina se stesso dal filesystem. Anti reboot: i dispositivi embedded sono dotati di watchdog timers che agiscono per riavviare il dispositivo in caso di anomalia. L eseguibile MIRAI va a riprogrammare i watchdogs in modo tale da non far MAI riavviare il dispositivo. Il MER è un emblematico dispositivo embedded remoto ed automatizzato. I watchdogs sono essenziali per il suo corretto funzionamento.

27 7.1 MIRAI: analisi del codice del bot Le informazioni vitali (*) per il corretto funzionamento del bot sono hard coded in apposite strutture all interno del suo codice sorgente. Tali informazioni sono offuscate staticamente, mediante tecniche crittografiche. Inoltre, un PRNG efficiente è implementato nel malware stesso. L autore si è servito di queste tecniche per rendere più difficile l analisi del malware.

28 7.2 MIRAI: analisi del codice del bot uint32 x, y, z, w; input init (x, y, z, w) output // seeds initialization void rand_init() { x = now(); y = getpid() getppid(); z = clock(); w = z y; } Algoritmo PRNG: Xorshift128 avente periodo ( ) // PRNG uint32 rand_next() { uint32 t = x; t = t (t << 11); t = t (t >> 8); x = y; y = z; z = w; w = w (w >> 19); w = w t; return w; }

29 7.3 MIRAI: analisi del codice del bot // initialization of the structure called table... add_entry(table_cnc_domain, "\x41..\x22"); // cnc.foo.com add_entry(table_cnc_port, "\x22\x35"); // 23 add_entry(table_scan_cb_domain, "\x50..\x22"); // report.foo.com add_entry(table_scan_cb_port, "\x99\xc7"); // Le informazioni vitali sono memorizzate all interno di una struttura ( table ) sotto forma di stringhe di bytes.

30 7.4 MIRAI: analisi del codice del bot Debolezza dell algoritmo di cifratura! {[(b k 0 ) k 1 ] k 2 } k 3 = = b (k 0 k 1 k 2 k 3 ) = = b (0xDE 0xAD 0xBE 0xEF) = = b 0x22 = b 34 // buggy obfuscation... uint32 key = 0xdeadbeef; void toggle_obfuscation(i) { k0 = key[0].. k3 = key[3] for (j=0;j<len(tab[i]);j++) { uint8& b = tab[i][j]; b = b k0; b = b k1; b = b k2; b = b k3; } }... L autore credeva di usare una chiave a 32 bit, ma di fatto la chiave è lunga solo 8 bit! Lo scopo di offuscare/deoffuscare l informazione a runtime è rendere più difficile l analisi dinamica (tecniche anti gdb).

31 7.5 MIRAI: comportamento del bot Al primo avvio il bot genera una stringa alfanumerica casuale (utilizzando il PRNG) per cambiare il nome del processo di MIRAI con uno incomprensibile. Il bot avvia 2 processi figli: 1) il gestore della scansione 2) il gestore della terminazione di processi concorrenti e/o sospetti Il parsing delle richieste d attacco avviene nel processo padre (che quindi è anche gestore degli attacchi).

32 7.6 MIRAI: comportamento del bot Il gestore degli attacchi gestisce la connessione con il CNC e attende le richieste di attacco. La richiesta d attacco ha una struttura precisa. Le informazioni obbligatorie che essa deve contenere sono: il vettore d attacco, gli obiettivi, e la durata. In base al vettore d attacco altre informazioni possono essere incluse nella richiesta (chiave=valore). I vettori d attacco più importanti implementati sono i seguenti: UDP flood TCP SYN and ACK flood DNS water torture HTTP layer 7 flood

33 7.7 MIRAI: comportamento del bot ipv4 get_random_ip() { uint32 d; uint8 o1, o2, o3, o4; do { d = rand_next(); o1 = d & 0xff; o2 = (d >> 8) & 0xff; o3 = (d >> 16) & 0xff; o4 = (d >> 24) & 0xff; } while (!ip_is_valid(o1,.., o4)); return d; } Il gestore delle scansioni autonomamente cerca di scoprire nuove vittime da riportare al loader. Le infezioni avvengono sulla porta 23 (90%) e la 2323 (10%) gli IPv4 candidati sono scelti basandosi sul PRNG visto in precedenza. La funzione ip_is_valid(.) restituisce false se l IP esaminato è un indirizzo privato o broadcast/multicast oppure se è un indirizzo appartenente alle reti di General Electric, HP, US Postal Service e Department of Defense.

34 7.8 MIRAI: comportamento del bot // obfuscated auth entries... add_auth_entry("\x50\x4d\x4d\x56", "\x49\x4e\x54\x13\x10\x11\x16"); // root, klv1234 add_auth_entry("\x50\x4d\x4d\x56", "\x78\x56\x47\x17\x10\x13"); // root, Zte521 add_auth_entry("\x50\x4d\x4d\x56", "\x4a\x4b\x11\x17\x13\x1a"); // root, hi3518 add_auth_entry("\x50\x4d\x4d\x56", "\x48\x54\x40\x58\x46"); // root, jvbzd... Il processo di scansione consiste semplicemente nel connettersi da remoto al dispositivo vittima utilizzando credenziali scelte a partire da un set (circa 60 paia) hard coded nel codice. Tra queste credenziali si riconoscono molte paia utilizzate di default (factory default credentials) da i maggiori vendor di dispositivi IoT.

35 7.9 MIRAI: comportamento del loader Il loader ha un architettura multi-threaded basata sulla libreria C Linux POSIX thread. Il main thread ascolta costantemente in attesa di connessioni provenienti dai bots che notificano (con ip:port user,pass ) l avvenuto rilevamento di un nuovo dispositivo vittima. Queste informazioni vengono passate ad un worker thread che completa l infezione. Al fine di completare l infezione, il worker thread prova a connettersi al sistema remoto sul quale esso può eseguire comandi Linux via BusyBox.

36 7.10 MIRAI: comportamento del loader Ciascuna infezione condotta dal loader è tracciata all interno del working thread mediante una struttura dati ad hoc chiamata connection descriptor. Nel connection descriptor vengono memorizzate informazioni sul dispositivo vittima come ad esempio le directories su cui il loader ha il permesso di scrittura, l architettura hardware del dispositivo, etc.

37 7.11 MIRAI: comportamento del loader Il loader: deve conoscere l architettura hardware del dispositivo vittima al fine di infettarlo con l eseguibile adatto a quella architettura; può scegliere, ovviamente, l eseguibile da un set di eseguibili compilati in precedenza (cross-compilazione); è in grado di infettare le seguenti architetture hardware: arm, arm7, x86, m68k, mips, ppc, sh4, spc.

38 7.12 MIRAI: comportamento del loader Quando una directory scrivibile viene individuata il loader può scegliere tra 3 metodi diversi per effettuare l upload del malware. I metodi sono nell ordine WGET, TFTP e ECHO! Una volta che il processo di upload è completato il file caricato viene eseguito (*) e la connessione con il loader viene chiusa.

39 8.0 Sicurezza dei dispositivi IoT Se si ha la necessità di accedere da remoto via TELNET al dispositivo IoT: -> modificare la configurazione del demone affinché risponda su una porta diversa da TCP 23 o Se non si ha la necessità di accedere da remoto via TELNET al dispositivo IoT: -> spegnere il demone TELNET; problema: watchdog -> limitare l accesso solo da determinati (fidati) prefissi di rete.

40 8.1 Sicurezza dei dispositivi IoT Se i dispositivi IoT non fossero stati venduti con factory default usernames e passwords statici e globali, probabilmente, MIRAI non sarebbe mai esistita! -> Evitare questi dispositivi insicuri by design. Golden Rule SEMPRE, cambiare sia il default username (se possibile) sia la default password, validi per l accesso remoto ai dispositivi presenti nella nostra rete!... admin, smcadmin root, password root, 1234 root, klv123 service, service supervisor, supervisor guest, guest guest, admin1, password administrator, 1234 ubnt, ubnt root, klv1234 root, Zte521 root, hi3518 root, jvbzd root, anko root, zlxx....

41 9.0 Riferimenti [1] A. K. Tyagi, G. Aghila. A Wide Scale Survey on Botnet. Novembre 2011 [2] C. Schiller, S. Fogie, C. DeRodeff, M. Gregg. InfoSecurity Threat Analysis [3] R. Ferguson. 'The Botnet Chronicles, A Journey to Infamy'. Trend Micro, Inc [4] 'Gartner Says 8.4 Billion Connected "Things" Will Be in Use in 2017, Up 31 Percent From 2016'. Gartner, Inc. Febbraio [5] Anna-senpai. Mirai source code. Ottobre 2016 [6] M. Schallner. Basic Linux Anti Anti Debugging Techniques. Maggio 2006 [7] 'Who Makes the IoT Things Under Attack?'. KrebsOnSecurity. Ottobre 2016.

42 Grazie per l attenzione. Domande? Filippo Lauria <filippo.lauria@iit.cnr.it>