S.G.D.S.N

Agence nationale
de la sécurité des
systèmes d'information

Paris, le 19 octobre 2007
N° CERTA-2007-ACT-042
Affaire suivie par: CERT-FR

Bulletin d'actualité du CERT-FR

Objet: Bulletin d'actualité 2007-42

Gestion du document

Référence CERTA-2007-ACT-042
Titre Bulletin d'actualité 2007-42
Date de la première version19 octobre 2007
Date de la dernière version19 octobre 2007
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 Serveurs Web et fichiers de mots de passe

Lors du traitement d'un incident récent, le CERTA a découvert un fichier contenant des mots de passe disponibles depuis l'Internet. Les mots de passe de ce fichier n'étaient pas « en clair ». Toutefois, l'utilisation d'un outil dédié aux tests de robustesse des mots de passe a permis de trouver le texte clair de ces derniers.

La découverte de fichiers de mots de passe sur les serveurs Web est relativement aisée. Généralement, l'utilisation d'un moteur de recherche peut suffire. L'accès à de tels fichiers peut mener à la compromission des mots de passe, qui peuvent ensuite être utilisés pour accéder à des pages à lecture restreinte, ou encore pour se connecter à certains services de la même machine (parfois du même réseau). Dans certains cas, les mots de passe apparaissent en clair dans les fichiers.

Le CERTA recommande :

  • de ne jamais stocker de mots de passe en clair dans des fichiers ;
  • d'éprouver la robustesse de ces mots de passe à l'aide d'outils dédiés et hors-ligne ;
  • de restreindre l'accès à certains fichiers qui, par nécessité, doivent se trouver sur des serveurs.

2 Les listes noires de messagerie

Cette semaine, le CERTA a traité un incident relatif à la messagerie. Suite à une modification de son architecture de messagerie, une administration s'est vue rejeter tous ses courriers électroniques par certains destinataires. Suite à l'analyse des message de retour, les responsables de ce serveur de messagerie ont constaté qu'ils avaient été mis sur des listes noires (blacklist).

Il existe de plus en plus de listes noires sur l'Internet. Des sites permettent de vérifier la présence d'une adresse IP dans celles-ci. C'est le cas par exemple de robtex qui vérifie dans plus d'une centaine de listes noires :

http://www.robtex.com

La plupart de ces listes tentent d'expliquer de manière plus ou moins claire leurs critères de bannissement et certaines proposent une procédure de retrait d'une adresse IP. Les listes noires se basant sur les adresses IP émettrices, il est facile pour des virus et autres émetteurs de courriers non sollicités de les contourner en utilisant une nouvelle adresse IP ou en essayant d'infecter une nouvelle machine.

2.1 Une mauvaise configuration

Dans le cadre de cet incident, la présence de l'adresse IP dans certaines listes noires s'explique par une mauvaise configuration de la nouvelle architecture de messagerie. En effet, lors d'une connexion SMTP, le nouveau serveur de messagerie ne se présentait pas correctement :

  • pendant une connexion SMTP, la manière correcte de se présenter est : 
            EHLO <nom de domaine de messagerie ou adresse IP>
  • la mauvaise manière (laissée dans une configuration par défaut) est : 
            EHLO

Il est assez facile de contrôler la bonne présentation d'un serveur en regardant l'en-tête d'un courrier reçu par celui-ci :

Received: from <nom de domaine ou adresse IP pr�sent� par le serveur> 
(<nom r�solu par le serveur recevant la connexion> [ADRESSE IP R�elle])

Exemple :

    Received: from mail.certa.ssi.gouv.fr (mail.certa.ssi.gouv.fr [213.56.176.1])

2.2 Une réaction hâtive

Le second problème intervenu dans cet incident est qu'avant de corriger totalement leur problème de configuration, les administrateurs ont tenté de réaliser les procédures de retraits des listes noires, quand cela était possible. Mais, afin de limiter les abus, certaines listes noires n'autorisent qu'une ou deux tentatives de retrait par jour. Le CERTA a pu débloquer la situation après s'être assuré avec les administrateurs de la bonne configuration du serveur de messagerie.

Il faut noter que des codes malveillants vérifiant la présence d'une adresse IP dans les listes noires peuvent tenter d'épuiser le nombre de possibilités de retraits qu'ont les administrateurs. Il devient alors impossible de se « désinscrire » des listes.

2.3 Ce qu'il faut en retenir

La mise en production d'une nouvelle application nécessite une vérification approfondie de son fonctionnement : tests de non-régression, maquettes, ...

Le CERTA constate que de plus en plus de listes « noires », « grises » ou « blanches » apparaissent sur l'Internet. Ces listes utilisent des critères parfois arbitraires et il est souvent très difficile de comprendre les raisons exactes de leur choix. D'autre listes se basent sur des listes tierces et sont incapables de supprimer une adresse listée. Ces listes doivent être utilisées avec beaucoup de précaution et il est impératif de garder la possibilité de contourner une mise en liste noire abusive.

Documentation associée

3 Les services de redirection gratuits par Internet

3.1 Incident traité cette semaine

Le CERTA a traité cette semaine le cas d'une défiguration de site. Il apparaît, après analyse, que le serveur hébergeant le site n'a pas été compromis. En revanche, la défiguration est due à un phénomène bien particulier : la page se visite par le biais d'une adresse réticulaire (URL), incluant un nom de domaine particulier, géré par une société tierce. Celle-ci doit en principe rediriger toute requête vers le site légitime. Dans le cas présent, le système de redirection de cette société tierce a été détourné vers un site malveillant.

Les détails de cette méthode, et les problématiques qu'elles comportent sont décrits ci-dessous.

3.2 Un service de redirection

Il existe sur Internet la possibilité d'acquérir gratuitement des noms de domaine. Ces noms peuvent être de la forme [monSite].[LESERVICE].[TLD] avec :

monSite
qui est le nom désiré pour le site administré.
LESERVICE
qui est tout ou partie du nom du service qui offre gracieusement la possibilité de créer son nom de domaine (presque) sur mesure ;
TLD
qui correspond au Top Level Domain, par exemple .fr, .org ou .com.

Ces extensions permettent d'avoir une ou plusieurs adresses URL pointant sur un seul et même site A :

http://[monSite1].[LESERVICE].[TLD]/index.html => page index.html de site A 
http://[monSite2].[LESERVICE].[TLD]/index.html => page index.html de site A

Seulement il ne s'agit pas d'entrées dans un serveur DNS. Il s'agit d'une redirection de pages. Les différentes interactions sont donc :

  1. l'utilisateur navigue et cherche à se rendre sur [monSite1].[LESERVICE].[TLD]/index.html ;
  2. une requête DNS lui indique que ce site se trouve sur une machine du service [LESERVICE].[TLD] ;
  3. le navigateur cherche alors à récupérer la page d'accueil sur cette machine ;
  4. cette dernière redirige par du code HTML l'utilisateur vers le vrai site où se trouve la page index.html attendue.

Le CERTA tient à attirer l'attention sur les risques que peuvent engendrer l'utilisation de tels services.

Dans le cas de l'incident traité, les machines physiques ne sont pas sous la maîtrise des responsables du service de redirection. Ils utilisent des machines virtuelles pour y mettre les pages de redirections, et ces machines sont installées sur un poste hôte maintenu par une autre société. Ces serveurs peuvent être compromis et toute modification de la page de redirection donnera l'impression que c'est le site original qui a été compromis.

De plus ces serveurs peuvent héberger plusieurs redirections de sites et donc poser des problèmes d'image lorsqu'une même adresse IP est associée à des sites peu recommandables. Les redirections se font de manière générale via une redirection de cadres (frame). Les autres cadres de la page permettent l'intégration de publicité, contre partie de la gratuité.

La redirection par cadre peut prendre la forme suivante :

<_html>
 <_head>
  <_title>Titre de la page</title>
 <_/head>
  <_frameset rows="20,*" frameborder="NO" border="0" framespacing="0">
  <_frame name="pub" /publicite.html noresize scrolling="no">
  <_frame name="principale" http://adresse_du_site_A/index.html>
 <_/frameset>
<_/html>

Il faut également avoir conscience que toute visite d'un internaute vers le site A passe au préalable par une requête vers le site de [LESERVICE].[TLD] (étape 3). Cette requête est journalisée.

La société tierce peut donc savoir :

  • quels internautes se rendent sur le site A ;
  • à quelle heure ils s'y rendent ;
  • depuis quelle adresse IP ils s'y rendent ;
  • le navigateur utilisé par l'internaute ;
  • depuis quel site il se rend sur le site A ;
  • etc.

Ce sont donc des données collectées à l'insu de l'utilisateur, et ce dernier n'a pas moyen de savoir qu'elles seront les exploitations faites de ces dernières.

Toutes ces raisons amènent le CERTA à vivement déconseiller de tels services. Ils peuvent provoquer la méfiance des internautes, et ils apportent dans tous les cas une surface supplémentaire d'attaques pour défigurer des sites.

4 Mise à jour de la liste des logiciels obsolètes

La liste des logiciels obsolètes maintenue dans la note d'information CERTA-2005-INF-003 a été mise à jour pour ajouter les deux sections suivantes :

  • les versions de php supportées : la version 4 sera obsolète à la fin de l'année.
  • les versions de Microsoft Office encore supportées : 2000, XP, 2003 et 2007.

Le document est disponible à l'adresse suivante :

http://www.certa.ssi.gouv.fr/site/CERTA-2005-INF-003/

5 Deux formats d'actualité

5.1 Les documents au format PDF

Le CERTA a publié le 10 octobre une alerte concernant la vulnérabilité dans le traitement des URI sous Windows. La présence d'Internet Explorer 7 est un pré-requis pour l'exploitation de cette vulnérabilité, qui peut alors être provoquée par plusieurs applications tierces.

L'une d'elles est l'interprétation de fichiers PDF (Portable Document Format) par des lecteurs comme Adobe Acrobat Reader. Des preuves de faisabilité ont été assez largement publiées sur l'Internet, et leur modification n'est pas très complexe. Des commandes peuvent ainsi être exécutées à l'insu de l'utilisateur, au moment de l'ouverture d'un document spécialement construit.

Dans l'attente d'un correctif par Microsoft, le CERTA recommande la plus grande méfiance vis-à-vis de ces documents. Ils peuvent se caractériser par l'existence de la chaîne de caractères mailto:% dans le code source. Adobe a également publié dans son avis de sécurité du 05 octobre 2007 quelques mesures préventives :

http://www.adobe.com/support/security/advisories/apsa07-04.html

5.2 Les documents au format DOC

Le CERTA a publié le 10 octobre 2007 l'avis de sécurité CERTA-2007-AVI-430. Celui-ci concerne le logiciel bureautique Microsoft Word, et présente le correctif de Microsoft décrit dans son bulletin MS07-060.

Le CERTA a, depuis, été informé de l'existence de documents Word tentant d'exploiter la vulnérabilité décrite (CVE-2007-3899). Symantec a par ailleurs signalé le 14 octobre 2007 l'existence d'un Cheval de Troie similaire, utilisant cette vulnérabilité, et prénommé Trojan.Mdropper.Z. Il se présente actuellement sous la forme d'un document .doc intitulé hope see again.doc. Il tente alors d'exécuter du code sur la machine ayant une version vulnérable, et cherche ensuite à correspondre en TCP via le port 80 vers un site distant.

Il est donc important de vérifier que les versions d'Office sont à jour, et le CERTA recommande également la plus grande méfiance à l'ouverture de tels documents. Il est important de ne pas ouvrir de fichiers dont la source n'est pas de confiance, notamment en pièce jointe d'un courriel.

6 Evénements sous Windows

Les événements sous Microsoft Windows sont souvent délaissés par les administrateurs car la documentation les concernant peut être difficile à trouver ; de plus, à chaque nouvelle version de Windows des changements sont apportés par Microsoft. Puisqu'il est impossible d'être exhaustif et de détailler chaque événement selon le système utilisé, cet article a pour but de fournir au lecteur quelques pointeurs pour obtenir des documentations officielles concernant les événements.

En ce qui concerne Windows 2000, un article en deux parties de la base de connaissances KB299475 de Microsoft liste et détaille les événements de sécurité du système d'exploitation.

Une documentation concernant les événements de sécurité dans Windows Server 2003 est également disponible en ligne sur le site de Microsoft, dans le chapitre 4 du guide de sécurité (Windows Server 2003 Security Guide). Les événements sont ici groupés par catégorie (connexions au système, gestion des utilisateurs, utilisation de privilèges...) ce qui peut aider pour le choix de la politique d'audit, mais sont peu détaillés.

Le site Technet Events & Errors Message Center permet d'obtenir plus de détails concernant les événements particuliers que l'on spécifie via un moteur de recherche. Seuls les systèmes Windows 2000 et 2003 semblent supportés.

Enfin, concernant Windows Vista et le futur Windows Server 2008, aucune documentation officielle de la part de l'éditeur n'a été publiée pour le moment, mais un article devrait paraître dans la base de connaissances.

Toutefois, l'utilitaire en ligne de commande wevtutil (Windows Events Command Line Utility), qui sert à gérer les événements sur ces systèmes, peut donner beaucoup d'informations sur ceux-ci. Ainsi, la commande wevtutil gp Microsoft-Windows-Security-Auditing /ge /gm:true /f:xml listera au format XML tous les événements disponibles pour la catégorie Microsoft-Windows-Security-Auditing. Toutes les catégories sont visibles avec la commande wevtutil el. Il est ainsi possible d'obtenir un descriptif de tous les événements du système.

6.1 Documentation

7 Les canaux de communication et les réseaux de machines zombies

7.1 Des exemples de canaux de communication

Des machines compromises peuvent être gardées sous contrôle, afin de créer un réseau de zombies. Ce dernier peut alors être utilisé à différentes fins, comme l'envoi de courriers non sollicités ou le lancement d'attaques distribuées en déni de service. Il y a a fortiori un canal de communication, qui permet aux personnes malveillantes, directement ou pas, de commander ce réseau, afin de lui signaler les actions à entreprendre.

Le plus populaire des canaux de communication pour ces réseaux est IRC. Ce dernier est assez facilement identifiable par une analyse réseau. Sa mise en œuvre se fait fréquemment avec l'utilisation du port TCP 6667, même si tout autre port est en théorie possible. Le client peut utiliser un proxy, et le serveur peut être configuré pour écouter sur le port de son choix. Une première surveillance au niveau du pare-feu périmétrique de toute tentative de connexion utilisant ces ports en particulier est donc un signe d'utilisation d'IRC. L'analyse de la machine infirme ou confirme ensuite que ce canal de communication est utilisé à des fins malveillantes.

Le CERTA a mentionné dans différents bulletins d'actualité cette année, notamment CERTA-2007-ACT-034, l'existence du ver Storm Worm. Celui-ci, aussi nommé par certains Zhelatin, a la particularité d'utiliser le réseau pair-à-pair Overnet pour communiquer, et prendre connaissance des commandes à exécuter. Les échanges se font de la même manière qu'un utilisateur normal, avec les différents types de requêtes :

  • Publicize pour annoncer aux voisins son existence, et identifier les ressources disponible (UDP) ;
  • Connect pour commencer des transferts de données (TCP) ;
  • Search pour chercher des ressources particulières parmi les nœuds voisins.

Il ne s'agit pas ici de décrire le fonctionnement de Storm, mais de signaler que certains comportements dans un réseau local de taille modeste peuvent mettre en évidence son existence. Outre les différents échanges mentionnés précédemment, une simple augmentation du trafic UDP peut déjà éveiller les premiers soupçons, ainsi que l'apparition de certains éléments dans les en-têtes TCP ou UDP (identifiant de protocoles, ports de destination, etc.).

7.2 BlackEnergy

Récemment, une étude est apparue et a décrit en détail un autre type de réseau de machines zombies. Ce réseau se nomme BlackEnergy et a pour principale motivation les attaques en déni de service, du moins à la date de l'analyse effectuée.

Ce réseau en lui-même consiste selon l'auteur en peu de machines. Son activité est pour le moment restreinte à des machines localisées en Asie et en Europe de l'Est. Ce qui est intéressant dans BlackEnergy, en revanche, c'est son mode de communication qui s'appuie sur des requêtes HTTP valides. Des serveurs Web sont compromis et l'utilisation de PHP et MySQL de ceux-ci est détournée. Les machines compromises cherchent alors leurs instructions sur ces serveurs par des requêtes HTTP en mode POST. Dans l'exemple décrit par l'article, il s'agit d'une requête de la forme :

POST /dot/stat.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
.NET CLR 1.1.4322)
Host: **********
Content-Length: 31
Cache-Control: no-cache
id=xxxxxxxxxxxxxxx&build_id=yyyyy

Il inclut dans l'en-tête son identifiant.

Le serveur lui répond en retour :

HTTP/1.1 200 OK
Date: Tue, XX Sep 2007 08:30:13 GMT
Server: Apache/2.0.59 (Unix) FrontPage/5.0.2.2635 PHP/5.2.3
mod_ssl/2.0.59 OpenSSL/0.9.7e-p1
X-Powered-By: PHP/5.2.3
Content-Length: 80
Connection: close
Content-Type: text/html
MTA7MjAwMDsxMDswOzA7MzA7MTAwOzM7MjA7MTAwMDsyMDAwI3dhaXQjMTAjeENSMl8yN
(...)

La dernière ligne de données transmises correspond à la commande attendue. Elle peut préciser les paramètres d'une attaque par inondation de trames, ou d'un fichier à télécharger et à exécuter.

La question est donc : que peut-on détecter ?

Des initiatives envisageables sont :

  • l'identification des requêtes vers le serveur distant, si celui-ci est connu comme étant compromis ;
  • des recherches de contenus sur des chaînes de caractères particulières, mais pouvant provoquer beaucoup de fausses alertes, ou faux positifs.

Le lecteur comprendra ici que les moyens d'identifier ce canal de communication ne sont pas simples à mettre en œuvre.

7.3 Le fond du problème

Les exemples précédents montrent la complexité à identifier les canaux de communication de manière précise. Si ceux-ci sont bien connus, des heuristiques peuvent aider à les trouver (IRC), mais les méthodes déployées par les codes malveillants sont toujours plus furtives (recours à Overnet, HTTP, POP3, etc.). Dissimuler un canal de communication est faisable par le biais de multiples méthodes. Le détecter est beaucoup plus complexe.

Suite à la médiatisation du ver Storm Worm, des signatures sont apparues pour aider des administrateurs de réseaux à identifier des machines compromises qui communiquent. Ces signatures doivent venir enrichir la base de connaissance d'une sonde détection d'intrusions.

Le CERTA tient cependant à attirer l'attention sur le fait que ces signatures sont bien sûr intéressantes, mais ne représentent pas l'approche la plus pertinente pour combattre ces activités.

La détection des canaux de communication est une opération complexe, qui peut s'avérer impossible, et le premier effort consiste à prévenir le danger.

Dans tous les cas présentés auparavant, les machines ont d'abord été compromises.

Storm Worm se propage par plusieurs vecteurs, dont l'un est une simple technique d'ingénierie sociale (clic et installation de fichiers exécutables), et un autre une exploitation de vulnérabilités dans des navigateurs qui ne sont pas à jour et qui ont une configuration trop laxiste.

BlackEnergy contamine des serveurs Web, en ajoutant des tables MySQL particulières et des pages PHP.

Quelques mesures simples sont donc suffisantes, en principe, pour se prémunir de telles activités :

  • les systèmes et les applications installées doivent être à jour ;
  • l'utilisation standard d'un poste de travail doit se faire avec des privilèges limités ;
  • la navigation doit se faire depuis un navigateur correctement configuré, n'interprétant pas les codes dynamiques par défaut. Il est préférable de se limiter également à une navigation sur des sites de confiance.
  • l'intégrité des pages et des services d'un serveur doit être régulièrement vérifiée.

L'effort doit être mis en priorité dans l'application de ces mesures. L'investissement s'applique ainsi contre plusieurs codes malveillants. La détection par signatures, quant à elle, ne vient qu'en complément, car elle tend à être, par définition, propre à quelques variantes de codes : la signature ne caractérise au mieux qu'un trait particulier d'un canal de communication, et parfois de manière inexacte.

8 Nouvelles fonctionnalités Vista

Dans son nouveau système d'exploitation, Vista et dans la future version serveur de celui-ci (Windows 2008 Server), Microsoft a inclus certaines fonctionnalités d'administration à distance. Il y a en particulier le service WinRM (Windows Remote Management). Ce dernier permet à un administrateur d'accéder à certaines fonctionnalités d'inventaire ou de diagnostics d'une machine sous Windows Vista à distance. Cette commande avec des paramètres bien choisis donne aussi la possibilité d'obtenir des informations très utiles en vue de conduire une attaque.

Par ailleurs, il existe une autre commande nommée WinRS (Windows Remote Service) dont la finalité est de permettre à un administrateur d'exécuter des commandes sur une machine distante. Grâce à ce service, il serait donc possible de lancer une installation d'un logiciel ou d'exécuter une commande système.

Ces deux fonctionnalités ne sont pas activées par défaut dans Windows Vista.

Recommandations :

Dans ce contexte, il est impératif de définir précisément un périmètre d'utilisation de ce genre de services. En effet, ces commandes peuvent tout à fait être inclues dans des scripts VB pour en automatiser l'utilisation. Le CERTA recommande donc de bien vérifier que ces services sont désactivés par défaut s'ils ne sont pas utilisés.

Dans l'hypothèse où ces services sont nécessaires, il conviendrait d'accompagner cette activation par des mesures visant à limiter leurs accès de manière rigoureuse et à journaliser leur utilisation.

Rappel des publications émises

Dans la période du 08 octobre 2007 au 14 octobre 2007, le CERT-FR a émis les publications suivantes :


Durant la même période, les publications suivantes ont été mises à jour :

Gestion détaillée du document

    le 19 octobre 2007
    version initiale.