#MITM de #Google par l’ #ANSSI : la théorie du doigt qui pointait la Lune

Ce week-end, sur son blog dédié à la sécurité, Google a publié une note qui n’a pas manqué d’attirer l’attention de toute la communauté de la sécurité informatique hexagonale. Dans son billet, Google explique qu’un
Abonnez-vous ou connectez-vous pour lire le reste de cet article
Twitter Facebook Google Plus email

35 thoughts on “#MITM de #Google par l’ #ANSSI : la théorie du doigt qui pointait la Lune”

  1. Il y a des erreurs dans l’article, la DGTresor a des SERVICES économiques, Ubifrance a les MISSIONS économiques, les deux sont fortement séparés depuis maintenant quelques années, en particuliers pour l’informatique. Il y a encore parfois des bureaux communs cependant, mais les réseaux sont quasiment étanches.

      1. Je dis juste que normalement Applocker en place à la DGT empêche que Chrome soit installé sur les postes de travail. Mais il peut avoir quelques installs résiduelles qui ont été faites pour certains profils.

  2. Euh, pourquoi Google n’a-t-il tout simplement pas profité d’OCSP, comme pour les faux certificats précédents ? Pas besoin de Chrome pour cela.

    Autre hypothèse : un employé a vu quelque chose de bizarre, a regardé le certificat, et l’a transmis à un copain chez Google. On ne peut pas espérer faire du MITM sur TLS sans laisser des traces, pas la peine de suspecter un complot Google pour cela.

  3. Effectivement, google ne dit pas comment ils ont eu l’information. Une des réactions* sur hacker news d’un des contributeurs à ce qui concerne les certificats chez google dit « Note that we haven’t said that pinning found this event. We have several channels by which we receive information about these sorts of things. » Mais quelle source ils ne le précisent pas. Pourquoi ?

    * : https://news.ycombinator.com/item?id=6869978

    1. > Mais quelle source ils ne le précisent pas. Pourquoi ?

      Tout simplement pour éviter de tarir la source d’information, personnellement si j’apprends qu’un état se permet d’espionner mes conversations, j’aurai tendance à le dénoncer sans dire ce qui m’a tuyauté, histoire que s’il recommence je puisse le reprendre la main dans le sac.

  4. Après analyse des retweets menant à cette page et en fouillant les identités des personnes qui ont retweeté (cette page seulement), cet article a au moins fait naitre de l’interêt dans les ministères.

    Michel CAZENAVE: RSSI, MINISTÈRE DES AFFAIRES ÉTRANGÈRES ET EUROPÉENNES ( @michelcazenave)
    Frédéric DELFOSSE: Lead System and Network Engineer chez Direction générale du Trésor situé à Bruxelle :-D ( @fred_delfosse)

    Merci topsy :-)

    1. oui,

      j’en ai trouvé un bcp plus important dans la liste des retweeters:

      Florent C. ( @FlorentCBD) ancien sous-dir de l’ANSSI avec une belle carrière (celar, DCSSI)
      un autre de l’anssi @piscou, je ne publie pas le nom pour respecter son pseudonymat ou plutôt son prénonymat et j’ai de la sympathie pour les RE ;-)
      A priori, ils se posent la question aussi ^^

      Mais ce qui fait réfléchir, c’est que rien qu’en fouillant dans twitter et qui suit/est suivi, les centres d’intérêt affiché et les tweets/retweets (genre, je retweete bcp de ce que dis mon boss), on arrive a refaire une bonne partie de la sphère d’influence/sociale de quelqu’un. on pourrait recroiser avec lkdin, viadleau, gropain d’avent et ça ferai une joli liste

  5. Les postes sous windows étant sous le contrôle du service informatique et chrome utilisant le keyring windows, ils auraient du injecter une CA dédié à ce type de « travaux » plutôt que d’utiliser leur CA publique. Du coup, aucun risque de se faire prendre en pleine fabrication de contrefaçon.

    L’effet positif de cet article est quand même de montrer du doigt qu’un site, même avec le sacro-saint « petit cadenas » n’est pas forcement celui que l’on cherche à visiter.

  6. Voici la chaîne de certification qui a été détecté par Google:
    (c’est le blog de Adam Langley)
    https://www.imperialviolet.org/binary/anssi-chain.txt

    et la liste des domaines signés est sur la Security Advisory (2916652) de microsoft http://technet.microsoft.com/en-us/security/advisory/2916652 soit grosso modo les sites concernant google, android, youtube & urchin.

    Donc Google a bien réussi à récupérer les certificats en entier :-D

  7. Un point qui n’est pas très développé dans l’article, c’est comment la procédure de création/signature d’une sub CA (signée par la CA IGC/A) peut être aussi « simple » à l’ANSSI.

    Je veux bien croire à « l’erreur humaine » mais c’est un peu facile comme réponse.

    Normalement dans une entreprise / administration conséquente, signer une sub CA, ça se fait pas comme ça, suivant l’envie du moment d’un admin !

    Une personne seule ne doit pas être capable de créer et signer une sub CA… ou alors la procédure de l’ANSSI est vraiment à revoir (et c’est TRES inquiétant pour toutes les CA dépendant de l’IGC/A…).

    1. Ce n’est pas la création de l’autorité intermédiaire qui est en cause ici. On peut penser que cette procédure est maitrisée par l’ANSSI d’une bonne façon.
      Le problème est l’utilisation qui en a été faite derrière (signer des certificats pour des noms de domaines appartenant à google, et surement d’autres). L’erreur humaine est ici, faire du mitm avec une ca publique ne devrait pas arriver.

      Apres je me demande comment on peut être sur que chrome n’est pas utilisé à la DG Trésor (j’ai entendu le contraire) ?

      1. > Ce n’est pas la création de l’autorité intermédiaire qui > est en cause ici. On peut penser que cette procédure est > maitrisée par l’ANSSI d’une bonne façon.

        Je ne suis pas d’accord avec toi, il y a bien un problème avec la procédure de création de la CA. Ce n’est pas l’ANSSI qui l’a créée mais apparemment les admins de la ‘DG Trésor’ qui avait une délegation pour cela.

        Il suffit de revoir la chaine de certification en cause (https://www.imperialviolet.org/binary/anssi-chain.txt) : on est à 4 sous-niveaux sous l’IGC/A : (Root CA) IGC/A => MINEFI-AUTORITE DE CERTIFICATION RACINE => AC Racine DGTPE => AC DGTPE Signature Authentification => AC DG Trésor SSL

        Pas étonnant qu’avec une telle chaine de délégation, certains fassent des « conneries » sans comprendre.

        D’ailleurs, dans sa réponse, l’ANSSI a bien indiquée qu’elle avait démarrée un audit pour voir si les procédures de création des sub CA dépendantes de l’IGC/A, étaient correctement respectées.

        Par contre, on est bien d’accord que la connerie est d’avoir mis un CA « publique » sur une appliance firewall pour faire du « SSL Inspection ».

        Relis un post de blog que j’avais écrit à ce sujet à propos d’un problème analogue sur les appliances Cyberoam (Inde) : http://open.arkoon.net/aoc/blog/blog/archives/de-l-analyse-des-flux-chiffres-pourquoi-pas-mais-encore-faut

        1. J’étais pas allé voir la chaine effectivement. Cela dit, ma réaction était plutôt sur l’ANSSI, je ne pense pas qu’on puisse ici leur reprocher quoi que ce soit, l’erreur est du côté du Minefi/DG trésor. Cela va obliger l’ANSSI, à surveiller un peu mieux ce qui est fait, mais ils ne devraient pas en avoir besoin…
          Sinon, on est d’accord :)

  8. Si DGTresor n’utilise pas Chrome mais que Google a détecté le faux certificat, cela signifie (peut-être) que le faux certificat a été utilisé en dehors du réseau de DGTresor pour du MiTM conduit par l’ANSSI ou d’autres barbouzes ce qui a conduit à sa détection par Chrome…

  9. Je ne vois pas ce qui gène les gens dans l’activité du trésor.

    A mon avis, il est du devoir de l’equipe d’administrateurs en charge de la sécurité, d’éviter toute fuite ou toute intrusion dans leur réseau, tout en laissant les utilisateurs utiliser au mieux les ressources du net.

    Cela veut dire les laisser aller sur des sites externes à l’utilité reconnue, genre google, tout en garantissant la confidentialité de leurs transactions (flux sécurisés par « tuyaux » SSL). Cela passe par le fait d’anonymiser les requêtes sortantes via un proxy qui ne présentera qu’un seul utilisateur au reste du monde, par le fait de virer tout ce qui pose problème dans les pages visitées (traceurs, cookies, scripts, pub, etc) et qui seront rapatriées par la requête faite par l’utilisateur.

    Cela impose une inspection des paquets, et une éventuelle ré-écriture par le proxy, chose impossible si le flux est sécurisé de boute en bout.

    Donc si on est un admin, on a le choix entre ne rien autoriser comme traffic, autoriser du traffic en clair, ou crypter entre le proxy et le service externe _et_ crypter entre le proxy et l’utilisateur interne.

    C’est probablement cette dernière option qui a été retenue. Elle n’est pas malicieuse, d’autant plus qu’il n’a jamais été fait mystère de l’origine du certificat qui dit tout simplement à l’utilisateur interne que « Nous le trésor, nous vous certifions que votre connexion avec ce site est cryptée, vous êtes bien en contact avec le site demandé, malgré le fait que le certificat n’est pas celui d’origine, il ne s’agit pas d’une attaque de type MITM menée par un inconnu situé entre vous et le site serveur distant, et si vous avez des doutes sur le fait que je suis bien le trésor, voyez, l’ANSSI, tiers de confiance accrédité au plus haut niveau l’atteste… »… Après c’est comme tout certificat, soit vous avez confiance dans le tiers de confiance, soit vous ne lui faites pas confiance.

    Donc rien que de très normal, à mon sens, coté trésor. Ce scénario pourrait très bien avoir lieu dans n’importe quelle entreprise soucieuse de la sécurité de ses données et de ses utilisateurs, même pas besoin d’être une administration, et nul doute qu’une charte quelconque mentionne que le trafic sortant/entrant est surveillé/sécurisé.

    Après cela gène peut être Google de perdre la trace de l’identité du client de ses services, de ne pas pouvoir faire son profil psychologique, de ne pas pouvoir lui fourguer des pubs adaptées, mais ça, a priori, n’est pas légitime.

    (Ceci posé, la vraie question qui reste en suspend, c’est comment un tiers externe au reseau interne a pu connaitre la nature des échanges entre les utilisateurs du trésor et leur firewall? )

    1. Tout a fait d’accord sur l’usage legitime d’un certificat interne pour inspecter les flux sortants… surtout pour des sites US soumis au Patriot Act et offrant du webmail
      Mais je comprends l’ANSSI qui prefere communiquer sur une erreur plutot que devoir expliquer comment inspecter un flux chiffre SSL au travers d’un proxy !?

      Je pense qu’il faut lire ‘rien d’anormal’ dans votre propos ‘Donc rien que de très normal’

    2. « Cela passe par le fait d’anonymiser »

      C’est illégal, tout simplement. C’est un intrusion dans une communication sécurisée. C’est une contrefaçon d’une marque de Google et une violation des conditions d’utilisation de Google.

      L’Etat ne doit pas jouer à ça. Jamais.

      C’est une honte.

  10. Tout simplement ils ont dû utiliser la fonction atv de flux et/ou atv mail du netasq. Y compris pour les communications SSL.
    Ce qui nécessite de transformer le firewall en proxy SSL et avec autorité de certificat CA, donc en quelque sorte en faire un pseudo DPI.
    Lors d’une com http standard pas de certificat, analyse de flux et atv se font sans soucis (avec blacklist et whitelist au besoin), en revanche en SSL il faut bien que le Fw soit capable de déchiffrer le flux pour l’analyser, et le rechiffrer en sortie pour garantir le chiffrement de la com vers le serveur distant, d’où un certificat différent de celui du navigateur (comment Google l’a su mystère).
    Je présume donc que l’admin netasq a sûrement merdouillé, ou que celui qui lui a filé le certificat racine s’est peut être lourdé ou que Google ne tolère pas l’analyse de flux SSL.
    L’ANSSI fait de la LID et de la formation/conseil/audit, ce n’est pas dans leurs prérogatives de faire du MITM et ça la LIO (rôle de la DGSE plutôt).

  11. Que d’efforts pour noyer le poisson.

    La conclusion est que l’ANSSI n’est pas capable de garantir la sécurité informatique de sa clef, qu’on ne peut pas lui confiance et qu’on passe pour des cons dans le monde entier.

    Mais bien sûr, quand l’ANSSI contrefait un site Google, c’est Google le méchant. LOL

  12. Pour la question à la fin de l’article, la réponse est sans doute simple :
    Il est techniquement possible d’effectuer une connexion https en javascript (AJAX), et se débrouiller pour en récupérer les propriétés SSL/TLS. Afin, ensuite, de remonter les infos collectées si elles ne correspondent pas.

    Si les services de google ne sont pas tous bloqués par l’appliance qui effectue le MITM, c’est sans doute par ce biais que google a détecté l’affaire.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *