1 Une architecture de gestion des machines zombies

1.1 Introduction

Les personnes malveillantes sont souvent astucieuses, mais dans le cas général, elles cherchent assez naturellement à simplifier leurs modes opératoires, et à tirer un maximum de profits pour une opération donnée. Ces dernières années, il est donc fréquent d’entendre parler de réseaux de machines compromises, ou « machines zombies », dirigées par un contrôleur central (le C&C ou Command&Control). Ces machines, massivement compromises, sont soumises aux directives de ce serveur, soit directement, soit indirectement, par le biais d’une chaîne de contrôleurs intermédiaires, pour rendre l’accès au C&C plus opaque.

Les objectifs pour construire de tels réseaux de machines compromises sont variés :

  • les utiliser comme relais de messagerie pour émettre des courriels indésirables (spam) ou utiles à une attaque par filoutage ;
  • diffuser des codes malveillants, sous forme de pièces jointes à des courriels ;
  • héberger des sites web frauduleux de filoutage ;
  • stocker des données (vidéos, images, codes malveillants) ;
  • attaquer en déni de service un serveur distant en synchronisation avec les autres machines zombies;
  • louer à qui veut un parc de machines afin qu’il profite lui-même des possibilités mentionnées ci-dessus ;
  • etc.

Le moyen de communication le plus fréquemment cité est l’IRC, qui peut se manifester par des trames échangées entre des machines internes au réseau et des machines distantes, vers leurs ports 6660-6670/TCP. Un très grand nombre de moyens de communication sont également possibles, afin d’utiliser des flux plus atypiques, comme ceux des données HTTP (pages, images), ou DNS, ou ICMP, etc. Il ne s’agit cependant pas ici de décrire certains types de canaux cachés, mais plutôt de montrer une évolution de cette architecture générale.

1.2 Architecture et astuces

Comme hypothèse, prenons un courrier de filoutage, contenant une adresse réticulaire www.Mauvais_SiteXX.net, redirigeant l’utilisateur vers une copie d’un site légitime.

Ce dernier, s’il découvre la supercherie, peut, soit mécaniquement par le biais d’un logiciel, soit manuellement, contacter le fournisseur d’accès pour signaler le comportement étrange de la machine W.X.Y.Z répondant au nom www.Mauvais_SiteXX.net.

Afin de rendre ces actions moins dangereuses pour leurs affaires, les personnes malveillantes utilisent parfois une architecture plus robuste. En voici les détails :

  1. la personne malveillante dispose d’un nom de domaine complet (ou FQDN, pour Fully Qualified Domain Name) : www.Mauvais_SiteXX.net ;
  2. elle dispose également d’un ensemble de machines compromises, ayant des adresses IPs distinctes : IP1, IP2, IP3, …IPn.
  3. les associations entre le nom de domaine et les adresses IPs précédentes changent très fréquemment, à partir par exemple d’un roulement régulier (round-robin) et d’une date d’expiration DNS (aussi appelée TTL ou Time-To-Live) très courte.

Pour la personne malveillante, cela permet de brouiller quelques pistes et de distribuer les charges de trafic vers les sites frauduleux.

Le scénario peut même impliquer deux groupes de machines compromises : celles contenant les sites de filoutage et celles servant de relais DNS.

Pour l’utilisateur, toutes les opérations se font à son insu. La figure 1 illustre une telle situation.

  • il clique sur un lien contenu dans un courrier électronique, qui cherche à atteindre www.Mauvais_SiteXX.net ;
  • pour contacter cette machine, une résolution de nom est nécessaire, et une requête est envoyée au serveur DNS (étape 1) ;
  • en considérant qu’il n’y a pas la solution en cache et que les dates d’expiration sont très courtes, la hiérarchisation DNS conduit l’utilisateur vers le serveur de nom du domaine Mauvais_SiteXX.net (étape 2) ;
  • ce serveur, pouvant également être un serveur compromis, ou une redirection vers un autre serveur DNS, retourne in fine une adresse IP, parmi celles disponibles et fonctionnelles du réseau de machines compromises (étape 3). Le choix de l’adresse peut varier toutes les minutes par exemple ;
  • le navigateur de l’utilisateur peut charger la page malveillante, car il a contacté l’une des machines compromises, ici IP2 (étape 4).
Figure 1: Architecture possible de l’utilisation d’un réseau de machines zombies
Image fluxDNS

1.3 Les moyens préventifs

1.3.1 Pour l’utilisateur

L’utilisateur, dans le scénario précédent, a voulu se rendre initialement sur le site www.Mauvais_SiteXX.net. Il est important de ne pas cliquer sur des liens inclus dans les corps des courriers électroniques, et de se rendre sur des sites de confiance, avec toutes les précautions nécessaires (interprétation de codes dynamiques désactivés).

Des mesures de filtrage par des listes dites « blanches » ou « noires » sont également possibles, par exemple à partir d’outils d’anti-filoutage. Cependant, ces solutions posent d’autres problèmes (origine de la liste, maintenance, faux-positifs, etc.) qui doivent également être pris en considération.

1.3.2 Détection au niveau des trames DNS

Il est souvent plus facile de filtrer les interactions des machines de son réseau avec le monde extérieur au niveau réseau (IP) et transport (TCP ou UDP par exemple). Dans le cas présent, il s’agit de filtrer à un niveau supérieur, afin d’empêcher des interactions avec certains noms de domaine. Des mesures peuvent être entreprises au niveau des serveurs de relais proxy, au moyen de règles et de listes blanches et noires.

L’administrateur peut également essayer d’analyser les trames DNS qui circulent. Les documents cités ci-dessous fournissent quelques pointeurs. Il s’agit de récupérer les réponses DNS (d’autorité si possible) (la requête se trouvant également incluse dans la trame réponse), et d’essayer d’en extraire les enregistrements les plus éphémères, ou le nombre d’enregistrements de type A ou NS retournés par requête. Les durées d’expiration de courte valeur sont également des critères d’observation.

Il faut cependant vérifier préalablement que cette collecte d’informations répond bien aux exigences de la politique de sécurité en vigueur.

1.4 Documentation associée

2 Révélation de mots de passe par certains logiciels

Cette semaine, IBM a confirmé une vulnérabilité1 découverte dans le client de messagerie Lotus Notes. En effet, le fait d’ajouter deux lignes dans le fichier de configuration du logiciel a pour conséquence de créer des informations de débogage dans un fichier, parmi lesquelles figure le mot de passe en clair de l’utilisateur. Voici ces deux lignes :

KFM_ShowEntropy=1
Debug_Outfile=c:\testvowe.txt

Ce mot de passe étant la pierre angulaire de la sécurisation de Lotus Notes, l’ajout de ces lignes dans le fichier de configuration est à proscrire.

Ce comportement n’est malheureusement pas isolé, et un grand nombre de logiciels sauvegardent des mots de passe dans des fichiers texte en clair. C’est notamment le cas de nombreux CMS (Content management System, ou Système de Gestion de Contenu).

Il est donc important de rester vigilant lors de l’installation de tout logiciel, et de vérifier le contenu des fichiers créés afin que ceux-ci ne mettent pas en défaut la sécurité de son système.

3 URL spoofing dans les navigateurs Internet

Dernièrement, plusieurs vulnérabilités ont été publiées concernant les navigateurs Firefox, Internet Explorer, Opera et Konqueror.

En ce qui concerne Firefox, des pages web malveillantes peuvent accéder au cache du navigateur via des URI de type wyciwyg:// (What You Click is What You Get). Celles-ci sont normalement inacessibles pour des utilisateurs, toutefois trois moyens différents contournant le contrôle d’accès ont été révélés par un chercheur. L’accès à l’URI wyciwyg permet notamment à un attaquant d’accéder à des informations confidentielles, d’injecter des données dans les documents, ou encore d’usurper la barre d’adresse URL. Cette vulnérabilité est corrigée dans la mise à jour 2.0.0.5 de Firefox, dont le contenu entier est détaillé dans l’avis CERTA-2007-AVI-318 du 18 juillet 2007.

La vulnérabilité dans Internet Explorer, qui utilise Javascript, consiste à empêcher une personne de quitter une page créée par l’attaquant tout en affichant correctement l’URL spécifiée par l’utilisateur. Le principe est d’appeler continuellement une fonction pour qu’elle soit invoquée avant la transition vers la page appelée. La particularité de cette faille est qu’elle fonctionne si l’utilisateur tape directement une URL dans la barre d’adresse. La vulnérabilité n’est pas corrigée et concerne au moins le navigateur Internet Explorer 7.

Enfin, la vulnérabilité concernant les navigateurs Opera et Konqueror est due à un mauvais affichage des URL data: qui contiennent des données. En effet, seule la fin d’une adresse URL est affichée dans une page web construite de cette manière. Il est donc possible de cacher la véritable URL en utilisant des caractères espace. Cette vulnérabilité est corrigée dans la version 9.22 d’Opera, dont le détail se trouve dans l’avis CERTA-2007-AVI-324 du 20 juillet 2007.

Ces trois vulnérabilités permettent donc de cacher les véritables URL des sites visités par un utilisateur. Elles seraient particulièrement efficaces dans des attaques par filoutage, par exemple. S’il est recommandé de taper des URL manuellement, la faille concernant Internet Explorer contourne cela. Cependant, celle-ci utilise du code Javascript, qui devrait être désactivé par défaut.

3.1 Références

4 Cycle de vie de php4

Le projet php dévelopeur du langage du même nom, a anoncé sur son site (http://www.php.net) que la branche 4.x de php ne serait plus maintenue à compter du 31 décembre 2007. Cela veut dire qu’à partir de cette date, il ne sera plus fourni de mise à jour ou de correctif de sécurité pour cette version. Le CERTA recommande vivement d’envisager dès à présent une migration vers la version 5.

5 Installation de pilotes sous GNU/Linux

Le constructeur Samsung propose des pilotes pour ses imprimantes et ses scanners sous GNU/Linux. Cependant, il semblerait que le programme d’installation exécute des opérations affaiblissant le niveau de sécurité du système. En effet si l’on examine le code du script shell d’installation on peut y trouver la section suivante :
       wrap_setuid_third_party_application xsane
       wrap_setuid_third_party_application xscanimage

wrap_setuid_ooo_application soffice wrap_setuid_ooo_application swriter wrap_setuid_ooo_application simpress wrap_setuid_ooo_application scalc

On peut ensuite examiner le code correspondant aux fonctions appelées ici :

wrap_setuid_third_party_application() {
       if echo « $1 » | grep -q « / » ; then
               APP_NAME=$1
       else
               APP_NAME=`which $1 2> /dev/null`
       fi
       NEW_NAME=${APP_NAME}.bin

if test -n « $APP_NAME » ; then if ! test -f « $NEW_NAME » && ! test -d « $NEW_NAME »; then mv « $APP_NAME » « $NEW_NAME » cp -af /opt/${VENDOR}/mfp/bin/suwrap « $APP_NAME » chown root:root « $APP_NAME » chmod 4755 « $APP_NAME » fi fi }

wrap_setuid_ooo_application() { WRAPPING_BIN=`ls /usr/lib*/*/program/$1.bin /opt/*/program/$1.bin 2> /dev/null | head -1` if test -n « $WRAPPING_BIN » ; then ${2}wrap_setuid_third_party_application $WRAPPING_BIN fi }

Dans les faits, cette partie de code, rend root propriétaire des exécutables soffice, swriter, etc. et positionne le bit SUID sur ces fichiers. Ceci revient à demander au système d’exécuter les exécutables de la suite OpenOffice.org en tant qu’administrateur en permanence quelque soit l’utilisateur lançant ces commandes.
Le CERTA recommande donc de modifier soit le script d’installation en remplaçant chmod 4755 par un chmod 0755 ou bien d’effectuer cette opération a posteriori : chmod 0755 soffice swriter simpress scalc dans le répertoire où ils se trouvent.

Rappel des avis émis

Dans la période du 09 au 15 juillet 2007, le CERT-FR a émis les publications suivantes :