Conficker.C : de peer en peer !
Par Fabien PERIGAUD, mardi 31 mars 2009 à 10:23 :: General :: #291 :: rss
Tout le monde l'a dit et répété, le 1er Avril 2009, la dernière variante en date du ver Conficker va commencer à générer des noms de domaine pour tenter de s'y connecter et rapatrier une potentielle charge malveillante.
Nous l'avons vu, le nouveau mécanisme de mise à jour repose désormais sur la génération de 50000 noms de domaine par jour, parmi lesquels 500 seront contactés afin d'essayer de télécharger une mise à jour. Statistiquement, cela correspond à la mise à jour d'1% des machines infectées en enregistrant un unique nom de domaine. Les auteurs seraient-ils décidés à réduire leur botnet à 1% de son étendue ?
Que nenni ! Les fonctions obfusquées présentes dans le corps du ver sont celles d'un redoutable mécanisme de communication Peer-to-peer, permettant à Conficker de communiquer avec ses pairs afin de propager une mise à jour. Le faible pourcentage de machines ayant téléchargé une mise à jour par le biais des noms de domaine pourrait ainsi communiquer celle-ci à l'ensemble des autres machines en toute (relative) discrétion.
Ce mécanisme, déjà étudié par le SRI, repose sur plusieurs threads gérant les communications avec les autres pairs, parmi lesquels deux threads s'occupant des communications UDP, et 2 threads pour les communications TCP. Une observation des paquets UDP envoyés donne l'impression d'une génération aléatoire du couple IP/port, et il serait intéressant d'établir un lien entre l'adresse et le port, afin d'avoir un moyen de détecter le trafic P2P du ver.
Une fois que l'on a tracé un peu l'exécution des différents threads, on retombe sur une même fonction chargée de générer les différents ports en fonction de l'adresse IP de la machine infectée et d'un paramètre que nous déterminerons par la suite.

Ce long bloc aux allures cryptographiques est présent deux fois dans la fonction. Le premier bloc ne prend en paramètre que l'adresse IP de la machine (dans le registre eax sur la capture précédente), et génère un premier couple de ports TCP/UDP dans esi et esi+4. Ceux-ci ne dépendent donc que de l'adresse IP. Avant l'entrée dans le second bloc, on note que le registre eax est xoré par le premier argument de notre fonction de génération.

Le second bloc est quasiment identique au premier, et résulte en la génération d'un nouveau couple de ports TCP/UDP dans esi+8 et esi+C.

L'argument passé à notre fonction est le résultat de la fonction appelée juste avant. L'étude de celle-ci nous montre que son résultat correspond à edx dans la capture suivante :

eax contient alors le timestamp de la date actuelle. On note que la valeur 0x54600 est retranchée à notre timestamp, ce qui correspond en secondes à 4 jours. Le timestamp est ensuite multiplié par 0x6EF5DE4D puis edx subit un décalage de ses bits de 12 vers la droite. Ces deux opérations combinées correspondent à une optimisation du compilateur pour effectuer une division par la valeur 604800, qui correspond elle-même au nombre de secondes dans une semaine. Notre paramètre est donc identifié, il s'agit du numéro de semaine depuis le 1er Janvier 1970 !
Une fois ces informations connues, il est possible de créer un outil prenant en paramètre une adresse IP et une date afin de déterminer les couples de ports TCP et UDP utilisés par le mécanisme peer-to-peer à cette date et pour cette adresse.
lexsi:~/conficker$ ./conficker_ports 192.168.111.2 05 02 2009 Used UDP ports : 45804 / 35543 Used TCP ports : 17116 / 62114
lexsi:~/conficker$ nmap 192.168.111.2 -P0 -p 1-65535 Interesting ports on 192.168.111.2: PORT STATE SERVICE 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 17116/tcp open unknown 62114/tcp open unknown
Il nous est ainsi possible de déterminer si du trafic non identifié est imputable à Conficker ou non, en vérifiant que l'adresse IP destination et le port correspondant sont conformes à l'algorithme. Mieux encore, il est possible de scanner le réseau à la recherche des ports TCP ouverts par le ver, ce qui, à la veille des tentatives de mise à jour de Conficker, serait fort judicieux !
Notons que les éditeurs de rogue-antivirus commencent à utiliser le buzz autour de conficker pour distribuer de faux produits de désinfection.