L’app de vérification d’âge de la Commission européenne présente de « grosses lacunes »
Des p'tits trous, des p'tits trous, toujours des p'tits trous
Présentée comme « techniquement prête », l’app de vérification d’âge de la Commission européenne n’a pas tardé à soulever chez certains chercheurs des questions sur sa sécurité. Leurs découvertes sont pour le moins embarrassantes, même si le champ des attaques possibles est limité. Pour Olivier Blazy, contacté par Next, « les grosses lacunes ne mettent pas en danger directement les utilisateurs ».
L’application de vérification d’âge de l’Union européenne est « techniquement prête »… mais l’est-elle réellement ? Peu de temps après l’annonce d’Ursula von der Leyen du mercredi 15 avril, le chercheur en sécurité Paul Moore débusquait des vulnérabilités dans le code de l’app, disponible en open-source sur GitHub.
Des trous dans les bonnes pratiques de sécurité
Durant la configuration, l’application (testée sous Android) demande à l’utilisateur de créer un code PIN, ce qui jusque-là n’a rien d’anormal. Ce code est ensuite chiffré puis stocké dans un fichier local. Pour Paul Moore, ce code n’a aucune raison d’être chiffré car il n’est pas censé être récupérable : en cas de perte, il faut en créer un nouveau. L’app devrait normalement stocker une empreinte irréversible (hash).
Autre gros défaut de cette application : le code PIN sert juste de verrou local, il n’est pas techniquement attaché aux données qu’il protège. Un attaquant ayant accès au smartphone peut aller dans le fichier de configuration, supprimer les valeurs liées au code, relancer l’app et créer un nouveau PIN. Cela lui permettra d’accéder à l’identité d’un autre utilisateur.
Une démonstration confirmée dans une démo vidéo par Baptiste Robert, hacker éthique et patron de Predicta Lab. L’application intègre également une option permettant de désactiver l’authentification biométrique. En modifiant la valeur (de true à false), il est en effet possible de contourner complètement cette étape.
Faut-il pour autant prendre ses jambes à son cou ? « L’attaque la plus crédible, c’est votre neveu qui prend votre smartphone, il ne connait pas le code PIN, mais il existe malgré tout un moyen pour qu’il puisse utiliser votre vérification », explique Olivier Blazy, professeur à l’École polytechnique ayant notamment travaillé avec la CNIL sur un démonstrateur de vérification de l’âge en ligne. Il tempère : « C’est un peu limité comme champ d’attaque. »
Commentaires (32)
Le 21 avril à 11h10
Le 21 avril à 11h44
Je n'ai rien trouvé.
Le 21 avril à 11h54
Dans les deux cas, la façon la plus simple de retrouver le code PIN à partir du hash, reste une table de correspondance d'un million d'entrée ?
Le 21 avril à 12h11
Sauf table de correspondance effectivement mais normalement tu "Sel" ton Hash pour éviter ça.
Modifié le 21 avril à 12h16
Le 21 avril à 13h22
Pour 1 000 000 de possibilités, c'est assez rapide de trouver le bon code. C'est juste un peu plus long que déchiffrer le code pin chiffré.
La question d' @aureus me semble pertinente.
Le 21 avril à 13h41
Quand j'étais étudiant, un prof avait mis en ligne une plateforme totalement gérée via la DB (CouchDB à l'époque) pour qu'on puisse uploader nos projets. Le mot de passe par défaut c'était notre date de naissance (6 chiffres) et toute la base était accessible en lecture seule, l'écriture était limitée à une authentification, il me semble.
Bah j'ai pu bruteforcer tous les mots de passes (sauf celui d'un petit malin qui était parti le changer :-p ) en un temps relativement court.
Le 21 avril à 15h05
Le 21 avril à 13h43
Modifié le 21 avril à 15h10
L'algo de hashage est également à considérer : il existe des algos de hashage qui sont conçus pour prendre du temps pour calculer un hash. Si calculer chaque hash prend 100ms, le calcul d'une rainbow table à 1 million d'entrée (pour un code pin à 6 chiffres) prend un peu plus d'une journée.
Après, de toute façon si la seule chose qui protège l'accès c'est un code pin à 6 chiffres, on voit vite les limites en terme de sécurisation...
Le 21 avril à 15h51
Une table n'est utile que si on n'a plusieurs (généralement, beaucoup) de mot de passe à "craquer". Si on en a qu'un, autant faire un brut force classique. Plus simple, et plus efficace.
Le 21 avril à 17h34
Le 21 avril à 13h41
Un chiffrement d'un code pin impliquerait de deux voir stocker deux informations : La clé ayant servit au chiffrement, et le résultat du chiffrement. Ce qui implique de devoir stocker de manière trés sécurisée à la fois la clé et le résultat du chiffrement. Car si les deux sont compromis, il est évidemment très facile de retrouver le mot de passe.
A contrario, une fonction de hashage ne prend qu'une entrée correspondant au mot de passe, et par une série de décalage de bits, rotations, et autres joyeusetés te produit une sortie unique (en théorie). Mais cette étape de transformation mathématique n'est pas réversible (en théorie). Dès lors, stocker un mot de passe sous cette forme revient à simplement stocker son hash. S'il est compromis, ce n'est pas très grava car la conversion du hash vers le message d'origine est très lourd en temps de calcul.
Ainsi c'est plus safe que de chiffrer, car pas besoin d'une clé à stocker en plus (et ceux de manière sécurisée) et deuxième le hash est prévu pour être facile à calculer dans le sens du mot de passe -> hash, mais dans le sens inverse rendant sa compromission coûteuse pour l'adversaire.
Après il faudrait discuter des algorithmes, des dérivations, du sel (comme mentionné par @Raikiwi avec la table de correspondance (rainbow table dans le jargon) et @ray_lifequest ), du poivre... Mais c'est l'idée.
Le 21 avril à 13h51
En général par contre, c'est effectivement ce qui est recommandé, pour éviter de pouvoir remonter au mot de passe originel et garantir que les responsables même de l'application ne puissent pas récupérer le mot de passe (c'est une sécurité supplémentaire pour les utilisateurs).
A retenir donc : pour la généralité, c'est hashage (avec sel au minimum) et non chiffrement.
Le 21 avril à 19h30
Le 21 avril à 20h51
Le 21 avril à 12h22
Sérieusement, en l"état, faut pas l'utiliser ce truc.
Le 21 avril à 12h53
Le 21 avril à 14h00
Par contre qu'il y ai besoin qu'une personne externe pointe les défauts de sécurité de l'app c'est quand même abusé.
Secure by design qu'il disait...
Le 21 avril à 13h39
Cela dit, l'avantage que l'application soit en open source, c'est qu'elle a permis ce genre d'audit plus facilement. Un bon point pour la transparence.
Modifié le 21 avril à 15h04
Ces algorithmes présentent plusieurs avantages :
Pour plus d'information : https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
Le 21 avril à 20h58
Modifié le 21 avril à 15h28
Il est dit "un attaquant ayant accès au smartphone peut aller dans le fichier de configuration, supprimer les valeurs liées au code", donc l'attaquant doit avoir le phone, et pouvoir éditer un fichier sur la partition système.
Chose possible que si on est root.
Et on peut empêcher une appli de se lancer sur un appareil modifié (avec un root par exemple) en utilisant l'API PlayIntegrity, qui est (quasi) impossible à contourner (beaucoup d'applis bancaires, ou même Google Pay, l'utilisent).
Donc quand ils se défendent et disent "c’est un SDK, un embryon pour que les pays développent ensuite leurs propres apps", eh bien c'est vrai.
Chaque État va proposer sa propre version, et surement y intégrer PlayIntegrity, car les applis sensibles (sérieuses) l'intègrent toutes.
Bref, moi aussi mes applis Android vous pourriez en faire ce que vous voulez si vous avez accès en écriture sur la partition système. Mais je peux me protéger avec PlayIntegrity.
Le 21 avril à 15h23
Modifié le 21 avril à 15h34
Et le dossier "data" n'est accessible que si on est root 🙂
Le 21 avril à 19h45
Et ça, désolé, c'est non.
Que ce soit soumis à une validation utilisateur, que le boot demande confirmation (voire un code PIN) , OK.
Mais interdire le root, c'est admettre que l'algo est faillible et qu'on joue la carte de l’obscurité. Ça achète du temps avant que qu'un hack ne trouve une faille et ça incite à la complaisance.
Outre le fait que c'est remettre à un acteur étranger la possibilité d'utiliser les applis (et un jour le tél ?) puisque Play Integrity échange un token avec un serveur google - serveur qui, si injoignable, implique que le test échoue, ça favorise aussi l'obsolescence programmée lorsque au bout de 2/3 ans les constructeurs arrêtent les mises à jour, et sans possibilité de le reflasher c'est une brique.
J'ai pas ce souci pour des téléphones pro où je ne suis pas administrateur, comme pour mon PC pro managé par l'IT de ma boite où , idem, je ne peux pas aller farfouiller partout.
Mais c'est pas mon PC (Et l'IT de la boite , elle , peux intervenir).
Là, à ce que je sache, je ne loue pas un téléphone à Samsung ni Google, ni Orange ni personne.
l'hégémonie n'est jamais une bonne chose, or là entre Apple et Google , bah on a pas le choix (c'est pas demain la veille que ni l'EU, ni les banques développeront une app pour Ubuntu Touch ou PostmarketOS).
Le 21 avril à 20h41
Ils ont juste été meilleurs que les autres, dans un bon timing, maintenant la course est terminée. Et les banques ne feront jamais des appli pour moins de 1% des utilisateurs.
Windows Phone, blackberry Os, Bada, firefox Os, Symbian, Ubuntu touch, /e/ OS, Sailfish... La liste est longue.
Le 22 avril à 08h45
Un des soucis est que tu commences à avoir certaines banques qui ne permettent même plus un accès par une autre méthode (y compris web) , ou qui oblige à avoir un smartphone pour certaines opérations. On en a déjà parlé bien des fois ici..
Alors oui je comprends les dev de ces applis : Moins de plateformes c'est moins de boulot, et même 2 plateformes c'est 1 de trop déjà (heureusement que des frameworks existent pour mutualiser le dev) , surtout en embrassant la promesse de Google : "Ne vous inquiétez pas notre plateforme est sécurisé, sécurisé je vous dit !" .
Pas si longue si l'on élimine les OS qui ont été officiellement abandonnés.
Pour moi /e/OS n'en fait pas partie car c'est un Android , comme lineage & co.
Donc Ubuntu Touch, Sailfish, Postmarket... j'en connais pas d'autre.
Mais de toute façon, sans une couche de virtualisation pour les app existantes c'est inutilisable en tant que smartphone au sens où on l'entends actuellement.
Le 22 avril à 08h57
Oui c'est un sujet récurrent. Le secteur bancaire est aussi l'un des domaines les plus sécurisé, donc on peut comprendre qu'en réduisant la voilure, ils réduisent aussi les risques, sans trop s'embêter et en réduisant les coûts.
Le 22 avril à 09h05
Le 22 avril à 09h15
Certaines appli marchent avec MicroG, d'autres non (je pense à l'identité numérique et France Connect). Pour les banques ça dépends effectivement des apps de banques - la mienne marche par exemple (Nickel) mais j'ai dû abandonner Boursorama à cause de ça.
J'ai testé mon tel avec PlayIntegrity API Checker, et j'ai un fail sur les 3 niveaux:
Plus PlayIntegrity va se répandre (poussé par Google dans leurs docs & API) plus ça va devenir un problème pour moi.
Le 22 avril à 18h18
Je suis obligé de passer par le site web de Boursorama, par exemple.
Et je suis 100% d'accord avec ton avis sur cette API : le phone nous appartient, et on ne devrait pas dépendre du bon vouloir d'un serveur géré à l'étranger.
Mais bon, comme a dit dvr-x : c'est foutu, la bataille est perdue d'avance.
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?