Journal d'investigation en ligne et d'information‑hacking
Édito
par Rédaction

#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.

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](http://%20www.bluecoat.co.jp/downloads/manuals/SGOSVol8AccLog5.3.1.pdf), 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"](https://%20www.eff.org/deeplinks/2011/05/syrian-man-middle-against-facebook) visant les utilisateurs syriens. L'alerte a été donnée par un blogger syrien. Les certificats SSL de Facebook [ont étés modifiés](https://%20twitpic.com/4terpo). 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_TUNNELED Celle-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 ?

 

0 Commentaires
Une info, un document ? Contactez-nous de façon sécurisée