Slides from Simone Onofri talk @Codemotion Roma 2014

1. ROME 11-12 april 2014ROME 11-12 april 2014
Hackers vs Developers: vulnerabilità e soluzioni nello sviluppo di
applicazioni Mobile
simone.onofri@techub.it
Simone Onofri

2. Introduzione

4. h,p://onofri.org/u/hvd14

5. Agenda
• Introduzione
• Cosa
succede
nel
mondo
della
sicurezza
del
mobile
• Quali
sono
gli
a5acchi
e
le
minacce?
• Cosa
ne
pensa
OWASP?
• Come
rendere
sicure
le
nostre
applicazioni
mobile
• Q&A
e
Conclusioni

6. Agenda
• Introduzione
• Cosa
succede
nel
mondo
della
sicurezza
del
mobile
• Quali
sono
gli
a5acchi
e
le
minacce?
• Cosa
ne
pensa
OWASP?
• Come
rendere
sicure
le
nostre
applicazioni
mobile
• Q&A
e
Conclusioni

7. Perché
siamo
qui

8. Cosa
succede
nel
mondo?

9. Computer
Security
Timeline
1970
Nei
primi
anni
nasce
il
primo
Virus,
infe5a
gli
Apple
e
si
diffonde
tramite
Floppy.
Negli
ulAmi
anni
nascono
i
Worm,
alcuni
dei
quali
cifrano
il
disco.
A,acchi
alle
PA.
1980 1990
Blue
Box
Phreaking
da
Capitan
Crunch.
A5acchi
alle
compagnie
telefoniche.
Il
mezzo
di
propagazione
è
spesso
l’e-­‐mail
e
i
bersagli
sono
i
sistemi
operaAvi
MicrosoI
(a5accando
es.
Outlook
express).
Il
bersaglio
sono
le
persone.

10. Computer
Security
Timeline
2000
Si
denunciano
Advanced
Persistent
Threat.
I
disposiAvi
mobile
diventano
un
bersaglio
Apico.
Sono
molto
frequenA
a5acchi
a
sfondo
poliQco.
Diventa
evidente
come
quesA
strumenA
siano
usaQ
come
armi.
2010
I
Virus
a5accano
anche
i
servizi
di
rete
(es.
Slammer,
Sasser
e
Blaster).
Iniziano
gli
a5acchi
alle
Applicazioni
Web
e
su
SCADA.
L’obieQvo
è
anche
creare
disservizi.
E’
a
tuQ
gli
effeQ
un
Business.

11. Aumenta
la
sofisAcazione
degli
a,acchi
che
mirano
a
creare
un
disservizio
e
di
quelli
che
hanno
come
bersaglio
le
applicazioni
web.

12. A5acchi
frequenA
sono
ai
disposiAvi
Mobile,
bersaglio
di
malware
per
rubare
conQ
o
transazioni
bancarie,
daQ
di
accesso
(social,
e-­‐mail).
Furto
di
idenQtà
e
di
daA
più
in
generale.

13. Sopra5u5o
sul
sistema
operaAvo
Android.
Ne
è
moAvo
la
forte
diffusione
e
il
fa5o
che
non
sono
spesso
distribuiQ
tempesQvamente
gli
aggiornamenQ
di
sicurezza
da
parte
dei
provider
che
“brandizzano”
il
disposiAvo

14. Aumenta
la
sofisAcazione
degli
a,acchi
che
mirano
a
creare
un
disservizio
e
di
quelli
che
hanno
come
bersaglio
le
applicazioni.

15. gli
a5accanA
tendono
a
sfru5are
vulnerabilità
che
sono
presenA
a
causa
di
praQche
di
sicurezza
basilari
inadeguate

16. app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
Circa
la
metà
delle
applicazioni
web
hanno
vulnerabilità
importanA
secondo
l’X-­‐Force
50%

17. app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
app
Quasi
tu5e
le
applicazioni
sono
vulnerabili
secondo
il
report
CENZIC
99%

18. Le
principali
problemaQche
delle
applicazioni
mobile

19. La
TOP
10
Risk
Mobile
(2013
vs
2014
RC1)
M1:Insecure
Data
Storage
M2:Weak
Server
Side
Controls
M3:Insufficient
Transport
Layer
ProtecQon
M4:
Client
Side
InjecQon
M5:
Poor
AuthorizaQon
and
AuthenQcaQon
M6:
Improper
Session
Handling
M7:
Security
Decisions
Via
Untrusted
Inputs
M8:
Side
Channel
Data
Leakage
M9:
Broken
Cryptography
M10:
SensiQve
InformaQon
Disclosure
M1:
Weak
Server
Side
Controls
M2:
Insecure
Data
Storage
M3:Insufficient
Transport
Layer
ProtecQon
M4:
Unintended
Data
Leakage
M5:
Poor
AuthorizaQon
and
AuthenQcaQon
M6:
Broken
Cryptography
M7:
Client
Side
InjecQon
M8:
Security
Decisions
via
Untrusted
Inputs
M9:
Improper
Session
Handling
M10:
Lack
of
Binary
ProtecQon

20. Il
nostro
disposiQvo
mobile
Hardware
Sistema
OperaQvo
RunQme
Applicazioni
Aziendali
Personali
Bult-­‐in
Malicious
Librerie Dipendenze
VM
Kernel Driver
File
System
Radio GPS
Sensori
Estensioni
hardware
Le,ori/
Sensori
802.11 /
NFC /
Bluetooth
Peer
Rete del Carrier SMS
Voce
DaQ
WiFi /VPN
(o via Carrier)
Web
M2:
Insecure
Data
Storage
M1:
Weak
Server
Side
Controls
M3:
Insufficient
Transport
Layer
ProtecQon
M8:
Security
Decisions
via
Untrusted
Inputs
M5:
Poor
AuthorisaQon
and
AuthenQcaQon
M6:
Broken
Cryptography
M7:
Client
Side
InjecQon
M4:
Unintended
Data
Leakage
M9:
Improper
Session
Handling
M10:
Lack
of
Binary
ProtecQon

21. Come
rendere
sicure
le
nostre
applicazioni
mobile

22. M1.
Weak
Server
Side
Controls
Sono
quelle
problemaAche
che
dipendono
dai
servizi
che
uQlizza
l’applicazione
mobile,
come
il
servizio
web
uAlizzato
(Web
Service,
REST,
SOAP).
Se
la
nostra
applicazione
uAlizza
servizi
esterni
anche
quesA
devono
essere
sicuri
e
non
dobbiamo
solamente
concentrarci
sulle
problemaAche
dell’applicazione
in
se.
Gli
a,accanQ
non
fanno
troppe
disQnzioni
tra
vulnerabilità
web,
Mobile
o
di
sistema
ma
sfru,eranno
quella
più
semplice.

23. Riflessioni
e
SuggerimenQ
• UAlizziamo
servizi
Web?
Facciamo
riferimento
alla
OWASP
TOP
10
Web
(almeno
per
iniziare).
• UAlizziamo
servizi
Cloud?
Facciamo
riferimento
alla
TOP
10
Cloud.

24. 2003/2004
(a,acks)
2007
(vulnerabiliQes)
2010
(risks)
2013
(risks)
Unvalidated
Input Cross
Site
ScripQng
(XSS) InjecQon InjecQon
Broken
Access
Control InjecQon
Flaws Cross-­‐Site
ScripQng
(XSS)
Broken
AuthenQcaQon
and
Session
Management
Broken
AuthenQcaQon
and
Session
Management
Malicious
File
ExecuQon
Broken
AuthenQcaQon
and
Session
Management
Cross-­‐Site
ScripQng
(XSS)
Cross
Site
ScripQng
(XSS)
Flaws
Insecure
Direct
Object
Reference
Insecure
Direct
Object
References
Insecure
Direct
Object
References
Buffer
Overflows
Cross
Site
Request
Forgery
(CSRF)*
Cross-­‐Site
Request
Forgery
(CSRF)
Security
MisconfiguraQon
InjecQon
Flaws
InformaQon
Leakage
and
Improper
Error
Handling
Security
MisconfiguraQon SensiQve
Data
Exposure
Improper
Error
Handling
Broken
AuthenQcaQon
and
Session
Management
Insecure
Cryptographic
Storage
Missing
FuncQon
Level
Access
Control
Insecure
Storage
Insecure
Cryptographic
Storage
Failure
to
Restrict
URL
Access
Cross-­‐Site
Request
Forgery
(CSRF)
Denial
of
Service Insecure
CommunicaQons
Insufficient
Transport
Layer
ProtecQon
Using
Known
Vulnerable
Components
Insecure
ConfiguraQon
Management
Failure
to
Restrict
URL
Access
Unvalidated
Redirects
and
Forwards
Unvalidated
Redirects
and
Forwards

25. M2.
Insecure
Data
Storage
Sono
quelle
problemaAche
di
protezione
dei
daQ
memorizzaQ.
Si
concreAzzano
quando
viene
compromesso
il
disposiAvo
tramite
applicazioni
malevoli
oppure
in
caso
di
furto.
Se
ci
sono
delle
informazioni
riservate
(es.
password,
CVV2,
daA
privaA)
devono
essere
proteQ.

26. Riflessioni
e
SuggerimenQ
• Se
il
disposiAvo
viene
rubato,
oppure
è
presente
un
trojan
o
altra
applicazione
malevola
la
nostra
applicazione
deve
proteggere
i
daA
che
gesAsce.
• Fare
a5enzione
a
quando
si
memorizzano
informazioni
su:
• Database
SQLite
• File
di
Log
• Plist
• XML
• File
Manifest
• Storage
di
altro
Apo
su
file
• Cookie
• Schede
SD

27. M3.
Insufficient
Transport
Layer
ProtecQon
Sono
quelle
problemaAche
relaAve
alla
sicurezza
della
comunicazione,
perme5ono
di
interce5are
il
traffico
tra
l’utente
e
il
server
o
tra
server
differenA.
Come
per
le
altre
vulnerabilità
il
problema
potrebbe
consistere
o
nella
mancanza
del
controllo
stesso
(come
l’uAlizzo
di
HTTP)
o
nelle
problemaAche
di
configurazione
di
SSL/TLS
sia
lato
server
ma
in
parAcolare
lato
disposiAvo
mobile.

28. Riflessioni
e
SuggerimenQ
• Tipicamente
un
disposiAvo
mobile
viene
uAlizzato
tramite
la
rete
del
Carrier
(di
cui
ci
fidiamo?)
oppure
tramite
reA
Wireless
casalinghe
oppure
gratuite
(anche
in
Italia
cominciano
a
diffondersi)
• Dobbiamo
proteggere
l’applicazione:
• Tramite
il
server
(configurandolo
corre5amente
e
tenendolo
aggiornato)
• Tramite
l’applicazione
(validare
e
acce5are
solamente
cerAficaA
trusted)

29. Breaking
News!

30. M4.
Unintended
Data
Leakage
Prima
chiamata
Side-­‐Channel
Data
Leakage
è
una
so,o-­‐categoria
della
più
completa
Insecure
Data
Storage,
riguarda
dove
vengono
salvaA
i
daA.
Sono
quelle
problemaAche
che
rendono
accessibili
informazioni
che
invece
dovrebbero
essere
prote5e.
Solitamente
generata
da
un
uAlizzo
non
corre5o
del
Sistema
OperaAvo,
di
Framework,
Compilatori
senza
che
gli
sviluppatori
ne
siano
a
conoscenza.

31. Riflessioni
e
SuggerimenQ
• E’
possibile
che
librerie,
framework
o
il
sistema
operaAvo
salvino
in
qualche
locazione
non
prote5a
informazioni
sensibili.
Bisogna
fare
a5enzione
a:
• Caching
delle
richieste/risposte
HTTP
e
dei
Cookie
• Caching
della
tasAera
• Sistemi
che
mantengono
i
Log
o
che
inviano
staAsAche
• Storage
di
HTML5

32. A5.
Poor
AuthorizaQon
and
AuthenQcaQon
Sono
quelle
problemaAche
che
riguardano
AutenQcazione
e
Autorizzazione,
elemenA
cruciali
in
parAcolare
per
le
applicazioni
mobile.
Secondo
la
stru5ura
dell’applicazione
quesA
due
controlli
potrebbero
essere
gesAA
dire5amente
sul
disposiAvo
oppure,
se
l’applicazione
si
collega
a
dei
servizi
web,
devono
essere
gesAA
dire5amente
lato
server.
Inoltre
è
importante
la
scelta
dei
vari
criteri
da
uAlizzaA
per
idenAficare
(e
quindi
poi
autenAcare
l’utente).

33. Riflessioni
e
SuggerimenQ
• GesAre
sempre
l’autenAcazione
e
l’autorizzazione
lato
server,
e
fornire
i
daA
solo
previa
verifica.
• Se
bisogna
memorizzare
delle
informazioni
sul
disposiAvo
e
prevedere
più
utenA
allora
cifrare
le
informazioni
così
da
non
renderle
accessibili.
• A5enzione
alle
funzionalità
di
“Ricordami”
e
al
salvataggio
dei
Token
di
autenAcazione.
• Non
uAlizzare
informazioni
che
possono
essere
alterate
per
l’autenAcazione
(es.
device
id,
caller
id).

34. M6.
Broken
Cryptography
Questa
problemaAca
relaAva
alla
protezione
delle
informazioni
memorizzate,
consiste
nell’uAlizzo
di
algoritmi
cri5ografici
non
sicuri
o
uAlizzaA
in
maniera
errata.
Gli
algoritmi
uAlizzaA
devono
essere
infaQ
consideraA
sicuri
dalla
comunità
ed
essere
uAlizzaA
corre5amente.

35. Riflessioni
e
SuggerimenQ
• Quando
si
uAlizzano
elemenA
cri5ografici
dobbiamo:
• Usare
solamente
algoritmi
consideraQ
sicuri
(es.
evitare
MD5,
SHA1)
• UAlizzarli
in
maniera
propria
(es.
Password
con
gli
hash
e
non
con
cifratura
simmetrica)
• GesAre
corre5amente
le
chiavi
cri5ografiche
e
i
cerAficaA.

36. M7.
Client
Side
InjecQon
Questa
problemaAca
apparAene
alla
validazione
dei
daQ,
in
quanto
l’applicazione
interagisce
con
l’esterno
a5raverso
dei
daA.
Può
ricevere
daA
dall’utente
come
da
altre
enAtà
come
sensori,
hardware,
database
interni
o
dire5amente
dal
nostro
web
server.
QuesA
daA
possono
essere
manipolaA
più
o
meno
facilmente
e
pertanto
devono
essere
verificaA
per
evitare
comportamenA
anomali
dell’applicazione.

37. Riflessioni
e
SuggerimenQ
• Quando
riceviamo
daA
dall’utente
o
da
fonA
esterne
all’applicazione,
anche
quelli
memorizzaA
all’interno
di
un
database
locale
dobbiamo
sempre
considerare
che
possiamo
ricevere
daA
alteraA
e
fare
a5enzione
ai
daA
che
sono
uAlizzaA
da:
• Database,
per
le
SQL
InjecAon
• File
System,
per
le
File
Inclusion
• InterpreA
più
in
generale
(XML,
Xpath,
Xquery…)
e
anche
funzioni
matemaAche.
• UAlizziamo
HTML5?
h5p://onofri.org/u/html5sec

38. M8.
Security
Decisions
via
Untrusted
Inputs
L’applicazione
potrebbe
interagire
con
i
processi
esterni,
esempio
tramite
l’Inter-­‐Process
CommunicaAon
(IPC)
di
iOS.
Oppure
su
Android
altre
applicazioni
potrebbero
avere
i
permessi
per
accedere
ad
alcune
componenA.
Tali
interazioni
devono
essere
sempre
verificate.

39. Riflessioni
e
SuggerimenQ
• L’applicazione
può
acce5are
daA
ed
essere
uAlizzata
anche
da
altre
applicazioni:
l’accesso
a
tale
componenA
devono
essere
gesAte
corre5amente.
• Ad
esempio
su
iOS:
• NON
uAlizzare
handleOpenURL
ma
openURL,
uAlizzando
una
whitelist
per
le
applicazioni.
NON
uAlizzare
la
Pasteboard
per
le
comunicazioni
IPC.
• Su
Android
configurare
corre5amente
AndroidManifest.xml:
per
le
componenA
private
uAlizzare
android:exported=false,
per
le
altre
uAlizzare
true
ma
specificare
l’android:permission.

40. M9.
Improper
Session
Handling
HTTP
è
un
protocollo
state-­‐less
e
per
mantenere
la
sessione
aQva
tra
Client
e
Server
viene
stabilita
una
sessione
a5raverso
l’uAlizzo
di
Cookie
o
di
Token
univoci.
La
sessione
deve
essere
prote5a
sia
lato
server,
come
indicato
in
M1,
sia
lato
Client
con
dovuA
accorgimenA
sia
per
quel
che
riguarda
la
protezione
del
Cookie
e/o
del
Token
che
per
quel
che
riguarda
la
gesAone
delle
informazioni
contenute
all’interno
della
sessione
che
devono
essere
distru5e
quando
la
sessione
termina.
Lo
stesso
Ameout
della
sessione
(assoluto
e
relaAvo)
deve
essere
ben
definito
e
coerente
con
il
contesto.

41. Riflessioni
e
SuggerimenQ
• La
gesAone
della
sessione
è
un
elemento
Apicamente
criQco,
in
parAcolare
se
la
nostra
applicazione
manQene
aqva
la
sessione
verso
il
web
server.
La
sessione
deve
essere
gesAta
corre5amente
lato
server
(come
specificato
per
M1),
ma
anche
lato
client
distruggendo
corre5amente
i
daA
alla
fine
della
sessione.
• Deve
essere
specificato
un
Qmeout
assoluto
(tempo
di
vita
massimo)
e
relaAvo
(dall’ulAmo
uAlizzo)
in
coerenza
con
il
contesto
applicaAvo.
• I
Cookie
o
più
in
generale
i
Token
di
sessione
devono
essere
gesQQ
corre,amente
(es.
cambiaA
ad
ogni
login
e
devono
essere
abbastanza
complessi
e
casuali
da
resistere
ad
a5acchi
di
cri5oanalisi
o
brute-­‐force).

42. M10.
Lack
of
Binary
ProtecQon
L’applicazione
stessa
deve
essere
prote5a
come
anche
il
suo
codice
sorgente.
Il
disposiAvo
mobile
deve
essere
considerando
un
“ambiente
osAle”
per
la
nostra
applicazione
e
dobbiamo
proteggerla
da
eventuali
a5acchi
come
il
reverse
engineering,
la
modifica
di
eventuali
componenA
(es.
file
web
presenA
in
locale)
o
dei
binari
stessi.
Le
tecniche
per
la
protezione
sono
diverse
e
cambiano
da
ambiente
ad
ambiente.

43. Riflessioni
e
SuggerimenQ
• Dobbiamo
considerare
osAle
l’ambiente
mobile
e
difendere
la
nostra
applicazione,
il
suo
codice
sorgente
e
i
vari
elemenA
residenA
sul
disposiAvo
uAlizzaA
dall’applicazione,
ad
esempio
verificando
l’integrità
delle
componenA
uAlizzate
o
se
viene
inserito
del
codice
al
runAme:
• Su
iOS
verificando
se
il
disposiAvo
è
stato
so5oposto
a
Jailbreak
o
se
è
possible
eseguire
il
dump
dell’eseguibile
(es.
Clutch)
• Su
Android
verificando
se
il
disposiAvo
è
stato
rootato
e
offuscando
il
codice.

44. Conclusioni

45. Mobile App

47. Security
User
GrOup
!
h,ps://groups.google.com/forum/#!
forum/sugo

48. GRAZIE!
;-­‐)http://onofri.org/
http://twitter.com/simoneonofri
http://it.linkedin.com/simoneonofri
http://slideshare.net/simoneonofri

49. DOMANDE
?http://onofri.org/
http://twitter.com/simoneonofri
http://it.linkedin.com/simoneonofri
http://slideshare.net/simoneonofri