Objet: Bulletin d'actualité 2007-44

1 Rappel : vulnérabilités sur OpenSSL

Le CERTA rappelle que l'application OpenSSL a été récemment touchée par trois vulnérabilités importantes :

• la première faille concerne la fonction BN_from_montgomery qui n'implante pas correctement l'algorithme de multiplication de Montgomery dans les versions 0.9.8e et antérieures. Ceci permet à une personne malveillante de reconstruire la clé secrète utilisée ;
• la deuxième vulnérabilité est un débordement de mémoire dans la fonction SSL_get_shared_ciphers dans les versions d'OpenSSL antérieures à 0.9.8f. Un attaquant pourrait exploiter cette vulnérabilité en envoyant un paquet spécialement conçu et ainsi exécuter du code arbitraire à distance ;
• la dernière faille concerne l'implémentation de DTLS dans les versions d'OpenSSL antérieures à 0.9.8f et permettrait également l'exécution de code arbitraire à distance via des vecteurs inconnus.

Ces vulnérabilités ont été détaillées dans l'avis CERTA-2007-AVI-423. Le déploiement massif de cette application et le risque critique de ces trois vulnérabilités en font des cibles de choix pour des attaquants (potentiels). Le CERTA recommande donc la mise à jour sans tarder de l'application OpenSSL, la dernière version étant 0.9.8g (publiée le 19 octobre 2007).

6.4 Documentation

• Avis de sécurité CERTA-2007-AVI-423 du 04 octobre 2007 :

  http://www.certa.ssi.gouv.fr/site/CERTA-2007-AVI-423/index.html
  

2 La magie des nombres

2.1 Le cas Storm Worm

Le thème du réseau de machines zombie compromises par le code Storm Worm, aussi appelé Nuwar ou Zhelatin, est très débattu dans les média. Le CERTA a abordé les propriétés de celui-ci dans quelques bulletins d'actualité, dont CERTA-2007-ACT-007, CERTA-2007-ACT-028 et CERTA-2007-ACT-034.

Sa première caractéristique est l'utilisation des techniques pair-à-pair, et l'autre sa capacité au fil des mois à s'adapter et à évoluer. A valeur d'illustration, les versions les plus actuelles à la date de rédaction de ce bulletin profitent de la fête d'Halloween pour se propager par des pages Web et des courriers électroniques sur ce thème d'actualité.

L'objet de cet article n'est pas de revenir sur ces derniers traits de caractère, mais de regarder objectivement les informations disponibles sur l'Internet.

Depuis le mois de juillet 2007, les chiffres vont bon train dans les média. De quelques millions de machines compromises, certains articles parlent même de plus de 50 millions, et comparent même cette puissance de calcul potentielle à celle cumulée des 500 plus importants supercalculateurs existant à la date de rédaction de leur article. Cette information a été amplifiée dans de nombreux articles.

Or, en septembre 2007, Microsoft annonce sur un bloc-notes un nombre très différent : un peu plus de 200000 au mois d'août 2007. Il s'agit du nombre de remontées par l'outil facultatif MSRT (Malicious Software Removal Tool) de machines compromises.

Au mois d'octobre, un chercheur d'une université américaine a présenté les résultats de certains tests. Il a réalisé un crawler, ou générateur de trafic artificiel, afin de compter les machines compromises en fonction des réponses reçues. Il estime ainsi que quelques centaines de milliers de machines seraient victimes du code Storm Worm et actives.

Dans l'analyse publiée, il y a bien sûr quelques limitations (mentionnées). Celle-ci ne prend en compte que les nœuds actifs. Le nombre est donc sûrement sous-estimé. Par ailleurs, le code Storm Worm a subi au début du mois d'octobre quelques modifications, notamment dans sa méthode de chiffrement. Ces nouvelles variantes ne seraient également pas comptabilisées.

Il ne s'agit pas ici de critiquer la méthode présentée, mais bien de comprendre que les chiffres mentionnés dans le document ont une origine correctement détaillée. Ils peuvent être vrais, ils peuvent être faux, mais ils sont justifiés d'une certaine manière. Ceci est également valable avec le chiffre de Microsoft.

D'un autre côté, les millions de machines compromises citées en juillet n'ont pas une telle justification. Elles sont issues de déclarations reprises sans plus plus de vérification dans de multiples articles sur la toile.

2.2 Rationalité face aux magic numbers

Les chiffres sont souvent très manipulés et manipulables sur l'Internet. Il est cependant important de faire la part des choses. Il est, de manière générale, toujours préférable de favoriser les chiffres justifiés par une méthode documentée. Il est également important de ne pas interpréter ces derniers aussi rapidement que certains articles tendent à le faire.

La plus grande prudence doit être appliquée à l'annonce de telles informations, et seul l'esprit critique du lecteur peut l'aider à faire la part des choses.

Documentation associée

• Bloc-notes de Microsoft : « Storm Drain »:

  http://blogs.technet.com/antimalware/archive/2007/09/20/storm-drain.aspx
  

• Présentation de B. Enright à la conférence Toorcon 2007 :

  http://noh.ucsd.edu/~bmenrigh/exposing_storm.ppt
  

3 Les modifications de configuration DNS

Un cheval de Troie fait, à la date de rédaction de ce document, parler de lui car il vise les systèmes Mac OS. Comme tout cheval de Troie, il faut à un moment donné que l'utilisateur installe le code malveillant : ce dernier se présentant comme un codec au format .DMG, qui est proposé au téléchargement à l'ouverture d'une vidéo par QuickTime Player.

Ses actions sur le poste infecté consistent en particulier à modifier la configuration DNS, afin de diriger l'utilisateur vers des sites particuliers (sites de filoutage, sites malveillants ou sites publicitaires...).

L'interface de configuration visuelle (menu Réseau dans Préférences Systèmes) ne montre pas nécessairement cette modification DNS simplement (sous Mac OS 10.4 par exemple).

La simple visualisation par cette interface n'est donc pas suffisante.

Il est donc recommandé de :

• filtrer les connexions sortantes du réseau et de n'autoriser que les flux légitimes (ports 53 TCP et UDP associés au DNS notamment) ;
• surveiller le trafic DNS, afin de déterminer des machines potentiellement compromises ;
• vérifier sur le poste la bonne configuration, si possible au niveau des fichiers de configuration, comme resolv.conf et hosts ;
• signaler tout comportement anormal du navigateur (ouverture de pages de publicité, etc.) ;
• ne pas installer de code venant de sources n'étant pas de confiance. Il est aussi vivement recommandé de naviguer sur un compte aux droits limités.

Documentation

• Alerte d'Intego, "OSX.RSPlug.A Trojan Horse Changes Local DNS Settings to Redirect to Malicious DNS Servers :

  http://www.intego.com/news/ism0705.asp
  

4 Phishing : du neuf avec du vieux

Les différentes techniques de phishing (ou filoutage) sont connues et ont été détaillées dans plusieurs bulletins d'actualité ces derniers mois : un courriel est envoyé à un échantillon de personnes, prétendant provenir d'un organisme de confiance et qui, par une tournure plus ou moins élégante, incite le client à se rendre sur une page Web ressemblant à une légitime (page bancaire, page d'une boutique ou d'un service en ligne, etc.) et à rentrer ses informations personnelles. La personne malintentionnée à l'origine de cette escroquerie récupère ainsi des identifiants et des mots de passe valides, dont il peut faire usage par la suite.

Une autre approche peut être utilisée pour récupérer les identifiants des utilisateurs. Au lieu d'inciter le lecteur du courriel à cliquer sur un lien spécifiquement construit, le courrier électronique indique de prendre contact avec son service client (ou son support) en téléphonant à un numéro joint dans le corps du message. Ce numéro de téléphone est bien sûr faux, redirigeant la victime vers un serveur vocal ou un responsable client fictif. Les identifiants sont alors demandés via ce nouveau canal de communication, et la fuite d'information échappe donc au contrôle informatique pur (outils anti-filoutage). Ces techniques d'escroqueries téléphoniques ne sont pas nouvelles, loin de là, mais permettent de contourner plusieurs outils supposés réduire les risques de filoutage.

Si un courriel de ce type arrive dans la boîte aux lettres, le CERTA recommande de:

• vérifier le numéro de téléphone fourni en contactant le service à son numéro habituel (disponible sur le contrat au moment de la souscription) ;
• ne jamais dévoiler de données personnelles, privées ou sensibles par téléphone, quel que soit le contexte;
• prévenir les responsables du service légitime de la tentative d'escroquerie afin qu'ils prennent les mesures nécessaires à la résolution de cet incident.

5 Vulnérabilité dans Nagios et le module SNMP

Le CERTA a publié le 02 novembre 2007 l'avis CERTA-2007-AVI-473 relatif à deux vulnérabilités dans les extensions du logiciel de supervision Nagios. L'une d'entre elles concerne une faille dans l'extension check_snmp et permet l'exécution de code arbitraire à distance. Ce module donne la possibilité à Nagios d'intéroger des éléments du réseau via le protocole SNMP (Simple Network Management Protocol). Généralement, les équipements de réseau comme les routeurs ou les commutateurs mettent en œuvre ce protocole afin de fournir des éléments de supervision à une console de centralisation comme Nagios ou Big Brother. Outre le fait que la vulnérabilité de Nagios soit relativement importante et doive être corrigée dans les plus brefs délais, le CERTA attire l'attention sur l'absence de prise en compte de la sécurité dans la première version du protocole SNMP ou SNMPv1. En effet, la version 1 de SNMP (RFC-1157, port 161/udp et 161/tcp) n'offre aucun mécanisme d'autentification hormis un système de communautés (communities) souvent au nombre de 2 et nommées simplement publique et privée. Il conviendra donc de mettre en œuvre une politique de sécurité visant à limiter l'accès aux services SNMP sur les machines par le biais, par exemple, d'un réseau d'administration dédié ou par l'emploi de réseaux virtuels (VLAN ou VPN) si cela est possible.

6 Les images nommées Captchas

6.1 Introduction

Un Captcha (pour Completely Automated Turing Test To Tell Computers and Humans Apart) est une forme de test permettant de distinguer un utilisateur d'une machine. Il se présente souvent sous la forme d'une image dont le contenu est difficilement interprétable par des moyens logiciels. Il peut également s'agir de fichiers audios ou videos.

Le choix d'images pour effectuer ces tests ne favorise pas les personnes malvoyantes ou ayant des troubles affectant l'identification de mots écrits (formes de dyslexie), comme le souligne un rapport du W3C. Des alternatives existent donc au format des images. Nous allons cependant traiter ce cas dans les paragraphes suivants, car il s'agit à la date de rédaction de cet article, du test le plus répandu.

6.2 MoBIC : Le mois des vulnérabilités concernant les Captchas

Les mois précédents ont vu l'apparition de défis, sous la forme : « le mois des vulnérabilités sur ... ». Le CERTA a mentionné dans plusieurs bulletins ces défis. Ce mois de novembre 2007 est dédié, par certains, aux Captchas : MoBIC (Month of Bugs in Captchas).

Le CERTA reviendra éventuellement dans de prochains articles sur des publications intéressantes liées à cet événement. La sécurité des Captchas se limite parfois dans les esprits à la difficulté que les outils automatiques peuvent rencontrer pour interpréter le contenu visuel de l'image. En effet, le fondement même du développement et du déploiement des Captchas repose sur ce point sensible. Des sites présentent d'ailleurs certaines faiblesses des images Captchas, en fonction de leur méthode de construction (cf. section Documentation). Il est en revanche plus rare de considérer les vulnérabilités plus contextuelles ou architecturales liées à la mise en œuvre d'une solution basée sur les Captchas.

Ainsi, dès le premier jour de ce MoBIC, des vulnérabilités ont été signalées :

1. la première vulnérabilité vise la construction de l'image à partir d'un texte. Certains sites produisent le texte (via un Javascript) sur le poste client, puis le communiquent au serveur par une méthode HTTP GET au site distant afin de générer l'image à afficher. Il suffit donc à une personne malveillante d'intercepter cette requête sortante, pour avoir la réponse directe au Captcha, avant même que celui-ci ne s'affiche ;
2. certains sites laisseraient la possibilité à une personne malveillante de ré-utiliser le même code d'un Captcha à de multiples reprises. La vulnérabilité s'appuie sur une mise en œuvre ASP.NET, et le contournement de la protection CSRF (Cross-Site Request Forgery). Elle consiste à réutiliser certaines valeurs de variables.

Dans ces deux cas, il ne s'agit donc pas de la qualité même de la construction de Captchas, mais de son utilisation dans un environnement de production.

6.3 L'interprétation des Captchas par des tierces personnes

Certains sites proposent ainsi de tels tests pour empêcher à des « robots » l'accès de certaines pages. Si une personne malveillante n'a pas le temps d'interpréter chaque image qui lui est présentée, mais si elle souhaite néanmoins automatiser diverses actions, elle peut passer par la manipulation de tierces personnes. Cela peut se faire suivant deux grandes méthodes :

• par l'embauche, ou la participation de personnes dévouées à cette tâche, et pouvant être rémunérées ;
• par la manipulation de toute personne allant visiter un site. Ce dernier doit avoir, de préférence, un taux de fréquentation élevé, afin d'assurer une certaine « efficacité » à interpréter un grand nombre de Captchas différents ; il s'agit bien souvent de sites au contenu pornographique, ou de téléchargement. Le scénario est le suivant :
  1. la personne malveillante a un outil qui récupère les Captchas sur les sites susceptibles de l'intéresser ;
  2. elle les affiche sur un site à forte fréquentation, en proposant par exemple l'affichage ou le téléchargement à tout utilisateur après interprétation du Captcha ;
  3. l'utilisateur intéressé renseigne le site malveillant ;
  4. ce dernier retourne le résultat sur le site d'origine, et peut accéder au contenu initialement d'accès limité.

L'utilisateur doit donc comprendre qu'il peut être manipulé et servir d'intermédiaire à de telles activités malveillantes. Il est important de ne pas naviguer sur des sites dangereux ou d'apparence plus que douteuse. L'administrateur du site peut, lui, surveiller les temps de réaction entre la création d'un Captcha et la réception de la réponse de l'utilisateur, et ajouter éventuellement un compte-à-rebours. La solution par nature du Captcha est de distinguer la machine d'une personne, mais pas de garantir que la personne qui lui réponde est habilitée à le faire. D'autres mécanismes doivent être mis en place pour assurer ce dernier point.

6.4 Documentation

• Le site sur les Captchas, maintenu par l'université de Carnegie-Mellon :

  http://www.captcha.net
  

• Des alternatives aux Captchas visuels, proposées par le W3C Working Group :

  http://www.w3.org/TR/turingtest/
  

• Les faiblesses techniques de certaines mises en œuvre de Captchas :

  http://sam.zoy.org/pwntcha