(musica leggera per pianoforte)
(applausi)
Grazie per il caloroso benvenuto,
e grazie a voi ragazzi per essere venuti oggi.
So che ci sono parecchi discorsi decenti al momento
e la sicurezza di Android può essere un po ‘di nicchia.
Ho provato a
usa quell’analogia della giungla
per parlare dell ‘”ecosistema Android”:
alcune delle minacce e dei rischi.
(questa è l’idea dietro al discorso).
L’ho diviso in due parti,
per consentire il fatto
che questa è una conferenza per
tutti gli sviluppatori e le persone tecniche.
Il primo semestre è per tutti.
Speriamo di poter parlare dell’ecosistema
e dissipare alcuni miti.
La seconda metà, ci accingiamo a entrare
consigli di sopravvivenza completi da rafforzare
la sicurezza delle tue app.
(Potresti notare alcuni riferimenti
in un certo film della giungla per tutta la presentazione.
ci sono premi alla fine se riesci a indovinare quale è).
Prima di iniziare, permettimi di presentarmi
un po ‘più in dettaglio.
Sono uno sviluppatore principale di Android presso una piccola azienda di app
con sede a Bath (Regno Unito).
Lavoro a distanza da Bristol
(che, dopo aver parlato con alcune persone ieri,
nessuno sapeva davvero dove fosse,
e quindi è a circa 100 miglia a ovest di Londra,
ed è la casa di Banksy.
E quelle due cose che la gente sembra avere dove si trova.)
In Intohand creo app
per le industrie
(app meteo, vendita al dettaglio, video on demand e roba del genere).
E il mio pezzo preferito, o il po ‘mi eccita
ed entusiasta è la parte di sicurezza:
rendendoli più difficili da hackerare.
Questo interesse mi ha portato a essere coautore
il ricettario di sicurezza Android.
Ho scritto circa un terzo di quel libro
(capitoli difensivi e di protezione).
Alcune delle cose che copriamo un po ‘nella seconda metà.
(breve nelle diapositive, ovviamente,
ma ci sono più esempi di codice
nel libro).
L’ultima cosa
è che ho co-fondato SWmobile,
che è un gruppo di meetup per sviluppatori mobili
con sede nel sud-ovest dell’Inghilterra
(circa 600 membri,
e facciamo regolari colloqui e hackathon tecnici).
(Sono un lavoratore a distanza, ma
Mi piace stare in contatto con altri sviluppatori,
e condividendo storie di guerra e cose,
quindi per favore vieni a dire “Ciao” dopo il discorso).
vuoi ambientare la scena con Android.
All’inizio della scorsa settimana, Sundar ha annunciato
che ora abbiamo 1,4 miliardi
utenti attivi di Android
(30 giorni attivi
dispositivi con servizi Google installati,
questo non include nemmeno tutti quelli
Compresse cinesi).
(Numero enorme).
Di gran lunga la più grande piattaforma mobile.
(Questa grafica funky sta cercando di illustrare
è che è una piattaforma diversa).
C’è oltre un milione di righe di codice
nel progetto open source Android.
Migliaia di dispositivi diversi
(che questo grafico sta cercando di illustrare
da opensignals.com
relazione annuale sulla frammentazione).
Centinaia di OEM.
In teoria, ci sono occhi sul codice.
Questo dovrebbe creare fiducia,
ma non c’è
un singolo punto di errore;
non ci affidiamo a una singola azienda o entità
che contiene tutte le chiavi.
E il punto di queste diapositive di coppia era solo per dire:
non esiste un “modo in cui è” su Android.
Dovresti essere scettico
di qualsiasi venditore di sicurezza o società
quello dice che hanno una maniglia su esso.
A differenza di iOS, dove abbiamo
aggiornare i dispositivi in questo ambiente diversificato
tramite aggiornamenti via etere,
quando abbiamo diversi OEM
e diverse modifiche del vettore,
gli aggiornamenti via etere semplicemente non funzionano.
In che modo Google contribuisce alla sicurezza in questi casi?
Hanno messo i servizi di sicurezza.
Ho appena scelto un paio che pensavo fossero rilevanti.
Il primo è (quello probabilmente la maggior parte di voi
sentito parlare): Google Play Store.
C’è stato un umano coinvolto
nel processo di approvazione dall’inizio del 2015.
Quando ti registri per gli account,
ci sono controlli sullo sfondo
di cui non si conosce
Ma Google ha sfruttato le loro altre app
(es. Gmail),
e tutti i loro punti di dati per aiutare con quello
controllo di validazione in background.
Hanno anche iniziato
le notifiche di sicurezza sviluppatore.
Durante la scansione delle app
e facendo il loro test per vedere se
non è malware,
se rilevano le cose
lo sviluppatore ha accidentalmente incluso
le loro chiavi private nell’app,
se stanno usando una versione vulnerabile
di SSL aperto che hanno incluso,
e hanno anche, ci sono alcuni problemi
attorno a particolari versioni di PhoneGap, Cordova.
Quello che hanno iniziato a fare è stato avvisare gli sviluppatori,
dicendo “Sai che hai le tue chiavi private
nella tua app, dovresti aggiornarlo. “
Pensano che ci siano circa 60.000 app
sono stati aggiornati in merito a quelle notifiche
(buon sistema).
Piccola goccia nell’oceano rispetto al numero di app,
ma è un passo nella giusta direzione.
L’altra cosa che sta dietro la scena
su Google Play Store è il servizio Android Bouncer,
che è stato annunciato o annunciato pubblicamente,
diversi anni fa, e questo va e viene
tutte le app in emulare gli ambienti.
Controlla le firme del malware e roba ingannevole,
e poi li rimuove dall’app store,
li sospende e, se giustificato,
può cancellarli da remoto dai dispositivi.
L’altro
è il gestore dispositivi Android,
un servizio gratuito
(chiunque abbia un dispositivo Android può installare:
aiutarti a trovare, bloccare,
e, se necessario, pulire il dispositivo).
(Se hai un dispositivo Android
e non l’ho installato,
Consiglierei sicuramente di metterlo su).
Qualcosa che Google ha annunciato di recente
è il sistema di sicurezza:
un sistema di rilevamento delle intrusioni.
È possibile raccogliere qualsiasi dispositivo con servizi Google
diversi punti di dati e carica quello
ai servizi di Google e eseguono analisi dei dati.
Cercano e cercano potenziali malware.
Nella seconda parte della presentazione,
Parlerò dell’API pubblica per la rete di sicurezza
(puoi sfruttare le tue app,
per sfruttare parte di quella conoscenza,
che è abbastanza buono).
Infine, menzione
Android at Work, che è un modo di segregazione
i tuoi dati personali e aziendali e le applicazioni
sullo stesso dispositivo.
Decisamente orientato verso
un approccio BYOD,
ma fornisce agli amministratori di sistema
Accesso API per provisioning,
gestione dei profili.
Puoi
rimuovi il tuo accesso
e basta cancellare i dati aziendali e le app
non le tue foto e cose personali
(Penso che sia bello).
La prossima slide parla dei diversi livelli
(Ho rubato questo dal discorso di Adrian Ludwig
da Black Hat, perché pensavo che fosse abbastanza buono
a mostrare i diversi strati).
Se vai da sinistra a destra
questo è il numero maggiore di servizi basati su cloud,
agli strati all’interno
il dispositivo.
Volevo solo attirare l’attenzione
la sezione delle app verificate.
È entrato in Android in 4.2,
un modo per Google di monitorare le app
e rilevare potenziali malware quando gli utenti stavano installando
applicazioni non da Google Play Store.
Chiunque abbia un dispositivo Android
che l’ha installato, vedrà il consenso “Verifica app”;
poi,
quando è un potenziale malware,
riceverai un avvertimento,
In effetti, se è così pericoloso
potresti essere bloccato dall’installazione.
(bel controllo, a proposito
che Google sta cercando di aumentare la tua sicurezza
anche se non stai utilizzando Google Play Store).
L’altra cosa che vale la pena tenere a mente,
è Android
aggiornando il suo più recente. Le versioni più recenti
avere più funzioni di sicurezza e un più forte,
Ho pensato di dirlo
se stai cercando un
una politica BYOD,
versioni più recenti di Android
sarebbe una buona politica
Per alcune app,
se hai bisogno di determinati requisiti di sicurezza,
targeting cinque e sopra
sarebbe una buona chiamata.
Questo è l’ecosistema.
Voglio parlare di alcune delle minacce ora.
Malware di
e sicurezza Android
ialways ottiene,
i media tech adorano mettersi in contatto.
Sono sicuro che tutti voi avete visto quei titoli clickbait
questo riguarda il modo in cui Android è stato aperto.
Mentre impari di più a riguardo,
puoi vedere, è un sacco di hype.
Ma c’è stato di più
malware divulgato pubblicamente su Android
che su iOS.
Tendono ad essere in giro, in gran parte,
intorno agli SMS premium.
Sebbene, in Android 4.2, abbiamo ricevuto questo nuovo avviso;
se scrivi un breve codice ottieni
una schermata di conferma dell’utente che viene visualizzata.
Ciò ha attenuato alcuni malware.
A parte questo, tende ad esserlo
ladri di informazioni,
e, di recente
ransomware.
L’ultima cosa che volevo dire sul malware:
regioni in cui ti trovi nel mondo
gioca un ruolo enorme.
Russia, Cina e Persia,
l’istanza media di malware
è superiore a Europa e America.
Qualcosa che,
per quanto Google ha annunciato, stanno esaminando
(Qualcosa da tenere a mente
quando ascolti queste storie di malware).
Una delle altre minacce che abbiamo
è il dirottamento di app
(noto anche come app “trojanizing”).
Prendi una vera app,
decompilalo
e mettere malizioso
Ovviamente,
potrebbe potenzialmente danneggiare il tuo marchio (se questa è la tua app),
e influenzano i tuoi utenti.
Dovresti ingannare gli utenti per installarlo,
da e-mail di phishing, ecc.
Le preoccupazioni su questo è perché
invertire le app per Android è abbastanza semplice.
(c’è un discorso questo pomeriggio che riguarda parte di questo,
Non ho intenzione di entrare troppo nei dettagli ora).
Su Android non abbiamo, un’autorità di certificazione
quando firmiamo app
(ogni app deve essere firmata
per essere installato su un dispositivo,
ma non c’è un’autorità centrale intorno a questo,
quindi ci saranno tutti i certificati autofirmati).
L’altra preoccupazione è quella delle app che caricano il sideload
(installazione di app
che non provengono dal negozio di giochi approvato),
è molto semplice (è solo un’opzione
che si spegne sul dispositivo).
Tre cose
che rendono il dirottamento delle app più di un problema
che n iOS (più difficile
per sideload app).
Parleremo nella seconda parte di alcune delle difese che puoi mettere
nella tua app per proteggersi dal dirottamento delle app.
Ci sono stati un paio di grandi storie.
(Probabilmente potrei fare una presentazione
solo su tutti gli incidenti di sicurezza negli ultimi 18 mesi
dentro e intorno a Internet e Android).
(Anche se, Heartbleed, di cui sto parlando qui,
ha colpito solo una versione di Android).
(Era ancora interessato).
Chiunque abbia incluso quella versione,
aveva a che fare con una vulnerabilità SSL aperta.
Parte degli assegni dello sviluppatore
che il Play Store fa ora (la scansione dell’app)
è legato a questa minaccia.
Recentemente (come probabilmente avete indovinato),
se vieni su
con un exploit Android,
devi trovare un nome interessante
e un bel logo. (tutti stanno facendo un ottimo lavoro,
che è bello vedere).
Stagefright era un altro
che ha interessato quasi tutti i dispositivi Android
fuori nel mercato.
Era un exploit diffuso, potenzialmente,
e potrebbe denial-of-service attaccare quel dispositivo
(non ci sono state minacce
o attacchi ancora).
(Ho pensato di menzionarlo, A, perché è recente).
b) sono accadute alcune cose veramente positive).
I dispositivi Nexus ora hanno un aggiornamento di sicurezza mensile
e bollettino sulla sicurezza
(i problemi di sicurezza sono stati risolti).
Anche Samsung e LG si sono impegnati
per frequenti programmi di patch di sicurezza.
Alla luce di questi,
questa grande ricerca,
(e questo nome funky
che ha attirato l’attenzione di tutti i media),
costretto alcuni degli OEM
per aumentare i loro aggiornamenti di sicurezza.
(grande cosa).
(Questo è un paio delle minacce).
Parliamo di alcuni dei rischi per le nostre applicazioni
(quando li stiamo creando).
(Nessuna presentazione può essere completa
senza una Top 10).
Citerò il
i primi 10 rischi
che ci sono le nostre app.
Questo è stato compilato dal progetto OWASP
(alcuni di voi forse conoscono il
Apri il progetto di sicurezza delle applicazioni Web dal mondo web).
È un’organizzazione senza fini di lucro
focalizzato sul miglioramento della sicurezza nel software.
E un paio di anni fa, hanno prodotto
i primi 10 rischi mobili
(Dovrebbero aggiornarlo molto presto)
Quando stiamo parlando
consigli di sopravvivenza
proveremo e relazioneremo
ad alcuni di questi
(Li ho appena messi qui per riferimento.
è troppo da accettare, su una diapositiva).
Se vai al sito OWASP
(il sito del progetto Mobile Security),
ognuno di questi è suddiviso in
vettori di attacco e codice di esempio
di come mitigarli
(sicuramente vale la pena verificarlo).
(una delle cose
dovresti guardare quando lo fai
il tuo sviluppo e test).
Se riesci a spuntare questi 10 rischi,
allora sei sulla buona strada per rendere la tua app più sicura.
(seconda parte)
(rapido spettacolo di mani:
chi è uno sviluppatore Android nel pubblico?
Brillante, è fantastico
è molto più di quanto mi aspettassi.
Fantastico – adorerai questa roba).
(Anche se non sei uno sviluppatore Android,
molto di questo si applica ancora a iOS
quando parlo
mobile thick client in modo efficace).
Diamo un’occhiata a come possiamo (sopravvivere
in questa giungla) migliorare la sicurezza delle nostre app.
(Stavo per concentrarmi su queste quattro aree;
ogni area ha diverse cose).
B Desideriamo rafforzare la comunicazione di rete
tra l’app e il nostro servizio.
Vogliamo proteggere tutti i dati che abbiamo archiviato.
Stiamo per: utilizzare
crittografia per quello;
guarda come convalidare
(dove è in esecuzione l’app), l’integrità del dispositivo e dell’app.
Quindi, guarda come possiamo
aumentare la sicurezza binaria.
(queste
si applica anche a iOS).
Ho pensato di iniziare
rafforzare le comunicazioni di rete,
perché ogni app che ho scritto
ha qualche componente online.
(È quasi scontato, ma)
Utilizzo di SSL e TLS per tutte le comunicazioni di rete
dovrebbe essere un valore predefinito
In iOS 9,
l’hanno reso obbligatorio
(devi rinunciare).
(Spero che la prossima versione di Android
viene fornito con qualcosa di simile).
Il secondo punto: utilizzare la piattaforma
Validazione SSL / TLS e non disabilitarla.
(sembra una cosa stupida da dire;
ma se tu Google
o vai a Stack Overflow come abilitare l’uso
certificati SSL autofirmati,
vedrai la risposta più votata
su Stack Overflow con tonnellate di rep
ti spiega come disabilitare la convalida SSL,
rendendo totalmente inutile il concetto di SSL.)
Esistono diversi modi per farlo.
Puoi usare una forma di pinning (di cui parlerò successivamente),
o acquista certificati originali
per il tuo servizio di sviluppo
(questo è quello che ho fatto in passato;
ti risparmia di dover mettere tutto questo codice dubbia
nella tua base di codice
che in pratica disabilita la convalida).
L’altra cosa che potresti fare
è utilizzare solo le suite di crittografia più potenti,
e le versioni TLS più forti.
(Questo è particolarmente importante o utile.)
Se controlli il servizio, puoi controllarlo
il tipo di connessione,
la forza della crittografia
tra le tue app e il server.
SSL predefinito per versioni inferiori,
per supportare i browser più vecchi.
Ma non devi farlo nella tua app. Puoi
far rispettare ciò, e
se qualcuno sta usando OKHttp,
2.1, visto
fantastici aggiornamenti e funzionalità di sicurezza.
Se stai usando 2.1, c’è un buon articolo
su come è possibile far rispettare le specifiche di connessione
(essere più forte
e rilasciare le specifiche inferiori).
Se stai usando direttamente dall’SDK,
HttpsURLConnection,
potresti ancora farlo con.
(Se qualcuno vuole dei campioni di codice,
dammi solo un urlo).
È una linea su OKHttp.
L’altra cosa che potresti vedere
con le tue connessioni è: pinning SSL.
(Se solo potessi avere una dimostrazione di mani,
chi ha già sentito parlare di SSL prima?
Brillante, quindi molte persone).
(Per coloro che non ne hanno sentito parlare)
È solo un modo per ridurre
la quantità di autorità di certificazione
di cui ti fidi
Stai vincolando in modo efficace il tuo certificato SSL
per assicurarsi che sia quello.
Esistono due diversi tipi di pinning.
1) pin l’intero certificato,
o 2) pin la chiave pubblica di quel certificato.
Raccomando sempre di inserire la chiave pubblica.
È un piccolo passo in più per ottenere il pin …
ma non devi cambiare la tua app
o forzare un aggiornamento dell’app
ogni volta che rinnovi il tuo certificato.
(Ho messo un link al libro, lì,
c’è un esempio di codice su come farlo).
(C’è un codice open source online
di Moxie Marlinspike,
ma non ha una grande licenza commerciale).
(Controlla le cose nel libro.)
In sostanza,
quando si effettua una connessione, si esegue una verifica
per assicurarsi che sia il certificato SSL che dovrebbe essere.
(questo è il fondamento del pinning).
L’altra cosa dovresti probabilmente guardare
è il networking (il
parte dei servizi di Google Play,
loro hanno introdotto questo
fornitore di sicurezza dinamico).
Questa è un’altra di quelle cose
perché, non possiamo garantire aggiornamenti via etere,
non possiamo garantire che gli utenti
stanno andando ad aggiornare i loro telefoni,
Google ha messo in atto,
e il ciclo di aggiornamento dei servizi di Google Play
dura da sei a otto settimane.
In quel periodo di tempo,
c’è una possibilità di ottenere,
se c’è una vulnerabilità che viene fuori,
o un exploit, c’è una possibilità che quella soluzione
viene fornito in bundle all’interno dei servizi di riproduzione.
(Ho messo un link all’articolo di formazione lì.
Ha tutto ciò che devi sapere su come chiamarlo
e quando chiamarlo;
l’esempio del codice è così semplice.)
Puoi usare quello:
il fornitore risolverà eventuali problemi nel sistema che ha
con una qualsiasi delle librerie OpenSSL.
Perché è un aggiornamento
del provider di crittologia, puoi usarlo
per
anche crittografia automatica standard.
Puoi usarlo al posto di Bouncy Castle.
(questo è per le cose in rete.)
Successivo: dati.
Quando dico immagazzinare dati,
Intendo criptare i tuoi dati.
Qualcosa che mi ha frustrato come sviluppatore di app,
quando ho avuto rapporti sulle pen test sulle app che ho creato,
o parlato con persone della sicurezza, analisti,
hanno sempre detto “non archiviare dati”.
Voglio fare la mia app
il più performativo possibile,
Voglio farlo funzionare offline,
o in scomode connessioni mobili.
(Il “non memorizzare dati”
usato per insinuarmi.)
Se lo stai immagazzinando,
deve essere crittografato.
E, ovviamente, questo dipende
sul tipo di dati e
applicazione che hai
(cartelle cliniche, codici di lancio nucleari,
probabilmente non dovrebbe essere memorizzato nella cache;
altri dati dovrebbero essere).
(Ecco un codice,
solo per mostrare quanto sia facile.)
Questo è un approccio di best practice,
quando si esegue la crittografia:
usa la crittografia basata su password.
(non farlo
memorizzare la chiave ovunque).
La cosa principale della crittografia
è dove archiviare le chiavi.
Raramente è l’algoritmo che è rotto,
è il fatto che qualcuno trovi dove sono le chiavi.
Questo mostra come usare
crittografia basata su password: utilizzo
l’utente inserisce e quindi usa quello
derivare una chiave di crittografia. In questo caso,
derivare una chiave di crittografia simmetrica
(la chiave che usiamo per la crittografia e la decrittografia).
(Ho messo questo per riferimento.
c’è un esempio migliore nel libro.)
Tu non
persistere la chiave ovunque,
non si blocca la chiave da nessuna parte,
e poi costruisci in un timeout dell’app
(a seconda della tua app,
forse quando l’app va in secondo piano,
forse quando l’utente si disconnette,
ma si cancellerebbe quella chiave dalla memoria).
(è così che rimane al sicuro).
In questo esempio di codice stiamo usando circa 10.000 iterazioni,
(bello e forte, ma basta un po ‘di tempo,
forse quattro secondi
su un Nexus 5).
Puoi sintonizzarti, a seconda di
quanto vuoi che sia sicuro.
Un paio di librerie
può rendere le tue attività di crittografia molto più semplici
(commercialmente fattibile).
(Altrimenti, non c’è motivo di menzionarli, per essere sinceri.)
(Le diapositive che sono caricate hanno collegamenti
e roba a tutti questi).
Conceal è di Facebook:
fantastico per i file.
Lo usano per crittografare le foto
che hanno memorizzato nella cache sulla scheda SD.
Facile da usare,
per impostazione predefinita tutti gli algoritmi più potenti.
Usa AES-GCM (il preferito
Algoritmo AES).
(Consiglio vivamente di provarlo.)
(È predefinito per le cose forti,
perché la roba, se è un hangup
dai giorni Java, sai, dal passato di Android,
essendo basato su Java,
ma l’impostazione predefinita, quando si ha a che fare con la crittografia,
non è predefinito per il forte,
l’algoritmo più forte.)
(Un vero peccato,
perché vuoi solo iniziare a usarlo
ed è il più forte possibile,
ma questo è il bello di Conceal.)
QLCipher, se qualcuno di voi ha
un database SQLLite nella tua app,
che utilizzi per l’archiviazione dei dati,
puoi facilmente scambiare in SQLCipher.
Le API sono tutte esattamente uguali,
a parte quando apri un database
e quando crei un database,
devi passare una password,
e usa quella crittografia basata su password
(che ho parlato di un paio di diapositive fa),
generare, creare una chiave e crittografare i file del database.
La chiave su queste librerie
sono molto facili da usare,
facile da scambiare dentro e fuori
(questo è ciò che ottiene grandi segni di spunta nei miei libri).
SQLCipher utilizza AES a 256 bit in modalità CBC
(è abbastanza decente).
Tuttavia CQLCipher
aggiunge tra quattro e sette MB
alla tua dimensione APK (per alcune persone, è troppo).
La buona notizia è che Google si è appena alzato
il limite di dimensioni APK nel Play Store a 100 MB;
speriamo che dia meno
meno scuse per non usarlo.
Infine: Secure-Preferences,
una delle mie librerie open-source.
Puoi anche guardare Hawk (molto meglio chiamato
e implementazione molto più popolare).
(saltare i riferimenti per coloro che non sono familiari).
È un archivio di valori chiave supportato da un file XML:
modo semplice di assicurare
o offuscando quei file
(persone su dispositivi rooted
non posso scherzare con le tue cose).
Con Secure-Preferences, puoi usarlo con la password,
e fa quella crittografia basata su password.
(bello e sicuro).
Se non si utilizza una password, ne verrà generata una,
e conservalo lì
(se estrai il file, non puoi dire quale sia la chiave).
Ma
è ancora offuscato, perché
lo potresti trovare con abbastanza sforzo.
Solo piccoli passi
per rendere le tue app più difficili da hackerare.
Soprattutto:
evitare di codificare la chiave di crittografia.
Reverse engineering e ricerca di una costante,
una costante di stringa per la chiave di crittografia
è banalmente facile.
Ma
non tutte le app possono utilizzare la crittografia basata su password,
un passcode dell’app (o qualcosa di simile).
Se necessario, generare una chiave
in modo dinamico per installazione, non hardcode.
(è l’equivalente di chiudere la porta principale
ma lasciando le tue chiavi lì dentro
La porta è chiusa, ma non hai alcuna sicurezza,
quindi spero che vi ricordiate quei due).
Continuiamo a verificare l’integrità dell’app.
Ci sono un paio di cose che puoi fare.
Puoi controllare
se
queste sono tecniche di rilevamento di manomissioni.
La tua app è stata dirottata ?,
Funziona in uno stato diverso?
Puoi parlare con PackageManager,
e vedere se ci si trova in uno stato di debugging,
(non dovrebbe accadere
una volta che sei in produzione).
Puoi calcolare un checksum in apk
per vedere se è stato modificato.
O puoi
firmare una verifica del certificato.
Questo è il mio preferito, perché ognuno di noi
l’app deve essere firmata
con la chiave di uno sviluppatore
(quando lo pubblichiamo o lo distribuiamo).
Quella chiave rimane la stessa attraverso il
durata dell’app. Uno dei capisaldi
della sicurezza di Android è questo,
le firme devono corrispondere. Non posso prendere
L’app di Facebook, decompila –
romperebbe la firma, la rassegnasse,
e poi distribuirlo, e tu installi
La versione di Scott di Facebook. Non funziona in quel modo.
Le firme non corrisponderebbero
non ti permetterebbe di aggiornare.
La tua firma rimane la stessa
per tutta la durata della tua app.
Lo sai che in tempo di costruzione,
puoi controllare questo runtime.
(E questo è rapidamente come lo fai.)
Dovresti usare keytool (Java),
per elencare il tuo keystore
firma.
Quindi l’hai appena incorporato nell’app.
In fase di esecuzione, chiederei
il PackageManager per la tua firma.
Hash la firma (per assicurarne una,
per abbinare ciò che hai incorporato),
e quindi confrontare le stringhe.
(E questo è un modo semplice e veloce
di scoprire se la tua app è stata,
è stato decompilato e quindi modificato.)
Tuttavia, se qualcuno può decompilare il codice,
possono prendere questo controllo.
(copriremo tra un paio di diapositive
come possiamo offuscare il nostro codice,
rendere questo più difficile da fare.)
Puoi dire che per qualsiasi cosa inseriamo nell’app,
il pinning SSL, la crittografia,
qualcuno può decompilare, prendere pezzi e guardarlo.
Ma sta usando tutti questi metodi
in combinazione tra loro per rafforzare l’app.
Se vogliamo verificare l’integrità del dispositivo,
ci sono varie cose che puoi controllare.
Nelle proprietà della bolletta, solo per vedere se si tratta di un emulatore,
ci sono un paio di buone risposte su Stack Overflow.
Tim Strazzere ha una buona libreria su GitHub,
che passa attraverso molte cose
(ispirato al diverso malware
che ha incontrato come ricercatore di sicurezza).
Una bella biblioteca se
dovresti essere in esecuzione in un emulatore
se sei in produzione. Potrebbe dare un’indicazione
quella
ti stai manomettendo.
O dinamicamente debuggato.
L’altra cosa che puoi fare
è il test SafetyNet.
(Questo è quello che ho menzionato all’inizio.)
Fa parte dei servizi di Google Play.
(Penso che sia stato 7.5, è stato rilasciato.)
C’è un test che puoi eseguire
(la documentazione è un po ‘vaga su ciò che fa).
Dice se è compatibile con CTS,
e i test CTS di
ogni versione di Android da cui è stato creato
l’albero open source.
Se passa tutti loro, allora è verificato come
un dispositivo okay.
Il SafetyNet
tornerà falso se il dispositivo è radicato,
se è stato compromesso in altri modi.
Ha la vulnerabilità,
puoi
controllare lo stato del dispositivo.
L’API era abbastanza ingombrante,
così ho scritto una libreria di supporto per completarla.
(Questo vale per la convalida del dispositivo.)
(c’è anche un campione nel Play Store,
puoi semplicemente eseguire sul tuo dispositivo.)
Dà un’indicazione
quell’installazione di quell’app
potrebbe essere in esecuzione su un dispositivo di compromissione,
e puoi agire di conseguenza sul server
a seconda di questa informazione.
La libreria di esempio non ha un componente lato server
(il team di sicurezza di Android me lo fa sapere
questo è quello che dovrebbe avere):
fai il test di validazione sul dispositivo,
(Che è buono, ma è meglio fare il test di validazione
sul server, perché non può essere compromesso).
Se il dispositivo è di proprietà,
vuoi fare quei controlli sul server.
(è abbastanza per farti andare con quello).
Sto lavorando su un ramo lato server di quello
per mostrare come potrebbe essere usato.
(Vale la pena controllare.)
Di solito mi viene chiesto di rilevare root;
la cosa che potresti voler fare
nella tua app.
Probabilmente dovrei iniziare con un disclaimer
che non esiste un modo 100% di controllo per root.
(La radice di root su un dispositivo è l’equivalente
ad essere Dio; non c’è modo che tu possa mai
Il 100% afferma di averlo rilevato o meno).
Ma puoi cercare app di root,
app potenzialmente pericolose.
È possibile controllare alcune proprietà del sistema,
che avrebbe potuto essere cambiato
su un dispositivo rooted.
Il modo più comune è cercare il binario SU,
che può o non può essere presente o potrebbe essere nascosto.
Lo stesso con il binario BusyBox.
È inoltre possibile controllare se determinati percorsi di sistema
sono scrivibili o riscrivibili
(quando non dovrebbero essere).
Abbiamo tirato quegli assegni
e metterlo in una biblioteca chiamata Rootbeer
(logo in alto).
Questo fa anche un controllo nativo.
E siamo riusciti a sconfiggere
alcuni dei mantelli della radice che abbiamo trovato.
Se installi diversi dispositivi di protezione di root,
riescono a sconfiggerlo alla fine.
È un buon riferimento
Se qualcuno ha altri controlli di root
vogliono aggiungere, sarebbe fantastico.
Modo semplice e veloce per farlo.
Con molti di questi,
questo rafforzamento di queste funzionalità di sicurezza.
Dobbiamo guardare ai modi in cui possiamo proteggere il binario,
per renderlo più difficile per gli attaccanti
prendere i controlli.
Possiamo offuscare il codice
(un modo per trasformare il tuo bello,
codice gestibile in ciò che vediamo in background qui,
burocratese).
È più difficile invertire, ma è ciò a cui la gente si riferisce
come sicurezza attraverso l’oscurità.
Il tuo codice non è crittografato,
è solo più difficile da leggere.
E poi spero che molti di voi abbiano sentito parlare di ProGuard.
è l’obfuscator di Java,
parte dell’SDK di Android, gratuito.
Molto facile da accendere in modo efficace.
Molte eccezioni Android che devi avere
già installato
(se hai installato l’SDK).
Una delle cose che devi ricordare
quando inizi a utilizzare il codice offuscato
è che se si ottiene crash.
(So che a volte succede nelle app.)
(Non posso dire di aver mai scritto un’app che si blocca, me stesso.)
(Non udibile)
Cercando di capire cosa sta succedendo
con una traccia di stack che è stata offuscata
è quasi impossibile
Ed ecco perché, in ProGuard,
hanno uno strumento chiamato ReTrace,
che prende l’output da ProGuard,
che è come il tuo file di mapping,
e puoi usarlo
con la traccia dello stack e reinserirla
una traccia di stack sensibile con numeri di linea
e nomi propri per le tue classi e metodi.
(La cosa fantastica è quella,)
Servizi come Crashlytics, HockeyApp,
e critterismo
(ma non ricordo se lo fanno ora),
supporta il disarmo automatico dei blocchi.
Sono un grande fan dei Crashlytics,
(L’ho usato di più
Ne parlerò solo.)
Hanno un compito Gradle
che gira quando fai una build; caricherà
quel file di mapping automaticamente.
(è molto utile).
Ma se vuoi andare a Pro-ProGuard,
vuoi dare un’occhiata a DexGuard.
Questa è la versione pro / a pagamento.
Certo, ci sono altri offuscatori
che potresti guardare
Metaforico e Arxan
(molto popolare e costoso)
fare un lavoro migliore
di ProGuard in protezione.
(Ho più familiarità con DexGuard,
Lo farò, ne parlerò.)
ProGuard
è un obfuscator di Java;
DexGuard, è stato realizzato per Android,
ed è più intorno alla protezione.
Ci sono utilità di sicurezza
integrato nella versione Enterprise
(alcune delle cose di cui abbiamo parlato in questa presentazione)
solo usando il codice di utilità. Questo è automaticamente
indurito come parte del processo.
Solo utilities utili, in modo efficace.
Le mie due caratteristiche preferite:
crittografia di sting,
perfetto per qualsiasi chiave API
o segreti che hai nella tua app
(quando si esegue il reverse engineering, è facile da trovare).
(Utilizzare la crittografia delle stringhe è un modo per farlo).
Nel tuo file di configurazione DexGuard,
solo quelle stringhe, che siano
il nome della variabile attuale,
o il codice
(hai diverse opzioni).
Ogni volta che appare nel codice,
questo è tutto criptato.
Ovviamente, la chiave è nei file APK da qualche parte;
altrimenti non saresti in grado di eseguire l’app,
ma è solo un modo semplice e veloce
di nascondere le tue chiavi.
L’altro è nascosto nell’API
(parte del processo DexGuard),
cambia tutto ciò che è stato nascosto
in una chiamata basata su reflection Java.
Quando lo decodifichi,
è più difficile da
capire il flusso dell’app.
Puoi usare quelli
in congiunzione con l’altro
(è per questo che mi piacciono).
Puoi nascondere il controllo antimanomissione,
o nascondere la verifica del blocco SSL,
e quindi, usando la crittografia delle stringhe, fai riferimento al tuo
nome del metodo, i nomi delle classi,
che hai utilizzato una chiamata basata sulla riflessione, in modo efficace,
che hai nascosto, e che è anche crittografato.
Questo lo rende un controllo a doppia intensità.
Qualcuno che sta cercando quello
sta guardando un codice che non ha alcun senso
ma sta anche cercando qualcosa
che poi devono prima decrittare.
(Penso che sia abbastanza bello.)
(questo è per i consigli di sopravvivenza.)
Test e cercando di vedere l’altro lato della medaglia,
cosa vede l’aggressore.
ci sono molti strumenti
e ottimi articoli su come decodificare:
Apktool, dex-to-jar, Androguard.
Il kit di recensione rapida per Android,
(che non posso fare a meno di pensare “Quark”)
(ed è proprio come lo dico, e questa è la faccia che vedo
ogni volta che vedo quella libreria,)
è abbastanza nuovo, è stato open source
un paio di mesi fa da LinkedIn.
È uno script Python
che corri contro la tua app o il tuo codice sorgente.
Ti fornirà un rapporto HTML sui punti deboli
o qualsiasi exploit che potrebbe potenzialmente essere fatto.
Come un APK di exploit,
puoi provare e sfruttare diverse cose.
(sicuramente uno per i tuoi tester
e per te da fare una volta che ne hai messo alcuni
consigli di sopravvivenza sul posto.)
È una nuova biblioteca, stanno cercando una maggiore esposizione
(Ho pensato di menzionarli).
L’altro è
Drozer, da Mercury Labs.
È stato intorno per un po ‘.
molto ricco di funzionalità.
(il tizio con cui ho scritto il libro,
ha scritto alcune cose davvero buone su come
sfruttare e testare le app per vedere se sono vulnerabili
usando Drozer, quindi vale sicuramente la pena di provarlo.)
Links,
perché
ci sono tonnellate di altre cose che puoi guardare.
(ci sono solo alcuni collegamenti che potrebbero essere utili).
Come un riepilogo,
si spera l’analogia della giungla
non era troppo artificioso
L’ecosistema è vario, ci sono predatori
e minacce là fuori.
E, si spera, ti ho armato con alcuni consigli di sopravvivenza,
potenzia la sicurezza delle tue app.
Grazie mille a GOTO Copenhagen
per avermi invitato qui.
La mia azienda ha bisogno di una mano per sostenermi in questo,
e 20th Century Fox, ovviamente, per non farmi causa
per aver strappato sfacciatamente un sacco di loro,
screenshot dai loro film.
Grazie per l’ascolto.
Saluti.
(applausi)
– Grazie mille, Scott.
ci sono solo un paio di domande, qui.
Immagino che faresti meglio a metterli in campo da soli.
– Va bene.
“stai dicendo di non persistere la chiave sul dispositivo,
come gestisci il cambio della password? “
Ce la puoi fare. Se vuoi vedere un esempio
di come fare questo, controlla la mia libreria Secure-Preferences
perché lo gestisco in questo, e così sarebbe
in un modo molto stupido
decifrare la libreria / codice
con la password esistente,
e quindi criptarlo nuovamente con l’altra password.
Non puoi farcela, perché quello è
modifica della password, non ti aiuta a far fronte
con se qualcuno ha dimenticato la password.
In tal caso, non è possibile decrittografare i dati.
Ecco perché lo vedo più come,
è davvero buono per il caching dei dati.
Ma non c’è modo di
trovando quella password, questo è il punto.
Ecco perché è il modo sicuro per farlo.
C’è un’altra domanda:
I collegamenti JavaScript in WebView sono sicuri da usare?
Questa è una buona domanda, non so se ho un
una risposta definitiva su questo.
Direi di no, mi sbaglierei dalla parte della cautela.
Sono sempre stato spaventato
cosa puoi fare con quello
È migliorato nell’API 17, con l’annotazione
che devi annotare esplicitamente i metodi
che puoi chiamare da JavaScript in Java.
Ma non l’ho usato
che vincola molto.
E c’è una domanda su …
about: Bootstrapping firmware in banda base
come vulnerabilità, reale o bufala?
Non conosco la risposta a questa domanda.
Qualcuno ha delle domande dal vivo,
prima di partire?
– [Voiceover] Puoi confrontare il Keystore
per password, digitare quello?
Ne hai mai usato uno?
– Sì. Una delle cose
Non ho avuto il tempo di parlare,
dal momento che Android 3.1, c’è
il Keystore Android, simile
per iOS Keychain, nel fatto che lo è,
è un posto dove puoi immagazzinare
un certificato. Sfortunatamente non lo è
come il portachiavi su iOS,
perché puoi semplicemente archiviare segreti arbitrari.
Su Android, devi memorizzare una chiave pubblica-privata,
e poi usarlo per crittografare altre cose.
Questo è venuto in Android 4.3,
e ci sono un paio di problemi con esso,
non essere coerenti
nel modo in cui si comporta;
se l’utente cambia il proprio PIN su alcune versioni di Android,
cancella semplicemente il Keystore e altre volte
dice ancora che è lì,
ma in realtà l’ha cancellato.
Uno dei miei amici ha scritto un articolo
chiamato “The Forgetful Keystore”.
Ha fatto una metrica
su quali versioni e quali cose diverse accadono,
perché ha iniziato a usarlo.
In termini di ciò è più sicuro,
sono basati sullo stesso principio.
Stanno usando qualcosa che l’utente inserisce,
che non memorizziamo sul dispositivo, per poi crittografarlo,
per generare una chiave che usiamo per fare la crittografia.
Vorrei che fossero più o meno uguali,
Preferisco semplicemente fare una crittografia basata su password
che internamente, con la mia app,
perché ne ho il controllo.
E inoltre, costringendo l’utente a inserirsi
un passcode o una password per la mia app,
quando è un’app sicura e c’è un punto in cui
è una vendita facile, ma
costringendo quell’utente ad avere un PIN, un codice di accesso,
quando non ne hanno uno, questo è il grande problema.
Questa è una vendita più grande, se sei una banca,
Penso che costringendo l’utente ad avere un codice PIN sul proprio dispositivo
è, probabilmente potresti farla franca,
ma altre app con cui penso ti farebbe davvero fatica.
Forse app aziendali,
probabilmente te la caverai pure,
ma questo è un grosso problema per l’utente.
Per essere chiari, per utilizzare il Keystore Android,
l’utente deve avere un codice PIN o un passcode abilitato,
e questa è la cosa fondamentale.
Devi forzarlo per l’intero dispositivo
piuttosto che solo la tua app; è per questo che tendo a preferire,
facendolo in-app,
ma è anche una buona soluzione.
Inoltre, se stai usando, se sei in una posizione fortunata
di poter scegliere come target l’API 17 e versioni successive,
che, non so se nessun altro
è in quella grande situazione, so che non lo sono.
Davvero una buona domanda.
– Ok, un’altra domanda.
– [Voce fuori campo] Ho appena guardato il sito Web di occultamento,
parte di questa libreria di Facebook,
e affermano che è super veloce.
Lavori con esso o lo fai
cosa fanno che lo rende molto più veloce,
o cosa sta succedendo –
– L’ho usato,
ed è piuttosto veloce, e usa
un paio degli algoritmi SSL aperti,
che sono veloci
Sta facendo codice nativo,
piuttosto che cosa fa SQLCipher
è in bundle l’intera libreria SSL aperta,
raggruppa semplicemente quegli algoritmi
e le cose di cui hai bisogno,
è per questo che è più veloce.
Non è così grande
un carico utile, in modo efficace.
In realtà, vale la pena menzionare,
L’ho menzionato nel discorso,
ma è una di quelle librerie di Facebook
che non ha la strana licenza su …
Ho dimenticato di cosa si tratta.
È commercialmente fattibile.
Freddo.
Brillante, grazie per quelle grandi domande,
e applaude di nuovo per essere venuto.
(applausi)
(applausi)
Grazie per il caloroso benvenuto,
e grazie a voi ragazzi per essere venuti oggi.
So che ci sono parecchi discorsi decenti al momento
e la sicurezza di Android può essere un po ‘di nicchia.
Ho provato a
usa quell’analogia della giungla
per parlare dell ‘”ecosistema Android”:
alcune delle minacce e dei rischi.
(questa è l’idea dietro al discorso).
L’ho diviso in due parti,
per consentire il fatto
che questa è una conferenza per
tutti gli sviluppatori e le persone tecniche.
Il primo semestre è per tutti.
Speriamo di poter parlare dell’ecosistema
e dissipare alcuni miti.
La seconda metà, ci accingiamo a entrare
consigli di sopravvivenza completi da rafforzare
la sicurezza delle tue app.
(Potresti notare alcuni riferimenti
in un certo film della giungla per tutta la presentazione.
ci sono premi alla fine se riesci a indovinare quale è).
Prima di iniziare, permettimi di presentarmi
un po ‘più in dettaglio.
Sono uno sviluppatore principale di Android presso una piccola azienda di app
con sede a Bath (Regno Unito).
Lavoro a distanza da Bristol
(che, dopo aver parlato con alcune persone ieri,
nessuno sapeva davvero dove fosse,
e quindi è a circa 100 miglia a ovest di Londra,
ed è la casa di Banksy.
E quelle due cose che la gente sembra avere dove si trova.)
In Intohand creo app
per le industrie
(app meteo, vendita al dettaglio, video on demand e roba del genere).
E il mio pezzo preferito, o il po ‘mi eccita
ed entusiasta è la parte di sicurezza:
rendendoli più difficili da hackerare.
Questo interesse mi ha portato a essere coautore
il ricettario di sicurezza Android.
Ho scritto circa un terzo di quel libro
(capitoli difensivi e di protezione).
Alcune delle cose che copriamo un po ‘nella seconda metà.
(breve nelle diapositive, ovviamente,
ma ci sono più esempi di codice
nel libro).
L’ultima cosa
è che ho co-fondato SWmobile,
che è un gruppo di meetup per sviluppatori mobili
con sede nel sud-ovest dell’Inghilterra
(circa 600 membri,
e facciamo regolari colloqui e hackathon tecnici).
(Sono un lavoratore a distanza, ma
Mi piace stare in contatto con altri sviluppatori,
e condividendo storie di guerra e cose,
quindi per favore vieni a dire “Ciao” dopo il discorso).
vuoi ambientare la scena con Android.
All’inizio della scorsa settimana, Sundar ha annunciato
che ora abbiamo 1,4 miliardi
utenti attivi di Android
(30 giorni attivi
dispositivi con servizi Google installati,
questo non include nemmeno tutti quelli
Compresse cinesi).
(Numero enorme).
Di gran lunga la più grande piattaforma mobile.
(Questa grafica funky sta cercando di illustrare
è che è una piattaforma diversa).
C’è oltre un milione di righe di codice
nel progetto open source Android.
Migliaia di dispositivi diversi
(che questo grafico sta cercando di illustrare
da opensignals.com
relazione annuale sulla frammentazione).
Centinaia di OEM.
In teoria, ci sono occhi sul codice.
Questo dovrebbe creare fiducia,
ma non c’è
un singolo punto di errore;
non ci affidiamo a una singola azienda o entità
che contiene tutte le chiavi.
E il punto di queste diapositive di coppia era solo per dire:
non esiste un “modo in cui è” su Android.
Dovresti essere scettico
di qualsiasi venditore di sicurezza o società
quello dice che hanno una maniglia su esso.
A differenza di iOS, dove abbiamo
aggiornare i dispositivi in questo ambiente diversificato
tramite aggiornamenti via etere,
quando abbiamo diversi OEM
e diverse modifiche del vettore,
gli aggiornamenti via etere semplicemente non funzionano.
In che modo Google contribuisce alla sicurezza in questi casi?
Hanno messo i servizi di sicurezza.
Ho appena scelto un paio che pensavo fossero rilevanti.
Il primo è (quello probabilmente la maggior parte di voi
sentito parlare): Google Play Store.
C’è stato un umano coinvolto
nel processo di approvazione dall’inizio del 2015.
Quando ti registri per gli account,
ci sono controlli sullo sfondo
di cui non si conosce
Ma Google ha sfruttato le loro altre app
(es. Gmail),
e tutti i loro punti di dati per aiutare con quello
controllo di validazione in background.
Hanno anche iniziato
le notifiche di sicurezza sviluppatore.
Durante la scansione delle app
e facendo il loro test per vedere se
non è malware,
se rilevano le cose
lo sviluppatore ha accidentalmente incluso
le loro chiavi private nell’app,
se stanno usando una versione vulnerabile
di SSL aperto che hanno incluso,
e hanno anche, ci sono alcuni problemi
attorno a particolari versioni di PhoneGap, Cordova.
Quello che hanno iniziato a fare è stato avvisare gli sviluppatori,
dicendo “Sai che hai le tue chiavi private
nella tua app, dovresti aggiornarlo. “
Pensano che ci siano circa 60.000 app
sono stati aggiornati in merito a quelle notifiche
(buon sistema).
Piccola goccia nell’oceano rispetto al numero di app,
ma è un passo nella giusta direzione.
L’altra cosa che sta dietro la scena
su Google Play Store è il servizio Android Bouncer,
che è stato annunciato o annunciato pubblicamente,
diversi anni fa, e questo va e viene
tutte le app in emulare gli ambienti.
Controlla le firme del malware e roba ingannevole,
e poi li rimuove dall’app store,
li sospende e, se giustificato,
può cancellarli da remoto dai dispositivi.
L’altro
è il gestore dispositivi Android,
un servizio gratuito
(chiunque abbia un dispositivo Android può installare:
aiutarti a trovare, bloccare,
e, se necessario, pulire il dispositivo).
(Se hai un dispositivo Android
e non l’ho installato,
Consiglierei sicuramente di metterlo su).
Qualcosa che Google ha annunciato di recente
è il sistema di sicurezza:
un sistema di rilevamento delle intrusioni.
È possibile raccogliere qualsiasi dispositivo con servizi Google
diversi punti di dati e carica quello
ai servizi di Google e eseguono analisi dei dati.
Cercano e cercano potenziali malware.
Nella seconda parte della presentazione,
Parlerò dell’API pubblica per la rete di sicurezza
(puoi sfruttare le tue app,
per sfruttare parte di quella conoscenza,
che è abbastanza buono).
Infine, menzione
Android at Work, che è un modo di segregazione
i tuoi dati personali e aziendali e le applicazioni
sullo stesso dispositivo.
Decisamente orientato verso
un approccio BYOD,
ma fornisce agli amministratori di sistema
Accesso API per provisioning,
gestione dei profili.
Puoi
rimuovi il tuo accesso
e basta cancellare i dati aziendali e le app
non le tue foto e cose personali
(Penso che sia bello).
La prossima slide parla dei diversi livelli
(Ho rubato questo dal discorso di Adrian Ludwig
da Black Hat, perché pensavo che fosse abbastanza buono
a mostrare i diversi strati).
Se vai da sinistra a destra
questo è il numero maggiore di servizi basati su cloud,
agli strati all’interno
il dispositivo.
Volevo solo attirare l’attenzione
la sezione delle app verificate.
È entrato in Android in 4.2,
un modo per Google di monitorare le app
e rilevare potenziali malware quando gli utenti stavano installando
applicazioni non da Google Play Store.
Chiunque abbia un dispositivo Android
che l’ha installato, vedrà il consenso “Verifica app”;
poi,
quando è un potenziale malware,
riceverai un avvertimento,
In effetti, se è così pericoloso
potresti essere bloccato dall’installazione.
(bel controllo, a proposito
che Google sta cercando di aumentare la tua sicurezza
anche se non stai utilizzando Google Play Store).
L’altra cosa che vale la pena tenere a mente,
è Android
aggiornando il suo più recente. Le versioni più recenti
avere più funzioni di sicurezza e un più forte,
Ho pensato di dirlo
se stai cercando un
una politica BYOD,
versioni più recenti di Android
sarebbe una buona politica
Per alcune app,
se hai bisogno di determinati requisiti di sicurezza,
targeting cinque e sopra
sarebbe una buona chiamata.
Questo è l’ecosistema.
Voglio parlare di alcune delle minacce ora.
Malware di
e sicurezza Android
ialways ottiene,
i media tech adorano mettersi in contatto.
Sono sicuro che tutti voi avete visto quei titoli clickbait
questo riguarda il modo in cui Android è stato aperto.
Mentre impari di più a riguardo,
puoi vedere, è un sacco di hype.
Ma c’è stato di più
malware divulgato pubblicamente su Android
che su iOS.
Tendono ad essere in giro, in gran parte,
intorno agli SMS premium.
Sebbene, in Android 4.2, abbiamo ricevuto questo nuovo avviso;
se scrivi un breve codice ottieni
una schermata di conferma dell’utente che viene visualizzata.
Ciò ha attenuato alcuni malware.
A parte questo, tende ad esserlo
ladri di informazioni,
e, di recente
ransomware.
L’ultima cosa che volevo dire sul malware:
regioni in cui ti trovi nel mondo
gioca un ruolo enorme.
Russia, Cina e Persia,
l’istanza media di malware
è superiore a Europa e America.
Qualcosa che,
per quanto Google ha annunciato, stanno esaminando
(Qualcosa da tenere a mente
quando ascolti queste storie di malware).
Una delle altre minacce che abbiamo
è il dirottamento di app
(noto anche come app “trojanizing”).
Prendi una vera app,
decompilalo
e mettere malizioso
Ovviamente,
potrebbe potenzialmente danneggiare il tuo marchio (se questa è la tua app),
e influenzano i tuoi utenti.
Dovresti ingannare gli utenti per installarlo,
da e-mail di phishing, ecc.
Le preoccupazioni su questo è perché
invertire le app per Android è abbastanza semplice.
(c’è un discorso questo pomeriggio che riguarda parte di questo,
Non ho intenzione di entrare troppo nei dettagli ora).
Su Android non abbiamo, un’autorità di certificazione
quando firmiamo app
(ogni app deve essere firmata
per essere installato su un dispositivo,
ma non c’è un’autorità centrale intorno a questo,
quindi ci saranno tutti i certificati autofirmati).
L’altra preoccupazione è quella delle app che caricano il sideload
(installazione di app
che non provengono dal negozio di giochi approvato),
è molto semplice (è solo un’opzione
che si spegne sul dispositivo).
Tre cose
che rendono il dirottamento delle app più di un problema
che n iOS (più difficile
per sideload app).
Parleremo nella seconda parte di alcune delle difese che puoi mettere
nella tua app per proteggersi dal dirottamento delle app.
Ci sono stati un paio di grandi storie.
(Probabilmente potrei fare una presentazione
solo su tutti gli incidenti di sicurezza negli ultimi 18 mesi
dentro e intorno a Internet e Android).
(Anche se, Heartbleed, di cui sto parlando qui,
ha colpito solo una versione di Android).
(Era ancora interessato).
Chiunque abbia incluso quella versione,
aveva a che fare con una vulnerabilità SSL aperta.
Parte degli assegni dello sviluppatore
che il Play Store fa ora (la scansione dell’app)
è legato a questa minaccia.
Recentemente (come probabilmente avete indovinato),
se vieni su
con un exploit Android,
devi trovare un nome interessante
e un bel logo. (tutti stanno facendo un ottimo lavoro,
che è bello vedere).
Stagefright era un altro
che ha interessato quasi tutti i dispositivi Android
fuori nel mercato.
Era un exploit diffuso, potenzialmente,
e potrebbe denial-of-service attaccare quel dispositivo
(non ci sono state minacce
o attacchi ancora).
(Ho pensato di menzionarlo, A, perché è recente).
b) sono accadute alcune cose veramente positive).
I dispositivi Nexus ora hanno un aggiornamento di sicurezza mensile
e bollettino sulla sicurezza
(i problemi di sicurezza sono stati risolti).
Anche Samsung e LG si sono impegnati
per frequenti programmi di patch di sicurezza.
Alla luce di questi,
questa grande ricerca,
(e questo nome funky
che ha attirato l’attenzione di tutti i media),
costretto alcuni degli OEM
per aumentare i loro aggiornamenti di sicurezza.
(grande cosa).
(Questo è un paio delle minacce).
Parliamo di alcuni dei rischi per le nostre applicazioni
(quando li stiamo creando).
(Nessuna presentazione può essere completa
senza una Top 10).
Citerò il
i primi 10 rischi
che ci sono le nostre app.
Questo è stato compilato dal progetto OWASP
(alcuni di voi forse conoscono il
Apri il progetto di sicurezza delle applicazioni Web dal mondo web).
È un’organizzazione senza fini di lucro
focalizzato sul miglioramento della sicurezza nel software.
E un paio di anni fa, hanno prodotto
i primi 10 rischi mobili
(Dovrebbero aggiornarlo molto presto)
Quando stiamo parlando
consigli di sopravvivenza
proveremo e relazioneremo
ad alcuni di questi
(Li ho appena messi qui per riferimento.
è troppo da accettare, su una diapositiva).
Se vai al sito OWASP
(il sito del progetto Mobile Security),
ognuno di questi è suddiviso in
vettori di attacco e codice di esempio
di come mitigarli
(sicuramente vale la pena verificarlo).
(una delle cose
dovresti guardare quando lo fai
il tuo sviluppo e test).
Se riesci a spuntare questi 10 rischi,
allora sei sulla buona strada per rendere la tua app più sicura.
(seconda parte)
(rapido spettacolo di mani:
chi è uno sviluppatore Android nel pubblico?
Brillante, è fantastico
è molto più di quanto mi aspettassi.
Fantastico – adorerai questa roba).
(Anche se non sei uno sviluppatore Android,
molto di questo si applica ancora a iOS
quando parlo
mobile thick client in modo efficace).
Diamo un’occhiata a come possiamo (sopravvivere
in questa giungla) migliorare la sicurezza delle nostre app.
(Stavo per concentrarmi su queste quattro aree;
ogni area ha diverse cose).
B Desideriamo rafforzare la comunicazione di rete
tra l’app e il nostro servizio.
Vogliamo proteggere tutti i dati che abbiamo archiviato.
Stiamo per: utilizzare
crittografia per quello;
guarda come convalidare
(dove è in esecuzione l’app), l’integrità del dispositivo e dell’app.
Quindi, guarda come possiamo
aumentare la sicurezza binaria.
(queste
si applica anche a iOS).
Ho pensato di iniziare
rafforzare le comunicazioni di rete,
perché ogni app che ho scritto
ha qualche componente online.
(È quasi scontato, ma)
Utilizzo di SSL e TLS per tutte le comunicazioni di rete
dovrebbe essere un valore predefinito
In iOS 9,
l’hanno reso obbligatorio
(devi rinunciare).
(Spero che la prossima versione di Android
viene fornito con qualcosa di simile).
Il secondo punto: utilizzare la piattaforma
Validazione SSL / TLS e non disabilitarla.
(sembra una cosa stupida da dire;
ma se tu Google
o vai a Stack Overflow come abilitare l’uso
certificati SSL autofirmati,
vedrai la risposta più votata
su Stack Overflow con tonnellate di rep
ti spiega come disabilitare la convalida SSL,
rendendo totalmente inutile il concetto di SSL.)
Esistono diversi modi per farlo.
Puoi usare una forma di pinning (di cui parlerò successivamente),
o acquista certificati originali
per il tuo servizio di sviluppo
(questo è quello che ho fatto in passato;
ti risparmia di dover mettere tutto questo codice dubbia
nella tua base di codice
che in pratica disabilita la convalida).
L’altra cosa che potresti fare
è utilizzare solo le suite di crittografia più potenti,
e le versioni TLS più forti.
(Questo è particolarmente importante o utile.)
Se controlli il servizio, puoi controllarlo
il tipo di connessione,
la forza della crittografia
tra le tue app e il server.
SSL predefinito per versioni inferiori,
per supportare i browser più vecchi.
Ma non devi farlo nella tua app. Puoi
far rispettare ciò, e
se qualcuno sta usando OKHttp,
2.1, visto
fantastici aggiornamenti e funzionalità di sicurezza.
Se stai usando 2.1, c’è un buon articolo
su come è possibile far rispettare le specifiche di connessione
(essere più forte
e rilasciare le specifiche inferiori).
Se stai usando direttamente dall’SDK,
HttpsURLConnection,
potresti ancora farlo con.
(Se qualcuno vuole dei campioni di codice,
dammi solo un urlo).
È una linea su OKHttp.
L’altra cosa che potresti vedere
con le tue connessioni è: pinning SSL.
(Se solo potessi avere una dimostrazione di mani,
chi ha già sentito parlare di SSL prima?
Brillante, quindi molte persone).
(Per coloro che non ne hanno sentito parlare)
È solo un modo per ridurre
la quantità di autorità di certificazione
di cui ti fidi
Stai vincolando in modo efficace il tuo certificato SSL
per assicurarsi che sia quello.
Esistono due diversi tipi di pinning.
1) pin l’intero certificato,
o 2) pin la chiave pubblica di quel certificato.
Raccomando sempre di inserire la chiave pubblica.
È un piccolo passo in più per ottenere il pin …
ma non devi cambiare la tua app
o forzare un aggiornamento dell’app
ogni volta che rinnovi il tuo certificato.
(Ho messo un link al libro, lì,
c’è un esempio di codice su come farlo).
(C’è un codice open source online
di Moxie Marlinspike,
ma non ha una grande licenza commerciale).
(Controlla le cose nel libro.)
In sostanza,
quando si effettua una connessione, si esegue una verifica
per assicurarsi che sia il certificato SSL che dovrebbe essere.
(questo è il fondamento del pinning).
L’altra cosa dovresti probabilmente guardare
è il networking (il
parte dei servizi di Google Play,
loro hanno introdotto questo
fornitore di sicurezza dinamico).
Questa è un’altra di quelle cose
perché, non possiamo garantire aggiornamenti via etere,
non possiamo garantire che gli utenti
stanno andando ad aggiornare i loro telefoni,
Google ha messo in atto,
e il ciclo di aggiornamento dei servizi di Google Play
dura da sei a otto settimane.
In quel periodo di tempo,
c’è una possibilità di ottenere,
se c’è una vulnerabilità che viene fuori,
o un exploit, c’è una possibilità che quella soluzione
viene fornito in bundle all’interno dei servizi di riproduzione.
(Ho messo un link all’articolo di formazione lì.
Ha tutto ciò che devi sapere su come chiamarlo
e quando chiamarlo;
l’esempio del codice è così semplice.)
Puoi usare quello:
il fornitore risolverà eventuali problemi nel sistema che ha
con una qualsiasi delle librerie OpenSSL.
Perché è un aggiornamento
del provider di crittologia, puoi usarlo
per
anche crittografia automatica standard.
Puoi usarlo al posto di Bouncy Castle.
(questo è per le cose in rete.)
Successivo: dati.
Quando dico immagazzinare dati,
Intendo criptare i tuoi dati.
Qualcosa che mi ha frustrato come sviluppatore di app,
quando ho avuto rapporti sulle pen test sulle app che ho creato,
o parlato con persone della sicurezza, analisti,
hanno sempre detto “non archiviare dati”.
Voglio fare la mia app
il più performativo possibile,
Voglio farlo funzionare offline,
o in scomode connessioni mobili.
(Il “non memorizzare dati”
usato per insinuarmi.)
Se lo stai immagazzinando,
deve essere crittografato.
E, ovviamente, questo dipende
sul tipo di dati e
applicazione che hai
(cartelle cliniche, codici di lancio nucleari,
probabilmente non dovrebbe essere memorizzato nella cache;
altri dati dovrebbero essere).
(Ecco un codice,
solo per mostrare quanto sia facile.)
Questo è un approccio di best practice,
quando si esegue la crittografia:
usa la crittografia basata su password.
(non farlo
memorizzare la chiave ovunque).
La cosa principale della crittografia
è dove archiviare le chiavi.
Raramente è l’algoritmo che è rotto,
è il fatto che qualcuno trovi dove sono le chiavi.
Questo mostra come usare
crittografia basata su password: utilizzo
l’utente inserisce e quindi usa quello
derivare una chiave di crittografia. In questo caso,
derivare una chiave di crittografia simmetrica
(la chiave che usiamo per la crittografia e la decrittografia).
(Ho messo questo per riferimento.
c’è un esempio migliore nel libro.)
Tu non
persistere la chiave ovunque,
non si blocca la chiave da nessuna parte,
e poi costruisci in un timeout dell’app
(a seconda della tua app,
forse quando l’app va in secondo piano,
forse quando l’utente si disconnette,
ma si cancellerebbe quella chiave dalla memoria).
(è così che rimane al sicuro).
In questo esempio di codice stiamo usando circa 10.000 iterazioni,
(bello e forte, ma basta un po ‘di tempo,
forse quattro secondi
su un Nexus 5).
Puoi sintonizzarti, a seconda di
quanto vuoi che sia sicuro.
Un paio di librerie
può rendere le tue attività di crittografia molto più semplici
(commercialmente fattibile).
(Altrimenti, non c’è motivo di menzionarli, per essere sinceri.)
(Le diapositive che sono caricate hanno collegamenti
e roba a tutti questi).
Conceal è di Facebook:
fantastico per i file.
Lo usano per crittografare le foto
che hanno memorizzato nella cache sulla scheda SD.
Facile da usare,
per impostazione predefinita tutti gli algoritmi più potenti.
Usa AES-GCM (il preferito
Algoritmo AES).
(Consiglio vivamente di provarlo.)
(È predefinito per le cose forti,
perché la roba, se è un hangup
dai giorni Java, sai, dal passato di Android,
essendo basato su Java,
ma l’impostazione predefinita, quando si ha a che fare con la crittografia,
non è predefinito per il forte,
l’algoritmo più forte.)
(Un vero peccato,
perché vuoi solo iniziare a usarlo
ed è il più forte possibile,
ma questo è il bello di Conceal.)
QLCipher, se qualcuno di voi ha
un database SQLLite nella tua app,
che utilizzi per l’archiviazione dei dati,
puoi facilmente scambiare in SQLCipher.
Le API sono tutte esattamente uguali,
a parte quando apri un database
e quando crei un database,
devi passare una password,
e usa quella crittografia basata su password
(che ho parlato di un paio di diapositive fa),
generare, creare una chiave e crittografare i file del database.
La chiave su queste librerie
sono molto facili da usare,
facile da scambiare dentro e fuori
(questo è ciò che ottiene grandi segni di spunta nei miei libri).
SQLCipher utilizza AES a 256 bit in modalità CBC
(è abbastanza decente).
Tuttavia CQLCipher
aggiunge tra quattro e sette MB
alla tua dimensione APK (per alcune persone, è troppo).
La buona notizia è che Google si è appena alzato
il limite di dimensioni APK nel Play Store a 100 MB;
speriamo che dia meno
meno scuse per non usarlo.
Infine: Secure-Preferences,
una delle mie librerie open-source.
Puoi anche guardare Hawk (molto meglio chiamato
e implementazione molto più popolare).
(saltare i riferimenti per coloro che non sono familiari).
È un archivio di valori chiave supportato da un file XML:
modo semplice di assicurare
o offuscando quei file
(persone su dispositivi rooted
non posso scherzare con le tue cose).
Con Secure-Preferences, puoi usarlo con la password,
e fa quella crittografia basata su password.
(bello e sicuro).
Se non si utilizza una password, ne verrà generata una,
e conservalo lì
(se estrai il file, non puoi dire quale sia la chiave).
Ma
è ancora offuscato, perché
lo potresti trovare con abbastanza sforzo.
Solo piccoli passi
per rendere le tue app più difficili da hackerare.
Soprattutto:
evitare di codificare la chiave di crittografia.
Reverse engineering e ricerca di una costante,
una costante di stringa per la chiave di crittografia
è banalmente facile.
Ma
non tutte le app possono utilizzare la crittografia basata su password,
un passcode dell’app (o qualcosa di simile).
Se necessario, generare una chiave
in modo dinamico per installazione, non hardcode.
(è l’equivalente di chiudere la porta principale
ma lasciando le tue chiavi lì dentro
La porta è chiusa, ma non hai alcuna sicurezza,
quindi spero che vi ricordiate quei due).
Continuiamo a verificare l’integrità dell’app.
Ci sono un paio di cose che puoi fare.
Puoi controllare
se
queste sono tecniche di rilevamento di manomissioni.
La tua app è stata dirottata ?,
Funziona in uno stato diverso?
Puoi parlare con PackageManager,
e vedere se ci si trova in uno stato di debugging,
(non dovrebbe accadere
una volta che sei in produzione).
Puoi calcolare un checksum in apk
per vedere se è stato modificato.
O puoi
firmare una verifica del certificato.
Questo è il mio preferito, perché ognuno di noi
l’app deve essere firmata
con la chiave di uno sviluppatore
(quando lo pubblichiamo o lo distribuiamo).
Quella chiave rimane la stessa attraverso il
durata dell’app. Uno dei capisaldi
della sicurezza di Android è questo,
le firme devono corrispondere. Non posso prendere
L’app di Facebook, decompila –
romperebbe la firma, la rassegnasse,
e poi distribuirlo, e tu installi
La versione di Scott di Facebook. Non funziona in quel modo.
Le firme non corrisponderebbero
non ti permetterebbe di aggiornare.
La tua firma rimane la stessa
per tutta la durata della tua app.
Lo sai che in tempo di costruzione,
puoi controllare questo runtime.
(E questo è rapidamente come lo fai.)
Dovresti usare keytool (Java),
per elencare il tuo keystore
firma.
Quindi l’hai appena incorporato nell’app.
In fase di esecuzione, chiederei
il PackageManager per la tua firma.
Hash la firma (per assicurarne una,
per abbinare ciò che hai incorporato),
e quindi confrontare le stringhe.
(E questo è un modo semplice e veloce
di scoprire se la tua app è stata,
è stato decompilato e quindi modificato.)
Tuttavia, se qualcuno può decompilare il codice,
possono prendere questo controllo.
(copriremo tra un paio di diapositive
come possiamo offuscare il nostro codice,
rendere questo più difficile da fare.)
Puoi dire che per qualsiasi cosa inseriamo nell’app,
il pinning SSL, la crittografia,
qualcuno può decompilare, prendere pezzi e guardarlo.
Ma sta usando tutti questi metodi
in combinazione tra loro per rafforzare l’app.
Se vogliamo verificare l’integrità del dispositivo,
ci sono varie cose che puoi controllare.
Nelle proprietà della bolletta, solo per vedere se si tratta di un emulatore,
ci sono un paio di buone risposte su Stack Overflow.
Tim Strazzere ha una buona libreria su GitHub,
che passa attraverso molte cose
(ispirato al diverso malware
che ha incontrato come ricercatore di sicurezza).
Una bella biblioteca se
dovresti essere in esecuzione in un emulatore
se sei in produzione. Potrebbe dare un’indicazione
quella
ti stai manomettendo.
O dinamicamente debuggato.
L’altra cosa che puoi fare
è il test SafetyNet.
(Questo è quello che ho menzionato all’inizio.)
Fa parte dei servizi di Google Play.
(Penso che sia stato 7.5, è stato rilasciato.)
C’è un test che puoi eseguire
(la documentazione è un po ‘vaga su ciò che fa).
Dice se è compatibile con CTS,
e i test CTS di
ogni versione di Android da cui è stato creato
l’albero open source.
Se passa tutti loro, allora è verificato come
un dispositivo okay.
Il SafetyNet
tornerà falso se il dispositivo è radicato,
se è stato compromesso in altri modi.
Ha la vulnerabilità,
puoi
controllare lo stato del dispositivo.
L’API era abbastanza ingombrante,
così ho scritto una libreria di supporto per completarla.
(Questo vale per la convalida del dispositivo.)
(c’è anche un campione nel Play Store,
puoi semplicemente eseguire sul tuo dispositivo.)
Dà un’indicazione
quell’installazione di quell’app
potrebbe essere in esecuzione su un dispositivo di compromissione,
e puoi agire di conseguenza sul server
a seconda di questa informazione.
La libreria di esempio non ha un componente lato server
(il team di sicurezza di Android me lo fa sapere
questo è quello che dovrebbe avere):
fai il test di validazione sul dispositivo,
(Che è buono, ma è meglio fare il test di validazione
sul server, perché non può essere compromesso).
Se il dispositivo è di proprietà,
vuoi fare quei controlli sul server.
(è abbastanza per farti andare con quello).
Sto lavorando su un ramo lato server di quello
per mostrare come potrebbe essere usato.
(Vale la pena controllare.)
Di solito mi viene chiesto di rilevare root;
la cosa che potresti voler fare
nella tua app.
Probabilmente dovrei iniziare con un disclaimer
che non esiste un modo 100% di controllo per root.
(La radice di root su un dispositivo è l’equivalente
ad essere Dio; non c’è modo che tu possa mai
Il 100% afferma di averlo rilevato o meno).
Ma puoi cercare app di root,
app potenzialmente pericolose.
È possibile controllare alcune proprietà del sistema,
che avrebbe potuto essere cambiato
su un dispositivo rooted.
Il modo più comune è cercare il binario SU,
che può o non può essere presente o potrebbe essere nascosto.
Lo stesso con il binario BusyBox.
È inoltre possibile controllare se determinati percorsi di sistema
sono scrivibili o riscrivibili
(quando non dovrebbero essere).
Abbiamo tirato quegli assegni
e metterlo in una biblioteca chiamata Rootbeer
(logo in alto).
Questo fa anche un controllo nativo.
E siamo riusciti a sconfiggere
alcuni dei mantelli della radice che abbiamo trovato.
Se installi diversi dispositivi di protezione di root,
riescono a sconfiggerlo alla fine.
È un buon riferimento
Se qualcuno ha altri controlli di root
vogliono aggiungere, sarebbe fantastico.
Modo semplice e veloce per farlo.
Con molti di questi,
questo rafforzamento di queste funzionalità di sicurezza.
Dobbiamo guardare ai modi in cui possiamo proteggere il binario,
per renderlo più difficile per gli attaccanti
prendere i controlli.
Possiamo offuscare il codice
(un modo per trasformare il tuo bello,
codice gestibile in ciò che vediamo in background qui,
burocratese).
È più difficile invertire, ma è ciò a cui la gente si riferisce
come sicurezza attraverso l’oscurità.
Il tuo codice non è crittografato,
è solo più difficile da leggere.
E poi spero che molti di voi abbiano sentito parlare di ProGuard.
è l’obfuscator di Java,
parte dell’SDK di Android, gratuito.
Molto facile da accendere in modo efficace.
Molte eccezioni Android che devi avere
già installato
(se hai installato l’SDK).
Una delle cose che devi ricordare
quando inizi a utilizzare il codice offuscato
è che se si ottiene crash.
(So che a volte succede nelle app.)
(Non posso dire di aver mai scritto un’app che si blocca, me stesso.)
(Non udibile)
Cercando di capire cosa sta succedendo
con una traccia di stack che è stata offuscata
è quasi impossibile
Ed ecco perché, in ProGuard,
hanno uno strumento chiamato ReTrace,
che prende l’output da ProGuard,
che è come il tuo file di mapping,
e puoi usarlo
con la traccia dello stack e reinserirla
una traccia di stack sensibile con numeri di linea
e nomi propri per le tue classi e metodi.
(La cosa fantastica è quella,)
Servizi come Crashlytics, HockeyApp,
e critterismo
(ma non ricordo se lo fanno ora),
supporta il disarmo automatico dei blocchi.
Sono un grande fan dei Crashlytics,
(L’ho usato di più
Ne parlerò solo.)
Hanno un compito Gradle
che gira quando fai una build; caricherà
quel file di mapping automaticamente.
(è molto utile).
Ma se vuoi andare a Pro-ProGuard,
vuoi dare un’occhiata a DexGuard.
Questa è la versione pro / a pagamento.
Certo, ci sono altri offuscatori
che potresti guardare
Metaforico e Arxan
(molto popolare e costoso)
fare un lavoro migliore
di ProGuard in protezione.
(Ho più familiarità con DexGuard,
Lo farò, ne parlerò.)
ProGuard
è un obfuscator di Java;
DexGuard, è stato realizzato per Android,
ed è più intorno alla protezione.
Ci sono utilità di sicurezza
integrato nella versione Enterprise
(alcune delle cose di cui abbiamo parlato in questa presentazione)
solo usando il codice di utilità. Questo è automaticamente
indurito come parte del processo.
Solo utilities utili, in modo efficace.
Le mie due caratteristiche preferite:
crittografia di sting,
perfetto per qualsiasi chiave API
o segreti che hai nella tua app
(quando si esegue il reverse engineering, è facile da trovare).
(Utilizzare la crittografia delle stringhe è un modo per farlo).
Nel tuo file di configurazione DexGuard,
solo quelle stringhe, che siano
il nome della variabile attuale,
o il codice
(hai diverse opzioni).
Ogni volta che appare nel codice,
questo è tutto criptato.
Ovviamente, la chiave è nei file APK da qualche parte;
altrimenti non saresti in grado di eseguire l’app,
ma è solo un modo semplice e veloce
di nascondere le tue chiavi.
L’altro è nascosto nell’API
(parte del processo DexGuard),
cambia tutto ciò che è stato nascosto
in una chiamata basata su reflection Java.
Quando lo decodifichi,
è più difficile da
capire il flusso dell’app.
Puoi usare quelli
in congiunzione con l’altro
(è per questo che mi piacciono).
Puoi nascondere il controllo antimanomissione,
o nascondere la verifica del blocco SSL,
e quindi, usando la crittografia delle stringhe, fai riferimento al tuo
nome del metodo, i nomi delle classi,
che hai utilizzato una chiamata basata sulla riflessione, in modo efficace,
che hai nascosto, e che è anche crittografato.
Questo lo rende un controllo a doppia intensità.
Qualcuno che sta cercando quello
sta guardando un codice che non ha alcun senso
ma sta anche cercando qualcosa
che poi devono prima decrittare.
(Penso che sia abbastanza bello.)
(questo è per i consigli di sopravvivenza.)
Test e cercando di vedere l’altro lato della medaglia,
cosa vede l’aggressore.
ci sono molti strumenti
e ottimi articoli su come decodificare:
Apktool, dex-to-jar, Androguard.
Il kit di recensione rapida per Android,
(che non posso fare a meno di pensare “Quark”)
(ed è proprio come lo dico, e questa è la faccia che vedo
ogni volta che vedo quella libreria,)
è abbastanza nuovo, è stato open source
un paio di mesi fa da LinkedIn.
È uno script Python
che corri contro la tua app o il tuo codice sorgente.
Ti fornirà un rapporto HTML sui punti deboli
o qualsiasi exploit che potrebbe potenzialmente essere fatto.
Come un APK di exploit,
puoi provare e sfruttare diverse cose.
(sicuramente uno per i tuoi tester
e per te da fare una volta che ne hai messo alcuni
consigli di sopravvivenza sul posto.)
È una nuova biblioteca, stanno cercando una maggiore esposizione
(Ho pensato di menzionarli).
L’altro è
Drozer, da Mercury Labs.
È stato intorno per un po ‘.
molto ricco di funzionalità.
(il tizio con cui ho scritto il libro,
ha scritto alcune cose davvero buone su come
sfruttare e testare le app per vedere se sono vulnerabili
usando Drozer, quindi vale sicuramente la pena di provarlo.)
Links,
perché
ci sono tonnellate di altre cose che puoi guardare.
(ci sono solo alcuni collegamenti che potrebbero essere utili).
Come un riepilogo,
si spera l’analogia della giungla
non era troppo artificioso
L’ecosistema è vario, ci sono predatori
e minacce là fuori.
E, si spera, ti ho armato con alcuni consigli di sopravvivenza,
potenzia la sicurezza delle tue app.
Grazie mille a GOTO Copenhagen
per avermi invitato qui.
La mia azienda ha bisogno di una mano per sostenermi in questo,
e 20th Century Fox, ovviamente, per non farmi causa
per aver strappato sfacciatamente un sacco di loro,
screenshot dai loro film.
Grazie per l’ascolto.
Saluti.
(applausi)
– Grazie mille, Scott.
ci sono solo un paio di domande, qui.
Immagino che faresti meglio a metterli in campo da soli.
– Va bene.
“stai dicendo di non persistere la chiave sul dispositivo,
come gestisci il cambio della password? “
Ce la puoi fare. Se vuoi vedere un esempio
di come fare questo, controlla la mia libreria Secure-Preferences
perché lo gestisco in questo, e così sarebbe
in un modo molto stupido
decifrare la libreria / codice
con la password esistente,
e quindi criptarlo nuovamente con l’altra password.
Non puoi farcela, perché quello è
modifica della password, non ti aiuta a far fronte
con se qualcuno ha dimenticato la password.
In tal caso, non è possibile decrittografare i dati.
Ecco perché lo vedo più come,
è davvero buono per il caching dei dati.
Ma non c’è modo di
trovando quella password, questo è il punto.
Ecco perché è il modo sicuro per farlo.
C’è un’altra domanda:
I collegamenti JavaScript in WebView sono sicuri da usare?
Questa è una buona domanda, non so se ho un
una risposta definitiva su questo.
Direi di no, mi sbaglierei dalla parte della cautela.
Sono sempre stato spaventato
cosa puoi fare con quello
È migliorato nell’API 17, con l’annotazione
che devi annotare esplicitamente i metodi
che puoi chiamare da JavaScript in Java.
Ma non l’ho usato
che vincola molto.
E c’è una domanda su …
about: Bootstrapping firmware in banda base
come vulnerabilità, reale o bufala?
Non conosco la risposta a questa domanda.
Qualcuno ha delle domande dal vivo,
prima di partire?
– [Voiceover] Puoi confrontare il Keystore
per password, digitare quello?
Ne hai mai usato uno?
– Sì. Una delle cose
Non ho avuto il tempo di parlare,
dal momento che Android 3.1, c’è
il Keystore Android, simile
per iOS Keychain, nel fatto che lo è,
è un posto dove puoi immagazzinare
un certificato. Sfortunatamente non lo è
come il portachiavi su iOS,
perché puoi semplicemente archiviare segreti arbitrari.
Su Android, devi memorizzare una chiave pubblica-privata,
e poi usarlo per crittografare altre cose.
Questo è venuto in Android 4.3,
e ci sono un paio di problemi con esso,
non essere coerenti
nel modo in cui si comporta;
se l’utente cambia il proprio PIN su alcune versioni di Android,
cancella semplicemente il Keystore e altre volte
dice ancora che è lì,
ma in realtà l’ha cancellato.
Uno dei miei amici ha scritto un articolo
chiamato “The Forgetful Keystore”.
Ha fatto una metrica
su quali versioni e quali cose diverse accadono,
perché ha iniziato a usarlo.
In termini di ciò è più sicuro,
sono basati sullo stesso principio.
Stanno usando qualcosa che l’utente inserisce,
che non memorizziamo sul dispositivo, per poi crittografarlo,
per generare una chiave che usiamo per fare la crittografia.
Vorrei che fossero più o meno uguali,
Preferisco semplicemente fare una crittografia basata su password
che internamente, con la mia app,
perché ne ho il controllo.
E inoltre, costringendo l’utente a inserirsi
un passcode o una password per la mia app,
quando è un’app sicura e c’è un punto in cui
è una vendita facile, ma
costringendo quell’utente ad avere un PIN, un codice di accesso,
quando non ne hanno uno, questo è il grande problema.
Questa è una vendita più grande, se sei una banca,
Penso che costringendo l’utente ad avere un codice PIN sul proprio dispositivo
è, probabilmente potresti farla franca,
ma altre app con cui penso ti farebbe davvero fatica.
Forse app aziendali,
probabilmente te la caverai pure,
ma questo è un grosso problema per l’utente.
Per essere chiari, per utilizzare il Keystore Android,
l’utente deve avere un codice PIN o un passcode abilitato,
e questa è la cosa fondamentale.
Devi forzarlo per l’intero dispositivo
piuttosto che solo la tua app; è per questo che tendo a preferire,
facendolo in-app,
ma è anche una buona soluzione.
Inoltre, se stai usando, se sei in una posizione fortunata
di poter scegliere come target l’API 17 e versioni successive,
che, non so se nessun altro
è in quella grande situazione, so che non lo sono.
Davvero una buona domanda.
– Ok, un’altra domanda.
– [Voce fuori campo] Ho appena guardato il sito Web di occultamento,
parte di questa libreria di Facebook,
e affermano che è super veloce.
Lavori con esso o lo fai
cosa fanno che lo rende molto più veloce,
o cosa sta succedendo –
– L’ho usato,
ed è piuttosto veloce, e usa
un paio degli algoritmi SSL aperti,
che sono veloci
Sta facendo codice nativo,
piuttosto che cosa fa SQLCipher
è in bundle l’intera libreria SSL aperta,
raggruppa semplicemente quegli algoritmi
e le cose di cui hai bisogno,
è per questo che è più veloce.
Non è così grande
un carico utile, in modo efficace.
In realtà, vale la pena menzionare,
L’ho menzionato nel discorso,
ma è una di quelle librerie di Facebook
che non ha la strana licenza su …
Ho dimenticato di cosa si tratta.
È commercialmente fattibile.
Freddo.
Brillante, grazie per quelle grandi domande,
e applaude di nuovo per essere venuto.
(applausi)
Please follow and like us: