Une importante faille de sécurité a été trouvée au sein d’Android. Elle pourrait représenter le saint Graal des pirates car cette brèche, vieille de quatre ans, concerne pratiquement toutes les versions du système mobile de Google.
Crédits : greyweed, licence Creative Commons
Le saint Graal de la faille de sécurité
La plateforme Android écrase littéralement la concurrence en volume de ventes et en parts de marché, grâce notamment à la pluralité des modèles proposés par les constructeurs. Depuis plusieurs années, la situation a abouti à un marché fragmenté, les smartphones et tablettes étant proposés avec des versions différentes qui ne sont pas forcément mises à jour, même si le problème est beaucoup moins présent avec les appareils récents. De fait, si une faille commune à toutes les versions était détectée, elle mettrait en danger de très nombreux utilisateurs.
C’est précisément le cas avec la découverte faite par la société Bluebox : une brèche de sécurité capable de toucher 99 % des appareils Android à cause de son âge plus que vénérable. La faille remonte au moins jusqu’à Android 1.6, autrement dit une version vieille de quatre ans. Depuis, 900 millions d’appareils ont été vendus avec le système selon Bluebox, ce qui permet aux pirates une exploitation dans une échelle sans précédent.
La faille en question est particulièrement grave : elle permet la modification d’un paquet d’application (APK) sans que cela ne modifie la signature électronique. En clair, une application parfaitement légitime pourrait être trafiquée pour la rendre « vérolée » sans que personne ne puisse détecter le changement. La boutique d’applications ne verrait pas la différence car la signature électronique serait toujours la même. Or, cette même signature n’est censée pouvoir être faite que par l’éditeur authentique de l’application.
Des privilèges dépendant de l'application visée
La situation est pour Bluebox encore plus complexe lorsque l’on considère les applications fournies par les constructeurs tels que HTC, Samsung, Motorola et ainsi de suite. Ces applications maison possèdent le plus souvent des privilèges élevés car elles sont parfois spécifiques à un matériel donné. On pensera par exemple à HTC et à Beat Music. Ce peut être le cas également avec celles qui sont fournies par les partenaires du constructeur, comme Cisco avec sa solution VPN AnyConnect. À cause des privilèges inhérents à ces applications, un malware pourrait avoir accès à des privilèges élevés lui donnant tout pouvoir sur le système.
Ce contrôle pourra s’exercer de deux manières :
- Lire n’importe quel type de données stockées sur le téléphone : les SMS, les emails, les informations stockées par les applications, les pièces-jointes, les identifiants des différents comptes, etc.
- Agir : passer des appels arbitrairement, envoyer des SMS, utiliser la caméra, enregistrer le contenu des appels en direct…
Le problème est qu’il faudrait maintenant que tous les appareils soient mis à jour. Et là, évidemment, il existe un pépin de taille : de nombreux appareils ne sont plus supportés, tout en pouvant encore accéder à Google Play. On pense notamment à la myriade de modèles restés bloqués à Android 2.3 alors que beaucoup d’applications demandent au minimum cette version pour fonctionner, les rendant ainsi compatibles. On peut par exemple prendre le cas de l’application Facebook qui serait modifiée et dont la clé de signature ne serait pas modifiée, empêchant Android de voir la différence et laissant alors le malware agir à sa guise.
La capture ci-dessus montre comment Bluebox a pu utiliser les privilèges élevés d’une application fournie avec un appareil HTC pour modifier la version du Baseband, une information qui normalement n’est donnée que depuis le firmware et qui n’est donc pas modifiable.
Bluebox indique que les détails plus complets de la faille seront révélés lors de la prochaine conférence Black Hat qui se tiendra du 27 juillet au 1er août à Las Vegas. La société de sécurité indique cependant que les informations ont été transmises confidentiellement à Google en février dernier et que c’est désormais aux constructeurs de réagir en proposant de nouveaux firmwares.
En attendant, les utilisateurs devraient faire très attention à la source d’installation de leurs applications. Dans les entreprises, les stratégies BYOD (Bring your own device) devraient être complétées d’une obligation de mettre à jour les appareils.
Commentaires (176)
en même temps le systeme Android permet très simplement d’autoriser l’exécution d’APK tiers …
du coup même sans faille de sécurité les risques pour un utilisateur non averti sont très elevés …
Ben oui, c’est bien connu, cette faille s’appelle PRISM
" />
J’ai lu un article ce matin indiquant que le S4 ne semblait pas touché, ce qui tendrait à prouver que la faille était connue depuis un certain temps
C’est très flippant… je me demande comment google va pourvoir y remédier avec la pléthore de versions en circulation…
Avec la plupart des fabricants qui laissent tomber le téléphone à peine au bout d’un an quand c’est pas moins, ça me fait marrer ceux qui disent que c’est pas grave de pas avoir de maj (rapport à la news sur le HTC One S).
On va moins rigoler quand tous les téléphones seront pourris. Comme à la grande époque de Windows tiens.
La faille en question est particulièrement grave : elle permet la modification d’un paquet d’application (APK) sans que cela ne modifie la signature électronique. En clair, une application parfaitement légitime pourrait être trafiquée pour la rendre « vérolée » sans que personne ne puisse détecter le changement.
Ok, mais quel est le point d’entrée de cette faille? Une application tierce installée hors market? Ou bien autre chose?
La version 5.0 key lime pie doit théoriquement pouvoir supporter tout les devices android du marché. Mais cette version n’apparaitra que dans au moins 1 an…
J’ai lu un article ce matin indiquant que le S4 ne semblait pas touché, ce qui tendrait à prouver que la faille était connue depuis un certain temps
Suite à une palpitante lecture sur les black hat via Korben :http://goo.gl/aDYQS on devrait pouvoir en conclure que oui, le temps qu’une faille soit médiatisée elle a parcouru son petit bonhomme de chemin.
En même temps, sauf à ce que le play store ne soit piraté, la faille ne concerne que les boutiques d’application tierces, non ?
Ça me fait bizarre de voir marquer android là où habituellement on voyait plutôt windows.
Au boulot google, pour corriger la faille.
Put*** que je suis content de pas être sous android
Ce n’est absolument pas une faille de sécurité !
La signature n’est pas un hash vérifiant la validité d’une app, c’est plutot un tag qui lui est accolé pour pouvoir vérifier les mises à jour, et avoir une validité lors d’un achat inApp.
On peut décompiler et recompiler n’omporte quel APK depuis toujours sans avoir à re-signer. Si cette fonctionnalité est bloquée, beaucoup de boîtes qui vendent des IDE vont couler.
C’est ridicule, pour nuire au public, on devrait soit :
Si l’une de ces deux condition n’est pas remplie, il n’y a absolument aucun moyen de nuire.
Et même si cette “faille” n’existait pas, l’une de ses deux conditions aurait déjà été suffisante pour faire faire ce que l’on veut à n’importe quel téléphone…
Autant affirmer que tous les projets opensources ont une faille de sécurité :
On peut les forker et rajouter un virus…
C’est presque tout aussi ridicule comme alerte.
Pas de problème pour moi, je suis 24h/24 en mode avion
" />
" /> et c’est vrai (je n’utilise que mon ancien mobile)
" />
" />
Il apparaît qu’il suffirait de désactivé (fait par défaut) l’installation d’application depuis les sources extérieures.
Cela ne semble en effet pas une faille de sécurité mais plutôt l’idée que l’on pourrait télécharger un clone vérolé d’une application par ailleurs sur le store (mais clean) si on la télécharge depuis un endroit en dehors du store … ceci définissant qu’android ne certifie pas les applications qui ne viennent pas de son store … C’est plus une pub pour les store ultra-fermé que la définition d’une faille.
Et il n’est pas possible d’avoir un Android comme un Windows ou autre sur PC ?
Avoir Android avec ses mise à jour faites par Google et l’utilisation du matériel faite par les Drivers et mise à jour par le fabricant de téléphone (Samsung ou autre).
Et avoir un Android de base avec plusieurs drivers pour pouvoir lancer le téléphone avec les fonctions de bases…
Enfin je ne sais pas mais ça serait terrible comme évolution je trouve! Après ça empécherai pas d’ajouter des applications ou interface graphique les constructeurs mais on aurait le noyau android toujours à jour ^^.
Pour une fois que je suis content de tourner sur Windows (phone) concernant la sécurité
" />
Une raison de plus d’opter pour Firefox OS plus tard.
" />
Le plus marrant dans tout ça c’est :
Androïd c’est super sécurisé, c’est libre et en partie open-source, donc toute faille peut être corrigée, donc c’est génial.
Sauf que voilà, c’est la théorie. Mais en pratique voilà :
On a ici une faille majeure quand même, et qui pourra avoir la mise à jour sans faire de bidouilles : presque PERSONNE !
Pourquoi ? Parce que les appareils ne sont plus supportés en même pas l’espace d’un an (et que le temps de déploiement des mises à jour prend une éternité).
La faute à qui ? aux constructeurs qui pour des raisons de rentabilité sortent un flagship tous les 4 mois et délaissent les précédents aussi rapidement. Et le support des appareils bas/moyen de gamme n’en parlons pas …
Maintenant, au tour de Google de s’attaquer aux problèmes de sécurité. C’est un cauchemar pire que Windows, avec de nouvelles versions tous les ans même pas.
Et le problème dans le monde de la téléphonie, c’est que uniquement les dernières versions aux droits aux mises à jour de sécurité (par analogie, Windows a droit à ses maj pendant plusieurs années… )
Lëkki,Apple, Microsoft, aiment cette news.
+1 à Khalev
de plus
The Bluebox Security research team – Bluebox Labs – recently discovered a vulnerability in Android’s security model that allows a hacker to modify APK code without breaking an application’s cryptographic signature, to turn any legitimate application into a malicious Trojan, completely unnoticed by the app store, the phone, or the end user.
allows a hacker to modify APK code : on a pas de détails sur la manière de faire, on a simplement fait la supposition de compromission du compte développeur (pour démontrer que même sans autoriser l’installation d’app tierce on était vulnérables), mais c’est pas la porte d’entrée la plus discrète en effet.
L’installation d’une app hors market venant modifier un de tes APK favori (launcher, jeu, réseau social) me paraît être un vecteur beaucoup plus grave
@Shyfer :
tu compares des MAJ Windows OS X86 (de 3.0 a 8 ) à des telephones ?
interessant….
Windows a droit a ses MAJ pendants plusieurs années…..certes….
bien bien bien…., mais peut etre parce que la durée de vie d’un PC est plus longue ?
Je fais du dev pour une banque, ils ont des environnements en windows server 2000, 2005, 2008 et 2012….
bah pour tout ce qui est 2000 et 2005, on peut s’asseoir dessus pour les mises a jours
enfin bref, on ne compare pas des choux avec des carottes
Il faudrait que le contrôle se fasse au niveau du téléphone:
Un pop-up d’alerte et on retombe sur le problème de l’utilisateur qui clique sur oui/ok sans lire le message.
En cas de corruption du compte d’un développeur, il n’y a pas besoin de faille pour foutre la merde.
Bref, c’est pas vraiment une faille mais çà reste préoccupant.
Effet PRISM : oh la jolie faille commandé par la CIA à Google …
Donc en gros, comme au temps de Windows, les problèmes peuvent apparaître pour les gens qui “piratent” des applications majoritairement? Si on utilise son téléphone normalement, pas de problème (sauf si Gameloft se fait hacker son compte Google).
Restons honnête et tout ira bien.
Le problème arrivera réellement quand des failles exploitables via des sites internet (via java évidemment) apparaitront.
It’s not a bug, its a PRISM feature!
" />
Google peut désinstaller une application installée hors google play, ça c’est sûr j’en ai fait l’expérience
Quid de la vulnérabilité des versions custom d’android (type CyanogenMod) ?
Ceux qui parlent de sécurité et qui suggèrent de ne pas installer des applis hors Google Play doivent dans ce cas revoir leur jugement vis-à-vis de Windows … Parce que si avoir un OS sécurisé revient à n’installer que des applications vérifiées, alors dites moi en quoi Windows est moins sécurisé si on fait là aussi attention à ce que l’on installe …
Comme je l’ai dit, Google s’est empêtré avec la fragmentation d’Android, et surtout le refus de mise à jour des nombreux constructeurs. C’est comme s’ils avaient sorti Windows 95, 98, 2000, XP, 7 et 8 en l’espace de 4 ans, sans la moindre possibilité d’upgrade pour la plupart des consommateurs.
D’ou l’intérêt d’avoir un nexus qui profite des dernières MAJ.
J’espère que Google va se bouger.
Mais si google connait cette faille depuis février, peut être l’on-t-il corrigé dans les toutes dernières versions ?
Ah je comprend maintenant pourquoi mon S2 a fortement insisté ces dernières semaines pour se mettre à jour, alors qu’il n’avait jamais fait de mise à jour automatique en 4 ans.
Sinon la boite mettrait en danger 900M de devices rien qu’avec l’article qu’ils ont publié (et je pense même avant puisque le sujet de la conférence est connu depuis mai 2013, c’est le genre de truc qui guide les hackers en tout genre).
Bluestack ne fait qu’appliquer les menaces qu’a proféré Google vis-à-vis de Microsoft… avec un peu plus de délai quand même. Et au moins ça fera sortir des gens de l’illusion Android = système parfait sans failles.
Et sur les 900M d’appareils actuellement affectés, peut être 3 ou 4% recevront le correctif… les autre, bah niet comme d’hab :)
Knox… tu parles…
De toute façons, avec un Google aux ordres, comme Apple d’ailleurs, et Crosoft… il ne reste que BB pour être tranquille
j’ai pas lu tous les commentaires, mais sait-on si la dernière version est touché (4.2.2 sur Nexus 4)?
Merci NeVeS et Khalev, moi j’étais déjà toute chèvre….
Pour préciser un peu plus ce que viens de dire millman42
D’après http://developer.android.com/tools/publishing/app-signing.html, jarsigner est utilisé pour la signature.
D’après http://docs.oracle.com/javase/6/docs/technotes/tools/windows/jarsigner.html (recherche google oracle nsa….. bon bref), 2 fichiers sont incorporés dans le fichier .apk (qui n’est qu’un .jar). En particulier, un fichier .dsa (signature du .sf mentionné par millman42) qui contient la signature et le certificat.
Ainsi, @Glubglub : vous n’avez qu’à prendre 2 versions d’un .apk, les ouvrir, comparer le contenu de ces fichiers et nous dire si d’une part vous avez le même certificat, et d’autre part, si la signature est identique. (un peu compliqué si ce sont des fichiers binaires mais je ne pense pas sinon pour la portabilité on repassera)
Pour une personne qui, au début, parlait de “tag” qu’on pouvait remettre à l’identique, je (on, si je ne suis pas seul) pensais que vous aviez déjà vu la tête de cette signature. Maintenant que vous avez reconnu que signature = hash chiffré et vu la description du processus de signature et de vérification, je suis désolé mais pour ma part, c’est toute votre crédibilité que je remet en cause.
D’autant que le problème que vous venez enfin de soulever/admettre à la fin de ce débat est justement le sujet de la news. Vrai faille ou pas? Si oui, qu’elle est-elle?
Plus d’infos en anglais ici
Extraits :
“We are able to modify executing code in the APK that is installed. That is normally a red flag because that would break the signature,” Forristal said. “We can do it by not breaking the signature.
C’est assez clair tout en restant mystérieux.
Forristal said that Google has taken measures to protect applications in the Google Play store so that they’re not vulnerable to exploit. That, however, does not apply to third-party locations hosting APKs for download, or APKs that are exchanged via email or FTP, for example.
Ça al ‘air de vouloir dire que Google qui connaît la faille vérifie maintenant sur son store que les applications ne tirent pas profit de la faille, comme je le suggérais plus tôt.
Enfin :
It’s a very small fix; I have multiple devices in front of me that have it patched,” he said. “The fix is two lines of code in a very specific location. It requires a firmware update to the device, but fixing the bug is simple.
Bref, ça ressemble bien à un simple bug aux conséquences importantes.
tinnin!
http://i.imgur.com/yU7RAma.png
(dispo sur toutes les versions d’Android)
merci theverge
En faite il semblerait qu’on puisse rajouter certain fichier dans un apk qui vont être installé sans aucune vérification.
Il faut savoir que ce qui est signé dans un apk c’est le fichier contenant le sha1 de tout les fichiers et pas l’apk au complet. Si un des fichiers est modifié android le détecte car le sha1 change. De même si on modifie le fichier qui contient la sha1 la signature de celui-ci change et android le détecte. Cependant il serait possible de rajouter des fichiers dans le apk sans les rajouter dans cert.cf (le fichier qui contient les hashs sha1). La faille c’est que android va installer ces fichiers tout de même sans les vérifier car il ne sont pas dans cert.cf.
Cependant je n’est pas réussi à reproduire la faille je ne sais pas si sur mon téléphone la faille est corrigée où si faut faire quelque chose en plus.
la NSA avait bien besoin d’un faille dans androîd pour espionner tout le monde.
" />
mot clé static?
Je ne suis pas expert en JAVA (ni en dev au sens large), mais il me semble que le mot clé static permet de forcer la mise en mémoire d’un objet dès le lancement.
En gros écris une classe qui fait quelque chose de méchant. Puis dans une autre classe instancie en un en étant static. Même si cette seconde classe n’est pas appelée, le mot static force l’instanciation de la première classe dans la mémoire pour qu’elle soit disponible dans le reste du code.
Jme trompe?
Si je peux me permettre, un store sérieux?
" />
Avec Google qui pratique une vérification à postériori (c’est toujours le cas?) des applications sur son playstore, tu le classes où?
A mon grand regret, la pomme a le mérite de faire ça avant la publication mais bon on parle de modèles différents
@Khalev
J’ai déja vu des
import com.truc.machin.chouette.*;
pour éviter de se taper la liste des classes à importer.
La plateforme Android écrase littéralement la concurrence en volume de ventes et en parts de marché
J’espère que ça ne fait pas trop mal ?
Je sais pas si il y a un lien mais j’ai eu droit a une mise a jour aujourd’hui je suis sous 4.0.3
" />
@127.0.0.1
Accéder = assigner? (souci de terminologie pour moi). Dans ce cas, si je comprends bien, il suffit de faire par exemple:
private static int inutile=255;
Rien que cet assignation va donc provoquer l’initialisation de la classe. Même si la classe n’est pas référencé dans le code d’origine.
C’est ça?