Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Une importante faille de sécurité concernerait 99 % des appareils Android

Le cybercrime était presque parfait

Une importante faille de sécurité concernerait 99 % des appareils Android

Le 04 juillet 2013 à 08h50

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.

android malware

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.

 

bluebox faille android

 

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 (173)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar







Glubglub a écrit :



Donc oui, tu peux prendre un APK vérolé, et le signer avec la clé d’Angy Birds. C’est très simple, rien ne nous en a jamais empêché.

Par contre, ce fameux APK falsifié ne pourra jamais être distribué à grande échelle. On ne peut le publier sur Google Play sans avoir le mot de passe du compte Google Play Dev de Rovio.







et justement, vu que ton app (vérolé) réutilise une clé Rovio, déjà publié sur le play store, google refusera de la publier non ?


votre avatar







von-block a écrit :



Je me suis moi-même toujours posé la question.



C’est évident qu’il y aura toujours des failles et des grosses un jour ou l’autre. Pourquoi ne pas avoir un système de mises à jour automatiques pour tous les téléphones (comme Windows Update). Les constructeurs fourniraient qu’une couche de plus.







Par ce que c’est tout bénéf pour les fabricants de téléphones. “Un risque de sécurité? Achetez notre nouveau modèle de téléphone et vous pourrez dormir tranquille”.



Et si un jour les gens en ont assez de ces pratiques et qu’ils passer majoritairement à des versions alternatives du genre de CM, les fabricants déborderont d’ingéniosité pour verrouiller la chaine de boot afin d’empêcher le client d’user de son propre téléphone comme il le souhaite. Et on nous dira que c’est normal, que l’enrichissement des entreprises passe avant le bien-être du simple citoyen.


votre avatar







Glubglub a écrit :



Une vérification par hash est donc impossible (auprès de quel store on vérifierait la validité du hash ? Tous ?).







Encore une fois je ne sais pas comment ça marche sur Android, mais c’est le principe d’une PKI.


votre avatar







metaphore54 a écrit :



Apple a retiré une application française qui faisait des réduction sur certaines applis, apple l’a laisser où c’était installé ?





Retiré du Store, pas effacé des appareils<img data-src=" />


votre avatar







misterB a écrit :



Retiré du Store, pas effacé des appareils<img data-src=" />







Ok merci. ;)


votre avatar







Glubglub a écrit :



J’imagine que ce hash est vérifié par l’AppStore, et qu’il interdit l’installation s’il est falsifié?

Donc, en suivant cette logique, un iPhone aura forcément besoin de l’AppStore pour installer une app.







C’est la clé publique du développeur qui permet de savoir si le package est authentique. On ne pourrait pas faire une appli iOS avec la signature des dev d’Angry Birds si on ne dispose pas de leur clé privée. Pas besoin de passer par une vérification sur l’App Store.


votre avatar







Glubglub a écrit :



Mais (pour la 100ème fois), Android a été fait pour pouvoir fonctionner sans Google Play, et les stores tiers officiels sont légions.

Une vérification par hash est donc impossible (auprès de quel store on vérifierait la validité du hash ? Tous ?).





L’installeur pourrait garder la trace du store d’origine de l’APK, comme c’est fait dans les repositories Linux. Elles ont leur propre clé pour authentifier les paquets. Et ce tout en autorisant les packages non signés.


votre avatar







Glubglub a écrit :



Dans ce cas, je me clarifie :

La “signature numérique” consiste uniquement à un tag dans l’apk, rien de plus.

On peut récupérer un tag (cette fameuse “signature”), et l’appliquer à un autre APK depuis toujours en une ligne de code.

Tous les outils nécessaires sont disponibles dans les outils du SDK oficiel de Google.



Donc oui, tu peux prendre un APK vérolé, et le signer avec la clé d’Angy Birds. C’est très simple, rien ne nous en a jamais empêché.





Mais il faut la clé privée d’Angry Bird pour ça. La clé (contenu dans un certificat) qui est fourni avec l’APK est la clé publique qui permet de vérifier que le hash est bon. Elle ne peut-être utilisée pour signer un APK.



C’est la base de la crypto asymétrique. Toute la sécurité repose sur le fait que la clé privée est en théorie protégée (tu n’as besoin de la communiquer à personne la clé publique est là pour ça).



dans le cas qui nous intéresse ça fait que quelqu’un qui pirate le compte de Rovio (plus simple que d’obtenir la clé privée en théorie) ne pourra publier une maj de l’appli puisque la signature ne correspondra pas à celle utilisée habituellement.







Para-doxe a écrit :



Du coup, comment la modification des données peut ne pas entrainer la modification de la signature?





Pour moi il y a une partie de l’APK qui n’est pas couvert par la signature et ils ont réussi à y intégrer du code et à le faire s’exécuter. Ne connaissant pas la structure exact d’un APK ni le process de signature je ne saurais t’en dire plus ni aller plus loin dans la confirmation/infirmation de cette théorie.



Ce serait comme un gars qui envoie un mail avec une pièce jointe, signe le contenu de son message mais pas la pièce jointe, un pirate intercepte le truc, modifie la pièce jointe. Son destinataire ne vérifie que la signature du message (ils utilisent le même programme pour signer et vérifier, donc il a les mêmes défauts de conception) et pas de la pièce jointe Le mail dit au destinataire d’ouvrir la pièce jointe, confiant, celui-ci s’exécute.







Para-doxe a écrit :



En lisant l’article de Bluebox, j’ai un peut l’impression qu’ils jouent sur les mots pour faire monter la mayonnaise.





Surement, c’est le gros problème de la Black Hat, c’est devenu hyper “commercial” et pas mal de participants essaient de se faire mousser (ça n’enlève en rien la qualité des présentations, mais c’est plutôt toute la com autour qui est assez insupportable).


votre avatar







nick_t a écrit :



Exact mais dans certains cas t’as pas le choix.



Moi par exemple, je n’ai pas un abo français, donc je n’ai pas accès à certaines applications françaises.

Alors c’est vrai, il y a des techniques pour contourner ces restrictions.



Sinon ben tu choppes l’apk où tu peux…









Il faut garder quand même à l’esprit … que c’est un téléphone.



Je veux bien croire que tu ne puisses pas avoir tout le contenu de toute application en fonction de l’endroit où tu es mais là on est en train de discuter sur fond de Prism du fait que n’importe qui donne n’importe quoi comme information à n’importe qu’elle entreprise américaine et met n’importe quoi sur son téléphone puis se demande si il va crever dans les 2 jours si par hasard il télécharge une grosse bouse depuis n’importe où … et on se demande où se trouve la faille.



Quand on télécharge facebook sur le téléphone où l’on a tout son agenda et voir même des accès à son compte en banque et que l’on demande de pouvoir télécharger n’importe quoi n’importe où en criant sur les forum, “Attention google, ce sera de ta faute si je m’en prends plein le c*l” … à un moment donné, il faut quand même atterrir et comprendre que non, le problème ne vient pas du fait que l’on puisse télécharger n’importe quoi n’importe où mais qu’il serait temps pour les utilisateurs de s’assumer



Sii tu télécharge une bouse, tu l’a vire et tu en remet une autre. Et si il s’avère que des gens on piraté un compte de développeur en se donnant de remplacer l’application du dit compte et qu’en la téléchargeant et en l’utilisant, les photos de nus de tes gosses et les mensuration et l’adresse de ta femme se sont retrouvé sur le net, dit-toi quand même que la faille ce n’est pas le fait de pouvoir télécharger depuis n’importe où ni même un ash dans l’application codant son nom. Le problème c’est que tu as une très mauvaise utilisation d’un outil qui n’a aucune nature à veiller sur la protection de tes informations : Il y a quand même quelque chose comme une news par semaine sur ce site qui définit que l’Europe ou la France ou le monde fait des procès à l’ensemble des entreprises américaines pour des questions de dévoiement de la vie privée tandis que les USA même se font traiter de tout les noms pour vol de données à l’échelle planétaire !!! NON la faille se n’est pas la clef ASH !!! C’est ce qui n’a rien à voir avec l’informatique le problème !!! Je vous rappelle que l’informatique est une science, que son utilisation est une technologie et que l’usage qui est fait de ces technologies est décrit par tout les sites de presses et d’information comme étant de la pire navrance !! Il faut être totalement timbré pour estimé que la possibilité de télécharger depuis autre chose qu’un app store américain est ce qui va nuire aux libertés individuelles !!!


votre avatar







psn00ps a écrit :



L’installeur pourrait garder la trace du store d’origine de l’APK, comme c’est fait dans les repositories Linux. Elles ont leur propre clé pour authentifier les paquets. Et ce tout en autorisant les packages non signés.







C’est une possibilité, mais dans la pratique, c’est impossible.

Si l’on stocke cette info sur l’appareil de l’utilisateur, elle sera forcément altérable, et donc pas fiable.







canti a écrit :



et justement, vu que ton app (vérolé) réutilise une clé Rovio, déjà publié sur le play store, google refusera de la publier non ?







Exactement, donc on sera bloqué si l’on a pas accès au compte dev de Rovio.







NeVeS a écrit :



Encore une fois je ne sais pas comment ça marche sur Android, mais c’est le principe d’une PKI.







C’est ce que je dis depuis le début, cette signature n’est pas une clef publique, c’est juste un tag.

Tu dis ne pas croire ça possible, mais c’est exactement ce que soulève cet article.

C’est tout à fait possible, et ça n’a pas de conséquence sur la sécurité.


votre avatar







nyandog a écrit :



Il faut être totalement timbré pour estimé que la possibilité de télécharger depuis autre chose qu’un app store américain est ce qui va nuire aux libertés individuelles !!!





Toutafaitement, on est d’accord.

<img data-src=" />


votre avatar







Glubglub a écrit :



Mais (pour la 100ème fois), Android a été fait pour pouvoir fonctionner sans Google Play, et les stores tiers officiels sont légions.

Une vérification par hash est donc impossible (auprès de quel store on vérifierait la validité du hash ? Tous ?).





Justement, la signature contient le hash (*) tel que vu par l’expéditeur. Toi de ton côté tu calcules le hash de ce que tu as reçu, tu compares ce hash à celui contenu dans la signature. Si c’est le même tu peux supposer que le code signé reçu est le même que le code signé envoyé.



(*) une signature c’est un hash chiffré.



Je veux t’envoyer un message A et je veux le signer:




  • je génère un coupe de clé privé/publique p/P.

  • je calcule le hash de mon message : h(A)

  • je chiffre ce hash avec ma clé privée : p(h(A))

  • je t’envoie p(h(A)), A, P (ma clé publique)

  • tu déchiffres la signature : P(p(h(A))). Tu obtiens h(A) le hash tel que vu de mon côté.

  • tu calcules de ton côté le hash du A que je t’ai envoyé avec un autre logiciel de hash : h’(A)

  • tu compares h(A) et h’(A). S’ils sont égaux c’est bon, sinon c’est qu’il y a eu un soucis pendant le transfert.



    http://commons.wikimedia.org/wiki/File<img data-src=" />igital_Signature_diagram.svg



    Tu stockes P de ton côté comme ça lors des futures mise à jour tu peux comparer ton P à celui envoyé par moi. S’il est différent c’est que j’ai changé de clé, si ce n’était pas prévu c’est que c’est la grosse merde et je te déconseille de tenir compte de mon message.



    Pas besoin de faire intervenir un quelconque tiers, sauf que sous Android, quand on passe par Gplay, celui-ci s’occupe en plus d’authentifier P histoire d’assurer le coup, mais rien n’empêche un store tiers d’assurer ce rôle aussi, il suffit de stocker P+le store qui gère l’appli associée à P.


votre avatar







Glubglub a écrit :



C’est ce que je dis depuis le début, cette signature n’est pas une clef publique, c’est juste un tag.

Tu dis ne pas croire ça possible, mais c’est exactement ce que soulève cet article.

C’est tout à fait possible, et ça n’a pas de conséquence sur la sécurité.







Tu es d’accord que ce que tu dis est en totale opposition avec le site d’Android ?



https://developer.android.com/tools/publishing/app-signing.html


votre avatar







Khalev a écrit :



Justement, la signature contient le hash (*) tel que vu par l’expéditeur. Toi de ton côté tu calcules le hash de ce que tu as reçu, tu compares ce hash à celui contenu dans la signature. Si c’est le même tu peux supposer que le code signé reçu est le même que le code signé envoyé.



(*) une signature c’est un hash chiffré.



Je veux t’envoyer un message A et je veux le signer:




  • je génère un coupe de clé privé/publique p/P.

  • je calcule le hash de mon message : h(A)

  • je chiffre ce hash avec ma clé privée : p(h(A))

  • je t’envoie p(h(A)), A, P (ma clé publique)

  • tu déchiffres la signature : P(p(h(A))). Tu obtiens h(A) le hash tel que vu de mon côté.

  • tu calcules de ton côté le hash du A que je t’ai envoyé avec un autre logiciel de hash : h’(A)

  • tu compares h(A) et h’(A). S’ils sont égaux c’est bon, sinon c’est qu’il y a eu un soucis pendant le transfert.



    http://commons.wikimedia.org/wiki/File<img data-src=" />igital_Signature_diagram.svg



    Tu stockes P de ton côté comme ça lors des futures mise à jour tu peux comparer ton P à celui envoyé par moi. S’il est différent c’est que j’ai changé de clé, si ce n’était pas prévu c’est que c’est la grosse merde et je te déconseille de tenir compte de mon message.



    Pas besoin de faire intervenir un quelconque tiers, sauf que sous Android, quand on passe par Gplay, celui-ci s’occupe en plus d’authentifier P histoire d’assurer le coup, mais rien n’empêche un store tiers d’assurer ce rôle aussi, il suffit de stocker P+le store qui gère l’appli associée à P.







    Je vais devenir chèvre…

    En fait on est d’accord depuis le début.



    Donc selon toi, chaque store doit faire ses vérifications?

    Dans ce cas là, on est bien d’accord : il y aurait toujours un risque si l’on ne télécharge pas un APK depuis un store, ou si l’on fait confiance à un store malhonnête…



    Et c’est exactement ce que je dit depuis le début !

    Il y a déjà d’autres vérifications, et des hash pour le transfert de l’APK. Mais ce n’est pas le rôle de cette signature incriminée.




votre avatar







Glubglub a écrit :



Et c’est exactement ce que je dit depuis le début !

Il y a déjà d’autres vérifications, et des hash pour le transfert de l’APK. Mais ce n’est pas le rôle de cette signature incriminée.





signature = hash chiffré.



En gros pouvoir modifier le code sans modifier la signature c’est comme modifier le code sans modifier le hash. C’est à dire que tu fais confiance à un code qui n’est pas celui initialement fourni par le développeur officiel.



Tu le vois le problème là? Maintenant tu associes ça à une protection des comptes officiels qui laisse parfois à désirer et tu obtiens un joli cocktail explosif.


votre avatar

Quid de la vulnérabilité des versions custom d’android (type CyanogenMod) ?

votre avatar







TheDidouille a écrit :



donc c’est une faille, puisque je fais confiance à ce que me dit mon tél sur les droits d’une appli que j’installe depuis n’importe où. Il suffit de vérifier la signature avant de l’installer.



Suffit juste que Google mette à jour l’utilitaire d’installation des apk, puis basta.







ou que tu arrête de télécharger n’importe quoi depuis n’importe où … ou que tu achète un téléphone qui t’oblige à ce que tu doit acheter et où.



Télécharger ce que l’on veut (même de la merde) c’est un droit et non tout le monde ne veut pas d’un téléphone qui te dise quoi acheter (même de la merde) et où.



Et donc ce n’est pas une faille : c’est une politique de store.


votre avatar

Il faudrait que le contrôle se fasse au niveau du téléphone:




  • pas de problème avec les multiples stores

  • détection après installation de modification



    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.

votre avatar

Effet PRISM : oh la jolie faille commandé par la CIA à Google …

votre avatar

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.

votre avatar







Droogs a écrit :



Trop gras, passera pas <img data-src=" />









Khalev a écrit :



C’est le modèle de signature propre à Google qui est foireux. La partie sur laquelle la communauté ne peut que observer quand Google daigner publier ses sources.



Le faille est déjà corrigée, le bug a été officialisé en février, c’est les constructeurs qui retardent le truc, donc c’est pas lié au libre non plus.



Troll hors sujet, n’a pas compris le sujet : 1⁄20.









<img data-src=" />









<img data-src=" />


votre avatar







after_burner a écrit :



<img data-src=" />









<img data-src=" />







En même temps, l’OS de Google étant le moins libre des OS libre <img data-src=" />


votre avatar







Droogs a écrit :



En même temps, l’OS de Google étant le moins libre des OS libre <img data-src=" />







Et vu la difficulté d’y contribuer en amont, on pourrait presque le qualifier de projet uniquement Open Source. <img data-src=" />


votre avatar







Glubglub a écrit :



Encore une fois : la “signature” n’est pas un hash. Il n’a jamais eu la vocation de l’être. C’est juste un tag pour Google Play, rien de plus.

Elle a peut être un nom ambigu, (en tout cas en français), mais ce n’est pas une faille au système.







Je ne connais rien au dev Android mais cette page :



https://developer.android.com/tools/publishing/app-signing.html



semble indiquer le contraire de ce que tu racontes.


votre avatar







Glubglub a écrit :



Il recompile l’app sans nous, et sans changer la signature, et il publie l’app comme il veux.









When you build in release mode you use your own private key to sign your application.



Source



Donc quand ton client compile l’application, il utilise sa propre clé pour signer. Après, il y a peut-être un tag quelque part qui identifie l’application comme étant basé sur l’application template de ta boîte, mais l’application de ton client a bien une signature individuel.



Et ça n’empêche en rien de prendre un APK, de le décompiler, de faire des modifications et après de l’installer sur ton téléphone android. Par contre, il utilisera un autre certificat, et ne pourra pas servir de mise-à-jour pour l’ancienne application (enfin, sauf qu’apparement il y a une faille <img data-src=" />, mais ça devrait pas être le cas).


votre avatar







trash54 a écrit :



attend ton tour <img data-src=" />





Déjà eu au début, le petit virus par sms qui bloqué le tel =)



Shyfer a écrit :



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… )





Sauf erreur de ma part c’est libre qu’en partie. Temps que la version ou android utilisera tout le noyau linux ne sera pas encore dispo on aura tjs ce soucis.



Moi le soucis c’est que la faille est été vu, et non corrigé, depuis la 1.6 …


votre avatar







Para-doxe a écrit :



Et vu la difficulté d’y contribuer en amont, on pourrait presque le qualifier de projet uniquement Open Source. <img data-src=" />







J’ai seulement une question que je me pose, Google offre beaucoup de choses gratuites et/ou pas cher, le jour où ils décident de changer de politique… ça risque d’en surprendre plus d’un (comme pour GoogleSync)… Ca me fait penser à ce que j’entendais il y a peu de temps à propos de Microsoft. Comme pour les dealers, la première dose est gratuite ensuite… Je me dis (sûrement à tort, j’en sais rien après tout) qu’une fois leurs OS bien implantés grâce à Samsung, les Google Book… s’ils décident que c’en est fini, Samsung… auront joué les chevaux de Troie et le consommateur pourrait se trouver “bête”.



Je dis ça, sans rien en savoir, juste une réflexion que je pose là <img data-src=" />


votre avatar







psn00ps a écrit :



Je ne vois pas en quoi un PC durerait plus longtemps qu’un téléphone.







Je ne sais pas, peut etre parce que les composants sont faits pour durer ? Que dans un PC, les composants ne sont pas forcements miniaturisés pour tenir dans une coque de 8 centimetres de coté ?

Je n’ai jamais vu personnellement un smartphone rester plusieurs années en route 24⁄24. Mais un PC oui, avec des reboots a cause de mises a jours biensur

bref, de toutes facons c’est hors sujet.


votre avatar







Glubglub a écrit :



Encore une fois : la “signature” n’est pas un hash. Il n’a jamais eu la vocation de l’être. C’est juste un tag pour Google Play, rien de plus.

Elle a peut être un nom ambigu, (en tout cas en français), mais ce n’est pas une faille au système.



Et je pense que la vérification par le hash est probablement impossible sans violer pas mal de lois antitrusts.





“allows a hacker to modify APK code without breaking an application’s cryptographic signature”. http://bluebox.com/corporate-blog/bluebox-uncovers-android-master-key/)



Que toi tu ne parles pas de la signature numérique de l’APK peut-être, mais la faille porte sur la signature numérique. Et dans ce cas tu es hors sujet depuis le début



Je comprends pas ce que viennent faire les lois anti-trust dans la vérification par le hash. C’est le genre de méthode qui est utilisé… quasiment partout où il y a échange de fichier sans que ça pose problème.







fred42 a écrit :



En lisant le site de Bluebox, j’ai l’impression que le bug est lié à une anomalie dans la vérification de la signature et dans l’installation des applications.



La seule chose que l’on peut affirmer, c’est que l’on n’a pas assez d’informations pour comprendre la faille. Il faut attendre les infos au Black Hat USA 2013, donc le premier Août au plus tard.





C’est aussi l’impression que j’ai. Je ne pense pas que ça soit que le code n’est pas vérifié, mais c’est peut-être les ressources (images, etc…) qui ne sont pas vérifiées, sauf qu’il est possible d’ajouter du code exécutable à ce niveau, genre tu remplaces une image par du code et le code sera exécuté au moment de charger l’image.



Mais oui il faudra attendre le 1 Aout à 11h45 (20h45 en France, pour ceux qui ont accès au stream) pour savoir exactement ce qu’il en est.


votre avatar







nyandog a écrit :



ou que tu arrête de télécharger n’importe quoi depuis n’importe où … ou que tu achète un téléphone qui t’oblige à ce que tu doit acheter et où.



Télécharger ce que l’on veut (même de la merde) c’est un droit et non tout le monde ne veut pas d’un téléphone qui te dise quoi acheter (même de la merde) et où.



Et donc ce n’est pas une faille : c’est une politique de store.







Exact mais dans certains cas t’as pas le choix.



Moi par exemple, je n’ai pas un abo français, donc je n’ai pas accès à certaines applications françaises.

Alors c’est vrai, il y a des techniques pour contourner ces restrictions.



Sinon ben tu choppes l’apk où tu peux…







Google a écrit :



Accès au Contenu.

Vous pouvez utiliser Google Play pour parcourir, identifier et/ou télécharger le Contenu sur votre téléphone portable, ordinateur ou autre appareil pris en charge (« Appareil »). La disponibilité du Contenu variera en fonction des pays et il se peut que tout le Contenu ne soit pas disponible dans votre pays. Certains éléments de ce Contenu peuvent être proposés par Google tandis que d’autres peuvent être mis à disposition par des tiers non affiliés à Google. Google n’est pas responsable du Contenu sur Google Play qui provient d’une autre source que Google et ne cautionne pas un tel Contenu.



votre avatar







fraoch a écrit :



@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







C’est bien là que le modèle des smartphones est pourri… C’est le matériel qui dicte que le suivi du système. C’est clairement anormal comme fonctionnement, uniquement fait dans le but de vendre du device.



Je ne vois pas en quoi au nom de la durée de vie (pour info, mon iPhone 3GS a trois ans et demi et ne montre aucun signe de fatigue niveau batterie ou matériel en général, et il n’est plus supporté désormais) du matériel ce serait au constructeur de proclamer l’abandon du support logiciel. C’est une aberration totale. Surtout quand le constructeur et le développeur du système sont deux entités différentes !



Le hardware et le software doivent être dissociés pour les smartphones. Le modèle actuel est clairement malsain, fermé, et pourri jusqu’à l’os.



Accessoirement, le support de Windows 2000 s’est arrêté en 2010, soit dix ans après sa sortie commerciale. Windows 2005 par contre perso je connais pas, mais si tu voulais parler de 2003, il est encore en support étendu (mises à jours de sécurité, support payant possible) jusqu’en juillet 2015.


votre avatar







Khalev a écrit :



Je ne pense pas que ça soit que le code n’est pas vérifié, mais c’est peut-être les ressources (images, etc…) qui ne sont pas vérifiées, sauf qu’il est possible d’ajouter du code exécutable à ce niveau, genre tu remplaces une image par du code et le code sera exécuté au moment de charger l’image.







Je pense à la même chose. Windows (WinVerifyTrust) y a eu droit aussi il y a quelques années.


votre avatar



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 <img data-src=" />

votre avatar







Lemon Pie a écrit :



Put* que je suis content de pas être sous android









Anikam a écrit :



Cool story bro<img data-src=" />





Rien de nouveau sous le soleil donc.







Parce que vous croyez que Windows/Windows Phone ne trainent pas de véritables vieilles casseroles en matière de sécurité ??? <img data-src=" />



Ouai, rien de nouveau sous le soleil…



Et à moins d’être un véritable Michu, il existe plusieurs applications permettant de limiter/bloquer les apps d’accèder finement à certaines données et/ou fonctionnalités d’Androd/smartphone/tablette, comme par exemple LBE ou LBE Security Master qui n’ont rien à voir avec la véritable passoire qu’est le Firewall de MS…



Mais ce ne sont pas les seuls outils…







Takoon a écrit :



Une raison de plus d’opter pour Firefox OS plus tard.

<img data-src=" />







Il ne sera probablement pas plus à l’abri plus tard… <img data-src=" />


votre avatar

j’ai pas lu tous les commentaires, mais sait-on si la dernière version est touché (4.2.2 sur Nexus 4)?

votre avatar







Glubglub a écrit :





  • Soit c’est effectivement possible de changer la signature, et je bosse dans l’une des nombreuses boites dans le monde qui savent le faire, et je ne vais pas fournir du code appartennant à mon entreprise.



    • Soit c’est totalement impossible à faire… Et dans ce cas là les auteurs de cet article prétendent qu’un truc impossible provoque une faille de sécurité.







      Soit :







      NeVeS a écrit :



      Une des possibilités est que la vuln de BlueBox permette de mettre du code exécutable dans une partie non vérifiée par la signature.







      Soit il y a une erreur d’implémentation dans la vérification de la signature. Soit, etc.







      Glubglub a écrit :



      Mais si la signature ne change pas d’une version à l’autre, ça veut bien dire que ce n’est pas une “vraie” signature ?







      Oui. Mais pour moi elle change, je ne peux pas concevoir cela autrement. Tu dois confondre la signature avec quelque chose d’autre, ce n’est pas possible autrement.







      Glubglub a écrit :



      Dans ce cas, je vous invite à tester le dev Android (c’est gratuit), et à vérifier cette fameuse signature…







      Je n’ai rien d’installé pour tester ça, je n’ai pas les connaissances en dev Android pour le faire, pourquoi en veux tu pas me montrer la procédure, ce qui va te prendre 5 minutes là où ça me prendra 2 heures au minimum ? Montre nous comment tu extrais la signature d’un APK, comment tu la copie sur un autre APK et comment tu vérifies que cette signature est valide sur ce dernier APK.







votre avatar







Glubglub a écrit :



Je suis d’accord avec vous deux.

Mais si la signature ne change pas d’une version à l’autre, ça veut bien dire que ce n’est pas une “vraie” signature ?





Vrai





Glubglub a écrit :



Dans ce cas, je vous invite à tester le dev Android (c’est gratuit), et à vérifier cette fameuse signature…





Tu parles de la regarder à quel moment du process de génération d’un APK?


votre avatar







arobase40 a écrit :



Parce que vous croyez que Windows/Windows Phone ne trainent pas de véritables vieilles casseroles en matière de sécurité ??? <img data-src=" />





C’était du sarcasme pour ma part.


votre avatar







Anikam a écrit :



C’était du sarcasme pour ma part.





En Taule <img data-src=" /><img data-src=" />


votre avatar







Ly-sAn a écrit :



Pour une fois que je suis content de tourner sur Windows (phone) concernant la sécurité <img data-src=" />









trash54 a écrit :



attend ton tour <img data-src=" />







C’est déjà fait depuis quelques dizaines d’années… <img data-src=" />





kamuisuki a écrit :



Lëkki,Apple, Microsoft, aiment cette news.









Takoon a écrit :



« Qui est plus aveugle que celui qui ne peut pas voir ? »







<img data-src=" /> <img data-src=" />





Shyfer a écrit :



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… )







Et cela ne te met pas la puce à l’oreille ??? <img data-src=" />



Déjà du temps de Windows NT les failles se comptaient par dizaines de milliers dont certaines étaient des héritages des versions pré-NT, et même depuis il en existent encore quelques milliers, mais les problèmes ne proviennent pas uniquement des applis ou des drivers, mais du coeur même de Windows !!! <img data-src=" /> <img data-src=" />


votre avatar







Glubglub a écrit :



Il n’y a que deux possibilités :




  • Soit c’est effectivement possible de changer la signature, et je bosse dans l’une des nombreuses boites dans le monde qui savent le faire, et je ne vais pas fournir du code appartennant à mon entreprise.

  • Soit c’est totalement impossible à faire… Et dans ce cas là les auteurs de cet article prétendent qu’un truc impossible provoque une faille de sécurité.





    Je suis d’accord avec vous deux.

    Mais si la signature ne change pas d’une version à l’autre, ça veut bien dire que ce n’est pas une “vraie” signature ?

    Dans ce cas, je vous invite à tester le dev Android (c’est gratuit), et à vérifier cette fameuse signature…





    En faite c’est dans le fichier apk, dans le dossier META-INF, il y a un fichier cert.sf qui contient le hash de tout les fichiers présent dans l’apk. Il est fournis avec son certificat cert.rsa.



    en.wikipedia.org Wikipedia


votre avatar







Glubglub a écrit :





  • Soit c’est totalement impossible à faire… Et dans ce cas là les auteurs de cet article prétendent qu’un truc impossible provoque une faille de sécurité.





    La capture montre que ce n’est pas impossible


votre avatar

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?

votre avatar







Droogs a écrit :



J’ai seulement une question que je me pose, Google offre beaucoup de choses gratuites et/ou pas cher, le jour où ils décident de changer de politique… ça risque d’en surprendre plus d’un (comme pour GoogleSync)… Ca me fait penser à ce que j’entendais il y a peu de temps à propos de Microsoft. Comme pour les dealers, la première dose est gratuite ensuite… Je me dis (sûrement à tort, j’en sais rien après tout) qu’une fois leurs OS bien implantés grâce à Samsung, les Google Book… s’ils décident que c’en est fini, Samsung… auront joué les chevaux de Troie et le consommateur pourrait se trouver “bête”.



Je dis ça, sans rien en savoir, juste une réflexion que je pose là <img data-src=" />







Si cela arrivait, soit les smartphone/tablettes, soit Android n’existeraient plus parce qu’on aurait des implants dans le corps et il faudra espérer que les anticorps resteront d’actualités afin de se retrouver moins “bête”… <img data-src=" />


votre avatar







seboss666 a écrit :



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.







Tout à fait.



Le fait que de nombreux appareils se retrouvent rapidement privés de mise à jour est un problème de sécurité majeur et à grande échelle.



D’autant qu’avec le temps toutes les failles des kernels et de l’environnement sont listées.





votre avatar







paradise a écrit :



Le tout est d’y croire, ou de ne pas savoir. <img data-src=" />







Ou de se voiler la face derrière son petit doigt… <img data-src=" />



<img data-src=" /> Ça y est, je ne vois plus rien. <img data-src=" /> <img data-src=" />



votre avatar







Raknor a écrit :



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, quelle est-elle?





votre avatar







arobase40 a écrit :



Si cela arrivait, soit les smartphone/tablettes, soit Android n’existeraient plus parce qu’on aurait des implants dans le corps et il faudra espérer que les anticorps resteront d’actualités afin de se retrouver moins “bête”… <img data-src=" />







Je me disais bien aussi <img data-src=" />



Faut vraiment que je revois T1 et T2 ce week-end, ça m’y fait penser avec tes histoires d’implants…


votre avatar







NeVeS a écrit :









Khalev a écrit :









millman42 a écrit :



En faite c’est dans le fichier apk, dans le dossier META-INF, il y a un fichier cert.sf qui contient le hash de tout les fichiers présent dans l’apk. Il est fournis avec son certificat cert.rsa.



en.wikipedia.org Wikipedia







Merci, millman42.

J’ai pu vérifier du coup, je ne savais pas où était ce hash.



Voilà un exemple d’une de ces fameuses signatures :

AB<img data-src=" />6:10:91:EF<img data-src=" />1:5C<img data-src=" />8:57:38:08:03:0B:3F:7E:00<img data-src=" />8:EB:9E:5D

Il ne suffit que de ça pour publier un APK sur Google Play, ou autre.

Il est même pas masqué lorsqu’on tente de publier un APK signé avec un mauvais keystore sur Google Play.

C’est cette donnée qui est falsifiable, mais elle est complètement inutile sans avoir un accès total au compte Google Play Dev lié.

Elle ne change jamais, même lorsqu’on met à jour l’APK. C’est ce que renvoie le keystore.



Ce n’est pas un hash.

Ce qui est appelé “signature” sous Android n’est QUE ça.



Le hash, cripté, vérifiant la validité de l’application, fait 190ko.

Celui là est nettement plus critique s’il est cassé. Ce n’est toujours pas le cas.

Il est généré avec la clé publique, et c’est ce que NeveS et Khaley appellaient certainement la signature.



Voilà, voilà.


votre avatar







psn00ps a écrit :



La capture montre que ce n’est pas impossible







tu connais pas photoshop? <img data-src=" />


votre avatar







canti a écrit :



tu connais pas photoshop? <img data-src=" />





Dans ce cas les résultats de l’élection de Hollande ont été photoshopés aussi <img data-src=" /><img data-src=" />


votre avatar







Glubglub a écrit :



Voilà un exemple d’une de ces fameuses signatures :

AB<img data-src=" />6:10:91:EF<img data-src=" />1:5C<img data-src=" />8:57:38:08:03:0B:3F:7E:00<img data-src=" />8:EB:9E:5D







Ce n’est pas une signature mais l’empreinte du certificat.







Glubglub a écrit :



Ce n’est pas un hash.

Ce qui est appelé “signature” sous Android n’est QUE ça.







Où ça ? Je doute que le monde Android se permette de renommer des concepts de base de la cryptographie. Je pense plutôt que tu mélanges un peu tout :)







Glubglub a écrit :



Le hash, cripté, vérifiant la validité de l’application, fait 190ko.

Celui là est nettement plus critique s’il est cassé. Ce n’est toujours pas le cas.

Il est généré avec la clé publique, et c’est ce que NeveS et Khaley appellaient certainement la signature.







Parce que c’est ça, la signature :)


votre avatar

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.

votre avatar

tinnin!



http://i.imgur.com/yU7RAma.png



(dispo sur toutes les versions d’Android)



merci theverge

votre avatar

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.

votre avatar







millman42 a écrit :



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.





J’ai aussi pensé à un truc comme ça à force de lire différents trucs sur le sujet.

C’est un peu gros, mais c’est typiquement le genre de bug qui se corrige en 2 lignes de code comme l’a indiqué Forristal : vérifier que le fichier est bien dans la liste des fichiers et qu’il a bien le bon SHA1


votre avatar







fred42 a écrit :



Plus d’infos en anglais ici

Extraits :



C’est assez clair tout en restant mystérieux.



Ç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 :

Bref, ça ressemble bien à un simple bug aux conséquences importantes.





Oui donc en gros ils arrivent à insérer du code via des updates (ou non, mais ça serait une méthode possible de distribution de trojan) sans que ça modifie la signature de l’appli, du coup ça fou la merde.



Vivement la conf pour savoir ce qu’il en est vraiment (et les comptes-rendus surtout, parce que 400$ le stream :eeek:). Mais je suis d’accord avec ta conclusion. C’est souvent le cas en même temps (comme dire que c’est 2 lignes à ajouter à un endroit spécifique, en général si tu mets le code au mauvais endroit ça marche pas super…).



Merci pour le lien <img data-src=" />


votre avatar







millman42 a écrit :



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.







De http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html#Verifying



Read each file in the JAR file that has an entry in the .SF file. While reading, compute the file’s digest, and then compare the result with the digest for this file in the manifest section. The digests should be the same, or verification fails.





A supputer que jarsigner (ou des parties de son code) est utilisé pour la vérification, donc en gros, la vérification n’est faite que sur les fichiers qui sont mentionnés dans le .SF…..



D’accord avec fred42, mais c’est quand même vachement gros pour que personne ne l’ai vu depuis tout ce temps (je ne suis pas dev android <img data-src=" /> ).


votre avatar

la NSA avait bien besoin d’un faille dans androîd pour espionner tout le monde. <img data-src=" />

votre avatar
votre avatar







NeVeS a écrit :







Bien, dans ce cas je vais utiliser le vocabulaire du cryptographe, pour éviter les confusions.

Désolé si Android ne respecte pas les normes.



On peut aisément copier un certificat sans problème, et l’appliquer à un tout autre APK.

Les mises à jour sur le store (à condition d’avoir les accès au compte Google Play du Dev) ne vérifient que ça, lorsqu’une mise a jour est soumise.

Lorsqu’une mise à jour est validée et publiée, la vérification du dld se fait avec le hash.

Jusqu’ici, on est d’accord…



Bien, maintenant la terrible faille est que la gestion des tokens est basée sur le certificat, et non pas sur le hash.

A bien y réfléchir, la plupart des stores ne re-demandant pas les permissions à chaque maj a un fonctionnement identique.



Mais la faille est donc que l’on peut falsifier un apk, et utiliser les permissions d’une autre appli.



C’est mal, mais cet APK falsifié n’a aucun moyen d’être publié sur un store sérieux.

Donc on en revient à la conclusion que je répète depuis tout l’après midi :

Tant que l’on ne télécharge pas ses apk sur un store obscur ou un site de torrent, cette “faille” ne pourra pas infecter 99% des machines, comme son titre raccoleur le clame.


votre avatar







NeVeS a écrit :



Ce n’est pas une signature mais l’empreinte du certificat.





Plus d’info sur la signature d’un apk :



The Signed JAR File



When jarsigner is used to sign a JAR file, the output signed JAR file is exactly the same as the input JAR file, except that it has two additional files placed in the META-INF directory: 




 a signature file, with a .SF extension, and   


 a signature block file, with a .DSA, .RSA, or .EC extension.


[…]



The Signature (.SF) File



A signature file (the .SF file) looks similar to the manifest file that is always included in a JAR file when jarsigner is used to sign the file. That is, for each source file included in the JAR file, the .SF file has three lines, just as in the manifest file, listing the following: 




 the file name,   


 the name of the digest algorithm used (SHA), and   


 a SHA digest value.




In the manifest file, the SHA digest value for each source file is the digest (hash) of the binary data in the source file. In the .SF file, on the other hand, the digest value for a given source file is the hash of the three lines in the manifest file for the source file.



The signature file also, by default, includes a header containing a hash of the whole manifest file. The presence of the header enables verification optimization, as described in JAR File Verification.



The Signature Block File

The .SF file is signed and the signature is placed in the signature block file. This file also contains, encoded inside it, the certificate or certificate chain from the keystore which authenticates the public key corresponding to the private key used for signing. The file has the extension .DSA, .RSA, or .EC depending on the digest algorithm used.



http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html



Donc en gros le manifest liste chaque fichier présent avec le SHA, le .SF liste chaque fichier avec le SHA des 3 lignes correspondantes au fichier (et le SHA du manifest) dans le manifest et le “Signature block file” contient la signature du .SF et le certificat ou la chaine identifiant la clé public à utiliser pour vérifier la signature.



Et dans la partie vérification :



“One reason the hash of the manifest file that is stored in the .SF file header may not equal the hash of the current manifest file would be because one or more files were added to the JAR file (using the jar tool) after the signature (and thus the .SF file) was generated. When the jar tool is used to add files, the manifest file is changed (sections are added to it for the new files), but the .SF file is not. A verification is still considered successful if none of the files that were in the JAR file when the signature was generated have been changed since then, which is the case if the hashes in the non-header sections of the .SF file equal the hashes of the corresponding sections in the manifest file.”



Même si Jarsigner n’est pas utilisé dans Android c’est bon à savoir ça pour ceux qui utilisent cet outil.


votre avatar







Raknor a écrit :



De http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html#Verifying





A supputer que jarsigner (ou des parties de son code) est utilisé pour la vérification, donc en gros, la vérification n’est faite que sur les fichiers qui sont mentionnés dans le .SF…..



D’accord avec fred42, mais c’est quand même vachement gros pour que personne ne l’ai vu depuis tout ce temps (je ne suis pas dev android <img data-src=" /> ).





Sauf que je peux t’ajouter 36000 fichiers, si le code signé ne les appelle jamais, ils servent à rien. Je pense que c’est là que réside le petit plus de BlueBox, ils ont du trouver un moyen pour que ces fichiers soit toujours ajoutés (si c’est bien de ça qu’il s’agit, si ça se trouve on est à côté de la plaque).


votre avatar







barbach a écrit :



Quid de la vulnérabilité des versions custom d’android (type CyanogenMod) ?







A moins que l’équipe CM aie pris le temps de remanier l’ensemble des millions de lignes de code d’Android de fond en comble, je crains que la situation ne soit guère différente… ^^



Par contre, il existe tout de même des solutions tiers, genre LBE et touti quanti qui permettent de limiter la casse… <img data-src=" />







SebGF a écrit :



C’est bien là que le modèle des smartphones est pourri… C’est le matériel qui dicte que le suivi du système. C’est clairement anormal comme fonctionnement, uniquement fait dans le but de vendre du device.



Je ne vois pas en quoi au nom de la durée de vie (pour info, mon iPhone 3GS a trois ans et demi et ne montre aucun signe de fatigue niveau batterie ou matériel en général, et il n’est plus supporté désormais) du matériel ce serait au constructeur de proclamer l’abandon du support logiciel. C’est une aberration totale. Surtout quand le constructeur et le développeur du système sont deux entités différentes !



Le hardware et le software doivent être dissociés pour les smartphones. Le modèle actuel est clairement malsain, fermé, et pourri jusqu’à l’os.







Je vois bien le topo là. Tu vas acheter un smartphone dans une boutique, mais le vendeur te prévient à l’avance : “Attention, on vous vend un matos, mais vous ne pourrez pas l’utiliser tout de suite car vous allez devoir trouver par vous même l’OS qui vous convient et l’installer par vous-même. Accessoirement, on vous en propose un mais ce sera 2 ou 3 fois le prix du msartphone… <img data-src=" />







SebGF a écrit :



Accessoirement, le support de Windows 2000 s’est arrêté en 2010, soit dix ans après sa sortie commerciale. Windows 2005 par contre perso je connais pas, mais si tu voulais parler de 2003, il est encore en support étendu (mises à jours de sécurité, support payant possible) jusqu’en juillet 2015.







Là on parle déjà d’OS Entreprise qui ont éventuellement les moyens de se payer le support étendu…



Mais pour ce qui est des OS grand public dérivés, c’est une toute autre histoire… <img data-src=" />





Shyfer a écrit :



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.









  • Commence par comprendre la “notion de fragmentation d’Android” avant de la ressortir à toutes les sauces sans savoir de quoi il s’agit… ^^ <img data-src=" />



  • Comme déjà indiqué et pour ce qui est de Windows, il se traine de vieilles casseroles depuis des dizaines d’années, genre la pile TCPIP : juste 1 exemple parmi des milliers d’autres…



  • Android (accessoirement iOS) et Windows ont deux philosophies totalement différentes en matière de conception et de fonctionnement : on ne flashe pas du Windows comme on flashe de l’Android !!! <img data-src=" />



  • Les produits sous Android utilisent presque à 100% de la mémoire NAND flash et non pas des HDD mécaniques et pour peu que le système permette ce genre de hotfixes, il y aurait réellement un problème de fragmentation (du support de stockage et non pas d’une ligne de produits).



  • Android a été conçu pour être compilé et créé pour un produit et un seul, ceci afin que la ROM soit la plus optimisée et la plus performante possible en fonction du produit sur lequel elle fonctionne.



    Cela signifie qu’Android n’est pas un OS générique occupant au bas mot quelques 16 ou 20 Go de stockage comme avec Windows, et pour parti comme sous une distribution Linux…



  • Cela a des avantages et des inconvénients !!!



  • Enfin, le problème des MAJ ne vient pas tant de Google/Android que des constructeurs (quelque qu’ils soient) afin d’entretenir le marché et l’obsolescence programmée. Mais là, c’est aux politiques de quelques pays/continents qu’ils soient de jouer leurs rôles afin d’imposer des règles/lois adéquates… <img data-src=" />







    coket a écrit :



    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 <img data-src=" />







    De quoi tu parles ???



    Sauf erreur de ma part Knox est la couche de sécurité spécifique à Samsung…



    Celle-là même qui a été autorisé par le Pentagone (entre autre) afin que les produits Samsung sous Android aient leur entrée chez eux, mais également potentiellement dans les autres institutions gouvernementales US, sensibilisées à la sécurité… ^^


votre avatar

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 …

votre avatar







fwak a écrit :



Ben oui, c’est bien connu, cette faille s’appelle PRISM <img data-src=" />







Tu m’as retiré les mots de la bouche. C’est juste la découverte de la backdoor d’Androîd


votre avatar







spidy a écrit :



et aussi, jusqu’à quelle version d’android la faille existe ? 4.1, 4.2 ?





Je recherche l’info mais je trouve pas. C’est juste évident que le truc est corrigé puisque le gars va sortir des PoC à la fin du mois. (Et dans le blog ils disent que maintenant il ne tient qu’aux constructeurs de déployer la maj, je pense que se sont les plus au courant de l’état du bug).


votre avatar







Khalev a écrit :



Euh…en.wikipedia.org WikipediaAu lieu de dire des bêtises, renseigne-toi avant.







Désolé, mais le dev Android est mon métier.

Ce que l’on appelle signature sur Google Play n’est qu’un tag, pas un hash.

La signature est la même quelle que soit la version de l’app.



Et j’ai expliqué plus haut qu’un verrouillage via le hash est inenvisageable, cela enfreindrait pas mal de lois.


votre avatar







Khalev a écrit :



“Suffit” de compromettre le compte du propriétaire de l’appli et de remplacer l’apk par celui modifié.



Le truc c’est que l’utilisateur final n’a aucun moyen de s’en rendre compte.







Si le market vérifie les signatures, c’est tintin.


votre avatar







Khalev a écrit :



“Suffit” de compromettre le compte du propriétaire de l’appli et de remplacer l’apk par celui modifié.



Le truc c’est que l’utilisateur final n’a aucun moyen de s’en rendre compte.





On doit pouvoir détecter une appli modifiée sur les serveurs hébergeant les stores officiels puisque l’on semble pouvoir corriger le problème sur les smartphones par une mise à jour.



Cela éviterait la difficulté de mise à jour des vieux Androïd.


votre avatar

Pour une fois que je suis content de tourner sur Windows (phone) concernant la sécurité <img data-src=" />

votre avatar

Une raison de plus d’opter pour Firefox OS plus tard.

<img data-src=" />

votre avatar







Ly-sAn a écrit :



Pour une fois que je suis content de tourner sur Windows (phone) concernant la sécurité <img data-src=" />







attend ton tour <img data-src=" />


votre avatar







Glubglub a écrit :



Je reste affirmatif sur le fait que ce ne soit pas une faille. C’est tout aussi possible sur iOS, et très certainement sur WindowsPhone.





Pouvoir ajouter du code à un apk sans en modifier la signature sans avoir à rechercher des collisions? C’est une faille de sécurité.



À part si tu as plus de détails que moi sur la “faille” (j’en sais pas plus que ce dit le blog de bluebox et quelques infos glanées à droite à gauche mais non vérifiées) je ne vois pas vraiment ce qui te permet de dire que de pouvoir modifier un fichier sans en modifier la signature n’est pas une faille.



Actuellement (sous réserve qu’il n’y existe pas une faille du même genre) la seule façon de réaliser la même chose sous iOS et WP c’est de trouver des collisions ou d’avoir la clé privée.


votre avatar







Ly-sAn a écrit :



Pour une fois que je suis content de tourner sur Windows (phone) concernant la sécurité <img data-src=" />







« Qui est plus aveugle que celui qui ne peut pas voir ? »


votre avatar







dj0- a écrit :



Comme évoqué plus haut par Khalev, imagine que le compte de facebook (ou gameloft) sur le play store soit compromis, et que soit proposé au téléchargement une application qui possède la même signature que l’app légitime mais qui est vérolée?

Tu imagines les dégâts?







Oui, ce serait catastrophique.

Mais c’est pareil pour tous les stores du monde : téléphoniques, consoles de jeu, etc.

Dès que l’on a accès au compte du dev, on peut faire ce que l’on veut.

(et encore, pas tout à fait : il y a des vérifications de faites par Google lors d’une publication, et un délai qui peut aller jusqu’à une semaine)



Bref, une faille est viable quand elle permet de contourner, ou de compromettre les avantages énormes de ce compte développeur.

Mais cette faille ne le permet pas, donc ce n’en est pas une.


votre avatar







spidy a écrit :



je me pose la même question.



et aussi, jusqu’à quelle version d’android la faille existe ? 4.1, 4.2 ?





La faille concerne toutes les versions depuis la 1.6, et n’est actuellement pas corrigée (marrant d’ailleurs, vu qu’ils disaient qu’ils rendraient toute faille de sécu publique au bout de 7 jours <img data-src=" /> )

Le seul device qui ne semble pas touché est le S4 (peut être une modification faite par Samsung directement)


votre avatar







Khalev a écrit :



Actuellement (sous réserve qu’il n’y existe pas une faille du même genre) la seule façon de réaliser la même chose sous iOS et WP c’est de trouver des collisions ou d’avoir la clé privée.







Ce qui ne servirait pas à grand chose vu que WP ne permet pas d’installer une application sans passer par le store officiel. A part dans le contexte d’une entreprise, qui publie ses propres applications en interne. A ce moment là effectivement il faut pirater le repository de l’entreprise ET obtenir la clé, la faille permettrait de s’abstenir de cette deuxième étape. C’est le seul impact que je vois sous Windows Phone.


votre avatar







Khalev a écrit :



Actuellement (sous réserve qu’il n’y existe pas une faille du même genre) la seule façon de réaliser la même chose sous iOS et WP c’est de trouver des collisions ou d’avoir la clé privée.







Dans ma boite, on vend des templates d’app tous les jours, et des outils pour les modifier à la volée.

La signature reste, et on laisse au client de changer les images, les couleurs, les liens URL de son choix…

Il recompile l’app sans nous, et sans changer la signature, et il publie l’app comme il veux.



Je ne travaille que sur la version Android, mais le même outil est fonctionnel sur iOS.

Donc je peux affirmer que c’est tout à fait possible chez la concurrence de Google.


votre avatar

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… )

votre avatar

Lëkki,Apple, Microsoft, aiment cette news.

votre avatar

It’s not a bug, its a PRISM feature! <img data-src=" />

votre avatar







SebGF a écrit :



C’est bien là que le modèle des smartphones est pourri… C’est le matériel qui dicte que le suivi du système. C’est clairement anormal comme fonctionnement, uniquement fait dans le but de vendre du device.



Je ne vois pas en quoi au nom de la durée de vie (pour info, mon iPhone 3GS a trois ans et demi et ne montre aucun signe de fatigue niveau batterie ou matériel en général, et il n’est plus supporté désormais) du matériel ce serait au constructeur de proclamer l’abandon du support logiciel. C’est une aberration totale. Surtout quand le constructeur et le développeur du système sont deux entités différentes !



Le hardware et le software doivent être dissociés pour les smartphones. Le modèle actuel est clairement malsain, fermé, et pourri jusqu’à l’os.



Accessoirement, le support de Windows 2000 s’est arrêté en 2010, soit dix ans après sa sortie commerciale. Windows 2005 par contre perso je connais pas, mais si tu voulais parler de 2003, il est encore en support étendu (mises à jours de sécurité, support payant possible) jusqu’en juillet 2015.







Ha mais je suis d’accord avec toi ! Mon galaxy , premier du nom, sans le “S” fonctionne toujours, il me sert de tel Pro et de baladeur MP3. Par contre, mon galaxy S est tombé en rade deux ans apres que je l’ai acheté et un mois apres la garantie…. Mon Note 2 tiens la route … pour le moment ^^

De meme, que j’ai des amis qui ont eu des ennuis avec leurs Iphones, du 3GS au 4S. Apres reparation, c’est reparti



Mais c’est la loterie.

un ordinateur classique, est plus robuste (en general)



Mais oui, je trouve aussi anormal que ce soit le matos qui dirige tout, et que les marques en profitent. Le galaxy S sur lequel jelly bean fonctionne impec dessus alors que samsung n’est jamais allé plus loin que la 2.1 dessus est un exemple.



Mais c’est comme ca malheureusement, obsolescence programmée.



Les gens doivent changer leurs appareils parce que c’est imposé, ils feront donc les mises a jour…. de force….





bon jarrette mon hors sujet.


votre avatar







GiLidan a écrit :



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 ^^.







Je me suis moi-même toujours posé la question.



C’est évident qu’il y aura toujours des failles et des grosses un jour ou l’autre. Pourquoi ne pas avoir un système de mises à jour automatiques pour tous les téléphones (comme Windows Update). Les constructeurs fourniraient qu’une couche de plus.


votre avatar







Khalev a écrit :



Que toi tu ne parles pas de la signature numérique de l’APK peut-être, mais la faille porte sur la signature numérique. Et dans ce cas tu es hors sujet depuis le début



Je comprends pas ce que viennent faire les lois anti-trust dans la vérification par le hash. C’est le genre de méthode qui est utilisé… quasiment partout où il y a échange de fichier sans que ça pose problème.







Dans ce cas, je me clarifie :

La “signature numérique” consiste uniquement à un tag dans l’apk, rien de plus.

On peut récupérer un tag (cette fameuse “signature”), et l’appliquer à un autre APK depuis toujours en une ligne de code.

Tous les outils nécessaires sont disponibles dans les outils du SDK oficiel de Google.



Donc oui, tu peux prendre un APK vérolé, et le signer avec la clé d’Angy Birds. C’est très simple, rien ne nous en a jamais empêché.

Par contre, ce fameux APK falsifié ne pourra jamais être distribué à grande échelle. On ne peut le publier sur Google Play sans avoir le mot de passe du compte Google Play Dev de Rovio.



Donc à moins de publier ton APK falsifié sur un store obscur, ou un site de torrents, tu ne peux “contaminer” personne.

Mais si tu arrives à faire en sorte que des gens l’installent, il n’y aura aucun hash de l’application, ni aucune vérification envoyée à Google Play (pour la simple et bonne raison qu’Android a été conçu pour pouvoir fonctionner sans Google).



C’est plus clair?


votre avatar







Glubglub a écrit :



Dans ma boite, on vend des templates d’app tous les jours, et des outils pour les modifier à la volée.

La signature reste, et on laisse au client de changer les images, les couleurs, les liens URL de son choix…

Il recompile l’app sans nous, et sans changer la signature, et il publie l’app comme il veux.



Je ne travaille que sur la version Android, mais le même outil est fonctionnel sur iOS.

Donc je peux affirmer que c’est tout à fait possible chez la concurrence de Google.







Sauf que sous iOS l’application est signée après la compilation avec la clé privée du client. Il n’est pas possible de modifier le package après qu’il soit signé à moins de posséder cette clé privée (même si on a accès au compte développeur, car la clé privé ne peut pas être retéléchargée naturellement)


votre avatar







Glubglub a écrit :



Mais si tu arrives à faire en sorte que des gens l’installent, il n’y aura aucun hash de l’application, ni aucune vérification envoyée à Google Play (pour la simple et bonne raison qu’Android a été conçu pour pouvoir fonctionner sans Google).







Tu peux vérifier une signature sans rien envoyer à Google, cf. l’article Wikipedia de Khalev.


votre avatar

Google peut désinstaller une application installée hors google play, ça c’est sûr j’en ai fait l’expérience

votre avatar







Khalev a écrit :



“allows a hacker to modify APK code without breaking an application’s cryptographic signature”. http://bluebox.com/corporate-blog/bluebox-uncovers-android-master-key/)







Du coup, comment la modification des données peut ne pas entrainer la modification de la signature?



En lisant l’article de Bluebox, j’ai un peut l’impression qu’ils jouent sur les mots pour faire monter la mayonnaise.



Vaut mieux attendre plus de détails avant de juger si il s’agit d’une faille, d’une absence de fonctionnalité ou d’un gros malin qui a voulut faire parler de lui.



PS: Pour ceux qui ont déjà développé sous Android, une installation d’application consiste à une extraction du contenu de l’APK dans un dossier ou les données sont gardés dans cette archive?


votre avatar







Glubglub a écrit :



Je ne travaille que sur la version Android, mais le même outil est fonctionnel sur iOS.

Donc je peux affirmer que c’est tout à fait possible chez la concurrence de Google.







Autant je ne connais rien au dev Android, autant ce que tu racontes sur IOS est archi-faux. Ce qui me confirme que tu dois aussi te tromper pour Android :)



Ce que tu décris ne peut fonctionner que sur un IOS jailbreaké, dont le système de confiance a été cassé.


votre avatar







belgeek a écrit :



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.







mais non, même pas, les gens qui piratent cours le même risque que les gens qui pirate pas : l’application ne vole pas tes contacts sans te le signaler.



Juste que lorsque tu pirates une appli, tu peux pas savoir si celle que tu télécharges est vraiment “L’Officiel”.



Arrêtez de flipper..


votre avatar







dj0- a écrit :



Google peut désinstaller une application installée hors google play, ça c’est sûr j’en ai fait l’expérience





Apple, MS, Amazon et BB aussi



Pour le moment seul Google et Amazon l’ont fait, mais ça n’empêchera pas les deux autres de le faire si ils le juge nécessaire <img data-src=" />


votre avatar







von-block a écrit :



Je me suis moi-même toujours posé la question.



C’est évident qu’il y aura toujours des failles et des grosses un jour ou l’autre. Pourquoi ne pas avoir un système de mises à jour automatiques pour tous les téléphones (comme Windows Update). Les constructeurs fourniraient qu’une couche de plus.







Actuellement la surcouche des constructeurs va plus loin que le launcher. Certains fichiers d’Android (.jar du système) sont modifiés… <img data-src=" />



Il faudrait effectivement une plus grande séparation des composants pour que Google puisse directement pousser des updates système.


votre avatar







madjawa a écrit :



Sauf que sous iOS l’application est signée après la compilation avec la clé privée du client. Il n’est pas possible de modifier le package après qu’il soit signé à moins de posséder cette clé privée (même si on a accès au compte développeur, car la clé privé ne peut pas être retéléchargée naturellement)







Ok, donc la signature n’est pas seulement l’identifiant du compte Itunes du vendeur. Elle contient donc aussi un hash de l’app.



J’imagine que ce hash est vérifié par l’AppStore, et qu’il interdit l’installation s’il est falsifié?

Donc, en suivant cette logique, un iPhone aura forcément besoin de l’AppStore pour installer une app.



Mais (pour la 100ème fois), Android a été fait pour pouvoir fonctionner sans Google Play, et les stores tiers officiels sont légions.

Une vérification par hash est donc impossible (auprès de quel store on vérifierait la validité du hash ? Tous ?).



Forcément, ça ouvre des failles si quelqu’un fait confiance à un store vérolé. Mais si on s’en tient à Google Play, ou à d’autres stores de confiance, il n’y a pas de faille exploitable.


votre avatar







misterB a écrit :



Apple, MS, Amazon et BB aussi



Pour le moment seul Google et Amazon l’ont fait, mais ça n’empêchera pas les deux autres de le faire si ils le juge nécessaire <img data-src=" />







<img data-src=" /> c’était pour répondre à







Glubglub a écrit :



Mais si tu arrives à faire en sorte que des gens l’installent, il n’y aura aucun hash de l’application, ni aucune vérification envoyée à Google Play (pour la simple et bonne raison qu’Android a été conçu pour pouvoir fonctionner sans Google).



C’est plus clair?





votre avatar







misterB a écrit :



Apple, MS, Amazon et BB aussi



Pour le moment seul Google et Amazon l’ont fait, mais ça n’empêchera pas les deux autres de le faire si ils le juge nécessaire <img data-src=" />





Apple a retiré une application française qui faisait des réduction sur certaines applis, apple l’a laisser où c’était installé ?



Edit : j’ai retrouvé le nom appgratis.


votre avatar







Glubglub a écrit :



La “signature numérique” consiste uniquement à un tag dans l’apk, rien de plus.

On peut récupérer un tag (cette fameuse “signature”), et l’appliquer à un autre APK depuis toujours en une ligne de code.

Tous les outils nécessaires sont disponibles dans les outils du SDK oficiel de Google.







J’y crois pas du tout, désolé (que ce “tag” soit la signature de l’APK).



Peux-tu écrire ici cette ligne de code qui permettrait de copier cette signature d’un APK à l’autre ?


votre avatar

Ben oui, c’est bien connu, cette faille s’appelle PRISM <img data-src=" />

votre avatar

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

votre avatar

C’est très flippant… je me demande comment google va pourvoir y remédier avec la pléthore de versions en circulation…

votre avatar

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.

votre avatar



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?

votre avatar

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…

votre avatar



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.

votre avatar







Droogs a écrit :



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





Le bug a été communiqué en février 2013. Le S4 est sorti bien après, ça ne m’étonnerait pas que la solution ait déjà été mise en place et n’attend que les constructeurs pour être appliquée.


votre avatar

En même temps, sauf à ce que le play store ne soit piraté, la faille ne concerne que les boutiques d’application tierces, non ?

votre avatar

Ça me fait bizarre de voir marquer android là où habituellement on voyait plutôt windows.



Au boulot google, pour corriger la faille.

votre avatar







Pc_user a écrit :



C’est très flippant… je me demande comment google va pourvoir y remédier avec la pléthore de versions en circulation…







Bah dans la mesure ou Google ne semple pas supporter pas les vieilles versions d’Android, ils vont laisser sur le carreaux pas mal d’appareils et donc pas mal d’utilisateurs. Alors cela risque d’être très problématique pour sortir un correctif rapidement.. voir impossible.



D’ici à ce que l’on ai un “androidGate” ou un “virusGates” du coté de chez Google..





votre avatar







dj0- a écrit :



Ok, mais quel est le point d’entrée de cette faille? Une application tierce installée hors market? Ou bien autre chose?





“Suffit” de compromettre le compte du propriétaire de l’appli et de remplacer l’apk par celui modifié.



Le truc c’est que l’utilisateur final n’a aucun moyen de s’en rendre compte.


votre avatar







dj0- a écrit :



Ok, mais quel est le point d’entrée de cette faille? Une application tierce installée hors market? Ou bien autre chose?





Patience, petit scarabée.<img data-src=" />


votre avatar







indyiv a écrit :



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 …







De toute facon l’interface chaise-clavier est toujours pleine de bugs et fait souvent n’importe quoi <img data-src=" />


votre avatar







martin230389 a écrit :



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…









  1. Simple rumeur (plutot d’ailleurs fondée sur une optimisation pour les appareils bas de gamme, monocore et possédant au moins 512 Mo de RAM), et prévu plutot pour l’automne… (ITB | IT | GNT)

  2. Tu crois quand même pas que les constructeurs vont porter tous leurs anciens appareils sous KLP quand même…?!


votre avatar







metaphore54 a écrit :



Ça me fait bizarre de voir marquer android là où habituellement on voyait plutôt windows.



Au boulot google, pour corriger la faille.





C’est déjà fait. Google a été informé en Février 2013, là le site en parle justement parce qu’elle est corrigée et qu’il vont faire une conférence dessus à la Black Hat. Le gros problème c’est le déploiement du correctif.


votre avatar







Glubglub a écrit :



Désolé, mais le dev Android est mon métier.

Ce que l’on appelle signature sur Google Play n’est qu’un tag, pas un hash.

La signature est la même quelle que soit la version de l’app.



Et j’ai expliqué plus haut qu’un verrouillage via le hash est inenvisageable, cela enfreindrait pas mal de lois.





Si la signature ne change pas en fonction du binaire, c’est pas une signature.

Ça serait pas la “clé publique” de la signature qui ne change pas par hasard?



La cryptographie c’est mon métier. Je ne connais pas exactement le fonctionnement de Gplay mais je connais le fonctionnement de signatures électroniques.



Globalement le fonctionnement d’une signature électronique c’est:

Je génère un couple clé publique - clé privé.

Je calcule un hash de mes données

Je chiffre mon hash avec ma clé privée.

J’envoie mes données, mon hash chiffré et ma clé publique (*)

Le destinataire calcul le hash des données, déchiffre le hash que je lui ai envoyé avec la clé publique et compare les 2. Si les hash sont identique on suppose que les données reçues sont identiques à celles envoyées par la personne possédant le clé privée.



Un schéma représentant la chose :http://commons.wikimedia.org/wiki/File<img data-src=" />igital_Signature_diagram.svg



*:normalement la clé publique est transmise par un autre canal, dans le cas de Gplay c’est possible que se soit avec l’APK et que ce serait donc ce que toi tu appelles la “signature”, c’est normal qu’elle ne change jamais, c’est la seule façon de garantir que celui qui envoie est bien la même personne à chaque fois.



Ceci dit si tu as un lien vers le doc Gplay à ce sujet je suis preneur.


votre avatar







Glubglub a écrit :



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 :




  • Faire en sorte que les gens téléchargent les APK sur des sites de torrent ou des markets obscurs.

  • ou récupérer le MDP du compte Google Play developer de l’app.



    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.







    ok, je comprends mieux.



    En fait, il y a strictement aucune faille si on utilise Google Play, car on est obligé d’avoir une signature valide pour y figurer. à moins de se faire pirater son compte, ET QUE l’une de nos appli fassent des choses embêtantes. MÊME dans ce cas de figure, l’OS nous prévient bien que l’appli à des droits qu’elle prétend avoir, donc aucune faille de la part d’Android.



    Si on télécharge une APK vérolée, il se passe quoi? RIEN, car Android vous dira : “Ce fond d’écran de Martine Aubry recouverte de mièle nue va accéder à vos contacts…”



    Le seul problème, c’est que lorsque l’on télécharge “GMail” depuis un autre store, on a pas la certitude que c’est bien celui de Google.. En aucun cas cette appli ne s’abroge des droits qu’elle ne prétend pas avoir.



    Donc c’est pas une faille. Vous avez confiance dans votre antivirus pour le respect de votre vie privé? Non, une appli vérolé qui dit ce quelle fait, c’est quand même vachement rassurant.


votre avatar

+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

votre avatar

@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


votre avatar







fred42 a écrit :



On doit pouvoir détecter une appli modifiée sur les serveurs hébergeant les stores officiels puisque l’on semble pouvoir corriger le problème sur les smartphones par une mise à jour.



Cela éviterait la difficulté de mise à jour des vieux Androïd.





Si l’appli modifiée est signée côté dev, Google voit une modification, mais si la signature est légitime il va la laisser passer pensant à une màj.



En fait j’ai un problème avec ce bug. Si c’est dû à l’algo de signature et que le bug a été corrigé ça veut dire qu’en ce moment les APK sont envoyés avec 2 signatures différentes en fonction si le smartphone possède le correctif ou pas.

Mais ça me semble un peu étrange comme façon de faire (surtout le faire de façon silencieuse comme ça)



D’un autre côté je ne vois pas comment il pourrait faire autrement.







Glubglub a écrit :



Dans ma boite, on vend des templates d’app tous les jours, et des outils pour les modifier à la volée.

La signature reste, et on laisse au client de changer les images, les couleurs, les liens URL de son choix…

Il recompile l’app sans nous, et sans changer la signature, et il publie l’app comme il veux.



Je ne travaille que sur la version Android, mais le même outil est fonctionnel sur iOS.

Donc je peux affirmer que c’est tout à fait possible chez la concurrence de Google.





T’es sûr qu’il change pas la signature? Pour publier l’app il faut pas passer par un outil spécial sur lequel le dév doit se loguer? Ça serait pas cet outil qui s’occupe de signer l’apk?



Comme je l’ai dit je ne connais pas le système de publication sous Gplay, mais ce que tu me décris ne correspond pas du coup à ce qui se fait en matière de signature électronique. À moins que les ressources autres que le code ne sont pas signées, du coup modifier les images/URL/etc. n’influerai pas sur la signature, mais ça me semble encore plus tordu. (Quitte à signer un truc autant tout signer).


votre avatar







Khalev a écrit :



“Suffit” de compromettre le compte du propriétaire de l’appli et de remplacer l’apk par celui modifié.



Le truc c’est que l’utilisateur final n’a aucun moyen de s’en rendre compte.







en même temps si tu as chopé le compte du propriétaire de l’appli, tu pouvais déjà foutre une sacrée merde.



Dans la pratique si tu exploite la faille de cette façon, tu es rapidement repéré, et l’application aspiré des devices par google…

si tu met du code “viral connu”, il ne passera pas le “bouncer” de google

si tu demandes des autorisations suplémentaire, les utilisateurs ne metteront pas forcement à jour …



pour moi ce n’est pas la cible la plus approprié de passer par le market


votre avatar







Khalev a écrit :



Si la signature ne change pas en fonction du binaire, c’est pas une signature.

Ça serait pas la “clé publique” de la signature qui ne change pas par hasard?



La cryptographie c’est mon métier. Je ne connais pas exactement le fonctionnement de Gplay mais je connais le fonctionnement de signatures électroniques.



Globalement le fonctionnement d’une signature électronique c’est:

Je génère un couple clé publique - clé privé.

Je calcule un hash de mes données

Je chiffre mon hash avec ma clé privée.

J’envoie mes données, mon hash chiffré et ma clé publique (*)

Le destinataire calcul le hash des données, déchiffre le hash que je lui ai envoyé avec la clé publique et compare les 2. Si les hash sont identique on suppose que les données reçues sont identiques à celles envoyées par la personne possédant le clé privée.



Un schéma représentant la chose :http://commons.wikimedia.org/wiki/File<img data-src=" />igital_Signature_diagram.svg



*:normalement la clé publique est transmise par un autre canal, dans le cas de Gplay c’est possible que se soit avec l’APK et que ce serait donc ce que toi tu appelles la “signature”, c’est normal qu’elle ne change jamais, c’est la seule façon de garantir que celui qui envoie est bien la même personne à chaque fois.



Ceci dit si tu as un lien vers le doc Gplay à ce sujet je suis preneur.







Pour avoir étudié la cryptographie à la fac, je comprends tes réserves.

Mais la signature de Google Play n’en est pas une. Elle n’en a que le nom (et en français, en anglais ça s’appelle une clé).

Ce n’est vraiment qu’un tag, et ce n’est utilisé que comme tel.



Cela e pose un problème que si l’on a déjà un accès total au compte Google Play Developper, cela n’est pas une faille.

Encore une fois, ce n’est pas plus une faille que la possibilité de forker une application opensource. Pourtant les applications opensource avec des payements inapp existent.



La doc Google play est très complète, si tu veux de la lecture.


votre avatar







fraoch a écrit :



@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 ne vois pas en quoi un PC durerait plus longtemps qu’un téléphone.


votre avatar







dj0- a écrit :



Comme évoqué plus haut par Khalev, imagine que le compte de facebook (ou gameloft) sur le play store soit compromis, et que soit proposé au téléchargement une application qui possède la même signature que l’app légitime mais qui est vérolée?

Tu imagines les dégâts?







ben oui, il y a un(e faille du) compte facebook et donc des dégats … mais je ne vois toujours pas en quoi le fait que facebook aurait alors à s’excuser de s’être fait compromettre son compte et aurait à demander de supprimer son apps et de la re-télécharger, défini une compromission de l’os ormis le fait que l’os aurait donc permis quoi que ce soit de facebook. Le problème serait ici que le compte de facebook aurait été compromis (ce qui est difficile vu leur fonctionnement) et je ne voit effectivement pas comment une telle compromission ne pourrait pas faire de dégâts. La seule façon de ne pas en faire dans l’hypothèse gardée de compromission d’un compte comme facebook, c’est de ne pas donner de compte à facebook … C’est la compromission du compte qui serait ici problématique (ou plutôt facebook dans ce cas très précis).


votre avatar







trash54 a écrit :



faut se mettre au gout du jour <img data-src=" />







oué mais il y a toujours un clavier quand même <img data-src=" />



bon après interface chaise-clavier, pied-tactile, canapé-tactile , lit-tactile, cabinet-clavier-tactile, ça reste basé sur un même modèle de device buggué de partout <img data-src=" />


votre avatar







Khalev a écrit :



Si l’appli modifiée est signée côté dev, Google voit une modification, mais si la signature est légitime il va la laisser passer pensant à une màj.







Pas vraiment, il ne considère une mise à jour que si le numéro de version est changé. Cela est indépendant de la signature avec le keystore.



Il ne fait aucun hash de l’app. Jamais.

Google ne voit pas de modification, il n’a aucun moyen de le faire :




  • Une fois l’appli installée, toutes les données stockées sur l’appareil sont potentiellement modifiées. Il n’y a donc aucun hash/identifiant fiable possible.

  • Si le hash est vérifié par Google à l’installation de l’APK, cela obligerait à passer par Google play en permannence. Cela verrouillerait tous les autres stores (Amazon, Ouya, etc…) et imposerait encore plus le monopole de Google (pour lequel il se fait déjà taper sur les doigts).







    Khalev a écrit :



    En fait j’ai un problème avec ce bug. Si c’est dû à l’algo de signature et que le bug a été corrigé ça veut dire qu’en ce moment les APK sont envoyés avec 2 signatures différentes en fonction si le smartphone possède le correctif ou pas.

    Mais ça me semble un peu étrange comme façon de faire (surtout le faire de façon silencieuse comme ça)







    La même appli ne peut pas être publiée avec deux signatures différentes.

    Et oui, on peut même changer la signature en une ligne de code sur le terminal.

    C’est juste un tag ! Il n’a pas la vocation de servir à plus que ça.







    Khalev a écrit :



    T’es sûr qu’il change pas la signature? Pour publier l’app il faut pas passer par un outil spécial sur lequel le dév doit se loguer? Ça serait pas cet outil qui s’occupe de signer l’apk?



    Comme je l’ai dit je ne connais pas le système de publication sous Gplay, mais ce que tu me décris ne correspond pas du coup à ce qui se fait en matière de signature électronique. À moins que les ressources autres que le code ne sont pas signées, du coup modifier les images/URL/etc. n’influerai pas sur la signature, mais ça me semble encore plus tordu. (Quitte à signer un truc autant tout signer).







    Certain, il y a tous les outils pour décompiler/modifier/recompiler les APK dans le SDK de Google.

    Encore une fois : la “signature” n’est pas un hash. Il n’a jamais eu la vocation de l’être. C’est juste un tag pour Google Play, rien de plus.

    Elle a peut être un nom ambigu, (en tout cas en français), mais ce n’est pas une faille au système.



    Et je pense que la vérification par le hash est probablement impossible sans violer pas mal de lois antitrusts.


votre avatar







Ly-sAn a écrit :



Pour une fois que je suis content de tourner sur Windows (phone) concernant la sécurité <img data-src=" />





Le tout est d’y croire, ou de ne pas savoir. <img data-src=" />


votre avatar







Khalev a écrit :



Si l’appli modifiée est signée côté dev, Google voit une modification, mais si la signature est légitime il va la laisser passer pensant à une màj.



En fait j’ai un problème avec ce bug. Si c’est dû à l’algo de signature et que le bug a été corrigé ça veut dire qu’en ce moment les APK sont envoyés avec 2 signatures différentes en fonction si le smartphone possède le correctif ou pas.

Mais ça me semble un peu étrange comme façon de faire (surtout le faire de façon silencieuse comme ça)





En lisant le site de Bluebox, j’ai l’impression que le bug est lié à une anomalie dans la vérification de la signature et dans l’installation des applications.





The vulnerability involves discrepancies in how Android applications are cryptographically verified & installed, allowing for APK code modification without breaking the cryptographic signature.





Cela laisse supposer soit que le code n’est pas vérifié d’un point de vue signature lors d’une installation, soit pire, que le code n’est pas compris dans la signature ce qui me semble trop gros.



Si c’est juste la vérification qui manque à l’installation, il suffit de l’ajouter pour corriger le bug.



La seule chose que l’on peut affirmer, c’est que l’on n’a pas assez d’informations pour comprendre la faille. Il faut attendre les infos au Black Hat USA 2013, donc le premier Août au plus tard.


votre avatar

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?

votre avatar







Glubglub a écrit :



Bien, dans ce cas je vais utiliser le vocabulaire du cryptographe, pour éviter les confusions.

Désolé si Android ne respecte pas les normes.





Est-ce bien Android?





Glubglub a écrit :



On peut aisément copier un certificat sans problème, et l’appliquer à un tout autre APK.





Ouai enfin faut juste obtenir la clé privée qui est privée justement. Le certificat contient juste la clé publique.





Glubglub a écrit :



Les mises à jour sur le store (à condition d’avoir les accès au compte Google Play du Dev) ne vérifient que ça, lorsqu’une mise a jour est soumise.

Lorsqu’une mise à jour est validée et publiée, la vérification du dld se fait avec le hash.

Jusqu’ici, on est d’accord…





Ouai juste vérifie des signatures, donc des hash.





Glubglub a écrit :



Bien, maintenant la terrible faille est que la gestion des tokens est basée sur le certificat, et non pas sur le hash.

A bien y réfléchir, la plupart des stores ne re-demandant pas les permissions à chaque maj a un fonctionnement identique.





Si pas de modification des permissions, pas de demande. Sinon ça redemande. (On a un message nous disant que la maj est prête mais faut aller sur le store qui nous redemande de vérifier les autorisations, j’ai déjà eu le cas).





Glubglub a écrit :



Mais la faille est donc que l’on peut falsifier un apk, et utiliser les permissions d’une autre appli.





La faille c’est qu’on peut falsifier un apk et utiliser ses propres permissions. Si tu falsifie un APK constructeurs, tu as des droits équivalents au root.





Glubglub a écrit :



C’est mal, mais cet APK falsifié n’a aucun moyen d’être publié sur un store sérieux.

Donc on en revient à la conclusion que je répète depuis tout l’après midi :

Tant que l’on ne télécharge pas ses apk sur un store obscur ou un site de torrent, cette “faille” ne pourra pas infecter 99% des machines, comme son titre raccoleur le clame.





http://www.ehackingnews.com/2013/05/sky-news-google-play-account-hacked-by.html

<img data-src=" />


votre avatar







Raknor a écrit :



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?





Mais la classe faut bien un import pour l’appeler, donc ça impliquerai de modifier du code pour l’import. Mais ouai c’est peut-être une solution, genre surclasser une classe basique et avoir le trojan stocké dans le “constructeur” de la classe(je suis pas expert java non plus, mais il doit bien y avoir une fonction par défaut appelée à l’instanciation d’une classe).


votre avatar

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ù?

<img data-src=" />



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

votre avatar







barbach a écrit :



Quid de la vulnérabilité des versions custom d’android (type CyanogenMod) ?





Apparemment Google n’a pas publié le patch pour AOSP, du coup je vois mal les projet qui l’utilise l’avoir sous la main. Par contre une fois qu’il sera sorti je pense qu’il sera instantanément intégré aux nightly.



source :

“Google will soon release a patch to the Android Open Source Project (AOSP), Bluebox chief technology officer Jeff Forristal said.” (C’est le gars qui va faire la présentation à la BlackHat).

http://threatpost.com/android-vulnerability-enables-malicious-updates-to-bypass-…


votre avatar

@Khalev



J’ai déja vu des



import com.truc.machin.chouette.*;



pour éviter de se taper la liste des classes à importer.

votre avatar







Raknor a écrit :



@Khalev



J’ai déja vu des



pour éviter de se taper la liste des classes à importer.





#spafo

regarde son code <img data-src=" />



(nan j’déconne je fais de pas Java moi)



Ceci dit je ne sais pas à quel point il est facile d’ajouter une classe comme ça et qu’elle soit prise en compte.


votre avatar



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 ?

votre avatar







Khalev a écrit :



Mais la classe faut bien un import pour l’appeler, donc ça impliquerai de modifier du code pour l’import. Mais ouai c’est peut-être une solution, genre surclasser une classe basique et avoir le trojan stocké dans le “constructeur” de la classe(je suis pas expert java non plus, mais il doit bien y avoir une fonction par défaut appelée à l’instanciation d’une classe).







En java, le seul chargement d’une classe n’exécute pas de code de la classe.

Le code s’exécute à partir du moment où on initialise la classe.



Une classe est initialisée seulement si:

* on crée une instance: new Truc()

* on appelle une méthode statique: Truc.machin()

* on accède a un champ statique: Truc.bidule = 2

* on accède a la classe par reflection: Class.forName(“Truc”).blablabla()


votre avatar

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 <img data-src=" />

votre avatar







127.0.0.1 a écrit :



En java, le seul chargement d’une classe n’exécute pas de code de la classe.

Le code s’exécute à partir du moment où on initialise la classe.



Une classe est initialisée seulement si:

* on crée une instance: new Truc()

* on appelle une méthode statique: Truc.machin()

* on accède a un champ statique: Truc.bidule = 2

* on accède a la classe par reflection: Class.forName(“Truc”).blablabla()





Mais justement si tu surclasses une classe (tu crées une classe portant le même nom qui sera appelée à la place de la classe originale, je sais pas si c’est possible ça en java) tu peux modifier la fonction appelée par new Truc().



Je sais que ce genre de truc est possible en C C++, mais la difficulté serait de faire en sorte que la classe soit bien importée sans modifier le code. <img data-src=" />


votre avatar

@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?

votre avatar







fred42 a écrit :



J’ai aussi pensé à un truc comme ça à force de lire différents trucs sur le sujet.

C’est un peu gros, mais c’est typiquement le genre de bug qui se corrige en 2 lignes de code comme l’a indiqué Forristal : vérifier que le fichier est bien dans la liste des fichiers et qu’il a bien le bon SHA1







«Oh pardon chef, je croyais que || c´était l’opérateur ‘et’»


votre avatar







Raknor a écrit :



@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:



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?







En java, les attributs sont toujours encapsulés dans une classe. Il n’existe pas de “variables globales”. Il faut forcément mettre cette variable dans une classe et accéder explicitement à la classe.



[quote:4658931:Khalev]Mais justement si tu surclasses une classe (tu crées une classe portant le même nom qui sera appelée à la place de la classe originale, je sais pas si c’est possible ça en java) tu peux modifier la fonction appelée par new Truc()./quote]



Oui, c’est possible si tu injectes dans le JAR une classe qui porte le même nom qu’une autre, afin qu’elle se charge à la place de celle d’origine. Mais dans ce cas là, elle n’a pas la même signature SHA1. <img data-src=" />


votre avatar







Khalev a écrit :



Mais il faut la clé privée d’Angry Bird pour ça. La clé (contenu dans un certificat) qui est fourni avec l’APK est la clé publique qui permet de vérifier que le hash est bon. Elle ne peut-être utilisée pour signer un APK.



C’est la base de la crypto asymétrique. Toute la sécurité repose sur le fait que la clé privée est en théorie protégée (tu n’as besoin de la communiquer à personne la clé publique est là pour ça).



dans le cas qui nous intéresse ça fait que quelqu’un qui pirate le compte de Rovio (plus simple que d’obtenir la clé privée en théorie) ne pourra publier une maj de l’appli puisque la signature ne correspondra pas à celle utilisée habituellement.





Pour moi il y a une partie de l’APK qui n’est pas couvert par la signature et ils ont réussi à y intégrer du code et à le faire s’exécuter. Ne connaissant pas la structure exact d’un APK ni le process de signature je ne saurais t’en dire plus ni aller plus loin dans la confirmation/infirmation de cette théorie.



Ce serait comme un gars qui envoie un mail avec une pièce jointe, signe le contenu de son message mais pas la pièce jointe, un pirate intercepte le truc, modifie la pièce jointe. Son destinataire ne vérifie que la signature du message (ils utilisent le même programme pour signer et vérifier, donc il a les mêmes défauts de conception) et pas de la pièce jointe Le mail dit au destinataire d’ouvrir la pièce jointe, confiant, celui-ci s’exécute.





Surement, c’est le gros problème de la Black Hat, c’est devenu hyper “commercial” et pas mal de participants essaient de se faire mousser (ça n’enlève en rien la qualité des présentations, mais c’est plutôt toute la com autour qui est assez insupportable).









Je pense que vous ne parlez pas de la même chose depuis le début.



Il n’empêche, cette faille (puisque ç’en est bien une), même si elle est très gênante, est très difficile (si ce n’est impossible) à implémenter via Google Play.



D’une part, généralement, il faut compromettre un compte éditeur (ce qui se saura très vite), publier rapidement une MAJ (pour que les gens la fasse) qui passe le bouncer….



Mouais…j’ai des doutes sur une réelle faisabilité et même sur l’utilité pour un hacker (puisque découvert ultra rapidement)…et pour le coup, j’ai encore l’impression d’une énième opération de com sur la sécurité Android…le marronnier depuis plusieurs années, histoire de continuer à alimenter les débats







Au passage, compromettre un compte développeur sans compromettre sa clés privé? WTF! Genre, tu te fais remarquer en sachant que tu n’en fera pas grand chose….Et pour le coup, si tu compromet la compte ET la clés privé, toutes les plateformes sont dans le même sac !! (et ne dépendent alors que des procédures de vérifications de MAJ, qu’il faudra encore passer !)


votre avatar







Skiz Ophraine a écrit :



De toute facon l’interface chaise-clavier est toujours pleine de bugs et fait souvent n’importe quoi <img data-src=" />







l’utilisateur de smartphone est souvent debout <img data-src=" />


votre avatar







Khalev a écrit :



“Suffit” de compromettre le compte du propriétaire de l’appli et de remplacer l’apk par celui modifié.



Le truc c’est que l’utilisateur final n’a aucun moyen de s’en rendre compte.







mouais, c’est un exemple en effet.

Je suis préssé d’en savoir plus pour savoir comment s’en prémunir car mon téléphone ne sera plus mis à jour. (Même par la communauté ça devient sporadique, alors… HTC Desire avec un portage de CM10.1)





psn00ps a écrit :



Patience, petit scarabée.<img data-src=" />





<img data-src=" />


votre avatar

Put* que je suis content de pas être sous android

votre avatar







Skiz Ophraine a écrit :



De toute facon l’interface chaise-claviertactile est toujours pleine de bugs et fait souvent n’importe quoi <img data-src=" />







faut se mettre au gout du jour <img data-src=" />


votre avatar

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 :




  • Faire en sorte que les gens téléchargent les APK sur des sites de torrent ou des markets obscurs.

  • ou récupérer le MDP du compte Google Play developer de l’app.



    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.

votre avatar

Pas de problème pour moi, je suis 24h/24 en mode avion <img data-src=" /><img data-src=" /> et c’est vrai (je n’utilise que mon ancien mobile)<img data-src=" /><img data-src=" />

votre avatar







Garat a écrit :



En même temps, sauf à ce que le play store ne soit piraté, la faille ne concerne que les boutiques d’application tierces, non ?









Khalev a écrit :



“Suffit” de compromettre le compte du propriétaire de l’appli et de remplacer l’apk par celui modifié.



Le truc c’est que l’utilisateur final n’a aucun moyen de s’en rendre compte.







je me pose la même question.



et aussi, jusqu’à quelle version d’android la faille existe ? 4.1, 4.2 ?



votre avatar







Glubglub a écrit :



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 :




  • Faire en sorte que les gens téléchargent les APK sur des sites de torrent ou des markets obscurs.

  • ou récupérer le MDP du compte Google Play developer de l’app.



    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.







    Sauf que si cette faille n’existait pas, google pourrait connaître sur quels appareils est installée une app vérolée et les désinstaller à distance.

    Avec la faille tu ne fais plus la différence entre les app vérolées et les app légitimes


votre avatar







Glubglub a écrit :



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.





Euh…en.wikipedia.org WikipediaAu lieu de dire des bêtises, renseigne-toi avant.





Glubglub a écrit :



C’est ridicule, pour nuire au public, on devrait soit :




  • Faire en sorte que les gens téléchargent les APK sur des sites de torrent ou des markets obscurs.

  • ou récupérer le MDP du compte Google Play developer de l’app.

    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.





    Et évidemment il n’y a jamais eu de corruption d’un compte Google Play…



    http://www.ehackingnews.com/2013/05/sky-news-google-play-account-hacked-by.html


votre avatar







Lemon Pie a écrit :



Put* que je suis content de pas être sous android





Cool story bro<img data-src=" />





En attendant, les utilisateurs devraient faire très attention à la source d’installation de leurs applications.



Rien de nouveau sous le soleil donc.


votre avatar

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.

votre avatar







seboss666 a écrit :



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.







Vérifier la signature des applications sur leur store, et mettre à jour l’installeur d’application à distance (pas besoin de faire un m.a.j. de l’os pour ça).



ça fait news à clique, et pour le coup, c’est important d’être au courant.



Si un store propose des applications sans vérifier les signatures, c’est ballot.


votre avatar







dj0- a écrit :



Sauf que si cette faille n’existait pas, google pourrait connaître sur quels appareils est installée une app vérolée et les désinstaller à distance.

Avec la faille tu ne fais plus la différence entre les app vérolées et les app légitimes







Je comprends ton raisonnement, mais cette “fonctionnalité” serait impossible à mettre en place :

Google n’a aucun moyen de référencer tous les hashs des stores ne lui appartennant pas. (et encore une fois, il devrait se baser sur les hash et non pas sur la signature des APK pour ça).

Cela assurerai un monopole total du store GooglePlay. Il l’a déjà un peu, c’est vrai, cela tuerai instantanément le store Amazon par exemple.



Bref, je ne pense pas que cet argument soit valable au regard de toutes les lois antitrusts.

Je reste affirmatif sur le fait que ce ne soit pas une faille. C’est tout aussi possible sur iOS, et très certainement sur WindowsPhone.


votre avatar

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 ^^.

votre avatar







nyandog a écrit :



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.







donc c’est une faille, puisque je fais confiance à ce que me dit mon tél sur les droits d’une appli que j’installe depuis n’importe où. Il suffit de vérifier la signature avant de l’installer.



Suffit juste que Google mette à jour l’utilitaire d’installation des apk, puis basta.


votre avatar







nyandog a écrit :



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.







Comme évoqué plus haut par Khalev, imagine que le compte de facebook (ou gameloft) sur le play store soit compromis, et que soit proposé au téléchargement une application qui possède la même signature que l’app légitime mais qui est vérolée?

Tu imagines les dégâts?


votre avatar







barbach a écrit :



Quid de la vulnérabilité des versions custom d’android (type CyanogenMod) ?





Faut voir quand ça a été corrigé dans la branche officielle. Et si le correctif a bien été poussé dans les sources fournies.



Je pense pas qu’ils se soient amusés à retirer ce genre de modif une fois qu’elle a été intégrée (en gros les dernière version doivent être protégée, mais j’ai pas encore trouvé de trace de ça).


votre avatar

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.

votre avatar

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 ?

votre avatar







barbach a écrit :



Quid de la vulnérabilité des versions custom d’android (type CyanogenMod) ?





Pareil, les méthodes de téléchargement, de vérification et d’installation des applications sont les mêmes quelles que soient les constructeurs/roms.



Elles sont inhérentes à l’AOSP


votre avatar







NeVeS a écrit :



Tu es d’accord que ce que tu dis est en totale opposition avec le site d’Android ?



https://developer.android.com/tools/publishing/app-signing.html







C’est pour cela que je me demande si en réalité, la sous-disant faille ne consisterait pas à modifier le contenu fourni par l’APK après son installation depuis un autre logiciel. Vu que la signature est vérifié avant l’installation, donc avant la modification, pas de problème détecté.



Dans ce cas ce ne serait pas un problème de sécurité dans le système de distribution actuel mais un manque de fonctionnalité.


votre avatar







Magyar a écrit :



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 ?





Vu que la boite n’en parle que maintenant et que les PoC et la conférence va avoir lieu à la fin du mois (1er aout), je pense que c’est déjà corrigé et surement en train d’être déployé chez les constructeurs.



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).


votre avatar

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.

votre avatar



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 :)

votre avatar







Shyfer a écrit :



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.







Honnêtement, sans troller cette fois <img data-src=" />, je crois que c’est plutôt un moyen de faire réfléchir sur les blocages exagérés qui ont parfois lieu sur les smartphones.



Si ça se trouve les constructeurs sont actuellement pris à leur propre jeu à ne pas pouvoir répandre de correctifs à cause de ces limitations, et pour Google ça risque d’être ingérable.


votre avatar







Para-doxe a écrit :



C’est pour cela que je me demande si en réalité, la sous-disant faille ne consisterait pas à modifier le contenu fourni par l’APK après son installation depuis un autre logiciel. Vu que la signature est vérifié avant l’installation, donc avant la modification, pas de problème détecté.



Dans ce cas ce ne serait pas un problème de sécurité dans le système de distribution actuel mais un manque de fonctionnalité.





Sauf que BlueCoatBox parle d’appli corrompue sans que l’app store ne s’en rende compte. C’est donc que la modif devrait être visible lorsque l’appli est sur l’appstore.(oui je sais ça reste un communiqué de presse pour attirer des gens à leur présentation)



De plus : “Device owners should be extra cautious in identifying the publisher of the app they want to download.”



Pour moi ça veut bien dire que l’appli est déjà pourrie au moment où tu la télécharges.



(Mais je peux me tromper, ce que tu dis me semble parfaitement possible aussi)


votre avatar







Khalev a écrit :



signature = hash chiffré.



En gros pouvoir modifier le code sans modifier la signature c’est comme modifier le code sans modifier le hash. C’est à dire que tu fais confiance à un code qui n’est pas celui initialement fourni par le développeur officiel.



Tu le vois le problème là? Maintenant tu associes ça à une protection des comptes officiels qui laisse parfois à désirer et tu obtiens un joli cocktail explosif.







Râââh !

Ok, donc tu as raison. La signature EST un hash chiffré.

Effectivement, cela engendre des failles énormes.



Si seulement cette fameuse signature n’était pas un hash chiffré de l’APK, et que le hash était ailleurs, alors il n’y aurait plus de problème !



Si seulement…

Ceci dit, c’est quand même étonnant qu’ils arrivent à faire des MaJ d’applis (donc changer le hash de l’APK), tout en gardant la même signature…

C’est même la condition sinéquanone pour faire une MaJ.

C’est à croire qu’il n’y a pas de hash chiffré de l’APK dedans !







NeVeS a écrit :



Tu es d’accord que ce que tu dis est en totale opposition avec le site d’Android ?



https://developer.android.com/tools/publishing/app-signing.html







J’en ai un peu marre d’argumenter, et de recevoir 60 notifications à l’heure.



Alors relis-le, et teste des trucs. Je serai le premier à te féliciter si tu arrives à contaminer 99% des appareils Android.

Si tu préfères penser que tu as raison, alors il y a manifestement un énorme problème sur Android depuis 4 ans, et Google distribue depuis toujours les outils pour l’exploiter.



C’est quand même un coup de bol énorme que personne ne l’ait exploité, non?

C’est d’autant plus étonnant que les seuls problèmes sur Android viennent des APK téléchargées depuis des sites peu fiables, et des pseudo stores obscurs !



Comment Google Play, Amazon et compagnie ont pu éviter les problèmes pendant 4 ans avec un système aussi bancal ?


votre avatar







Khalev a écrit :



Vu que la boite n’en parle que maintenant et que les PoC et la conférence va avoir lieu à la fin du mois (1er aout), je pense que c’est déjà corrigé et surement en train d’être déployé chez les constructeurs.



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).







On peut tout du moins l’espérer…


votre avatar







Glubglub a écrit :



J’en ai un peu marre d’argumenter, et de recevoir 60 notifications à l’heure.



Alors relis-le, et teste des trucs. Je serai le premier à te féliciter si tu arrives à contaminer 99% des appareils Android.

Si tu préfères penser que tu as raison, alors il y a manifestement un énorme problème sur Android depuis 4 ans, et Google distribue depuis toujours les outils pour l’exploiter.



C’est quand même un coup de bol énorme que personne ne l’ait exploité, non?

C’est d’autant plus étonnant que les seuls problèmes sur Android viennent des APK téléchargées depuis des sites peu fiables, et des pseudo stores obscurs !







Hola, du calme. Ce n’est pas parce que tu répètes quelques choses 50 fois que ça en devient vrai. En attendant je n’ai toujours pas vu cette fameuse ligne de code qui permettrait de copier la signature d’un APK à l’autre et que ce dernier soit valide.



BlueBox parle de “modify APK code without breaking an application’s cryptographic signature”, ils ne disent pas “la signature n’en est pas une et il suffit de la copier pour que l’APK soit valide”.


votre avatar







Glubglub a écrit :



Ceci dit, c’est quand même étonnant qu’ils arrivent à faire des MaJ d’applis (donc changer le hash de l’APK), tout en gardant la même signature…

C’est même la condition sinéquanone pour faire une MaJ.

C’est à croire qu’il n’y a pas de hash chiffré de l’APK dedans !







Visiblement tu as des lacunes en chiffrement asymétrique. Le hash change, évidement, d’une version de l’application à l’autre, mais pas la clé publique. Et c’est cette dernière qui permet de dire si la signature (qui change d’une version à l’autre) est valide ou non. Et sans connaissance de la clé privée, tu ne peux pas forger de signature valide.



Une des possibilités est que la vuln de BlueBox puisse permettre de mettre du code exécutable dans une partie non vérifiée par la signature. Mais ça peut être autre chose.


votre avatar







Glubglub a écrit :



Râââh !

Ok, donc tu as raison. La signature EST un hash chiffré.

Effectivement, cela engendre des failles énormes.



Si seulement cette fameuse signature n’était pas un hash chiffré de l’APK, et que le hash était ailleurs, alors il n’y aurait plus de problème !



Si seulement…

Ceci dit, c’est quand même étonnant qu’ils arrivent à faire des MaJ d’applis (donc changer le hash de l’APK), tout en gardant la même signature…

C’est même la condition sinéquanone pour faire une MaJ.

C’est à croire qu’il n’y a pas de hash chiffré de l’APK dedans !





Je veux pas être méchant, mais t’as rien compris à tes cours de crypto (et à mes explications <img data-src=" />).



Est-ce que ça peut t’aider?http://www.commentcamarche.net/contents/212-signature-electronique



Sinon si tu veux tu peux me contacter par MP (ou ouvre un poste sur le forum et envoie-moi le lien) et je t’expliquerai tout ça calmement en détail. Parce que là tu écris des énormités…



votre avatar







NeVeS a écrit :



Hola, du calme. Ce n’est pas parce que tu répètes quelques choses 50 fois que ça en devient vrai. En attendant je n’ai toujours pas vu cette fameuse ligne de code qui permettrait de copier la signature d’un APK à l’autre et que ce dernier soit valide.



BlueBox parle de “modify APK code without breaking an application’s cryptographic signature”, ils ne disent pas “la signature n’en est pas une et il suffit de la copier pour que l’APK soit valide”.







Il n’y a que deux possibilités :




  • Soit c’est effectivement possible de changer la signature, et je bosse dans l’une des nombreuses boites dans le monde qui savent le faire, et je ne vais pas fournir du code appartennant à mon entreprise.

  • Soit c’est totalement impossible à faire… Et dans ce cas là les auteurs de cet article prétendent qu’un truc impossible provoque une faille de sécurité.









    NeVeS a écrit :



    Visiblement tu as des lacunes en chiffrement asymétrique. Le hash change, évidement, d’une version de l’application à l’autre, mais pas la clé publique. Et c’est cette dernière qui permet de dire si la signature (qui change d’une version à l’autre) est valide ou non. Et sans connaissance de la clé privée, tu ne peux pas forger de signature valide.









    Khalev a écrit :



    (même argument)







    Je suis d’accord avec vous deux.

    Mais si la signature ne change pas d’une version à l’autre, ça veut bien dire que ce n’est pas une “vraie” signature ?

    Dans ce cas, je vous invite à tester le dev Android (c’est gratuit), et à vérifier cette fameuse signature…






Une importante faille de sécurité concernerait 99 % des appareils Android

  • Le saint Graal de la faille de sécurité

Fermer