S.G.D.S.N

Agence nationale
de la sécurité des
systèmes d'information

Paris, le 13 juin 2008
N° CERTA-2008-ACT-024
Affaire suivie par: CERT-FR

Bulletin d'actualité du CERT-FR

Objet: Bulletin d'actualité 2008-24

Gestion du document

Référence CERTA-2008-ACT-024
Titre Bulletin d'actualité 2008-24
Date de la première version 13 juin 2008
Date de la dernière version 13 juin 2008
Source(s)
Pièce(s) jointe(s) Aucune(s)
Tableau 1: Gestion du document

Une gestion de version détaillée se trouve à la fin de ce document.

1 Les incidents de la semaine

1.1 Le phishing d'un site de vente en ligne

Cette semaine, le CERTA a traité un incident relatif au filoutage (ou phishing) d'un site de vente en ligne. Le site utilise un portail pour vendre les différents services qu'il propose. En analysant les statistiques de connexions, le responsable s'est rendu compte qu'un site qu'il ne connaissait pas le référençait (visible par le champ REFERER de l'en-tête HTTP fourni dans les journaux). En se rendant sur ce site, il a constaté qu'il reproduisait à l'identique son site légitime, utilisant le même nom de service, la même charte graphique, les mêmes images, les mêmes références clients, ... Les seuls changements portaient sur les tarifs pratiqués et les coordonnées de contacts.

Le CERTA rappelle que les escroqueries, comme le phishing, ne touchent pas que les banques ou les fournisseurs d'accès. Ils peuvent viser tout service en ligne sur Internet.

L'utilisateur doit donc rester vigilant et méfiant au cours de sa navigation, et ne pas fournir trop rapidement ses identifiants de connexion.

L'administrateur doit, comme il a été fait ici, surveiller avec attention ses journaux de connexion afin de déceler toute anomalie ou mettre en évidence des phénomènes étranges.

1.2 Compromissions en série

1.2.1 Présentation des faits

Cette semaine le CERTA a participé au traitement d'un incident relatif à la compromission de plusieurs sites Internet. Ces sites étaient tous co-hébergés sur le même serveur. Il a en fait suffi à l'attaquant de profiter de la vulnérabilité d'un des sites présents pour compromettre tous les autres et mettre en péril la sécurité du serveur. En effet, la même archive de kit de filoutage a pu être déployée sur tous les sites. Il est important de souligner qu'une telle compromission de masse n'a nécessité que l'exécution d'une seule commande sur le serveur.

Le CERTA rappelle qu'en matière d'hébergement mutualisé, il convient de respecter certaines bonnes pratiques, comme certaines décrites dans la note d'information du CERTA CERTA-2005-INF-005.

1.2.2 Documentation

2 A propos du contournement de MS08-033

L'avis CERTA-2008-AVI-307 qui concerne des vulnérabilités corrigées dans Microsoft DirectX est décrit par Microsoft dans son bulletin de sécurité MS08-033. Dans celui-ci, Microsoft propose un contournement provisoire qui consiste à modifier les ACL (Access Control List) du fichier quartz.dll ou de désactiver cette bibliothèque dans le registre. quartz.dll est une bibliothèque contenant des fonctions pour DirectShow, une partie de DirectX. Ce contournement a également été conseillé pour d'autres bulletins concernant DirectX, par exemple MS07-064 et MS06-005. Il peut être intéressant de l'appliquer pour des administrateurs qui ne peuvent effectuer les mises à jour immédiatement.

Pour restreindre les droits en modifiant les ACL, les commandes à taper sont les suivantes :

Sur Windows XP (avec un compte administrateur) :

Echo y| Cacls.exe %WINDIR%\SYSTEM32\QUARTZ.DLL /E /P everyone:N

Sur Windows Vista (sous une invite de commandes ouverte en tant qu'administrateur):

Takeown.exe /f %WINDIR%\SYSTEM32\QUARTZ.DLL
Icacls.exe %WINDIR%\SYSTEM32\QUARTZ.DLL /save %TEMP%\QUARTZ_ACL.TXT
Icacls.exe %WINDIR%\SYSTEM32\QUARTZ.DLL /deny everyone:(F)

Pour remettre les droits originaux :

Sur Windows XP :

Cacls.exe %WINDIR%\SYSTEM32\QUARTZ.DLL /E /R everyone

Sur Windows Vista :

Icacls.exe %WINDIR%\SYSTEM32\QUARTZ.DLL /grant everyone:(F)
Icacls.exe %WINDIR%\SYSTEM32 /restore %TEMP%\QUARTZ_ACL.TXT

L'autre contournement consiste à désactiver quartz.dll :

Regsvr32.exe -u %WINDIR%\SYSTEM32\QUARTZ.DLL

Pour le réactiver :

Regsvr32.exe %WINDIR%\SYSTEM32\QUARTZ.DLL

Quartz.dll étant un composant majeur de DirectShow, ces contournements ont des impacts qui peuvent être non négligeables. En effet, DirectShow est un framework (environnement de travail) multimédia utilisé par certaines applications sous Windows. Les effets de bord sont cependant différents selon le système d'exploitation. Ainsi, sur Windows XP, aucun fichier ne pourra être interprété dans une application utilisant DirectShow. Sur Windows Vista, seule la lecture des fichiers .avi et .wav avec des applications utilisant DirectShow serait concernée. Le lecteur Windows Media Player est notamment affecté par cet effet de bord.

2.1 Documentation

3 Les codes malveillants chiffrants

Une nouvelle variante d'un code malveillant a fait son apparition récemment. Cette dernière répond au nom de gpcode.ak. Elle est la dernière évolution d'un code aux manières un peu particulières : les victimes de ce programme constatent le chiffrement de l'ensemble des fichiers ayant une extension particulière (.doc, .txt, .pdf, .xls, .jpg, ...) selon les versions. Pour retrouver l'usage de ces fichiers, il est demandé de payer ($100 ou $200 ?) afin d'obtenir le programme de déchiffrement. Ce type de programme est connu sous le terme ransomware 1.

Si ce type de code malveillant n'est pas nouveau cette version pose toutefois des problèmes. Les anciennes versions avaient pu être déjouées grâce à un défaut dans l'implémentation de l'algorithme de chiffrement et ainsi permettre le déchiffrement des fichiers sans avoir à payer cette rançon. Cette nouvelle variante ne fait malheureusement pas la même erreur. La taille de la clé de chiffrement (1024 bits) ainsi que l'algorithme utilisé (RSA) ne permettent pas de trouver une méthode de décryptement.

Différentes initiatives, plus ou moins critiquables et critiquées, ont été lancées afin de trouver une solution à ce code malveillant. Par exemple, des projets de collaborations appelant toute personne volontaire à contribuer à la recherche d'un remède efficace ont été créés. A ce jour, aucun moyen n'est à disposition pour récupérer des données modifiées par ce code. Une signature de ce dernier est cependant disponible.

Le CERTA tient à rappeler l'ensemble des bonnes pratiques afin de limiter les risques d'infection et leurs impacts :

  • faire des sauvegardes régulières ;
  • ne pas stocker de données sensibles sur un poste exposé ;
  • prendre les précautions d'usage pour prévenir les intrusions :
    • disposer d'un système d'information à jour (système d'exploitation, applicatifs, antivirus, ...) ;
    • ne pas ouvrir de pièce jointe dans un courriel ne provenant pas d'une source de confiance ;
    • ouvrir les courriels au format texte ;
    • ne pas cliquer sur des liens non sûrs ;
    • désactiver l'exécution des codes dynamiques du type JavaScript et flash de son navigateur.

4 Adobe 9 et autres nouveautés

Plusieurs sources sur l'Internet, dont Adobe, confirment l'arrivée prochaine de la version 9 de Adobe Reader. Cette nouvelle version sera, en outre, accompagnée d'une suite de logiciels enrichissant le catalogue des produits proposés par Adobe. Concernant Adobe Reader, il sera possible parmi les nouveautés avec la prochaine version d'inclure du contenu Flash (.swf) dans un fichier au format PDF (.pdf).

Le CERTA rappelle que la technologie Flash n'est pas sans risque (cf. CERTA-2008-ACT-016) et que, par conséquent, les risques liés à cette technologie pourront se retrouver également dans les fichiers PDF de dernière génération.

Pour mémoire il est possible, par exemple, avec la dernière version de Flash, d'utiliser des ressources réseau (sockets) dans le contexte de la lecture d'un fichier .swf. On comprend dès lors que le format Flash n'est plus un format statique sans intéraction forte avec son environnement.

Quant à la suite logicielle qui sera proposée par Adobe, elle comprendra, à l'image d'un concurrent dans le domaine, un traitement de texte en ligne, un outil de travail collaboratif en ligne, un outil d'échange de fichiers et un convertisseur ``universel'' de fichiers en PDF. Tous ces outils, bien qu'installés en partie sur la machine, utiliseront des composantes distribuées en ligne. Dans ce contexte, il devient assez difficile de savoir quelle est la part de traitement qui est faite « en local » de la part réalisée en ligne. Cela complexifie la maîtrise les informations traitées localement de celles envoyées « pour traitement » sur un serveur distant. Ce type d'outil pose des problèmes évidents de confidentialité.

4.1 Recommandations

Dans un cas comme dans l'autre, le CERTA recommande la plus grande prudence vis-à-vis de ces technologies qui, certes, apportent de nouvelles fonctionnalités mais entraînent surtout d'inquiétants problèmes de confidentialité et plus généralement de sécurité.

5 SNMP : une gestion dangereuse ?

5.1 La gestion de réseau

La gestion des réseaux n'est pas une tâche évidente. Elle impose souvent de connaître l'état des équipements, comprendre leurs demandes, voire aussi modifier certains paramètres de configuration. Pour cela, des architectures de communication sont mises en place. Elles recourent souvent à un protocole : SNMP (pour Simple Network Management Protocol), standardisé au début des années 90. Les données utiles pour gérer des équipements (dotés d'« agents » SNMP) se présentent sous forme de variables qui peuvent être interrogées et modifiées (l'information complète étant une collection d'objets appelée MIB ou Management Information Base dont le langage respecte la SMI ou Structure of Management Information). Plusieurs versions de ce protocole existent. Le standard RFC 2570, publié en avril 1999, décrit la version la plus récente : SNMPv3.

En terme de sécurité, SNMPv3 comble quelques lacunes des versions précédentes en offrant des solutions d'authentification et de chiffrement précisées dans le standard RFC 2574. La méthode s'appuie sur le principe d'utilisateurs définis par un nom, des droits d'accès et un mot de passe.

  • chiffrement : les données peuvent être chiffrées par chaînes de blocs avec DES (Data Encryption Standard). Le secret est partagé entre les deux acteurs de la communication ;
  • le contrôle d'accès : le contrôle se fait sur le principe de « vues » ; les informations peuvent être lues ou modifiées selon les utilisateurs ;
  • protection contre le rejeu : un compteur est inclus dans chaque message. Il représente la durée depuis le dernier redémarrage du service de gestion d'administration ainsi que le nombre total de redémarrages depuis son installation. À la réception, le service vérifie que ce compteur reste dans une marge d'erreur raisonnable pour estimer s'il s'agit d'un rejeu. Cette mesure n'est donc pas parfaite ;
  • authentification : un principe de condensat appliqué au secret partagé est utilisé pour s'authentifier : il s'agit de HMAC (keyed-Hashing for Message Authentication) précisé dans le standard RFC 2104. Il s'agit en réalité de concaténer les données avec le secret partagé, puis d'en calculer un condensat avec une fonction donnée, comme MD5 (HMAC-MD5) ou SHA-1 (HMAC-SHA1).

Même si cette version est celle qui est préconisée depuis son lancement, elle est loin d'être déployée dans la majorité des architectures de gestion.

5.2 Le problème actuel : CVE-2008-0960

HMAC (keyed-Hashing for Message Authentication Code) peut ainsi être utilisé pour authentifier les utilisateurs. Cependant, plusieurs applications ne vérifient pas que les valeurs fournies sont de taille raisonnable, permettant à quiconque d'envoyer des condensats de 1 octet. Cela se résume à 256 valeurs de condensats différentes. En d'autres termes, l'envoi d'une trame usurpée a donc 1 chance sur 256 de passer la phase d'authentification avec succès. Cette vulnérabilité reste valable pour les variantes HMAC-SHA-96 et HMAC-MD5-96 s'appuyant respectivement sur les algorithmes Secure Hashing Algorithm-1 (SHA-1) et Message-Digest Algorithm 5 (MD5).

Du code d'exploitation est déjà disponible.

Cette vulnérabilité a été initialement détectée sur les mises en œuvre de SNMP suivantes :

L'avis CERTA-2008-AVI-302 rappelle ainsi que les versions vulnérables de NET-SNMP sont toutes celles antérieures à 5.4.1.1, 5.3.2.1 et 5.2.4.1.

L'effet « boule de neige » issu de la réutilisation de mêmes codes par plusieurs applications implique de nombreux autres produits. Parmi ceux-ci :

  • Cisco (Cisco IOS, Cisco IOS-XR, Cisco CatOS, Cisco NX-OS, Cisco ACE)
  • Juniper Networks (Session and Resource Control SRC pour les versions 1.0.0, 1.0.1 ou 2.0.0) ;
  • Sun Microsystems
  • Red Hat (Red Hat Enterprise Linux 2.1, 3, 4 et 5 utilisant les paquets ucd-snmp ou net-snmp) ;
  • Network Appliance (Data ONTAP version 7.3RC1, 7.3RC2) ;
  • SNMP Research (produits ayant SNMPv3 pour les versions 16.1 et antérieures).

Une liste est maintenue à l'adresse suivante :

http://www.kb.cert.org/vuls/id/878044

Cette vulnérabilité est relativement importante. Il ne faut pas oublier non plus que de tels services ne doivent pas être accessibles depuis l'Internet. En effet, il est possible de cartographier l'ensemble des équipements ayant de telles vulnérabilités par des balayages de ports à large échelle. Des personnes ont déjà lancé de telles opérations et le résultat a été rendu public. Toute interface connectée à l'Internet ne peut pas cacher simplement les services en écoute sur des ports.

Il suffit d'un équipement embarqué mal configuré comme un routeur pour mettre en danger l'ensemble des communications sortantes d'un réseau.

5.3 Recommandations

Plusieurs mesures peuvent être entreprises pour limiter les risques.

La première consiste à vérifier si SNMP est effectivement déployé ou activé sur les équipements ; l'usage de ce protocole n'est parfois pas clairement mentionné par les outils d'administration à distance. Cela peut se faire par le biais de balayages contrôlés dans le réseau local, par une écoute passive des trames ou en interrogeant directement la configuration des équipements.

Par exemple, les équipements Cisco (IOS, CatOS ou IOS-XR) peuvent être interrogés par la commande show snmp group. L'information est visible dans le champ security model, qui signale par usm ou v3 auth que SNMPv3 est configuré.

Si SNMP est effectivement utilisé, il faut alors s'assurer qu'il est correctement configuré avec l'application des différentes mesures de sécurité. De manière générale, des utilisateurs distincts sont utilisés pour la lecture et l'écriture de données. De même, le chiffrement peut s'activer ou se désactiver. Dans la configuration Net-SNMP, cela se fait avec le champ priv.

        # �criture et lecture
        rwuser certa1 priv
        # lecture seulement
        rouser certa2 priv
Il est souvent possible de journaliser les erreursd'authentification et d'émettre un signal (trap) à laconsole d'administration quand cela se produit. Pour Net-SNMP, ilsuffit également d'ajouter dans le fichier de configurationsnmpd.conf la ligne : 
        authtrapenable 1
        # d�finir aussi la destination des "trap"

Parmi les autres mesures envisageables :

  • vérifier les cloisonnements des services. Les échanges de données pour administrer les équipements doivent être physiquement (ou logiquement si cela n'est pas possible) décorrélés du réseau et les interfaces doivent être inaccessibles pour toute autre application que celle de console d'administration sur un poste dédié ;
  • surveiller le trafic SNMP. Par défaut, il utilise les ports de destination 161/udp et 162/udp ;
  • mettre à jour les équipements.

5.4 Documentation

Rappel des publications émises

Dans la période du 02 juin 2008 au 08 juin 2008, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 13 juin 2008
    version initiale.