Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
(UN)SECURITY GUIDELINES
Best practice e linee guida per uno
sviluppo sicuro e responsabile
$whois
Chi siamo
(Un)security
Conclusioni
VoidSec.com
voidsec@voidsec.com
Paolo Stagno
Cyber Security Analist, iDialoghi
L...
(Un)security
“Digital trust is an imperative, mobile app
developers must take greater responsibility
for ensuring that the...
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
DATA
STORAGE
External vs Internal Storage
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
•...
SharedPreferences & SQLite
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
• S...
Esempio: SQLite
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
Su un disposit...
Log
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
• Dati accessibili tramite...
Usare la RAM
• Accesso alla RAM consentito solo con permessi di
root
• Liberare sempre la memoria dalle informazioni
sensi...
Riassunto
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
• Criptare sempre i ...
ACCESSIBILITY
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
Content Provider
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
I ContentProv...
Intents
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
• Mai usare Intent imp...
Intents
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
• Limitare il broadcas...
Validation
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
I dati che vengono ...
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
CRITTOGRAFIA
«Lo XOR non è un buon sistema di crittografia»
Non si ha prova della robustezza del proprio
protocollo
Ci si affida al con...
Quali algoritmi?
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
• Evitare AES...
Random
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
In ambienti legati al m...
Funzioni di derivazione della chiave (KDF)
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento...
Certificate Pinning
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
Per pinnin...
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
API
Backend
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
• Elemento essenziale ...
SQLi
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
SQL Injection inserimento...
XSS
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
XSS esecuzione codice male...
CSRF
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
Cross-site request forger...
CSRF - Esempio
L’utente è autenticato sul sito della sua
banca.
www.example.com/pagamento?
importo=XXXX&destinatario=YYYY
...
User Enumeration
User Enumeration test con lo scopo di
individuare un insieme di utenti di un
determinato servizio
• Compr...
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
OFFUSCAMENTO
Motivazioni
Chi siamo
(Un)security
Data Storage
Accessibility
Crittografia
API
Offuscamento
Conclusioni
Serve a rendere me...
Offuscamento vs Performances
Offuscamento ≠ Minify
Minify
• Riduce il validation e il class loading time
Offuscamento
• Co...
Tipologie
Due tipi di offuscamento
• Prima generazione: rinomina il package, le classi, I
metodi e le variabili, elimina I...
Conclusioni
Chi siamo
(Un)security
Conclusioni
In questo breve talk abbiamo
intravisto alcune delle problematiche
che poss...
Riferimenti
Chi siamo
(Un)security
Conclusioni
Riferimenti
Domande?
• http://developer.android.com/training/articl
es/secu...
Luca Poletti
Crazy Mathematician & Developer
Paolo Stagno
Cyber Security Analist, iDialoghi
Domande?
Chi siamo
(Un)securit...
Upcoming SlideShare
Loading in …5
×

Android (Un)Security Guidelines - VoidSec

216 views

Published on

  • Be the first to comment

  • Be the first to like this

Android (Un)Security Guidelines - VoidSec

  1. 1. (UN)SECURITY GUIDELINES Best practice e linee guida per uno sviluppo sicuro e responsabile
  2. 2. $whois Chi siamo (Un)security Conclusioni VoidSec.com voidsec@voidsec.com Paolo Stagno Cyber Security Analist, iDialoghi Luca Poletti Crazy Mathematician & Developer
  3. 3. (Un)security “Digital trust is an imperative, mobile app developers must take greater responsibility for ensuring that their applications follow the secure programming practices and vulnerability responses developed over the past decade, and by doing so provide the level of protection required for us to trust our digital lives with them.” Vincent Weafer, senior vice president of McAfee Chi siamo (Un)security Conclusioni
  4. 4. Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni DATA STORAGE
  5. 5. External vs Internal Storage Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni • Dati accessibili da chiunque – WRITE_EXTERNAL_STORAGE – READ_EXTERNAL_STORAGE • Memoria accessibile fisicamente • Dati protetti dal sistema Android • Difficile accesso fisico alla memoria • Accessibile con permessi di root • Differenti modalità operative – MODE_PRIVATE – MODE_WORLD_READABLE – MODE_WORLD_WRITABLE
  6. 6. SharedPreferences & SQLite Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni • Salvati nell’Internal Storage • Differenti modalità operative – MODE_PRIVATE – MODE_WORLD_READABLE – MODE_WORLD_WRITABLE • Salvati nell’Internal Storage • Non accessibile da altre applicazioni • Accessibile tramite ADB > sqlite3 con i permessi di root o applicazioni debuggable
  7. 7. Esempio: SQLite Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni Su un dispositivo con root è possibile accedere ai database delle applicazioni. /data/data/com.yahoo.mobile.client.android.im/ databases/messenger.db L’app di messaggistica e di posta salvavano in chiaro i dati degli utenti • Conversazioni • Password YAHOO! MESSENGER
  8. 8. Log Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni • Dati accessibili tramite logcat • In Android < 4.0 qualsiasi app può leggere i log di qualsiasi altra app – android.permission.READ_LOGS • Non usare i log per tener traccia di informazioni sensibili
  9. 9. Usare la RAM • Accesso alla RAM consentito solo con permessi di root • Liberare sempre la memoria dalle informazioni sensibili • Non usare mai elementi immutabili per informazioni sensibili – char[] può essere sovrascitto dall’utente – String è immutabile, da evitarsi Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni
  10. 10. Riassunto Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni • Criptare sempre i file sensibili • Potenzialmente tutti i dati scritti possono essere letti, anche se eliminati • Mai salvare su disco dati quali chiavi crittografiche o altri dati estremamente sensibili • I dati sensibili in RAM non devono essere immutabili • Mai rilasciare app con flag android:debuggable="true"
  11. 11. ACCESSIBILITY Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni
  12. 12. Content Provider Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni I ContentProvider permettono la condivisione di dati tra le applicazioni, bisogna essere cauti per evitare accessi non autorizzati ai dati • Limitare gli accessi tramite attributo – android:exported="true" – android:exported="false" • Definire appropriate permission e protectionLevel – android:protectionLevel="signature"
  13. 13. Intents Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni • Mai usare Intent impliciti e broadcast pubblici per dati riservati o operazioni critiche – Intercettazioni e denial of service • Usare Intent espliciti definendo il component name – setComponent(), setClass(), setClassName(), Intent([…], Class)
  14. 14. Intents Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni • Limitare il broadcast a singole applicazioni – Intent.setPackage(), LocalBroadcastManager • Mai usare Intent impliciti con i PendingIntent – I PendingIntent hanno gli stessi privilegi della applicazione che li ha inviati
  15. 15. Validation Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni I dati che vengono ricevuti da terze parti devono sempre essere controllati e resi in forma canonica. • URL ricevuti da content provider possono causare vulnerabilità di directory trasversal • I dati presenti sulla SD possono essere alterati da chiunque • I Broadcast Receiver devono verificare l’identità dell’autore dell’Intent
  16. 16. Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni CRITTOGRAFIA
  17. 17. «Lo XOR non è un buon sistema di crittografia» Non si ha prova della robustezza del proprio protocollo Ci si affida al concetto di security through obscurity Il reverse engineering porta alla conoscenza della logica utilizzata Si possono trovare vulnerabilità che invalidano completamente tutta la segretezza o presunta tale Homemade Security Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni
  18. 18. Quali algoritmi? Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni • Evitare AES-ECB • IV generati casualmente • Non usare chiavi crittografiche hard-coded • Nel SecureRandom()non usare seed hard-coded AES-ECB
  19. 19. Random Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni In ambienti legati al mondo della sicurezza, usare la classe SecureRandom • Evitare di usare il costruttore SecureRandom(byte[] seed) • Evitare seed statici • Porre particolare attenzione alle versioni Android obsolete (API < 18)
  20. 20. Funzioni di derivazione della chiave (KDF) Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni Si può derivare una chiave crittografica a partire da un PIN o da una password • PKDF2, scrypt , bcrypt • Usare almeno salt a 128 bit • Usare più di 1000 iterazioni (16000 per scrypt) • Usare delle policy per le password severe
  21. 21. Certificate Pinning Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni Per pinning si intende il processo di associare ad un host il suo certificato o la sua chiave pubblica. • Controllare sempre l’identità dell’interlocutore tramite il certificato hard- coded • Le informazioni di interesse sono – Certificati – Chiavi pubbliche – Hash dei precedenti
  22. 22. Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni API
  23. 23. Backend Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni • Elemento essenziale delle applicazioni Android è una logica lato server • Mai fidarsi mai degli input dell’utente • Vulnerabilità analoghe allo sviluppo WEB
  24. 24. SQLi Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni SQL Injection inserimento di codice malevolo all'interno di una query SELECT * FROM users WHERE user=‘.$_POST['user'].’ AND pwd=‘.$_POST['pwd']’ SELECT * FROM users WHERE user=‘utente‘ AND pwd=‘’or 1=1-- • Exploiting: recupero db, tabelle, colonne, dati • Prevenzione: usare le PreparedStatement SQLiteDatabase db = dbHelper.getWritableDatabase(); SQLiteStatement stmt = db.compileStatement("SELECT * FROM Country WHERE code = ?"); stmt.bindString(1, "US"); stmt.execute();
  25. 25. XSS Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni XSS esecuzione codice malevolo lato client • raccolta e manipolazione di informazioni (cookie) • visualizzazione e modifica di dati presenti sui server • alterazione del comportamento dinamico delle pagine web Due tipologie • stored • reflected effettuate dallo stesso client che subisce l'attacco
  26. 26. CSRF Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni Cross-site request forgery (CSRF) non viene verificata l’intenzionalità della richiesta • XSS sfruttano la fiducia di un utente in un sito • CSRF sfruttano la fiducia di un sito nel browser di un utente
  27. 27. CSRF - Esempio L’utente è autenticato sul sito della sua banca. www.example.com/pagamento? importo=XXXX&destinatario=YYYY L‘attaccante invia all’utente un tag img html <IMG src="www.example.com/pagamento? importo=2000&destinatario=Attaccante"> Quando l’utente tenterà di accedere all'immagine, il browser invierà di fatto una richiesta HTTP alla pagina web della banca; Il sito rileverà, tramite il cookie, che la richiesta arriva effettivamente dall’utente e autorizzerà l'operazione. Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni
  28. 28. User Enumeration User Enumeration test con lo scopo di individuare un insieme di utenti di un determinato servizio • Compromissione di credenziali • Recupero di informazioni non pubbliche Esempio: • http://trade.aliexpress.com/mailingaddress/mailingAd dress.htm?mailingAddressId=123456 • mailingAddressId è l’id dell’account utente • Gli id sono stati assegnati in maniera incrementale e prevedibile Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni
  29. 29. Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni OFFUSCAMENTO
  30. 30. Motivazioni Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni Serve a rendere meno comprensibile ad un lettore umano il codice sorgente • Proteggere la proprietà intellettuale dal riutilizzo non autorizzato del proprio codice • Rendere difficile il reverse engineering • Rendere più difficile la modifica malevola • Evitare azioni di violazione della licenza d'uso, come la creazione di crack
  31. 31. Offuscamento vs Performances Offuscamento ≠ Minify Minify • Riduce il validation e il class loading time Offuscamento • Comunemente l’offuscamento porta ad un degrado delle performance • Genericamente si ha una perdita trascurabile • Opera a livello di bytecode acct.setBalance(newBalance) if(x=0)a.s(b); else{ //do something else } Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni
  32. 32. Tipologie Due tipi di offuscamento • Prima generazione: rinomina il package, le classi, I metodi e le variabili, elimina I commenti e le informazioni di debug. • Seconda generazione: cambia il flusso di controllo, introduce cicli, condizioni e salti condizionati Chi siamo (Un)security Data Storage Accessibility Crittografia API Offuscamento Conclusioni
  33. 33. Conclusioni Chi siamo (Un)security Conclusioni In questo breve talk abbiamo intravisto alcune delle problematiche che possono verificarsi in ambito Android. • Crittografate sempre i dati sensibili • Validate sempre gli input • Non rilasciate app debuggabili • Controllate i certificati • Mettete in sicurezza il backend • Offuscate
  34. 34. Riferimenti Chi siamo (Un)security Conclusioni Riferimenti Domande? • http://developer.android.com/training/articl es/security-tips.html • https://www.securecoding.cert.org/confluence /pages/viewpage.action?pageId=111509535 • https://www.nowsecure.com/resources/secure- mobile-development/ • http://www.jssec.org/dl/android_securecoding _en.pdf • http://android- developers.blogspot.it/2013/08/some- securerandom-thoughts.html • http://thehackernews.com/2014/12/aliexpress- website-vulnerability_7.html • http://securityaffairs.co/wordpress/34084/ma lware/mcafee-labs-threat-report-201402.html • http://voidsec.com/yahoo-messenger/
  35. 35. Luca Poletti Crazy Mathematician & Developer Paolo Stagno Cyber Security Analist, iDialoghi Domande? Chi siamo (Un)security Conclusioni Riferimenti Domande? “Some things in life are unpredictable, your App doesn’t have to be one of them” VoidSec.com voidsec@voidsec.com

×