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

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 19 mars 2010
No 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œ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


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.)


Liste des tableaux

Gestion détaillée du document

19 mars 2010
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-03-27