Sécurité : le péché très peu mignon des apps

Du point de vue de la sécurité des applications mobiles, l'année 2019 peut être considérée comme annus horribilis. Rappelons-nous : d'un simple coup de fil, des hackers prirent le contrôle de dizaines de comptes WhatsApp ciblés.

Au lendemain de la sortie de Tchap, l'application de messagerie sécurisée du gouvernement, 1h15 suffirent à un expert en sécurité pour s'y introduire. Au Japon, l'application de paiement des épiceries 7-Eleven fut désactivée 3 jours après son lancement : des pirates avaient détroussé un millier de clients d'environ 500? chacun.

On aurait pu penser que ces déboires serviraient de leçon aux éditeurs d'applications mobiles. Pourtant pas un mois ne s'écoule depuis sans qu'une entreprise ne soit victime de piratage par le biais du canal mobile.

? En avril 2020, des chercheurs en sécurité (ZecOps) mirent en évidence la possibilité d'attaques élaborées contre l'application native Mail d'iOS.

? En mai, l'app de "sondage social" Wishbone est attaquée : les données privées de 40 millions d'utilisateurs, mots de passe compris, sont dérobées. La firme avait déjà été victime d'un piratage similaire en 2017, portant sur "seulement" 2 millions d'adresses mail.

? Enfin en février, dans un registre moins dramatique, trois hackers éthiques et assurément gastronomes de Hambourg combinèrent plusieurs vulnérabilités de l'app McDonald's pour s'offrir des burgers en quantité potentiellement illimitée. Ils en informèrent McDonald's qui avoua n'avoir rien remarqué.

Quatre raisons qui expliquent les accidents de sécurité trop fréquents

Pourquoi cette litanie des accidents industriels ne se tarit-elle pas ? On peut avancer plusieurs explications.

1. La première tient à l'extraordinaire popularité des smartphones : on en compte aujourd'hui 3,5 milliards, la moitié de la population mondiale. Les applications utilisées par plus de 100 millions de personnes ne sont pas rares. WhatsApp possède plus de 1,5 milliards d'utilisateurs réguliers, parmi lesquels, nécessairement, des personnalités de haut rang. Une telle base est une source de convoitise sans égale pour les assaillants dont certains sont prêts à mettre en oeuvre, pour parvenir à leurs fins, des moyens hors du commun, proportionnels à la valeur de leur cible.

2. La seconde relève paradoxalement de la grande sécurité des plateformes de développement iOS et Android. Apple et Google rivalisent à qui protégera le mieux les données et la vie privée de leurs clients, Apple allant jusqu'à faire un argument marketing de son choix du "privacy by design".
Il est certain que les environnements d'exécution des applications offerts par ces OS sont particulièrement hermétiques aux intrusions (technique du "bac à sable" - sandbox). Le revers de cette médaille est une illusion de sécurité qui pousse les développeurs à baisser la garde : pourquoi se soucier de sécurité si mon OS s'en charge pour moi ?

3. La troisième tient à la relative jeunesse des métiers du développement mobile. L'iPhone vient seulement de fêter son 13ème anniversaire, et si les plateformes se sont certes développées à une vitesse élevée, les équipes qui conçoivent des solutions mobiles n'ont pas toujours été capables de pérenniser leur savoir.
Ainsi, la faille de 7-Eleven mentionnée plus haut tient vraiment du péché de jeunesse : dans la page permettant de modifier son mot de passe, il était possible de se faire envoyer un lien de réinitialisation. à l'adresse de son choix (celle du hacker par exemple) ! On tombe des nues devant tant de légèreté, qu'on peine à imaginer dans un logiciel plus traditionnel.

4. Il résulte des deux précédents points un manque criant de "culture sécurité" chez les acteurs du développement mobile : non seulement chez beaucoup de développeurs, mais aussi les concepteurs, designers, et jusqu'aux équipes dirigeantes.
Contrairement à l'UX, domaine où les collaborations pour ainsi dire interculturelles entre développeurs, designers et chefs de projet sont nombreuses et fructueuses, la sécurité est la grande oubliée de la conception mobile. Au lieu d'être l'affaire de tous, elle n'est l'affaire de personne. Il s'agit d'un cas d'école du syndrome « not my job » : si je ne suis pas responsable de la sécurité de mon app, alors je ne serai pas coupable non plus si celle-ci se fait pirater.

Les applications les plus connues négligent les règles de sécurité basiques

On pourrait croire que les problèmes de sécurité, c'est bien connu, n'arrivent qu'aux autres, et qu'il faut de toute façon déployer des techniques ultra-sophistiquées pour compromettre une app - à l'image des méthodes stupéfiantes de technicité déployées par NSO Group quand elle s'en prit à WhatsApp. Il n'en est rien.

Prenons un exemple concret avec le reverse engineering le plus élémentaire d'une application choisie au hasard parmi le Top 100 de l'App Store. Pour ne pas la citer, nous conviendrons du nom d'emprunt : Doe. Il s'agit d'une app de diffusion de contenus numériques, qui figure dans le Top 10 de sa catégorie. Avec plus de 10 millions d'utilisateurs, Doe joue dans la cour des grands.

25 octobre 2020. Comptons une minute pour télécharger Doe. En deux minutes, à l'aide d'un outil aussi banal que Apple Configurator, un développeur sans talent particulier pourra mettre la main sur le code compilé et les ressources de Doe (son .ipa), puis les parcourir librement. Deux minutes de plus, et le trafic de l'app sera redirigé vers un proxy (Charles par exemple) : c'est ce qu'on appelle une attaque de l'homme du milieu (MIM), qui permet, quand elle réussit, de visualiser tous les échanges réseau.

Si ces deux analyses, statique pour la première, dynamique pour la seconde, ne donnent pas de résultats rapidement, il y a de grandes chances que l'apprenti-hacker se décourage - et c'est bien la moindre des choses qu'on attendrait d'une appli à 10 millions d'utilisateurs ! Or, que découvre-t-on dans Doe ?

1. Le code compilé laisse apparaître de longues chaînes alphanumériques qui ressemblent fort à des clés d'API.

2. L'attaque MIM fonctionne sans encombre : la communication entre Doe et ses serveurs est parfaitement lisible. On y retrouve la clef d'API entrevue à l'étape précédente.

3. Non seulement le trafic est lisible, mais il n'est pas même pas chiffré : les échanges se font en HTTP standard (HTTP-non-S), à rebours de toutes les recommandations.

Quels risques ces vulnérabilités font-elles encourir à Doe ? Ils sont considérables. Muni des clés d'API et d'une compréhension fine de la communication de l'app (grâce aux failles 1 et 2), il est aisé de construire par exemple un service concurrent exploitant, aux dépens de Doe, ses propres API privées ; ou plus sournoisement, coordonner une attaque pour aspirer une bonne partie du catalogue de Doe, ou bien les données partagées de ses utilisateurs.
La 3ème faille peut être exploitée par un concurrent pour générer un affreux bad buzz, sur l'air de : « savez-vous, utilisateurs de Doe, qu'en vous connectant à votre app favorite via par exemple le wifi de votre entreprise, votre employeur peut avoir accès en clair à toute la consommation que vous en faites ? »

Ces trois failles sont pourtant faciles à colmater ! On sait qu'une app ne devrait pas stocker de secrets comme des clés d'API en dur (à tout le moins pas sans un minimum d'obfuscation). On connaît depuis longtemps la contre-mesure efficace du certificate pinning pour freiner les attaques MIM. Par dessus-tout, on ne peut ignorer que les échanges Internet devraient se faire en HTTPS : sur iOS, depuis le lancement d'App Transport Security en 2015, les appels HTTP non sécurisés échouent. à moins d'activer un réglage bien particulier, dangereux, fortement déconseillé, et pour lequel Apple exige normalement une justification lors de la soumission à l'App Store. On pourrait d'ailleurs reprocher à Apple un double discours, qui d'une part prétend proposer la plateforme la mieux sécurisée, et d'autre part autorise les développeurs à débrancher ces sécurités sans en avertir leurs utilisateurs.

Penser la sécurité n'est pas une pensée vaine : données utilisateurs, propriété intellectuelle, clés, secrets. on connaît la valeur des actifs à protéger. Et pour ce qui est de comment les protéger, nous ne sommes pas seuls : des livres entiers ont été écrits, des tonnes d'informations sont disponibles en ligne. La fondation OWASP propose gratuitement un guide d'évaluation de la sécurité d'une app, avec une check-list très complète en 84 points, traduite en 5 langues : qui s'y réfère ? Trop peu d'acteurs, d'après l'étude "Mobile Security Index" (Verizon, 2020) : 43% des entreprises interrogées admettent sans fard avoir "sacrifié la sécurité" dans l'année écoulée. Ce chiffre très élevé nous laisse voûté d'un grand silence.

La culture de la sécurité comme seul salut

Tout est-il perdu ? Non, mais mieux diffuser la culture de la sécurité suppose un changement drastique de mentalité. La première étape consiste à considérer la sécurité comme un atout commercial, comme le fait Apple, et d'attractivité, à l'instar de Leboncoin : pour recruter des développeurs friands de sécurité, qui ont tendance à mettre leur nez partout, ils ciblèrent ceux-ci en dissimulant dans le code source HTML de leurs pages. une offre d'emploi pointant vers leur site de recrutement ! S'inspirer des autres secteurs d'activité sera également profitable.

Imagine-t-on donner le contrôle d'un avion de ligne à qui n'a pas le permis de le piloter ? Ou commercialiser une voiture sans qu'elle ait passé un contrôle technique et des crash tests (dont l'équivalent informatique sont les tests d'intrusion) ? Non bien sûr. On voit par là que sur les questions de sécurité, les entreprises du numérique pourraient avantageusement mettre de côté leur penchant pour la disruption, et renouer avec les bonnes pratiques de leurs consoeurs plus traditionnelles.

Hervé Bérenger, Lead développeur iOS - Fabernovel.