Malware, Reverse Code Engineering and Cyber Threat Intelligence - SUPSI M00002
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Malware, Reverse Code Engineering and
Cyber Threat Intelligence
Studente/i Relatore
Furger Nino Consoli Angelo
Correlatore
-
Committente
SUPSI
Corso di laurea Modulo
Ingegneria informatica M00002
(Informatica TP)
Anno
2018
Data
31 agosto 2018
i
Indice
1 Abstract 1
1.1 Italiano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 English . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Progetto assegnato 3
2.1 Descrizione del compito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Precisazione sulle tematiche . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Pianificazione 5
3.1 Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Analisi SmartLock 7
4.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1 Il prodotto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 Analisi del protocollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1 I tools necessari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Analisi dell’applicazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.1 Analisi statica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.2 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4 NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.5 Traffico di rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5.1 Breve guida all’attacco MITM . . . . . . . . . . . . . . . . . . . . . . . 21
5 Analisi Samsung SmartTV 25
5.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1.1 Modello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 Analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Attacchi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.1 Exploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.2 Samsung Smart View . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Malware, Reverse Code Engineering and Cyber Threat Intelligence
ii INDICE
6 Cyber-attacco di tipo RAT 29
6.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2 Pupy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3 Componenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.4 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.5 Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.6 Pupy vs antivirus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.7 Offuscamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.7.1 Excursus su VirusTotal . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.7.2 Veil evasion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.7.3 Hyperion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.7.4 Shellter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.7.5 Compilare python a exe . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.7.6 Nascondere manualmente il codice . . . . . . . . . . . . . . . . . . . 37
6.8 Vettori di infezione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.8.1 Eseguibile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.8.2 PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.8.3 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.8.4 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.8.5 Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.8.6 Hardware-Rubberducky . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.9 Utilizzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7 Conclusioni 43
7.1 Problemi riscontrati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Malware, Reverse Code Engineering and Cyber Threat Intelligence
iii
Elenco delle figure
3.1 Diagramma di Gantt pianificato . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Diagramma di Gantt effettivo . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 SmartLock da noi analizzato . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Adafruit bluetooth sniffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3 Svariati pacchetti catturati nel processo di autenticazione . . . . . . . . . . . 9
4.4 Sorgenti ottenuti da jadx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5 Una delle classi ottenute dalla decompilazione . . . . . . . . . . . . . . . . . 11
4.6 Una sessione di debug con alcune variabili visibili . . . . . . . . . . . . . . . . 13
4.7 Svariate variabili offuscate in una sessione di debug . . . . . . . . . . . . . . 15
4.8 Schermata principale di mifare classic tool . . . . . . . . . . . . . . . . . . . . 16
4.9 Visualizzazione del dump di una chiave MiFare . . . . . . . . . . . . . . . . . 17
4.10 Pacchetti catturati in cui si può vedere l’autenticazione dell’utente . . . . . . . 19
4.11 Schermata principale di ettercap . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.12 menu di selezione dei target . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.13 lista di connessioni catturate da ettercap . . . . . . . . . . . . . . . . . . . . . 23
5.1 Smart TV Samsung modello 2017 da 24 pollici[Samsung(2017)] . . . . . . . . 26
5.2 Immagine di esempio si Samsung Smart View . . . . . . . . . . . . . . . . . 27
5.3 Possibili exploit per upnp 1.0 trovati con searchsploit . . . . . . . . . . . . . . 27
5.4 Opzioni disponibili per il modulo metasploit scelto . . . . . . . . . . . . . . . . 28
6.1 Metodi di codifica disponibili per veil-evasion . . . . . . . . . . . . . . . . . . 33
6.2 Opzioni disponibili per l’encoder scelto . . . . . . . . . . . . . . . . . . . . . . 34
6.3 Prompt di Shellter con lista di payload utilizzabili . . . . . . . . . . . . . . . . 36
6.4 Adafruit trinket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.5 Lista di comandi disponibili su pupy . . . . . . . . . . . . . . . . . . . . . . . 41
Malware, Reverse Code Engineering and Cyber Threat Intelligence
iv ELENCO DELLE FIGURE Malware, Reverse Code Engineering and Cyber Threat Intelligence
1
Capitolo 1
Abstract
1.1 Italiano
Il progetto prevede tre compiti separati, tutti nell’ambito della sicurezza informatica:
• l’analisi della sicurezza di un lucchetto elettronico
• l’analisi della sicurezza di una SmartTV
• lo studio di un malware in svariati aspetti (sviluppo, infezione etc)
Sono state eseguite svariati tipi di analisi sul lucchetto in questione, considerando metodi di
attacco completamente differenti e valutando la bontà degli attacchi in base alla loro fattibilità
e facilità di esecuzione.
La stessa cosa è stata fatta con la Smart TV, ma utilizzando tipologie di attacco differenti
per via delle superfici di attacco completamenti diverse.
Io studio del malware è stato eseguito analizzando un malware open source, mettendosi
nei panni di un attaccante e dunque tentando di sviluppare un software in grado di non
essere rilevato dalle comuni soluzioni di protezione come gli antivirus. Oltre a ciò sono stati
sviluppati dei vettori di infezione per permettere al suddetto virus di spargersi il più possibile
tramite la rete.
I risultati ottenuti sono piuttosto incoraggianti nella maggior parte dei casi: Nel primo si
siamo stati in grado di individuare falle importanti nella sicurezza dello smart lock, che sono
state opportunamente comunicate al produttore dello stesso. Nel secondo abbiamo ottenuto
un virus in grado di non farsi rilevare dai maggiori antivirus e di espandersi infettando sempre
più macchine utilizzando più metodi di infezione. Per quanto riguarda la SmartTV invece non
abbiamo trovato nessuna falla di grande importanza, anche se questo non esclude alcuni
attacchi da non sottovalutare.
Malware, Reverse Code Engineering and Cyber Threat Intelligence
2 Abstract
1.2 English
This project is made of three smaller tasks, both in the field of Cyber Security:
• a security analysis of a electronic doorlock
• a security analysis of a SmartTv
• the analysis of a virus in many different aspects, from developement to infection
Many different approaches have been used to assess the security of the smart lock, using
completely different attack methods and prioritizing them based on effectivness and ease of
execution.
The same methodology was also used on the SmartTV, but the attacks completely changed
since the attack surface is way different from the one of the SmartLock.
The malware analysis has been done using an open source malware and, while inpersona-
ting an attacker, and trying to develope a software able to avade standard security solutions
such as antiviruses and to spread through many different infection vectors.
The result obtained have been encouraging in most of the cases: In the first one we were
able to detect important security flaws, which have been reported to the maker of the pro-
duct. In the second one we obtained a virus able to run unseen by modern antiviruses and
infect many different machines using three different infection vectors. We haven’t instead
found any major bug affecting the SmartTV, but this doesn’t mean that some interesting
attacks can ben performed on it.
Malware, Reverse Code Engineering and Cyber Threat Intelligence
3
Capitolo 2
Progetto assegnato
2.1 Descrizione del compito
Con la digitalizzazione che continua ad avanzare, le tematiche della sicurezza informatica
assumono importanza sempre maggiore, risulta dunque essenziale che i vari prodotti di
sicurezza venduti sul mercato possano garantire un alto livello di sicurezza.
Uno dei tre compiti risulta dunque nell’analisi di sicurezza di uno smartlock, con lo sco-
po principale di testarne la sicurezza su vari livelli e nel caso fosse possibile anche di
riconoscere e sfruttare eventuali falle nel sistema.
Rimaniamo poi sullo stesso argomento analizzando una moderna SmartTV di Samsung,
alla ricerca anche in questo caso di falle ma ovviamente utilizzando metodologie differenti,
e molto più simili a quelle che verrebbero utilizzate nel caso di attacco a un classico personal
computer.
Assieme a ciò si affianca l’analisi ed utilizzo di un malware open source, per comprenderne
a fondo il funzionamento e, combinandolo con svariate tecniche, andare ad ottenere un
software in grado di evadere antivirus e diffondersi in molti modi differenti.
2.2 Precisazione sulle tematiche
Il lettore di questo documento potrebbe rimanere perplesso per via della scarsa correlazione
tra i tre temi affrontati, e ne avrebbe tutte le ragioni, tuttavia è necessario sottolineare alcune
informazioni per rendere più chiara la scelta effettuata.
Essendo questa tesi completamente concentrata sulla cyber security, era nostro obbiettivo
quello di coprire il più possibile i vari aspetti a questa legati, ovvero
1. Reconnaissance
2. Scan
3. Exploit
Malware, Reverse Code Engineering and Cyber Threat Intelligence
4 Progetto assegnato
4. Access Maintenance
5. Exfiltration
6. Identification Prevention
Per coprire la maggior parte di questi punti non sarebbe dunque stato sufficiente uno solo
dei vari compiti, inquanto il primo e secondo permette di coprire i punti da 1 a 3, mentre la
seconda parte copre i punti 3 4 e 5. Effettivamente il punto sei rimane scoperto, ma questo
principalmente per via della sua natura postuma rispetto agli altri punti.
Malware, Reverse Code Engineering and Cyber Threat Intelligence5
Capitolo 3
Pianificazione
Le analisi di sicurezza sono difficilmente definibili come lineari, molto spesso è necessario
lasciare qualcosa da parte per poi ritornarci sopra più tardi, mentre altre volte tutto va bene
e il compito viene eseguito con estrema facilità. Le deadline principali che ho intenzione di
porre sono quelle relative alla fine dei singoli progetti, pur cosciente che spesso mi troverò
a saltare da uno all’altro nel caso dovessi rimanere bloccato in alcune parti.
Questo a quanto pare è considerato normale in molti ambienti di media grandezza, il cui
motivo principale è dato dal fatto che spesso per effettuare passi avanti sia necessario avere
intuizioni particolari, che non possono essere forzate o raggiunte tramite la pura disciplina.
Questo obbliga il ricercatore a fasi di semplice contemplazione unita a ripetuti tentativi prima
di poter trovare una strada da seguire in maniera sicura.
3.1 Gantt
Risultano dunque due digrammi di Gantt: uno raffigurante la pianificazione dei lavori ideale,
e uno rappresentante come si siano effettivamente svolti.
Malware, Reverse Code Engineering and Cyber Threat Intelligence6 Pianificazione
Figura 3.1: Diagramma di Gantt pianificato
Figura 3.2: Diagramma di Gantt effettivo
Malware, Reverse Code Engineering and Cyber Threat Intelligence7
Capitolo 4
Analisi SmartLock
4.1 Introduzione
4.1.1 Il prodotto
La ditta in questione produce una discreta serie di modelli, tutti con features molto simili ma
adatte a situazioni differenti (dal lucchetto per bloccare la bici, a uno smartlock per la casa).
Il device che andremo ad analizzare è uno smartlock da sostituire a una normale serra-
tura, sbloccabile però tramite cellulare, badge NFC o codice. La descrizione del prodotto
esalta la garanzia di sicurezza che quest’ultimo è in grado di offrire, menzionando al con-
tempo una serie di test standardizzati a cui il prodotto è stato sottoposto e che ha passato
brillantemente.
Malware, Reverse Code Engineering and Cyber Threat Intelligence8 Analisi SmartLock
Figura 4.1: SmartLock da noi analizzato
L’obbiettivo è quello di andare ad analizzare approfonditamente la sicurezza di ognuna delle
features, comprenderne il funzionamento, e qualora ci fossero vulnerabilità sfruttarle per
eseguire un attacco sul lucchetto, che possa portare nel caso ideale a uno sblocco senza
alcun tipo di credenziale.
4.2 Analisi del protocollo
4.2.1 I tools necessari
Il lucchetto in questione utilizza bluetooth per la comunicazione con lo smartphone, risul-
ta dunque prioritario analizzare la comunicazione per comprendere il protocollo e trovarvi
eventuali falle, è dunque necessario acquistare un device in grado di analizzare il traffico
bluetooth tra altri dispositivi. Il Bluefruit LE Sniffer fa esattamente al caso nostro, e ci per-
mette di analizzare i vari pacchetti bluetooth trasmessi nella rete tramite un plugin wireshark
oppure delle API per python.
Malware, Reverse Code Engineering and Cyber Threat Intelligence9
Figura 4.2: Adafruit bluetooth sniffer
Il processo di installazione risulta estremamente semplice, ed è possibile seguirlo a questo
indirizzo: https://learn.adafruit.com/introducing-the-adafruit-bluefruit-le-sniffer
Una volta installato i software necessari possiamo andare a catturare il traffico di rete rela-
tivo al processeo di sblocco del lucchetto. Utilizzando wireshark osserviamo il traffico per
identificare il nostro pacchetto
Figura 4.3: Svariati pacchetti catturati nel processo di autenticazione
Catturando vari scambi di pacchetti, possiamo notare un pattern di tre pacchetti che si
susseguono, e dove sicuramente avviene lo sblocco del lucchetto.
Malware, Reverse Code Engineering and Cyber Threat Intelligence10 Analisi SmartLock Rcvd Handle v a l u e n o t i f i c a t i o n 0x0008 − 0 0 : a3 : c9 : d7 : d2 : 1 1 : 1 c : 8 d : 0 3 Rcvd Handle v a l u e n o t i f i c a t i o n 0x0008 − 0 0 : 2 9 : 2 9 : ee : 4 6 : 4 a : 7 5 : 5 6 : b8 : dd : 5 a : 1 3 : e2 : Rcvd Handle v a l u e n o t i f i c a t i o n 0x0008 − 0 0 : 2 4 : 5 4 : ba : f 4 : 8 c : 0 9 : ac : 1 6 Il primo e terzo payload rimangono sempre uguali, mentre quello centrale cambia a ogni sblocco del lucchetto, e quindi con ogni probabilità corrisponde all’autorizzazione. Il fatto che il pacchetto continui a cambiare non è positivo, perchè significa che sicuramente la password non viene trasmessa "in chiaro", come succedeva con alcune versioni precedenti di questi lucchetti. Sarà dunque necessario approfondire il metodo di autenticazione tra- mite un’analisi della applicazione, sperando di capire quale sia l’algoritmo utilizzato nella trasmissione. 4.3 Analisi dell’applicazione A questo punto possiamo andare ad analizzare l’app in molti modi differenti per tentare di ottenere più informazioni su come il lucchetto venga sbloccato. Per comprendere meglio la struttura e il funzionamento dell’app andremo per prima cosa ad ottenere il suo codice, e in seguito tenteremo di debuggare l’applicazione per cercare di trovare eventuali falle. 4.3.1 Analisi statica Per eseguire questo tipo di analisi necessitiamo di un tool in grado di ottenere del codice java leggibile da un eseguibile apk. Apktool è un software in grado di ottenere del codice smali da un file apk, ma questo a noi non basta visto che il codice smali è molto difficile da comprendere specialmente in applicazioni complesse. Il tool che invece fa al nostro caso si chiama jadx, un software in grado di ricostruire il sorgente java di un progetto partendo da un file apk. Malware, Reverse Code Engineering and Cyber Threat Intelligence
11
Figura 4.4: Sorgenti ottenuti da jadx
Notiamo subito che fortunatamente il codice non è offuscato tranne per alcune librerie, pos-
siamo dunque cominciare ad analizzare l’applicazione. Scorrendo le varie classi troviamo
subito KeyItem, con i seguenti attributi
Figura 4.5: Una delle classi ottenute dalla decompilazione
Possiamo dunque intuire che questa classe contenga dei dati che poi andranno combinati
per ottenere una chiave che sarà poi utilizzata per criptare il messaggio trasmesso. Con-
tinuando a scorrere la lista delle classi ne troviamo una chiamata AESUtils, che conferma
quasi completamente le nostre ipotesi sul fatto che l’algoritmo di crittazione fosse appunto
AES, come nella maggiorparte dei casi quando si parla di algoritmi a chiavi simmetriche.
Malware, Reverse Code Engineering and Cyber Threat Intelligence12 Analisi SmartLock
Purtroppo notiamo che l’algoritmo utilizzato è AES256 e risulta dunque praticamente im-
possibile un attacco di forza bruta.
Possiamo però provare a capire i vari valori contenuti nella classe al momento dello sblocco
tramite il debugging.
4.3.2 Debugging
Per poter eseguire il debugging di una applicazione non di nostra proprietà, e di cui posse-
diamo solo il file apk è necessario fare una serie di operazioni:
• Ottenere i sorgenti dell’applicazione
• Estrarre il file apk
• Modificare l’AndroidManifest per rendere l’applicazione debuggabile
• Ricompilare l’applicazione
• Firmare l’applicazione
• Installare l’applicazione
• avviare l’applicazione sul cellulare e collegare il pc come debugger
I sorgenti li abbiamo già ottenuti, mentre per gli altri punti possiamo utilizzare un software
chiamato apkstudio1 , che combina svariati tools come zipalign, jarsigner, apktool eccetera
eccetera.
Una volta fatto preparata l’applicazione con il flag debuggable="true", possiamo importare
l’apk creato su android studio, sdk ufficiale di android e applicazione che useremo per ese-
guire il debug. Prima di eseguire il debugging è però necessario fornire i codici sorgenti
del programma ad android studio per far si che possa associarli con il codice smali e quindi
sincronizzare "bytecode" e codice java.
Eseguito questo processo possiamo finalmente esegire il debug.
1
https://github.com/vaibhavpandeyvpz/apkstudio
Malware, Reverse Code Engineering and Cyber Threat Intelligence13
Figura 4.6: Una sessione di debug con alcune variabili visibili
Malware, Reverse Code Engineering and Cyber Threat Intelligence14 Analisi SmartLock
Posizioniamo dei breakpoint in posizioni interessanti come ad esempio i punti in cui viene
chiamata la funzione di sblocco del lucchetto e lanciamo l’applicazione. Scopriamo rapi-
damente che i sorgenti non sono realmente sincronizzati con il codice smali, e che quindi
molto spesso un breakpoint viene spostato di parecchie righe. Questo non ci da la sicurezza
di essere nella corretta porzione del codice e l’unico modo in cui possiamo intuirlo è guar-
dando le i valori nello stack/heap. Inoltre, molto rapidamente l’esecuzione del programma
raggiunge parti di codice offuscate, e questo rende l’operazione di debugging estremamente
complicata. Con alcune ulteriori ricerche ho scoperto che la libreria bluetoothlib è disponi-
bile su github2 , quindi pur essendo offuscata il codice è comunque visibile. Non sono però
stato in grado di trovare nessun bug nella suddetta libreria, probabilmente anche per via
dei commenti e commit completamente scritti in cinese. Non riuscendo quindi ad ottenere
informazioni sufficienti per individuare una falla accantoniamo momentaneamente questo
tipo di approccio.
2
https://github.com/xiaoxiaohaozai/Bluetoothlib
Malware, Reverse Code Engineering and Cyber Threat Intelligence15
Figura 4.7: Svariate variabili offuscate in una sessione di debug
4.4 NFC
Il lucchetto fornitoci permette, oltre allo sblocco tramite codice numerico e tramite applica-
zione, la possibilità di essere aperto anche tramite l’utilizzo di una tessera con tag NFC
tramite la tecnologia MiFare. In questo capitolo andiamo a tentare di capire se sia possibile
un attacco tramite questo tipo di tecnologia Cercando un po’ di informazioni online scopria-
mo che esistono due tipi principali di chip MiFare: classic e plus. La nostra tessera è di tipo
classic, che tra le due tecnologie è la più debole per quanto riguarda la sicurezza.
Utilizzando un tool per android chiamato MiFare Classic Tool possiamo tentare un attacco di
forza bruta basandoci su un dizionario di chiavi di crittazione già recuperate da altre persone
e postate online.
Nel nostro caso il software è subito in grado di leggere tutti i blocchi, otteniamo quindi un
dump del chip. Il problema però sorge nello scrivere i dati ottenuti su un’altro chip MiFa-
re, questo perchè nella maggior parte dei tag NFC non permetto di scrivere sul blocco 0,
contenente le informazioni sul venditore eccetera. Purtroppo tutti i tag NFC che aveva-
mo a disposizione non permettevano di effettuare questa operazione, non siamo quindi in
possesso di un attacco funzionante e riuscito ma possiamo con sicurezza che la cosa è
possibile.
Malware, Reverse Code Engineering and Cyber Threat Intelligence16 Analisi SmartLock
Figura 4.8: Schermata principale di mifare classic tool
Malware, Reverse Code Engineering and Cyber Threat Intelligence17
Figura 4.9: Visualizzazione del dump di una chiave MiFare
Malware, Reverse Code Engineering and Cyber Threat Intelligence18 Analisi SmartLock È comunque necessario notare che un attacco del genere richiede di rimanere a pochi centi- metri dal tag NFC per almeno una decina di secondi se non di più. Non risulterebbe dunque particolarmente comodo eseguire questo tipo di attacco, e dovrebbe essere considerato una delle vie meno plausibili. 4.5 Traffico di rete A questo punto analizziamo i pacchetti mandati dall’app verso i server di autenticazione, per tentare di trovare eventuali vulnerabilità a livello di login o api in generale. Cominciamo dunque utilizzando wireshark per analizzare un po’ di pacchetti trasmessi dall’applicazione al server, nella speranza di trovare qualcosa di interessante. Malware, Reverse Code Engineering and Cyber Threat Intelligence
19
Figura 4.10: Pacchetti catturati in cui si può vedere l’autenticazione dell’utente
Analizzando alcuni pacchetti abbiamo subito una grande sorpresa: i pacchetti di autenti-
cazione vengono inviati tramite semplice HTTP e quindi sono visibili a chiunque stia ascol-
tando sulla rete o in caso di rete wired con un attacco MITM. Abbiamo dunque trovato un
primo bug, riproducibile seguendo la breve guida in fondo al capitolo. È inoltre importante
notare come questo tipo di bug renda vulnerabili tutti i tipi di lucchetti sbloccabili tramite
quest’ultima, e non solamente il modello da noi analizzato.
Notiamo anche una richiesta http mandata a un server differente con l’endpoint /amdc/-
mobileDispatch la cui risposta è completamente codificata in base64, sfruttiamo dunque
il comando in bash per decodificare la stringa, scoprendo così una sorta di json di cui in
seguito è presente una parte.
{
{
" aisles " : [
{
" c t o " : 10000 ,
" heartbeat " : 0 ,
" p o r t " : 443 ,
" protocol " : " https " ,
" retry " : 1,
" r t o " : 10000
},
{
" c t o " : 10000 ,
" heartbeat " : 0 ,
" p o r t " : 80 ,
Malware, Reverse Code Engineering and Cyber Threat Intelligence20 Analisi SmartLock
" protocol " : " http " ,
" retry " : 1,
" r t o " : 10000
}
],
" h o s t " : " l o g . mmstat . com " ,
" idc " : false ,
" ips " : [
" 198.11.190.7 "
],
" strategies " : [
],
" t t l " : 300
}
Questi dati contengono svariati server utilizzati dall’app, compreso l’indirizzo ip del server sui
cui poi viene eseguito il login. Risulta dunque chiaro come anche una semplice implemen-
tazione di ssl per l’autenticazione non sarebbe sufficiente, inquanto un attaccante potrebbe
semplicemente modificare la sopracitata risposta a un proprio server, che andrebbe poi ad
occuparsi di instradare il traffico al server reale.
Continuiamo a esplorare le api scoprimamo rapidamente un’altro bug: Il sistema invia due
tipi di risposte differenti nel caso si abbia sbagliato la password, o l’username sia inesistente.
Questo, unito alla completa assenza di un meccanismo di capcha ci permette di fare una
enumerazione almeno parziale degli utenti tramite un attacco di forza bruta o, nel caso ci
si stia concentrando su una determinata vittima, provando una lista di indirizzi email che
potrebbero essere di questa persona.
È inoltre interessante notare come i requisiti di sicurezza per la password siano davvero
minimi, il sistema obbliga solamente ad immettere una password di 6 o più caratteri, senza
effettuare nessun controllo su maiuscole o caratteri speciali.
Unendo queste due informazioni sarebbe anche possibile un attacco completamente casua-
le con una lista di indirizzi email trovata online e un dizionario con tutte le possibili password
di 6 o 7 caratteri.
Malware, Reverse Code Engineering and Cyber Threat Intelligence21
4.5.1 Breve guida all’attacco MITM
Per seguire la seguente guida è necessario
1. Un pc
2. Una distro di pentesting come Kali Linux o ParrotOS
3. Un cellulare con l’applicazione dello SmartLock installata
4. una rete che contenga entrambe le device
Lanciamo la distribuzione e apriamo Ettercap4.11
Figura 4.11: Schermata principale di ettercap
Selezionare Sniff->Unified Sniff e selezionare l’interfaccia di rete su cui eseguire l’attacco.
Andare su Targets->Select Targets e inserire le macchine tra cui catturare il traffico. 4.12
Malware, Reverse Code Engineering and Cyber Threat Intelligence22 Analisi SmartLock
Figura 4.12: menu di selezione dei target
Malware, Reverse Code Engineering and Cyber Threat Intelligence23
Mitm-> Arp Poisoning-> Ed abilitare entrambe le opzioni. A questo punto è sufficiente
cliccare su Start->Start Sniffing
È possibile vedere i dati di login catturati, nella console in basso, o più nello specifico
andando su View->Connections4.13
Figura 4.13: lista di connessioni catturate da ettercap
Malware, Reverse Code Engineering and Cyber Threat Intelligence24 Analisi SmartLock Malware, Reverse Code Engineering and Cyber Threat Intelligence
25
Capitolo 5
Analisi Samsung SmartTV
5.1 Introduzione
In questo capitolo, andremo a mostrare i tentativi di attacco utilizzati sulla moderna SmartTV
Samsung da noi posseduta. Dopo una fase di analisi preliminare andremo a cercare even-
tuali falle nel sistema, prioritizzando vulnerabilità in grado di sottrarre dati personali sensibili.
Online è possibile facilmente trovare articoli riguardanti un ricercatore di sicurezza che mol-
to tempo fa aveva dichiarato il sistema operativo di Samsung Tizen pieno di falle, non sono
presenti alcun tipo di exploit pubblici a riguardo, questo ovviamente non esclude che molti
siano stati venduti in altri mercati illegali. È da notare come in questa analisi siano stati
evitati metodi di analisi complessi, come ad esempio l’analisi dell’hardware all’interno della
SmartTV, per via della grande quantità di tempo necessaria a completare compiti del genere
e la presenza di altri argomenti di cui era necessario occuparsi.
5.1.1 Modello
Il modello di cui ci occuperemo è molto recente (2017), ma privo di fotocamera e microfo-
no, cosa non estremamente positiva dal momento che molti dei dati sensibili che sarebbe
possibile acquisire sono automaticamente a noi preclusi.
Malware, Reverse Code Engineering and Cyber Threat Intelligence26 Analisi Samsung SmartTV
Figura 5.1: Smart TV Samsung modello 2017 da 24 pollici[Samsung(2017)]
5.2 Analisi
La più importante analisi che siamo andati ad eseguire è sicuramente uno scan completo
delle porte, per individuare le varie porte aperte sulla SmartTV. Con l’aiuto di nmap ese-
guiamo un "comprehensive scan" puntando all’indirizzo ip della SmartTV, e troviamo così
una serie di porte aperte, con relativi servizi associati, come lighthttpd,upnp etc.
Effettuando alcune ricerche online andiamo pure a trovare degli articoli che descrivono co-
me le vecchie api del web browser di Tizen, permettessero un accesso a fotocamera e
microfono senza nessun tipo di interazione da parte dell’utente. Quest’ultime potrebbero
essere ancora presenti, anche se la cosa sembra parecchio improbabile, ma putroppo non
siamo in grado di testare questo tipo di attacco per via della assenza di queste periferiche
di input sulla nostra SmartTV.
Notiamo anche come sia possibile comandare la SmartTV a tramite smartphone utilizzando
la rete wifi e un’app di samsung chiamata Samsung Smart View.
Malware, Reverse Code Engineering and Cyber Threat Intelligence27
Figura 5.2: Immagine di esempio si Samsung Smart View
Questa applicazione, oltre ad aprire svariati tipi di applicazioni presenti sulla SmartTV alla
pressione di una semplice icona, è anche in grado di fungere da vero e proprio telecomando
e il tutto senza chiedere nessun tipo di login.
5.3 Attacchi
5.3.1 Exploit
Alla luce delle informazioni che abbiamo ottenuto, si delineano alcuni possibili attacchi, di
cui il primo è l’utilizzo di un semplice exploit, nel caso fossimo in grado di trovarne uno
funzionante. Utilizzziamo dunque searchsploit e cerchiamo eventuali exploit per le versioni
dei servizi trovati:
Figura 5.3: Possibili exploit per upnp 1.0 trovati con searchsploit
A questo punto è sufficiente copiare lo script nella cartella di metasploit con il seguente
comando:
sudo cp / u s r / share / e x p l o i t d b / e x p l o i t s / l i n u x / remote / 2 5 9 7 5 . r b
/ u s r / share / m e t a s p l o i t −framework / modules / e x p l o i t s / l i n u x /
e successivamente avviare metasploit e digitare:
Malware, Reverse Code Engineering and Cyber Threat Intelligence28 Analisi Samsung SmartTV
use e x p l o i t / l i n u x /25975
A questo punto è possibile visualizzare le varie impostazioni disponibili tramite il comando
"show options"
Figura 5.4: Opzioni disponibili per il modulo metasploit scelto
È ora sufficiente impostare i valori corretti e poi andare a lanciare l’exploit con il comando
"exploit" appunto.
Purtroppo nessuno degli exploit trovati risulta funzionare sulla nostra SmartTV, probabil-
mente perchè già patchato oppure non presenti in una eventuale versione customizzata del
software.
5.3.2 Samsung Smart View
Andiamo dunque ad esplorare le possibilità dateci dalla applicazione Samsung Smart View.
Purtroppo l’applicazione non ci permette in modo ovvio di ottenere informazioni confidenziali
su ciò che è contenuto nella SmartTV, a parte forse i nomi dei video presenti all’interno
della stessa e la lista delle app installate, ma ci permette comunque di utilizzare la SmartTV
come telecomando. Risulta dunque possibile sfruttare quest’ultima funzionalità per andare a
modificare le impostazioni della SmartTV mentre nessuno osserva lo schermo, ad esempio
di notte.
Il tutto può essere automatizzato con uno script che sfrutta le api della SmarTV per eseguire
tutti gli input necessari in rapida successione, dandoci la possibilità di modificare impostazio-
ni importanti come ad esempio l’indirizzo dei server DNS, sfruttabili poi per dirottare l’utente
su siti malevoli da noi specificati.
Sarebbe stato molto interessante esplorare ulteriormente questo tipo di attacchi, ma pur-
troppo il poco tempo rimastoci a disposizione non è sufficiente per un compito del genere.
Malware, Reverse Code Engineering and Cyber Threat Intelligence29
Capitolo 6
Cyber-attacco di tipo RAT
6.1 Introduzione
Ci spostiamo ora dalla parte di Reconnaissance, Scanning e Gaining Access al manteni-
mento dell’accesso ottenuto, e per questo avremo bisogno di trovare un software in grado
di farci eseguire comandi remoti sulla macchina infettata. Generalmente per questo tipo di
compito vengono utilizzati dei RAT(Remote Administration Tool) o Trojan, che ormai arriva-
no a offrire moltissime funzionalità nonchè metodi per eludere svariati sistemi di sicurezza.
Online sono disponibili moltissimi prodotti del genere, ma generalmente a pagamento. Noi
invece stiamo cercando una soluzione gratis e se possibilie completamente open source, e
quindi modificabile in un ipotetico futuro.
6.2 Pupy
Il prodotto che ho scelto di utilizzare si chiama pupy, ed è un RAT open source scritto in
python e con una moltitudine di moduli che lo rendono altamente estendibile e personaliz-
zabile. Tra le varie funzionalità spicca la possibilità di non lasciare mai il virus in chiaro sul
disco, caricando prima il codice criptato in ram per evitare i moderni controlli dei vari antivi-
rus. Il progetto è disponibile su GitHub e risulta frequentemente aggiornato, con una buona
quantità di issues a cui è stata data una risposta, che potremmo usare come fonte in caso
di problemi.
6.3 Componenti
Pupy rispetta la classica struttura che contraddistingue la maggiorparte dei trojian, ovvero
client-server. Il server deve essere installato su una macchina esposta in rete, e tramite
quest’ultima sarà possibile generare diversi file infetti che una volta eseguiti diventeranno
client e si connetteranno al server da noi installato. Questa scelta non è sicuramente l’unica
Malware, Reverse Code Engineering and Cyber Threat Intelligence30 Cyber-attacco di tipo RAT
disponibile, inquanto spesso si sente parlare di virus che utilizzano strutture distribuite peer-
to-peer, o anche evitando di compromettere la propria identità tramite l’utllizzo di servizi
come bot telegram, per poter evitare di dover acquistare server. Oltre a ciò pupy utilizza
un sistema di moduli, che permettono dunque di generare payload con funzionalità molto
differenti e in grado di adattarsi a svariate piattaforme. Pupy è infatti disponibile per una
moltitudine di piattaforme, tra cui android, linux, mac e windows proprio per via di questo
tipo di struttura.
6.4 Installazione
L’installazione risulta di per sè piuttosto semplice, i comandi da eseguire sono infatti i se-
guenti
docker p u l l a l x c h k / pupy : u n s t a b l e
docker run −d −p 2022:22 −v / tmp / p r o j e c t s : / p r o j e c t s a l x c h k / pupy : u n s t a b l e
cp ~ / . ssh / i d _ r s a . pub / tmp / p r o j e c t s / keys / a u t h o r i z e d _ k e y s
ssh −p 2022 pupy@127 . 0 . 0 . 1
È possibile anche utilizzare l’installazione "manuale", ma fortemente sconsigliato inquanto
è in corso una completa pulizia del progetto e quindi quest’ultima potrebbe non funzionare.
Nulla vieta però di utilizzare il branch master per ottenere una versione più stabile. In questo
caso eseguire
g i t c l o n e h t t p s : / / g i t h u b . com / n1nj4sec / pupy . g i t pupy
cd pupy
g i t submodule i n i t
g i t submodule update
p i p i n s t a l l − r pupy / r e q u i r e m e n t s . t x t
Alcune dipendenze presenti nei requisiti potrebbero non essere installate correttamente da
pip a seconda della distribuzione. In questo caso è consigliato installare queste dipen-
denze utilizzando il manager di pacchetti nativo della distribuzione, e poi rilanciare l’ultimo
comando.
6.5 Payload
Una volta installato il software, è il momento di generate un file che, una volta eseguito dalla
vittima, ci permetterà l’accesso remoto alla macchina. Per eseguire questo compito possia-
mo utilizzare il tool compreso nel progetto chiamato pupygen, che permette di scegliere tra
una vasta gamma di payload, tra cui:
• un eseguibile per windows
Malware, Reverse Code Engineering and Cyber Threat Intelligence31
• un file python con tutte le librerie necessarie già incluse
• un file per powershell
• uno script per robber ducky
Il comando più semplice che possiamo andare ad eseguire è il seguente:
python2 pupygen . sh − f c l i e n t
Andiamo così ad ottenere un file exe che una volta eseguito andrà a connettersi automatica-
mente all’indirizzo ip della macchina da cui abbiamo generato lo script, anche se ovviamente
in una situazione reale il seguente parametro dovrà essere modificato per far connettere il
pc a una macchina esterna alla rete.
6.6 Pupy vs antivirus
I payload generati da pupy originariamente non venivano considerate minacce da nessun
tipo di antivirus, ma con l’aumento della sua popolarità e con la comparsa di servizi come
virustotal, si è velocemente passati a una situazione dove la maggior parte dei file generati
da pupy vengono rilevati.
Nella seguente tabella è possibile vedere quali payload sono riconosciuti:
Nome originale descrizione rilevato(si/no)
client payload in formato exe o dll si
py payload in formato py con librerie già incluse no
pyinst payload volutamente ottimizzato per poi essere compilato in .exe no
py oneliner payload deployabile eseguendo una linea da terminale no
ps1 payload in formato powershell si
ps1 oneliner come py oneliner ma con una stringa che utilizza powershell no
rubber ducky script per robberducky no
Possiamo constatare come la situazione di partenza non sia affatto male, avendo solo 2
payload su 7 rilevati, ma purtroppo tra questi c’è il principale metodo di deployment per file
malevoli, ovvero exe e dll.
Dobbiamo quindi cercare un metodo per offuscare l’eseguibile e renderlo non rilevabile dai
principali antivirus. Per eseguire questo compito è dunque necessario approfondire i vari
tools e metodi utilizzati per rendere vari tipi di files fully undetectable (abbreviato con FUD).
6.7 Offuscamento
Con l’evoluzione continua dei vari antivirus, il campo dell’offuscamento risulta in continuo
cambiamento, e senza nessuna garanzia sul periodo per cui i nostri payload rimarranno
Malware, Reverse Code Engineering and Cyber Threat Intelligence32 Cyber-attacco di tipo RAT
undetected. Tramite svariati test ho avuto modo di notare come, per ovvi motivi, le soluzioni
il più possibili custom made risultino essere le più efficaci nel superare gli svariati controlli
di sicurezza in atto.
6.7.1 Excursus su VirusTotal
Virustotal è il più popolare sito web utilizzato per controllare la non pericolosità di file ese-
guibili e non. Esso permette di eseguire una analisi utilizzando una moltitudine di antivirus
differenti, così da ottenere risultati estremamente accurati e validi. così da avere A quasi
ogni file postato online è associato il relativo link a virustotal come garanzia di sicurezza.
Per coloro che creano Trojan, servizi del genere risultano quantomeno scomodi, inquanto
una volta che un antivirus comincia a rilevare un file come pericoloso, il risultato si espande
velocemente agli altri prodotti tramite un meccanismo di condivisione che VirusTotal met-
te a disposizione ai vari produttori di antivirus. Molti utenti ingenui, caricando svariati files
per controllare che il proprio payload fosse valido, hanno reso il compito di generare file
non rilevati come pericolosi molto più arduo, e svariati tools di offuscamento quasi inutili.
Per tutti coloro che volessero provare alcune delle strategie descritte in questo documento
consiglio di NON caricare questi files su servizi del genere, ma di testare la validità dei files
manualmente sui vari antivirus dopo aver disabilitato il meccanismo di condivisione incluso
negli stessi.
6.7.2 Veil evasion
Veil evasion è un framework che permette di generare file malevoli e di criptarli utilizzando
svariate tecniche di hiding. Tra le varie opzioni offerte sono presenti algoritmi tra cui:
• criptazione del codice malevolo tramite aes
• codifica del payload in base64
• sostituzione di lettere tramite un algoritmo personalizzato
Il processo di generazione è guidato e molto semplice, e permette di aggiungere del codice
malevolo a un file eseguibile "sano" o di codificare semplicemente un file malevolo.
Sfortunatamente però nessuna delle tecniche che ho testato sono state in grado di evadere
Microsoft Essentials, il principale antivirus che ho utilizzato per eseguire questi test. Questo
con ogni probabilità è accaduto perchè il codice relativo alla parte di decodifica del payload
rimane sempre uguale, e questo ha dunque permesso ai vari antivirus di individuare le so-
miglianze tra i vari files infetti analizzati, fino a riconoscere quasi tutti i files prodotti da questo
framework.
Per codificare un file con Veil Evasion possiamo andare a lanciare veil e poi andiamo a
selezionare il tipo di payload da utilizzare con
Malware, Reverse Code Engineering and Cyber Threat Intelligence33
use nomepayload
Figura 6.1: Metodi di codifica disponibili per veil-evasion
Una volta selezionato il payload possiamo andare a modificare i vari settaggi in base al tipo
di pyload che stiamo utilizzando.
Una volta selezionate le opzioni desiderate possiamo generare il file con "generate".
6.7.3 Hyperion
Hyperion utilizza un approccio molto particolare all’encoding di file eseguibili, esso infatti
crypta i file utilizzando AES per poi cancellare la chiave necessaria per decriptare il file.
Una volta eseguito il file, verrà messo in atto un processo di bruteforcing per andare a
ritrovare la chiave e conseguentemente decriptare il file ed eseguirlo. Ovviamente se il
software utilizzasse una implementazione corretta di AES questo processo richiederebbe
anni di tentativi, ma affidandosi a una implementazione volutamente difettosa dell’algoritmo,
è possibile recuperare il file originale in tempi relativamente brevi.
Nonostante il metodo molto originale, il codice base che esegue il bruteforce risulta cono-
sciuto dai produttori di antivirus da molto tempo, e questo ha reso tutti i miei tentativi di otte-
nere un file FUD vani. Nonostante ciò non è da escludere che in futuro sia possibile per gli
Malware, Reverse Code Engineering and Cyber Threat Intelligence34 Cyber-attacco di tipo RAT
Figura 6.2: Opzioni disponibili per l’encoder scelto
Malware, Reverse Code Engineering and Cyber Threat Intelligence35
sviluppatori di questo software generare un decoder differente a ogni iterazione del program-
ma così da sfuggire a questo genere di controlli.
Codificare un file con hyperion è molto semplice:
wine h y p e r i o n . . / source . exe n e w f i l e . exe
6.7.4 Shellter
Shellter è un software disponibile in versione Pro e Free, in grado di inserire in modo di-
namico shellcode all’interno di un file eseguibile a 32 bit. Shellter riesce spesso ad evitare
di essere riconosciuto da antivirus utilizzando un sistema che randomizza il più possibile il
modo in cui le varie operazioni vengono nascoste all’interno dell’eseguibile nel tentativo di
rendere il workflow della applicazione il meno sospetto possibile.
Inizialmente shellter non mi ha dato risultati particolarmente notevoli, ma dopo un aggiora-
namento all’ultima versione, che ha introdotto molte ottimizzazioni, e aver provato un po’
di settaggi diversi, sono riuscito ad ottenere il primo file eseguibile considerato sicuro da
Microsoft Security Essentials.
È interessante specificare che Shellter non permette di utilizzare un file eseguibile per infet-
tare l’eseguibile a 32 bit, ma semplicemente una shellcode oppure una self reflective dll. Ho
dovuto quindi trovare un metodo per inserire il payload generato da pupy all’interno di una
applicazione valida. Fortunatamente un modulo di shellter permette di iniettare un comando
per cmd direttamente nell’eseguibile interessato, sono dunque stato in grado di utilizzare il
payload "ps1 oneliner" menzionato nella tabella 6.6 per ottenere un file in grado di scaricare
a runtime il payload di pupy da un server esterno ed eseguirlo.
Shellter fornisce un wizard interattivo che rende estremamente semplice il suo utilizzo, so-
no tuttavia presenti molti parametri che devono essere necessariamente specificati come
parametri da linea di comando per essere uzilizzati.
Una volta selezionato un file valido in cui iniettare la shellcode, possiamo decidere se
utilizzare un modulo già presente nel software oppure una nostra shellcode personale.
Malware, Reverse Code Engineering and Cyber Threat Intelligence36 Cyber-attacco di tipo RAT
Figura 6.3: Prompt di Shellter con lista di payload utilizzabili
Nel nostro caso selezioneremo il modulo WinExec [7] e andremo a fornire il comando per
eseguire il payload.
6.7.5 Compilare python a exe
Essendo il payload principale scritto in python, può essere una buona idea utilizzare un
programma come pyinstaller per ottenere un file eseguibile dal suddetto file, sperando ovvia-
mente di evitare di creare pattern al suo interno riconosciuti dagli antivirus.
Pupy fortunatamente fornisce un payload appositamente generato per essere compatibile
con pyinstaller, evitando così possibili problemi dati dalle varie dipendenze del programma.
I passi da eseguire per ottenere un risultato funzionante sono pochi e semplici:
p y i n s t a l l e r −− o n e f i l e t a r g e t . py
L’opzione onefile specifica di comprimere i vari files creati in un eseguibile.
Il file che risulta da questo procedimento non viene rilevato da nessun antivirus come male-
volo, tuttavia esso non viene considerata come "applicazione valida" da Windows 10 a meno
che non si attivino delle funzionalità di compatibilità disattivate di default.
Non sono stato in grado di comprendere cosa vada a generare un errore del genere, ma
una volta risolto questa soluzione sarebbe probabilmente tra le migliori, assieme a shellter.
Un’altra operazione consigliata nel caso di una operazione di grande importanza, è di acqui-
stare un certificato digitale per far risultare l’applicazione firmata, ed evitare così un prompt
di avvertimento all’avvio del programma.
Malware, Reverse Code Engineering and Cyber Threat Intelligence37
6.7.6 Nascondere manualmente il codice
Un’altra opzione è di prendere la dll generata da pupy e codificarla tramite una serie di
procedimenti a scelta, per poi inserirla come stringa all’interno di un file c e caricarla a
runtime dopo averla nuovamente decodificata. È molto importante che la dll nella sua forma
originale non sia in alcun momento presente se non nella memoria di lavoro del pc vittima,
inquanto l’analisi statica dell’antivirus sarebbe in grado di identificarla immediatamente. Un
semplice esempio per questo approccio è il seguente
1 char ∗ b u f f e r = " i n s e r i r e q u i l a l i b r e r i a c o d i f i c a t a i n base64 "
2 v o i d ∗ r e s u l t = m a l l o c ( ( s i z e o f ( b u f f e r ) ∗ 6) / 8 ) ;
3 base64decode ( b u f f e r , s i z e o f ( b u f f e r ) , r e s u l t , s i z e o f ( r e s u l t ) ) ;
4 HMEMORYMODULE MemoryLoadLibrary ( r e s u l t , s i z e o f ( r e s u l t ) ) ;
Tuttavia un approccio del genere viene individuato facilmente dall’antivirus per via della
funzione di decoding da base64. Non dovrebbe tuttavia risultare troppo complicato rendere
la procedura di decoding irriconoscibile all’antivirus, per esempio offuscando la funzione di
decoding e dandole un nome a caso.
6.8 Vettori di infezione
Una volta generati i nostri payload,è necessario trovare uno o più metodi per diffonderli,
e per questo motivo, andremo a sviluppare svariate tecniche per infettare più macchine
possibili.
Malware, Reverse Code Engineering and Cyber Threat Intelligence38 Cyber-attacco di tipo RAT
6.8.1 Eseguibile
La prima soluzione
è anche la più semplice: convincere la vittima a scaricare il file exe utilizzando un po’ di in-
gegneria sociale o una mail di phishing. Per l’occasione il file eseguibile può essere debita-
mente mascherato e firmato in modo da sembrare più invitante, anche se rimarrà comunque
il messaggio di avvertimento di windows all’esecuzione del file.
6.8.2 PDF
Un altro metodo è quello di creare un file pdf in grado di eseguire del codice sulla macchina
della vittima una volta aperto. Le specifiche per il formato pdf contengono molte funzionalità
che potrebbero essere sfruttare per questo genere di compito, come la possibilità di ese-
guire codice javascript per esempio. Ovviamente ogni volta che che una simile vulnerabilità
viene scoperta, Adobe e gli altri produttori di pdf reader si assicurano di chiudere la falla
di sicurezza in tempi il più brevi possibile. Non è dunque possibile utilizzare i vari exploit
presenti online sulle ultime versioni di Adobe Reader, ma possiamo farlo con altre versioni
meno aggiornate. Essendo questo un progetto didattico, non mi sono concentrato partico-
larmente sulla attualità di un exploit del genere, quanto alla sua utilità. È comunque utile
sottolineare come exploit più efficaci siano acquistabili sul deep web.
Per generare un file pdf infetto possiamo utilizzare un modulo di metasploit fatto apposita-
mente per l’exploit che vogliamo usare. Andiamo dunque a lanciare metasploit e successi-
vamente digitiamo
Malware, Reverse Code Engineering and Cyber Threat Intelligence39
use e x p l o i t / windows / f i l e f o r m a t / adobe_pdf_embedded_exe
A questo punto possiamo decidere quale file utilizzare, il payload e altre opzioni minori. Una
volta impostati i vari parametri possiamo generare il pdf con il comando "exploit".
6.8.3 Java
Java è un linguaggio di programmazione estremamente diffuso, e anche se al momento
esistono dei linguaggi di programmazione con una crescita chiaramente più rapida di java,
è innegabile che fino a qualche anno fa java era considerato da una grande parte della
comunità tecnologica il futuro dell’informatica. Questo ha portato il linguaggio a diffondersi
estremamente rapidamente, fino ad essere incorporato anche nella quasi totalità dei web
browsers e in moltissimi device mobile. Java ha tuttavia avuto parecchi problemi di sicurezza
negli anni passati, e questo unito all’arrivo di nuove tecnologie ha certamente reso minore
la presenza di java. Un eventuale vettore di infezione tramite java avrebbe lo svantaggio di
necessitare che l’interprete sia installato sulla macchina vittima, esattamente come con il
payload python. Nella nostra attuale posizione, non c’è dunque nessuna vera ragione per
cui dovrebbe essere generato un virus in java.
6.8.4 JavaScript
JavaScript è una delle tecnologie correntemente più utilizzate sul web, e risulterebbe dun-
que molto comodo poter sfruttare un vettore di infezione del genere per via della altissima
quantità di vittime che sarebbe possibile raggiungere. Purtroppo però, risulta quasi im-
possibile trovare una vulnerabilità nel linguaggio stesso, quanto piuttosto nella particolare
implementazione utilizzata da uno specifico browser web. Questo ovviamente riduce ov-
viamente il numero di vittime raggiungibili utilizzando un singolo exploit, ma nel caso fosse
possibile ottenere un exploit per un browser molto popolare l’ordine di grandezza sarebbe
sicuramente comparabile all’ipotetico exploit di cui abbiamo parlato prima.
6.8.5 Flash
Adobe Flash è stata una delle tecnologie più famose ed utilizzate per lo sviluppo di pagi-
ne interattive e la riproduzione di contenuti multimediali fino a qualche anno fa. Uno dei
motivi che ha favorito la sparizione di questa tecnologia, assieme all’avvento di HTML5,è
stata appuntole svariate falle di sicurezza scoperte negli anni, che costringevano Adobe a
rilasciare continue patch e gli utenti a frequentissimi aggiornamenti. La rapida sparizione di
flash rende molto meno conveniente lo sviluppo di un exploit per questa tecnologia, anche
considerando che molti browser hanno già smesso o smetteranno a breve di supportar-
lo. Ovviamente se la scelta fossa stata effettuata anche solamente 3 anni fa, il risultato di
questa valutazione sarebbe stato completamente differente, inquanto la sparizione di flash
Malware, Reverse Code Engineering and Cyber Threat Intelligence40 Cyber-attacco di tipo RAT
è qualcosa di estremamente recente. Potrebbe comunque rimanere un buon metodo per
attaccare macchine con sistemi operativi più datati.
6.8.6 Hardware-Rubberducky
Il rubberducky è un dispositivo usb reso molto popolare dal sito di cyber security nonchè
team hak5, in grado di apparire al pc come una tastiera pur avendo l’apparenza di una
normale chiavetta usb. Un dispositivo del genere permette, qualora si riuscisse ad inserire
quest’ultimo in un pc non sorvegliato, di otterene il controllo del suddetto pc in pochissimi
secondi. Inizialmente vengono simulati i comandi CTRL+R per poter lanciare un comando,
e dopo aver aperto un terminale è possibile scegliere cosa verrà digitato. Nel nostro ca-
so ovviamente andiamo a lanciare il comando fornitoci alla generazione del payload "ps1
oneliner", che automaticamente scaricherà il trojan e lo caricherà in memoria.
Per evitare di comprare la versione originale di questo prodotto ho deciso di utilizzare qual-
cosa di più economico per riprodurre tutte le sue funzionalità, ovvero un adafruit trinket
andando così a risparmiare una buona quantità di denaro.
Figura 6.4: Adafruit trinket
Il codice per programmare la board e ottenere le funzionalità richieste è incluso nell’archivio
fornito assieme a questo documento.
Malware, Reverse Code Engineering and Cyber Threat Intelligence41
6.9 Utilizzo
Utilizzare pupy risulta molto semplice: una volta lanciato il server interattivo con ./pupysh.py
possiamo utilizzare una moltitudine di comandi per gestire i client a noi connessi. Digitando
help otteniamo una lista completa di tutti i comandi.
Figura 6.5: Lista di comandi disponibili su pupy
Qualora non si sapesse come utilizzare un qualunque comando, è possibile digitare help
seguito dal nome del comando per ottenere informazioni dettagliate sull’utilizzo dello stesso.
Malware, Reverse Code Engineering and Cyber Threat Intelligence42 Cyber-attacco di tipo RAT Malware, Reverse Code Engineering and Cyber Threat Intelligence
43
Capitolo 7
Conclusioni
In conclusione ritengo i risultati ottenuti piuttosto soddisfacenti, in due dei tre compiti as-
segnatici siamo stati in grado di raggiungere l’obbiettivo che ci eravamo prefissati, mentre
nel terzo abbiamo comunque trovato delle falle che con una buona quantità di lavoro si
potrebbero trasformare in pericoli molto più seri.
7.1 Problemi riscontrati
Alcune parti sono state parecchio impegnative ed in alcuni momenti decisamente frustran-
ti, per la mancanza di risultati, cosa abbastanza tipica nell’ambiente della sicurezza in-
formatica. Spesso alcuni risultati sono arrivati solamente dopo una "illuminazione" e non
necessariamente durante le sessioni di lavoro.
Malware, Reverse Code Engineering and Cyber Threat IntelligencePuoi anche leggere
