[Seminari] [Defensant Darrere del dispositiu: Application Security Mobile]
 [Chris Wysopal] [Universitat de Harvard]
 [Aquest és CS50.] [CS50.TV]
 

Bona tarda. El meu nom és Chris Wysopal.
 Sóc el director de tecnologia i cofundador de Veracode.
 Veracode és una empresa de seguretat de l'aplicació.
 Provem tot tipus d'aplicacions diferents,
 i el que vaig a parlar avui és la seguretat d'aplicacions mòbils.
 La meva experiència és que he estat fent la investigació sobre seguretat
 durant molt de temps, probablement gairebé tan llarg com el que més.
 Vaig començar a mitjans dels anys 90,
 i va ser un temps en què era bastant interessant perquè
 vam tenir un canvi de paradigma en els mitjans dels anys 90.
 Tot l'equip d'un tot sobtat estava connectat a Internet,
 i després vam tenir l'inici de les aplicacions web,
 i això és el que m'he centrat en molt llavors.
 És interessant.
 Ara tenim un nou canvi de paradigma passant amb la informàtica,
 que és el canvi a les aplicacions mòbils.
 

Sento que és una espècie de temps similar i després va ser a finals dels anys 90
 quan estàvem investigant les aplicacions web i la recerca de defectes com
 errors d'administració de sessions i d'injecció SQL
 que en realitat no existia abans, i, de sobte, estaven per tot arreu
 en les aplicacions web, i ara una gran part del temps que pas
 està mirant a les aplicacions mòbils i mirant al que està passant allà fora en el salvatge.
 Les aplicacions mòbils són realment serà la plataforma informàtica dominant,
 pel que realment hem de gastar un munt de temps si vostè està en la indústria de la seguretat
 centrant-se en les aplicacions web.
 Hi va haver 29000000000 d'aplicacions mòbils descarregats el 2011.
 Es preveu de ser de 76000000000 d'aplicacions per a l'any 2014.
 Hi ha 686 milions de dispositius que es compraran aquest any,
 de manera que aquest és el lloc on la gent va a estar fent
  la major part de la seva informàtica de client en el futur.
 

Jo estava parlant amb un vicepresident de Fidelity Investments
 Fa un parell de mesos, i em va dir que acaben de veure més trànsit
 fer transaccions financeres des de la base de clients
 en la seva aplicació mòbil que a la seva pàgina web,
 de manera que un ús comú del web en el passat ha estat
 la comprovació de les seves cotitzacions d'accions, la gestió de la seva cartera,
 i que en realitat estem veient que el 2012 més d'interruptor
 a ser més dominant a la plataforma mòbil.
 Certament, si no hi haurà cap activitat criminal,
 qualsevol activitat maliciosa, que començarà a centrar-se en la plataforma mòbil
 amb el temps com la gent canvia a això.
 Si ens fixem en la plataforma mòbil,
 mirar els riscos de la plataforma és útil per desglossar en les diferents capes,
 igual que ho faria en un ordinador d'escriptori,
 i es pensa en les diferents capes, programari, sistema operatiu,
 capa de xarxa, capa de maquinari, i per descomptat, hi ha vulnerabilitats en totes aquestes capes.
 

El mateix succeeix en el mòbil.
 Però el mòbil, sembla que algunes d'aquestes capes estan en pitjor situació.
 D'una banda, la capa de xarxa és més problemàtica al mòbil
 perquè molta gent té a la seva oficina oa casa
 cablejat o les connexions que tenen connexions segures Wi-Fi,
 i amb una gran quantitat de dispositius mòbils que està, òbviament fora de la casa
 o fora de l'oficina molt i si estàs fent servir Wi-Fi no
 es podria estar utilitzant una connexió Wi-Fi insegura,
 cosa que és un públic de connexió Wi-Fi gratuïta,
 així que quan pensem en aplicacions mòbils que hem de tenir en compte
 que l'entorn de xarxa és més arriscat per a les aplicacions
 quan s'està utilitzant Wi-Fi.
 I quan em fico en diversos dels riscos d'aplicacions mòbils
 veuràs per què això és més important.
 Hi ha riscos a nivell de maquinari en els dispositius mòbils.
 Aquesta és una àrea de recerca en curs.
 La gent crida a aquests atacs de banda ampla o atacs de banda base
 on s'està atacant el firmware que està escoltant a la ràdio.
 

Aquests són realment atacs de por perquè
 l'usuari no ha de fer res.
 Vostè pot colpejar un munt de dispositius en la gamma de RF
 alhora, i sembla que cada vegada que aquesta investigació es propaga cap amunt
 ràpidament es classifica en el
 gent sola vegada en la volta i dir: "Aquí, ens diuen sobre això, i si us plau deixin de parlar-ne."
 Hi ha una mica de recerca en curs en l'àrea de la banda ampla,
 però sembla ser Hush Hush molt.
 Crec que és més d'un tipus d'Estat-nació de la investigació que està passant.
 Una àrea d'investigació activa, però, és la capa del sistema operatiu,
 i de nou, això és diferent que en el món de la computació d'escriptori
 perquè en l'espai mòbil té aquests equips de persones anomenats Jailbreakers,
 i Jailbreakers són diferents que els investigadors de vulnerabilitats regulars.
 Estan tractant de trobar vulnerabilitats en el sistema operatiu,
 però la raó per la qual estan tractant de trobar les vulnerabilitats no és
 entrar a la màquina d'una altra persona i comprometre.
 És entrar en el seu propi ordinador.
 

Volen entrar en el seu propi mòbil, modificar el sistema operatiu del seu propi mòbil
 perquè puguin executar les aplicacions de la seva elecció
 i canviar les coses amb els permisos administratius,
 i ells no volen dir-li al venedor sobre això. No són com un investigador de seguretat que és un investigador de seguretat barret blanc
 que es va a fer d'una font responsable i dir-li al venedor sobre això.
 Ells volen fer aquesta investigació, i que volen publicar en realitat
 en una explotació o un rootkit o un codi de fuga de la presó,
 i volen fer-ho estratègicament com just després del
 les naus de proveïdors del nou sistema operatiu.
 Vostè té aquesta relació de confrontació
 amb vulnerabilitats a nivell de sistema operatiu al mòbil,
 que crec que és bastant interessant, i un lloc on veig
 es ho fa perquè hi hagi un bon codi publicat explotar per aquí
 a la recerca de vulnerabilitats a nivell de nucli,
 i hem vist els realment ser utilitzat pels creadors de malware.
 És una mica diferent que el món del PC.
 I a continuació, la capa final és la capa superior, la capa d'aplicació.
 Això és el que vaig a parlar avui.
 

Existeixen les altres capes, i les altres capes exerceixen en ell,
 però jo estic majoritàriament va a parlar sobre el que està passant a la capa d'aplicació
 on el codi s'executa en l'entorn limitat.
 No té privilegis administratius.
 S'ha d'utilitzar les API del dispositiu,
 però tot i així, una gran quantitat d'activitats malicioses i una gran quantitat de risc poden ocórrer en aquesta capa
 perquè aquesta és la capa on tota la informació està.
 Les aplicacions poden accedir a tota la informació en el dispositiu
 si tenen els permisos adequats,
 i poden accedir als diferents sensors en el dispositiu,
 Sensor de GPS, micròfon, càmera, el que vostè té.
 Tot i que només estem parlant de la capa d'aplicació
 tenim una gran quantitat de risc allà.
 L'altra cosa que és diferent en l'entorn mòbil
 és que tots els jugadors del sistema operatiu, ja sigui BlackBerry o Android
 o iOS o Windows Mobile, tots ells tenen un model de permisos de gra fi,
 i aquesta és una de les formes en què construeixen en el sistema operatiu
 la idea que no és tan arriscat com sembla.
 Tot i que té tots els seus contactes en allà, tota la seva informació personal,
 vostè té les seves fotos, vostè té la seva ubicació en allà,
 vostè està emmagatzemant la seva pin bancària per a inici de sessió automàtic de l'existència, és segur perquè
 aplicacions han de tenir certs permisos per arribar a certes parts
 de la informació en el dispositiu, i l'usuari ha de ser presentada amb
 aquests permisos i diuen bé.
 

El problema amb això és que l'usuari sempre diu bé.
 Com una persona de seguretat, sé que vostè pot demanar a l'usuari,
 dir alguna cosa molt dolent passarà, és el que vols que passi?
 I si estan en un compromís o hi ha alguna cosa realment atractiu a l'altra banda d'això,
 com un joc es va a instal · lar que han estat esperant,
 que van a fer clic bé.
 És per això que dic en el meu diapositiva aquí només vull llançar ocells als porcs ja,
 i es pot veure a la diapositiva aquí hi ha exemples d'una caixa permís BlackBerry.
 Diu: "Si us plau, estableix els permisos de l'aplicació BlackBerry Travel
 després de fer clic al botó de baix ", i, bàsicament, l'usuari és només dirà
 establir els permisos i guardar.
 Heus aquí un símbol de l'Android en el qual mostra les coses,
 i que en realitat posa una cosa que gairebé sembla una advertència.
 Té una mena de senyal de cedir allà dient comunicació de xarxa, trucada de telèfon,
 però l'usuari s'instal · larà, feu clic a, oi?
 I llavors el d'Apple és completament innocu.
 No dóna cap tipus d'advertència.
 És només d'Apple li agradaria utilitzar la seva ubicació actual.
 Per descomptat que faràs clic bé.
 

No és aquest model de permisos de gra fi,
 i les aplicacions han de tenir un fitxer de manifest en el qual declaren
 els permisos que necessiten, i que aconseguiran que es mostra a l'usuari,
 i l'usuari haurà de dir que em concedeixo aquests permisos.
 Però siguem honestos.
 Els usuaris són només dirà sempre bé.
 Fem un ràpid cop d'ull als permisos que aquestes aplicacions estan demanant
 i alguns dels permisos que hi són.
 Aquesta empresa pretoriana va fer una enquesta de l'any passat
 de 53.000 aplicacions analitzades en els mercats del mercat i de 3 ª part per Android,
 així que això és tot Android.
 I l'aplicació mitjana va demanar 3 permisos.
 Algunes aplicacions van sol · licitar 117 permisos,
 de manera que, òbviament, aquests són de gra molt fi i massa complex per a un usuari a entendre
 si se'ls presenten amb aquesta aplicació que necessita aquests 117 permisos.
 És com l'acord de llicència d'usuari final que és 45 pàgines de llarg.
 Potser aviat tindran una opció on se sent
 imprimir els permisos i enviar-me un correu electrònic.
 

Però si ens fixem en alguns dels millors permisos interessants
 24% de les aplicacions que es descarreguen de la 53000
 la informació del GPS sol · licitat des del dispositiu.
 8% llegeix els contactes.
 4% enviament de SMS, i 3% de SMS rebut.
 2% l'àudio gravat.
 1% processa les trucades sortints.
 No.
 No crec que el 4% de les aplicacions disponibles a la botiga d'aplicacions que necessita per enviar missatges de text SMS,
 així que crec que això és un indici que alguna cosa dolenta està passant.
 8% de les aplicacions necessita llegir la llista de contactes. Probablement no sigui necessari.
 Una altra de les coses interessants sobre els permisos és
 si enllaça a les biblioteques compartides en la seva aplicació
 els hereten els permisos de l'aplicació,
 així que si la seva aplicació necessita la llista de contactes o necessita la ubicació GPS per funcionar
 i vincular en una biblioteca de la publicitat, per exemple,
 que biblioteca anunci també serà capaç d'accedir als contactes
 i també ser capaç d'accedir a la ubicació del GPS,
 i el desenvolupador de l'aplicació no sap res sobre el codi que hi ha a la biblioteca anunci.
 Només estan vinculació que perquè volen obtenir beneficis econòmics de la seva aplicació.
 

Aquí és on-i vaig a parlar d'alguns exemples d'això amb
 una aplicació anomenada Pandora, on un desenvolupador d'aplicacions
 podria ser, sense saber-ho, la filtració d'informació
 dels seus usuaris a causa de les biblioteques que han vinculades polz
 Topografia del paisatge per aquí, mirant totes les diferents aplicacions
 que s'han reportat en les notícies com una cosa que els usuaris malintencionats o fer que no volien
 i després d'inspeccionar una gran quantitat d'aplicacions-que fem un munt d'anàlisi binari estàtic en aplicacions mòbils,
 de manera que els hem inspeccionat i mirem el codi en si mateix-
 se'ns va ocórrer el que anomenem la nostra llista dels 10 comportaments de risc en les aplicacions.
 I es divideix en 2 seccions, el codi maliciós,
 així que aquestes són les coses dolentes que les aplicacions podrien estar fent que
 és probable que sigui una cosa que un individu malintencionat
 ha posat específicament en l'aplicació, però és una mica difusa.
 Podria ser una cosa que un desenvolupador pensa està bé,
 però acaba sent considerat com maliciós per l'usuari.
 

I després la segona secció és el que anomenem les vulnerabilitats de codificació,
 i aquestes són les coses que el desenvolupador bàsicament està cometent errors
 o simplement no entén com escriure de forma segura l'aplicació,
  i això és posar l'usuari de l'aplicació en risc.
 Vaig a anar a través d'aquests punts en detall i donar alguns exemples.
 Com a referència, jo volia posar la llista mòbil top 10 OWASP.
 Aquests són els 10 temes que un grup de la OWASP,
 Projecte Obrir Web Application Security, que té un grup de treball
 treballant en una llista dels 10 mòbil.
 Tenen una molt famosa llista superior del drap 10, que són els 10 primers
 les coses més arriscades que poden tenir en una aplicació web.
 Estan fent el mateix per a mòbils,
 i la seva llista és una mica diferent a la nostra.
 6 de la 10 són el mateix.
 Tenen 4 que són diferents.
 Crec que tenen una mica d'una opinió diferent sobre
 risc en aplicacions mòbils on molts dels seus temes
 són realment la forma en l'aplicació es comunica amb un servidor back-end
 o el que està passant al servidor back-end,
 no tant les aplicacions que tenen conductes de risc que són aplicacions client simplement senzill.
 

Els que estan en vermell aquí són les diferències entre les 2 llistes.
 I part del meu equip d'investigació ha contribuït realment a aquest projecte,
 així que ja veurem què passa amb el temps, però crec que el menjar per emportar aquí és
 nosaltres no sabem realment el que la llista dels 10 està en les aplicacions mòbils, ja
 realment han estat només al voltant de 2 a 3 anys,
 i no hi ha hagut temps suficient per investigar realment els sistemes operatius
 i el que són capaços de, i no hi ha hagut temps suficient
 per a la comunitat maliciós, si es vol, que ha passat prou temps
 tractar d'atacar als usuaris a través d'aplicacions mòbils, de manera que espero que aquestes llistes canvien una mica.
 Però per ara, aquests són els 10 millors coses de què preocupar-se.
 Vostè podria preguntar-se pel costat mòbil, on fa el codi mòbil maliciós
 com arriba al dispositiu?
 North Carolina State té un projecte anomenat Projecte Genoma Mobile malware
 on s'estan recollint la major quantitat de malware mòbil com poden i la seva anàlisi,
 i han enderrocat els vectors d'injecció que utilitza el malware per a mòbils,
 i el 86% utilitza una tècnica anomenada reenvasament,
 i això és només en la plataforma Android
 Pot vostè realment fer això reenvasat.
 

La raó és el codi d'Android està construït amb
 un codi de bytes de Java anomenada Dalvik que és fàcilment decompilable.
 El que el dolent de la pel · lícula pot fer és
 tenir una aplicació per Android, descompilar,
 afegir-li el codi maliciós, recompilar,
 i després el va posar en l'App Store que pretén ser una nova versió d'aquesta aplicació,
 o només potser canviar el nom de l'aplicació.
 Si es tractava d'una mena de joc, canviar el nom una mica,
 de manera que aquest reenvasament és com el 86% del malware mòbil es distribueix.
 Hi ha una altra actualització tècnica trucada que
 molt similar al reenvasament, però en realitat no posa el codi maliciós polz
 El que fa és posar en un petit mecanisme d'actualització.
 Vostè descompilar, vostè posa en un mecanisme d'actualització, i torni a compilar ella,
 i després, quan l'aplicació s'està executant, es baixa el programari maliciós en el dispositiu.
 

La gran majoria són aquestes 2 tècniques.
 En realitat no hi ha molt de descàrrega drive-bys o descàrregues drive-by en els mòbils,
 el que podria ser com un atac de phishing.
 Escolta, fes un cop d'ull a aquest lloc realment genial,
 o has d'anar a aquest lloc web i omplir aquest formulari
 per mantenir constant fent alguna cosa. Aquests són els atacs de phishing.
 El mateix pot passar a la plataforma mòbil on
 apuntar a una aplicació mòbil per a descarregar, dir "Hola, això és Bank of America."
 "Veiem que utilitzeu aquesta aplicació."
 "Vostè ha de descarregar aquesta altra aplicació."
 En teoria, això podria funcionar.
 És possible que simplement no s'utilitza prou com per determinar si és correcta o no,
 però es van trobar que s'utilitza menys d'1% del temps que la tècnica.
 La majoria de les vegades és realment un codi de reenvasament.
 

Hi ha una altra categoria anomenada independent
 on algú construeix una aplicació nova.
 Construeixen una aplicació que pretén ser alguna cosa.
 No és un nou embolcall d'una altra cosa, i que té el codi maliciós.
 Que s'utilitza el 14% del temps.
 Ara vull parlar del que està fent el codi maliciós?
 Un dels primers malware que hi ha
 vostè podria considerar un spyware.
 Bàsicament espia a l'usuari.
 Recull correus electrònics, missatges SMS.
 S'encén el micròfon.
 Recull la llibreta de contactes, i l'envia a una altra persona.
 Aquest tipus de programari espia existent al PC,
 així que té sentit perfecte per a les persones que tracten de fer això en els dispositius mòbils.
 

Un dels primers exemples d'això va ser un programa anomenat Secret SMS replicador.
 Va ser en el mercat Android fa un parell d'anys,
 i la idea era si tenia accés a telèfon Android d'algú
 que volia espiar, per la qual cosa potser és el seu cònjuge
 o la seva parella i vol espiar als seus missatges de text,
 vostè pot descarregar aquesta aplicació i instal · lar i configurar
 per enviar un missatge de text SMS a vostè amb una còpia
 de cada missatge de text SMS que van aconseguir.
 Això, òbviament, està en violacions dels termes botiga d'aplicacions de servei,
 i això va ser retirat de la del mercat androide termini de 18 hores que hi sigui,
 de manera que un nombre molt petit de persones que estaven en situació de risc a causa d'això.
 Ara, crec que si el programa es deia alguna cosa potser una mica menys provocativa
 com Secret SMS replicador probablement hauria funcionat molt millor.
 Però era una mica obvi.
 

Una de les coses que podem fer per determinar si les aplicacions tenen aquest comportament que no volem
 és inspeccionar el codi.
 Això és realment molt fàcil de fer en Android, ja que podem descompondre les aplicacions.
 En iOS pot usar un desensamblador, com ANADA Pro
 mirar el que les API de l'aplicació està trucant i el que està fent.
 Escrivim el nostre propi analitzador estàtic binari per al nostre codi
 i ho fem, i així el que podria fer és que es pot dir
 ¿El dispositiu de fer tot el que està bàsicament espiant a mi o em seguiment?
 I tinc alguns exemples aquí a l'iPhone.
 Aquest primer exemple és com accedir a la UUID al telèfon.
 Això és realment una cosa que Apple acaba de prohibir per a noves aplicacions,
 però les aplicacions antigues que vostè pot ser que s'estiguin executant al telèfon encara es pot fer això,
 i de manera que l'identificador únic pot ser usat per rastrejar vostè
 en moltes aplicacions diferents.
 

En l'Android, tinc aquí un exemple d'obtenir la ubicació del dispositiu.
 Es pot veure que si aquesta crida a l'API és allà on l'aplicació és el seguiment,
 i es pot veure si es tracta d'obtenir la ubicació per bé o ubicació gruixuda.
 I després a la part inferior aquí, tinc un exemple de com al BlackBerry
 una aplicació pot accedir als missatges de correu electrònic a la safata d'entrada.
 Aquests són el tipus de coses que vostè pot inspeccionar per veure
 si l'aplicació està fent aquestes coses.
 La segona gran categoria de comportament maliciós, i això és probablement la categoria més gran ara,
 és el marcatge no autoritzada, els missatges de text SMS premium no autoritzada
 o pagaments no autoritzats.
 Una altra cosa que és únic sobre el telèfon
 hi ha el dispositiu està connectat a un compte de facturació,
 i quan les activitats ocorren al telèfon
 pot crear càrrecs.
 Vostè pot comprar les coses a través del telèfon,
 i quan s'envia un missatge de text SMS premium en realitat estàs donant diners
 al titular del compte del número de telèfon a l'altra banda.
 Aquests van ser creats per obtenir cotitzacions de borsa o d'obtenir el seu horòscop diari o d'altres coses,
 però poden ser configurats per demanar un producte mitjançant l'enviament d'un SMS de text.
 La gent dóna diners a la Creu Roja mitjançant l'enviament d'un missatge de text.
 Vostè pot donar 10 $ d'aquesta manera.
 

Els agressors, el que han fet és que van crear
 comptes a l'estranger, i s'incrusten en el malware
 que el telèfon enviarà un missatge de text SMS premium,
 per exemple, un parell de vegades al dia, i al final del mes t'adones que has gastat
 desenes o potser fins i tot centenars de dòlars, i s'allunyen amb els diners.
 Això va arribar a tal punt que aquesta era la primera cosa que l'Android
 Del mercat o del lloc-que Google va ser el mercat d'Android en el moment,
 i ara és Google Play-el primer que Google va començar comprovant.
 Quan Google va començar a distribuir les apps Android a la seva botiga d'aplicacions
 em van dir que no anaven a revisar qualsevol cosa.
 Traurem les aplicacions un cop hem estat notificats que han trencat els nostres termes de servei,
 però nosaltres no anem a revisar qualsevol cosa. Bé, fa aproximadament un any es va posar tan malament amb aquest SMS premium missatge de text de malware
 que aquesta és la primera cosa que van començar comprovant.
 Si una aplicació pot enviar missatges de text SMS
 vigilar més manualment l'aplicació.
 Busquen les API que criden a això,
 i ara des de llavors Google s'ha expandit,
 però aquesta era la primera cosa que ells van començar a buscar.
 

Algunes altres aplicacions que van fer alguns dels missatges de text SMS,
 aquest Qicsomos Android, crec que es diu.
 Hi havia un esdeveniment en curs al mòbil on aquesta CarrierIQ va sortir
 com a programari espia posen al dispositiu pels transportistes,
 de manera que la gent volia saber si el seu telèfon estava vulnerable a això,
 i això era una aplicació gratuïta que va provar això.
 Bé, per descomptat, el que aquesta aplicació va fer va ser que va enviar missatges de text SMS premium,
 així provant per veure si vostè està infectat amb spyware
 que ha carregat de malware al dispositiu.
 Vam veure el mateix succeeix en l'últim Super Bowl.
 No hi va haver una versió falsa del partit de futbol Madden
 que envien missatges de text SMS premium.
 En realitat, va tractar de crear una xarxa bot també al dispositiu.
 Aquí tinc alguns exemples.
 Curiosament, Apple era bastant intel · ligent,
 i que no permeten a les aplicacions enviar missatges de text SMS en absolut.
 No aplicació pot fer-ho.
 Això és una gran manera de desfer de tota una classe de vulnerabilitat,
 però en Android que pots fer-ho, i per descomptat, en el BlackBerry pot fer-ho també.
 És interessant que en el BlackBerry només necessites permisos d'Internet
 per enviar un missatge de text SMS.
 

L'altra cosa realment que busquem
 quan estem mirant per veure si alguna cosa és maliciós és qualsevol tipus de
 activitat de xarxa no autoritzat, com miri el activitat de la xarxa
 l'aplicació se suposa que ha de tenir la seva funcionalitat,
 i mirar a aquesta altra activitat de la xarxa.
 Potser una aplicació, a treballar, ha d'obtenir les dades a través d'HTTP,
 però si es tracta de fer les coses per correu electrònic o SMS o Bluetooth, o alguna cosa així
 ara que l'aplicació podria deure maliciós, de manera que aquesta és una altra cosa que vostè pot inspeccionar.
 I en aquesta diapositiva aquí tinc alguns exemples.
 Una altra cosa interessant que vam veure amb malware que va succeir el 2009,
 i va succeir d'una manera gran.
 No sé si ha passat molt des d'aleshores, però era una aplicació
 que van personificar a una altra aplicació.
 Hi havia un conjunt d'aplicacions, i va ser anomenat l'atac 09Droid,
 i algú va decidir que hi havia una gran quantitat de petits bancs, regional, de grandària mitjana
 que no tenen les aplicacions de banca en línia,
 així que el que van fer va ser que van construir prop de 50 aplicacions de banca en línia
 que l'únic que van fer va ser prendre el nom d'usuari i contrasenya
 i li redirigirà a la pàgina web.
 I pel que posar tots aquests en el mercat de Google,
 en el mercat Android, i quan algú buscat per veure si el seu banc
 tingut una aplicació que trobarien l'aplicació falsa,
 que va recollir les seves credencials i després els redirigeix ​​a la seva pàgina web.
 La forma en què aquest fet es va convertir en-les aplicacions hi eren per un parell de setmanes,
 i hi havia milers i milers de descàrregues.
 

La forma en què va sortir a la llum va ser que algú està patint un problema
 amb una de les aplicacions, i ells van cridar al seu banc,
 i van cridar a la línia d'atenció al client del seu banc i li van dir:
 "Estic tenint un problema amb la seva aplicació de banca mòbil".
 "Em pots ajudar?"
 I ells van dir: "No tenim una aplicació de banca mòbil".
 Això va començar la investigació.
 Aquest banc diu Google, i després Google va mirar i va dir:
 "Wow, el mateix autor ha escrit 50 aplicacions bancàries", i se'ls va endur cap avall.
 Però, certament, això podria succeir de nou.
 Aquí hi ha la llista de tots els diferents bancs aquí
 que formaven part d'aquesta estafa.
 L'altra cosa que una aplicació pot fer és presentar la interfície d'usuari d'una altra aplicació.
 Mentre s'està executant podria aparèixer al Facebook UI.
 Es diu que vostè ha de posar el seu nom d'usuari i contrasenya per a continuar
 o posar qualsevol nom d'usuari i la contrasenya de la interfície d'usuari per a un lloc web
 que potser l'usuari utilitza només per intentar enganyar l'usuari
 a posar les seves credencials polz
 Això és realment un paral · lel directe dels atacs de phishing de correu electrònic
 on algú li envia un missatge de correu electrònic
 i li dóna bàsicament una interfície d'usuari per a un lloc web fals
 que vostè té accés.
 

L'altra cosa que busquem en el codi maliciós és la modificació del sistema.
 Vostè pot buscar totes les trucades a l'API que requereixen privilegis de root
 per executar correctament.
 Canvi de proxy web del dispositiu seria una cosa que una aplicació
 no hauria de ser capaç de fer.
 Però si l'aplicació té codi en allà per fer que
 vostè sap que és probable que sigui una aplicació maliciosa
 o molt altament probable que sigui una aplicació maliciosa,
 i així el que succeiria és que l'aplicació tindria alguna forma d'una escalada de privilegis.
 Tindria alguna escalada de privilegis explotar
 en l'aplicació i, a continuació, una vegada que es va intensificar privilegis
 seria fer aquestes modificacions en el sistema. Vostè pot trobar malware que té una escalada de privilegis
 en ell, fins i tot sense saber com l'escalada de privilegis
 explotar passarà, i això és una bona manera, fàcil
 buscar malware.
 DroidDream va ser probablement la més famosa peça de malware Android.
 Crec que va afectar prop de 250.000 usuaris en pocs dies
 abans que fos trobat.
 Ells reenvasament 50 aplicacions falses,
 posar-los en la botiga d'aplicacions Android,
 i, essencialment, s'utilitza el codi jailbreak Android per escalar privilegis
 i després instal · lar un comandament i control i giri totes les víctimes
 en una xarxa bot, però es podria haver detectat aquesta
 Si estava escanejant l'aplicació i només a la recerca de
 API demana permís a aquesta arrel necessari per executar correctament.
 

I hi ha un exemple aquí he de canvia el proxy,
 i això en realitat només està disponible en l'Android.
 Es pot veure que t'estic donant una gran quantitat d'exemples sobre Android
 perquè aquí és on l'ecosistema de malware més actiu és
 perquè és molt fàcil per a un atacant per obtenir el codi maliciós
 en el mercat Android.
 No és tan fàcil de fer que a l'App Store d'Apple
 perquè Apple obliga els desenvolupadors a identificar-
 i signar el codi.
 Ells realment comprovar que és vostè, i Apple és en realitat escodrinyant les aplicacions.
 No veiem una gran quantitat de malware de veritat en el que el dispositiu s'està compromès.
 Vaig a parlar d'alguns exemples en què és realment la vida privada que està sent compromesa,
 i això és el que realment està succeint en el dispositiu d'Apple.
 Una altra cosa a cercar codi maliciós, el codi de risc en els dispositius
 és lògiques o de bombes i bombes de temps són probablement
 molt més fàcil de buscar que les bombes lògiques.
 Però amb bombes de temps, el que pot fer és que es pot buscar
 llocs en el codi on es posa a prova el temps o un temps absolut que es busca
 abans de certa funcionalitat en l'aplicació passa.
 I això es podria fer per amagar que l'activitat de l'usuari,
 pel que està succeint a altes hores de la nit.
 DroidDream fer tota la seva activitat 11 p.m.-08 a.m. hora local
 en tractar de fer-ho, mentre que l'usuari no estigui utilitzant el dispositiu.
 

Una altra raó per fer això és que si la gent està utilitzant l'anàlisi del comportament d'una aplicació,
 executar l'aplicació en un entorn limitat a veure el que el comportament de l'aplicació és,
 poden utilitzar la lògica basada en el temps de fer l'activitat
 quan l'aplicació no es troba a la caixa de sorra.
 Per exemple, una botiga d'aplicacions com Apple
 executa l'aplicació, però probablement no s'executen totes les aplicacions, per exemple, 30 dies
 abans d'aprovar-la, el que pot posar
 la lògica de l'aplicació que, va dir, està bé, només fer el dolent
 després de 30 dies ha passat, o al cap de 30 dies després de la data de publicació de la sol · licitud,
 i que pot ajudar a ocultar el codi maliciós de la gent inspeccionant per a això.
 Si les companyies d'antivirus estan funcionant les coses en caixes de sorra
 o les pròpies botigues d'aplicacions són que això pot ajudar
 amagar que a partir d'aquesta inspecció.
 Ara, l'altra cara d'això és que és fàcil de trobar amb l'anàlisi estàtic,
 el que en realitat inspeccionar el codi que pot buscar tots els llocs
 on l'aplicació comprova el temps i inspeccionar d'aquesta manera.
 I aquí tinc alguns exemples d'aquestes 3 plataformes diferents
 com el temps es pot comprovar pel fabricant de l'aplicació
 així que vostè sap què cercar si està inspeccionant l'aplicació de forma estàtica.
 

Acabo d'anar a través d'un munt de diferents activitats malicioses
 que hem vist en la naturalesa, però que són els més freqüents?
 Aquest mateix estudi realitzat a Carolina del Nord State Project Mobile Genoma
 publicat algunes dades, i existeixen principalment 4 àrees
 que van veure on hi havia poca activitat.
 37% de les aplicacions va fer una escalada de privilegis,
 pel que van tenir algun tipus de codi de jailbreak allà
 on van tractar d'escalar privilegis perquè poguessin
 Què comandaments de l'API s'executa com a sistema operatiu.
 45% de les aplicacions per aquí va fer SMS premium,
 així que és un gran percentatge que està tractant d'obtenir beneficis econòmics de forma directa.
 El 93% ho va fer de control remot, pel que va tractar d'establir una xarxa bot, una xarxa bot mòbil.
 I el 45% obtingut informació d'identificació
 com números de telèfon, UUID, localització GPS, comptes d'usuari
 i això se suma a més de 100, perquè la majoria del malware tracta de fer algunes d'aquestes coses.
 

Vaig a canviar a la segona meitat i parlar sobre les vulnerabilitats de codi.
 Aquesta és la segona part de l'activitat de risc.
 Aquí és on essencialment el desenvolupador està fent errors.
 Un desenvolupador legítim escriure una aplicació legítima
 està cometent errors o és ignorant dels riscos de la plataforma mòbil.
 Ells simplement no saben com fer que una aplicació mòbil segura,
 o, de vegades el desenvolupador no es preocupa per posar l'usuari en risc.
 De vegades part del seu model de negocis podria ser
 collir la informació personal de l'usuari.
 Això és una espècie de l'altra categoria, i és per això que alguns d'aquest maliciós
 contra arrencades legítims a sagnar de nou perquè hi ha diferència d'opinions
 entre el que l'usuari vol i el que l'usuari consideri arriscada
 i el que el desenvolupador de l'aplicació considera arriscat. Per descomptat, no és de dades dels desenvolupadors d'aplicacions en la majoria dels casos.
 

I, finalment, una altra forma això passa és un desenvolupador podria vincular a
 una biblioteca compartida que té vulnerabilitats o aquesta conducta de risc en ella
 a esquena d'ells.
 La primera categoria és la fuga de dades sensibles,
 i això seria l'aplicació recull informació
 com la ubicació, la informació de la llibreta d'adreces, informació del propietari
 i envia d'apagar el dispositiu.
 I una vegada que està fora del dispositiu, no sabem el que està passant amb aquesta informació.
 Podria ser emmagatzemat de forma insegura pel desenvolupador de l'aplicació.
 Hem vist els desenvolupadors d'aplicacions queden compromeses,
 i les dades que s'estan emmagatzemant és portat.
 Això va succeir fa uns mesos a un desenvolupador a Florida
 on un gran nombre de-era iPad UUID i noms de dispositius
 es van filtrar perquè algú, crec que va ser en l'anonimat,
 reclamat per fer això, van irrompre en els servidors d'aquest desenvolupador
 i van robar milions d'iPad UUID
 i els noms d'equip.
 No és la informació més arriscat,
 però el que si que era l'emmagatzematge de noms d'usuari i contrasenyes
 i adreces de domicili?
 Hi ha un munt d'aplicacions que emmagatzemen aquest tipus d'informació.
 El risc hi és.
 

L'altra cosa que pot succeir és si el desenvolupador no s'ocupa
 per assegurar el canal de dades, i això és un altre gran vulnerabilitat que vaig a parlar,
 que les dades s'envien en el clar.
 Si l'usuari està en una xarxa Wi-Fi pública
 o algú que està olorant l'Internet en algun lloc
 al llarg de la ruta d'accés està sent exposat a aquestes dades.
 Un cas molt famós d'aquesta fuga d'informació ocórrer amb Pandora,
 i això és una cosa que investiguem a Veracode.
 Ens assabentem que hi havia una-Crec que va ser una Comissió Federal de Comerç
 investigació passant amb Pandora.
 Vam dir: "Què està passant aquí? Anem a començar a cavar en l'aplicació de Pandora."
 I el que es va determinar va ser l'aplicació Pandora recollit
 seu sexe i la seva edat,
 i també accedir a la seva ubicació GPS i l'aplicació de Pandora
 Ho vaig fer pel que van dir eren raons legítimes.
 La música que tocaven-Pandora és una aplicació de streaming de música
 la música estaven jugant només va ser autoritzada als Estats Units,
 així que van haver de comprovar que compleix amb els seus acords de llicència que tenien
 per a la música que l'usuari estava als Estats Units.
 També volien complir amb l'assessorament dels pares
 al voltant de llenguatge d'adults en la música,
 i el que és un programa voluntari, però volia complir amb aquest
 i no jugar lletres explícites de nens de 13 anys o menors.
 

No tenien motius legítims per recopilar aquestes dades.
 La seva aplicació té els permisos per fer-ho.
 Els usuaris van pensar que això era legítim. Però, què va passar?
 Es van unir en 3 o 4 biblioteques d'anuncis diferents.
 Ara, de sobte, totes aquestes biblioteques d'anuncis
 són cada vegada més l'accés a la mateixa informació.
 Les biblioteques d'anuncis, si ens fixem en el codi a les biblioteques d'anuncis
 el que fan és cada biblioteca anunci diu
 "La meva aplicació té permís per obtenir la ubicació GPS?"
 "Oh, sí? Bé, digues-me la ubicació GPS."
 Cada biblioteca anunci fa això,
 i si l'aplicació no té permís GPS
 no serà capaç de fer-ho, però si ho fa, l'obtindrà.
 Aquí és on el model de negoci de les biblioteques d'anuncis
 s'oposa a la privadesa dels usuaris.
 I no hi ha hagut estudis per aquí que dirà si vostè sap l'edat
 d'una persona i vostè sap la seva ubicació
 on dormir a la nit, perquè té les seves coordenades GPS
 mentre que potser estiguin dormint, vostè sap exactament qui és aquesta persona
 perquè es pot determinar quin membre d'aquesta llar és aquesta persona.
 Realment això és identificar els anunciants
 exactament qui és vostè, i es veu com si fos legítim.
 Només vull que la meva música streaming, i aquesta és l'única manera d'aconseguir-.
 

Bé, vam exposar això.
 Escrivim això en diverses publicacions al bloc,
 i va resultar que algú de la revista Rolling Stone
 llegir un dels nostres missatges de bloc i escriure el seu propi bloc a la revista Rolling Stone en això,
 i l'endemà Pandora va pensar que era una bona idea
 per eliminar les biblioteques d'anuncis de la seva aplicació.
 Pel que jo sé que són l'únic-que haurien de ser elogiats.
 Crec que són l'únic tipus freemium d'aplicació que s'ha fet això.
 Totes les altres aplicacions freemium tenen aquest mateix comportament,
 pel que ha de pensar en quin tipus de dades que s'estan donant
 aquestes aplicacions freemium perquè tot va a anunciants.
 Pretoriana també va fer un estudi sobre les biblioteques compartides i va dir:
 "Anem a veure el que comparteixen les biblioteques són les biblioteques compartides superiors", i això va ser les dades.
 

Van analitzar 53,000 aplicacions,
 i la biblioteca compartida número 1 era AdMob.
 En realitat, va ser en el 38% de les aplicacions que hi ha,
 de manera que el 38% de les aplicacions que utilitzeu
 probablement estiguin capturant la seva informació personal
 i enviar-lo a les xarxes d'anuncis. Apache i Android van ser del 8% i 6%,
 i llavors aquests altres cap avall a la part inferior, els anuncis de Google, Flurry,
 Mob City i Millennial Mitjana,
 aquestes són totes les empreses de publicitat, i després, curiosament,
 4% relacionat a la biblioteca de Facebook
 probablement per realitzar l'autenticació a través de Facebook
 pel que l'aplicació pot autenticar al Facebook.
 Però això també significa que la corporació Facebook controla codi
 que s'està executant en el 4% de les aplicacions mòbils per Android per aquí,
 i tenen accés a totes les dades que aquesta aplicació té permís per arribar.
 Facebook essencialment tracta de vendre espais publicitaris.
 Aquest és el seu model de negoci.
 

Si ens fixem en tot aquest ecosistema amb aquests permisos
 i les biblioteques compartides de començar a veure que
 vostè té una gran quantitat de risc en una aplicació suposadament legítim.
 La mateixa cosa semblant va passar amb Pandora
 passat amb una aplicació anomenada Path,
 i ruta va pensar que estaven sent útils, els desenvolupadors d'amistat.
 Ells estaven tractant de donar-li una gran experiència d'usuari,
 i va resultar que sense preguntar a l'usuari o indicant a l'usuari res-
 i això va succeir en l'iPhone i en Android,
 Pandora aplicació era a iPhone i Android-
 que l'aplicació Sender estava agafant tota la seva llibreta d'adreces
 i pujar-lo a la ruta només quan va instal · lar i executar l'aplicació,
 i no li van dir res sobre això.
 Ells van pensar que era molt útil per a vostè
 per poder compartir amb totes les persones de la seva llibreta d'adreces
 que utilitzeu l'aplicació Path.
 

Bé, òbviament Sender va pensar que era gran per la seva empresa.
 No és tan bo per a l'usuari.
 Cal pensar que es tracta d'una cosa si potser un adolescent
 és l'ús d'aquesta aplicació i les seves desenes d'amics hi són,
 però el que si que és el CEO d'una empresa que instal · la Sendera
 i després, de la seva llibreta d'adreces sencera sobtada és allà dalt?
 Vostè va a obtenir una gran quantitat d'informació de contacte que pot ser valuosa
 per a un munt de gent.
 Un periodista del New York Times, que podria ser capaç de veure el telèfon
 per als expresidents de la seva llibreta d'adreces,
 pel que, òbviament, una gran quantitat d'informació sensible es transfereix amb alguna cosa com això.
 Hi va haver un gran penjoll tals sobre això que Sender es va disculpar.
 Van canviar la seva aplicació, i que fins i tot van afectar Apple.
 Apple va dir: "Anem a obligar els proveïdors d'aplicacions per sol · licitar als usuaris
 si cobraran la totalitat de la seva llibreta d'adreces ".
 

Sembla que el que està succeint aquí és
 quan hi ha una gran violació de la privacitat i fa la premsa
 veiem un canvi que hi ha.
 Però, és clar, hi ha altres coses per aquí.
 L'aplicació LinkedIn collita les entrades de calendari,
 però Apple no ho fa se sol · licita a l'usuari sobre això.
 Les entrades de calendari pot tenir informació confidencial a ells també.
 A on va a traçar la línia?
 Això és realment una espècie de lloc en evolució
 on no hi ha realment cap bona qualitat per aquí
 per als usuaris a entendre quan la informació estarà en risc
 i quan ho van a saber que està sent presa.
 Escrivim una aplicació en Veracode anomenat Adios,
 i, essencialment, que va permetre que vostè assenyali l'aplicació en el directori d'iTunes
 i mirar totes les aplicacions que estaven collint la seva llibreta d'adreces completa.
 I com es pot veure en aquesta llista aquí, Angry Birds,
 AIM, AroundMe.
 Per què Angry Birds necessiten la teva llibreta d'adreces?
 No ho sé, però ho fa d'alguna manera.
 

Això és una cosa que moltes, moltes aplicacions fan.
 Vostè pot inspeccionar el codi per això.
 Hi ha APIs ben definides per a iPhone, Android i BlackBerry
 per arribar a la llibreta d'adreces.
 Vostè pot inspeccionar amb gran facilitat per això, i això és el que vam fer en la nostra aplicació Adios.
 La següent categoria, no segur d'emmagatzematge de dades sensibles,
 és una cosa que els desenvolupadors tenen una mena agulla o un número de compte
 o una clau i guardi-la en el clar en el dispositiu.
 Pitjor encara, podrien emmagatzemar en una àrea al telèfon
 que és accessible a nivell mundial, igual que la targeta SD.
 Vostè veu això més sovint en Android Android perquè permet una targeta SD.
 Dispositius iPhone no.
 Però fins i tot vam veure que això passi en una aplicació de Citigroup.
 La seva aplicació de banca en línia emmagatzema els números de compte de forma insegura,
 només en el clar, així que si vostè va perdre el seu dispositiu,
 en essència el que vas perdre el teu compte bancari.
 És per això que jo personalment no faig les activitats bancàries en el meu iPhone.
 Crec que és massa arriscat en aquest moment per fer aquest tipus d'activitats.
 

Skype va fer el mateix.
 Skype, per descomptat, té un saldo de compte, nom d'usuari i contrasenya
 d'accedir a aquest equilibri.
 Ells estaven emmagatzemant tota aquesta informació en el clar en el dispositiu mòbil.
 Tinc alguns exemples aquí de la creació d'arxius
 que no tenen els permisos adequats o escrivint a disc
 i no tenir cap tipus de xifrat passi per això.
 Aquesta àrea següent, insegur Sensible de transmissió de dades,
 M'he referit a això unes quantes vegades, i perquè de públic Wi-Fi
 això és una cosa que les aplicacions tenen una necessitat imperiosa de fer,
 i això és probablement el que veiem sortir malament la majoria. Jo diria que-en realitat, crec que tinc les dades reals,
 però és a prop de la meitat de les aplicacions mòbils
 ficar la pota fent SSL.
 Ells simplement no s'utilitzen les APIs correctament.
 Vull dir, tot el que has de fer és seguir les instruccions i utilitzar les API,
 però sí coses com no comprovar si hi ha un certificat no vàlid en l'altre extrem,
 No comprovar si l'altre extrem està tractant de fer un atac rebaixa protocol.
 

Els desenvolupadors, que volen aconseguir la seva casella, no?
 La seva requisit és usar això per vendre. Han utilitzat aquest per vendre.
 El requisit és no usar això per vendre amb seguretat,
 pel que aquesta és la raó per totes les aplicacions que utilitzen SSL per protegir les dades
 ja que està sent transmesa apagar el dispositiu necessita realment per ser inspeccionat
 per assegurar-se que s'ha implementat correctament.
 I aquí tinc alguns exemples on es pot veure una aplicació
 podria ser a través d'HTTP en lloc de HTTPS.
 En alguns casos, les aplicacions es cauran de nou a HTTP
 si el HTTPS no està funcionant.
 Tinc una altra trucada aquí a Android on han desactivar el xec certificat,
 de manera que un atac man-in-the-middle pot succeir.
 S'acceptarà un certificat no vàlid.
 Aquests són tots els casos en què els atacants seran capaç d'obtenir en
 la mateixa connexió Wi-Fi com l'usuari i accedir a totes les dades
 que està sent enviat a través d'Internet.
 

I finalment, l'última categoria que tinc aquí és la contrasenya i les tecles codificat.
 En realitat, veiem una gran quantitat de desenvolupadors utilitzen el mateix estil de codificació
 que ho van fer quan estaven construint aplicacions de servidor web,
 pel que estan construint una aplicació de servidor Java, i s'estan codificant la clau.
 Bé, quan vostè està construint una aplicació de servidor, si,
 codificar la clau no és una bona idea.
 Això fa que sigui difícil canviar.
 Però no és tan dolent en el costat del servidor, ja que té accés a la part del servidor?
 Només els administradors.
 Però si es pren el mateix codi i s'aboca per sobre d'una aplicació mòbil
 ara tothom que té aquesta aplicació mòbil té accés a aquesta clau codificada,
 i que en realitat veure això moltes vegades, i tinc algunes estadístiques
 la freqüència amb què veiem que això passi.
 En realitat va ser en l'exemple de codi que va publicar MasterCard
 sobre l'ús del seu servei.
 El codi d'exemple va mostrar com vostè acaba de prendre la contrasenya
 i el va posar en una cadena codificada allà,
 i sabem com els desenvolupadors els encanta copiar i enganxar fragments de codi
 quan estan tractant de fer alguna cosa, de manera que copiar i enganxar el fragment de codi
 que ha posat com a exemple de codi, i vostè té una aplicació insegura.
 

I aquí tenim alguns exemples.
 Aquesta primera és que veiem un munt on retoquen
 el dret de les dades en un URL que s'envia.
 A vegades veiem string password = contrasenya.
 Això és molt fàcil de detectar, o la contrasenya de sèrie en el BlackBerry i Android.
 En realitat és bastant fàcil de detectar pel fet que gairebé sempre
 els noms dels desenvolupadors de la variable que es sosté la contrasenya
 alguna variació de la contrasenya.
 Vaig esmentar que fem anàlisi estàtic en Veracode,
 pel que hem analitzat diversos centenars d'aplicacions d'Android i iOS.
 Hem construït models complets d'ells, i som capaços d'escanejar
 per a diferents vulnerabilitats, especialment les vulnerabilitats de què parlava,
 i tinc algunes dades aquí.
 68,5% de les aplicacions d'Android que vam veure
 havia trencat el codi de xifrat,
 que, per a nosaltres, no podem detectar si ha realitzat la seva pròpia rutina de xifrat,
 no és que això sigui una bona idea, però això en realitat està utilitzant els API publicades
 que estan a la plataforma, però fent ells de tal manera
 que la criptografia seria vulnerable, 68.5.
 I això és per a les persones que ens estan enviant seves sol · licituds en realitat perquè
 ells pensen que és una bona idea per fer les proves de seguretat.
 Aquests ja són persones que probablement estan pensant de forma segura,
 pel que és probablement encara pitjor.
 

No vaig parlar sobre la injecció d'alimentació de la línia de control.
 És una cosa que anem a comprovar, però no és tan arriscat un problema.
 Filtració d'informació, és aquí on s'estan enviant dades sensibles fora del dispositiu.
 Es va trobar que en el 40% de les sol · licituds.
 El temps i l'estat, els que són qüestions de tipus condició de carrera, en general molt difícils d'explotar,
 així que no em refereixo a això, sinó que el vaig mirar.
 23% tenia problemes d'injecció SQL.
 Molta gent no sap que una gran quantitat d'aplicacions
 utilitzar una mica petita base de dades SQL a la part posterior per emmagatzemar dades.
 Bé, si les dades que vostè està agafant per la xarxa
 té cadenes d'atac d'injecció SQL-hi
 algú pot posar en perill el dispositiu a través d'això,
 i així que crec que trobarà prop del 40% de les aplicacions web tenen aquest problema,
 que és un problema enorme epidèmia.
 El trobem 23% de les vegades en les aplicacions mòbils
 i això és probablement pel fet que moltes més aplicacions web utilitzen SQL de mòbil.
 

I després encara veiem algunes seqüències d'ordres entre llocs, les qüestions d'autorització,
 i després l'administració de credencials, que és on vostè té la contrasenya codificada.
 En el 5% de les aplicacions que veiem això.
 I després tenim algunes dades sobre iOS.
 El 81% tenia problemes de maneig d'errors. Això és més d'un problema de la qualitat del codi,
 però el 67% tenia problemes de xifrat, pel que no és tan dolent com Android.
 Potser les API són una mica més fàcil, els codis d'exemple una mica millor en iOS.
 Però segueix sent un percentatge molt alt.
 Vam tenir un 54% amb la fuga d'informació,
 aproximadament el 30% amb errors de gestió de memòria intermèdia.
 Això és els llocs on podria ser potencialment un problema de corrupció de memòria.
 Resulta que això no és com molt d'un problema per a l'explotació
 en iOS, perquè tot el codi ha de ser signat,
 així que és difícil per a un atacant per a executar codi arbitrari en iOS.
 La qualitat del codi, recorregut de directori, però la gestió de credencials d'aquí en un 14,6%,
 per el pitjor que en l'Android.
 Tenim gent no gestionar contrasenyes correctament.
 I a continuació, els errors numèrics i de desbordament de memòria intermèdia,
 que estan més hi haurà problemes de qualitat de codi en iOS.
 

Això va ser tot per la meva presentació. No sé si estem fora de temps o no.
 No sé si hi ha alguna pregunta.
 [Home] Una pregunta ràpida al voltant de la fragmentació i el mercat Android.
 D'Apple, almenys, és propietària de pegats.
 Ells fan una bona feina de fer les coses per aquí mentre que en menor mesura en l'espai d'Android.
 Gairebé es necessita per fer jailbreak al seu telèfon per estar al dia
 amb la versió actual d'Android.
 Sí, això és un gran problema i que si es pensa en-
 [Home] Per què no t'ho repeteixi?
 

Ah, clar, així que la pregunta era què passa amb la fragmentació
 del sistema operatiu a la plataforma Android?
 Com afecta el grau de risc d'aquests dispositius?
 I el que realment és un gran problema perquè el que passa és
 els dispositius més antics, quan algú se li ocorre una fugida de la presó per a aquest dispositiu,
 en essència, que és una escalada de privilegis, i fins que s'actualitzi el sistema operatiu
 qualsevol tipus de malware pot llavors utilitzar aquesta vulnerabilitat per comprometre totalment el dispositiu,
 i el que estem veient en l'Android és la fi d'obtenir un nou sistema operatiu
 Google ha de apagar el sistema operatiu, i després el fabricant de maquinari
 té per personalitzar, i després el transportista ha de personalitzar i lliurar-lo.
 Vostè té bàsicament 3 peces en moviment aquí,
 i s'està convertint en que els transportistes no els importa,
 i els fabricants de maquinari no els importa, i Google no aguijoneándolos suficient
 per fer qualsevol cosa, el que en essència més de la meitat dels dispositius per aquí
 tenir sistemes operatius que tenen aquestes vulnerabilitats d'escalada de privilegis en ells,
 i així que si tens el malware en el seu dispositiu Android és molt més d'un problema.
 

Bé, moltes gràcies.
 [Aplaudiments]
 [CS50.TV]