Pinning SSL avec TrustKit

Le pinning SSL « maison », c’est un peu compliqué parfois.

Heureusement, l’excellente équipe de Data Theorem est là.

Ils fournissent depuis plusieurs années la solution TrustKit sur iOS, tvOS, macOS et watchOS qui permet de mettre en place le pinning SSL en 2 temps 3 mouvements.

Ils fournissent maintenant une version Android de TrustKit compatible avec les API 15+.

Pour ceux qui ne connaissent pas le fonctionnement de TrustKit, c’est franchement simple.

En gros,  il faut déterminer ce que l’on va pinner dans la chaîne de confiance, à l’instar de HPKP :

  • le certificat de l’autorité de certification (CA)
  • le certificat de l’autorité de certification intermédiaire (ies)
  • le certificat du serveur (EE, leaf)

À partir de là, on peut calculer les clés publiques actuelles. Il est fortement conseillé d’utiliser une clé de secours. Et, enfin, on peut ajouter une date d’expiration.

En gros, si les clés sont validées, ça passe. Sinon, on regarde côté clé de secours. Et, passé la date d’expiration, on ne fait plus de pinning.

Et ensuite : TrustKit fait le job. Et ça, c’est top.

Pourquoi le pinning SSL ne suffit pas toujours

Pour rappel, le pinning SSL permet de sécuriser une connexion SSL afin d’éviter les attaques MITM.

Le truc, c’est que ça ne suffit pas pour protéger son code, même si cela évite la très grande majorité des attaques.

Pourquoi ?

Autant mettre ma source, cela ira plus vite : http://fr.slideshare.net/anantshri/ssl-pinning-and-bypasses-android-and-ios

En résumé, l’idée est :

  • sur iOS, de casser la sécurité de l’app chiffrée (via jailbreak, etc) et patcher l’app de sorte à modifier le comportement du SSL pour que tous les appels soient valides
  • sur Android, c’est le même procédé, sauf que l’app n’est pas chiffrée, ce qui simplifie grandement le travail.

Que faire ?

Pour les informations sensibles (mot de passe) : les chiffrer, de sortes à avoir un niveau de protection supplémentaire.

Mais si l’app est crackée, le chiffrage ne sert pas à grand-chose.

Sinon, sur iOS, le mieux est de bloquer – si possible – l’exécution de l’app sur un système jailbreaké.

Sur Android, c’est un peu plus compliqué à sécurisé.

Éventuellement, l’alternative est d’intégrer les appels SSL directement dans son code, via OpenSSL par exemple. Avec le NDK dans Android. Mais cela peut toujours être détourné.

Globalement, le problème vient du système d’exploitation. Il faut surtout espérer qu’une solution soit trouvée de ce côté-là.

En intégrant le pinning SSL directement dans le système d’exploitation, l’ensemble serait sécurisé de manière automatique.

Le pinning SSL : comment on fait ?

Le pinning SSL permet de s’assurer, lors d’une connexion HTTPS, que celui qui utilise un certificat SSL est bien celui qu’il prétend être. Sinon, on lui coupe le sifflet !

Le pinning SSL et ses outils

Pour faire du pinning SSL, il y a diverses stratégies. Inutile de s’étendre sur le sujet. OWASP a déjà rédigé un article bien complet là-dessus.

Même plusieurs articles.

Mais comment ils font les autres ?

C’est bien le coeur du problème. Connaître la technique est une chose. Savoir mettre en place la technique en est une autre.

Le pinning de clé publique, c’est assez cool, mais c’est un peu trickie comme approche et parfois complexe.

Le plus simple est certainement le pinning du certificat en lui-même.

Ha oui, mais si le certificat change ?

Une faille comme Heartbleed peut en effet forcer à révoquer les certificats.

Qui dit certificat changé dit pinning cassé.

Donc autant ne pas faire de pinning SSL ?

Chiffrer les données au-delà du HTTPS

L’avantage des technologies modernes, c’est qu’on peut chiffrer certaines données. Sans nécessairement passer par HTTPS.

Par exemple, on peut imaginer un serveur utilisé uniquement en cas d’incident. Par exemple, quand la clé enregistrée dans l’app ne fonctionne plus et qu’il faut en enregistrer une autre.

On effectue alors une requête précise sans pinning sur le service web. Avec un système de jeton unique qui ne peut être généré quand connaissant un algorithme particulier. Ce jeton inclue une clé valable temporairement partagée entre le client et le serveur. Cette clé permet d’obtenir une autre clé qui servira à chiffrer l’information avec encore une autre clé, également partagée entre client et serveur et d’une durée temporaire.

Le client reçoit l’information. La déchiffre avec la clé aléatoire qu’il a généré + la clé partagée. Là, il a la nouvelle empreinte permettant d’effectuer le pinning sur le nouveau certificat.

La clé partagée entre le client et le serveur sera chiffrée sur iOS. Aucun soucis.

Sur Android, la mauvaise idée est de la mettre dans les préférences. Ou de la mettre en dur dans le code. Heureusement, il y a le NDK qui permet de compiler des informations. Evidemment, ce code peut-être décompilé. Mais on peut aussi obfusquer le code du NDK. Et là, c’est moins cool à décompiler et comprendre. Surtout s’il y a en plus du fake code avec une bonne obfuscation du code Java en lui-même.

Bref. En attendant la mise à jour de l’app, c’est une solution de secours qui évite l’interruption de service.

Ça peut aussi être utile pour les identifiants d’accès aux services web externes (Facebook, Google, Cloudinary, etc).

Ha ouais, c’est cool

Bah ouais. Maintenant, faut s’y mettre. Avec un peu de bonne volonté, tout est possible.

 

Les apps de banques non sécurisées (ultimatum allégé inside)

Si j’ai choisi une image un peu kitch, c’est pour essayer d’attirer le regard insouciant de nos établissements bancaires. Oui oui : ceux pour qui la sécurité est le mot d’ordre.

Je ne vais pas rentrer dans les détails. Histoire de ne pas donner de mauvaises idées. Du moins, pas pour le moment.

Tout ce que je peux dire, c’est qu’en quelques minutes (secondes), j’ai réussi à duper mon propre smartphone et voir paraître sous mes yeux le mot de passe de mon app bancaire et toutes les informations associées. Ainsi que toutes les informations consultées (relevés de banque, etc). Bref. Niveau débutant.

Sachant qu’en quelques heures on peut pirater un réseau WiFi, surtout s’il est public : autant dire que les informations de tous les clients sont à la merci des hackers.

Je ne dévoilerai pas aujourd’hui la technique employée ni la solution, tellement le tout est simpliste. Je vais attendre une semaine (14 février, jour de la Saint Valentin) attendre la fin du 1er semestre 2017 (suite à demande de délai, voir si dessous) avant de diffuser la technique et la solution.

Ça fait des mois que j’essaye de signaler ces problèmes de sécurité (qui touchent aussi les assurances soit dit en passant) : et tout le monde assume pleinement cette légèreté alors que les clients donnent leur confiance.

Si les établissements concernés souhaitent en savoir plus, qu’ils me contactent. En espérant que ma banque soit juste une exception.

Je ne souhaite pas faire de chantage ou quoi que ce soit. Je trouve juste anormal que la sécurité – même basique – sur des sujets aussi sensibles soit laissée de côté.

Rendez-vous dans une semaine. 🙂

[ Première mise à jour du 8 février 8h46 (ça commence..) ]

Non, je ne veux pas faire chanter les banques. Je m’en fous comme de l’an 40. J’ai un boulot honnête qui me suffit.

Mon seul intérêt est citoyen : les informations privées concernant mes contemporains et moi-même doivent être protégées. Et je ferai le nécessaire pour ça.

C’est pas compliqué : un email (formulaire de contact), une validation que vous êtes bien un responsable sérieux de l’établissement (et pas le stagiaire qui veut faire une blague), et je vous envoie les infos. C’est corrigé (en moins de 24h chez Apple pour une MAJ urgente) et on n’en parle plus. L’article sera obsolète à sa sortie et tout le monde sera content.

Et non, je ne fournirai aucune information, même contre de l’argent ou quelque rétribution que ce soit, afin de permettre l’accès aux informations sensibles de qui que ce soit. Le piratage, c’est pas bien. Si vous voulez dégommer vos concurrents, soyez meilleurs qu’eux, c’est tout. Et voler de l’argent via un détournement de smartphone, ce n’est pas bien non plus. Et voler l’identité de quelqu’un, c’est pas très beau.

Ce sont les premières clarifications. Pour l’instant, aucun établissement ne m’a contacté et j’ai peu d’espoir.

Même si, par le passé, j’ai déjà contacté un établissement pour des problèmes de sécurité. Qui m’a reçu, poliment. Considère que les informations contenues dans les apps ne sont pas très sensibles. Mais au moins est au courant de ses faiblesses et connait les solutions. Après, je ne porte pas de jugement. J’éviterai juste d’être client. (et non, vous ne saurez pas qui c’est car cela pourrait nuire à l’image de l’établissement)

Et il y a aussi eu beaucoup d’emails, contacts Twitter et Facebook pour savoir quelles informations pouvaient être accessibles de la part de particuliers inquiets. Ils ne sont pas plus rassurés, mais sont au moins informés.

Encore une fois, on ne peut pas jeter la pierre aux banques. La sécurité, ce n’est pas leur métier. C’est la faute des prestataires ou qui sais-je. Cela n’a pas vraiment d’importance à leurs yeux. Et ils ne peuvent pas savoir qu’un simple échantillon de données est une brèche de sécurité dans un système plus global. Mais bon, ça les concerne quand même un peu.

Donc je fais le job et les informe : vu qu’en privé, je ne réussis pas à les contacter (malgré des mois de tentatives), je suis obligé de prendre un canal de communication plus élargi. C’est juste un problème de communication interne, on ne peut pas leur en vouloir.

Merci d’avance pour la sécurité de nos informations personnelles.

[ Mise à jour 2 : 08/02 14h24 ]

Ça avance : une première banque m’a contacté. J’ai retrouvé la foi.

[ Mise à jour 3 : 09/02 17h17 ]

J’ai été contacté par un établissement qui s’engage à faire le nécessaire dans le 1er semestre 2017. Pas avant parce que c’est compliqué. Plus compliqué qu’il n’y parait.

Sauf qu’à un moment ça va poser problème. M’enfin. C’est comme ça.

Rendez-vous le 30 juin 2017. (ou avant, en cas de miracle)

[ Mise à jour 4 : 10/02 18h53 ]

Un autre établissement est rentré en contact avec moi. C’est formidable. 🙂

[ Mise à jour 5 : 14/02 17h46 ]

Le second établissement a échangé avec moi. Même discours : ils sont déjà au courant, mais c’est long à mettre en place.

De manière générale, le risque de perdre quelques utilisateurs est mis en face du risque côté sécurité. Une problématique assez complexe. Vite réglée quand il y a un incident.

En tout cas, la mise en place d’une sécurité renforcée est le choix pour le premier trimestre 2017 pour cet établissement. Quitte à laisser quelques utilisateurs non précautionneux sur le bord de la route (en redirigeant vers la version web malgré tout). Un choix courageux et intelligent.

Votre carte bancaire hackée en 6 secondes

Une pratique scandaleuse des établissements bancaires : nous obliger à posséder une carte bancaire avec le fameux sans contact.

Le sans contact par CB « sécurisé » ?

On vous dira : de toutes manières, le risque est limité.

Sur le papier, en effet :

  • il faut être à quelques centimètres de la carte pour lire les infos
  • « seuls » le numéro de CB et la date d’expiration sont transmis
  • aucun code n’est transmis
  • le code à 3 chiffres au dos de la carte n’est pas transmis
  • on peut seulement débiter 20 € par transaction.

Sur le papier, c’est sécurisé. Sur le papier.

Sécurité sur le papier = sécurité en carton

Reprenons ces arguments.

il faut être à quelques centimètres de la carte pour lire les infos

Dans le métro, avec un simple smartphone, on peut récupérer ces infos.

Il existe même des boîtiers permettant une lecture à distance de ces informations.

« seuls » le numéro de CB et la date d’expiration sont transmis

Ces 2 informations (sur 3) sont transmises. Sans soucis.

 

aucun code n’est transmis

Il n’est pas utile.

 

le code à 3 chiffres au dos de la carte n’est pas transmis

C’est la seule inconnue.

 

on peut seulement débiter 20 € par transaction.

Pas sur le web si on a ce fameux code à 3 chiffres.

Trouver le code à 3 chiffres

Si les CB MasterCard sont limitées à 100 essais (ce qui laisse une chance de trouver le code), les CB Visa n’ont pas cette limite.

A partir de là, des petits programmes peuvent automatiquement tester la carte sur plusieurs sites.

En voici la preuve. En 6 secondes.

Le « sans contact » n’est donc pas fiable ?

Le sans contact peut être fiable si vous passez par une solution mobile comme Apple Pay, Android Pay, Samsung Pay, Microsoft Wallet, Boon ou bien encore Orange Cash.

Dans ces cas-là, votre mobile va transmettre au terminal de paiement un code valable pour une durée définie, pour un commerçant et un montant défini, valable une seule fois.

Autant dire, le risque est quasiment nul. Du moins face aux menaces actuelles.

Quel avenir pour la carte bancaire ?

Face au sans contact mobile, la carte bancaire semble vivre ses dernières années.

D’autant que les solutions mobiles permettent maintenant – progressivement – de payer en ligne sur Internet. Ce qui est encore plus fiable que la CB.

La CB montre chaque jour ses limites tandis que les solutions mobiles se développent.

Peut-être est-il temps de passer le relais ?

Mise à jour de sécurité importante des iPhone et iPad

Comme tous les systèmes d’exploitation, iOS contient des failles de sécurité. Et certains sont particulièrement acharnés pour les trouver. C’est le cas de la dernière en date, corrigée grâce à la mise à jour 9.3.5.

L’origine de la faille

Cette faille (ces failles en réalité) n’a pas été trouvée par un hacker quelconque dans sa chambre d’étudiant.

Elle a été trouvée par l’organisation israélienne NSO Group qui a pour spécialité la cyber-guerre. En gros, des entreprises et des gouvernements ont investi – probablement des millions de dollars – pour trouver la faille permettant d’espionner journalistes et activistes.

C’est d’ailleurs Ahmed Mansoor, un défenseur des droits de l’homme, qui en a été la victime et qui a permis de détecter et combler cette faille.

Le pauvre homme a reçu le 10 août un SMS avec un lien suspect. Au lieu de cliquer sur le lien, il a contacté l’organisation Citizen Lab (défense des droits numériques) qui a demandé à la société Lookout (sécurité mobile) d’analyser la chose.

C’est là qu’ils ont découvert le spyware (logiciel d’espionnage) Pegasus, vendu aux gouvernements et aux entreprises prêt(e)s à payer le prix fort pour espionner leurs cibles.

Pegasus

Pegasus est un outil reposant en réalité sur 3 failles :

  1. CVE-2016-4655 : une faille permettant de calculer la position du noyau (le coeur du système) en mémoire
  2. CVE-2016-4656 : une faille permettant – à partir de l’accès au noyau – de jailbreaker (faire sauter les verrous du système) l’iPhone sans que l’utilisateur ne s’en rende compte
  3. CVE-2016-4657 : une faille permettant d’accéder à un espace mémoire spécifique depuis Safari

En gros, les hackers procèdent ainsi :

  1. Un lien est envoyé
  2. L’utilisateur ciblé clique sur le lien
  3. Le lien s’ouvre dans Safari
  4. La page de destination contient un code permettant d’accéder à la mémoire (via la faille CVE-2016-4657)
  5. L’espace mémoire ciblé (le noyau) est calculé grâce à la faille CVE-2016-4655
  6. La sécurité du noyau saute grâce à la faille CVE-2016-4655
  7. Des données sont écrites dans cet espace mémoire de sorte à faire sauter les sécurités du système
  8. Une fois le système déverrouillé, le logiciel espion est installé sans que l’utilisateur ne s’en soit rendu compte
  9. Les données transitent à volonté, car tout le système est ouvert.

Bref : Pegasus n’est pas cool.

iOS n’est donc pas sécurisé ?

Cette attaque démontre le contraire.

Il n’a pas fallu une mais trois failles de sécurité pour pouvoir installer un logiciel malveillant.

Si l’une des trois failles n’avait pas été trouvée, le système n’aurait pas pu être attaqué.

Également, Apple a été informée de la faille le 10 août. iOS a été corrigé en 15 jours. Et la mise à jour a été diffusée dans la foulée, sur tous les appareils concernés.

Pour une prochaine attaque (et il y en aura forcément une), il faudra encore trouver plusieurs failles.

Sachant qu’en parallèle iOS 10 va sortir dans les prochaines semaines avec de nouveaux mécanismes de sécurité :

  • par défaut, pas de support du SSL non sécurisé (oui, c’est paradoxale, mais véridique)
  • nouvelles options pour sécuriser le contenu web au sein des apps
  • l’intégration du support de Certificate Transparency au sein des apps (complément au SSL)
  • etc

Globalement, c’est une course contre la montre. Mais Apple s’en sort très très bien, même si on voit aujourd’hui qu’il ne faut pas relâcher l’effort.

Que puis-je faire pour garantir ma sécurité ?

Les règles sont simples :

  • protéger ses comptes (email, Apple, Facebook, Twitter, etc) avec un maximum de sécurité
  • protéger l’accès à son iPhone
  • mettre à jour l’iPhone régulièrement
  • utiliser des outils comme Lookout afin de s’assurer que tout va bien.

En suivant ces quelques règles de base, on s’en sort plutôt bien et ça ne prend pas spécialement de temps en plus au quotidien.

On ne le dira jamais assez : protégez-vous !

Let’s Encrypt + Heroku :-)

Depuis peu, Heroku intègre gratuitement en beta le SSL via SNI.

Let’s Encrypt permet d’obtenir des certificats SSL gratuits.

Comment faire fonctionner l’ensemble avec Ruby on Rails ? C’est l’objet de cet article, fortement inspiré d’un article de Collective Idea.

Après ça, vous n’aurez plus d’excuses pour ne plus sécuriser vos sites !

D’abord, installer Let’s Encrypt

Vous êtes sur Mac et avez installé Homebrew ? C’est facile. Une simple ligne de commande suffit.

brew install letsencrypt

Pour les autres, rendez-vous sur le site officiel.

Premières étapes

Lancez l’invite de commande et suivez doucement les instructions.

sudo letsencrypt certonly --manual

On vous demande ensuite le nom de domaine.

Puis si vous êtes d’accord pour enregistrer votre IP : acceptez.

Ensuite, l’écran passe au noir avec un message de type :


Make sure your web server displays the following content at [...]

Là, stoppez !

On passe à la partie Ruby on Rails.

La partie Ruby on Rails

D’abord, mettez à jour config/routes.rb.


Rails.application.routes.draw do
# ...

# Let’s encrypt
get ‘/.well-known/acme-challenge/:id’ => ‘pages#letsencrypt’

# …

end

 

Le contrôleur s’appelle ici PagesController mais peut être n’importe quel contrôleur de pages statiques.
class PagesController < ApplicationController
def letsencrypt
# utilisez ici le code fourni par Let's Encrypt
render text: "code-fourni-par-lets-encrypt"
end
end

C’est fini pour la partie Ruby on Rails.

On continue via Let’s Encrypt

D’abord, on vérifie l’adresse http://<mon-domaine>/.well-known/acme-challenge/<id&gt; histoire de s’assurer que ça retourne bien le texte en code.

Là, c’est compliqué. On presse Enter.

Vous voyez le message Congratulations! ? C’est gagné !

Mais on ne s’arrête pas là.

Installation sur Heroku

Simple commande :
sudo heroku _certs:add /etc/letsencrypt/live/<domaine>/fullchain.pem /etc/letsencrypt/live/<domaine>/privkey.pem --app <mon-app>

Et voilà.

Pensez ensuite à mettre à jour vos DNS. Attendez quelques instants. Normalement, tout devrait être sécurisé.

[ Edit ]

Un outil permet de faciliter tout ça. Venez le découvrir sur GitHub. (merci @dmathieu)

Astuce Android : récupérer son code source depuis Google Play

Attention : Utilisez cette technique uniquement avec vos propres applications. Prendre le code des autres, ce n’est pas bien.

Cas de figure

Vous êtes étourdi et avez égaré le code source de votre application Android : la mise à jour de votre application va être un travail long et fastidieux.

Heureusement, vos étourderies vous ont fait oublier de protéger le code source de votre application.

Google a pensé à tout : par défaut, le code généré n’est pas protégé. Et, si vous souhaitez réellement le protéger, il faut mettre la main à la poche et acheter les outils adéquats.

En 2 minutes de travail, et quelques heures de patience, vous allez pouvoir récupérer la majeure partie de votre travail.

On récupère d’abord le fichier APK

Récupérez d’abord le fichier APK de votre application.

Si la procédure vous semble compliquée, utiliser le site APK PURE qui vous permet de récupérer un APK sans avoir à vous identifier. (cette astuce est également valable pour gonfler artificiellement le nombre de vos téléchargements, ce qui fera plaisir à Google également)

Un fichier APK, c’est chouette. Mais on n’a pas le code source. C’est tout caché dedans.

Heureusement, il y a une app pour ça !

Dare dare

Un chouette outil, appelé Dare, permet d’analyser la sécurité de vos apps.

Et donc récupérer le code source ! (c’est une faille de sécurité normalement, mais – comme je l’ai entendu récemment – ça ne sert à rien de protéger un code source)

On télécharge l’outil ici : http://siis.cse.psu.edu/dare/

Encore une fois, n’utilisez pas cet outil pour récupérer le code source des applications dont vous n’êtes pas auteur. Ce n’est pas sympa. De toutes manières, vous en feriez quoi d’un code source ?

L’outil réside en une archive zip qui contient un exécutable.

Il suffit alors d’une ligne de commande :

./dare -c -e -p -b -d <output> <apk-file>

Et le tour est joué !

Vous vous rendez dans le répertoire cible et vous récupérez votre code source Java.

Google a pensé à tous les développeurs, y compris les plus étourdis !

Les apps Android : merci, au revoir

Après 3 ans de développement Android, il me semble bon d’en arrêter là.

Morin Innovation ne concevra plus aucune autre application Android que celle où elle est engagée (que mes clients actuels se rassurent, le job sera fait).

Les raisons de cette décision

Cette décision n’a pas été prise à la légère. Elle est le fruit de plusieurs mois de réflexion.

Un niveau qualitatif insuffisant

Bien que le travail des ingénieurs Google soit tout à fait honorable, la plateforme Android ne répond pas à autant de critère de qualité que ses concurrents.

La conséquence immédiate de cette légèreté : les utilisateurs sont moins bien servis, et les clients sont déçus lorsqu’ils comparent avec les autres plateformes.

Malgré une tentative louable, Android n’atteint absolument pas le niveau requis. A quelque niveau que ce soit.

Les outils ne sont pas terribles : on a toujours l’impression d’avoir une version « beta », ce qui nuit à la productivité.

Le kit de développement est correct dans le sens où il est complet. Pour le reste, c’est basique, mais acceptable.

L’ergonomie est très moyenne.

D’autant qu’il faut composer avec les anciennes versions Android, ce qui ne garantit pas une cohérence optimale. Ça fait des lustres qu’on nous promet des améliorations : rien ne vient. On doit être compatible avec des OS datant de 2012 (4 ans!). Autant dire, une éternité dans le monde mobile.

Bref : la qualité est moyenne et en plus ça prend plus de temps, donc ça coûte plus cher pour tout le monde.

La cerise sur le gâteau : la sécurité

Après une étude approfondie d’un problème qui est d’actualité, il s’avère que la sécurité Android est au niveau minimum. Même sur les versions récentes du système (et celles en développement aussi d’ailleurs).

Je ne souhaite pas que les informations concernant les utilisateurs de mes apps soient divulguées ou du moins facilement accessible. Je me suis fait entendre dire plus d’une fois : « Oui, mais on s’en fout de la sécurité des données des utilisateurs. Qui s’en préoccupe ? ». C’est pour moi un manque de respect. On se doit d’offrir le meilleur.

Je souhaite également éviter la propagation des informations sensibles concernant les développements réalisés pour mes clients. Je protège tous mes appareils (chiffrage de disque, etc) et les codes sources que je partage avec mes clients sont stockés sur des plateformes sécurisées, dont l’accès nécessite une sécurité à facteurs multiples (envoi d’un code par SMS pour accéder aux données protégées, certificats SSL pour accéder au code source, identification par signature GPG des développeurs, etc).

De la même manière, je fais en sorte de ne stocker aucun identifiant dans mes codes sources, de sorte à ne pas donner le moindre indice à un potentiel hacker.

Et je met également en application, dans la mesure du possible, l’intégralité des recommandations OWASP disponibles.

Ceci est possible sur iOS, au sein de Ruby on Rails, mais pas vraiment sur Android dont la plateforme ne correspond plus aux critères de sécurité actuels. Pour ceux qui en doutent, je rappelle à leur bon souvenir le temps qu’il a fallu au FBI pour accéder à un appareil Apple moyennement protégé alors que la sécurité Android saute en quelques heures tout au plus.

De plus, en quelques heures (2 minutes devant l’ordi qui va fonctionner tout seul pendant quelques heures), on peut récupérer une version du code source allant de lisible à difficilement compréhensible. Mais il est extrêmement compliqué et coûteux de réellement bien protégé une app Android. A contrario, une app iOS ou Windows est sécurisée par défaut. Le code source n’est pas accessible. Et, de surcroit, il est possible de ne pas y intégrer d’informations sensibles.

À l’instar de la qualité d’usage, qui est peut être subjective, la qualité en matière de sécurité est un critère on ne peut plus factuel. Et cette réalité va en grandissant au fur et à mesure que le temps passe.

Je ne prendrai pas cette responsabilité.

Les alternatives

Les alternatives pour les clients et les utilisateurs sont les suivantes.

Pour les clients

Honnêtement, il y a beaucoup de faux dans les téléchargements et exécutions d’apps Android. J’ai moi-même vu des statistiques Analytics avec des applications étant téléchargées et non lancées. Ou des applications étant lancées une fraction de seconde. Ce n’est pas un comportement d’utilisateur « normal » et encore moins un comportement « rentable ».

Autant disposer d’applications natives de très bonne qualité et un très bon compromis pour la version web. Le HTML5 fait aujourd’hui de très bonnes choses dans un cadre relativement sécurisé. Certes, cela ne permet pas forcément de disposer de toutes les possibilités du natif, mais cela reste mieux qu’une app de qualité moyenne.

Si vous souhaitez vraiment avoir une app Android, je vous recommande donc de consulter un développeur Android avec un niveau senior et de très solides compétences dans le domaine de la sécurité. Pour vous et pour vos utilisateurs.

Pour les utilisateurs

Vous avez un Android et entendez des promesses d’amélioration depuis des années ? C’est normal : la publicité et le marketing, c’est le domaine de Google.

Quand vous téléchargez une app, assurez-vous qu’elle est très bien protégée (Comment ? Je l’ignore) et utilisez l’authentification à multiples facteurs quand c’est possible.

Sinon, si vous avez un budget à partir de 500 € en appareil nu (sans abonnement), l’iPhone SE est une petite bombe. Vous pouvez avoir des iPhone chez Free Mobile pour moins de 20 € par mois. Et chez Orange, avec un abonnement, on peut avoir un iPhone à partir de 1 €. Un iPhone SE sera au top pendant environ 3-4 ans.

Les Windows Phone récents (surtout Windows 10) tiennent bien la route aussi en matière de sécurité.

Si vous êtes sur Android, de manière générale, préférez les applications web aux applications natives : elles ont plus de chances d’être sécurisées.

Et l’avenir ?

L’avenir s’annonce radieux. 🙂

Morin Innovation va se focaliser sur un développement web (sites + services web) de bonne qualité grâce à Ruby on Rails.

Le tout fonctionnant en parfaite harmonie avec des applications Apple (iOS, tvOS, watchOS, macOS OS X) répondant aux mêmes critères de qualité et de sécurité.

Je continuerai de faire de la veille sur Android, notamment pour assurer un niveau de sécurité adéquat vis à vis des services web que je mettrai en place. Mais c’est tout.

L’expérience Android se termine ici.

Merci Google et au revoir.

Vous souhaitez savoir qui connait vos mots de passe ?

Le titre est un peu racoleur, mais il fait suite à une expérience menée récemment par Morin Innovation.

Selon l’appareil et le réseau que vous utilisez, des informations sensibles vous concernant (mot de passe, coordonnées bancaires, coordonnées sécurité sociale, etc) peuvent être interceptées de manière manuelle ou automatique.

La démarche précise ne va pas être évoqué ici : inutile de donner aux hackers en herbe les techniques de piratage qu’ils pourraient eux-même utiliser.

Première faille : ne pas mettre à jour

Vous utilisez Windows XP « parce que c’était mieux avant » ? Sachez que Windows XP ne reçoit plus de mises à jour. Les nouvelles failles trouvées ne sont donc plus corrigées. C’est un terrain de jeu idéal pour récupérer vos informations personnelles.

Il en va de même pour les anciennes versions de OS X, le système du Mac, dont la mise à jour est gratuite.

Et c’est également la même chose sur les smartphones.

Bien choisir son smartphone

Les smartphones de plus de 4 ans représentant environ 5 % des utilisateurs, et tous les 2 ans en moyenne.

Si votre iPhone a plus de 5 ans, il ne reçoit plus les mises à jour du système iOS. Les iPhone 4S et plus récent ont toujours droit à leur mise à jour. Et sont donc protégés au maximum possible.

Si vous vous orientez vers Android, vous avez le choix entre plusieurs milliers d’appareils. Choisissez plutôt du haut de gamme. Le Galaxy S2 peut être mis à jour avec la dernière version d’Android en passant par l’outil CyanogenMod (si vous êtes un peu geek, vous devriez vous en sortir sans soucis). Les modèles de moyenne gamme ont des mises à jour pendant environ 1 à 2 ans. Les modèles d’entrée de gamme sont bien souvent déjà obsolètes à la sortie.

Pour ce qui est de Windows Phone, environ 80 % des appareils reçoivent des mises à jour récentes, dont la dernière version Windows 10. Les versions Windows 8.1 reçoivent malgré tout des mises à jour de sécurité. Ce qui est plutôt intéressant.

L’étude de la sécurité s’est limitée aux mises à jour concernant Windows Phone tant la part de marché reste – encore – mince.

Le navigateur web

Utilisateurs d’Internet Explorer : toutes les versions inférieures à la version 11 sont obsolètes.

Les autres navigateurs sont mis à jour automatiquement et de manière régulière.

« HTTPS » ne signifie pas toujours « sécurité absolue »

Quand vous vous connectez sur un site en HTTPS, la connexion est sécurisée. Les données qui transitent entre votre ordinateur / smartphone et le site ne sont pas visibles.

Une personne (ou un robot) malintentionnée qui « observerait » la connexion ne verrait passer que des chiffres et lettres sans aucune cohérence.

On distingue les connexion HTTPS par un petit cadenas dans l’adresse du site (la barre en haut), souvent en vert, à gauche ou à droite de l’adresse.

HTTPS

Cependant, les certificats sont parfois obsolètes. En conséquence de quoi un pirate peut interférer entre vous et le site web. En gros, il se fera passer pour le site web vis à vis de vous. Et il se fera passer pour vous vis à vis du site web. Ainsi, il pourra récupérer les informations déchiffrées.

Les techniques modernes et les navigateurs modernes permettent justement d’éviter ça.

Dans Chrome, vous pouvez distinguer un site véritablement sécurisé :

Morin_Innovation

Et un site à la sécurité douteuse :

RSI_–_Authentification_et_Developer_Tools_-_http___localhost_8080_rwd_maiffr_dist_www_transverse_services_simulateur_html

Attention : de nombreuses banques et autres organismes « de confiance » utilisent des procédés obsolètes en matière de sécurité.

Comment aller sur Internet en toute sécurité ?

Il y a 2-3 règles simples pour être en sécurité sur Internet.

Disposer d’un appareil à jour

En allumant votre PC / Mac / Smartphone / What else vérifiez vos mises à jour.

C’est un premier niveau de protection.

Utiliser votre propre ordinateur et votre propre réseau

Les ordinateurs des lieux publics sont des cibles faciles pour les pirates. Ils peuvent souvent se mettre en intermédiaire : l’accès aux connecteurs réseaux n’est pas forcément sécurisé, ce qui permet d’intercepter les communications si on maîtrise la chose.

Et les ordinateurs des lieux publics sont rarement à jour.

Connectez-vous soit chez vous, soit chez un proche. Eventuellement sur une box de votre fournisseur d’accès ou un procédé similaire reconnu.

A défaut, utilisez votre connexion 3G/4G.

Les applications mobiles (ça fait mal…)

L’étude de la sécurité qui a été faite a été réalisée sur des applications mobiles iOS et Android.

La responsabilité de la sécurité dépend à la fois du système d’exploitation et du concepteur de l’application.

La faille courante sur mobile

La faille la plus courante sur mobile n’est pas d’essayer de casser la sécurité de la connexion à un service, mais de baisser le niveau de sécurité pour le rendre obsolète et ainsi récupérer les informations.

En gros, en utilisant un appareil Android « rooté » (ou non mis à jour) ou un iPhone « jailbreaké », on peut faire croire au site web que nous n’avons pas la capacité de mettre en place le niveau de sécurité maximum. On demande donc à communiquer au travers d’une connexion sécurisée obsolète.

Et là, le pirate peut se mettre entre les deux.

IOS : sécurisé par défaut

Les applications iOS sont sécurisées par défaut. Elles sont compilées, chiffrées et le système bloque beaucoup d’accès de sorte à protéger vos données.

Si vous êtes encore sur iOS 8 (il en reste quelques uns), passez rapidement à iOS 9. La dernière mise à jour permet de forcer la sécurité des connexions des applications mobiles grâce à une technologie appelée ATS. Cependant, certains développeurs désactive cette fonctionnalité par paresse de la mise à jour.

Pour le reste, on peut réaliser des applications ne contenant aucun identifiant dans le code (pour se connecter au serveur) et donc totalement sécurisées.

On peut éventuellement renforcer la sécurité avec des techniques complémentaires, au cas où iOS aurait une faille non connue permettant de casser les mécanismes de sécurité en place. Mais, si c’était le cas, le FBI n’aurait pas fait de procès à Apple pour accéder aux informations d’un iPhone.

Sauf si vous ne mettez pas à jour votre iPhone, et si le développeur ne se donne pas la peine de respecter les règles de sécurité par défaut ou n’utilise pas les outils à disposition, votre iPhone est globalement très bien sécurisé.

Ce qui est normal : après tout, vous payez le prix fort – entre autre – pour que vos données soient en sécurité.

Android : sic!

Avant d’être accusé de quoi que ce soit, je tiens à préciser que j’ai lancé plusieurs appels sur la toile ces derniers jours et ils sont restés sans réponse. Si vous avez des réponses à me donner, n’hésitez pas, je complèterai l’article.

J’ai testé plusieurs applications Android, dont celles d’organisations qui devraient protéger la sécurité de leurs utilisateurs. Je ne les citerai pas, par bienveillance et parce que l’erreur est humaine. Et, de toutes manières, il est très difficile de faire mieux que pas terrible avec Android. Je vais expliquer précisément pourquoi.

En premier lieu, j’ai pu découvrir le code source de toutes les applications téléchargées. Et donc récupérer les identifiants de connexion au service web permettant de gérer les données.

J’ai même eu accès à un service d’envoi automatique de SMS. Bref, ça craint. Imaginez que je sois un pervers un peu taré et que j’utilise ce service pour envoyer des SMS salaces : qui se ferait accuser ?

En plus, une faille Android anéantit la sécurité mise en place sur les autres appareils.

Certaines techniques permettent de « masquer » le code source, dont l’obfuscation, qui consiste à complexifier artificiellement le code. Sur une dizaine d’apps, une seule était réellement compliquée à lire. Pour les autres, on s’y retrouvait tout de même facilement. Donc, ça craint. Y compris pour le développeur qui n’y peut rien.

On pourrait utiliser, comme avec iOS, des services Google qui permettraient de récupérer les identifiants sensibles via une connexion établie par l’application et exploitable uniquement par l’application. Ça n’existe pas. Et, même si ça arrivait dans la prochaine version, ce ne serait pas compatible avec la majorité des appareils Android avant plusieurs années.

Bref : on est condamné à laisser en clair les informations.

Si toutefois on utilise une bonne technique pour bien cacher les identifiants de connexion au service web, il n’y a malheureusement aucune technique permettant de forcer la protection de la connexion (aucun équivalent à ATS) : en conséquence, on doit utiliser des techniques particulières pour s’assurer qu’il n’y a personne entre notre serveur et notre application.

J’en ai déjà perdu la plupart d’entre vous : c’est normal, ce domaine qu’est la sécurité est très spécifique.

Pour les développeurs, c’est pareil : la plupart ne connaisse pas tellement la sécurité. Vu que le système n’est pas suffisamment sécurisé par défaut, l’application n’est pas sécurisée. Et, encore une fois, inutile de leur jeter la pierre : la sécurité est un domaine très spécifique et doit avant tout être géré par le système en lui-même.

Je ne dis pas qu’Android n’est pas sécurisé : il y a tout pour bien faire. C’est juste que dans plus de 90 % des cas ce n’est pas sécurisé. Et, malheureusement, on ne peut pas y faire grand-chose.

Faut-il responsabiliser l’utilisateur ? Faut-il responsabiliser le développeur d’application ? Faut-il responsabiliser les concepteurs d’Android ?

Ça ne vous a pas coûté cher : vous savez maintenant pourquoi.

Si un jour votre compte est débité ou votre identité falsifiée, vous saurez que vous n’avez pas eu de chance à la roulette russe. Mais vous saurez surtout d’où peut venir le problème.

« C’est malin, j’ai les boules : t’as pas une solution quand même ? »

Hormis mettre votre Android à la poubelle et acheter un Windows Phone ou un iPhone, vous pouvez tout de même protéger un peu plus vos informations personnelles en évitant que vos données soient volées par n’importe qui.

Cette solution est très utile et doit être appliquée quelle que soit votre smartphone ou ordinateur.

Vous savez maintenant qu’un mot de passe de connexion n’est absolument pas une sécurité : n’importe quel pingouin mal luné peut le récupérer en allant voir 3 tutoriels sur le piratage.

Pour autant, il existe une solution : l’identification à plusieurs facteurs.

Le premier facteur est le mot de passe, totalement « has been » aussi compliqué soit-il.

Le second facteur est l’envoi d’un SMS ou l’envoi d’un code dans une application spécifique.

Et là, c’est malin. Car, pour pouvoir accéder à votre compte, le petit malin devra posséder à la fois votre mot de passe (facile) ET votre téléphone sur lequel sera envoyé un SMS ou un code dans une app. Et, si votre smartphone est bien protégé (mot de passe ou mieux : TouchID), le petit malin pourra aller se brosser.

Si vous souhaitez en savoir plus, j’ai rédigé un petit article à ce sujet.

Le plus triste est que – malheureusement – les banques, assurances et autres établissements ayant à leur disposition des informations sensibles vous concernant utilisent rarement ce système d’identification. (par contre, Google, Facebook, Apple, Microsoft et autres le proposent)

Sur ce, dormez tranquilles… On vous surveille ! (rire sardonique)

Je rigole. 🙂 Mais faites attention quand même.