Marianne ANSSI

CERT-FR

Centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques

logo ANSSI
Informations utiles

Que faire en cas d'intrusion ?

Les systèmes obsolètes

Liens utiles

 

L'ANSSI recrute

 

 

Les documents du CERT-FR

Publications récentes

Les alertes en cours

Les bulletins d'actualité

Les notes d'information

Année en cours Archive

 

Les Flux RSS du CERT-FR

Flux RSS complet

RSS

Flux RSS des alertes

RSS

Flux RSS SCADA

RSS

 

CERTA-2008-ACT-047

Imprimer ce document

Version PDF

À propos du CERT-FR

Le CERT-FR

Nous contacter

Contact us ( Drapeau anglais )

A propos du site

Communauté CSIRT

Les CSIRT

Le FIRST

L'EGC

 
Archives du CERT-FR

Année 2017 Archive

Année 2016 Archive

Année 2015 Archive

Année 2014 Archive

Année 2013 Archive

Année 2012 Archive

Année 2011 Archive

Année 2010 Archive

Année 2009 Archive

Année 2008 Archive

Année 2007 Archive

Année 2006 Archive

Année 2005 Archive

Année 2004 Archive

Année 2003 Archive

Année 2002 Archive

Année 2001 Archive

Année 2000 Archive

 

S . G . D . S . N
Agence nationale
de la sécurité des
systèmes d'information

République Française Paris, le 21 novembre 2008
No CERTA-2008-ACT-047

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2008-47


Conditions d'utilisation de ce document : http://www.certa.ssi.gouv.fr/certa/apropos.html
Dernière version de ce document : http://www.certa.ssi.gouv.fr/site/CERTA-2008-ACT-047

Gestion du document

Le bulletin d'actualité est disponible dans son intégralité et au format PDF à l'adresse suivante :

http://www.certa.ssi.gouv.fr/site/CERTA-2008-ACT-047.pdf

Un extrait du bulletin, ne reprenant que les articles de la semaine, se trouve en HTML à l'adresse suivante :

http://www.certa.ssi.gouv.fr/site/CERTA-2008-ACT-047/

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


6 Rappel des avis émis

Dans la période du 14 au 21 novembre 2008, le CERTA a émis l'alerte et les avis suivants :

  • CERTA-2008-ALE-014 : Vulnérabilité dans Opera
  • CERTA-2008-AVI-556 : Vulnérabilité dans GnuTLS
  • CERTA-2008-AVI-557 : Vulnérabilités de Safari
  • CERTA-2008-AVI-558 : Vulnérabilités dans Mozilla Thunderbird
  • CERTA-2008-AVI-559 : Multiples vulnérabilités dans Symantec Backup Exec
  • CERTA-2008-AVI-560 : Multiples vulnérabilités dans Adobe AIR
  • CERTA-2008-AVI-561 : Multiples vulnérabilités dans HP OpenView Network Node Manager
  • CERTA-2008-AVI-562 : Vulnérabilités de Libxml2
  • CERTA-2008-AVI-563 : Multiples vulnérabilités dans Citrix XenServer

Durant la même période, l'avis suivant a été mis à jour :

  • CERTA-2008-AVI-302-002 : Vulnérabilité dans Net-SNMP

    (ajout de la référence debian)


Liste des tableaux

Gestion détaillée du document

21 novembre 2008
version initiale.


CERTA
2014-01-17
Premier Ministre / Secrétariat Général de la Défense et de la Sécurité Nationale / Agence nationale de la sécurité des systèmes d'information webmestre Dernière mise à jour : le 2017-04-20