Hackers vs Developers: vulnerabilità e soluzioni nello sviluppo di applicazioni Mobile

ROME 11-12 april 2014ROME 11-12 april 2014

Hackers vs Developers: vulnerabilità e soluzioni nello sviluppo di applicazioni Mobile

[email protected]

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

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

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


Circa la metà delle applicazioni web hanno vulnerabilità importanA secondo l’X-‐Force

50%



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



M8: Security Decisions via Untrusted Inputs


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



M4: Unintended Data Leakage


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.


• 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.


• 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.


• 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).


•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.


•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.


•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

http://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.


• 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.


• 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.


• 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

Hackers vs Developers: vulnerabilità e soluzioni nello sviluppo di applicazioni Mobile

Technology

Transcript of Hackers vs Developers: vulnerabilità e soluzioni nello sviluppo di applicazioni Mobile