Depuis la semaine dernière, nous voyons arriver dans nos boîtes à spam de nombreux messages ayant pour objet un soit-disant problème de livraison d'un paquet UPS. Le but est toujours le même : inciter la victime à exécuter le malware en pièce jointe par une dose d'ingénierie sociale.

Prise de contact...

Voici un exemplaire que nous avons reçu :

La pièce jointe est un fichier ZIP contenant un unique fichier exécutable. Celui-ci reprend l'icône des documents Microsoft Word afin de ne pas éveiller trop de soupçons. Cette pseudo-ruse peut sembler d'un autre âge, mais n'oublions pas par exemple que Windows Vista masque encore par défaut les extensions des fichiers connus...

Commençons par une analyse antivirale avec les principaux moteurs du marché. Comme malheureusement trop souvent, la détection par les anti-virus est décevante, seuls 7 sur 18 détectant notre échantillon (NB : quelques heures plus tard, ce nombre atteignait 13) :

Il s'agirait donc d'une variante de ZBot. Afin d'avoir une idée générale du fonctionnement du malware, poursuivons par une exécution du binaire en sandbox. Il se recopie sur le système sous le nom C:\WINDOWS\system32\ntos.exe :

Il modifie la clé Winlogon de HKLM pour assurer sa survie à chaque redémarrage du système, en y ajoutant le chemin vers ntos.exe :

Il crée aussi le répertoire wsnpoem pour y stocker des fichiers :

Côté réseau, le malware cherche à contacter un serveur russe via HTTP, certainement pour y chercher des mises à jour ou pour télécharger un fichier de configuration :

Unpacking

Les présentations étant faites, regardons de plus près de quoi le malware est fait. Premier réflexe, le packer est-il connu ? Une réponse négative nous étant donnée par PEiD, il va donc falloir y aller au radar.

Le but du jeu est d'arriver le plus tôt possible au point d'entrée original (OEP), sans nécessairement s'attarder sur chaque détail du packer (il ne s'agit pas de réaliser un unpacker par exemple). On peut tout de même s'attarder sur la récupération de l'adresse des fonctions. Tout se passe dans la fonction en 0x4014e6 :

• chargement d'une bibliothèque avec LoadLibraryA() (ici advapi32.dll)
• récupération en boucle de fonctions dans cette bibliothèque avec GetProcAddress() (ici RegDeleteValueA())
• boucle sur les bibliothèques restantes

Il faut rester vigilant lors de l'unpacking, le code se déchiffrant au fur et à mesure de l'exécution. Par exemple avant :

Apres :

Une fois le malware dépacké, reste à l'analyser (techniques de rootkit, chiffrement des flux, du fichier de configuration, etc), ce qui est une toute autre histoire...

Une vulnérabilité (Réf. Lexsi 10364) touchant les principaux serveurs DNS a été publiée aujourd'hui de manière coordonnée, les correctifs pour les produits Microsoft DNS et ISC Bind étant disponibles. Cette faille peut permettre à un attaquant de mener à bien des attaques de DNS Cache Poisoning, et donc de pratiquer du Pharming.

Concrètement le principe de l'attaque est connu depuis longtemps, des publications sur le sujet sont d'ailleurs datées de plus de deux ans. Le scénario mis en œuvre repose sur le fait que pour pouvoir forger une réponse DNS en lieu et place du serveur DNS légitime, il faut pouvoir connaitre l'adresse IP de ce serveur, la nature de la demande, le numéro de transaction DNS et enfin le port source utilisé par le serveur victime (celui qui effectue la demande). Avantage pour l'attaquant, pas de problème de session à gérer en couche 4, puisque le tout s'effectue en UDP.

S'il est facile de prévoir les deux premiers paramètres, le numéro de transaction DNS et le port source utilisés devraient être suffisamment imprévisibles pour empêcher l'usurpation. Et c'est semble-t-il la raison pour laquelle cette attaque est revenue sur le devant de la scène, car il s'avère qu'il pourrait être plus simple que prévu de deviner le numéro de port source utilisé par le serveur victime, ce dernier ayant tendance à ne pas utiliser tout l'espace des choix possibles, ou à avoir, en pratique, un espace restreint.

Ainsi, les serveurs DNS Bind choisissent par exemple un port source UDP au démarrage, puis le conservent pour toutes les requêtes à venir. Combiné au problème connu de l'espace restreint du choix du numéro de transaction DNS (codé sur 16 Bits, soit en théorie 65536 possibilités, mais incrémental sur certaines implémentations ...), cela réunit des conditions favorables pour tenter l'attaque.

D'après l'ISC, Dan Kaminsky, qui est à l'origine de la réaction des éditeurs, devrait publier tous les détails de l'attaque et de la vulnérabilité lors de la conférence Black Hat le 7 Aout. Prudence est mère de sureté, il y a donc peut-être des éléments importants qui n'ont pas encore été révélés.

C'est pourquoi dans l'attente il est important de corriger le problème sur les serveurs concernés, c'est à dire ceux qui effectuent des résolutions pour des domaines sur lesquels ils n'ont pas autorité, et en sachant que la correction joue plutôt sur l'augmentation de l'imprévisibilité du port UDP source utilisé.

Mise à jour

Toujours aussi peu d'informations sur cette vulnérabilité, mais ceux (ici et là) qui ont pu voir les détails confirment le caractère critique de la faille : il va falloir patcher !

Microsoft a publié hier soir un bulletin de sécurité concernant une vulnérabilité dans un contrôle ActiveX installé avec son logiciel Access, en versions 2000, XP et 2003. Les cas de publications de bulletins de sécurité de la part de Microsoft en dehors du célèbre Patch Day se comptent sur les doigts de la main, et sont souvent la conséquence d'une vulnérabilité particulièrement critique et exploitée "dans la nature".

La criticité de celle-ci n'est pas extrême, puisqu'elle ne permet que de faire télécharger un fichier à une victime, vers un répertoire arbitraire, en l'ayant incité à visiter une page web malveillante par le biais d'Internet Explorer. Une interaction avec l'utilisateur est donc nécessaire, et l'exécution de code arbitraire n'est possible que si l'attaquant arrive à faire enregistrer un binaire malveillant dans le répertoire "Démarrage" de sa victime, dont le nom varie avec les langues du système d'exploitation. Toutefois, une exploitation "dans la nature" a été identifiée, visant à faire télécharger un malware vers le répertoire ''c:\Documents and Settings\All Users\Start Menu\Programs\Startup''.

La vulnérabilité elle-même (Réf. Lexsi 10360) est plutôt simple, et provient du contrôle ActiveX "Snapshot Viewer" installé avec les versions d'Access précitées. Il suffit d'instancier ce contrôle en affectant certaines valeurs à certaines variables, et le malware se retrouve sur le disque de l'utilisateur infortuné.

Le malware identifié dans l'attaque actuelle est un "dropper" pour une bibliothèque enregistrée en tant que BHO d'Internet Explorer, c'est à dire qu'elle sera chargée en même temps que le navigateur, et détournera certaines de ses fonctions internes afin d'apporter les modifications qu'elle souhaite aux données transitant entre l'utilisateur et son fureteur. Cela lui permet de voler de nombreuses informations sensibles, parmi lesquelles :

• les mots de passe tapés dans les champs de type "password",
• les mots de passe enregistrés dans Internet Explorer,
• les mécanismes d'authentification de plusieurs sites bancaires ou de commerce.

Dans l'attente d'un correctif de la part de Microsoft, les utilisateurs d'Access sont invités à désactiver le contrôle ActiveX vulnérable, par une modification de la base de registre.