ROME 11-12 april 2014ROME 11-12 april 2014
Hackers vs Developers: vulnerabilità e soluzioni nello sviluppo di applicazioni Mobile
Simone Onofri
Introduzione
h,p://onofri.org/u/hvd14
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
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
Perché siamo qui
Cosa succede nel mondo?
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.
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.
Aumenta la sofisAcazione degli a,acchi che mirano a creare un disservizio e di quelli che hanno come bersaglio le applicazioni web.
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.
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
Aumenta la sofisAcazione degli a,acchi che mirano a creare un disservizio e di quelli che
hanno come bersaglio le applicazioni.
gli a5accanA tendono a sfru5are vulnerabilità che sono presenA a causa di praQche di
sicurezza basilari inadeguate
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%
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%
Le principali problemaQche delle applicazioni mobile
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
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 /
BluetoothPeer
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
Come rendere sicure le nostre applicazioni mobile
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.
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.
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
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.
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
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.
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)
Breaking News!
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.
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
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).
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).
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.
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.
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.
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
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.
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.
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.
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).
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.
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.
Conclusioni
Mobile App
Security User GrOup !
h,ps://groups.google.com/forum/#!forum/sugo
GRAZIE!
;-‐)http://onofri.org/ http://twitter.com/simoneonofri http://it.linkedin.com/simoneonofri http://slideshare.net/simoneonofri
DOMANDE
?http://onofri.org/ http://twitter.com/simoneonofri http://it.linkedin.com/simoneonofri http://slideshare.net/simoneonofri