[Seminario] [Difendere Dietro il dispositivo: Mobile Security Application]
 [Chris Wysopal] [Harvard University]
 [Questo è CS50.] [CS50.TV]
 

Buon pomeriggio. Il mio nome è Chris Wysopal.
 Io sono il CTO e co-fondatore di VeraCode.
 VeraCode è una società di sicurezza delle applicazioni.
 Testiamo tutti i tipi di applicazioni differenti,
 e quello che ho intenzione di parlare oggi è la sicurezza delle applicazioni mobile.
 Il mio background è ho fatto io la ricerca sulla sicurezza
 per un tempo molto lungo, probabilmente circa finché nessuno.
 Ho iniziato a metà degli anni '90,
 ed è stato un tempo che era abbastanza interessante perché
 abbiamo avuto un cambiamento di paradigma nella metà degli anni '90.
 Tutto computer di un tratto di tutti era collegato a Internet,
 e poi abbiamo avuto gli inizi di applicazioni web,
 ed è quello che mi sono concentrato su un terreno di allora.
 E 'interessante.
 Ora abbiamo un altro cambiamento di paradigma accadendo con l'informatica,
 che è il passaggio alle applicazioni mobili.
 

Mi sento una specie di tempo simile poi è stato alla fine degli anni '90
 quando stavamo indagando applicazioni web e di trovare difetti come
 errori di gestione sessione e SQL injection
 che in realtà non esisteva prima, e tutto ad un tratto si erano dappertutto
 in applicazioni web, e ora un sacco di tempo che trascorro
 sta guardando applicazioni mobili e guardando quello che sta succedendo là fuori nel selvaggio.
 Le applicazioni mobili sono davvero intenzione di essere la piattaforma informatica dominante,
 così abbiamo davvero bisogno di spendere un sacco di tempo, se sei nel settore della sicurezza
 incentrato su applicazioni web.
 Ci sono stati 29 miliardi di applicazioni mobili scaricate nel 2011.
 E 'previsto per essere di 76 miliardi di applicazioni entro il 2014.
 Ci sono 686 milioni i dispositivi che stanno per essere acquistati quest'anno,
 quindi questo è dove la gente va di fare
  la maggior parte del loro client computing andare avanti.
 

Stavo parlando con un vice presidente di Fidelity Investments
 un paio di mesi fa, e ha detto che appena visto più traffico
 fare transazioni finanziarie dalla loro base di clienti
 sulla loro applicazione mobile che sul loro sito web,
 quindi un uso comune per il Web, in passato è stato
 controllare le quotazioni di borsa, la gestione del portafoglio,
 e realmente stiamo vedendo che nel 2012 switch over
 per essere più dominante sulla piattaforma mobile.
 Certo, se non ci sara 'alcuna attività criminale,
 qualsiasi attività dannosa, che sta per iniziare a essere focalizzata sulla piattaforma mobile
 nel tempo come persone che commutano.
 Se si guarda alla piattaforma mobile,
 a guardare i rischi della piattaforma è utile scomposizione in diversi strati,
 proprio come si farebbe su un computer desktop,
 e si pensa i diversi strati, software, sistema operativo,
 livello di rete, livello di hardware, e, naturalmente, c'è vulnerabilità su tutti quegli strati.
 

La stessa cosa accade sul cellulare.
 Ma telefonia mobile, sembra che alcuni di questi strati sono peggio.
 Per uno, il livello di rete è più problematico sul cellulare
 perché un sacco di persone hanno nel loro ufficio oa casa
 cablata connessioni o hanno sicure connessioni Wi-Fi,
 e con un sacco di dispositivi mobili si è, ovviamente, al di fuori della casa
 o al di fuori della sede molto, e se si sta utilizzando la connessione Wi-Fi lì
 si potrebbero utilizzare una connessione Wi-Fi insicuro,
 qualcosa che è una connessione Wi-Fi pubblico,
 così quando pensiamo mobile apps dobbiamo prendere in considerazione
 che l'ambiente di rete è più rischioso per quelle applicazioni
 quando viene utilizzata la connessione Wi-Fi.
 E quando mi trovo in più dei rischi di applicazioni mobili
 capirete perché questo è più importante.
 Ci sono rischi a livello hardware su dispositivi mobili.
 Si tratta di un'area di ricerca in corso.
 La gente chiama questi attacchi a banda larga o attacchi in banda
 dove si sta attaccando il firmware che sta ascoltando alla radio.
 

Questi sono davvero spaventosi attacchi, perché
 l'utente non deve fare nulla.
 Si può colpire un sacco di dispositivi entro il raggio RF
 in una sola volta, e sembra che ogni volta che questa ricerca si propaga
 rapidamente viene classificato dove
 gente picchiata in giro e dicono: "Ecco, ci raccontano che, e vi prego di smettere di parlarne."
 Ci sono alcune ricerche in corso nel settore della banda larga,
 ma sembra essere hush hush molto.
 Penso che sia più di un tipo di Stato nazionale di ricerca che sta succedendo.
 Un'area di ricerca attiva, però, è lo strato di sistema operativo,
 e di nuovo, questo è diverso che nel mondo desktop computing
 perché nel settore mobile si dispone di questi gruppi di persone chiamate jailbreakers,
 e jailbreakers sono diverse da quelle ricercatori di vulnerabilità regolari.
 Stanno cercando di trovare le vulnerabilità del sistema operativo,
 ma la ragione che stanno cercando di trovare le vulnerabilità non è
 irrompere nella macchina di qualcun altro e compromettere esso.
 E 'per entrare nel proprio computer.
 

Vogliono entrare nel proprio cellulare, modificare il sistema operativo del proprio cellulare
 in modo che possano eseguire le applicazioni di loro scelta
 e cambiare le cose con le autorizzazioni amministrative complete,
 e non vogliono raccontare il fornitore di questo. Non sono come un ricercatore di sicurezza che è un bianco ricercatore di sicurezza cappello
 che sta per fare divulgazione responsabile e raccontare il venditore su di esso.
 Vogliono fare questa ricerca, e vogliono pubblicare realtà
 in un exploit o un rootkit o di un codice jailbreak,
 e vogliono farlo in modo strategico, come subito dopo
 le navi fornitore del nuovo sistema operativo.
 Hai questo rapporto conflittuale
 con vulnerabilità a livello di sistema operativo sul cellulare,
 che credo sia molto interessante, e un posto ci vedo
 si fa in modo che ci sia buon codice pubblicato sfruttare là fuori
 per le vulnerabilità a livello di kernel,
 e abbiamo visto quelli effettivamente essere utilizzato da autori di malware.
 E 'un po' diverso rispetto al mondo PC.
 E poi lo strato finale è lo strato superiore, il livello di applicazione.
 Questo è quello che ho intenzione di parlare oggi.
 

Gli altri strati esistono, e gli altri strati svolgono in esso,
 ma sto per lo più intenzione di parlare di quello che sta succedendo a livello di applicazione
 in cui il codice viene eseguito nella sandbox.
 Non ha privilegi amministrativi.
 Deve utilizzare le API del dispositivo,
 ma ancora, un sacco di attività dannose e un sacco di rischio possono accadere in quel livello
 perché questo è il livello in cui tutte le informazioni sono.
 Apps possono accedere a tutte le informazioni sul dispositivo
 se hanno i permessi giusti,
 e possono accedere ai diversi sensori sul dispositivo,
 Sensore GPS, microfono, fotocamera, quello che hai.
 Anche se stiamo parlando solo a livello di applicazione
 abbiamo un sacco di rischio c'è.
 L'altra cosa che è diverso l'ambiente mobile
 sono tutti i giocatori del sistema operativo, sia esso BlackBerry o Android
 o iOS o Windows Mobile, tutti hanno un bel modello di autorizzazione grana,
 e questo è uno dei modi che incorporate nel sistema operativo
 l'idea che non è così rischioso come si pensa.
 Anche se avete tutti i vostri contatti su lì, tutte le vostre informazioni personali,
 avete le vostre foto, avete la vostra posizione in là,
 stai memorizzare il PIN banca per il login automatico in là, è sicuro perché
 applicazioni devono avere determinate autorizzazioni per arrivare a talune parti
 delle informazioni sul dispositivo, e l'utente deve essere presentato con
 queste autorizzazioni e dire va bene.
 

Il problema è che l'utente dice sempre male.
 Come persona di sicurezza, so che è possibile richiedere all'utente,
 dire qualcosa di veramente brutto sta per accadere, vuoi che accada?
 E se siete di fretta o c'è qualcosa di veramente allettante sull'altro lato di questo,
 come un gioco sta per essere installato che stavate aspettando,
 andranno a fare clic su ok.
 Ecco perché io dico la mia presentazione qui fammelo scagliare gli uccelli a suini già,
 e si può vedere nella diapositiva qui ci sono esempi di una scatola di autorizzazione BlackBerry.
 Si dice "Vi preghiamo di impostare le autorizzazioni per le applicazioni BlackBerry di viaggio
 dopo Facendo clic sul pulsante in basso ", e fondamentalmente l'utente è solo andando a dire
 impostare le autorizzazioni e salvare.
 Ecco un prompt di Android, dove si vede le cose,
 e in realtà mette qualcosa che appare quasi come un avvertimento.
 E poi una sorta di segno di rendimento lì a dire la comunicazione di rete, telefonata,
 ma l'utente sta per fare clic su Installa, giusto?
 E poi l'Apple si è del tutto innocuo.
 Non fornisce alcun tipo di avvertimento.
 E 'solo di Apple vorrebbe usare la tua posizione attuale.
 Naturalmente si sta andando a fare clic su ok.
 

C'è questo modello di autorizzazione a grana fine,
 e apps avere un file manifesto in cui dichiarano
 le autorizzazioni di cui hanno bisogno, e che avranno mostrato all'utente,
 e l'utente dovrà dire che mi concedo queste autorizzazioni.
 Ma cerchiamo di essere onesti.
 Ci sono solo andando a dire sempre male.
 Diamo un rapido sguardo a le autorizzazioni che queste applicazioni siano chiedono
 e alcune delle autorizzazioni che ci sono.
 Questa società Praetorian fatto un sondaggio dello scorso anno
 di 53.000 applicazioni analizzate nei mercati mercato e 3rd party Android,
 quindi questo è tutto Android.
 E l'app media ha richiesto 3 autorizzazioni.
 Alcune applicazioni hanno chiesto 117 autorizzazioni,
 quindi ovviamente questi sono molto grana fine e troppo complesso per un utente a capire
 se sono presentati con questa applicazione che ha bisogno di questi 117 autorizzazioni.
 E 'come il contratto di licenza con l'utente finale che è lungo 45 pagine.
 Forse presto avranno un'opzione dove è come
 stampare le autorizzazioni e mandami una email.
 

Ma se si guarda ad alcune delle principali autorizzazioni interessanti
 Il 24% delle applicazioni che hanno scaricato fuori dal 53.000
 informazioni GPS richieste dal dispositivo.
 8% legge i contatti.
 4% ha inviato SMS, e il 3% ha ricevuto SMS.
 2% registrato l'audio.
 1% elaborato le chiamate in uscita.
 Non lo so.
 Non credo che il 4% delle applicazioni in App Store ha realmente bisogno di inviare messaggi di testo SMS,
 quindi penso che sia un indizio che qualcosa di spiacevole sta succedendo.
 8% delle applicazioni bisogno di leggere l'elenco dei contatti. Probabilmente non è necessario.
 Una delle altre cose interessanti su autorizzazioni è
 se si collega in librerie condivise nella vostra applicazione
 quelli che ereditano le autorizzazioni della domanda,
 quindi se la vostra applicazione ha bisogno l'elenco dei contatti o ha bisogno la posizione GPS di funzionare
 e si collega in una libreria di pubblicità, per esempio,
 tale libreria annuncio sarà anche in grado di accedere ai contatti
 e anche essere in grado di accedere alla posizione GPS,
 e lo sviluppatore dell'app non sa nulla del codice che si sta svolgendo in biblioteca annuncio.
 Stanno solo il collegamento che perché vogliono monetizzare le loro app.
 

Questo è dove e vi parlerò di alcuni esempi di questo con
 un'applicazione chiamata Pandora, dove uno sviluppatore di applicazioni
 potrebbero involontariamente essere fuga di informazioni
 dai loro utenti a causa delle biblioteche hanno legati dentro
 Esaminando il paesaggio là fuori, guardando a tutte le diverse applicazioni
 che sono stati riportati nelle notizie come utenti malintenzionati o fare qualcosa non volevano
 e quindi ispezionare un sacco di applicazioni, facciamo un sacco di analisi binario statico su applicazioni mobili,
 così li abbiamo ispezionati e guardato il codice stesso-
 siamo arrivati ​​a quello che noi chiamiamo la nostra top 10 dei comportamenti a rischio nelle applicazioni.
 Ed è suddiviso in 2 sezioni, codice dannoso,
 quindi queste sono cose cattive che le applicazioni potrebbero essere facendo che
 sono suscettibili di essere qualcosa che un utente non autorizzato
 ha in particolare messo nella domanda, ma è un po 'sfocata.
 Potrebbe essere qualcosa che uno sviluppatore pensa è bene,
 ma finisce per essere pensato come dannoso da parte dell'utente.
 

E poi la seconda sezione è quello che chiamiamo codifica vulnerabilità,
 e queste sono le cose in cui lo sviluppatore fondamentalmente sta facendo errori
 o semplicemente non capisce come scrivere l'applicazione in modo sicuro,
  e che sta mettendo l'utente app a rischio.
 Ho intenzione di passare attraverso questi nel dettaglio e fornire alcuni esempi.
 Per riferimento, ho voluto mettere l'OWASP cellulare top 10.
 Questi sono i 10 temi che un gruppo in OWASP,
 Progetto Open Web Application Security, hanno un gruppo di lavoro
 lavorando su un cellulare top 10.
 Hanno una molto famosa lista web top 10, che sono i primi 10
 le cose più rischiose si può avere in una applicazione web.
 Stanno facendo la stessa cosa per il mobile,
 e la loro lista è un po 'diversa dalla nostra.
 6 dei 10 sono uguali.
 Hanno 4 che sono diversi.
 Credo che abbiano un po 'di un approccio diverso su
 rischio nelle applicazioni mobili dove un sacco di loro problemi
 sono davvero come l'applicazione comunica con un server back-end
 o quello che sta succedendo sul server back-end,
 apps non tanto che hanno comportamenti a rischio che sono applicazioni client solo semplici.
 

Quelli in rosso qui sono le differenze tra le due liste.
 E alcuni del mio team di ricerca ha in realtà contribuito a questo progetto,
 quindi vedremo cosa succede nel corso del tempo, ma credo che il takeaway ecco
 noi non sappiamo quale sia la top 10 è in applicazioni mobili, perché
 hanno davvero stati solo in giro per 2 o 3 anni,
 e non c'è stato abbastanza tempo per la ricerca davvero i sistemi operativi
 e cosa sono capaci, e non c'è stato abbastanza tempo
 per la comunità dannoso, se si vuole, di aver trascorso abbastanza tempo
 cercando di attaccare gli utenti attraverso applicazioni mobili, quindi mi aspetto che queste liste per cambiare un po '.
 Ma per ora, queste sono le prime 10 cose di cui preoccuparsi.
 Si potrebbe chiedere sul lato mobile in cui funziona il codice dannoso cellulare
 come si ottiene al dispositivo?
 North Carolina State ha un progetto chiamato Progetto Genoma mobile malware
 dove si stanno raccogliendo quanto il malware mobile come possono e analizzarla,
 e hanno ripartiti i vettori di iniezione che il malware mobile utilizza,
 e il 86% utilizza una tecnica chiamata riconfezionamento,
 e questo è solo sulla piattaforma Android
 si può davvero fare questo riconfezionamento.
 

Il motivo è codice di Android è costruito con
 un byte code Java chiamata Dalvik che è facilmente riconvertibile.
 Che il cattivo può fare è
 prendere un'applicazione Android, decompilare,
 inserire il loro codice maligno, ricompilare,
 e poi metterlo in App Store che si presenta una nuova versione di tale domanda,
 o forse solo cambiando il nome dell'applicazione.
 Se era una specie di gioco, cambiare leggermente il nome,
 e quindi questo riconfezionamento è come l'86% del malware mobile viene distribuita.
 C'è un'altra tecnica chiamata aggiornamento che è
 molto simile al riconfezionamento, ma in realtà non mettere il codice maligno dentro
 Quello che fai è mettere in un piccolo meccanismo di aggiornamento.
 Si decompilare, si mette in un meccanismo di aggiornamento, e si ricompila esso,
 e poi quando l'applicazione è in esecuzione lo tira giù il malware sul dispositivo.
 

La stragrande maggioranza sono quei due tecniche.
 Non c'è davvero molto di download località di passaggio o download drive-by sui cellulari,
 che potrebbe essere come un attacco di phishing.
 Hey, controlla questo sito davvero cool,
 o avete bisogno di andare a questo sito e compilare questo modulo
 per mantenere continuare a fare qualcosa. Quelli sono gli attacchi di phishing.
 La stessa cosa può accadere sulla piattaforma mobile dove
 puntare a una applicazione mobile per scaricare, dire "Salve, questo è Bank of America."
 "Vediamo che si sta utilizzando questa applicazione."
 "Dovresti scaricare altre applicazioni."
 Teoricamente, che potrebbe funzionare.
 Forse semplicemente non viene utilizzato sufficiente per determinare se ha successo oppure no,
 ma hanno trovato che è utilizzato meno dell'1% delle volte quella tecnica.
 La maggior parte del tempo è davvero un codice riconfezionato.
 

C'è un'altra categoria chiamata standalone
 dove qualcuno solo costruisce un nuovissimo applicativo.
 Costruiscono una domanda che pretende di essere qualcosa.
 Non è un riconfezionamento di qualcos'altro, e che ha il codice dannoso.
 Che viene utilizzato il 14% del tempo.
 Ora voglio parlare di quello che sta facendo il codice dannoso?
 Uno dei primi malware in circolazione
 si potrebbe considerare uno spyware.
 Si spia fondamentalmente l'utente.
 Raccoglie e-mail, messaggi SMS.
 Si accende il microfono.
 Si raccoglie il libro di contatto, e lo invia via a qualcun altro.
 Questo tipo di spyware presente sul PC,
 quindi ha senso perfetto per le persone a cercare di fare questo su dispositivi mobili.
 

Uno dei primi esempi di questo era un programma chiamato Secret SMS Replicator.
 E 'stato nel Marketplace di Android un paio di anni fa,
 e l'idea era, se si ha avuto accesso al telefono Android di qualcuno
 che si voleva spiare, quindi forse è il vostro coniuge
 o il vostro altro significativo e si vuole spiare i loro messaggi di testo,
 è possibile scaricare questa applicazione e installarlo e configurarlo
 per inviare un messaggio SMS a voi con una copia
 di ogni messaggio SMS hanno ottenuto.
 Questo è ovviamente in violazioni dei termini app store di servizio,
 e questo è stato rimosso dal Marketplace di Android entro 18 ore dalla essere lì,
 così un numero molto piccolo di persone erano a rischio a causa di questo.
 Ora, penso che se il programma è stato chiamato qualcosa forse un po 'meno provocatorio
 come Segreto SMS Replicator probabilmente avrebbe funzionato molto meglio.
 Ma era abbastanza ovvio.
 

Una delle cose che possiamo fare per determinare se le applicazioni hanno questo comportamento che non vogliamo
 è per ispezionare il codice.
 Questo è in realtà molto facile da fare su Android perché possiamo decompilare le applicazioni.
 Su iOS è possibile utilizzare un disassembler come IDA Pro
 di guardare a ciò che le API app chiama e cosa sta facendo.
 Abbiamo scritto il nostro analizzatore statico binario per il nostro codice
 e lo facciamo, e quindi ciò che si potrebbe fare è che si possa dire
 fa il dispositivo fare qualcosa che è fondamentalmente spiando me o inseguimento?
 E ho alcuni esempi qui su iPhone.
 Questo primo esempio è come accedere al UUID al telefono.
 Questo è in realtà qualcosa che Apple ha appena bandito per le nuove applicazioni,
 ma le vecchie applicazioni che si potrebbe avere in esecuzione sul vostro telefono può ancora farlo,
 e in modo che identificatore unico può essere usato per rintracciare
 in molte applicazioni diverse.
 

Sulla Android, ho un esempio qui di ottenere la posizione del dispositivo.
 Si può vedere che se quella chiamata API è lì che app sta rintracciando,
 e si può vedere se si sta facendo bella posizione o luogo grossolani.
 E poi sul fondo qui, ho un esempio di come il BlackBerry
 un'applicazione può accedere ai messaggi e-mail nella tua casella di posta.
 Questi sono il genere di cose che si possono esaminare a vedere
 se l'applicazione sta facendo queste cose.
 La seconda grande categoria di comportamenti dannosi, e questo è probabilmente il più grande categoria ora,
 è telefonate non autorizzate, premium non autorizzato di messaggi di testo SMS
 o di pagamenti non autorizzati.
 Un'altra cosa che è unica per il telefono
 è il dispositivo è collegato a un account di fatturazione,
 e ove avvengono al telefono
 può creare oneri.
 È possibile acquistare le cose per telefono,
 e quando si invia un messaggio di testo SMS premium si sta effettivamente dando soldi
 al titolare del conto del numero telefonico sull'altro lato.
 Questi sono stati istituiti per ottenere le quotazioni di borsa o il tuo oroscopo del giorno o l'altro,
 ma possono essere impostati per ordinare un prodotto inviando un SMS.
 La gente dà i soldi alla Croce Rossa con l'invio di un messaggio di testo.
 Si può dare 10 dollari in quel modo.
 

Gli aggressori, quello che hanno fatto è hanno istituito
 conti in paesi stranieri, e incorporare nel malware
 che il telefono invierà un messaggio di testo SMS premium,
 dire, un paio di volte al giorno, e alla fine del mese ti accorgi di aver speso
 decine o forse anche centinaia di dollari, e se ne vanno con i soldi.
 Questo peggiorò a tal punto che questa era la prima cosa che Android
 Marketplace oppure Google luogo, è stato il Marketplace di Android, al momento,
 ed è ora Google Play-la prima cosa che Google ha iniziato controllando.
 Quando Google ha iniziato la distribuzione di applicazioni Android nella loro app store
 hanno detto che non stavano andando per verificare nulla.
 Ci tiriamo le applicazioni una volta siamo stati notificati hanno rotto i nostri termini di servizio,
 ma non stiamo andando a controllare nulla. Ebbene, circa un anno fa ha ottenuto così male con questo premio SMS messaggi di testo di malware
 che questa è la prima cosa hanno iniziato controllando.
 Se un'applicazione in grado di inviare messaggi di testo SMS
 si esaminano inoltre manualmente l'applicazione.
 Cercano le API che chiamano questo,
 e ora da allora Google ha ampliato,
 ma questa è stata la prima cosa che hanno iniziato cercando.
 

Alcune altre applicazioni che hanno fatto alcuni messaggi di testo SMS,
 questo Qicsomos Android, credo che si chiama.
 C'era questo evento corrente sul cellulare in cui questa CarrierIQ è venuto fuori
 come spyware mettere sul dispositivo dai vettori,
 così la gente voleva sapere se il loro telefono era vulnerabile a questo,
 e questo era un applicazione gratuita che ha testato questo.
 Beh, naturalmente, quello che questa applicazione ha fatto era inviato premium messaggi di testo SMS,
 così da test per vedere se sei stato infettato da spyware
 aver caricato il malware sul dispositivo.
 Abbiamo visto la stessa cosa accada all'ultimo Super Bowl.
 C'era una versione falsa della partita di calcio Madden
 che ha inviato premium messaggi di testo SMS.
 In realtà ha cercato di creare una rete bot troppo sul dispositivo.
 Qui ho alcuni esempi.
 È interessante notare che Apple è stata abbastanza intelligente,
 e non consentono alle applicazioni di inviare messaggi di testo SMS a tutti.
 Nessuna applicazione può farlo.
 Questo è un ottimo modo per sbarazzarsi di una intera classe di vulnerabilità,
 ma su Android si può fare, e, naturalmente, il BlackBerry si può fare troppo.
 E 'interessante che il BlackBerry è sufficiente disporre di autorizzazioni Internet
 per inviare un messaggio di testo SMS.
 

L'altra cosa davvero che cerchiamo
 quando stiamo cercando di vedere se qualcosa è dannoso è solo qualsiasi tipo di
 attività di rete non autorizzate, come cerca nella attività di rete
 l'applicazione si suppone di avere la sua funzionalità,
 e guardare a questa altre attività di rete.
 Forse un app, di lavorare, deve ottenere i dati su HTTP,
 ma se si tratta di fare le cose tramite e-mail o SMS o Bluetooth o qualcosa del genere
 ora che app potrebbe potenzialmente essere dannoso, quindi questa è un'altra cosa che si può verificare la presenza.
 E su questa diapositiva qui ho alcuni esempi.
 Un'altra cosa interessante che abbiamo visto con il malware è accaduto nel 2009,
 ed è successo in una grande strada.
 Non so se è successo così tanto da allora, ma era un app
 che impersona un'altra applicazione.
 Ci fu una serie di applicazioni, ed è stato soprannominato l'attacco 09Droid,
 e qualcuno ha deciso che c'erano un sacco di piccole, regionali, le banche medie
 che non avere applicazioni di online banking,
 così quello che hanno fatto è stato hanno costruito circa 50 applicazioni di online banking
 che tutti hanno fatto è stato prendere il nome utente e la password
 e reindirizzare l'utente verso il sito web.
 E così hanno messo tutti questi nel Marketplace di Google,
 nel Marketplace di Android, e quando qualcuno ricerche per vedere se la loro banca
 avuto un'applicazione che avrebbero trovato l'applicazione fasulla,
 che ha raccolto le loro credenziali e poi reindirizzati al loro sito web.
 Il modo in cui questa realtà è diventato-apps erano lì per un paio di settimane,
 e c'erano migliaia e migliaia di download.
 

Il modo in cui è venuto alla luce era qualcuno stava avendo un problema
 con una delle applicazioni, e hanno chiamato la loro banca,
 e hanno chiamato la linea di assistenza clienti della propria banca e disse,
 "Sto avendo un problema con l'applicazione di mobile banking".
 "Mi puoi aiutare?"
 Ed essi risposero: "Noi non abbiamo una applicazione di mobile banking".
 Che ha avviato l'inchiesta.
 Tale banca chiama Google, e quindi Google guardò e disse:
 "Wow, lo stesso autore ha scritto 50 applicazioni bancarie", e li ha giù.
 Ma certamente questo potrebbe accadere di nuovo.
 C'è l'elenco di tutte le diverse banche qui
 che facevano parte di questa truffa.
 L'altra cosa un app può fare è presente l'interfaccia utente di un'altra applicazione.
 Mentre è in esecuzione potrebbe apparire l'interfaccia utente di Facebook.
 Si dice che bisogna mettere il tuo nome utente e password per continuare
 o mettere qualsiasi nome utente e la password utente per un sito web
 che forse l'utente utilizza solo per cercare di ingannare l'utente
 nel mettere le loro credenziali dentro
 Questo è davvero un parallelo diritto degli attacchi e-mail di phishing
 dove qualcuno ti invia un messaggio di posta elettronica
 e ti dà fondamentalmente un utente falso per un sito web
 che si ha accesso.
 

L'altra cosa che cerchiamo in codice maligno è la modifica del sistema.
 Potete cercare per tutte le chiamate API che richiedono i privilegi di root
 per eseguire correttamente.
 Cambiare proxy Web del dispositivo sarebbe qualcosa che un'applicazione
 non dovrebbe essere in grado di fare.
 Ma se l'applicazione dispone di codice in là per farlo
 si sa che è probabilmente una un'applicazione dannosa
 o altamente probabile che sia un'applicazione dannosa,
 e così che cosa accadrebbe è che app avrebbe qualche modo di escalation di privilegi.
 Si avrebbe qualche escalation di privilegi exploit
 nella domanda, e poi una volta che l'escalation dei privilegi
 sarebbe fare queste modifiche del sistema. Potete trovare malware che ha scalata di privilegi
 in esso anche senza sapere come l'escalation di privilegi
 sfruttare sta per accadere, e questo è un bel modo semplice
 alla ricerca di malware.
 DroidDream è stato probabilmente il più famoso pezzo di malware Android.
 Penso che risente circa 250.000 utenti in pochi giorni
 prima che fosse trovato.
 Essi riconfezionati 50 applicazioni fasulle,
 metterli nel negozio Android app,
 ed essenzialmente ha usato il codice jailbreak Android per acquisire privilegi
 e poi installare un comando e controllo e girare tutte le vittime
 in una rete bot, ma si potrebbe avere individuato questo
 se tu fossi la scansione l'applicazione e solo in cerca di
 API chiede che i permessi di root necessari per eseguire correttamente.
 

E c'è un esempio qui ho che sta cambiando il proxy,
 e questo in realtà è disponibile solo su Android.
 Potete vedere sto dando un sacco di esempi su Android
 perché questo è dove l'ecosistema malware più attiva è
 perché è davvero facile per un utente malintenzionato di ottenere il codice dannoso
 nel Marketplace di Android.
 Non è così facile da fare che in Apple App Store
 perché Apple impone agli sviluppatori di identificarsi
 e firmare il codice.
 In realtà controllano chi sei, e Apple è in realtà scrutano le applicazioni.
 Noi non vediamo un sacco di vera minaccia in cui il dispositivo è sempre compromessa.
 Parlerò di alcuni esempi dove è davvero la privacy che è sempre compromessa,
 e questo è ciò che sta realmente accadendo sul dispositivo di Apple.
 Un'altra cosa da cercare il codice dannoso, il codice rischioso in dispositivi
 è logica o di tempo bombe e bombe a orologeria sono probabilmente
 molto più facile per cercare di bombe logiche.
 Ma con bombe a tempo, cosa si può fare è che si può cercare
 punti del codice in cui viene testato il tempo o un tempo assoluto è cercato
 prima di alcune funzionalità in app accade.
 E questo potrebbe essere fatto per nascondere tale attività da parte dell'utente,
 così sta accadendo a tarda notte.
 DroidDream ha fatto tutta la sua attività 11:00-08:00 ora locale
 per cercare di farlo mentre l'utente non potrebbe utilizzare il proprio dispositivo.
 

Un altro motivo per fare questo è che se la gente sta usando l'analisi del comportamento di un'applicazione,
 in esecuzione l'applicazione in una sandbox per vedere che cosa il comportamento della domanda è,
 possono utilizzare la logica basata sul tempo a svolgere l'attività
 quando l'applicazione non si trova nella sandbox.
 Ad esempio, un app store come Apple
 esegue l'applicazione, ma probabilmente non girano tutte le applicazioni per, diciamo, 30 giorni
 prima di approvarla, in modo da poter mettere
 la logica dell'applicazione che ha detto, va bene, solo fare la cosa brutta
 dopo 30 giorni è passato o dopo 30 giorni dalla data di pubblicazione della domanda,
 e che può aiutare a nascondere il codice dannoso da persone ispettive per esso.
 Se le aziende anti-virus sono in esecuzione le cose in sandbox
 o le app negozi stessi sono questo può aiutare
 nascondere che da quel controllo.
 Ora, il rovescio della medaglia è che è facile da trovare con l'analisi statica,
 quindi in realtà ispezionare il codice è possibile cercare tutti i posti
 in cui l'applicazione verifica il tempo e controllare in questo modo.
 E qui ho alcuni esempi su queste tre piattaforme diverse
 come il tempo può essere controllato dal creatore app
 in modo da sapere cosa cercare, se si sta controllando l'applicazione staticamente.
 

Ho appena passato attraverso un sacco di diverse attività dannose
 che abbiamo visto in natura, ma quali sono i più diffusi?
 Lo stesso studio della North Carolina State mobile Genome Project
 pubblicato alcuni dati, e ci sono stati fondamentalmente quattro aree
 che videro dove c'era un sacco di attività.
 37% delle applicazioni ha fatto escalation dei privilegi,
 così hanno avuto qualche tipo di codice jailbreak in là
 dove hanno cercato di acquisire privilegi in modo che potessero
 non comandi API esecuzione come sistema operativo.
 Il 45% delle applicazioni là fuori ha fatto SMS premium,
 così che è una percentuale enorme che sta cercando di monetizzare direttamente.
 Il 93% ha fatto telecomando, in modo hanno cercato di creare una rete di bot, una rete bot mobile.
 E il 45% raccolto informazioni di identificazione
 come numeri di telefono, UUID, posizione GPS, account utente,
 e questo aggiunge fino a più di 100 perché la maggior parte del malware tenta di fare alcune di queste cose.
 

Ho intenzione di passare alla seconda metà e parlare delle vulnerabilità del codice.
 Questa è la seconda metà dell'attività rischiosa.
 Questo è dove essenzialmente lo sviluppatore sta facendo errori.
 Un valido sviluppatore la scrittura di un app legittima
 sta facendo errori o è ignorante dei rischi della piattaforma mobile.
 Essi semplicemente non sanno come fare un app mobile sicura,
 o, talvolta, lo sviluppatore non si preoccupa di mettere l'utente al rischio.
 A volte parte del loro modello di business potrebbe essere
 la raccolta delle informazioni personali dell'utente.
 Questo è una sorta di altra categoria, e per questo motivo alcune di queste maligno
 contro inizia legittimi a sanguinare oltre perché non c'è differenza di opinioni
 tra ciò che l'utente vuole e ciò che l'utente considera rischiosa
 e ciò che lo sviluppatore dell'applicazione considera rischioso. Naturalmente, non è dati dello sviluppatore dell'applicazione nella maggioranza dei casi.
 

E poi, infine, un altro modo in cui questo accade è uno sviluppatore potrebbe collegare in
 una libreria condivisa che ha vulnerabilità o questo comportamento rischioso in esso
 a loro insaputa.
 La prima categoria è la perdita di dati sensibili,
 e questo è quando l'applicazione raccoglie informazioni
 come posizione, le informazioni della rubrica, informazioni proprietario
 e invia che spegne il dispositivo.
 Ed una volta che è spegnere il dispositivo, non sappiamo cosa sta accadendo con queste informazioni.
 Potrebbe essere memorizzato insicuro dallo sviluppatore dell'applicazione.
 Abbiamo visto gli sviluppatori di applicazioni vengono compromessi,
 ei dati che stanno memorizzazione viene scattata.
 Questo è accaduto un paio di mesi fa per uno sviluppatore in Florida
 dove un numero enorme di-era iPad UUID e nomi di dispositivo
 erano trapelate perché qualcuno, credo che fosse anonimo,
 ha affermato di fare questo, hanno fatto irruzione nella server di questo sviluppatore
 e ha rubato milioni di iPad UUID
 e nomi di computer.
 Non le informazioni più rischioso,
 ma se quella era la memorizzazione di nomi utente e password
 e indirizzi di casa?
 Ci sono un sacco di applicazioni che archiviano questo tipo di informazioni.
 Il rischio c'è.
 

L'altra cosa che può accadere è che se lo sviluppatore non prende cura
 per fissare il canale dati, e questo è un altro grande vulnerabilità ho intenzione di parlare,
 che i dati vengono inviati in chiaro.
 Se l'utente si trova su una rete Wi-Fi pubblico
 o qualcuno sta fiutando internet da qualche parte
 lungo il percorso che i dati vengono esposti.
 Un caso molto famoso di questa fuga di informazioni è successo con Pandora,
 e questo è qualcosa che abbiamo ricercato in VeraCode.
 Abbiamo sentito che c'era un credo che sia stato un Federal Trade Commission
 indagine in corso con Pandora.
 Abbiamo detto: "Che cosa sta succedendo lì? Cominciamo a scavare dentro l'applicazione Pandora."
 E quello che abbiamo determinato è stata l'applicazione Pandora raccolta
 il sesso e la tua età,
 ed è inoltre possibile accedere alla vostra posizione GPS, e l'applicazione Pandora
 fatto questo per quello che hanno detto erano motivi legittimi.
 La musica che stavano giocando, Pandora è un app-musica in streaming
 la musica che stavano giocando è stato autorizzato solo negli Stati Uniti,
 così hanno dovuto controllare per rispettare gli accordi di licenza che avevano
 per la musica che l'utente è stato negli Stati Uniti.
 Volevano anche di rispettare il Parental Advisory
 intorno linguaggio adulto nella musica,
 e quindi è un programma volontario, ma hanno voluto rispettare tale
 e non riprodurre testi espliciti ai bambini di 13 e sotto.
 

Avevano motivi legittimi per la raccolta di questi dati.
 La loro applicazione ha i permessi per farlo.
 Utenti pensato che questo era legittimo. Ma cosa è successo?
 Sono legati in 3 o 4 diverse biblioteche annunci.
 Ora, tutto ad un tratto tutte queste librerie di annunci
 sono ottenere l'accesso a queste stesse informazioni.
 Le librerie di annunci, se si guarda il codice nelle librerie di annunci
 quello che fanno è ogni biblioteca annuncio dice
 "La mia applicazione ha permesso di ottenere la posizione GPS?"
 "Oh, lo fa? Va bene, dimmi la posizione GPS."
 Ogni singola biblioteca annuncio lo fa,
 e se l'applicazione non dispone dell'autorizzazione GPS
 non sarà in grado di farlo, ma se lo fa, lo otterrà.
 Questo è dove il modello di business delle librerie di annunci
 si oppone alla privacy dell'utente.
 E ci sono stati studi là fuori che dirà se si conosce l'età
 di una persona e si sa la loro posizione
 dove dormire la notte, perché avete le coordinate GPS
 mentre forse dormono, si sa esattamente chi è quella persona
 perché è possibile determinare quale membro di quella famiglia è quella persona.
 Davvero questo è l'identificazione per gli inserzionisti
 esattamente chi sei, e sembra come se fosse legittimo.
 Voglio solo la mia musica in streaming, e questo è l'unico modo per farlo.
 

Beh, abbiamo esposto questo.
 Abbiamo scritto questo in molti post del blog,
 e si è scoperto che qualcuno dalla rivista Rolling Stone
 leggere uno dei nostri post sul blog e ha scritto il proprio blog su Rolling Stone su di esso,
 e il giorno dopo Pandora pensato che fosse una buona idea
 per rimuovere le librerie di annunci dalla loro applicazione.
 Per quanto ne so sono l'unico, che dovrebbero essere lodati.
 Penso che siano l'unico tipo freemium di app che ha fatto questo.
 Tutte le altre applicazioni freemium hanno questo stesso comportamento,
 quindi hai avuto modo di pensare a che tipo di dati si sta dando
 queste applicazioni freemium perché sta andando tutto per gli inserzionisti.
 Praetorian anche fatto uno studio sulle librerie condivise e disse:
 "Diamo un'occhiata a cosa librerie condivise sono le librerie condivise migliori", e questo era i dati.
 

Hanno analizzato 53.000 applicazioni,
 e il numero 1 libreria condivisa era Admob.
 In realtà è stato nel 38% delle applicazioni là fuori,
 così il 38% delle applicazioni che stai usando
 sono probabilmente la raccolta delle informazioni personali
 e l'invio alle reti pubblicitarie. Apache e Android erano l'8% e il 6%,
 e poi questi altri quelli giù in fondo, Google Ads, Flurry,
 Mob City e Millennial Media,
 queste sono tutte le imprese pubblicitarie, e quindi, abbastanza interessante,
 4% legato nella biblioteca Facebook
 probabilmente a che fare l'autenticazione tramite Facebook
 così l'applicazione potrebbe autenticare il Facebook.
 Ma questo significa anche la società Facebook controlla il codice
 che è in esecuzione nel 4% delle applicazioni mobili Android là fuori,
 e hanno accesso a tutti i dati che tale applicazione ha permesso di arrivare a.
 Facebook cerca essenzialmente di vendere spazi pubblicitari.
 Questo è il loro modello di business.
 

Se si guarda a questo intero ecosistema con queste autorizzazioni
 e librerie condivise si inizia a vedere che
 hai un sacco di rischio in un'applicazione apparentemente legittima.
 La stessa cosa simile che è accaduto con Pandora
 è successo con un'applicazione chiamata Path,
 e percorso pensato che venivano voti, sviluppatori amichevoli.
 Stavano solo cercando di darvi una grande esperienza utente,
 e si è scoperto che, senza chiedere conferma all'utente o raccontare l'utente nulla-
 e questo è successo su iPhone e su Android,
 Pandora app era su iPhone e Android-
 che l'applicazione Path è stato afferrando l'intera rubrica
 e caricarlo su Path solo quando si è installato ed eseguito l'applicazione,
 e non ti hanno detto su questo.
 Hanno pensato che fosse veramente utile per voi
 essere in grado di condividere con tutte le persone della vostra rubrica
 che si sta utilizzando l'applicazione Path.
 

Beh, ovviamente il percorso pensato che questo era ottimo per la loro azienda.
 Non così grande per l'utente.
 Dovete pensare che sia una cosa se forse un adolescente
 sta usando questa applicazione e le loro decine di amici sono lì,
 ma se è l'amministratore delegato di una società che installa Path
 e poi tutto ad un tratto tutta la loro rubrica è lassù?
 Stai andando a ottenere un sacco di informazioni di contatto potenzialmente preziose
 per un sacco di gente.
 Un giornalista del New York Times, si potrebbe essere in grado di ottenere il numero di telefono
 per gli ex presidenti dal loro rubrica,
 quindi ovviamente un sacco di informazioni sensibili viene trasferito con qualcosa di simile.
 C'era un grande lembo tale di questo che Path è scusato.
 Hanno cambiato la loro applicazione, e ancora influenzato Apple.
 Apple ha detto, "Stiamo andando a costringere i fornitori di app per richiedere agli utenti
 se andranno a raccogliere tutta la loro rubrica. "
 

Sembra che quello che sta succedendo qui è
 quando c'è una grande violazione della privacy e rende la stampa
 vediamo un cambiamento là fuori.
 Ma, naturalmente, ci sono altre cose là fuori.
 L'applicazione LinkedIn raccoglie le voci di calendario,
 ma Apple non rende l'utente viene invitato a tale proposito.
 Le voci del calendario possono avere informazioni sensibili anche in loro.
 Dove si sta andando a disegnare la linea?
 Questa è davvero una specie di luogo in evoluzione
 dove non c'è davvero nessun buon livello là fuori
 per gli utenti di capire quando le loro informazioni sta per essere a rischio
 e quando andranno a sapere che è in fase di presa.
 Abbiamo scritto un app a VeraCode chiamato Adios,
 ed essenzialmente ha permesso di puntare l'applicazione alla vostra directory di iTunes
 e guardare tutte le applicazioni che sono state la raccolta di tua rubrica completo.
 E come si può vedere in questa lista qui, Angry Birds,
 AIM, AroundMe.
 Perché la Angry Birds devono tua rubrica?
 Non lo so, ma lo fa in qualche modo.
 

Questo è qualcosa che molte, molte applicazioni fanno.
 È possibile esaminare il codice per questo.
 C'è API ben definite per iPhone, Android e BlackBerry
 per arrivare alla rubrica.
 Si può davvero facilmente ispezionare per questo, e questo è quello che abbiamo fatto nella nostra applicazione Adios.
 La categoria successiva, Unsafe Sensitive Data Storage,
 è qualcosa di cui gli sviluppatori prendono qualcosa come uno spillo o un numero di conto
 o una password e conservarla in chiaro sul dispositivo.
 Ancora peggio, potrebbero conservarlo in un'area al telefono
 che è accessibile a livello globale, come la scheda SD.
 Si vede più spesso su Android, perché Android permette una scheda SD.
 Dispositivi iPhone non lo fanno.
 Ma abbiamo anche visto che questo accada in una domanda di Citigroup.
 La loro applicazione online banking memorizzato i numeri di conto insicuro,
 solo in chiaro, quindi se avete perso il vostro dispositivo,
 in sostanza hai perso il tuo conto in banca.
 Questo è il motivo per cui io personalmente non faccio bancario sul mio iPhone.
 Penso che sia troppo rischioso in questo momento per fare questo tipo di attività.
 

Skype ha fatto la stessa cosa.
 Skype, ovviamente, ha un saldo del conto, un nome utente e una password
 che accedere a tale equilibrio.
 Erano l'archiviazione di tutte le informazioni in chiaro sul dispositivo mobile.
 Ho alcuni esempi qui di creazione di file
 che non hanno i permessi giusti o la scrittura su disco
 e non avendo avviene alcuna crittografia per questo.
 Questa zona successiva, Unsafe sensibili trasmissione di dati,
 Ho accennato a questo un paio di volte, ed a causa di Wi-Fi pubblico
 questo è qualcosa che apps assolutamente bisogno di fare,
 e questo è probabilmente ciò che vediamo sbagliare più. Direi, anzi, penso di avere i dati effettivi,
 ma è quasi la metà delle applicazioni mobili
 avvitare facendo SSL.
 Semplicemente non utilizzano le API correttamente.
 Voglio dire, tutto quello che devi fare è seguire le istruzioni e utilizzare le API,
 ma essi le cose come non verificare se vi sia un certificato non valido all'altra estremità,
 Non controllare se l'altra estremità sta cercando di fare un attacco protocollo downgrade.
 

Gli sviluppatori, vogliono ottenere la loro casella, giusto?
 La loro esigenza è quella di utilizzare questo per vendere. Hanno usato questo per vendere.
 Il requisito è di non usare questo per vendere in modo sicuro,
 e quindi questo è il motivo per cui tutte le applicazioni che utilizzano SSL per proteggere i dati
 mentre viene trasmesso spegnere il dispositivo davvero bisogno di essere ispezionato
 per assicurarsi che è stato attuato correttamente.
 E qui ho alcuni esempi dove è possibile vedere un'applicazione
 potrebbe essere utilizzando HTTP invece di HTTPS.
 In alcuni casi, applicazioni saranno ricadere HTTP
 se l'HTTPS non funziona.
 Ho un'altra chiamata qui su Android dove hanno disabilitato il controllo certificato,
 quindi un attacco di tipo man-in-the-middle può succedere.
 Sarà accettato un certificato non valido.
 Questi sono tutti i casi in cui gli attaccanti stanno per essere in grado di ottenere il
 la stessa connessione Wi-Fi come utente e accedere a tutti i dati
 che viene trasmesso su Internet.
 

E, infine, l'ultima categoria che ho qui è password hardcoded e le chiavi.
 Noi in realtà vediamo un sacco di sviluppatori utilizzano lo stesso stile di codifica
 che hanno fatto quando stavano costruendo applicazioni server web,
 così stanno costruendo un'applicazione server Java, e stanno hardcoding la chiave.
 Beh, quando si sta costruendo un'applicazione server, sì,
 hardcoding la chiave non è una buona idea.
 Essa rende difficile cambiare.
 Ma non è così male sul lato server perché chi ha accesso al lato server?
 Solo gli amministratori.
 Ma se si prende lo stesso codice e si versa sopra a una applicazione mobile
 ora tutti coloro che hanno tale applicazione mobile ha accesso a quella chiave hardcoded,
 e abbiamo effettivamente vedere questo un sacco di volte, e ho alcune statistiche
 come spesso vediamo che questo accada.
 In realtà era in esempio di codice che MasterCard ha pubblicato
 su come utilizzare il loro servizio.
 Il codice di esempio ha fatto vedere come si sarebbe solo prendere la password
 e metterlo in una stringa hardcoded proprio lì,
 e sappiamo come gli sviluppatori amano copiare e incollare frammenti di codice
 quando stanno cercando di fare qualcosa, in modo da copiare e incollare il frammento di codice
 che hanno dato come esempio di codice, e si dispone di un'applicazione insicuro.
 

E qui abbiamo alcuni esempi.
 Questo primo è uno vediamo un sacco dove hardcode
 il diritto di dati in un URL che viene inviato.
 A volte vediamo stringa password = la password.
 Questo è abbastanza facile da rilevare, o la password stringa su BlackBerry e Android.
 In realtà è abbastanza facile da controllare perché quasi sempre
 i nomi sviluppatore la variabile che sta tenendo la password
 qualche variazione di password.
 Ho detto che noi facciamo analisi statica a VeraCode,
 così abbiamo analizzato diverse centinaia di applicazioni Android e iOS.
 Abbiamo costruito modelli completi di loro, e siamo in grado di eseguire la scansione di loro
 per le diverse vulnerabilità, in particolare le vulnerabilità di cui parlavo,
 e ho alcuni dati qui.
 68,5% delle applicazioni Android abbiamo guardato
 si era rotto il codice crittografico,
 che per noi, non possiamo rilevare se hai fatto una propria routine di crittografia,
 non che sia una buona idea, ma questo è in realtà utilizza le API pubblicate
 che sono sulla piattaforma ma loro facendo in modo
 che la crypto sarebbe vulnerabile, 68.5.
 E questo è per le persone che ci stanno inviando le loro domande in realtà perché
 pensano che sia una buona idea per fare test di sicurezza.
 Queste sono già persone che stanno probabilmente pensando in modo sicuro,
 quindi è probabilmente anche peggio.
 

Io non parlo di linea di controllo dell'iniezione di alimentazione.
 E 'qualcosa che controlliamo per, ma non è così rischioso un problema.
 Perdita di informazioni, questo è dove vengono inviati i dati sensibili spegnere il dispositivo.
 Abbiamo trovato che nel 40% delle applicazioni.
 Il tempo e lo stato, questi sono problemi razziali condizione di tipo, in genere piuttosto difficile da sfruttare,
 quindi non ho parlato di questo, ma abbiamo guardato.
 Il 23% ha avuto problemi di SQL injection.
 Un sacco di gente non sa che un sacco di applicazioni
 utilizzare un piccolo piccolo database SQL sul back-end per memorizzare i dati.
 Beh, se i dati che si sta prendendo in rete
 ha stringhe SQL injection in esso
 qualcuno può compromettere il dispositivo mediante la,
 e quindi penso che trovare circa il 40% delle applicazioni web hanno questo problema,
 che è un problema enorme epidemia.
 Troviamo il 23% del tempo in applicazioni mobili
 e questo è probabilmente perché molte altre applicazioni web utilizzano SQL che mobile.
 

E poi vediamo ancora qualche cross-site scripting, problemi di autorizzazione,
 e poi gestione delle credenziali, è lì che hai la tua password hardcoded.
 In 5% delle applicazioni vediamo che.
 E poi abbiamo alcuni dati relativi iOS.
 81% ha avuto problemi di gestione degli errori. Questo è più di un problema di qualità del codice,
 ma il 67% ha avuto problemi di crittografia, quindi non è così male come Android.
 Forse le API sono un po 'più facile, i codici di esempio un po' meglio su iOS.
 Ma ancora una percentuale molto alta.
 Abbiamo avuto il 54% di perdita di informazioni,
 circa il 30% con errori di gestione di buffer.
 Ecco i luoghi dove ci potrebbe potenzialmente essere un problema di corruzione della memoria.
 Si scopre che non è tanto di un problema di sfruttamento
 su iOS perché tutto il codice deve essere firmato,
 quindi è difficile per un utente malintenzionato di eseguire codice arbitrario su iOS.
 Qualità del codice, directory traversal, ma poi la gestione delle credenziali qui al 14,6%,
 così peggio che su Android.
 Abbiamo gente non la corretta password.
 E poi gli errori numerici e buffer overflow,
 quelli sono più andando essere problemi di qualità del codice di iOS.
 

Questo è tutto per la mia presentazione. Non so se siamo fuori tempo o no.
 Non so se ci sono domande.
 [Maschio] Una domanda veloce intorno frammentazione e il mercato Android.
 Apple ha almeno possiede patch.
 Fanno un buon lavoro di ottenere là fuori che meno nello spazio Android.
 È quasi bisogno di jailbreak il telefono per rimanere aggiornati
 con la versione corrente di Android.
 Sì, è un problema enorme e quindi se ci pensate-
 [Maschio] Perché non hai ripetere?
 

Oh, giusto, quindi la domanda è per quanto riguarda la frammentazione
 del sistema operativo sulla piattaforma Android?
 In che modo questo influisce sulla rischiosità di questi dispositivi?
 Ed in realtà è un problema enorme, perché ciò che accade è
 i dispositivi più vecchi, quando qualcuno esce con un jailbreak per quel dispositivo,
 in sostanza, che è scalata di privilegi, e fino a che il sistema operativo sia aggiornato
 qualsiasi malware può quindi utilizzare tale vulnerabilità per compromettere completamente il dispositivo,
 e quello che stiamo vedendo in Android è al fine di ottenere un nuovo sistema operativo
 Google deve mettere il sistema operativo, e quindi il produttore dell'hardware
 ha da personalizzare, e quindi il vettore deve personalizzare e consegnarla.
 Che, fondamentalmente, tre parti in movimento qui,
 e si sta rivelando che i vettori non importa,
 ed i produttori di hardware non interessa, e Google non è pungolo abbastanza
 di fare qualcosa, così essenzialmente oltre la metà dei dispositivi là fuori
 disporre di sistemi operativi che hanno queste vulnerabilità escalation di privilegi in loro,
 e quindi se si ottiene malware sul vostro dispositivo Android è molto più di un problema.
 

Ok, vi ringrazio molto.
 [Applausi]
 [CS50.TV]