S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 10 avril 2009
N° CERTA-2009-ACT-015
Affaire suivie par: CERT-FR
le 10 avril 2009

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-15

Gestion du document

Référence CERTA-2009-ACT-015
Titre Bulletin d’actualité 2009-15
Date de la première version 10 avril 2009
Date de la dernière version 10 avril 2009
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 L’inclusion locale

1.1 Présentation

Cette semaine, le CERTA a traité un incident de sécurité relatif à la compromission d’un serveur Web. Cet incident a été révélé par la présence de contenu malveillant (du filoutage ou phishing). L’analyse des journaux a ensuite permis de mettre en évidence la présence et l’utilisation d’un outil malveillant de prise de contrôle à distance (un PHP Shell). Le téléchargement de ce fichier est en fait directement visible dans les journaux, l’attaquant a modifié dans sa requête Web le champ réservé à la présentation de la version de son navigateur (le UserAgent). L’attaque a ensuite consisté à inclure le fichier /proc/self/environ présent localement sur le serveur. Cette technique a permis à l’attaquant de contourner la mesure de protection qui se limitait à interdire l’inclusion de fichiers distants.

Cette attaque, aussi connue sous le nom de Local File Inclusion, est largement automatisée dans les codes malveillants. Il est pourtant assez simple de s’en prémunir. Il faut :

  • appliquer les correctifs de sécurité des applications et autres CMS utilisés ;
  • contrôler et valider systématiquement le contenu d’une variable avant de l’utiliser ;
  • protéger (voir interdire) l’accès aux ressources locales comme /proc/self/environ dévoilant la configuration du serveur.

Dans le cas d’hébergements mutualisés, toutes ces précautions sont rarement le fait de l’hébergeur. Le CERTA invite donc ses lecteurs à suivre ces bonnes pratiques afin de limiter les désagréments. Cet incident montre une nouvelle fois l’importance de la bonne gestion des journaux pour faciliter la compréhension de l’incident.

1.2 Documentation

2 Intrusion FTP

Le CERTA a traité cette semaine un incident dont le scénario est le suivant :

  1. une machine est infectée par un code malveillant ;
  2. l’utilisateur de cette machine se connecte au serveur FTP ftp.domain.tld et s’authentifie auprès de lui. Les identifiants de connexion sont interceptés par le code malveillant qui les transmet à un serveur distant sous contrôle d’attaquants ;
  3. un robot d’attaque se connecte quelque temps plus tard au serveur ftp.domain.tld et rejoue les identifiants de connexion. Il liste ensuite tous les fichiers des répertoires auxquels il a accès et télécharge (méthode RETR) tous les fichiers au format HTML. Il modifie quelques uns de ces fichiers en ajoutant du javascript et un iframe malveillants, puis il réinstalle (méthode STOR) ces fichiers. La durée de l’attaque est de l’ordre de quelques secondes ;
  4. plusieurs connexions font suite à cette attaque et il est difficile de dire s’il s’agit de robots ou non.

Après la découverte de cet incident, la réaction des administrateurs a été de modifier le mot de passe du compte FTP accédé frauduleusement. Cette décision peut paraître saine, mais elle ne suffit pas. En effet, le point de départ de cet incident est l’infection du client FTP. Le nouveau mot de passe positionné peut lui aussi être saisi par le code malveillant.

Dans un cas comme celui-ci, il est absolument indispensable de désactiver complètement le compte utilisé frauduleusement, tant que l’on n’a pas découvert quel poste client est infecté (il peut y en avoir plusieurs pour certains comptes partagés). D’autre part, dans la mesure où l’origine légitime des connexions FTP est connue (par exemple une adresse IP bien déterminée), il est particulièrement judicieux de mettre en place du filtrage afin de restreindre les accès.

3 Winemmem, un code malveillant original

3.1 Le fait

Cette semaine, un éditeur de solution antivirale a reporté l’existance d’une variante d’un code malveillant aux méthodes plutôt singulières. En effet, ce code malveillant réussit à s’insérer à l’intérieur d’une archive auto-extractible ou un fichier d’installation d’une application tout en passant les différents contrôles d’intégrité inclus dans ces différents formats.

3.2 La technique

Le code malveillant, nommé Winemmem par un éditeur d’antivirus, reussit à se camoufler grâce aux données supplémentaires (aussi appelée overlay) du format PE contenues dans les fichiers auto-extractibles et autres installeurs d’applications. Il réécrit la section code de l’application originale et réalloue une taille aléatoire de code du début de la section code et de l’OEP à la fin du fichier, augmentant ainsi la taille des données supplémentaires. Le virus ne crée pas de nouvelle section et ne modifie pas l’entête PE. Afin de prendre la main lors de l’éxecution du fichier infecté, le code malveillant réécrit le code original au point d’entrée (entry point).

À l’exécution du fichier compromis, le virus intercepte l’API CreateFileA() et recherche un fichier au format PE dans le répertoire Program Files. Il parcourt alors le fichier à la recherche d’une dll associée. Le code malveillant copie alors la dll dans le répertoire du fichier exécutable associé et l’infecte en modifiant l’entry point et en ajoutant sa charge utile à la fin de la dernière section. Il est ensuite capable de partir à la recherche de nouveaux fichiers exécutables sur des périphériques amovibles ou de récupérer de nouveaux codes d’une machine distante dès lors qu’il a été lancé.

Pour ne pas lever une alerte lors du contrôle d’intégrité des fichiers, le code malveillant restaure les données originales. Pour cela, il intercepte les fonctions d’une API contenue dans ntoskrnl.exe qui normalement empêche l’écriture ou la suppression d’un fichier en cours d’exécution ou vérouillé par un processus.

Le code malveillant contient également une routine d’interception des API ExitProcess() et ExitWindowsEx() afin de se recopier dans un fichier à la fermeture de l’exécution du fichier infecté ou de Microsoft Windows.

Cette technique permet à ce code malveillant de n’être reconnu que par très peu d’antivirus et peut poser des problèmes pour la désinfection.

3.3 Les recommandations

Le CERTA rappelle qui est important de n’exécuter que des fichiers de confiance. Il est ainsi recommandé de télécharger les installeurs sur le site de l’éditeur et de vérifer, lorsque celle-ci est disponible, la signature du fichier avant son exécution.

Rappel des avis émis

Dans la période du 30 mars au 05 avril 2009, 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 10 avril 2009
    version initiale.