Comment perdre son anonymité — 03 Jan 2003

.. en consultant son courrier électronique

Il a été beaucoup question récemment (NdA: mars 2000) de la perte de confidentialité à travers l'utilisation de balises particulières dans des messages électroniques (web, courriel ou news), notamment depuis la mise en garde du CERT au début du mois de février dernier (<http://www.cert.org/advisories/CA-2000-02.html>). La mise en garde concernait l'inclusion de code HTML, ou de scripts, d'origine non vérifiée dans une page web générée dynamiquement, ou dans un message électronique.

La plupart des navigateurs web, ainsi que les dernières versions des programmes de courrier électronique ou de consultation de news (forum de discussion) sont capables d'interpréter des scripts inclus dans les pages qu'ils chargent. En fait, la plupart des programmes sont réglés pour le faire par défaut.

La presse traditionnelle et électronique fait l'écho de nombreuses attaques et violations de la confidentialité lors de transactions en ligne, ou d'envois de messages « minés » (contenant du code qui permet d'accéder à des informations confidentielles si le destinataire répond au message en question des Chevaux de Troie).

Mais n'ajoutons pas à la paranoïa ambiante, et analysons quelques menaces réelles.

Dissimuler du code HTML dans un courriel

La plupart des navigateurs web indiquent la présence d'un lien par une surbrillance, une couleur différente ou en soulignant les quelques mots qui le composent. La portion du code HTML qui compose le lien est dissimulé des yeux de l'internaute. Les dernières versions des programmes de courriel en font de même.

La plupart du temps, il ne s'agit pas d'un bogue, mais d'une fonctionnalité (« It's not a bug, it's a feature!»). Ceux qui ont eu l'occasion de voir du code HTML, conviendront que ce n'est pas très parlant de prime abord. La plupart des utilisateurs de courrier électronique n'ont ni l'expertise, ni le temps, et ni l'envie d'analyser chaque portion de code HTML qu'ils reçoivent par courriel. Malheureusement, cela peut représenter pour une personne mal intentionnée (typiquement un « spammer ») une porte dérobée sur votre confidentialité.

Prenons comme exemple un message électronique non sollicité (« spam ») provenant d'un site peu recommandable qui contiendrait le code HTML suivant :

<a href="http://www.histoiresdeq.com">www.histoiresdeq.com</a>

Pas de problème pour l'instant: www.histoiresdeq.com n'est rien d'autre qu'un site web, et je ne me compromettrais pas plus mon anonymité en visitant celui-ci qu'un autre. Lors d'une visite (lorsque vous cliquez sur un lien), la plupart des sites web n'enregistrent que votre numéro IP (l'adresse de votre ordinateur), et éventuellement votre nom de domaine (unige.ch ou swissonline.ch par exemple), et la signature du navigateur que vous utilisez (Internet Explorer ou Netscape, sur Macintosh, Windows, Linux, etc.), en plus de la ressource requise (page HTML, image, etc.). Ces informations sont disponibles si vous désirez les voir de plus près. Aucune de ces informations ne peut être utilisée pour m'envoyer plus de spams, ou pour avoir accès à mon identité.

Malheureusement, ces URLs peuvent contenir d'autres éléments, dont des paramètres qui peuvent être renvoyés au site :

<a href="http://www.histoiresdeq.com?u=foo@bar.com">www.histoiresdeq.com</a>

Si je clique sur le lien et visite le site, mon adresse de courrier électronique foo@bar.com est susceptible d'être ajoutée à une liste de clients potentiels. Bien entendu, l'administrateur du site en question qui m'a fait parvenir le message connaissait déjà mon adresse, mais il ne savait pas si je pourrais être un client éventuel. Maintenant, il le sait.

Il y a pire. Si j'utilise un navigateur web pour gérer mon courrier électronique, le seul fait d'ouvrir un message peut suffire à provoquer une perte de confidentialité. La plupart des navigateurs sont capables de décorer un message électronique avec des images (parfois invisibles), qu'ils rapatrient lorsque le message est ouvert. Le spammer est libre d'inclure dans une balise IMG mon adresse électronique sous la forme d'un paramètre :

<img src="http://www.histoiresdeq.com/xxx.jpg?u=foo@bar.com">

Dès que vous ouvrez votre message, votre programme de courrier électronique va lancer une requête à www.histoiredeq.com pour l'image xxx.jpg?u=foo@bar.com afin de correctement rendre votre message, et cette requête sera répertoriée dans le fichier log du site en question (avec votre adresse de courriel).

Tu veux un cookie ?

Le spammer sait donc que j'ai ouvert son message - et ce n'est pas le pire. Le site en question peut également renvoyer un cookie à mon navigateur contenant de manière codée mon adresse électronique. Cela signifie que la prochaine visite que je ferais à son site (ou a un site qui collabore avec lui, ils sont rarement isolés), pourra être enregistrée et indexée à mon adresse de courriel.

En bref, mon anonymité aura été sévèrement compromise par mon logiciel de navigation ou de courrier électronique, sans que je le sache et sans que je l'autorise. Pour plus d'information sur ce genre d'attaque, veuillez vous référer aux publications du Electronic Frontier Foundation. ou à l'article de Richard Smith (« The Cookie Leak Security Hole in HTML Email messages »).

Variations sur le même thème

Ce type d'attaque peut prendre plusieurs formes. Il est possible d'éliminer l'utilisation de paramètres par exemple. Imaginons que la requête pour une image soit de la forme :

<img src="http://www.histoiresdeq.com/blonds/l_tabata_r.jpg">

Ce code semble plutôt inoffensif à première vue, mais il ne l'est peut-être pas. Dans un des scénarios possibles, le spammer peut générer un URL unique pour chaque adresse de courrier électronique qu'il utilise dans ses publipostages, en appondant des noms au hasard (marlene, tabata, etc.) avec des lettres de l'alphabet (r, s, t, etc.) lors de l'envoi de son publipostage, le spammer enregistre les combinaisons noms-lettres avec l'adresse de courrier électronique du destinataire dans une base de données.

Lorsque qu'une requête pour l'image en question intervient, un script sur le serveur peut enregistrer l'évenement et renvoyer un cookie au navigateur, et nous nous retrouvons dans le cas précédent.

<a href="http://www.histoiresdeq.com/blonds/l_tabata_r.html">...</a>

Si je suis suffisemement inconscient ou mal informé pour cliquer sur des URLs inconnus, la même logique s'applique, et sans que le spammer ne doive recourir à du code HTML dissimulé.

Bienvenue à SpamLand ..

Conclusions

Une morale de cette histoire pourrait être que les Chevaux de Troie peuvent prendre plusieurs formes, et qu'on ne devrait pas prendre pour argent comptant n'importe quelle offre d'un (site) inconnu, même si elle semble inoffensive.

Une morale alternative est que nos navigateurs et programmes de courriel qui regonfle de nouvelles fonctionnalités en agrégeant des morceaux d'applicatifs (comme la navigation sur le web et le courrier électronique par exemple) peuvent générer d'inattendues failles dans leur sécurité. Pour ne nommer personne, Microsoft est un des acteurs principaux dans ce domaine, mais Netscape et d'autres ont contribués à cette situation.

Le fait d'avoir inclus des macros (du code interprétable) dans les traitements de texte, et autres logiciels, est une bonne idée à la base, mais c'est également la porte ouverte aux abus. Il n'y a qu'à consulter le nombre de nouveaux macrovirus Word ou Excel qui est répertorié par mois pour se rendre compte de l'étendue du problème (<McAfee Virus Central>).

Il n'existe pas de solution miracle à ce problème, mais certaines règles de comportement peuvent contrevenir à la grande majorité des tentatives d'attaque. Soyez conservateur dans votre utilisation de logiciels de courriel hautement intégrés comme Microsoft OutLook par exemple. Ils sont trop accommodants pour les spammeurs. Désactivez les options automatiques de votre logiciel, particulièrement celles qui invoquent automatiquement le traitement de l'information par un logiciel tiers, ou l'exécution automatique de scripts. Le jour où les fabricants de logiciels intégreront davantage de sécurité dans leurs produits, les risques commenceront réellement à diminuer.

Pour en savoir plus..

• CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requestshttp://www.cert.org/advisories/CA-2000-02.html
• Read an e-mail, loose your privacy -- Rich Morinhttp://cnn.com/2000/TECH/computing/01/14/email.privacy.idg/index.html
• HTML Code causes 100% CPU Usage -- NT Securityhttp://www.ntsecurity.net/go/loader.asp?iD=/security/ie514.htm
• Electronic Frontier Foundation press releasehttp://www.eff.org/pub/Privacy/Profiling/19991202_joint_profiling_pressrel.html
• The Cookie Leak Security Hole in HTML Email messages -- Richard M. Smithhttp://www.tiac.net/users/smiths/privacy/cookleak.htm
• The Transparent SocietyDe David Brin (.co.uk) (.de)

Rédigé par davo39 le mars 20, 2000 02:59 PM | Cité

Le Checkbox - version weblog

Le Checkbox est relancé sous une nouvelle formule: les articles seront moins long, mais plus fréquents (hum), et organisés sous la forme d'un weblog, ou blog.

Les articles originaux et les souscriptions électroniques sont maintenus. Un index des articles en format XML est également à votre disposition pour ceux qui aimerait offrir des liens depuis leur site.

En espérant que cette nouvelle formule soit plus riche, et plus régulière, je vous souhaite une excellente nouvelle année 03.

// david roessli