Seminario sulla sicurezza delle applicazioni...

27 gennaio 2015Università degli Studi di Verona

Andrea Zwirner – LinkspiritSeminario sulla sicurezza delle applicazioni mobili 1

Seminario sulla sicurezza delle applicazioni mobili

Andrea Zwirner

[email protected]

@AndreaZwirner

Sicurezza informatica

Università degli Studi di VeronaCorso di Laurea Magistrale in Informatica



● Mi interesso di sicurezza informatica dallo scorso millennio

– “Connettere” significava “intrecciare”

– Hacker non aveva ancora alcun significato

● Ho fondato Linkspirit, azienda che si occupa di

– Consulenza nella progettazione di software e sistemi

– Verifiche di sicurezza su software e sistemi

– Formazione in materia di sicurezza informatica

Chi sono



Cosa faccio

● Partecipo a diversi progetti liberi legati la divulgazione della cultura sulla sicurezza informatica

www.isecom.org

www.hackerhighschool.org

www.owasp.org

Progetto scuole www.progettoscuole.it



Di cosa parliamo oggi

● OWASP Mobile Security Project: analisi delle 10 vulnerabilità più rischiose in ambito mobile

– Descrizione tecnica

– Scenari ed esempi d'attacco

– Modalità di rilevazione e prevenzione

● Sguardo ai rischi derivanti da reverse engineering e modifica dinamica del codice applicativo

● Scorsa dei 10 controlli di sicurezza più importanti in ambito mobile secondo OWASP ed ENISA



La sicurezza informatica

● Insieme di misure di carattere organizzativo, tecnologico e procedurale mirate a garantire

– CONFIDENZIALITÀ

– INTEGRITÀ

– DISPONIBILITÀ

dell'informazione.



Come funziona

● Definizione di politiche di accesso a servizi e informazioni

– autenticazione

– autorizzazione → chi può fare cosa

● Difesa perimetrale

● Difesa interna

● Formazione degli utenti



Sicurezza informatica offensiva

● Utilizzo di strumenti e metodologie usate dagli attaccanti reali

● Accesso a servizi ed informazioni senza possedere i permessi previsti dalle politiche di sicurezza

– Lettura → Confidenzialità

– Scrittura → Integrità / Disponibilità

● Evidenzia le vulnerabilità di sicurezza



Sicurezza applicativa

● Modellazione ed analisi dei rischi derivanti dal software





● Consapevolezza di analisti, sviluppatori, beta tester, utenti finali

– Sviluppo dell'architettura (secure by design)

– Ciclo di sviluppo del software

– Scrittura del codice

– Controlli di sicurezza comuni nelle fasi di test / review





● Consapevolezza di analisti, sviluppatori, beta tester, utenti finali

– Sviluppo dell'architettura (secure by design)

– Ciclo di sviluppo del software

– Scrittura del codice

– Controlli di sicurezza comuni nelle fasi di test / review

– Utilizzo consapevole da parte degli utenti finali




Il problema non è tecnologico, ma culturale!



Uno sguardo all'architettura mobile

Hardware

Sistema operativo

Librerie / Servizi Applicazione




Hardware

Sistema operativo


Utente




Hardware

Sistema operativo

Librerie / Servizi

ApplicazioneUMTSWi-Fi

Internet

Server Web

Hardware

Sistema operativo


Utente

Lato client Lato server



● Piattaforma

– Hardware

– Sistema operativo

– Librerie e servizi

● Applicazioni native

– Contatti

– Email

Superficie d'attacco nativa (out of the box)



● Applicazioni di terze parti

● Backend esposti su Internet

– Tutto quello che ci sta sotto

● App Market

Superficie d'attacco, altro



● Molte applicazioni mobili fanno uso del web

– Alcune sono a tutti gli effetti applicazioni web

– Altre fanno uso di API basate sul web (ReST)

● Il web non è stato progettato per essere sicuro

● Per progettare applicazioni mobili sicure, bisogna avere ben chiare le problematiche di sicurezza ereditate dal web

Superficie d'attacco ereditata



La metodologia

O W A S P

Open Web Application Security Project



● Associazione senza scopo di lucro

● Missione: aumentare la visibilità relativa la sicurezza del software al fine di permettere di prendere decisioni informate ad imprese ed individui

Open Web Application Security Project



● Si occupa di ricerca e divulgazione della cultura della sicurezza

● Mantiene svariati (e rinomati) progetti legati la sicurezza applicativa

● Includono informazioni circa librerie, API, best practices, auditing, suddivisi nelle tre categorie

– Protect

– Detect

– Life Cycle

Di cosa si occupa OWASP



● Descrive le dieci problematiche di sicurezza in ambiente mobile valutate come più rischiose

● Indirizzato a sviluppatori, designer, manager ed organizzazioni● Indipendente da linguaggio / framework utilizzato

OWASP Top 10 Mobile Risks



● Mobile Security Project

– Top Ten Mobile Risks

– Technical Risks of Reverse Engineering and Unauthorized Code Modification

● Development Guide● Secure Coding Practices – Quick Reference Guide● Code Review Guide

● Risk Rating Methodology● Threat Risk Modeling

Progetti OWASP collegati



M1 Weak Server Side Controls

M2 Insecure Data Storage

M3 Insufficient Transport Layer Protection

M4 Unintended Data Leakage

M5 Poor Authorization and Authentication

M6 Broken Cryptography

M7 Client Side Injection

M8 Security Decisions Via Untrusted Inputs

M9 Improper Session Handling

M10 Lack of Binary Protections

Top 10 Mobile Risks - Final List 2014



● Agenti di minaccia: qualunque entità non fidata utilizzata come input al backend

– Utente

– Malware

– Applicazione vulnerabile

● Il problema è di implementazione del backend

– E' una problematica di sviluppo web

M1: Weak Server Side Controls



● Fare uso di tecniche di sviluppo sicuro lato server

● Top Ten Project

– A1 Injection

– A2 Broken Authentication and Session Management

– A4 Insecure Direct Object References

– A7 Missing Function Level Access Control

– A10 Unvalidated Redirects and Forwards

M1: prevenzione



SQL Injection on Infostrada backend database



● Parametrizzazione insicura di una query SQL1. var_id = _post(id);2. query = “SELECT * FROM tab WHERE id = '” + var_id + “'”;3. result = invia_query_al_database(query);4. fai_qualcosa_con(result);

● Parametri attesi_post(id) = n naturale (o, al più, intero)

● Esempio di parametro inatteso_post(id) = 23'; DROP TABLE tab; --

A1: Injection



● Brute force su password o username – password deboli● Predizione di identificativo di sessione o credenziali di

accesso● Replay – autenticazione al di fuori di un canale crittografato● Session spotting – assegnazione di sessione al di fuori di un

canale crittografato● Session fixation – assegnazione malevola di sessione

precedente-mente avviata● Timeout di sessione troppo lunghi o inesistenti● Password non crittografate o non salate nella base dati

A2: Broken Authentication and Session Management



1. conto = _post['conto'];

2. query = prepara('SELECT * FROM conti WHERE conto = %',

conto);

3. result = invia_al_database(query);

4. fai_qualcosa_con(result);

A4: Insecure Direct Object References



● E' necessario effettuare una mappatura degli oggetti cui l'utente ha diritto di accesso

1. query = prepara('SELECT prendiContiDaSessione(%)', session_id);

2. conti[] = invia_al_database(query);

3. metti_conti_in_dropdown(conti[], dropdown);

… interazione dell'utente …

A4: prevenzione



1. map_conto = prendi_indice_selezionato(dropdown);

2. query = prepara('SELECT verificaPermessi(%,%)',

conti[map_conto], session_id);

3. result = invia_al_database(query);

4. if (result) {

5. tutto_ok_procedi();

6. } else {

7. biasima_utente_e_disconnetti(session_id);

8. }

A4: prevenzione



● Un utente non è in grado di autenticarsi all'applicazione, ma può richiamare direttamente una funzione, ad esempio:

– backend/esegui_qualcosa.php?comando=fai_questo

● Una funzione contiene un parametro che specifica l'azione da eseguire, il livello di autorizzazione non viene verificato:

– dalla chiamata backend/gestisci.cgi?azione=mostra

– alla chiamata backend/gestisci.cgi?azione=modifica

A7: Missing Function Level Access Control



● Contrariamente ad A4 la verifica avviene a livello di funzione

1. function funzione(id_sessione, …) {

2. aut_rich = CO_LIVELLO_AUTORIZZAZIONE_RICHIESTO;

3. if verifica_autorizzazione(id_sessione, aut_rich) {

4. tutto_ok_procedi();

5. } else {

6. disconnetti(id_sessione);

7. }

8. }

A7: prevenzione



● L'applicazione usa una pagina per il redirect che attende in input un parametro contenente l'URL di destinazionebackend/go.cgi?to=www.malware.ru/get_malware.html

● L'applicazione usa forward per ruotare le richieste da una funzione applicativa alla successiva usando un parametro per determinare la destinazione:backend/funzione1.cgi?fwd=funzione2.cgi

● Questo porta alla possibilità di alterazione del normale flusso di controllo

A10: Unvalidated Redirects and Forwards



● Agenti di minaccia: furto o smarrimento del dispositivo, malware, app ripacchettizzata

● Vettori d'attacco: navigazione all'interno del filesystem del dispositivo

● Debolezza: deriva dallo storage insicuro sul dispositivo

– Può essere molto grave: credenziali, token di autenticazione, cookies

– Dati geografici, personali, bancari, ID personale (!), etc

M2: Insecure Data Storage



● Nulla di ciò che non c'è può essere rubato

– Non salvare nulla in locale se non è strettamente necessario

– Non salvare credenziali d'accesso

– Se si salvano token, far scadere le sessioni!

– Utilizzare api di crittografia di sistema standard

– Considerare l'utilizzo di altri livelli di crittografia al di sopra di quelli forniti dal sistema

– Applicare i permessi opportuni sui file utilizzati

– Non utilizzare chiavi hardcoded

M2: Prevenzione



● Agenti di minaccia: informazioni in transito fra dispositivo e backend.

● Vettori d'attacco:

– Rete wifi compromessa o monitorata (MITM)

– dispositivi del fornitore di accesso

– infrastruttura lato server

– malware sul dispositivo

M3: Insufficient Transport Layer Protection



● Debolezza: deriva dalla mancanza di

– mutua autenticazione degli endpoint

– crittografia delle informazioni in transito

– Spesso SSL/TLS viene usato in sola fase di autenticazione e scambio token

– Usare SSL non significa necessariamente usarlo bene

M3: Insufficient Transport Layer Protection



● Mancata verifica del certificato o dell'endpoint

– Certificato corretto e firmato da CA fidata

– Presentato da server malevolo

● Negoziazione di protocollo di cifratura debole

– SSL3 e BEAST attack basato sulla debolezza di degli IV nel caso TLS 1.0 e CRC

● Perdita di informazioni sensibili

– Invio di informazioni sensibili verso altri endpoint attraverso canali non crittografati

M3: scenari d'attacco



● Assumere come non sicure le connessioni di rete● Utilizzare SSL/TLS, quanto meno al trasporto di credenziali e

token di sessione● Utilizzare protocolli di cifratura standard e sicuri, scegliere

chiavi adeguatamente lunghe e complesse● Utilizzare certificati firmati da CA accreditate, ove possibile

preferire il pinning (accordo)● Non disabilitare o ignorare la verifica della catena SSL● Stabilire connessioni sicure solo dopo aver verificato l'identità

del server endpoint

M3: prevenzione



● Avvertire l'utente attraverso l'UI in caso di riscontrato errore nei certificati

● Non inviare informazioni confidenziali attraverso canali alternativi (sms, mms, etc)

● Ove possibile aggiungere un livello di crittografia prima di SSL

– E' possibile intercettare il traffico all'interno del dispositivo prima che venga crittografato in SSL

M3: prevenzione



● Agenti di minaccia: malware, applicazioni ripacchettizzate, accesso fisico al dispositivo

● Vettori d'attacco: API per l'accesso alle zone di memoria condivise, strumenti di analisi forense

● Debolezza:

– Salvataggio involontario (OS, libs, etc) di informazioni sensibili in zone di memoria condivisa

– Deriva dalla mancata consapevolezza di come le informazioni gestite vengono trattate

M4: Unintended Data Leakage



● Per ogni asset strategico è necessario conoscere le modalità di gestione a basso livello di:

– cache, cookie

– buffer di copia/incolla, tastiera

– modalità di background

– log e modalità di debug

● E' importante sapere come queste informazioni vengono processate da sistema operativo, librerie e framework

M4: prevenzione



● Agenti di minaccia: richieste al backend, forzatura di autenticazione locale

● Vettori d'attacco:

– inclusione delle informazioni di autenticazione mediante richieste dirette al backend

– attacco locale all'applicazione (→ M10)

● Debolezza:

– il formato del dispositivo porta all'utilizzo di PIN

– possibilità di utilizzo offline: delegazione all'app delle decisioni in merito all'autorizzazione

M5: Poor Authorization and Authentication



● Attacchi al frontend (modalità offline)

– Rimozione dei controlli di autorizzazione

– Visualizzazione di informazioni scaricate ma non rese disponibili a livello di presentazione

● Attacchi al backend

– Esecuzione di funzioni in modalità anonima (rimuovendo i token di sessione dalle richieste) → A7

– Esecuzione diretta di funzioni non mostrate nella UI, per le quali l'utente non ha i diritti di esecuzione → A7

M5: Scenari d'attacco



● Assumere aggirabili tutti i controlli di autenticazione ed autorizzazione lato client

– Ove possibile devono essere fatti lato server

– Nel caso siano necessari controlli locali, effettuare verifiche di integrità del codice dell'applicazione (→ M10)

● Non permettere di usare PIN come password

– Brute force lato client

– Se rubate bastano “pochi” tentativi per romperle, anche se salvate in maniera sicura

M5: prevenzione



● Agenti di minaccia: qualunque entità possa accedere a dati crittografati in maniera errata

● Vettori d'attacco: decrittografia dei dati tramite accesso fisico al dispositivo, cattura del traffico di rete, malware sul dispositivo

● Debolezza: utilizzo di algoritmi di cifratura deboli o errori nel processo di crittografia

M6: Broken Cryptography



“If you're typing the letters A-E-S into your code,

you're doing it wrong”

Thomas Ptacek

M6: Broken Cryptography



● Affidamento a processi di crittografia implementati localmente

– In genere i sistemi di crittografia implementati localmente possono essere aggirati

– Esempio: protezione locale degli eseguibili di iOS

● Processo di gestione delle chiavi insicuro

– Inclusione delle chiavi con il contenuto (file system)

– Inclusione delle chiavi nel codice (hard-coding)

● Utilizzo di algoritmi insicuri, deprecati o propri(etari)

M6: cosa non fare



● Agenti di minaccia: qualunque entità possa inviare dati all'applicazione, utenti esterni o interni, altre applicazioni, file o l'applicazione stessa

● Vettori d'attacco: attacchi testuali che sfruttano la sintassi di un interprete o iniezione di codice applicativo

● Debolezza:

– l'input malevolo forza un cambio di contesto e viene interpretato come eseguibile, anche con alti privilegi

– iniezione diretta di codice eseguibile all'interno dell'app (→ M10)

M7: Client Side Injection



● SQL Injection su SQLite (→ A1)

– Accesso ai dati dell'applicazione

● JavaScript Injection (XSS → A3)

– Furto di sessioni

● Local File Inclusion

– Accesso a file e contenuto delle directory dell'app

M7: scenari d'attacco all'applicazione



● Attacchi al codice eseguibile (→ M10)

– Modifica del livello di presentazione

– Buffer overflow ed esecuzione di codice arbitrario

M7: scenari d'attacco al codice



● Validare tutti gli input all'applicazione● Parametrizzare le query SQL● Inibire l'esecuzione di JavaScript nei controlli WebView o

preferire l'uso dei browser mobili● Validare l'input ai file manager e disabilitare l'accesso al

filesystem alle WebView● Su iOS avere cura di proteggere C ed Objective-C

– Proteggere le funzioni Objective-C prone ad attacchi di tipo format string

– Non usare funzioni C prone all'iniezione (strcat, strcpy, strncat, strncpy, etc)

M7: prevenzione



● Agenti di minaccia: IPC (Inter Process Communication)● Vettori d'attacco: lettura o modifica dei messaggi IPC utilizzati

per prendere decisioni di sicurezza (→ A10)

● Debolezza: utilizzare informazioni non fidate per prendere decisioni di sicurezza

M8: Security Decisions via Untrusted Inputs



● Non passare informazioni confidenziali attraverso IPC, in quanto in molti scenari possono essere lette (→ !)

● Utilizzare white-list di applicazioni fidate da cui accettare input attraverso IPC

● Per il passaggio di informazioni, utilizzare funzioni che permettano di ottenere il BundleID dell'app chiamante

● Validare tutti gli input ricevuti tramite IPC

M8: prevenzione



● Agenti di minaccia: qualunque entità abbia accesso al traffico http(s), ai cookie, ai token di sessione, etc

● Vettori d'attacco: accesso fisico al dispositivo, cattura del traffico di rete o malware

● Debolezza: esposizione di token di sessione in fase di assegnazione, salvataggio o utilizzo degli stessi (→ A2)

M9: Improper Session Handling



● Chiusura di sessioni lato client (e non lato server)

● Mancanza di timeout di sessione

● Mancanza di rotazione dei token al cambio di livello di autorizzazione

● Creazione insicura dei token di sessione

M9: scenari d'attacco



● Chiudere le sessioni lato server

● Impostare timeout di sessione adeguati in base al livello di autorizzazione

● Ruotare i token ad ogni cambio del livello di autorizzazione

● Creare token in maniera casuale

M9: prevenzione



● Agenti di minaccia: analisi, reverse e modifica dell'applicazione

● Vettori d'attacco: modifica dell'app

– inserimento di funzionalità malevole

– esposizione di dati confidenziali e proprietà intellettuale

– superamento di blocchi (sicurezza, licenza, etc)

● Debolezza: l'applicazione non implementa controlli sulla propria integrità

M10: Lack of Binary Protections



● Decrittografia del codice dell'app o analisi mediante debugger● Visualizzazione delle strutture di controllo (diagramma di

flusso)● Modifica al livello di presentazione (html,js, css) ed

esecuzione di codice JavaScript modificato● Sostituzione di chiavi di crittografia o certificati per decifrare il

traffico generato● Superamento di controlli di sicurezza mediante modifica di

applicazione o spazio di memoria

M10: Lack of Binary Protections



● Implementare controlli di sicurezza per la rilevazione di

– Ambiente jailbroken

– Ambiente di debug

– Modifiche ai checksum

– Modifiche al pinning dei certificati

– Modifiche del codice a runtime

M10: prevenzione



● Ripacchettizzazione di applicazione modificata

– Decrittografia, modifica malevola e fornitura attraverso canali non ufficiali dell'applicazione

● Swizzling dei metodi mediante la fornitura di librerie esterne

– Fornitura di metodi malevoli con medesima firma di quelli richiamati dall'applicazione

● Aggiramento dei controlli di sicurezza mediante la modifica del flusso di controllo

– Autenticazione, autorizzazione e gestione delle sessioni

– Validazione di dati, verifica di firme, gestione licenze

Rischi derivanti dalla modifica del codice



● Aggiramento dei sistemi di verifica di ambienti jailbroken

● Modifica del livello di presentazione

– Modifica dei file che definiscono il livello di presentazione

● Sostituzione di chiavi di crittografia

– Esecuzione di attacchi di tipo MITM (Man In The Middle)

Rischi derivanti dalla modifica del codice



● Possibilità di analisi di logiche applicative o di business mediante

– Esposizione delle firme dei metodi

– Monitoraggio di API, librerie e chiamate di sistema

– Esposizione delle strutture dati (nomi degli attributi)

– Esposizione delle stringhe

– Intercettazione di chiavi di crittografia

– Decompilazione degli algoritmi

– Decrittografia delle applicazioni

Rischi derivanti da reverse ed analisi del codice



● C1 Identify and protect sensitive data on the mobile device● C2 Handle password credentials securely on the device● C3 Ensure sensitive data is protected in transit● C4 Implement user authentication,authorization and

session management correctly● C5 Keep the backend APIs (services) and the platform

(server) secure● C6 Secure data integration with third party services and

applications

Top Ten Mobile Controls



● C7 Pay specific attention to the collection and storage of consent for the collection and use of the user’s data

● C8 Implement controls to prevent unauthorized access to paid-for resources (wallet, SMS, phone calls etc.)

● C9 Ensure secure distribution/provisioning of mobile applications

● C10 Carefully check any runtime interpretation of code for errors

Top Ten Mobile Controls



● Network intelligence – SSL/TLS attacks: Part 1 – BEAST Attack● HP Enterprise Security – HP Fortify Taxonomy – Software Security

Errors● Infosecurity magazine – Two Thirds of Personal Banking Apps

Found Full of Vulnerabilities● Defuse Security – Password Hashing Security: Salted Password

Hashing – Doing it right● Thomas Ptacek – If You're Typing The Letters A-E-S Into Your

Code, You're Doing It Wrong.● OWASP – Format string attack● PenTest Magazine – SSH Tunnels: How to Attack Their Security● ENISA – Smartphone Secure Development Guideline● LifeHacker – How to Crack Just About Any Mac App (and How to

Prevent It)

Qualche riferimento



Seminario sulla sicurezza delle applicazioni mobili

Andrea Zwirner

[email protected]

@AndreaZwirner

Sicurezza informatica

Università degli Studi di VeronaCorso di Laurea Magistrale in Informatica

Seminario sulla sicurezza delle applicazioni...

Documents

Transcript of Seminario sulla sicurezza delle applicazioni...