#OpSyria : Bluecoat au coeur d’attaque MITM de grande envergure ?

Devant l’avalanche de preuves remontée par le groupe Telecomix, la société BlueCoat a finalement admis que certaines de ses machines étaient présentes en Syrie, et qu’elles étaient utilisées pour censurer le Web.

Le débat est-il clos pour autant ?

D’après BlueCoat, les machines repérées par Telecomix avaient été commandés par un distributeur de Dubaï en 2010 et étaient destinée au ministère des communications irakien. Comment sont-elles passées de l’Irak à la Syrie ? Mystère. Mais si cette dernière livraison de 14 appliances parait avoir eu pour but de servir à contrer le printemps Arabe, le régime de Bachar el-Assad s’est toujours montré friand des appliances BlueCoat. Le WSJ parle de plus de 25 appliances ayant trouvé leur chemin vers la Syrie depuis les années 2000. Celles-ci étaient déjà probablement à la base de la machine à censure du régime.

Le débat qui s’ouvre maintenant aux Etats-Unis est celui de la surveillance des exportations et du contrôle des embargos. L’enquête va essayer de déterminer les responsabilités de BlueCoat, du distributeur basé à Dubaï et celles du ministère des communications irakien. L’affaire est entre les mains du ministère du commerce.

Mais le débat nous a-t-il vraiment échappé ? Peut-être pouvons nous contribuer à le garder vivant et à le faire évoluer ?

Je vous invite à plonger dans les logs de la censure syrienne. Logs que nous savons issus des quatorze proxy BlueCoat commandés par le régime de Bachar en fin 2010. Proxys encore à l’oeuvre, à l’heure ou nous écrivons ces lignes, pour contrer la déferlante révolutionnaire issue du printemps arabe.

Nous allons devoir parler technique. Mais nous nous efforcerons de rester compréhensibles pour les moins techniciens d’entre vous.

 

Miner les logs Bluecoat à la pioche

Filtrer le Web d’un pays, revient à placer entre les utilisateurs syriens et le reste du monde des proxys. Ces logiciels reçoivent toutes les requêtes Web demandées par les syriens, les interceptent et les transmettent vers les sites légitimes demandés.

Utilisateur syrien  -> Proxy Bluecoat ->  Web mondial

Au passage ces proxys analysent les requêtes et peuvent prendre un certain nombre de décisions : laisser passer la requête, renvoyer une page d’erreur, … Chaque fois qu’une action est effectuée, les proxys gardent une trace de cette action. Ces traces sont appelées fichiers « logs ». Ce sont ces traces qui ont été récupérées par le groupe Telecomix et qui sont une des preuves avancées par le groupe pour démontrer que ces proxys sont produits par la société américaine BlueCoat.

Les informations contenues dans ces logs sont décrites par une « en-tête » en début de chaque fichier :

#Fields : date time time-taken c-ip cs-username cs-auth-group x-exception-id sc-filter-result cs-categories cs(Referer) sc-status s-action cs-method rs(Content-Type) cs-uri-scheme cs-host cs-uri-port cs-uri-path cs-uri-query cs-uri-extension cs(User-Agent) s-ip sc-bytes cs-bytes x-virus-id

En nous plongeant dans la documentation BlueCoat, nous pouvons identifier le format exact de ces logs : « bcreportermain_v1″. Chaque ligne de log contient des informations comme la date (date) et le type d’action effectué (s-action), la page Web demandée (cs-host, cs-uri-path, cs-uri-query), le navigateur utilisé par le client (cs(User-agent)), l’adresse IP du Proxy qui a reçu cette requête web (s-ip).

 

Creuser dans du trafic encrypté : le cas SSL

Si l’étude du cas de SSL nous a semblé intéressante, c’est que ce protocole permet de dissimuler ses communications. Lorsque vous vous connectez sur un site en SSL (https) la connexion entre votre navigateur et le site que vous visitez est cryptée, empêchant tout personne sur le chemin d’en inspecter le contenu. Cette confidentialité fait l’objet de bien des convoitises.

En mai 2011, l’EFF signale un attaque « Man In the Middle » visant les utilisateurs syriens. L’alerte a été donnée par un blogger syrien. Les certificats SSL de Facebook ont étés modifiés. Mais cette attaque reste dans le domaine de l’amateurisme : les certificats ne sont pas signés par une « autorité de certification » et émettent des alertes dans les navigateurs Web.

Peu efficace et très visible.

Les logs récupérés par les activistes de Telecomix datent de début août 2011, soit trois mois après l’attaque signalée par l’EFF. Comment, à cette date, les proxys BlueCoat réagissaient-ils au trafic SSL ?

Référons nous à un forum Bluecoat.

Un administrateur dans le besoin y explique vouloir mettre en place une interception transparente pour surveiller les utilisateurs de son réseau. Tout parait se dérouler sans problème en ce qui concerne le trafic en HTTP en clair. Mais pour le trafic crypté (https) : aucune solution.

So I configured a transparent TCP tunneling on port 443, without protocol detection, and no SSL Intercept layer. All traffic shows up in the main log as TCP_TUNNELED with tcp as the protocol and the destination IP as the destination.

Sans interception SSL, l’administrateur ne parvient à obtenir aucune information autre que l’adresse IP du serveur Web cible. L’action effectuée par le proxy semble être : TCP_TUNNELEDCelle-ci est ainsi décrite dans la documentation BlueCoat :

« The CONNECT method was used to tunnel this request (generally proxied HTTPS)« .

Revenons vers les fichiers logs de nos BlueCoat syriens. Dans ces logs, 90% du trafic entraînant la réponse TCP_TUNNELED était à destination du port 443. Et 94% des requêtes à destination du port 443 (SSL) amènent la réponse suivante :

OBSERVED "none" -  200 TCP_TUNNELED CONNECT -

Dans les logs syriens, nous trouvons de nombreuses lignes ressemblant au comportement décrit par notre administrateur trop curieux :

2011-08-02 11:22:35 140097 0.0.0.0 - - - OBSERVED "none" -  200 TCP_TUNNELED CONNECT - tcp 98.178.191.195 443 / - - - 82.137.200.48 39 209 -

Nous nommerons ces logs : les « Logs Muets ».

 

Des lignes de logs qui dérangent 

Jusqu’ici tout va bien. Nos utilisateurs syriens sont bel et bien surveillés (le blocage de la page « syrian.revolution », visible dans les logs, l’atteste). Mais lorsqu’ils prennent la peine de se connecter à leurs sites favoris en SSL, Bachar lui même ne peut pas lire leurs communications.

Sauf que …

Quitte à avoir sorti la pioche à logs, autant finir le travail. Penchons-nous à nouveau sur les requêtes SSL à destination du port 443 et creusons, à la recherche d’irrégularités.

Et très vite celles-ci sautent aux yeux. Plus de la moitié des requêtes à destination du port 443 sont beaucoup plus bavardes que ce à quoi nous nous attendions :

2011-08-02  11:18:20 892 0.0.0.0 - - - OBSERVED "none" -  200 TCP_TUNNELED CONNECT -  tcp login.live.com 443 / - - "Mozilla/4.0 (compatible; MSIE 6.0;  Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR  3.5.30729; InfoPath.1; IDCRL 5.000.819.1; IDCRL-cfg 11.0.18042.0; App  msnmsgr.exe, 14.0.8117.416, {7108E71A-9926-4FCB-BCC9-9A9D3F32E423})"  82.137.200.48 2935 464 -

Dans ces requêtes à destination du port 443 nous pouvons lire :

  • Le nom du site visé ( ici login.live.com )
  • Le User-Agent (navigateur utilisé par l’utilisateur, ici Mozilla/4.0 […]

Ces informations sont normalement protégées par l’encryption de la connexion et le proxy Bluecoat ne devrait pas y avoir accès. Nous allons appeler ces lignes de logs les « Logs Bavards ».

Quelques statistiques nous renseignent rapidement sur ces lignes de logs anormales.

  • 95% des sites en HTTPS émettent des « Logs muets ». Mais ces sites ne concernent que 43% du trafic
  • 5% des sites en HTTPS émettent des « Logs bavards ». Ces sites concernent plus de 55% du trafic observé.

Et quels sont donc les 15 premiers sites émettant des « Logs bavards » et qui totalisent 35% du trafic HTTPS observé :

  1. www.microsoft.com
  2. imo.im
  3. urs.microsoft.com
  4. plusone.google.com
  5. login.live.com
  6. s-static.ak.facebook.com
  7. www.facebook.com
  8. secure.wlxrs.com
  9. apis.google.com
  10. by6.omega.contacts.msn.com
  11. ssl.gstatic.com
  12. www.google.com
  13. mail.google.com
  14. fbcdn-profile-a.akamaihd.net
  15. login.yahoo.com

A ce stade là vous devriez commencer à être troublés. Les BlueCoat syriens seraient-ils réellement capables de décrypter le trafic SSL vers ces sites grand public ?

Et comment expliquer, que hormis l’affichage du Hostname et du User-Agent, nous n’observons jamais d’URL complexe pour ces sites ? Jamais de « /en-us/default.aspx » ou de « /syrian.revolution ».

Un effet du TCP Tunneling ?

 

Forer dans la documentation Bluecoat

Trouver un cas documenté d’interception SSL qui produise des logs « Bavards » nous permettrait de renforcer nos soupçons. D’écarter quelques doutes. Quelques mots clefs tapés sur google et nous nous retrouvons face à une avalanche de documentation et de forums d’aide BlueCoat.

Une partie de plaisir.

La surveillance  semble être un sujet de discussion courant entre les clients de BlueCoat. L’interception SSL se taille la part du lion. Ici une documentation PDF avec un titre explicite : « Comment obtenir la visibilité et le contrôle sur les sessions web cryptées en SSL« . Ici une entrée dans la base de connaissance BlueCoat : « Configurer le proxy SSL dans ProxySG pour l’interception transparente et l’authentification utilisant des certificats SSL issus du serveur PKI de Microsoft« , ou encore cet article « Bluecoat va nettoyer le traffic crypté« , vecteur pour les malware et les virus.

Continuons un peu de parcourir le Web à la recherche de ces lignes de logs mystère. C’est sur les forums d’aide aux administrateurs que nous trouvons les premières pistes des logs anormaux. Dans ce tutoriel appelé « SSL Proxy for the Bluecoat Proxy SG« , l’administrateur décrit les bénéfices du « SSL frowarding proxy » de Bluecoat.

Security is increased by Server cert validation , including CRLs and Virus scanning and Url filtering. There is also an increase in log visibility.

Continuons à suivre cette piste. C’est dans la documentation BlueCoat que nous trouverons notre prochain indice. Dans la documentation « Secure_Sockets_Layer_(SSL)« , le service marketing de l’entreprise explique que :

Just as importantly, Blue Coat user management tools, including alerts and coaching pages, user authentication, and centralized reporting, allow you not only to be selective in the SSL you intercept, but also to produce auditable logs of user consent.

Tout nous amène à penser que lorsqu’une interception SSL est mise en place, les logs du Proxy deviennent en effet plus bavards.

C’est finalement sur un site d’aide de Microsoft que nous démasquerons notre proie. Dans ce forum, le client s’interroge sur la façon dont communique un proxy BlueCoat avec les sites SSL, quand il utilise la technique du « TCP Tunneling ». Dans la configuration qui nous est décrite, l’administrateur identifie chaque utilisateur de son réseau grâce à un certificat embarqué dans le navigateur du client. Le proxy déchiffre donc le traffic SSL.

Quelques lignes plus bas, il publie un exemple de logs pour prouver que son tunnel tcp est bien actif.

2009-09-28 16:35:59 192.168.1.106 - - 164 200 TCP_TUNNELED 1744 920 CONNECT 443 tcp myweb.test.com / - - NONE 12.154.90.12 - OBSERVED HTTP/1.0 "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506)"

Notre « Log  bavard » !

Nos soupçons ne font que se confirmer. Début août 2011, les BlueCoat syriens semblaient être en mesure de faire de l’interception sur les flux SSL. Cette constatation soulève un problème de taille.

Pour être en mesure de décrypter le trafic SSL, les machines Bluecoat doivent être en possession de certificats SSL valide. Ces « clefs » secrètes garantissent l’identité du site visité. Seuls des organismes internationaux de confiance, appelés « autorité de certifications » sont habilités à les délivrer, et aucun des ces organismes n’est dans la sphère d’influence du régime de Bachar el-Assad. Sans certificats SSL délivrés par une « autorité de certification », impossible d’espionner discrètement les communications SSL.

Sans un certificat valide pour le domaine « facebook.com », voici le message qui apparaît dans les navigateurs Web « chrome » des utilisateurs qui tenteront de se connecter vers la version SSL de facebook : « https://www.facebook.com » :

Si des indices laissent bien à penser que une grande partie du trafic SSL syrien a bien été décrypté, comment imaginer que le gouvernement soit rentré en possession de certificats valides pour facebook.com, microsoft.com, google.com, …

Pour chaque site qui dans les logs Bluecoat émettent des traces « bavardes » ?

 

Un hacker à la manoeuvre ?

Jusqu’à présent nous avions travaillés avec des données concrètes, exfiltrées de Syrie et validées par la société BlueCoat elle même. Mais à part ces étranges lignes de logs, pas de trace de ces certificats dans les données remontées par Telecomix. Et mis à part l’alerte relayée par l’EFF en mai 2011, pas d’autres signes de malversation sur le trafic SSL.

Nous allons maintenant rentrer dans le domaine de la supposition. Et prendre un peu de recul avec la technique, pour jeter un coup d’oeil plus large sur le contexte géopolitique et la dynamique à l’oeuvre dans la région. Pour cela, rien de tel qu’une petite timeline.

  • Fin 2010 : Les BlueCoat commandés par l’intermédiaire de Dubaï, partent de Rotterdam et sont livrés, après de mystérieuses pérégrinations en Syrie.
  • Février 2011 : Lorsque le gouvernement, face aux revendications de son peuple, rouvre, en gage de bonne foi, l’accès libre à Facebook et à Twitter, les proxys BlueCoat sont prêt , à l’écoute.
  • Mai 2011 : L’EFF alerte sur une attaque MITM, qu’elle qualifie d’amatrice. Puis plus rien, le calme plat.
  • Juillet 2011 : Telecomix va mettre en place des comparaisons occasionnelles du certificat pour le domaine « facebook.com » avec des syriens. Ils ne noteront aucune malversation.
  • 19 Juillet 2011 : l’autorité de certification néerlandaise Diginotar détecte une intrusion sur son réseau. Elle affirme avoir effectué un audit et avoir révoqué tous les certificats frauduleux.
  • 22 Juillet – 5 aout 2011 : Période couverte par les logs de #OpSyria.
  • Autour du 10 aout : Des activistes observent le blocage du port 443 pour les domaines « facebook.com » et « yahoo.com » et la redirection automatique vers le port 80 (non crypté).
  • 29 août 2011 : Google détecte l’utilisation d’un certificat de DigiNotar frauduleux en Iran. Celui-ci semble avoir échappé à la vigilance des auditeurs.  Les principaux navigateurs décident de bannir DigiNotar de la liste des autorités de certification de confiance.
  • 5 septembre 2011 : « Comodohacker » revendique la compromission de DigiNotar. Il aurait pris la décision d’attaquer cette société le 11 juillet 2011, pour commémorer le massacre de Srebrenica.
  • 20 septembre 2011 : Diginotar est placée en procédure de banqueroute par son propriétaire, le groupe VASCO.

 

Serait-il possible que le gouvernement syrien soit entré en possession de certificats valides de la société DigiNotar. Ou de certificats en provenance d’une autre autorité de certification. Car « Comodohacker » n’en est pas à son coup d’essai. Le 26 mars 2011, il revendique une attaque sur la société Comodo. En transitant par une société partenaire italienne, il parvient à accéder à la console de génération de certificats SSL et à créer des certificats authentiques. A cette occasion, il proclame ses motivations et ses allégeances. Morceaux choisis :

Premièrement je dois mentionner que je n’ai aucune relation avec l’Iranian Cyber Army. […] Nous ne faisons que pirater, et nous rendre maître des serveurs.

Je ne suis pas un groupe, je suis un hacker solitaire avec l’expérience de 1000 hackers, un programmeur solitaire avec l’expérience de 1000 programmeurs, […]

Ceci s’adresse au monde donc écoutez attentivement :

Quand les USA et Israël écrivent Stuxnet, personne n’en parle, personne n’est blâmé, absolument rien n’arrive, donc quand je signe mes certificats rien ne doit arriver, Je le dit, rien ne doit arriver. C’est un marché simple.

Quand les USA et Israël peuvent lire mes mails dans Yahoo, Hotmail, Skype, Gmail, etc. sans le moindre petit problème, quand ils peuvent espionner avec Echelon, je peux faire tout ce qui est en mon pouvoir ! C’est une règle simple.

Vous agissez, j’agis, c’est tout. Vous arrêtez, j’arrête. C’est la Règle numéro 1.

[…]

Règle numéro 3 : Tout ceux qui ont en Iran des problèmes, de la fausse révolution verte à tous les membres du MKO et terroristes à deux faces, doivent me craindre personnellement. Je ne laisserai personne à l’intérieur de l’Iran blesser le peuple iranien, blesser les scientifiques nucléaires iraniens, blesser mon leader (ce que personne ne peut faire), blesser mon président, tant que je vivrais, vous n’en serai pas capable. Tant que je vivrais vous n’aurez pas de vie privée sur internet, vous n’êtes pas en sécurité sur le monde digital, patientez et vous verrez.

Règle numéro 4 : A Comodo et aux autres autorités de certification dans le monde : Ne pensez jamais être en sécurité, ne pensez pas que vous pouvez diriger internet, diriger le monde avec des nombres a 256 chiffres dont personne n’arrive à trouver les 2 facteurs premiers. […]

Règle numéro 5 : A Microsoft, Mozilla et Chrome qui ont updatés leurs logiciels dés que les instructions sont venues de la CIA. Vous êtes mes cibles aussi. Pourquoi la vulnérabilité imprimante Stuxnet n’a-t-elle été patché qu’après 2 ans ? Etait-elle nécessaire à Stuxnet ? […] J’apporte l’égalité sur Internet. Mes ordres vont égaler les ordres de la CIA.

Règle numéro 6 : Je suis un fantôme.

Règle numéro 7 : Personne ne peut m’arrêter, soyez effrayés si vous devez l’être, soyez inquiets si vous devez êtres inquiets.

 

Ce manifeste a été jugé crédible par les bloggers erratasec. Ils affirment :

I find it probable that (1) this is the guy, (2) he acted alone, (3) he is Iranian, (4) he’s patriotic but not political.

Mais d’autres experts se sont montrés plus dubitatifs. Comodo aurait été une attaque isolée, opportuniste et chanceuse. Avec la mise en banqueroute de la société DigiNoar, les menaces de « Comodohacker » sont peut-être à reconsidérer et à prendre au sérieux. « Comodohacker » affirme dans sa dernière revendication avoir compromis quatre authorités de certification majeures qu’il ne nomme pas. Il précise avoir eu accès aux serveurs des la societé StartCom CA, et aurait encore à l’autorité de certification GlobalSign.

 

Touchons-nous au but quand nous évoquons cette théorie du piratage de certificats ? Les proxy BlueCoat ont-ils bien embarqué pendant une période, des certificats Diginotar ?

Bien d’autres scénarios pourraient être envisagés. Avec l’essor des capacités de surveillance des populations, et le maintien d’une géopolitique hégémonique basée sur le tension, il est à craindre que les attaques sur le protocole SSL deviennent monnaie courante. Et lorsque l’on rentre dans le monde du détournement et du hack, l’arbre des possibles se déploie, et l’imagination devient les seule limite.

Infection massive sur les postes client Syriens, achat de certificats valide sur le marché noir, ou obtention de certificats authentiques contre on ne sait quelle contrepartie géopolitique…

 

Une carrière à ciel ouvert

Si nous nous sommes aventurés dans le domaine des hypothèses c’est que des indices solides, issu de données exfiltrés directement de Syrie montraient qu’une partie du trafic SSL syrien avait été sous surveillance.

Ces données sont publiques et nous invitons la communauté et nos contradicteurs à valider ou invalider nos hypothèses.

Et si de nombreuses questions restent encore suspens, il semble possible que les proxys BlueCoat aient servi à implémenter une attaque ‘Man in the Middle » de grande ampleur contre les utilisateurs de l’internet Syrien.

Comment conclure ? Pourquoi conclure ?

Devons-nous blâmer la société BlueCoat parce qu’elle propose des solutions d’inspection SSL ? Et de les proposer à l’échelle  d’un pays ?

Devons-nous blâmer les autorité de certifications  qui par leur incompétence, leur manque d’indépendance et leur structures centralisées, ont éventuellement mis en danger de nombreuses vies ? Ou « Comodohacker » pour avoir, peut-être, permis à deux gouvernements autocratiques de surveiller leur population ?

Devons nous blâmer l’Iran et la Syrie qui répriment par tous les moyens mis à leur disposition les aspirations démocratiques de leur peuples ? Ou les Etats-Unis et leur double langage : nucléaire civil pour toi, pas de nucléaire civil pour toi … surveillance généralisée de l’internet pour moi, et seulement pour moi !!

Notre but n’est pas de dénoncer tel ou tel acteur, mais de défendre des principes universels nécessaire à l’émergence d’un monde plus juste. En rapportant des faits étayés, nous visons encore et toujours à enrichir le débat.

Une question nous taraude : avec leurs capacités de surveillance généralisées, comment pensez-vous que réagirait l’élite aux Etats Unis face à une authentique révolution de la part de son peuple ? Verrions-nous apparaître des dérives à l’iranienne ?

 

Twitter Facebook Google Plus email


29 thoughts on “#OpSyria : Bluecoat au coeur d’attaque MITM de grande envergure ?”

  1. « auX Etats-Unis » et non pas « au Etats-Unis »

    « quatorze proxy BlueCoat commandées », ‘proxy’ est féminin ?

    « des proxy » ou « des proxys » (l’un ou l’autre plusieurs fois dans le texte) ?

    « Les informations contenues dans ces logs sont décritEs » et non pas « Les informations contenues dans ces logs sont décrits »

    « Lorsque vous vous connectez » et non pas « Lorsque que vous vous connectez »

    « les certificats ne sont pas signés » et non pas « les certificats ne sont pas signéEs »

    « sans problème » et non pas « sans problèmeS »

    « vous devriez commencer à être troubléS » et non pas « vous devriez commencer à être troublé »

    « Les BlueCoat syriens seraient-ils réellement capableS » et non pas « Les BlueCoat syriens seraient-ils réellement capable »

    « SeulS des organismes internationaux de confiance » et non pas « Seul des organismes internationaux de confiance »

    « Sans certificat SSL délivré » et non pas « Sans certificatS SSL délivré »

    « pas de trace » et non pas « pas de traces »

    Je finirai plus tard ;)

    Amicalement :)

      1. Je t’en prie :) J’apprécie trop votre travail pour laisser toutes ces fautes ; c’est important pour crédibiliser vos articles.

        Je continue donc,

        « pas d’autre signe » et non pas « pas d’autreS signeS »

        « les proxys BlueCoat sont prêtS, » et non pas « les proxys BlueCoat sont prêt , » (le ‘S’ à ‘prêts’ et pas espace avant la virgule)

        « Serait-il possible que… » -> donc un « ? » à la fin de la phrase.

        « dès que » et non pas « dés que »

        « n’a-t-elle été patchée » et non pas « n’a-t-elle été patché »

        « autorités » et non pas « autHorités »

        « et aurait encore accès à l’autorité » et non pas « et aurait encore à l’autorité »

        « achat de certificats valide » et non pas « achat de certificats valideS » non ?

        « issu de données exfiltrés » et non pas « issuS de données exfiltrés », enfin je pense…

        « de nombreuses questions restent encore EN suspens » et non pas « de nombreuses questions restent encore suspens »

        ‘Man in the Middle » : petit soucis de guillemets

        « les autoritéS de certifications » et non pas « les autorité de certifications »

        « leurS structures centralisées » et non pas « leur structures centralisées »

        « principes universels nécessaireS » et non pas « principes universels nécessaire »

        « Etats-Unis » et non pas « Etats Unis »

        Amicalement

  2. (Je suis conspirationniste mais)
    N’est-il pas permis d’imaginer que des passerelles du type de celles de BlueCoat ne puisse pas directement intégrer, par défaut, un certificat valide fournit par les autorités de certification à BlueCoat ou directement par le site tiers (Microsoft, Fakebook …) ?

    Owni publiait la présence d’un Glint français (pas vu ici) ; est il alors imaginable que celui-ci soit équipé de ces mêmes certifs ?

    J’ai vu une autre coquille pas remontée ci-dessus (mais c’est pas là l’important – et je troll pas ceux qui les remontent, ça participe à la crédibilité d’un article à mes yeux) : il manquait un mot comme « accès » lorsque tu écrivais un truc dans le genre « avoir * aux logs syriens », mais je ne l’ai pas retrouvé, sorry :)

    1. Non je pense qu’il est tout à fait improbable que les plateforme type « Bluecoat » ou « Amesys » embarquent ces certificats par défaut. Ces certificats valent leur pesant d’or et Bluecoat devrait alors sérieusement revoir ses tarifs à la hausse :)

      Par contre ces certificats pourraient (dans une théorie conspirationniste) devenir des carottes géopolitiques fort attrayantes.

  3. Super article !
    Par contre, et mis a part les quelques fautes d’orthographe vous parlez d’une attaque signalée en 2005 par EFF deux fois alors que dans le résumé chronologique elle semble apparaitre en mai 2011. Ce sont deux signalements differents ou une erreur de votre part ?

  4. Cette histoire de certificats est bien inquiétante.
    Elle me rappelle celle de Microsoft en Tunisie, si ma mémoire est bonne, cela remonte grosso modo à l’époque où Fabrice Epelboin est passé de RWW à Reflets, non ?

    Petite question (je ne suis pas technicien) : cela impacte-t-il la confiance qu’on peut faire à TOR ?
    Si oui, Telecomix ne regrette-t-il pas, retrospectivement, d’avoir incité les syriens à adopter TOR (ou suis-je à côté de la plaque) ?

    merci d’avance.

  5. Hello,

    Juste pour info on a des Bluecoat ici au boulot et on ne fait pas d’interception SSL.
    En revanche on passe bien par le proxy pour le SSL (CONNECT) et le fqdn (tcp://mysite.fqdn:443) ainsi que le useragent sont bien visibles dans les logs. Mais bien sur l’URI ne l’est pas…

    Donc je me demande si vous ne vous êtes pas fourvoyé pour le coup…

    1. Je suis très interressé à pouvoir avoir plus d’informations à ce sujet. Tu peut me joindre sur le chan de #reflets ou par mail.

      Nous sommes allé aussi loin que nous pouvions et nous n’avons pas réussi à lever toute les incertitudes sur ces lignes de logs.

      L’article a été écrit avec de nombreuses pincettes, et dans le but de confronter nos observations.

      Merci pour la remontée d’infos.

  6. Un petit point technique.

    1/ Soit un client A qui se connecte à un site B https.
    un intermédiaire passif placé sur le chemin ne verrait rien d’autre que la session SSL.
    Test: connectez vous sur votre routeur, faites un coup de wireshark, ça démarre par une session SSL

    2/ Soit un client qui se connecte par un proxy sur un site B en https.
    L’admin du proxy voit d’un seul coup beaucoup plus de choses. Les navigateurs webs sont un peu plus bavards et ne démarrent pas par une connection SSL.
    La connexion démarre par une commande
    CONNECT reflets.info:443 HHTP/1.1
    User-Agent: Mozilla/5.0 etc..
    Proxy-Connection: keep-alive
    Host: reflets.info
    etc…
    Donc l’admin du proxy peut avoir des logs verbeux.

    Et ceci, uniquement avec un observateur entièrement passif, sans parler de certificats cassés, ou de redirection de trafic.

      1. Yup. On peut regarder les FAI français, par exemple. Dans le temps, free proposait proxy.free.fr, orange propose proxy.orange.fr, etc…

        Il faudrait regarder les CGV des FAI syriens afin de vérifier s’ils proposent des proxy. Les internautes conscienceux renseignent le proxy dans leur navigateur, et les logs des bluecoat se remplissent de manière plus verbeuse.

          1. Un proxy transparent ne fonctionne pas avec de l’HTTPS (forcément).
            Le navigateur démarre par une session SSL, donc pas moyen pour le proxy d’intercepter quoi que ce soit.

            Si le proxy est spécifiquement paramétré, alors il y a un CONNECT.

          2. je me répond à moi même :
            en cas de proxy transparent (redirigé, inline ou en utilisant le protocole WCCP), on voit pas le user agent ni le fqdn car le navigateur n’utilise pas la méthode CONNECT.
            Donc le seul moyen pour analyser ce flux est bien de faire de l’interception SSL (https://kb.bluecoat.com/index?page=content&id=KB1478&actp=LIST).

            Une dernière possibilité est que beaucoup de navigateur sont configuré en mode autodiscovery pour le proxy, et ce serait cette faille qui pourrait être utilisée (à vérfier, c’est le cas pour IE il me semble mais pas pour Firefox).

          3. Autre information qui pourrait jouer en faveur de cette approche :

            Jusqu’en debut 2011, Facebook était bloqué en Syrie. Pour fournir quand même le service, les cybercafé proposaient de passer par des proxys (j’y était j’ai testé ).

            Peut être que même après la réouverture de Facebook, les utilisateurs ont gardés leurs comportement pre-2011 : paramétrer un proxy pour aller surfer sur facebook. Ce proxy étant configuré, il traite TOUS les sites en https donc ceux que nous pouvons observer.

            J’essayerai de poster quelques stats sur les logs pour essayer de tester cette théorie.

            L’idéal aurait été d’avoir les IP des clients ( est ce qu’un seul client a fait certaines requetes Bavardes ET certaines requets en mode Muet ) -> MITM

            J’essayerai de faire des stats sur les host destination des CONNECT ( si certains logs Muets sont à destination des IP de Facebook alors la caractéristique « Muet/Bavard » ne depend pas du site cible -> pas de MITM )

            Raisonnement correct ?

          4. Tu parles là de proxy explicitement configurés, et comme ce sont des proxys pour bypasser un blocage, ce ne sont surement pas des proxys d’états.
            Donc l’hypothèse me semble fausse, un client ne va pas explicitement utiliser un proxy d’état pour bypasser une censure d’état (à moins que ce soit plus pervers que ça et que l’état veuille voir le contenu exprès).
            Donc si ce proxy est utilisé c’est soit avec la complicité des cybercafés, soit par inadvertance (détection proxy activée), soit par reroutage du trafic.

            Mais ta dernière hypothèse est à creuser.

          5. :)

            Je parle bien sur d’une hypothèse ou :

            1 – les cyber café acceptent de passer par des proxy d’etat. Et qu’ils configure leur navigateurs par défaut pour réaliser ceci. Je rapelle que on doit montrer son ID pour se connecter dans un cyber café. Et que il y a 2 ans encore, les moukhabarat (renseignement) passaient plusieurs fois par jour pour récuperer les ID de ceux qui s’étaient connectés les derniers jours.

            2 – le syrien de base n’est pas Tech. Il ne fait aucune activitée subversive. Il n’a pas d’ordinateur chez lui. Il se connecte sur son compte Facebook au cybercafé du coin.

          6. Donc c’est bien perverti.
            « C’est bloqué sauf si on peut voir ce que vous faites »…

            Belle ambiance :(
            Enfin ça arrive ici aussi :(

          7. Pour info, oui en Syrie il faut renseigner explicitement le proxy.
            C’est du genre : proxy.scs-net.sy ou proxy.net.sy
            Je donne ces infos de mémoire, j’ai quitté le pays il y a qq temps.

            Beaucoup de gens (surtout les jeunes) accèdent a facebook et aux mails via leurs portable. Pareil, ils doivent d’abord configurer leurs téléphones (il faut envoyer un sms à l’opérateur, qui renvoi la conf automatiquement sur l’appareil).
            Par contre je ne connais pas les proxys pour les portables.

            SVP penchez-vous sur l’internet mobile, je pense que c’est là qu’est le plus gros enjeux car c’est ce qu’utilise le plus grand nombre (qui ne veulent pas aller en cyber café pour ne pas donner leur ID, et qui n’ont pas internet chez eux car trop cher).

  7. Pour le MITM via la récup de cert diginotar j’y crois pas une seule seconde. L’hypothèse la plus problable: un jour les clients ont vu le message d’avertissement ils ont cliqué oui/oui/oui et basta MITM SSL.

  8. J’aimerai vraiment connaître vos différents avis suite à votre échanges. Je suis désolé de ne pouvoir enrichir la réflexion vu mon faible niveau technique.
    Shaman, si vous faites cette analyse statistiques qui permettrait de donner du poids aux différentes des hypothèses, ce serait top.

  9. La session https passe en ssl… mais le « connect » à destination du proxy afin d’ouvrir le tunnel pour le traffic chiffré (inexploitable par le proxy), ne pourrait-il pas être plus bavard quand c’est le navigateur qui s’en charge car le proxy n’est pas configuré globalement sur la machine?

    Pour avoir utilisé des outils externes pour faire le connect (proxytunnel…), afin de me connecter du taf à mon PC perso en SSH, celui-ci donnait la possibilité de passer un user-agent (entre autres!) au proxy car là ou je bosse c’est vérifié (le user-agent chrome est bloqué pour pallier au fait que google s’accorde dans son EULA licence d’exploitation de ce qui y passe, posant de possibles pb de propriété intellectuelle) et un user-agent vide se faisait jeter.

    Bon, ca fait qq années car depuis y’a visiblement un test au niveau de la string de version du serveur SSH… qui provoque la fermeture du tunnel pour emmerder un peu plus les petits malins (obligeant à utiliser stunnel du port 443 vers le 22 à la maison et proxytunnel avec l’option pour rajouter une couche de SSL par dessus le SSH)… mais pour avoir regardé ça avec wireshark afin de savoir ce qui serait visible des admins, ce connect était bavard et passait en clair.

    Bref, je pense que l’article ne repose pas sur des bases fiables et qu’une petite expérimentation le confirmerait.

    Ce qui ne veut pas dire que ce soit par ailleurs impossible… auquel cas les bunkers de Khadafi, qui contenaient du matos d’interception, pourraient avoir eu une valeur assez conséquente si ceux qui y sont rentrés parmi les premiers avaient les connaissances pour extraires les certificats qui auraient pu y être inclus :o)

    Ce qui serait une autre piste possible de fuite si des soupçons devaient vraiment se porter sur SSL: Il n’y a peut-être pas que qq centaines/milliers (on ne semble pas trop savoir) de Sam7 qui se sont perdus (AQMI?) lors de la chute de Khadafou et menacent désormais l’aviation civile mondiale?

Laisser un commentaire

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