1 Incident de la semaine
Campagne de fausses cartes de vœ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œ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 œ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
