Cette "faille" de confidentialité a été révélée par un article sur le blog SecureThoughts.com. Et c'est assez simple en réalité.

Lorsque vous imprimez une page Web sous forme de fichier PDF, il est courant que l'application insère le nom du fichier imprimé en pied de page et par défaut il s'agira du chemin complet vers le fichier imprimé... Donc si vous avez sauvé localement une copie de la page Web ou construit sur votre disque dur la page Web en question, le chemin complet apparaîtra, révélant certaines informations sur votre arborescence, comme votre nom d'utilisateur local.

Il est d'ailleurs possible de configurer sous Internet Explorer le pied de page (Menu Fichier / Mise en page... / Pied de page, remplacer URL par - Vide - ou autre chose).

Ce qui pose problème est que lorsqu'on effectue cette impression depuis Internet Explorer 8 (et selon l'auteur pas depuis d'autres navigateurs), l'impression insère par défaut ce chemin complet vers le fichier imprimé à l'intérieur du code du fichier PDF, sans qu'il soit possible de modifier cet état de fait, et ce quel que soit le moteur d'impression PDF utilisé (Adobe, CutePDF, etc.). Ce serait d'ailleurs aussi le cas lorsque l'on invoque l'impression depuis l'explorateur de Windows.

L'auteur de cet article propose de chercher un certain nombre de ces fichiers dans votre moteur de recherches préféré en entrant comme mots clés: "filetype:pdf file c (htm OR html OR mhtml)" (puis d, e, etc. à la place de c). Outre des fichiers PDF qui arborent cette information dans le pied de chaque page, on trouve aussi des fichiers qui les abritent au sein du code PDF, à l'insu vraisemblablement de la personne qui a publié ce fichier.

Sous un angle criminalistique, ces métadonnées sont évidemment particulièrement intéressantes pour rapprocher une impression PDF d'un ordinateur. Sur le plan de la vie privée, avant de publier un PDF d'une page Web sur son site Web, on veillera à utiliser une autre configuration.

Twitter_Badge_1[1]Au début du mois de Novembre, une vulnérabilité touchant la fonction de re-négociation des protocoles de sécurisation SSL/TLS était rendue publique (et j'en avais déjà parlé ici). Cette semaine, une nouvelle démonstration de cette faille a été faite sur la plateforme Twitter. La société Twitter a déjà corrigé cette faille.

TLS-renegotiate[1]
Cliquer sur l'image pour aller vers l'article
D'abord, un pointeur vers un autre article qui décrit le principe de l'attaque découverte initialement par un joli schéma.

 

Beaucoup de spécialistes ont rapidement souligné que cette vulnérabilité ne devrait pas avoir d'application facile dans la vie réelle. Malheureusement il semble qu'il faille effectivement la prendre au sérieux. En effet, Anıl Kurmuş, jeune chercheur en sécurité Suisse, a rendu public une démonstration (il l'annonçait mercredi 11 novembre sur Full Disclosure) de la possibilité d'exploiter cette attaque sur Twitter.

Le principe sous-jacent est assez simple puisqu'il repose sur la fonctionnalité même de Twitter qui vise à laisser l'utilisateur publier n'importe quoi. Il a suffi à Anıl Kurmuş de détourner l'API (interface de programmation) de Twitter pour publier en lieu et place du message une partie du cookie, qui contient systématiquement le mot de passe codé, dans le cas de Twitter:

 

mitm
Démonstration d'Anil Kurnus

Il ne reste plus qu'à décoder l'identification qui est ici transmise en Base 64 (ou à la réutiliser telle qu'elle !). Twitter aurait depuis le 10 novembre corrigé la faille. On peut suivre l'évolution des publications des mises à jour des applications concernées par la faille de re-négociation SSL/TLS sur le site de Phonefactor, pour l'instant une version mise à jour d'OpenSSL 0.9.8l bloque déjà la fonction de re-négociation, en attendant un correctif plus pointu.

droitoubli3Sciences Po. Paris accueillait ce matin, 12 novembre 2009, un atelier organisé à l’initiative de Madame Nathalie KOSCIUSKO-MORIZET, secrétaire d’État chargée de la prospective et du développement de l’économie numérique. Portant sur le « Droit à l’oubli numérique », l’atelier était organisé en deux tables rondes abordant successivement l’oubli des traces et l’oubli des données publiées volontairement.

Présidé par la secrétaire d’État, le débat était animé par Bernard BENHAMOU, délégué aux usages de l’Internet. Alex TÜRK, président de la CNIL et sénateur du Nord était chargé de quelques mots en ouverture, tandis que Daniel LE METAYER (INRIA) a fait une rapide présentation sur les méthodes de préservation de la vie privée.

On saluera au passage la présence de parlementaires aux tables rondes (le député Patrice MARTIN-LALANDE et le sénateur Yves DÉTRAIGNE) ou dans la salle (Lionel TARDY, son blog-compte-rendu).

Dans son préambule, la ministre a rappelé la création d’un hashtag #oubli sur Twitter pour ceux qui souhaitent échanger par ce moyen.

Introduction par Alex TÜRK

Le président de la CNIL a rappelé que le droit à l’oubli était en réalité une préoccupation permanente de la commission, car effectivement à la base des règles de gestion des données personnelles au travers de la durée de conservation de ces données et du droit d’opposition. Il propose ensuite de remplacer l’attitude trop généralement rencontrée du "je n’ai rien à me reprocher", donc "ça ne m’embête pas que toutes ces données soient disponibles à mon sujet" (sous-entendu sur les réseaux sociaux et Internet en général) par le souci de son intimité, considéré comme une liberté fondamentale (consacrée par ailleurs dans le code pénal aux articles 226-1 et suivants). Enfin, M. TÜRK offre une première conclusion en faveur d’un gouvernement transparents et de citoyens non-transparents. Baudelaire faisait ainsi référence au "droit de se contredire et de s’en aller".

L’oubli des traces

Cette première table ronde rassemblait des avocats et juristes, ainsi que des professionnels de l’Internet, dont la présence notable de Peter FLEISCHER (son blog), responsable de la protection des données personnelles chez Google.
On a ainsi pu noter au travers des annonces faites par Google et Microsoft une évolution des pratiques professionnelles vers une plus grande transparence (comme le Dashboard de Google) ou le souci de la protection de la vie privée dès la conception des outils (comme les PETs mis en œuvre notamment par Microsoft). En forme de conclusion, le député Patrice MARTIN-LALANDE appelle les acteurs professionnels à investir une partie de leurs bénéfices dans l'innovation permettant une meilleure gestion par les individus de leurs traces.

L'oubli des données publiées volontairement

Cette deuxième table ronde a notamment permis d'entendre, par la voix d'Alain GAVAND, la position des professionnels du recrutement. Ainsi, l'association A compétence égale publie une charte réseaux sociaux, Internet, vie privée et recrutement. Parmi les professionnels présents à la table ronde, le représentant de Skyblogs, Jérôme AGUESSE a dû reconnaître leur impuissance face au phénomène des dédipix, ces images non pornographiques mais parfois très intimes publiées par leurs usagers. Enfin, Valérie SÉDALLIAN, avocate, a témoigné d'une affaire qu'elle a eue à traiter qui démontrait la difficulté de protéger les internautes des données publiées sur des plateformes hébergées pour l'essentiel en dehors des juridictions européennes et le sénateur Yves DÉTRAIGNE a d'ailleurs regretté l'impuissance du législateur à faire évoluer ce problème.

Conclusion par Madame Nathalie KOSCIUSKO-MORIZET

Le mot de la fin est revenu à la présidente de cet atelier. Ainsi, a-t-elle souligné qu'on n'avait pas eu suffisamment le temps d'évoquer les cas des données qui échappent totalement au contrôle de l'individu: les données personnelles qui le concernent et qui sont publiées par d'autres personnes ou celles que l'on peut reconstituer (elle a notamment évoqué une étude du MIT qui démontre la possibilité de deviner l'orientation sexuelle d'une personne à partir de sa liste d'amis sur Facebook).

La secrétaire d'État appelle à poursuivre les débats sur Twitter, mais aussi sur le futur site du Secrétariat d'État qui sera lancé le 25 novembre 2009. Elle souhaite que les débats sur la gouvernance de l'Internet deviennent plus institutionnels et propose enfin que la discussion sur le droit à l'oubli puisse permettre de commencer à discuter d'harmonisation mondiale des pratiques de protection des données personnelles.

Commentaires personnels

L'écoute attentive de ces ateliers m'amène quelques réflexions. D'abord, il ne faut pas oublier qu'une partie du débat en matière de traces et d'oubli porte sur l'obligation qui doit être faite aux acteurs techniques de conserver les données permettant d'identifier les auteurs de contenus diffusés sur Internet ou l'utilisateur d'une adresse IP. Ainsi, le droit à l'oubli ne doit pas faire oublier le devoir de responsabilité individuelle de ses actes et le droit fondamental à la sûreté.

Sur le débat de l'application du droit français à des sites hébergés à l'étranger, il faut d'abord rappeler que le droit pénal français s'applique dès lors que l'un des faits constitutifs de l'infraction a lieu sur le territoire de la République française (article 113-2 du code pénal) et la jurisprudence a régulièrement retenu le fait qu'un site Internet puisse être visible depuis la France et concerne directement des citoyens français peut constituer un élément de cette infraction. Ensuite, l'article 113-7 prévoit très clairement que "la loi pénale française est applicable à tout crime, ainsi qu'à tout délit puni d'emprisonnement, commis par un Français ou par un étranger hors du territoire de la République lorsque la victime est de nationalité française au moment de l'infraction."

Donc dans les cas où la victime est de nationalité française et en matière pénale, les outils existent bien et il nous revient de les faire appliquer, y compris contre des entreprises situées à l'étranger. Ce sera le cas pour des infractions de presse punies par une peine de prison, telles que les propos appelant à la violence en raison de la race, des pratiques sexuelles ou du handicap.

Le débat subsiste en matière civile, mais dans l'affaire AAARGH le juge s'était bien estimé compétent.

Enfin, Guillaume Desgens-Pasanau publie une tribune sur ce sujet d'actualité sur le blog de notre ouvrage.

1

Une faille des protocoles SSL/TLS qui assurent notamment la sécurité des connexions vers les serveurs web (lorsque l'adresse est en https://) a été révélée hier. (click here if you want an automated translation to English)

Histoire récente de la découverte de la faille

Marsh Ray annonce sur son blog qu'il aurait découvert cette faille lors de travaux pour sa société Phonefactor. Les premiers cercles ont été informés de cette découverte au début septembre 2009 et une réunion s'est tenue le 29 septembre 2009 à Mountainview, CA. Nom de code utilisé par le groupe qui s'est donné pour mission de corriger cette faille: "Project Mogul".

Hier, 4 novembre 2009, Martin Rex (SAP) a présenté publiquement sur la liste de discussion TLS de l'IETF une idée approchante et depuis l'annonce à commencé à faire le tour des blogs et autres twitts.

Description de la faille

La faille porte sur les phases de re-négociation entre le client et le serveur.

Les étapes du dialogue TLS (entre un client et un serveur):

  • Le client dit bonjour et indique les technologies de chiffrement acceptées,
  • Le serveur répond et précise quelle technologie de chiffrement il préfère, il joint un certificat de chiffrement et indique qu'il a fini la phase de premier contact,
  • Le client calcule une clé de chiffrement, la transmet de façon sécurisée grâce au certificat fourni par le serveur et lance une commande Change Cipher Spec pour activer le chiffrement,
  • A partir de ce moment tous les messages échangés sont chiffrés.

Le protocole permet à chacune des parties à l'échange de demander une re-négociation à n'importe quel moment.

Les scénarios d'attaque décrits par Marsh sont les suivants:

  1. Lors de l'authentification des clients sur la base de certificats,
  2. Lorsque le serveur nécessite plusieurs technologies de chiffrement,
  3. Lors d'une re-négociation initiée par le client (fonctionne sur des serveurs Apache).

Dans tous les cas, il s'agit pour l'attaquant placé en "man in the middle" d'insérer des commandes au début du dialogue (donc avant le chiffrement) qui seront rejouées au moment de la re-négociation. Et cela même si la re-négociation passe dans le canal chiffré.  Ainsi, si le texte inséré au début est fabriqué de façon intelligente, il permet d'imaginer différentes solutions pour contourner le chiffrement (dans les exemples donnés, il s'agit d'insérer une commande de chargement d'une page web malicieuse et une commande pour ignorer ce qui suit, c'est-à-dire la requête normale du client).

marsh-exemple
Code inséré

Et maintenant ?

Il aurait été démontré qu'aussi bien Apache qu'IIS de Microsoft étaient sensibles selon les cas à ces attaques. Il n'est pas certain que toutes les situations aient été explorées. Même si un tel mécanisme est très complexe à mettre en œuvre en pratique (les attaques de type man in the middle sont complexes) et suppose un certain nombre d'hypothèses, il démontre que les protocoles de sécurisation ne sont pas suffisamment intégrés avec les protocoles applicatifs tels qu'HTTP. Marsh décrit aussi dans son papier un scénario hypothétique où il serait possible d'obtenir des informations confidentielles sans que le client se connecte volontairement au site web objet de l'attaque.

Il existe encore un débat pour savoir si des utilisateurs de sites Web simples (donc sans authentification du client par un certificat) sont concernés, Marsh affirme que c'est bien le cas.

Très rapidement des propositions devraient être faites par l'IETF pour des modifications au protocole TLS et des mises à jour de GNU TLS et OpenSSL sont en cours de validation. Des annonces plus rapides que prévu sont donc à venir.

2

Rien dans l'actualité n'avait attiré mon attention depuis quelques semaines, mais l'incident survenu cette semaine aux propriétaires d'iPhones "jailbreakés" de l'opérateur T-Mobile aux Pays-Bas mérite qu'on s'y arrête un instant.

Le Jailbreak ?

Le "jailbreak" est la technique qui consiste à modifier le système d'exploitation des iPhone pour pouvoir y installer des applications qui n'ont pas été validées par Apple, accéder par une connexion SSH (donc normalement sécurisée) au contenu plus intime de son téléphone et partager son contenu tel un disque dur externe (ce que ne permet pas normalement l'iPhone). Ces manipulations sont aussi possibles sur les iPod Touch.

L'attaque

Ainsi, un pirate audacieux a scanné les adresses IP publiques des abonnés de T-Mobile aux Pays-Bas pour y détecter des iPhones jailbreakés. Malheureusement ces téléphones ont tous le même mot de passe pour deux comptes, le compte root (littéralement "racine", compte présent sur tous les systèmes de type Unix et qui dispose normalement de tous les droits d'administration sur le système) ainsi que le compte mobile. Cela lui a donc permis de prendre le contrôle de la plupart de ces téléphones et d'en changer le fond d'écran:

Ecran de l'iPhone après la prise de contrôle

Dans un premier temps, le pirate invitait ses visiteurs à lui payer la somme de 5 € sur son compte Paypal pour apprendre comment le débloquer, en leur expliquant notamment qu'il pouvait se servir de leur téléphone pour passer des appels téléphoniques à leur frais et fouiller dans leur vie privée.

Assez rapidement, l'auteur de cette plaisanterie s'est engagé à rembourser ses victimes et a fourni gratuitement les explications permettant de rétablir un semblant de sécurité sur les téléphones.

En résumé, les étapes de cette attaque:

  • scan de l'ensemble des IP potentielles d'abonnés de T-mobile, à la recherche de réponses sur le port TCP caractéristique des iPhone
  • test de la disponibilité du port TCP SSH (le port 22, ouvert uniquement sur les portables "jailbreakés") et des mots de passe par défaut pour les comptes root et mobile
  • modification du fond d'écran.

Cette attaque avait été expliquée dès le mois de juillet 2008 sur un forum néerlandais dédié à la sécurité (et par Dancho Danchev aussi). Elle fonctionnera aussi contre des iPhone connectés en Wifi ou des iPod Touch connectés sur un point d'accès Wifi (lorsqu'ils sont jailbreakés). Bien évidemment tenter ce genre de choses est répréhensible, et constituerait un accès frauduleux dans un système de traitement automatisé de données puni d'au moins deux ans d'emprisonnement et 30.000 € d'amende en France (article 323-1 du code pénal). J'en profite pour rappeler d'ailleurs que la tentative de tels faits est effectivement interdite en France (article 323-7 du code pénal), donc par exemple, le scan du port caractéristique des iPhone évoqué plus haut sur des réseaux où des téléphones mobiles sont susceptibles d'être connectés constituerait un acte matériel de commencement d'exécution...

Quelques leçons de cette affaire

  • On dirait que la société Apple a raison lorsqu'elle déclare qu'il est dangereux de jailbreaker son téléphone...
  • L'utilisation de téléphones constamment connectés sur les réseaux de 3ème génération n'est pas sans risque (en France, les réseaux des trois opérateurs ne permettent pas actuellement l'accès depuis l'extérieur), mais attention lorsque vous êtes en roaming dans d'autres pays. Les opérateurs devront-ils installer des pare-feu sur leurs réseaux pour protéger leurs abonnés ?
  • Cela va devenir de plus en plus complexe d'assurer la sécurité sur son téléphone portable: il va falloir installer un logiciel pare-feu, un antivirus, savoir l'administrer et mettre un mot de passe "root",... ce n'est pas forcément à la portée de tous les usagers.