Sécurité

26C3 – Conférence du CCC à Berlin (2)

… suite du suivi des présentations intéressantes du 26C3 (vues en vidéo par Internet, les commentaires de personnes qui sont effectivement à Berlin sont les bienvenus) :

Lundi

A noter que les vidéos officielles sont maintenant disponibles.

26C3 – Conférence du CCC à Berlin (1)

La 26ème conférence du Chaos Computer Club se tient cette semaine à Berlin, du 27 au 30 décembre 2009. En effet, cette association allemande organise depuis 1984 une conférence annuelle qui réunit plus de 2000 participants. Le caractère assez ouvert de cette événement permet à tout un chacun de voir en direct sur Internet les présentations qui ont lieu dans les différentes salles. Je vous propose un résumé de quelques présentations intéressantes auxquelles j’ai pu assister ainsi grâce à la magie d’Internet.

Le programme est accessible sur le Wiki de la conférence.

27 décembre 2009

Vous pouvez aussi visualiser les présentations sous forme de fichiers vidéo en téléchargement (lien temporaire pendant la conférence). La suite de mes impressions demain.

Un peu de son disque dans un PDF

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.

La vulnérabilité SSL/TLS démontrée sur Twitter

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.

Une faille dans le protocole SSLv3/TLSv1

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.

iHacked ! Attaque contre les iPhones jailbreakés

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.

De l’affaire Zataz et des sites d’information sur la sécurité en général

Grandville_-_Descente_dans_les_ateliers_de_la_libert%C3%A9_de_la_presse[1]

Cet article pour appeler mes lecteurs à lire un article qui donne un point de vue intéressant sur l’affaire Zataz, sur le blog de Sid, et en discuter quelques aspects complémentaires.

Pour mémoire : il s’agit dans cette affaire de plaintes successives (au civil puis pour diffamation) dont a été l’objet le gestionnaire du site Zataz suite à la publication d’un article révélant un incident de sécurité qu’aurait vécu une société de commerce en ligne. Comme beaucoup de sites d’information de sécurité, Zataz publie régulièrement des alertes sur de tels incidents, non sans avoir auparavant prévenu les gestionnaires concernés.

Cette mise en cause publique n’a apparemment pas été appréciée et Sid estime que c’est peut-être parce que la sécurisation des données personnelles des clients n’était – à un instant donné dans le passé – pas complètement assurée. La société plaignante aurait finalement déclaré qu’elle ne souhaitait pas faire appliquer les sanctions prononcées contre le journaliste.

La démonstration de Sid est détaillée et je vous invite donc à la lire. Par ailleurs vous pouvez aussi consulter:

  • L’arrêt de la Cour d’appel de Paris 2ème chambre Arrêt du 09 septembre 2009 (sur Legalis.net), où l’on découvre un débat d’experts, mais où manifestement ne transparaissent pas tous les éléments d’appréciation,
  • La présentation des faits sur le site Zataz.

Le débat sur les sites d’information de sécurité informatique

En préambule, je tiens à souligner que ce n’est pas la bonne foi d’un journaliste que je questionne – d’ailleurs le plaignant dans cette affaire semble finalement le reconnaître, mais bien de la situation juridique dont je cherche à débattre. On est en effet dans une situation d’insécurité juridique aussi bien pour les personnes qui cherchent à protéger leurs données, que celles qui souhaitent informer librement le public.

Sur la discussion juridique donc, le droit français ne prévoit pas (article 323-1 du code pénal) que des données doivent être protégées par un dispositif spécifique pour qu’il y ait accès frauduleux à un système de traitement automatisé de données (de la même façon, même si comparaison n’est pas raison, qu’il n’est nul besoin d’effraction pour que le vol soit reconnu, même si l’assurance ne couvre pas ces cas-là).

Toutefois, il faut que l’intention (comme pour toute infraction, son élément moral) soit prouvée, à savoir la conscience de pénétrer dans un serveur privé (comme lorsqu’on pousse la porte d’un appartement). Donc, soit en contournant une sécurité – même faible, soit en s’apercevant – par exemple – de la nature confidentielle des données. Et c’est justement ici que l’on trouve les limites de l’exercice des sites d’information sur la sécurité, puisque ce qui est cherché ce sont justement les failles et l’existence de données confidentielles non protégées: on peut légitimement supposer l’intention d’accéder à des secrets. Même si la motivation est honnête, l’intention d’un accès frauduleux (non autorisé ou non voulu par son propriétaire) sera donc le cas le plus courant.

Il revient ensuite évidemment à l’expert d’évaluer si le service qui a permis l’accès à ces données était :

  • librement offert à tout visiteur (notamment depuis le site Web de l’entreprise),
  • accessible uniquement en effectuant des recherches poussées (et dans ce cas-là si la personne mise en cause à volontairement ou involontairement trouvé ces données),
  • accessible uniquement en contournant un dispositif de sécurité.

Contrairement à la situation d’entreprises chargées par leurs clients de tester la sécurité de leurs serveurs, un journaliste ne peut se prévaloir dans ces circonstances d’une relation préalable avec l’entreprise testée et donc d’une présomption d’autorisation à accéder aux systèmes et à leurs données – souvent formalisée dans le contrat conclu entre les deux parties.

La loi n’a pas non plus prévu d’exemption générale pour les professionnels, comme ce serait le cas dans l’article 323-3-1 du code pénal en matière de possession d’outils de piratage par des spécialistes en sécurité informatique. Et le droit d’informer ne justifie pas de commettre des infractions.

Et pourtant, il paraît socialement utile, comme le souligne Sid, que le public soit informé de l’existence de défauts (de façon générale) dans la sécurisation des données personnelles qu’ils confient à des tiers.

Cette affaire donc, comme en son temps l’aventure très semblable vécue par un autre journaliste en ligne (Affaire kitetoa.com), démontre clairement la nécessité d’un débat sur les règles juridiques et déontologiques à appliquer aux sites d’information sur la sécurité informatique. Cela renvoie aussi au débat sur une obligation qui devrait bientôt peser sur les opérateurs de communications électronique de signaler les atteintes importantes aux données personnelles qu’ils administrent et que va introduire le Paquet télécom: faut-il généraliser ce principe à tous les professionnels ? Un événement tel que celui vécu par un grand intermédiaire financier américain en début d’année serait-il rendu public en Europe ou en tous cas ses clients informés ?

Des images utilisées pour commander des botnets

monkif-secureworksIl y a quelques jours, j’évoquais l’utilisation des groupes de discussion de Google pour diffuser les commandes d’un botnet. Les chercheurs de SecureWorks (CTU Counter Threat Unit) ont ainsi mis au jour un nouveau mode de distribution de ces ordres : l’utilisation d’images diffusées par des serveurs Web. C’est en observant le fonctionnement du botnet DIKhora/Monkif qu’ils ont pu faire ces observations. Il s’agit d’un cheval de Troie apparu apparemment assez récemment (08/2009) et encore peu documenté.

Cette méthode est particulièrement astucieuse, dans la mesure où elle sera le plus souvent indétectable pour les outils de filtrage des entreprises. En effet, quoi de plus banal sur un réseau que la visualisation d’images via une connexion HTTP. Ce type de canal caché n’est pas complétement nouveau dans sa conception, au sens où des images mouchards sont souvent utilisées pour permettre le décompte de visites sur des sites Web.

Mais ici, le procédé est encore plus astucieux : l’image téléchargée présente non seulement un nom de fichier caractéristique d’un JPEG, avec une extension en « .jpg », mais possède un en-tête  identique à ces images. L’en-tête d’un fichier est constitué – le plus souvent – par les premiers octets d’un fichier et constituent une sorte de signature  qui va indiquer au système d’exploitation ou au logiciel d’affichage à quel type de fichier il a affaire, et parfois quelle version du format de fichier est utilisée.

La technique (décrite aussi ici) est la juxtaposition de 32 octets typiques du début d’un fichier JPEG, suivis d’une commande pour les machines zombies embrouillées par un codage spécial (un XOR avec la valeur 4). Dans l’exemple cité, les concepteurs n’ont même pas pris la peine de rendre le fichier affichable. Mais sachant qu’une image JPEG peut contenir des commentaires (par exemple en utilisant le codage EXIF qui permet d’ajouter à une image des informations collectées pendant la prise de vue telle que la position GPS ou la marque de l’appareil photo), il est parfaitement imaginable de camoufler ces commandes de façon beaucoup plus difficile à détecter.

A suivre donc, et cela milite peut-être pour une évolution des pare-feux installés sur les réseaux des entreprises.

Un standard IETF pour la lutte contre les bots chez les FAI

ietflogotrans

Comme pour faire suite à l’article que j’ai publié hier, une information tombe à propos sur le site de SANS : l’IETF (Internet engineering task force), l’organisme qui anime la rédaction des standards de l’Internet, travaille depuis le mois de juillet 2009 sur un projet de standard de recommandations à destination des fournisseurs d’accès pour lutter contre la propagation de réseaux de machines zombies parmi leurs abonnés.

Un élément de plus à rajouter sur ce débat pour un rôle actif des FAI dans la lutte contre ces phénomènes criminels.

Attaque DDoS Twitter (suite)

En complément à mon billet d’hier sur l’attaque contre Twitter de la semaine passée, Arbor Networks en ferait une analyse intéressante tendant à indiquer qu’il ne s’agit effectivement que d’un événement de faible amplitude et qu’au même moment des attaques beaucoup plus importantes avaient lieu (contre un opérateur asiatique par exemple).

(Plus d’informations ici)

Cela confirmerait les inquiétudes sur la résistance de telles plateformes à des attaques de grande ampleur.