#OpSyria : BlueCoat maître artisan de la censure syrienne

Le pays de Mickey est, comme la France, très en pointe sur les technologies de filtrage d'Internet. Mais comme ces technologies sont interdites dans la majeure partie des démocraties (en France, le code des Postes et Télécommunications est formel) et qu'il faut bien trouver des débouchés commerciaux aux outils de la censure, il n'est pas rare qu'on vende deux ou trois machins à de bons gros dictateurs assumés... <subliminal> à l'image de ce grand patron français qui, le 13 février dernier, se trouvait à Tripoli pour vendre à l'ami Kadhafi un système d'écoute "Nation Wide" et un NAS assez conséquent pour mettre en cache tout Google</subliminal>

Ceci nous dérange. Et ça nous dérange encore plus quand le dictateur en question envoie les snipers et autres chars d'assaut tirer sur sa propre population.

Avec l'aide de nos amis de Telecomix et le soutien d'activistes plus ou moins affiliés à Anonymous, nous vous livrons aujourd'hui de nouveaux éléments sur l'implication de BlueCoat dans la mise en place des outils de censure et de répression de la Syrie.

Nous avons étudié le fonctionnement de la censure syrienne un peu plus en détail. Nous soupçonnons l'utilisation de deux technologies. La première est assez simple, relativement efficace (mais tout à fait contournable) : le proxy filtrant.

La seconde, bien plus vicieuse et que l'on ne vous présente même plus sur Reflets, c'est le Deep Packet Inspection (inspection en profondeur des paquets), capable de labelliser du trafic Internet afin d'en déterminer une règle de routage, de blocage, ou d'interception de la communication. Le DPI c'est avant tout une spécialité bien française, mais les américains ne sont pas en reste. Il faut dire que le marché, avant le printemps arabe, semblait particulièrement porteur... il l'est un peu moins maintenant et tout ça va quand même finir par se voir.

Nos amis de BlueCoat, qui sont aujourd'hui à l'honneur, disposent d'une large gamme d'outils de censure du Net, toujours présentés comme des outils bienveillants destinés à protéger nos enfants des pédonazis du Net, ou à préserver votre Windows d'attaques virales. Accessoirement, dans certaines dictatures, le DPI, ça peut aussi servir à éradiquer toute forme d'opposition ou à contrôler de manière massive des flux informationnels... mais ça, évidemment, on ne le trouve pas dans des plaquettes commerciales... peut être dans quelques white papers "confidentiels" comme sur celui de Qosmos qui nous explique les vertus du DPI pour un état.

Quelques tests menés directement depuis la Syrie nous ont permis de mettre en lumière l'utilisation de proxys filtrants et certainement d'outils de Deep Packet Inspection par le gouvernement Syrien grâce aux technologies américaines fabriquées par la firme BlueCoat.

Voici les tests qui ont été effectués et qui ont permis de dévoiler les systèmes de censure et de surveillance syriens. Nous essayons ici de vous en donner les principaux résultats, en décrivant la procédure que nous avons suivie et ce que nous avons observé.

Nous avions à notre disposition une machine serveur, que l'on appellera machine "S", située dans un pays « suffisamment démocratique » pour que l'ensemble des requêtes lui parviennent non altérées (de son côté, du moins), qu'elle soient effectuées en TCP, en UDP, et quel que soit leur contenu.

Considérons également deux machines situées sur le territoire syrien, connectées avec un ADSL classique et utilisant deux FAI différents :

• La machine "A", utilisant le FAI majoritaire en Syrie : Tarassul, dont tout le trafic est redirigé vers les passerelles de l'opérateur national dont il dépend, à savoir le Syrian Telecommunications Establishment (STE), contrôlé directement par le gouvernement - tranche IP : 31.9.*.
• La machine "B", utilisant le FAI Syrian Computer Society (SCS), institution publique dont le Président Bachar el-Assad est à la tête (source) - tranche IP : 77.44.*.

En premier lieu, des tests de connexions depuis "A" vers "S" ont été effectués, voici un résumé des résultats :

• Connexion vers le port TCP 5060 (utilisé pour le protocol SIP - nous voulions tester des solutions de VoIP sécurisées) : le port est bloqué (timeout du côté du client, et aucune requête de connexion n'arrive au serveur).
• connexion vers le port TCP 443 (comme tout le monde le sait, normalement utilisé pour le trafic HTTP sécurisé) : "S" voit arriver une connexion depuis l'IP de "A", et le trafic semble passer dans les deux sens sans problème.
• Le cas du port 80 est très certainement le plus intéressant. Nous avons tout d'abord tenté une simple connexion TCP par Telnet en envoyant des données aléatoires : "S" ne reçoit aucune requête de connexion, pourtant du côté de la machine client "A", la connexion semble avoir été ouverte, mais rien ne se passe, les données semblent partir dans le vide. Nous avons ensuite tenté d'utiliser le port 80 de façon traditionnelle, à savoir en faisant une requête HTTP avec un navigateur Web standard sur la machine "A". Résultat : le serveur "S" reçoit bien une tentative de connexion, mais qui ne vient pas de "A". Elle provient d'une IP qui n'est d'ailleurs même pas dans la même tranche, à savoir 82.137.200.56. Une recherche rapide nous montre que... Tiens, c'est une tranche IP appartenant au Syrian Telecommunications Establishment... En outre, certaines lignes attirent notre attention dans la requête reçue par "S" :

  X-Forwarded-For: 31.9.... (IP de "A")

  X-BlueCoat-Via: 2C044BEC00210EB6

Bon, cela se passe de commentaire. La requête a été redirigée vers un équipement BlueCoat qui nous l'a ensuite forwardée, et "A" n'est au courant de rien. Rien à dire de plus. Ah, si, le modèle de l'équipement : BlueCoat Proxy SG-9000.

Qu'en est-il de la Syrian Computer Society ? Voici les résultats des tests effectués depuis la machine "B", toujours en direction de "S" :

• Nous avons tenté à nouveau la connexion vers les ports 5060 et 5061 (ce dernier étant utilisé pour le SIP sécurisé) : même résultat que pour "A".
• Port 443 : comme pour "A", le trafic semble passer dans les deux sens, le serveur reçoit une connexion qui provient bien de l'IP de "B". D'autres ports classiques comme le 6667 ou 6697 passent également sans problème.
• Une fois de plus, le cas du port 80 est le plus intéressant. Même premier test : connexion de "B" vers "S" puis envoi de données aléatoires avec Telnet. Résultat, une page d'erreur HTML « Bad Request » du côté de "B", et rien ne se passe du côté de "S". Même second test : une requête HTTP quelconque avec un navigateur standard, et résultat similaire : "S" reçoit la connexion mais elle ne vient pas de l'IP de "B", mais de 213.178.244.16, une IP d'une tranche différente de celle de "B" donc, mais qui appartient bien à la SCS. En outre, ici aussi, deux lignes sortent du lot dans la requête HTTP :

  X-Forwarded-For: 77.44.... (IP de "B")

  X-BlueCoat-Via: E4007B080BF520E6

Il faut dire que ce coup-ci on s'y attendait un peu. Comme précédemment, du point de vue du client, rien ne permet de savoir que notre requête a été redirigée vers un proxy. Une petite différence tout de même, puisque le modèle de cet équipement est un BlueCoat SG-400. Nous avons effectué en outre un troisième test, et fait une requête HTTP pour la page "/proxy.html" depuis "B", toujours vers "S". Résultat : rien n'arrive à "S", et "B" se voit retourner une belle page HTML spécifiant que la page demandée est indisponible. Bon, évidemment, le mot "proxy" dans la requête n'avait pas été choisi au hasard... Le résultat ne fut donc qu'une demi-surprise, mais confirme bien le filtrage de certaines URL.

Pour synthétiser, tirons quelques conclusions de ces observations. Concernant la politique de blocage et d'observation, il est clair que le gouvernement syrien a compris que la vaste majorité du trafic se passe sur le Web, i.e. par le port 80. Et la plupart des syriens n'ont pas le réflexe d'utiliser le HTTPS (port 443). De toutes façons, il existe pléthore de sites qui ne fournissent pas d'accès sécurisé. Voici donc une façon simple et efficace de récupérer des logins et mots de passe par milliers et d'aller fouiller dans les boîtes mails à volonté. Nous avons vu également que le port 5060, utilisé pour la VoIP sur le protocol SIP, est bloqué. Et nous savons que Skype est utilisé de façon très large en Syrie. Le gouvernement aurait-il donc intérêt à ce que les gens continuent d'utiliser Skype en les empêchant de se servir de moyens alternatifs mieux sécurisés ? Le blocage sélectif des ports 5060 et 5061 rend cette perspective crédible, et par la même occasion, permet de se demander s'il existe une coopération quelconque entre Skype et le gouvernement syrien pour collecter les données personnelles des utilisateurs. Il convient toutefois d'envisager également que les blocages sélectifs de ports pourraient très bien être le fruit d'une configuration "par défaut" des équipements installés tel quels par les autorités. Éventualité également possible au vu des failles de sécurité béantes que nous avons croisées sur notre chemin et qui semblent indiquer une certaine précipitation (ou incompétence) dans l'installation des matériels.

Techniquement parlant, nous avons observé tout d'abord que le routage du trafic des clients ADSL se faisait en fonction du port TCP demandé. Si le port est différent de 80 et qu'il n'est pas bloqué, la requête parvient directement au serveur. Si c'est le port 80 qui est demandé, elle est redirigée vers un proxy BlueCoat sans que le client ne s'en aperçoive. Ensuite, l'équipement BlueCoat se charge de lire la requête et d'éventuellement la transmettre, si celle-ci ne contient pas de mot-clé interdit ou ne tente pas d'accéder à un site Web proscrit. Dans tous les cas, l'action de l'utilisateur est loggée (à son insu, bien entendu), nous en avions brièvement parlé dans un article précédent. En bref, le trafic est potentiellement observé et modifié à deux niveaux : selon les données du protocol IP (numéro du port demandé), puis selon les données du protocol HTTP.

DPI ou pas DPI ?

La nature même d'un équipement de Deep packet Inspection n'autorise pas sa détection. Ces derniers, connectés en Ethernet au "cul du tuyau" national, ne sont pas visibles depuis l'extérieur. SI nous n'avons pas de certitude quant à leur présence effective, nous soupçonnons pourtant la présence d'un mécanisme capable d'analyser le trafic à la volée, de taguer (labelliser) ce trafic, afin d'y appliquer des règles de routage, de blocage, d'archivage... le tout joyeusement réencapsulé grâce à la magie du protocole MPLS. Un simple proxy filtrant n'ayant à notre connaissance pas ce type de supers pouvoirs, nous en déduisons bien la présence d'outils d'analyse en profondeur de paquets.

BlueCoat responsable ou coupable ?

Nous n'avons à ce jour aucune preuve formelle que BlueCoat a directement vendu ces équipements au régime syrien. La nature même de ce type de marché révèle la présence d'intégrateurs de technologies de fabricants. BlueCoat est à la fois fabricant et intégrateur mais ses technologies sont fort probablement intégrées par d'autres entités, clientes de BlueCoat. Cependant, ce type de marchés inclue généralement des volants de maintenance, de formation qui ne peuvent échapper à la sagacité du fournisseur de technologie impliquée.

Nous sommes en 2011, les Etats et des sociétés privées vous protègent ... ayez confiance.