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

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…https://en.wikipedia.org/wiki/Digital_signature

Au 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

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.

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" />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.

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

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

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" />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.

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

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)

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.

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
" />