Depuis le mois de décembre et la première variante de Conficker, nous avons eu l'occasion de conseiller et d'assister certains de nos clients sur la méthodologie à adopter pour faire face à ce nouveau ver. Ce billet reprend certaines informations pratiques, en particulier sur une variante plus récente (Conficker.B, alias Downadup.B).

Comment se sortir de ce type d'infection généralisée sur tout un réseau d'entreprise, filiale à l'étranger y compris ? Dans le cas présent, la première chose à faire consiste à bloquer en sortie les résolutions DNS ou les flux vers les domaines utilisés pour les mises à jour du ver ; celui-ci ne pourra plus se mettre à jour et on pourra effectuer la désinfection sans que la cible ne soit "mouvante". F-Secure en fournit une liste régulièrement mise à jour. Simple à dire, ce point peut se révéler plus problématique que prévu (cas typique où le DNS est externalisé vers un prestataire pas toujours très réactif, ou dans le cas où un simple filtrage IP sur le pare-feu de l'entreprise ne servirait à rien, à cause des techniques de fast-flux notamment).

Pour la suite, la méthodologie est simple : on détermine les modes de propagation et on les supprime les uns après les autres.

Exploitation de la vulnérabilité MS08-067

La capture suivante montre une infection typique par ce biais (noter l'appel à NetPathCanonicalize) :

On remarque ici que l'exploitation se fait via l'interface \browser, l'accès à \srvsvc étant refusé. Dans le code d'exploitation, on remarque bien le motif "\..\..\" typique de MS08-067 :

Regardons plus précisément ce que l'exploit fait. On a pas mal de code de déchiffrement au début, comme celui-ci par exemple :

Un peu plus loin, la bibliothèque URLMON est chargée avec LoadLibraryA() :

Tout ceci afin de télécharger, via la fonction URLDownloadToFileA(), un fichier depuis la machine attaquante, donc infectée, sur un port que celle-ci avait choisi au hasard et préalablement ouvert (URL du type http://ip_attaquante:port_random/ chaine_random) :

On imagine que c'est une copie du ver qui est téléchargée pour être ensuite exécutée. Bien évidemment, le ver ajoute des exceptions au pare-feu Windows de la machine attaquante pour que les nouvelles machines infectées puissent accéder en toute tranquillité à ce fichier :

Pour se protéger contre ce biais d'exploitation, il n'y a pas 36 solutions : appliquer le correctif MS08-067 (KB958644) sur l'ensemble du parc (cela suppose bien sûr que le parc soit déjà migré au moins en Windows 2000 SP4, XP SP2 ou Vista), ou à défaut, une des solutions de contournement. Aucune régression fonctionnelle n'a été remontée suite à l'application de ce correctif, donc aucune raison a priori de ne pas le faire.

Propagation via ADMIN$

A ce moment du jeu, on arrive à désinfecter les quelques postes qui nous servent de témoin, avec éventuellement un petit coup de main manuel (et avec les signatures en version "beta" fournies par l'éditeur anti-virus). Mais au bout de quelques minutes, l'antivirus affiche malgré tout une alerte indiquant qu'une nouvelle instance à été trouvée sur le poste, et qu'elle a pu être supprimée (ou pas...). Nous avions heureusement pris soin de laisser tourner quelques Wireshark en arrière-plan et les différents PCAP obtenus sont riches en enseignements.

Une première capture montre que le ver se connecte via DCERPC à l'interface \samr :

Il utilise en particulier la fonction EnumDomainUsers afin de lister les comptes (si la machine attaquée est un contrôleur de domaine, cela retourne les utilisateurs du domaine ; sinon, cela retourne les utilisateurs locaux comme sur la capture ci-dessous) :

Pour chaque utilisateur ainsi trouvé, d'autres fonctions sont appelées :

Elles permettent au ver de récupérer diverses informations supplémentaires comme par exemple les dernières dates de connexion avec QueryUserInfo :

Une fois les utilisateurs énumérés, le bruteforce des mots de passe peut commencer :

Evidemment, si vous aviez appliqué la GPO de verrouillage automatique de comptes, cela entrainera le verrouillage de tout ou partie de vos comptes utilisateurs.

Tout ceci dans quel but ? Utiliser le partage administratif ADMIN$ afin d'y déposer une copie du ver :

Ceci explique pourquoi, sur une machine pourtant patchée, le ver revenait au bout de quelques minutes. Dans le détail, cela donne :

  1. connexion au partage ADMIN$
  2. requête Trans2 de type QUERY_PATH_INFO sur \System32 (dates, attributs, etc, peut-être pour vérifier que la connexion est bien établie)
  3. requête Trans2 de type FIND_FIRST2 sur \System32\ftahxx.dll (nom choisi au hasard). Réponse de la machine attaquée : STATUS_NO_SUCH_FILE
  4. requête NT Create AndX Request pour créer le fichier \System32\ftahxx.rc. Petite remarque : le ver demande à créer un fichier "super caché" (attributs caché et système) :

Le ver ne s'arrête pas là puisqu'il en profite aussi pour se connecter via DCERPC à l'interface \atsvc pour ajouter une nouvelle tâche planifiée via la fonction JobAdd :

Cette tâche démarrera le ver tous les jours à heure fixe et consiste à exécuter une fonction, ici nzyfqo(), de la bibliothèque préalablement déposée via ADMIN$ (cette tâche apparaitra comme AT1, AT2, AT3, etc, dans l'écran des Tâches planifiées) :

La détection de cette DLL est la suivante :

Pour endiguer la propagation du ver par ce moyen, il suffit de désactiver le partage administratif ADMIN$, par exemple via les valeurs AutoShareWks et AutoShareServer de la clé de registre HKLM\System\CurrentControlSet\Services\LanmanServer\ Parameters (attention, cela AURA des conséquences sur le parc).

Clés USB

Comme le ver se propage aussi via les clés USB, il est recommandé de désactiver Autorun et Autoplay. Idéalement, on formatera toutes les clés USB utilisées pendant la période d'infection.

Epilogue

Une fois que le ver ne se réplique plus sur le réseau, on peut estimer que le gros du travail a été fait. Le travail n'est cependant pas tout à fait fini puisque celui-ci, lors de son exécution, affecte la sécurité du système. Par exemple, il désactive le service BITS et Windows Update, en plus d'ajouter des exceptions au pare-feu Windows comme vu précédemment. La remise du parc dans son état pré-infection pourra donc prendre plus de temps que prévu.

On ne rappellera donc jamais assez l'urgence d'appliquer la mise à jour MS08-067 (KB958644), et de s'assurer de la robustesse de ses mots de passe, le risque n'étant pas seulement théorique.