Cyber Defense - How to find and manage zero-days

1. Cyber Defense e
attacchi zero-day come
trovarli e come gestirli
Simone Onofri
14 Marzo 2017

2. Agenda
- Il panorama delle minacce
- Cosa sono gli 0-day e perché sono importanti
- Come trovarli e alcuni casi
- Come proteggersi
2

3. «Capacità organizzata per
la protezione, la
mitigazione e il recupero
rapido dai ‘Cyber
Attack’»
Ispirato alla definizione di Cyber Defense della commissione bilaterale Stati
Uniti d’America – Russia, 2011
3
Source: https://www.files.ethz.ch/isn/130080/Russia-U%20S%20%20bilateral%20on%20terminology%20v76%20(2)-1.pdf

4. «Dai ad un uomo un
exploit e lo farai hacker
per un giorno;
insegnagli a trovare i
bug e lo farai hacker per
tutta la vita»
Felix «FX» Linder
4
Fonte: https://www.nostarch.com/bughunter

5. Il panorama delle minacce
5

6. Il panorama delle minacce
Giorni per rispondere ad
una compromissione46
53%146 Giorni per identificare
una compromissione Degli attacchi
provenivano
dall’interno
35%44%
$7.7M
Hanno ammesso
che sono state
compromesse
delle postazioni
negli ultimi due
anni**
54!
Vulnerabilità
zero-day nel
2015
552M$21,155
Costo medio di
una
comrpomissione*
Costo giornaliero
per la risoluzione di
una comrpmissione*
Di record
personali rubati
nel 2015
Delle
compromissio
ni sono state
segnalate
da una
terza parte
55%
Aumento del
phishing nel
2015
6
Fonti: Mandiant M-Trends 2016 Report,
*Ponemon 2015 Cost of Cyber Crime Study: Global
**SANS “State of the Endpoint Security” Survey March 2016

7. Come funziona un attacco
Weaponize
Deliver
Exploit
Maintain
Control
ExecuteRecon
Defense
Evasion
Credential
Access
Discovery
Privilege
Escalation
Persistence
Collection
Exfiltration
Command &
Control
Execution
Lateral
Movement
Fonti:
- MITRE Attack Tactics
- HPE Cyber Intelligence
0-day
Web

8. 9 Marzo 2017
La RAND corporation pubblica un report sugli
0day. Report criticato da alcuni*
Cosa è successo negli ultimi giorni
8
7 Marzo 2017
Wikileaks rilascia Valut7, una serie di documenti relativi
alle capacità della CIA rispetto al Cyber Warfare con
diverse informazioni sugli 0day in loro possesso.
6 Marzo 2017
E’ in discussione una legge americana sull’»hack back»

9. Alcuni numeri del report RAND sugli 0-day
9
Tempo medio di
vita di un exploit
6.9 anni
Media per lo
sviluppo di un
exploit (max 955)
22 giorni
Picco di prezzo per gli
“unicorni”, exploit affidabili ed
efficenti per la compromissione
remota di iOS.
$50/300k
Fonti: RAND RR1751
25%
Prezzo sul mercato «grigio» e «bianco»
Costo medio per lo sviluppo
di un exploit
$30k~ $30/50k
Prezzo sul mercato «nero»
«tasso di mortalità» dopo 1
anno
$ 1.000.000/1.500.000

10. Cosa sono gli 0-day e perché
sono importanti
10

11. Cosa sono le vulnerabilità zero-day?
11
«Le vulnerabilità Zero-Day sono
vulnerabilità nel software per le quali
non è stata rilasciata pubblicamente
una patch o una fix.
Il numero indica da quanti giorni il
vendor è a conoscenza della
vulnerabilità (per poter sviluppare una
patch/fix)»
Libicki, Ablon, and Webb - citati in Zero Days, Thousands of Nights
(2017)
“Software patch”
foto di Gabriele Asbesto Zaverio

12. Un po’ di definizioni
12
Un bug è una problematica nel codice
o nella sua progettazione che genera
un malfunzionamento, risultati errati o
un crash/terminazione anomala
Un bug di sicurezza è un bug che ha
delle implicazioni relative alla
sicurezza: può essere usato per
compromettere il sistema o una delle
sue componenti.
Non tutti i bug di sicurezza sono
potenzialmente sfruttabili, quando lo
sono vengono chiamati vulnerabilità.
L’exploit quel codice e/o quella
procedura che permette di trarre
vantaggio di una o pi vulnerabilità
Non tutto isanno che, negli anni ’90, lo zero-day era invece un software sotto copytight che
veniva rilasciato senza protezioni lo stesso giorno o prima. Era un segno di vanto per i gruppi
che ci riuscivano.

13. Responsible disclosure
Una delle possibili storie
13
Introduzione della vulnerabilità
nel codice, in maniera più o meno
dolosa.
La vulnerabilità viene scoperta
in maniera più o meno casuale, da
ricercatori / sviluppatori.
Viene scritto un Exploit / PoC
per sfruttare/dimostrare la
vulnerabilità*.
Segnalazione al Vendor che
collabora con il ricercatore per il fix,
ci si accorda per la pubblicazione.
La vulnerabilità resa pubblica
e il ricercatore debitamente
ringraziato (l’exploit/PoC dipende)
La patch viene installata
da chi utilizza il software
vulnerabile.
Viene rilasciata una patch
di solito in concomitanza con la
pubblicazione.
Può avvenire tramite
intermediari che possono fare una
disclosure .
Rilascio di una signature
da parte di intermediari o comunque
informazioni tramite feed.

14. Full disclosure
Una delle possibili storie
14
Introduzione della vulnerabilità
nel codice, in maniera più o meno
dolosa.
La vulnerabilità viene scoperta
in maniera più o meno casuale, da
ricercatori / sviluppatori.
Viene scritto un Exploit / PoC
per sfruttare/dimostrare la
vulnerabilità*.
Il vendor viene a conoscenza,
insieme al pubblico della
vulnerabilità e correi ai ripari.
La patch viene installata
da chi utilizza il software
vulnerabile.
Viene rilasciata una patch
di solito in concomitanza con la
pubblicazione.
La vulnerabilità resa pubblica
(l’exploit/PoC dipende) tramite liste,
blog o altri canali.

15. Disclose nothing (o almeno non al produttore)
Una delle possibili storie
15
Introduzione della vulnerabilità
nel codice, in maniera più o meno
dolosa.
La vulnerabilità viene scoperta
in maniera più o meno casuale, da
ricercatori / sviluppatori.
Viene scritto un Exploit / PoC
per sfruttare/dimostrare la
vulnerabilità*.
L’exploit viene
venduto/affittato/sfruttato da un
gruppo limitato/privato di persone.
La patch viene installata
da chi utilizza il software
vulnerabile.
Viene rilasciata una patch
di solito in concomitanza con la
pubblicazione.
Viene raffinato l’exploit
per aumentarne affidabilità ed
efficienza.
La vulnerabilità/exploit diventano
pubblici per qualche motivo***.

16. Il mercato degli 0-day
La legge della richiesta e dell’offerta
– Full disclosure tramite dei canali appositi (in questo caso non c’è
guadagno).
– Responsible disclosure (direttamente o tramite una terza parte), se
sono presenti programmi di bounty o eventi appositi (Pwn2Own).
– Discolse nothing, con eventuale vendita privata ad altre
organizzazioni, tramite broker. A questo punto l’exploit può finire in
qualche arsenale privato e sfruttato in rivendita o in affitto.
16
Copertina del libro di Carola
Frediani, Guerre di Rete, il cap. 2 è
dedicato a questo fenomeno.
Il guadagno massimo (listino pubblico di noto aquisition
program)
$ 100k-1.5M Sistemi operativi mobile
$ 50/80k Hypervisor, Lettori, Browser, Servizi web
$ 40k Bypass, Antivirus, Office, Servizi di posta
$ 30k Sistemi operativi PC/Server e Browser
$ 10k Applicazioni Web
Cosa fare con uno 0-day
Fonti:
- Zerodium – Acquisition program (2016)
- Carola Frediani – Guerre di rete (2017)

17. Storia da «Guerre di Rete»
Settembre 2015 Agosto 2015 Agosto 2015 Febbraio 2016 Marzo 2016
L’FBI
Chiede ad Apple
di sbloccare il
telefono di un
terrorista. Apple
si rifiuta.
Cellbrite
Sblocca il
telefono, l’FBI
indica come
prezzo una cifra
maggiore di
$1.3M
Exodus
Intelligence
Sulla scia di
Apple, offre per
le stesse
vulnerabilità più
del doppio
Apple
Stabilisce un
programma di
bug bounty di
200k dollari
Zerodium
Offre 3 taglie da
1 milione di
dollari l’una per
delle vulnerabilità
su Apple iOS
17
Sulle vulnerabilità di iOS
La cifra stellare […] è anche un
campanello d’allarme […] esistevano
compratori altrettanto stellari.
Nel 2013 l’NSA ha stanziato 25,1
milioni di dollari per l’acquisto di
vulnerabilità.
Le aziende produttrici cercano di
arginare il fenomeno attraverso Bug
Bounty, ma è difficile competere
Fonti:
- Carola Frediani – Guerre di rete (2017)
- USA Today - Apple v FBI timeline: 43 days that rocked tech

18. Come trovarli
18

19. «Non è magia – solo
creatività, intelligenza e
molta dedizione»
Enrico Perla, Massimiliano Oldani - A Guide to Kernel Exploitation (2011)
19

20. Come trovare delle vulnerabilità
Ogni ricercatore ha un suo metodo strettamente personale, non esiste una prassi standard per la ricerca
ma piuttosto delle tecniche comuni relativamente all’approccio statico o dinamico. Entrambi hanno dei pro e
dei contro.
Analisi statica
– Si analizza il codice sorgente dell’applicazione
(quindi presuppone di avere i sorgenti) oppure il
disassemblato, senza quindi eseguire il codice.
– Serve conoscere il linguaggio con la quale è
scritto il software e le sue problematiche.
e.g. Quindi per le applicazioni web tipicamente
gli interpretati, quando si analizza il kernel si
utilizza il C e il codice assembly, per applicazioni
Windows il .NET ecc...
Analisi dinamica
– Si analizza l’applicazione o il sistema
quando è in esecuzione manipolando gli
input in ingresso (e.g. fuzzing) e/o tramite
debugger.
– Si può fare a mano ma solitamente si scrive
uno strumento che automatizza fuzzer (da zero
o tramite diversi framework per il fuzzing) per
poter mandare in crash l’applicazione e
analizzarne i log e i dump.
20
Quando analizziamo i linguaggi interpretati possiamo impattare anche sulle funzioni dell’interprete che
normalmente sono scritte in un linguaggio di livello più basso (e.g. possiamo analizzare un’applicazione
scritta in PHP e quindi andare ad insistere sia su codice PHP che sul C sottostante dell’interprete).

21. ARC v2011-12-01 Multiple vulnerabilities
Dalla dimostrazione di una SPARQL Injection al database MySql
1. In occasione degli OWASP Days a
Roma, abbiamo mandato una proposta
relativa da una vulnerabilità di tipo
Injection che insisteva su un linguaggio
che – prima dell’avvento del Big Data –
era piuttosto di nicchia: SPARQL.
2. Per la dimostrazione pratica durante la
conferenza abbiamo usato il framework
semantico ARC che si basa su PHP e
MySql.
3. Il framework – come succede per le
ORM, presenta un livello logico
«semantico» e converte «al volo» le
varie query SPARQL in query SQL dove
effettivamente vengono memorizzati i
dati.
21

22. ARC v2011-12-01 Multiple vulnerabilities
La dimostrazione della SPARQL Injection
4. Abbiamo creato quindi una macchina
virtuale dedicata allo scopo, installato
PHP, MySql e il framework ARC.
5. Quindi abbiamo scritto un’applicazione
IAM in PHP con una funzionalità di
autenticazione che utilizza una query
SPARQL.
6. Volutamente, l’applicazione non
verificava i dati in ingresso e pertanto,
inserendo dell’input malformato
secondo la sintassi di SPARQL – nello
specifico i caratteri ’’ e # - ha permesso
di eseguire una query SPARQL con la
quale è stato possibile bypassare il
sistema di autenticazione.
22

23. ARC v2011-12-01 Multiple vulnerabilities
Oltre la SPARQL Injection
7. Una delle funzionalità
interessanti dei framework
SPARQL, è la possibilità di
offrire degli end-point semantici
per poter garantire il concetto
di Open Data.
8. Questo è stato particolarmente
utile per fare debug della
nostra applicazione.
9. Durante una delle richieste di
Injection una query malformata
l’errore che ha restituito
l’endpoint era quello di MySql.
10.Era presente un problema nel
codice che converte le query
SPAQL in MySql.
23

24. ARC v2011-12-01 Multiple vulnerabilities
Oltre la SPARQL Injection
11.Abbiamo preparato un Proof on
Concept relativo alla SQL Injection,
così da poter confermare lo
sfruttamento e verificato i sorgenti.
12.Abbiamo deciso per la Responsible
Disclosure, quindi abbiamo contattato
gli sviluppatori.
13.Ci hanno ringraziato, confermato la
vulnerabilità e rilasciato la patch.
14.Abbiamo così presentato tutto il
processo e rilasciato un advisory
relativa alla problematica (che
conteneva anche altre vulnerabilità).
24

25. Bug Bounty su un noto sito web
L’inizio della sfida
1. Un noto sito di contenuti ***** utilizza una
piattaforma di Bug Bounty per la segnalazione di
vulnerabilità sui propri sistemi esposti.
2. Due ricercatori (Ruslan Habalov e Dario Weißer)
decidono di accettare la sfida e di cercare delle
vulnerabilità.
3. Hanno analizzato dinamicamente l’applicazione
identificando l’utilizzo di «unserialize» di PHP in
particolare nel cookie [1].
4. Dopo averlo identificato hanno inviato un array
contenente un oggetto e notato che l’output
permette potenzialmente il rilascio di informazioni
[2].
5. E’ presente diversa documentazione relativa
all’exploiting della funziona unserialize() in PHP in
particolare per quel che riguarda le vulnerabilità di
memory corruption.
25
POST /album_upload/create HTTP/1.1
...
tags=xyz&title=xyz...&cookie=a:1:{i:
0;i:1337;}
Response Header:
Set-Cookie: 0=1337; expires
tags=xyz&title=xyz...&cookie=a:1:{i:
0;O:9:"Exception":0:{}}
0=exception 'Exception' in /path/t
o/a/file.php:1337
Stack trace:
#0 /path/to/a/file.php(1337): unse
rialize('a:1:{i:0;O:9:"E...')
#1 {main}
1
2

26. Bug Bounty su un noto sito web
Fuzzing e protezioni
6. Secondo la documentazione un modo per
sfruttare questa vulnerabilità è una tecnica
chiamata Property-Oriented-Programming (POP),
ma senza avere accesso al sorgente lo
sfruttamento era complesso.
7. Per quel che riguarda PHP, il codice sorgente era
piuttosto ampio e altre vulnerabilità erano state
già trovate.
8. I ricercatori scelgono quindi l’approccio del
Fuzzing, scrivendo un loro fuzzer specifico per
unserialize() e lo hanno provato sull’ultima
versione di PHP in locale, con risultati
interessanti.
9. Utilizzando la stessa tecnica sul bersaglio invece
non hanno avuto gli stessi risultati, generando
circa 1Tb di log da analizzare.
26
10.I ricercatori hanno quindi cambiato il loro
approccio al fuzzing fino a trovare dei dati binari
restituiti all’interno dei log.
11.Dopo molto tempo – non hanno specificato
quanto – sono riusciti a confermare una
problematica relativa alla gestione della memoria
(use-after-free).
12.Ulteriori ricerche hanno confermato che la
problematica era presente nel garbage collector e
non nell’unserialize() in se.
13.Dopo aver compreso meglio l’origine della
vulnerabilità per poterla sfruttare hanno dovuto
lavorare su diverse protezioni per poter sfruttare
le vulnerabilità.

27. Quando abbiamo gli 1-day
Cosa possiamo imparare quando viene rilasciata un patch
Ci serve un PoC per un Penetration Test?
Non riusciamo a fare l’aggiornamento
completo ma vogliamo proteggerci?
– Se abbiamo difficoltà a eseguire l’aggiornamento alla
release (ma questo potrebbe essere sintomo di cose
più gravi), è possibile osservare il sorgente
modificato (diff) e fare noi stessi una patch.
– Se non è disponibile un exploit o un PoC – e ci serve
in un Penetration Test - possiamo osservare il codice
vulnerabile e capire come sfruttarlo.
– Se non abbiamo il sorgente, è possibile fare anche il
diff dei binari, tramite appositi strumenti. Esempio di BinDiff di Zynamic
27
Dal punto di vista dell’attaccante, anche quando una patch viene rilasciata,
non è detto che tutti riescano ad applicarla in tempo, pertanto quando viene
pubblicata una vulnerabilità con un buon exploit spesso di notano una serie
di attacchi su quella vulnerabilità*

28. Come proteggersi
28

29. Approccio alla difesa
29
Fonte:https://www.mitre.org/capabilities/cybersecurity/threat-based-defense
Server
O.S.
Net Svcs
Web Application
Client/PC
O.S.
Client Apps
Browser/Player
Weaponize
Deliver
Exploit Maintain
Control
ExecuteRecon
Focus sulla prevenzione e
l’identificazione degli
attacchi
Focus sull’Incident
Response

30. Come difendersi dagli 0-day e non solo
Gli zero-day ci sono e li useranno contro di noi
Zero-day
- Possiamo prevenire trovandoli prima di un avversario:
- Penetration Test, Code Review…
- Avere un canale coi ricercatori
- Analisi dei log/anomalie
- Possiamo limitare gli impatti avendo un approccio
strategico:
- Strutturare le difese «in profondità» e «in larghezza».
- Implementare in ogni aspetto i principi del «privilegio
minimo» e «separazione dei ruoli», come per le
configurazioni.
Non solo zero-day
- Tenere aggiornato il software e attenzione agli «immortali»
- Ricordare che minacce molto frequenti e che hanno
successo (e.g. Ransomware) non usano 0-day.
30

31. Grazie!
31