>> [Séminaire] [Défendre Derrière le périphérique: Mobile Security Application]
[Chris Wysopal] [Université de Harvard]
[C'est CS50.] [CS50.TV]
>> Bonjour. Mon nom est Chris Wysopal.
Je suis le CTO et co-fondateur de VeraCode.
VeraCode est une société de sécurité de l'application.
Nous testons tous les types d'applications différentes,
et ce que je vais vous parler aujourd'hui est la sécurité de l'application mobile.
Mon fond est j'ai fait des recherches de sécurité
pour un temps très long, probablement aussi longtemps que quiconque.
J'ai commencé dans le milieu des années 90,
et il fut un temps que c'était assez intéressant car
nous avons eu un changement de paradigme dans le milieu des années 90.
Tout l'ordinateur d'un coup tout le monde a été relié à l'Internet,
et puis nous avons eu les débuts d'applications web,
et c'est ce que je me suis concentré sur un terrain alors.
C'est intéressant.
Maintenant, nous avons un autre changement de paradigme qui se passe à l'informatique,
qui est le passage à des applications mobiles.
>> Je pense que c'est une sorte de temps similaire alors qu'il était à la fin des années 90
quand nous étions étudions les applications Web et de trouver des défauts comme
erreurs de gestion de session et injection SQL
qui a vraiment n'existait pas avant, et tout d'un coup, ils étaient partout
dans les applications Web, et maintenant beaucoup de temps que je passe
est à la recherche à des applications mobiles et en regardant ce qui se passe là-bas à l'état sauvage.
Les applications mobiles vont vraiment être la plate-forme informatique dominante,
donc nous avons vraiment besoin de passer beaucoup de temps si vous êtes dans le secteur de la sécurité
en mettant l'accent sur les applications web.
Il y avait 29 milliards d'applications téléchargées en 2011 mobiles.
Il est prévu à 76 milliards d'applications en 2014.
Il ya 686 millions de dispositifs qui vont être achetés cette année,
c'est donc là que les gens vont faire
la majorité de leur informatique de client à l'avenir.
>> Je parlais à un vice-président de Fidelity Investments
Il ya quelques mois, et il a dit qu'ils viennent de voir plus de trafic
faire des transactions financières à partir de leur base de clientèle
sur leur application mobile que sur leur site web,
si un usage courant pour le Web dans le passé a été
vérifier vos cotations boursières, la gestion de votre portefeuille,
et nous sommes en train de voir que dans le commutateur 2012 sur
être plus dominant sur la plate-forme mobile.
Certes, si il va y avoir une quelconque activité criminelle,
toute activité malveillante, il va commencer à se concentrer sur la plate-forme mobile
au fil du temps que les gens passent plus de cela.
Si vous regardez à la plate-forme mobile,
d'examiner les risques de la plate-forme, il est utile de le décomposer en différentes couches,
tout comme vous le feriez sur un ordinateur de bureau,
et vous pensez des différentes couches, logiciels, système d'exploitation,
couche réseau, couche de matériel, et bien sûr, il ya des vulnérabilités sur toutes ces couches.
>> La même chose se produit sur mobile.
Mais mobile, il semble que certains de ces couches sont moins bien lotis.
D'une part, la couche de réseau est plus problématique sur mobile
parce que beaucoup de gens ont dans leur bureau ou à la maison
un raccordement fixe ou ils ont sécurisé les connexions Wi-Fi,
et avec un grand nombre de périphériques mobiles, vous êtes de toute évidence à l'extérieur de la maison
ou à l'extérieur du bureau d'un lot, et si vous utilisez une connexion Wi-Fi y
vous utilisez peut-être une insécurité connexion Wi-Fi gratuite,
quelque chose qui est une connexion Wi-Fi gratuite,
quand nous pensons à des applications mobiles que nous avons à prendre en compte
que l'environnement réseau est plus risquée pour ces applications
lorsque le Wi-Fi est utilisé.
Et quand je reçois en plus des risques d'applications mobiles
vous verrez pourquoi c'est plus important.
Il ya des risques au niveau matériel sur les appareils mobiles.
C'est un domaine de recherche en cours.
Les gens appellent ces attaques à large bande ou des attaques en bande de base
où vous attaquez le firmware qui est à l'écoute sur la radio.
>> Ce sont vraiment des attaques effrayantes parce
l'utilisateur n'a pas à faire quoi que ce soit.
Vous pouvez frapper un bon nombre de dispositifs à portée de RF
à la fois, et il semble que chaque fois que cette recherche bouillonne
il obtient rapidement classé où
les gens foncent en autour et disent: «Ici, nous disent à ce sujet, et s'il vous plaît arrêter d'en parler."
Il ya des recherches en cours dans le domaine de la large bande,
mais il semble être très hush hush.
Je pense que c'est plus d'un type de recherche de l'Etat de la nation qui se passe.
Un domaine de recherche active, cependant, c'est la couche de système d'exploitation,
et encore une fois, c'est différent que dans le monde informatique de bureau
parce que dans l'espace mobile, vous avez ces équipes de personnes appelées Jailbreakers,
et Jailbreakers sont différents de chercheurs réguliers de vulnérabilité.
Ils essaient de trouver des vulnérabilités dans le système d'exploitation,
mais la raison pour laquelle ils essaient de trouver les vulnérabilités n'est pas à
s'introduire dans l'ordinateur de quelqu'un d'autre et compromettre.
C'est à percer dans leur propre ordinateur.
>> Ils veulent percer dans leur propre mobile, modifier le système d'exploitation de leur propre portable
afin qu'ils puissent exécuter les applications de leur choix
et changer les choses avec des autorisations administratives complètes,
et ils ne veulent pas dire le vendeur à ce sujet.
Ils ne sont pas comme un chercheur en sécurité qui est un chercheur en sécurité chapeau blanc
qui va faire une divulgation responsable et dire le vendeur à ce sujet.
Ils veulent faire cette recherche, et ils veulent en fait publier
dans une exploitation ou un rootkit ou d'un code de jailbreak,
et ils veulent le faire de façon stratégique, comme juste après
les navires de fournisseurs du nouveau système d'exploitation.
Vous avez cette relation contradictoire
des vulnérabilités au niveau du système d'exploitation sur le mobile,
je pense que c'est tout à fait intéressant, et un endroit où nous vois
est-il fait en sorte que il ya du bon code publié exploiter là-bas
des vulnérabilités au niveau du noyau,
et nous avons vu ceux qui sont effectivement être utilisé par les auteurs de logiciels malveillants.
C'est un peu différent que le monde du PC.
Et ensuite la couche finale est la couche supérieure, la couche d'application.
C'est ce que je vais vous parler aujourd'hui.
Les autres couches >> existent, et les autres couches jouent en elle,
mais je suis surtout vais parler de ce qui se passe à la couche d'application
où le code est exécuté dans le bac à sable.
Il ne dispose pas de privilèges administratifs.
Il doit utiliser les API de l'appareil,
mais encore, beaucoup d'activités malveillantes et beaucoup de risques peuvent se produire à cette couche
parce que c'est la couche où toute l'information est.
Les applications peuvent accéder à toute l'information sur le dispositif
s'ils ont les bonnes autorisations,
et ils peuvent accéder aux différents capteurs de l'appareil,
capteur GPS, microphone, appareil photo, ce que vous avez.
Même si nous ne parlons que de la couche d'application
nous avons beaucoup de risque là.
L'autre chose qui est différent au sujet de l'environnement mobile
est l'ensemble des acteurs du système d'exploitation, que ce soit BlackBerry ou Android
ou iOS ou Windows mobile, ils ont tous un modèle d'autorisation à grain fin,
et c'est l'une des façons dont ils intégrés dans le système d'exploitation
l'idée que ce n'est pas aussi risqué que vous pensez.
Même si vous avez tous vos contacts sur il, toutes vos informations personnelles,
vous avez vos photos, vous avez votre position là-bas,
vous stockez votre NIP bancaire pour la connexion automatique là-bas, c'est sûr, car
applications doivent disposer de certaines autorisations à obtenir à certaines parties
des informations sur l'appareil, et l'utilisateur doit être présenté avec
ces autorisations et disent bien.
>> Le problème, c'est que l'utilisateur dit toujours d'accord.
Comme une personne de la sécurité, je sais que vous pouvez demander à l'utilisateur,
dire quelque chose de vraiment mauvais qui va se passer, voulez-vous que cela se produise?
Et si ils sont dans une course ou il ya quelque chose de vraiment séduisant de l'autre côté de cela,
comme un jeu va être installé que ils ont attendu,
ils vont cliquer sur ok.
C'est pourquoi je dis à ma diapositive laissez-moi jeter oiseaux à porcs déjà,
et vous pouvez le voir sur la diapositive, il ya des exemples d'une boîte de permission BlackBerry.
Il dit: «S'il vous plaît définir les autorisations d'application BlackBerry Travel
après cliquant sur le bouton ci-dessous, "et essentiellement l'utilisateur est juste dire
définir les autorisations et économisez.
Voici un rapide Android où il montre des choses,
et il met effectivement quelque chose qui ressemble presque à un avertissement.
Il a une sorte de signe de rendement il dire la communication de réseau, appel téléphonique,
mais l'utilisateur va cliquer sur installer, non?
Et puis l'un d'Apple est totalement inoffensif.
Il ne donne aucune sorte d'avertissement.
C'est juste d'Apple aimerait utiliser votre emplacement actuel.
Bien sûr, vous allez cliquer OK.
>> Il est ce modèle d'autorisation fine,
et applications à avoir un fichier de manifeste où ils déclarent
les autorisations dont ils ont besoin, et qui vont se présenter à l'utilisateur,
et l'utilisateur aura à dire, je l'accorde ces autorisations.
Mais soyons honnêtes.
Les utilisateurs vont juste dire toujours d'accord.
Jetons un coup d'œil sur les autorisations que ces applications se posent pour
et certains des autorisations qui sont là.
Cette société prétorienne a fait un sondage l'an dernier
de 53 000 applications analysées dans les marchés et 3ème parti marchés Android,
si c'est tout ce que Android.
Et l'application moyenne a demandé 3 autorisations.
Certaines applications ont demandé 117 autorisations,
si évidemment ce sont des grains très fins et trop complexe pour un utilisateur de comprendre
si ils sont présentés avec cette application qui a besoin de ces 117 autorisations.
C'est comme le contrat de licence utilisateur final qui est de 45 pages.
Peut-être que bientôt ils auront une option où c'est comme
imprimer les autorisations et envoyez-moi un e-mail.
>> Mais si vous regardez certains des meilleurs autorisations intéressantes
24% des applications qu'ils ont téléchargé sur le 53000
l'information de GPS demandé depuis le dispositif.
8% ont lu les contacts.
4% SMS envoyé, et 3% ont reçu des SMS.
2% enregistré audio.
1% traitement des appels sortants.
Je ne sais pas.
Je ne pense pas 4% des applications dans l'App Store vraiment besoin d'envoyer des messages texte SMS,
donc je pense que c'est un signe que quelque chose de fâcheux se passe.
8% des applications ont besoin de lire votre liste de contacts.
Il n'est probablement pas nécessaire.
Une des autres choses intéressantes sur les autorisations est
si vous liez les bibliothèques partagées dans votre application
ceux qui héritent des autorisations de la demande,
si votre application a besoin de la liste de contacts ou besoin de la position GPS pour fonctionner
et vous liez dans une bibliothèque de la publicité, par exemple,
qui annonce la bibliothèque sera également en mesure d'accéder aux contacts
et aussi être capable d'accéder à la position GPS,
et le développeur de l'application ne sait rien à propos du code qui s'exécute dans la bibliothèque de l'annonce.
Ils sont juste reliant que parce qu'ils veulent monétiser leur application.
>> C'est là-et je vais parler de quelques exemples de ce à
une application appelée Pandora, où un développeur d'applications
pourrait être à son insu la fuite d'informations
de leurs utilisateurs en raison de bibliothèques qu'ils ont liés po
Arpentage le paysage là-bas, en regardant les différentes applications
qui ont été signalés dans les nouvelles que des utilisateurs malveillants ou de faire quelque chose ne voulaient pas
puis inspecter beaucoup d'applications, nous faisons beaucoup d'analyse binaire statique sur les applications mobiles,
si nous les avons inspecté et examiné le code lui-même,
nous sommes arrivés à ce que nous appelons notre top 10 des comportements à risque dans les applications.
Et il est décomposé en deux sections, les codes malveillants,
donc ce sont de mauvaises choses que les applications pourraient faire que
sont susceptibles d'être quelque chose que d'individu malveillant
a spécifiquement mis en application, mais il est un peu floue.
Il pourrait être quelque chose que le développeur pense est très bien,
mais il finit par être considéré comme malveillant par l'utilisateur.
>> Et puis la deuxième section est ce que nous appelons les vulnérabilités de codage,
et ce sont des choses où le développeur est essentiellement de faire des erreurs
ou tout simplement ne pas comprendre comment écrire l'application en toute sécurité,
et cela de mettre l'utilisateur de l'application à risque.
Je vais les passer en revue en détail et donner quelques exemples.
Pour référence, je voulais mettre la liste OWASP portable top 10.
Ce sont les 10 questions qu'un groupe à l'OWASP,
le projet Open Web Application Security, ils ont un groupe de travail
travailler sur une liste des 10 mobile.
Ils ont une liste web top 10 très célèbre, qui sont le top 10
plus risqués choses que vous pouvez avoir dans une application Web.
Ils font la même chose pour le mobile,
et leur liste est un peu différente de la nôtre.
6 sur le 10 sont les mêmes.
Ils ont 4 qui sont différents.
Je pense qu'ils ont un peu d'un point de vue différent sur
risque dans les applications mobiles où beaucoup de leurs problèmes
sont vraiment comment l'application communique à un serveur back-end
ou ce qui se passe sur le serveur back-end,
applications pas tellement qui ont des comportements à risque que sont les applications clientes juste simples.
>> Ceux en rouge ici sont les différences entre les deux listes.
Et une partie de mon équipe de recherche a fait contribué à ce projet,
donc nous allons voir ce qui se passe dans le temps, mais je pense que l'emporter ici est
nous ne savons pas vraiment ce que la liste des 10 est dans les applications mobiles, car
ils ont vraiment seulement été autour depuis 2 ou 3 ans,
et il n'a pas eu assez de temps pour vraiment étudier les systèmes d'exploitation
et ce qu'ils sont capables de faire, et il n'a pas eu assez de temps
pour la communauté malveillants, si vous voulez, d'avoir passé assez de temps
en essayant d'attaquer les utilisateurs grâce à des applications mobiles, donc je attendre de ces listes pour changer un peu.
Mais pour l'instant, ce sont les 10 choses à s'inquiéter.
Vous pourriez vous demander sur le côté mobile où le fait le code mobile malveillant
comment obtient-il à l'appareil?
État de Caroline du Nord a un projet appelé projet du génome mobile Malware
où ils recueillent autant les logiciels malveillants mobiles que possible et de les analyser,
et ils ont brisé les vecteurs d'injection que le malware mobile utilise,
et 86% utilisent une technique appelée le reconditionnement,
et ce n'est que sur la plateforme Android
pouvez-vous vraiment faire ce reconditionnement.
>> La raison est le code Android est construit avec
un byte code Java appelé Dalvik qui est facilement decompilable.
Qu'est-ce que le méchant peut faire est
prendre une application Android, décompiler,
insérer leur code malveillant, recompiler,
et puis le mettre dans l'app store qui se présente comme une nouvelle version de cette application,
ou tout simplement peut-être changer le nom de l'application.
Si c'était une sorte de jeu, changer le nom légèrement,
et si ce reconditionnement est de savoir comment 86% des logiciels malveillants mobiles est distribué.
Il ya une autre technique appelée mise à jour qui est
très similaire à reconditionnement, mais vous n'avez pas vraiment mettre le code malveillant po
Ce que vous faites, c'est que vous mettez dans un petit mécanisme de mise à jour.
Vous décompiler, vous mettez dans un mécanisme de mise à jour, et vous recompiler,
puis lorsque l'application est en cours d'exécution, il tire vers le bas le malware sur l'appareil.
>> La grande majorité sont ces 2 techniques.
Il n'y a pas télécharger des accès voiture vraiment beaucoup ou drive-by downloads sur mobiles,
qui pourrait être comme une attaque de phishing.
Hey, consultez ce site vraiment cool,
ou vous devez aller sur ce site et remplir ce formulaire
de garder continue de faire quelque chose.
Ceux-ci sont les attaques de phishing.
La même chose peut se produire sur la plate-forme mobile où ils
pointer vers une application mobile à télécharger, dire "Salut, c'est la Bank of America."
"Nous voyons que vous utilisez cette application."
"Vous devez télécharger cette autre application."
Théoriquement, cela pourrait fonctionner.
Peut-être qu'il n'est tout simplement pas suffisamment utilisé pour déterminer si c'est un succès ou pas,
mais ils ont constaté que moins de 1% du temps, cette technique est utilisée.
La plupart du temps, c'est vraiment un code reconditionné.
>> Il ya une autre catégorie appelée autonome
où quelqu'un construit juste une application flambant neuf.
Ils construisent une application qui prétend être quelque chose.
Ce n'est pas un reconditionnement de quelque chose d'autre, et qui a le code malveillant.
Qui est utilisé 14% du temps.
Maintenant, je veux parler de ce qui est le code malveillant fait?
L'un des premiers logiciels malveillants là-bas
vous pourriez envisager un spyware.
Il espions essentiellement sur l'utilisateur.
Il collecte des emails, des messages SMS.
On met le microphone.
Il récolte le carnet d'adresses, et il l'envoie à quelqu'un d'autre.
Ce type de logiciels espions existe sur le PC,
il est donc parfaitement logique pour les gens d'essayer de le faire sur les appareils mobiles.
>> Un des premiers exemples de ce était un programme appelé secret SMS Replicator.
Il était dans le marché Android il ya quelques années,
et l'idée était si vous aviez accès à téléphone Android de quelqu'un
que vous vouliez pour espionner, donc c'est peut-être votre conjoint
ou votre autre significatif et que vous souhaitez espionner sur leur messagerie texte,
vous pouvez télécharger l'application et de l'installer et le configurer
d'envoyer un message texte SMS à vous avec une copie
de chaque message texte SMS qu'ils ont obtenu.
C'est évidemment en violation des conditions App Store de service,
et cela a été retiré du marché Android dans les 18 heures, il est là,
si un très petit nombre de personnes étaient en danger à cause de cela.
Maintenant, je pense que si le programme a été appelé quelque chose peut-être un peu moins provocante
comme secret SMS Replicator il aurait probablement travaillé beaucoup mieux.
Mais il était assez évident.
>> Une des choses que nous pouvons faire pour déterminer si les applications ont ce comportement que nous ne voulons pas
est d'inspecter le code.
C'est en fait très facile à faire sur Android parce que nous pouvons décompiler les applications.
Sur iOS, vous pouvez utiliser un désassembleur comme IDA Pro
regarder ce APIs l'application appelle et ce qu'il fait.
Nous avons écrit notre propre analyseur statique binaire pour notre code
et nous le faisons, et si ce que vous pouvez faire, c'est vous pourriez dire
ne le dispositif faire tout ce qui est essentiellement d'espionnage sur moi ou me suivent?
Et j'ai quelques exemples ici sur l'iPhone.
Ce premier exemple est de savoir comment accéder à l'UUID sur le téléphone.
C'est vraiment quelque chose que Apple vient d'interdire pour de nouvelles applications,
mais les anciennes applications que vous pourriez avoir en cours d'exécution sur votre téléphone peuvent encore le faire,
et que l'identificateur unique peut être utilisé pour vous suivre
dans de nombreuses applications différentes.
>> Sur Android, j'ai un exemple ici d'obtenir l'emplacement de l'appareil.
Vous pouvez voir que si l'appel d'API est il que l'application est suivi,
et vous pouvez voir si ça devient bon emplacement ou l'emplacement grossier.
Et puis sur le fond ici, j'ai un exemple de la façon dont le BlackBerry
une application peut accéder aux e-mails dans votre boîte de réception.
Ce sont le genre de choses que vous pouvez contrôler à voir
si l'application est en train de faire ces choses.
La deuxième grande catégorie de comportements malveillants, et c'est probablement la catégorie la plus importante maintenant,
est la composition non autorisée, primes non autorisée de messages texte SMS
ou des paiements non autorisés.
Une autre chose qui est unique sur le téléphone
est le dispositif est relié à un compte de facturation,
et lorsque les activités se produisent sur le téléphone
il peut créer des charges.
Vous pouvez acheter des choses sur le téléphone,
et lorsque vous envoyez un message texte SMS premium, vous êtes en train de donner de l'argent
pour le titulaire du compte du numéro de téléphone de l'autre côté.
Ils ont été mis en place pour obtenir des cotations boursières ou obtenir votre horoscope du jour ou d'autres choses,
mais ils peuvent être configurés pour commander un produit en envoyant un SMS.
Les gens donnent de l'argent à la Croix-Rouge en envoyant un message texte.
Vous pouvez donner $ 10 de cette façon.
>> Les assaillants, ce qu'ils ont fait, c'est qu'ils mis en place
comptes à l'étranger, et ils intégrer dans les logiciels malveillants
que le téléphone envoie un message texte SMS premium,
dire, quelques fois par jour, et à la fin du mois, vous réalisez que vous avez passé
dizaines ou peut-être même des centaines de dollars, et ils repartent avec l'argent.
Cette devenue si mauvaise que c'était la première chose que l'Android
Marché ou le lieu-il Google était l'Android Marketplace à l'époque,
et c'est maintenant Google Play-la première chose que Google a commencé à vérifier pour.
Lorsque Google a commencé à distribuer les applications Android dans leur app store
ils ont dit qu'ils ne vont pas vérifier quoi que ce soit.
Nous tirerons des applications une fois que nous avons été informés qu'ils ont cassé nos termes de service,
mais nous n'allons pas vérifier quoi que ce soit.
Eh bien, il ya environ un an, il a tellement mal avec cette prime message texte SMS logiciels malveillants
que c'est la première chose qu'ils ont commencé à vérifier pour.
Si une application peut envoyer des messages texte SMS
ils examinent en outre que l'application manuellement.
Ils recherchent les API qui appellent cette,
et maintenant depuis Google a étendu,
mais c'était la première chose qu'ils ont commencé à chercher.
>> D'autres applications qui ont fait des messages texte SMS,
ce Qicsomos Android, je suppose qu'il est appelé.
Il y avait cet événement courant sur le mobile où ce CarrierIQ est sorti
que les logiciels espions mis sur l'appareil par les transporteurs,
afin que les gens voulaient savoir si leur téléphone était vulnérable à cela,
et ce fut une application gratuite qui a testé cela.
Bien sûr, ce que cette application fait était-il envoyé prime messages texte SMS,
si en testant pour voir si vous êtes infecté par des logiciels espions
vous avez chargé les logiciels malveillants sur votre appareil.
Nous avons vu la même chose se produire au dernier Super Bowl.
Il y avait une version fausse du jeu de football Madden
qui a envoyé la prime des messages texte SMS.
Il fait essayé de créer un réseau de bot trop sur l'appareil.
Ici, j'ai quelques exemples.
Fait intéressant, Apple a été assez intelligent,
et ils ne permettent pas aux applications d'envoyer des messages texte SMS à tous.
Aucune application ne peut le faire.
C'est un excellent moyen de se débarrasser de toute une classe de vulnérabilité,
mais sur Android, vous pouvez le faire, et bien sûr, sur BlackBerry, vous pouvez le faire aussi.
Il est intéressant que le BlackBerry vous n'avez besoin que des autorisations d'Internet
d'envoyer un message texte SMS.
>> L'autre chose vraiment que nous recherchons
quand nous cherchons à voir si quelque chose est malveillant est n'importe quel type de
activité réseau non autorisé, comme regarder l'activité du réseau
l'application est censée avoir sa fonctionnalité,
et regarder cette autre activité de réseau.
Peut-être une application, au travail, doit obtenir des données sur HTTP,
mais si elle fait des choses par e-mail ou SMS ou Bluetooth ou quelque chose comme ça
maintenant que l'application pourrait être malveillant, donc c'est une autre chose que vous pouvez inspecter pour.
Et sur cette diapositive, j'ai quelques exemples.
Une autre chose intéressante que nous avons vu avec des logiciels malveillants qui s'est passé en 2009,
et il est arrivé dans une grande manière.
Je ne sais pas si c'est arrivé tellement depuis, mais c'était une application
que personnifiés une autre application.
Il y avait un ensemble d'applications, et il a été surnommé l'attaque 09Droid,
et quelqu'un a décidé qu'il y avait beaucoup de petites, moyennes, des banques régionales
qui n'ont pas les applications de banque en ligne,
si ce qu'ils ont fait, c'est qu'ils ont construit environ 50 applications bancaires en ligne
que tout ce qu'ils ont fait, c'est de prendre le nom d'utilisateur et mot de passe
et vous rediriger vers le site.
Et donc ils ont mis les tous dans le marché Google,
dans le marché Android, et quand quelqu'un recherché pour voir si leur banque
eu une demande qu'ils trouveraient l'application de faux,
qui a recueilli leurs informations d'identification, puis les redirigé vers leur site web.
La façon dont ce fait est devenu-les applications étaient là pour quelques semaines,
et il y avait des milliers et des milliers de téléchargements.
>> La façon dont cela est venu à la lumière avait quelqu'un avait un problème
avec l'une des applications, et ils ont appelé leur banque,
et ils ont appelé la ligne de soutien à la clientèle de leur banque, et dit:
«Je vais avoir un problème avec votre application de services bancaires mobiles."
"Pouvez-vous m'aider?"
Et ils ont dit, "Nous n'avons pas une application de services bancaires mobiles."
Cela a commencé l'enquête.
Cette banque s'appelle Google, puis Google a regardé et a dit,
"Wow, le même auteur a écrit 50 applications bancaires," et tous ont pris vers le bas.
Mais certainement cela pourrait se produire à nouveau.
Il ya la liste de toutes les différentes banques ici
qui faisaient partie de cette escroquerie.
L'autre chose que l'application peut faire est présente l'interface utilisateur d'une autre application.
Alors qu'il est en cours d'exécution, il pourrait apparaître le Facebook UI.
Il dit que vous devez mettre dans votre nom d'utilisateur et mot de passe pour continuer
ou mettre en place un nom d'utilisateur et mot de passe pour l'interface utilisateur d'un site Web
que peut-être l'utilisateur utilise juste pour essayer de tromper l'utilisateur
en mettant leurs pouvoirs po
C'est vraiment une droite parallèle des attaques e-mail de phishing
où quelqu'un vous envoie un message électronique
et vous donne essentiellement une interface faux pour un site Web
que vous avez accès.
>> L'autre chose que nous recherchons dans le code malveillant est la modification du système.
Vous pouvez rechercher tous les appels API qui nécessitent les privilèges de root
pour exécuter correctement.
Modification web proxy de l'appareil serait quelque chose qui demande
ne devrait pas être en mesure de le faire.
Mais si l'application a du code là pour ça
vous savez que c'est probablement une application malveillante
ou très fortement susceptible d'être une application malveillante,
et donc ce qui se passerait, c'est que l'application aurait un moyen de l'escalade de privilège.
Il aurait une certaine escalade de privilège exploiter
dans l'application, et puis une fois qu'il élever leurs privilèges
il ferait ces modifications du système.
Vous pouvez trouver des logiciels malveillants qui a une escalade de privilège
en elle même sans savoir comment l'escalade de privilège
exploiter qui va se passer, et c'est une façon agréable et facile
à la recherche de logiciels malveillants.
DroidDream était probablement le plus célèbre morceau de malware Android.
Je pense qu'il a touché près de 250 000 utilisateurs en quelques jours
avant qu'il ne soit constaté.
Ils reconditionnés 50 fausses demandes,
les mettre dans l'App Store Android,
et essentiellement, il utilise le code de jailbreak Android pour élever les privilèges
puis installer un commandement et de contrôle et tourner toutes les victimes
dans un filet de bot, mais vous pourriez avoir détecté ce
si vous numérisez l'application et à la recherche d'
Appels API que l'autorisation de racine nécessaire pour exécuter correctement.
>> Et il ya un exemple ici j'ai qui est en train de changer le proxy,
et c'est en fait seulement disponible sur l'Android.
Vous pouvez le voir, je vais vous donner beaucoup d'exemples sur Android
car c'est là que l'écosystème malwares les plus actifs est
parce que c'est vraiment facile pour un attaquant d'obtenir un code malveillant
dans le marché Android.
Ce n'est pas si facile à faire que dans le App Store d'Apple
parce que Apple exige des développeurs de s'identifier
et signer le code.
En fait, ils vérifier qui vous êtes, et Apple est en fait scrutent les applications.
Nous ne voyons pas beaucoup de vrai malware où le dispositif est se compromise.
Je vais parler de quelques exemples où c'est vraiment la vie privée qui est de se compromettre,
et c'est ce qui se passe réellement sur l'appareil d'Apple.
Une autre chose à regarder de code malveillant, le code risque dans les dispositifs
est logiques ou à des bombes, et des bombes à retardement sont probablement
beaucoup plus facile à regarder pour que les bombes logiques.
Mais avec des bombes à retardement, ce que vous pouvez faire est que vous pouvez regarder pour
endroits dans le code où le temps est testé ou un temps absolu est recherchée
avant certaines fonctionnalités dans l'application arrive.
Et cela pourrait être fait pour cacher que l'activité de l'utilisateur,
si ça se passe tard dans la nuit.
DroidDream fait de son activité 23 heures-8 heures, heure locale
à essayer de le faire alors que l'utilisateur pourrait ne pas être en utilisant leur appareil.
>> Une autre raison de le faire est si les gens utilisent l'analyse du comportement d'une application,
l'exécution de l'application dans un bac à sable pour voir ce que le comportement de l'application est,
ils peuvent utiliser la logique basée sur le temps de faire de l'activité
lorsque l'application n'est pas dans le bac à sable.
Par exemple, un magasin d'application comme Apple
exécute l'application, mais ils n'ont probablement pas exécuter chaque application pour, disons, 30 jours
avant de l'approuver, de sorte que vous pouvez mettre
logique dans votre application qui a dit, d'accord, que faire la mauvaise chose
après 30 jours se sont écoulés ou après les 30 jours suivant la date de publication de la demande,
et qui peuvent aider à masquer le code malveillant de personnes inspection pour elle.
Si les entreprises anti-virus sont en cours d'exécution choses dans des sandbox
ou les app stores sont eux-mêmes ce qui peut aider
cacher que de cette inspection.
Maintenant, le revers de la médaille est qu'il est facile à trouver avec l'analyse statique,
donc en fait inspecter le code que vous pouvez consulter pour tous les lieux
où l'application teste le temps et inspecter cette façon.
Et ici, j'ai quelques exemples sur ces trois plates-formes différentes
comment le temps peut être contrôlé par l'application fabricant
si vous savez ce que vous cherchez si vous inspecter l'application statique.
>> Je suis juste allé à travers tout un tas de différentes activités malveillantes
que nous avons vu à l'état sauvage, mais ceux qui sont les plus fréquents?
Cette même étude de North Carolina State mobile Genome Project
publié des données, et il y avait essentiellement quatre domaines
qu'ils virent où il y avait beaucoup d'activité.
37% des applications a une escalade de privilège,
de sorte qu'ils ont un certain type de code jailbreak là
où ils ont essayé de grimper privilèges, afin qu'ils puissent
ne commandes API fonctionnant comme le système d'exploitation.
45% des applications là-bas n'a SMS premium,
de sorte que c'est un pourcentage énorme qui tente de monétiser directement.
93% l'ont fait télécommande, si ils ont essayé de mettre en place un filet de bot, un filet de bot mobile.
Et 45% récolté des informations d'identification
comme les numéros de téléphone, UUID, localisation GPS, les comptes utilisateurs,
et cela ajoute à plus de 100 parce que la plupart des logiciels malveillants essaie de faire un peu de ces choses.
>> Je vais passer à la seconde moitié et parler des vulnérabilités de code.
Il s'agit de la deuxième moitié de l'activité risquée.
C'est là essentiellement le développeur fait des erreurs.
Un développeur légitime écrire une application légitime
est de faire des erreurs ou ignore les risques de la plate-forme mobile.
Ils ne savent pas comment faire une application mobile sécurisée,
ou parfois le développeur ne se soucie pas de mettre l'utilisateur en danger.
Parfois une partie de leur modèle d'affaires pourrait être
récolte des informations personnelles de l'utilisateur.
C'est en quelque sorte l'autre catégorie, et c'est pourquoi une partie de cette malveillants
par rapport commence légitimes à saigner plus parce qu'il ya différence d'opinions
entre ce que l'utilisateur veut et ce que l'utilisateur estime risqué
et ce que le développeur de l'application considère risqué.
Bien sûr, ce n'est pas les données du développeur d'application dans la plupart des cas.
>> Et puis finalement, une autre façon ce qui se passe est un développeur peut lier à
une bibliothèque partagée qui a vulnérabilités ou ce comportement à risque en ce
à leur insu.
La première catégorie est la fuite de données sensibles,
et c'est à ce moment l'application recueille des renseignements
comme l'emplacement, les informations du carnet d'adresses, informations sur le propriétaire
et envoie que l'appareil hors tension.
Et une fois qu'il est hors de l'appareil, nous ne savons pas ce qui se passe avec cette information.
Il peut être stocké de manière non sécurisée par le développeur de l'application.
Nous avons vu les développeurs d'applications en pâtir,
et les données qu'ils stockage se fait prendre.
Cela s'est passé il ya quelques mois à un développeur en Floride
où un grand nombre de c'était UUID iPad et noms de périphériques
ont été divulgués parce que quelqu'un, je pense que c'est anonyme,
selon ce faire, ont fait irruption dans les serveurs de ce développeur
et des millions d'iPad UUID volé
et des noms d'ordinateur.
Pas les informations les plus à risque,
mais si c'était le stockage des noms d'utilisateur et mots de passe
et l'adresse du domicile?
Il ya beaucoup d'applications qui stockent ce type d'information.
Le risque est là.
>> L'autre chose qui puisse arriver, c'est que si le développeur ne prend pas soin
pour sécuriser le canal de données, et c'est une autre grande vulnérabilité que je vais parler,
que les données sont envoyées en clair.
Si l'utilisateur est sur un réseau Wi-Fi publique
ou quelqu'un renifle l'Internet quelque part
le long du chemin de données qui est exposé.
Un très célèbre affaire de cette fuite d'informations qui s'est passé avec Pandora,
et c'est quelque chose que nous avons étudié au VeraCode.
Nous avons entendu qu'il y avait un je pense que c'était une Commission fédérale du commerce
enquête en cours avec Pandora.
Nous avons dit, "Qu'est-ce qui se passe là-bas? Commençons creuser dans l'application Pandora."
Et ce que nous avons déterminé était l'application Pandora recueillies
votre sexe et votre âge,
et il a également accédé à votre position GPS et l'application Pandora
fait cela pour ce qu'ils ont dit étaient des raisons légitimes.
La musique qu'ils jouaient-Pandora est une application-musique en streaming
la musique qu'ils jouaient n'a été autorisé aux États-Unis,
de sorte qu'ils devaient vérifier à respecter leurs accords de licence qu'ils avaient
pour la musique que l'utilisateur était aux Etats-Unis.
Ils voulaient aussi se conformer à l'avis parental
autour de la langue des adultes dans la musique,
et il s'agit d'un programme volontaire, mais ils ont voulu se conformer à cette
et ne pas jouer des paroles explicites aux enfants 13 ans et moins.
>> Ils avaient des raisons légitimes pour la collecte de ces données.
Leur application a les autorisations pour le faire.
Les utilisateurs pensaient que c'était légitime. Mais ce qui s'est passé?
Ils reliés en trois ou quatre bibliothèques d'annonces différentes.
Maintenant, tout d'un coup toutes ces bibliothèques d'annonces
qui ont accès à la même information.
Les bibliothèques d'annonces, si vous regardez le code dans les bibliothèques de l'annonce
ce qu'ils font est toutes les bibliothèques de l'annonce dit
"Est-ce que mon application autorisé à accéder à la localisation GPS?"
"Oh, il ne? Bon, dis-moi la position GPS."
Chaque bibliothèque seule annonce fait que,
et si l'application n'a pas l'autorisation de GPS
il ne sera pas en mesure de l'obtenir, mais si c'est le cas, il l'obtiendra.
C'est là que le modèle d'affaires des bibliothèques de l'annonce
est opposée à la vie privée de l'utilisateur.
Et il ya eu des études là-bas qui va dire si vous savez l'âge
d'une personne et que vous savez leur emplacement
où ils dormir la nuit, parce que vous avez leurs coordonnées GPS
pendant qu'ils dorment peut-être, vous savez exactement qui est cette personne
parce que vous pouvez déterminer quel membre de ce ménage est cette personne.
Vraiment ceci est d'identifier les annonceurs
exactement qui vous êtes, et il semble que c'était légitime.
Je veux juste que ma musique en streaming, et c'est la seule façon de l'obtenir.
>> Eh bien, nous avons exposé ce.
Nous avons écrit ce dans plusieurs messages de blog,
et il s'est avéré que quelqu'un du magazine Rolling Stone
lire l'un de nos messages de blog et écrit leur propre blog dans Rolling Stone à ce sujet,
et le lendemain Pandora pensait que c'était une bonne idée
de supprimer les bibliothèques de l'annonce de leur application.
Pour autant que je sais qu'ils sont la seule-ils devraient être félicités.
Je pense qu'ils sont le seul type freemium de l'application qui a fait cela.
Toutes les autres applications freemium ont ce même comportement,
de sorte que vous avez à penser à ce genre de données que vous donnez
ces applications freemium car tout va pour les annonceurs.
Praetorian également fait une étude sur les bibliothèques partagées et dit,
"Regardons ce que les bibliothèques partagées sont les bibliothèques partagées meilleurs», et ce fut les données.
Ils ont analysé 53 000 >> applications,
et la bibliothèque partagée numéro 1 était Admob.
Il était en fait dans 38% des applications là-bas,
si 38% des applications que vous utilisez
sont susceptibles récolte vos informations personnelles
et de l'envoyer aux réseaux publicitaires.
Apache et Android étaient 8% et 6%,
et puis ces autres vers le bas au fond, Google Ads, Flurry,
Mob Ville et Millennial Media,
ce sont toutes les entreprises de publicité, puis, curieusement,
4% lié à la bibliothèque Facebook
probablement à faire l'authentification via Facebook
si l'application pourrait authentifier Facebook.
Mais cela signifie aussi que la société Facebook contrôle de code
C'est en cours d'exécution dans 4% des applications mobiles Android là-bas,
et ils ont accès à toutes les données que cette application a la permission de venir.
Facebook tente essentiellement à vendre des espaces publicitaires.
C'est leur modèle d'affaires.
>> Si vous regardez l'ensemble de cet écosystème avec ces autorisations
et les bibliothèques partagées que vous commencez à voir que
vous avez beaucoup de risques dans une application soi-disant légitime.
La même chose similaire qui s'est passé avec Pandora
arrivé avec une application appelée chemin,
et Chemin pensé qu'ils étaient utiles, les développeurs amicales.
Ils essayaient juste pour vous donner une expérience utilisateur,
et il s'est avéré que, sans intervention de l'utilisateur ou de dire quoi que ce soit l'utilisateur-
et ce qui s'est passé sur l'iPhone et sur Android,
Pandore application était sur iPhone et Android
que l'application de chemin a été saisissant votre carnet d'adresses dans son intégralité
et l'uploader sur le chemin juste au moment où vous avez installé et exécuté l'application,
et ils n'ont pas vous dire à ce sujet.
Ils pensaient que c'était vraiment utile pour vous
pour être en mesure de partager avec tous les gens de votre carnet d'adresses
que vous utilisez l'application Path.
>> Eh bien, évidemment Chemin pensé que c'était super pour leur entreprise.
Pas terrible pour l'utilisateur.
Vous devez penser que c'est une chose si peut-être un adolescent
est d'utiliser cette application et leurs dizaines d'amis sont là,
mais si c'est le PDG d'une entreprise qui installe chemin
et puis tout d'un coup leur carnet d'adresses tout est là-haut?
Vous allez obtenir beaucoup d'informations de contact potentiellement précieux
pour beaucoup de gens.
Un journaliste du New York Times, vous pourriez être en mesure d'obtenir le numéro de téléphone
pour les anciens présidents de leur carnet d'adresses,
si évidemment beaucoup d'informations sensibles est transféré avec quelque chose comme ça.
Il y avait un gros volet de cette chemin qui s'est excusé.
Ils ont changé leur application, et il a même eu une incidence Apple.
Apple a déclaré, "Nous allons forcer appli fournisseurs pour inviter les utilisateurs
si ils vont chercher leur carnet d'adresses entier ".
>> Il ressemble à ce qui se passe ici est
quand il ya une grande violation de la vie privée et il fait la presse
nous voyons un changement là-bas.
Mais bien sûr, il ya d'autres choses là-bas.
L'application LinkedIn récolte vos entrées d'agenda,
mais Apple ne fait pas l'utilisateur est invité à ce sujet.
Les entrées de calendrier peuvent avoir des informations sensibles en eux aussi.
Où allez-vous tracer la ligne?
C'est vraiment une sorte d'un lieu en évolution
où il n'y a vraiment pas de bonne qualité là-bas
pour les utilisateurs à comprendre quand leur information va être à risque
et quand ils vont savoir c'est d'être prise.
Nous avons écrit une application à VeraCode appelé Adios,
et essentiellement, il vous a permis de pointer l'application à votre répertoire iTunes
et de regarder toutes les applications qui ont été récoltent votre carnet d'adresse.
Et comme vous pouvez le voir sur cette liste ici, Angry Birds,
AIM, AroundMe.
Pourquoi Angry Birds ne besoin de votre carnet d'adresses?
Je ne sais pas, mais il ne quelque sorte.
>> C'est quelque chose que beaucoup, de nombreuses applications font.
Vous pouvez inspecter le code pour cela.
Il ya API bien définies pour iPhone, Android et BlackBerry
pour obtenir au carnet d'adresses.
Vous pouvez très facilement inspecter pour cela, et c'est ce que nous avons fait dans notre application Adios.
La catégorie suivante, dangereux sensible de stockage de données,
est quelque chose où les développeurs prennent quelque chose comme une broche ou un numéro de compte
ou un mot de passe et le stocker en clair sur le dispositif.
Pire encore, ils pourraient stocker dans une zone sur le téléphone
qui est accessible à l'échelle mondiale, comme la carte SD.
Vous voyez ça plus souvent sur Android car Android permet pour une carte SD.
Dispositifs IPhone pas.
Mais nous avons même vu cela se produire dans une application Citigroup.
Leur application bancaire en ligne stocké les numéros de compte non sécurisée,
juste en clair, si vous avez perdu votre appareil,
essentiellement que vous avez perdu votre compte bancaire.
C'est pourquoi je ne fais pas personnellement bancaire sur mon iPhone.
Je pense que c'est trop risqué en ce moment pour faire ce genre d'activités.
>> Skype fait la même chose.
Skype, bien sûr, a un solde de compte, un nom d'utilisateur et mot de passe
que l'accès de cet équilibre.
Ils entreposaient toutes ces informations en clair sur le périphérique mobile.
J'ai ici quelques exemples de création de fichiers
qui n'ont pas les bonnes autorisations ou écriture sur le disque
et ne pas avoir de cryptage se produire pour que.
Cette zone suivante, dangereux sensible la transmission de données,
J'ai fait allusion à quelques reprises, et à cause de la connexion Wi-Fi
c'est quelque chose que les applications absolument besoin de faire,
et c'est probablement ce que nous voyons vont mal le plus.
Je dirais-en fait, je pense que j'ai les données réelles,
mais il est près de la moitié des applications mobiles
bousiller faire SSL.
Ils n'ont tout simplement pas utiliser les API correctement.
Je veux dire, tout ce que vous avez à faire est de suivre les instructions et utiliser les API,
mais ils ne les choses comme ne pas vérifier si il est un certificat non valide à l'autre extrémité,
pas vérifier si l'autre extrémité essaie de faire une attaque protocole de déclassement.
>> Les développeurs, ils veulent obtenir leur case, non?
Leur exigence est de l'utiliser pour vendre. Ils ont utilisé ce à vendre.
L'obligation est de ne pas l'utiliser pour vendre en toute sécurité,
et c'est donc la raison pour laquelle toutes les applications qui utilisent SSL pour sécuriser les données
comme il est transmis hors du dispositif vraiment besoin d'être inspecté
veiller à ce que a été mis en œuvre correctement.
Et ici, j'ai quelques exemples où vous pouvez voir une application
peut-être utiliser HTTP au lieu de HTTPS.
Dans certains cas, les applications seront revenir à HTTP
si le HTTPS ne fonctionne pas.
J'ai un autre appel ici sur Android où ils ont désactivé le contrôle de certificat,
si une attaque man-in-the-middle peut arriver.
Un certificat non valide sera acceptée.
Ce sont tous les cas où vont les attaquants d'être en mesure d'obtenir sur
la même connexion Wi-Fi et l'accès à l'utilisateur toutes les données
C'est d'être envoyé sur Internet.
>> Et enfin, la dernière catégorie que j'ai ici est le mot de passe codé en dur et clés.
Nous voyons effectivement beaucoup de développeurs utilisent le même style de codage
ce qu'ils ont fait quand ils ont été la construction d'applications serveur Web,
ils sont donc la construction d'une application serveur Java, et ils coder la clé.
Eh bien, quand vous construisez une application serveur, oui,
coder la clé n'est pas une bonne idée.
Il est donc difficile à modifier.
Mais ce n'est pas si mal sur le côté serveur car qui a accès à la côté serveur?
Seuls les administrateurs.
Mais si vous prenez le même code et que vous avez versé la parole à une application mobile
maintenant tout le monde qui a cette application mobile a accès à cette clé codé en dur,
et nous fait voir ce beaucoup de fois, et j'ai quelques statistiques
combien de fois nous voyons cela se produire.
Il était réellement en exemple de code qui MasterCard publié
sur la façon d'utiliser leur service.
L'exemple de code montre comment vous suffit de prendre le mot de passe
et le mettre dans une chaîne codée en dur là,
et nous savons comment les développeurs aiment à copier et coller des extraits de code
quand ils essaient de faire quelque chose, si vous copiez et collez l'extrait de code
qu'ils ont donné comme exemple de code, et vous avez une demande d'insécurité.
>> Et ici nous avons quelques exemples.
Cette première est celle que nous voyons un terrain où ils hardcode
le droit de données dans une URL qui est envoyé.
Parfois, nous voyons chaîne passe = mot de passe.
C'est assez facile à détecter, ou mot de passe de chaîne sur BlackBerry et Android.
C'est en fait assez facile à vérifier, car presque toujours
les noms des développeurs la variable qui est maintenant le mot de passe
une variante de mot de passe.
J'ai mentionné que nous faisons l'analyse statique à VeraCode,
nous avons donc analysé plusieurs centaines de demandes Android et iOS.
Nous avons construit des modèles complets d'entre eux, et nous sommes en mesure de les analyser
pour différentes vulnérabilités, en particulier les vulnérabilités dont je parlais,
et j'ai quelques données ici.
68,5% des applications Android que nous avons examinés
avait cassé le code de chiffrement,
qui, pour nous, nous ne pouvons pas détecter si vous avez fait votre propre routine de cryptage,
pas que c'est une bonne idée, mais cela est fait en utilisant les API publiées
qui sont sur la plate-forme mais les faire de manière
que la crypto serait vulnérable, 68,5.
Et c'est pour les gens qui nous envoient leurs applications en réalité parce
ils pensent que c'est une bonne idée de faire des tests de sécurité.
Ce sont déjà des gens qui pensent probablement en toute sécurité,
il est donc probablement encore pire.
>> Je n'ai pas parlé de l'injection de saut de ligne de commande.
C'est quelque chose que nous vérifions, mais ce n'est pas si risqué un problème.
La fuite d'informations, c'est là que les données sensibles est exclu du dispositif.
Nous avons constaté que dans 40% des applications.
Temps et de l'Etat, ceux qui sont la race questions de type de condition, généralement assez difficiles à exploiter,
donc je n'ai pas parlé de cela, mais nous regardé.
23% avaient des problèmes d'injection SQL.
Beaucoup de gens ne savent pas que beaucoup d'applications
utiliser un petit peu de base de données SQL sur leur extrémité arrière pour stocker des données.
Eh bien, si les données que vous saisir sur le réseau
a chaînes SQL d'attaque par injection en elle
quelqu'un peut compromettre l'appareil grâce à cela,
et je pense que nous trouver environ 40% des applications Web ont ce problème,
qui est un problème épidémique énorme.
Nous trouvons 23% du temps dans les applications mobiles
et c'est probablement parce que beaucoup plus d'applications web utilisent SQL que mobile.
>> Et puis nous voyons encore quelques cross-site scripting, les questions d'autorisation,
puis la gestion des titres de compétences, c'est là que vous avez votre mot de passe codé en dur.
Dans 5% des demandes, nous voyons que.
Et puis nous avons des données sur iOS.
81% avaient des problèmes de gestion des erreurs.
Il s'agit plus d'un problème de qualité de code,
mais 67% avaient des problèmes cryptographiques, donc pas tout à fait aussi mauvais que Android.
Peut-être que les API sont un peu plus facile, les exemples de codes un peu mieux sur iOS.
Mais encore un pourcentage très élevé.
Nous avons eu 54% de fuites d'informations,
environ 30% avec des erreurs de gestion de la mémoire tampon.
C'est là où il pourrait potentiellement être un problème de corruption de mémoire.
Il s'avère que ce n'est pas tant d'un problème pour l'exploitation
sur iOS car tout le code doit être signé,
il est si difficile pour un attaquant d'exécuter du code arbitraire sur iOS.
qualité de code, traversée de répertoire, mais la gestion des informations d'identification ici à 14,6%,
si pire que sur l'Android.
Nous avons des gens pas la manipulation des mots de passe correctement.
Et puis les erreurs numériques et dépassement de mémoire tampon,
ceux-ci sont plus va avoir des problèmes de qualité de code sur iOS.
>> C'était pour ma présentation. Je ne sais pas si nous sommes hors du temps ou pas.
Je ne sais pas s'il ya des questions.
[Homme] Une question rapide autour de la fragmentation et le marché Android.
Apple à moins possède correction.
Ils font un bon travail de l'obtenir là-bas alors que moins dans l'espace Android.
Vous devez presque de jailbreaker votre téléphone pour rester au courant
avec la version actuelle d'Android.
Ouais, c'est un énorme problème et si vous pensez-
[Homme] Pourquoi ne pas vous répéter?
>> Oh, c'est vrai, de sorte que la question était de savoir à propos de la fragmentation
du système d'exploitation sur la plate-forme androïde?
Comment cela affecte-t le niveau de risque de ces dispositifs?
Et c'est effectivement un énorme problème parce que ce qui se passe est
les appareils plus anciens, quand quelqu'un arrive avec un jailbreak pour cet appareil,
c'est essentiellement une escalade de privilège, et jusqu'à ce que ce système d'exploitation est mis à jour
tout logiciel malveillant peut alors utiliser cette vulnérabilité pour compromettre totalement le dispositif,
et ce que nous voyons sur l'Android est afin d'obtenir un nouveau système d'exploitation
Google doit mettre le système d'exploitation, puis le fabricant de matériel
a pour le personnaliser, et le transporteur a le personnaliser et de le livrer.
Vous avez essentiellement trois pièces mobiles ici,
et il tourne que les transporteurs ne se soucient pas,
et les fabricants de matériel ne se soucient pas, et Google ne sont pas les pousser assez
de faire quelque chose, si essentiellement plus de la moitié des appareils là-bas
avoir des systèmes d'exploitation qui ont ces vulnérabilités d'escalade de privilèges en eux,
et donc si vous avez des logiciels malveillants sur votre appareil Android, il est beaucoup plus un problème.
>> D'accord, merci beaucoup.
[Applaudissements]
[CS50.TV]