S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 21 novembre 2008
N° CERTA-2008-ACT-047
Affaire suivie par: CERT-FR
le 21 novembre 2008

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-47

Gestion du document

Référence CERTA-2008-ACT-047
Titre Bulletin d’actualité 2008-47
Date de la première version 21 novembre 2008
Date de la dernière version 21 novembre 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 Quand l’USB est le vecteur de l’infection

1.1 Présentation

Cette semaine, le CERTA a participé au traitement d’un incident relatif à la compromission d’un réseau de l’administration par un virus. Malgré un cloisonnement physique des réseaux ayant un niveau de sécurité différent, l’utilisation de supports de stockage USB était autorisée entre les différents réseaux. Une clef USB semble être le vecteur de la première infection. Le virus, qui n’était pas encore reconnu par les antivirus pourtant à jour, s’est ensuite répandu dans tout le réseau.

A cette étape de l’analyse, le CERTA rappelle que des règles de cloisonnement strictes doivent être mises en oeuvre pour éviter de pouvoir contourner les mesures de sécurité mises en place (ici l’isolement des machines en libre-service).

Le CERTA indique également qu’il existe plusieurs méthodes pour désactiver l’exécution automatique des périphériques USB :

  • une technique radicale consiste à désactiver le support USB, comme décrite dans la note d’information CERTA-2006-INF-006. Cela peut géner l’utilisation de périphériques comme des claviers ou des souris ;
  • la base de connaissances de Microsoft (cf article 823732) indique comment désactiver l’utilisation des dispositifs de stockage USB ;
  • une autre technique plus modérée consiste à modifier le comportement de Windows à l’égard des fichiers autorun.inf. Il est en effet possible de désactiver l’exécution automatique de ce fichier via une clef de registre : 
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies
\Explorer\NoDriveTypeAutorun

    Par exemple, la valeur 0xFF désactive cette fonctionnalité sur tous les supports.

1.2 Documentation

2 Modification malveillante des résolutions DNS

2.1 Présentation

Le CERTA traite actuellement la recrudescence d’infections d’ordinateurs par un code malveillant modifiant les résolutions DNS des machines victimes. Ce code malveillant modifie la configuration DNS des ordinateurs compromis. Ces derniers lancent alors de nombreuses requêtes DNS directement vers des serveurs DNS situés à l’étranger. Ces serveurs DNS suspects résolvent certaines requêtes de manière anormale en dirigeant les victimes vers des adresses incorrectes.

Ces infections proviennent souvent de la navigation sur des sites malveillants proposant de fausses vidéos ou des (faux) outils de protection gratuits (antivirus, antispyware, …) ou faisant croire à l’installation de mises à jour.

Pour détecter si des ordinateurs sont compromis, il est recommandé de :

  • surveiller le flux DNS et vérifier qu’il s’adresse aux serveurs définis dans l’architecture DNS ;
  • vérifier la configuration DNS des postes et le respect de l’architecture DNS comme préconisé dans CERTA-2008-INF-002 ;
  • rechercher dans les journaux des antivirus des signalements d’infections par des virus portant de noms tels que : (les versions peuvent évoluer) :
    • Trojan.Win32.DNSChanger.ef (Kaspersky Lab)
    • DNSChanger.a (McAfee)
    • TROJ_DNSCHAN.SUB (Trend Micro)
    • Troj/DNSBust-O (Sophos)
    • Trojan:Win32/Alureon.A (Microsoft)
    • Trojan.Win32.DNSChanger (Ikarus)

Pour se protéger des effets de tels codes malveillants, il est recommandé de :

  • mettre en place une architecture DNS n’autorisant les requêtes DNS sur des serveurs extérieurs que dans des cas exceptionnels (nomades) ;
  • vérifier l’application de cette architecture (configuration des postes, surveillance du trafic DNS) ;
  • rappeler les utilisateurs à la vigilance : ne pas télécharger des fichiers (images, codecs, exécutables, documents) depuis des sources non sures.

2.2 Références

3 OpenBSD et correctifs de fiabilité

Cette semaine, le projet OpenBSD a fourni un ensemble de correctifs pour son système d’exploitation homonyme dans sa dernière version ( OpenBSD 4.4 mentionné dans le bulletin d’actualité CERTA-2008-ACT-046) :

  • un premier concernant le comportement anormal de la pile IPv4 dans certaines conditions ;
  • un second relatif au mod_proxy du serveur HTTP intégré qui peut présenter des dysfonctionnements sur les systèmes 64-bit ;
  • un troisième concerne un bogue entraînant une consommation excessive de la mémoire lors de la manipulation de tableaux dans des applications ;
  • la dernière concerne un problème de non-interopérabilité du serveur DHCP avec certains clients comme ceux de OpenSolaris ou Solaris.

D’après l’éditeur, ces correctifs ne présentent pas un caractère de sécurité. Mais, dans la mesure où ils touchent des composants utilisés relativement fréquemment et que les erreurs peuvent mettre en jeu la disponibilité du système, il est conseillé d’appliquer ces correctifs.

4 Retour sur la vulnérabilité TKIP

4.1 Présentation

Le CERTA avait mentionné dans son bulletin d’actualité CERTA-2008-ACT-045 (section 3) une possible vulnérabilité concernant le protocole TKIP (Temporal Key Integrity Protocol).

Les intervenants ont effectivement présenté récemment une méthode d’attaque qui combine plusieurs points :

  • la réadaptation d’une attaque détaillée pour le WEP, prénommée chopchop ;
  • la possibilité d’utiliser différentes files de priorité, comme spécifié dans le standard pour la qualité de service 802.11e, afin de pouvoir réutiliser des keystreams ;
  • l’exploitation de l’algorithme MIC ou Michael servant au contrôle d’intégrité.

L’attaque concerne aussi bien WPA que WPA2 dans la mesure où TKIP est utilisé, indépendemment de la méthode d’authentification mise en place (PSK ou 802.1X/EAP).

L’exploitation complète de cette vulnérabilité conduit actuellement une personne quelconque qui se trouve à portée des échanges :

  • à déchiffrer des paquets arbitraires émis par un point d’accès à destination d’un poste. Comme le déchiffrement actuel de l’attaque est assez lent (un octet par minute), la technique s’applique essentiellement à peu de trames ou des trames de petites tailles et de contenu assez prévisible.
  • à injecter des trames arbitraires, avec une limitation imposée principalement par le nombre de files de priorité possibles. L’injection ne doit pas dépasser l’ordre d’une dizaine de trames.

Cette attaque s’appuie par ailleurs sur une technique active, chopchop. Il faut donc la lancer sur du trafic réel et non un simple rejeu. Si le poste client se désassocie du point d’accès, l’attaque échoue.

L’attaque a été déployée dans certains outils publics.

4.2 Recommandations

Les recommandations sont inchangées par rapport à celles citées dans CERTA-2008-ACT-045. Nous pouvons cependant apporter quelques précisions quant au renouvellement fréquent des clés avec TKIP. Une clé changée toutes les minutes permet de récupérer un octet. Une rotation de deux minutes peut donc être un bon contournement provisoire. Les points d’accès de type Aruba (« timer mkey-rotation-period« ) et Cisco (« broadcast-key change« , « devshell dot1xUpdateBroadcastRekeyTimer« ) permettent par exemple de modifier ce paramètre (cf. la documentation).

Ce changement doit être fait avec prudence afin de vérifier qu’il ne génère aucun désagrément pour l’architecture sans-fil.

Cette attaque nécessite également l’interprétation de la qualité de service (802.11e).

Enfin, il est important d’avoir une politique de chiffrement claire mise en place au niveau du point d’accès. Il faut choisir clairement l’option CCMP/AES. Certains points d’accès laissent la possibilité d’être configurés en mode « TKIP+AES ». Ce mode hybride est dangereux, car il risque d’imposer le chiffrement le plus faible à tous les postes, même si le mode TKIP est exigé par un seul d’entre eux.

Les tentatives d’attaques peuvent laisser des traces. Il ne faut donc pas négliger l’analyse régulière des journaux du point d’accès. Des erreurs de type MIC Failure report from the station peuvent apparaître.

Enfin, certains constructeurs feront éventuellement des mises à jour pour leurs produits. Il faut donc également suivre le support de ces derniers.

4.3 Conclusions

D’autres améliorations à cette attaque sont envisageables dans les prochains mois.

La vulnérabilité ne peut être exploitée qu’avec certaines contraintes. Elle permet néanmoins de mettre en oeuvre des attaques non négligeables, comme la redirection de trafic.

Cette vulnérabilité permet de rappeler que TKIP n’est qu’une solution de sécurité partielle et que les mises en oeuvre doivent tendre vers du chiffrement plus robuste, avec AES/CCMP.

Il est donc important de penser dès à présent à sensibiliser les utilisateurs et les aider à configurer leurs postes vers ce choix quand cela est possible.

4.4 Documentation associée

5 Les URI Data:

5.1 Présentation

Les URI (Uniform Ressource Identifier) de type Data: permettent l’insertion de données dans tout fichier acceptant ce format d’adresse. Les URI Data: sont définies dans la RFC 2397 et la syntaxe est la suivante :

data:[<mediatype>][;encodage],<data>

La RFC fait état de fichier média mais il est cependant possible d’envoyer des fichiers de différents types : texte, images, données à passer en paramètre à une application, vidéo, ….

Cette fonctionnalité pourrait être détournée à des fins malveillantes en envoyant des données malformées. De plus, l’encodage des données à leur emission permet une obfuscation des données transmises.

Ces URI ne sont pas encore supportées par tous les navigateurs, Safari, Firefox, Opera et Chrome sont capables des les traiter, Internet Explorer ne les prendra en compte que dans sa version 8 selon le format des données envoyées.

Le CERTA recommande cependant de prêter attention à cette fonctionnalité qui pourrait être de plus en plus utilisée dans les années à venir et recommande une analyse, voir un filtrage des données transmises par l’intermédiaire de ces URI afin de limiter les risques de compromission.

5.2.4 Documentation

5.2 OpenSSH : une vulnérabilité pas si triviale à exploiter

Vendredi dernier, le 14 novembre 2008, le CPNI (Centre for the Protection of National Infrastructure) a publié un bulletin de sécurité à propos d’OpenSSH. La vulnérabilité permettrait de décrypter n’importe quelle partie de 32 bits d’un bloc chiffré, sous certaines conditions.

Si l’on se penche sur les explications, la vulnérabilité n’est pas si évidente à exploiter dans un contexte opérationnel.

5.2.1 Explication de la vulnérabilité

En cryptographie, on appelle mode opératoire de chiffrement la manière dont seront traitées les données à chiffrer. En effet, lorsque l’on doit appliquer certains algorithmes de chiffrement à un gros ensemble de données, ces données sont découpées en blocs et le chiffrement est appliqué à ces blocs suivant un traitement particulier : le mode opératoire.

La vulnérabilité décrite pour OpenSSH est due au choix du mode opératoire de chiffrement CBC (Chipher Block Chaining ou Enchaînement de blocs) comme mode opératoire par défaut (cf RFC. 4251). Ce mode opératoire est initialisé par un vecteur d’initialisation, et chaque bloc chiffré sert dans le processus de chiffrement du bloc suivant (cf. figure 1).

Figure 1: Mode opératoire CBE
Image CBC

D’après le CPNI, l’utilisation de ce mode opératoire affaiblit le chiffrement des messages échangés via un tunnel SSH. Ainsi, en procédant par injection de fautes, il est a priori possible de décrypter un bloc de 32 bits avec une probabilité de .

5.2.2 Et d’un point de vue pratique ?

Pour conduire cette attaque, une personne malintentionnée doit tout d’abord être capable d’analyser en temps réel la connexion SSH dans son intégralité, afin d’analyser le résultat des injections d’erreurs.

Elle doit de plus injecter de nombreuses erreurs, ce qui a généralement pour conséquence de couper la connexion.

L’attaque est donc loin d’être triviale et réalisable dans un cas concret.

5.2.3 Comment me protéger ?

La solution la plus évidente consiste à changer le mode opératoire, et d’utiliser le mode CTR (CounTeR, c’est à dire basé sur un compteur) au lieu du mode CBC (cf. RFC 4344). De même, le mode de chiffrement Arcfour ne semble pas être vulnérable.

Pour utiliser un de ces modes, il convient de n’utiliser que les modes suivants dans les fichiers sshd_config and ssh_config :

Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc

5.2.4 Documentation

Rappel des avis émis

Dans la période du 10 au 16 novembre 2008, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 21 novembre 2008
    version initiale.