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

Paris, le 19 mars 2010
N^o CERTA-2010-ACT-011

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2010-11

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-2010-ACT-011

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-2010-ACT-011.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-2010-ACT-011/

1 Incident de la semaine

Campagne de fausses cartes de v $\oe$ ux virtuelles

Un de nos correspondants nous a informés que son serveur de messagerie était inondé de messages invitant les destinataires à consulter une carte de v $\oe$ ux virtuelle en ligne. Bien évidemment, cette prétendue « carte » est en fait un code malveillant. Cet incident n'a rien d'exceptionnel, néanmoins son analyse soulève deux points intéressants :

la liste des destinataires était relativement précise et ne contenait que peu d'erreurs. Ces listes sont parfois constituées à partir d'informations collectées sur les serveurs Web. L'expérience montre que de larges fichiers, voire des bases de données, contenant des adresses de messagerie sont parfois déposés sur des sites Web et laissés accessibles depuis l'Internet, soit par négligence, soit par insouciance ;
l'envoi massif des courriers électroniques a reposé sur des scripts PHP déposés sur des sites compromis. Le CERTA rencontre souvent ce genre de fichiers lors de l'analyse d'intrusions sur des serveurs, en particulier lorsque ces derniers ont été utilisés à des fins de hameçonnage. Il n'est d'ailleurs pas rare qu'après « nettoyage » des pages de phishing, ces fameux scripts d'émission de messages électroniques (souvent appelés phpmailer) soient « oubliés » par les administrateurs/webmestres. La meilleure pratique reste encore la réinstallation complète des serveurs compromis.

2 Durcissement de la configuration des systèmes Windows : désactivation des empreintes de type LM (4/8)

Windows met en $\oe$ uvre deux algorithmes pour calculer les empreintes des mots de passe des comptes utilisateur :

l'empreinte LM (ou « hash LM »), basée sur l'algorithme DES et utilisant un alphabet réduit. Il s'agit du mécanisme historique largement vulnérable ;
l'empreinte NTLM (ou « hash NTLM »), basée sur l'algorithme MD4 et utilisant le codage Unicode.

Il est recommandé de ne pas calculer les empreintes de type LM dans les bases SAM des comptes locaux ou dans les annuaires Active Directory, afin de réduire les possibilités de cryptanalyse des mots de passe. Seule la version NTLM doit être conservée. Cette recommandation s'applique tant pour les postes de travail que pour les serveurs.

Afin de ne pas calculer l'empreinte LM au prochain changement du mot de passe, il faut :

sous Windows 2000, ajouter une clé de registre appelée NoLMHash sous la clé
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLSA ;
à partir de Windows XP, ajouter une valeur dénommée NoLMHash de type DWORD dont la donnée vaut 1 dans la clé HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLSA.

Depuis Windows XP, la suppression de la génération des empreintes de type LM peut être configurée au travers des Options de sécurité. Le paramètre se situe dans l'arborescence Paramètres de sécurité, Stratégies locales, Options de sécurité et s'intitule « Sécurité réseau : ne pas stocker de valeurs de hachage de niveau Lan Manager sur la prochaine modification du mot de passe ».

L'invalidation de l'empreinte LM de la base des comptes n'est effective qu'au prochain changement de mot de passe de chaque utilisateur.

Cette recommandation doit être appliquée sur chaque station de travail afin que l'empreinte LM ne figure pas dans les bases de comptes locaux. En ce qui concerne les comptes du domaine, la configuration de la stratégie locale de sécurité doit être appliquée au niveau des contrôleurs de domaine.

De Windows 2000 à Windows 2003, les deux empreintes sont engendrées par défaut. En revanche, à partir de Windows Vista, le paramètre de non-génération est activé dans la configuration d'origine et seule l'empreinte NTLM est calculée.

Les détails de cette démarche sont décrits dans l'article de la base de connaissances Microsoft KB 299656 « Comment faire pour empêcher Windows de stocker un hachage LAN Manager de votre mot de passe dans Active Directory et dans les bases de données SAM locales ».

Documentation :

Microsoft KB 299656 « Comment faire pour empêcher Windows de stocker un hachage LAN Manager de votre mot de passe dans Active Directory et dans les bases de données SAM locales » :
```
http://support.microsoft.com/kb/299656
```

3 Code malveillant et tunnel DNS

La technique de tunneling, bien que relativement ancienne (CF. note du 29 août 2001 du CERTA), continue d'être régulièrement déclinée et utilisée. Cette semaine des chercheurs ont publié des logiciels établissant des connexions bidirectionnelles, entre un shell et l'extérieur, et cela en utilisant le protocole DNS.

3.1 Comment cela fonctionne

Pour réussir à mettre en place un tel tunnel DNS, l'attaquant doit disposer d'un serveur de noms en charge d'un domaine qu'il maitrise tel que mondomaine.tld. Ainsi, toutes les requêtes à destination de XXXXXXX.mondomaine.tld seront traitées par ce dernier, et il suffit d'utiliser la partie XXXXXX pour faire sortir des informations. Pour envoyer des données dans l'autre sens, le serveur de noms impliqué peut utiliser le champ TXT resource record field, associé à l'adresse IP dans une réponse normale. Cette technique, qui permet de contourner un grand nombre de filtres, laisse des traces significatives dans les journaux des DNS locaux. Entre autre, de nombreuses requêtes vers le même domaine de base et avec des sous domaines illisibles et sans signification. Attention, les données présentes dans ces journaux peuvent avoir des caractères personnels, et leur utilisation demande une certaine prudence.

3.2 Documentation

Note d'information du CERTA du 29 août 2001, mise à jour le 7 octobre 2005, CERTA-2001-INF-003-001 :
```
http://www.certa.ssi.gouv.fr/site/CERTA-2001-INF-003/CERTA-2001-INF003.html
```

4 Rappel des avis émis

Dans la période du 12 au 18 mars 2010, le CERTA a émis les avis suivants :

CERTA-2010-AVI-119 : Vulnérabilité dans dpkg
CERTA-2010-AVI-120 : Vulnérabilités dans Apple Safari
CERTA-2010-AVI-121 : Vulnérabilité dans les produits HP Small Form Factor et HP Microtower PC
CERTA-2010-AVI-122 : Vulnérabilité du serveur HTTP d'IBM
CERTA-2010-AVI-123 : Vulnérabilité dans sendmail pour IBM AIX
CERTA-2010-AVI-124 : Multiples vulnérabilités dans OSSIM
CERTA-2010-AVI-125 : Vulnérabilité dans Skype
CERTA-2010-AVI-126 : Multiples vulnérabilités dans Google Chrome
CERTA-2010-AVI-127 : Vulnérabilité dans le module mm_forum de TYPO3

Durant la même période, les avis suivants ont été mis à jour :

CERTA-2010-AVI-081-001 : Multiples vulnérabilités dans Adobe Reader et Adobe Acrobat (mention de la branche 8x et mise à jour de la description.)

Gestion détaillée du document

19 mars 2010: version initiale.

CERTA
2012-01-04