19
Juil
10

“C’est sécurisé, si si c’est marqué là !”

Après ce long silence voilà que j’affûte de nouveau mon clavier pour vous raconter une petite histoire qui j’espère vous amènera à avoir un regard critique sur la confidentialité de vos données.

Disclaimer: ce billet n’étonnera pas les acteurs du monde de la sécurité IT dont vous faites sans doutes partie, cela dit il s’adresse plutôt à tous les gens extérieurs à ce milieu.

Disclaimer bis: toute ressemblance avec un service de partage de fichiers existant serait évidemment purement fortuite.

Lorsque je lis le mot “sécurisé” sur la description d’un service en ligne payant, je repense toujours à ce magnifique documentaire de Striptease intitulé “Elle est nickel” (partie 1 et partie 2) dans lequel des magouilleurs belges tirent profit de la naïveté de leurs clients pour leur refourguer des voitures pourries mais bien polishées. Certains disent que je suis parano, moi je préfère parler de déformation professionnelle.

Mais revenons à nos moutons car je vous ai promis une histoire !

Cette histoire met en scène une société qui souhaite échanger des fichiers volumineux avec ses partenaires ( jusque là rien d’anormal), appelons la Client, ainsi qu’une société spécialisée dans ce genre de services que nous appellerons Presta.

La société Client est positionnée sur un secteur industriel particulièrement sensible, c’est pourquoi la confidentialité de ses données est très importante. De son coté Presta affiche fièrement sur son site et en plusieurs endroits un magnifique cadenas ainsi que le mot “sécurisé” écrit en lettres d’or gage du sérieux du service proposé, on parle même de “cryptage” pour les transferts de fichiers.

De quoi rassurer Client me direz vous ? Hé bien pas totalement. Après tout, la société Client n’est pas un spécialiste de la sécurité informatique, et elle préférerait avoir un avis extérieur avant d’envoyer ses données chez Presta.

C’est ainsi que par un beau matin d’avril, la société Paintesters est mandatée par Client pour tester la sécurité de Presta (ça va vous suivez ?).

Bien sûr Presta aurait pu s’opposer à ces tests, mais Client est une société qu’elle  rêverait d’afficher dans la section “Ils nous font confiance” de son site web, c’est pourquoi Presta a décidé de jouer le jeu. Et puis l’intérêt est double car si Client accepte de lui transmettre le rapport final, Presta aura bénéficié d’un test d’intrusion à l’oeil !

Les tests commencent donc de manière anonyme sans révéler grand chose de grave, puis se poursuivent du point de vue d’un utilisateur authentifié. “Et là, c’est le drame”: une faille importante, et peu commune, est mise au jour.

Encore tout émoustillé de cette découverte, l’employé de la société PainTesters (appelons le Bobby) affute ses outils pour exploiter la faille et “pif pouf”, 3 minutes plus tard le voici avec un bel accès sur le système du serveur hébergeant la solution de Presta.

Fort content de son exploit, Bobby commence a fouiller ce nouveau monde dont il vient à peine de fouler le sol avec ses outils, ils remonte dans l’arborescence du système de fichiers et découvre ainsi le lieu de stockage des données de Client, mais quelque chose l’étonne, il y a beaucoup de fichiers, et il ne se rappelle avoir envoyé qu’une seule archive avec le compte de test qu’on lui a fourni, étrange.

Bobby, se dit alors qu’il serait bien de vérifier si ces fichiers appartiennent bien à Client, il récupère donc un fichier au hasard et colle son nez dedans.  Hélas le résultat de l’analyse tombe immédiatement: le fichier n’appartient pas à Client, il n’est pas chiffré et, cerise sur le gâteau, il contient des données très sensibles d’une autre société (les plans de l’infrastructure éléctrique d’une grosse usine)…

Notons toutefois que le chiffrement des fichiers sur le serveur n’était pas annoncé sur le site, on aurait toutefois pu espérer que de tels fichiers soient chiffrés par leurs propriétaires avant de les envoyer chez un tiers.

Mais continuons notre histoire car bien que très excité par cette découverte (oui le bonheur des pentesters fait bien souvent le malheur des développeurs) Bobby garde son sang froid et continue ses “fouilles” jusqu’à tomber sur le script d’authentification de la solution de Presta. Celui-ci est écrit en PHP, il sera donc vite lu et analysé, et force est de constater que Bobby a eu de du flair puisqu’il découvre que le mécanisme possède un mot de passe”global” qui permet se connecter avec n’importe quel compte utilisateur sans mettre à jour la date de dernière connexion (qui a dit backdoor ?). Pire encore le mot de passe est écrit en dur dans le script (la probabilité pour qu’il soit changé régulièrement est donc quasi nulle) et jackpot, le niveau de difficulté du mot de passe est digne des 20 premières entrées de n’importe quel dictionnaire que tout bon “pirate” a sous la main (j’exagère à peine).

Mais alors, ces beaux cadenas et tous ces mots techniques ne seraient qu’un argumentaire marketing pipeaulogique ? Incroyable…

Vous pensez que la société Presta est unique en son genre ?

Pourtant les solutions de stockage et d’échange de fichiers fleurissent sur Internet comme des pâquerettes au printemps et elles se targuent toutes d’offrir le service le plus sécurisé du monde mais qu’en est-il vraiment ? Difficile (voir impossible) de le savoir légalement, cela dit l’actu laisse songeur.

Dans le cas de Presta, on ne peut qu’espérer que toutes ces vulnérabilités auront été corrigées rapidement.

Je terminerai donc ce billet sur un conseil: si vous êtes clients de ce genre de solutions, quelques soient les promesses faites sur le site de l’éditeur, collez vos données dans un conteneur TrueCrypt avant de les uploader… Avec ceinture et bretelles comme on dit !

A bon entendeur !

10 Commentaires:
  1. Gordontesos 19 Juil, 2011

    Ou dans une tarball chiffrée en GPG 🙂

  2. Heat Miser 19 Juil, 2011

    Tout à fait mais comme indiqué ce billet vise les gens “normaux” (:)) je vais donc éviter d’aborder la crypto asymétrique.

  3. @paulpkk 21 Juil, 2011

    Sympa ton article. Comme tu le dis cela n’étonne pas mais un tel enchaînement d'”erreurs” de ce niveau est affligeant. Néanmoins, il ne faut pas tirer sur l’ambulance mais plutôt sur le blessé(Client).
    Pour une entreprise ayant souhaité auditer ce service avant d’y confier ses données combien l’on fait sans se poser de questions?
    Si les clients n’ont pas d’exigences sécurité pourquoi offrir un service sécurisé qui coûtera plus cher (du moins c’est ce que prétendent/croient les développeurs).

  4. Heat Miser 21 Juil, 2011

    Merci pour ton commentaire. Toutefois je ne souhaite pas du tout “tirer sur le blessé” comme dis, au contraire, force est de constater que Client a eu une très bonne idée en commandant un test d’intrusion.

    Cela dit tu as certainement raison (:sic:) quand tu dis que très peu de société ont du se poser la question de la sécurité de cette solution d’échange.

    Quand à ta dernière phrase, elle ressemble à un appel au troll 🙂 mais le point de vue que tu évoques ne semble pas prendre en compte l’impact en terme d’image et la potentielle perte financière associée !

  5. @paulpkk 21 Juil, 2011

    Je me suis certainement mal exprimé en parlant de “tirer sur le Client”. Celui de ton histoire a en effet eu la bonne démarche de faire auditer le service auquel il souhaitait confier ses données. Je voulais plutôt parler des clients en général de ce type de service qui n’ont pas d’exigences de sécurité ce qui, à mon avis, favorise le développement de tels services.
    Enfin loin de moi l’idée de troller. Je fais simplement le constat en général de l’absence de demande d’exigences de sécurité qui explique peut être en partie l’offre de service unsecure. Pour moi il ne fait aucun doute que ce type de service doit être sécurisé mais je passe beaucoup de temps à tenter de convaincre de ce point de vue.

  6. Heat Miser 21 Juil, 2011

    Ah oui effectivement, je suis d’accord avec toi.

    Maintenant, comme disait Eric Freyssinet (@ericfreyss) dans un tweet il y a peu de temps “la sécurité … il faut accepter d’investir dedans, et la plupart préfèrent se dire que ça n’arrive qu’aux autres” …

    Quand cela touche Mme Michu c’est déjà problématique, mais quand on touche a des données qui peuvent avoir un impact direct sur la sécurité publique (nucléaire, armement, …) c’est vraiment flippant et ça motive pour batailler à faire changer les mentalités.

  7. StrawberryFieldsForever 22 Juil, 2011

    Hmm. N’y a-t-il pas risque d’amalgame? je m’explique: l’histoire racontée est celle de deux entreprises et d’une troisième qui audite et les exemples cités ensuite sont surtout destinés à la Mme Michu du commentaire précédent.

    Que les services accessibles à cette dame soient moins sûrs que ceux accessibles à une boîte du CAC40 ne me choque juste pas.

    Comme je l’ai entendu sur un podcast de fanboys Apple (oui, surprenant, ces gens là sont parfois capables de bon sens), les data qui finissent sur ce genre de service doivent être “personnal but not private [or encrypted]”.

    Conclusion: oui, c’est souvent de la responsabilité de Client (quelle qu’en soit la forme), s’il “a des problèmes”.

    La problématique qui vient juste derrière est l’éthique des Presta: quand un potentiel “Client” exige que les mots de passe du produit réalisé pour lui soient “cryptés en Base64”, la boite Presta, elle fait quoi?
    La réalité est qu’elle fait souvent comme on lui demande pour des contraintes business (“si on le fait pas comme il veut même si c’est pourri, d’autres le feront à notre place et auront le deal”).

    Les Presta finissent donc souvent par mal travailler pour des raisons mauvaises du point de vue “chevalier blanc avec un clavier en guise d’épée”, mais bonnes du point de vue “faire du chiffre”.
    C’est désolant pour les puristes, mais c’est comme ça. Telle est la réalité de 2011 (c’était mieux avant… comme tout…)

    Ceux à blâmer sont encore le boîtes Client (qui pour le coup peuvent prendre toutes les formes: agences publiques, banques, supply chain…) qui restent trop laxistes sur trop de choses au point où, par exemple, le principal concurrent des protocoles métiers de transfert de fichiers est… FTP (mais tout va bien, on peut supposer que ces gens là ne sont pas des cow-boys, et qu’ils “cryptent leurs transferts en B64” :o)

  8. Heat Miser 22 Juil, 2011

    AHHH J’aime l’odeur du troll de bon matin 🙂

    “N’y a-t-il pas risque d’amalgame ?”: Précisons que la société Presta s’affiche comme étant à destination des “Mme Michu” ET des entreprises (CAC 40 ou pas), on est donc en droit d’attendre que le niveau de sécurité soit tiré vers le haut. Non ?

    Quoi qu’il en soit, les Mme Michu du web sont capables de bien pire en terme d’irresponsabilité, j’ai d’ailleurs un article dans le pipe pour illustrer ce propos.

    L’étendue de l’impact est effectivement plus faible pour le reste du monde, mais pour Mme Michu et sa famille cela peut être dramatique. Aussi, j’ose espérer que les Mme Michu d’Internet peuvent aussi prétendre à utiliser des services de bonne facture simple et “sécurisés” mais elles ont également la responsabilité de ne pas laisser traîner leurs données un peu partout.

    Le reste de ton commentaire a un petit goût de développeur “blessé” par mon article :), comprenons nous bien, le but n’est absolument pas de pointer du doigt les développeurs de la solution et de dire: “regardez comme il sont mauvais!”.

    Non, comme tu dis, les développeurs sont souvent victimes des moyens qu’on leur donne et qu’on leur impose. Dans notre cas, la solution n’est à mon avis pas personnalisable pour un client particulier, il ne s’agit pas de développement de “haute voltige” mais d’un service standardisé.

    De mon point de vue, les principaux “responsables” dans cette affaire sont les chefs de projet de Presta qui souhaitent vendre un service sécurisé sans s’en donner les moyens: formation / assistance aux développeurs (oui le développeur n’est pas forcément un spécialiste de la sécurité mais dans ces cas là il ne faut pas hésiter à les faire sensibiliser / former / accompagner), réalisation d’un audit / test d’intrusion car même si un pentest ne permet pas d’avoir la certitude d’obtenir un service 100% sécurisé des failles comme celles-ci auraient pu être évitées.

    Quand à la problématique du mot de passe “global”, à mon avis on n’est pas là sur une malveillance (volontaire ou non) d’un développeur mais plutôt, comme tu le dis, d’une “fonctionnalité” qui a du être précisée dans un cahier des charges (qui ne provient certainement pas d’un client), et encore une fois, n’y aurait-il pas fallu ici qu’une personne sensibilisée à la sécurité soit intégrée dans la boucle dès le début du projet pour illustrer les risques d’une telle “fonctionnalité” et convaincre qu’il ne s’agit pas d’une bonne idée ?

    Pour terminer, j’ajouterai que les développeurs et les pentesters / auditeurs ne doivent pas être en conflit, au contraire, un développeur doit comprendre les préoccupations d’un auditeur tout comme les auditeurs doivent comprendre celles des développeurs. Bienvenue dans le monde des bisounours 🙂

  9. Heat Miser 22 Juil, 2011

    Oublié de répondre sur la partie podcast pour laquelle je suis entièrement d’accord: “personnal but not private or encrypted” ! Mais il y a un problème, Mme Michu a des données personnelles ET privées et elle veut pouvoir les stocker en ligne sans pour autant être titulaire d’un diplôme de geekologie avancée… Essaye donc d’expliquer GPG / TrueCrypt a ta maman et essaye de lui faire utiliser au quotidien ! Hum

  10. StrawberryFieldsForever 22 Juil, 2011

    Développeur “blessé” oui, mais par mon monde plus que par ton article…
    Et les responsables sont plus les commerciaux que les chefs de projets. Le chef de projet, il voit la propal qu’a vendue le commercial et gueule en devenant tout rouge: “Quoi t’as vendu ça??? Put*in, maintenant on va être obligé de le faire!!!!!” … et l’autre montre le chiffre en bas du contrat sourire aux lèvres (quoi? ça sent le vécu? naaaaaannnnnn :D)

    Quant à l’idée d’ajouter des gars de la sécurité dans la boucle tout du long: bah oui,… mais nan! ces gens là passent pour des emmerdeurs qui font perdre du temps. Et c’est vrai! le seul truc, c’est que c’est utile.

    Les auditeurs et les developpeurs ne sont pas en conflit pour moi (même si on est d’accord que beaucoup de développeurs très imbus d’eux-mêmes pensent le contraire).
    Au contraire, si le travail d’un développeur est epinglé dans le cadre d’un audit, et si le gars en question est du genre “developpeur blessé par son monde”, alors il va sauter de joie: enfin un truc qui va menacer le contrat du méchant commercial et permettre de faire ce qui aurait dû être fait dès le début.

    Sinon sur la partie données privées/personnelles chiffrées ou non, geekologie tout ça…
    Le “personnal but not private” (le “or encrypted” était un ajout de bibi) était un constat de l’utilisabilité des services de ce type en absence de plus d’information.
    Ensuite, est-ce qu’on peut vraiment attendre plus? tu l’as dit toi-même, il est difficile de savoir ce que les services entendent pas “sécurisé”, même avec ton brevet de geekologie. Oui c’est sur que ceux qui feraient un truc vraiment chiadé s’en vanteraient, mais n’aurait-on pas au final besoin de notre brevet de geekologie pour comprendre? J’en sais rien…

    Accessoirement non, je n’expliquerai pas TrueCrypt à ma maman, mais accessoirement, sur ce genre de truc, je ne l’utilise pas moi-même, j’y ai que des trucs “personnal but not private” et ça a toujours été comme ça, avant qu’une quelconque “polémique” sorte par rapport à ce service (oui, je m’en fous assez qu’une tierce personne puisse voir :
    – mon PDF avec la liste de raccourcis clavier d’Intellij Idea 10.5 pour Mac
    – mon PDF du plan du métro parisien en HD
    – le screenshot que j’ai fait à partir de VLC de Thierry Adam, commentateur du Tour de France sur France TV qui fait une tête de deumeuré…

Commenter




Celadon theme by the Themes Boutique