Western Union est un système de transfert d'argent régulièrement critiqué pour son business model rapidement identifié comme outil facilitant le blanchiment d'argent des trafiquants, terroristes et autres cybercriminels. Il a ainsi été longtemps stigmatisé, fait l'objet d'amendes et de surveillances particulières par les autorités fédérales américaines. e-Gold a par exemple été l'objet de semblables attentions un peu plus tard. Aujourd'hui, d'autres systèmes de paiement en ligne de type WebMoney - basés souvent dans des juridictions plus laxistes sur ces problématiques - sont ainsi préférés, du moins pour la monétisation de fonds volés sur Internet par les cybercriminels.

Mais Western Union est également un établissement financier "traditionnel", et à ce titre, une cible de longue date pour les phisheurs. Cependant, nous n'avions que très peu de cas avérés de phishing visant les clients francophones de l'institution. C'est aujourd'hui chose faite avec ce faux site, hébergé sur un blog personnel canadien compromis (utilisant le CMS Wordpress, en version 1.5.2 datant de août 2005!) :

http://xxxxxx.ca/images/https/westernunion.fr/asp/SignIn/udpate-infos/westernunion/

L'information a été relayée à Western Union France, mais le site mis en ligne hier soir, avait d'ores et déjà été désactivé en fin de matinée.

Il est à noter qu'une fois les informations envoyées via un script PHP au fraudeur, la victime était redirigée sur le site... australien de Western Union. Une indication supplémentaire pour les (probables rares) personnes visées et tombées dans le grossier piège tendu par le pirate.

Tous les experts de la sécurité vous le diront : les cybercriminels se spécialisent, s'enrichissent, améliorent leurs techniques de fraude, développent de véritables modèles économiques basés sur la création et la propagation de malware bancaires toujours plus efficaces, toujours plus évolués et ciblant des volumes d'informations jamais atteints.

Et pourtant, en marge de cette course à l'innovation permanente issue de ce marché noir, le scammeur traditionnel (dit nigérian) continue d'appliquer les mêmes vieilles recettes d'ingénierie sociale, basées sur une duperie de premier niveau, sans ressource technologique ni maximisation des rendements, uniquement conçues autour de la confiance immédiate et naïve que certaines personnes accordent à la parole donnée. Sans même se préoccuper de la qualité générale des schémas d'escroquerie : anglais ou français approximatifs, sites Web de fausses banques de piètre qualité graphique... Le scammeur répand impertubablement ses promesses de récompenses à 6 chiffres (ou plus).

Autour de cette pratique, on a vu se développer des communautés de chasseurs de scams (ou "scambaiters"), qui mordent volontairement à l'hameçon, dialoguent avec les escrocs, et tentent d'inverser le processus en trompant celui qui tentait de les tromper.

Une des plus belles réussites dans cet exercice est à mettre au crédit d'un certain Arthur Dent. Son challenge brillamment réussi a consisté à convaincre un scammeur de la nécessité de recopier à la main les 293 pages d'Harry Potter et la chambre des secrets, de les scanner et de les transmettre par email !

Cette performance date de 2006, mais ce type d'exploit est intemporel et en terme de "reverse-scam", on a rarement fait mieux.

Un peu en avance sur la date, plusieurs courriels de spam infectent actuellement les boîtes de nombreux utilisateurs, en les incitant à visiter un site web dédié à la Saint Valentin.

Cette page incite l'utilisateur à télécharger le programme "withlove.exe", une nouvelle variante du ver Storm, qui est à l'heure actuelle détecté comme étant malveillant par seulement 5 antivirus sur une trentaine. Toutefois, aucune tentative d'exploitation de vulnérabilité n'est présente sur le site, contrairement à certaines pages qui proposaient le téléchargement d'anciennes variantes de Storm.

Voilà qui devrait encore grossir les rangs des machines zombies infectées par le ver, dont le nombre a été estimé à plusieurs millions au cours de l'année 2007. Rappelons d'ailleurs que Storm va fêter le 19 Janvier sa première année d'existence, et que le malware avait déjà profité de la Saint Valentin l'année dernière pour se propager. De manière générale, il a été constaté que les concepteurs du ver profitaient de nombreux évènements majeurs pour produire une nouvelle variante de leur progéniture (Noël, Nouvel An, Superbowl (!), Saint Valentin, Halloween, etc).

Après une rapide analyse, il s'avère que le malware tente cette fois-ci de s'injecter dans la bibliothèque "ntdll.dll". N'oubliez pas de mettre à jour vos bases de signatures et d'appliquer une vigilance constante vis à vis des exécutables en pièce jointe et/ou à télécharger !

En janvier 1986, Brain, considéré comme le premier virus ciblant les PC, avait pour conséquence la modification du MBR des machines infectées. Plus de 20 ans après, la découverte dans la nature d'un malware utilisant cette méthode à des fins de furtivité grâce à des techniques avancées de rootkit Windows, relance une nouvelle fois la course en avant sur les technologies virales.

Un logiciel malveillant utilisant une technique de rootkit Windows au niveau du MBR a été détecté dans la nature en décembre dernier. En raison de certaines valeurs codées "en dur", seul Windows XP est touché. Plusieurs milliers d'utilisateurs ont ainsi été infectés après une visite sur des sites de "drive-by-download", tentant d'exploiter des vulnérabilités connues (MS03-011 (Réf. Lexsi 2706), MS06-014 (Réf. Lexsi 6876), MS06-055 (Réf. Lexsi 7520) ou MS06-071 (Réf. Lexsi 7688) ou de forcer l'usager à exécuter un binaire malveillant (en le faisant passer pour un codec par exemple). Quelques temps après sa mise au jour, le malware en question était détecté par un petit nombre de solutions antivirales seulement. Chose amusante, il semble que l'équipe derrière ce nouvel exemplaire de virus ne soit autre que celle ayant déjà développé le désormais célèbre troyen bancaire "Torpig".

Rappels sur les virus de boot

Le MBR (Master Boot Record), premier secteur d'un périphérique de stockage de masse, contient, en plus de la table des partitions, du code originalement destiné à rechercher une partition de démarrage valide et à charger le secteur de boot de cette partition (VBR, Volume Boot Record). Evidemment, des chargeurs de boot comme Grub ou Lilo, non liés à un OS spécifique, remplacent ce code par le leur afin par exemple d'afficher un menu. En clair, il s'agit de la première portion de code à laquelle le BIOS passe l'exécution lors du démarrage de l'ordinateur. Elle s'exécute dans un mode spécifique du processeur x86, dit mode "réel", dans lequel l'accès direct aux routines du BIOS et aux périphériques est possible sans aucune restriction.

Comme dit en introduction, l'utilisation du MBR dans le cadre de logiciels malveillants n'est vraiment pas nouvelle. Le but est très souvent de détourner les interruptions BIOS, dont la 20ème est la plus connue : INT 13h est en effet l'interruption permettant l'accès aux services bas niveau de gestion des disques, permettant de lire ou d'écrire des secteurs précis. Détourner cette interruption permet de contrôler le déroulement des opérations de disque effectuées par le système d'exploitation au cours de son chargement, pour éventuellement les modifier. Parmi les autres interruptions intéressantes, citons par exemple INT 10h, utilisée pour la vidéo. L'avantage du code présent dans le MBR est qu'il s'exécute avant le chargement du système d'exploitation et peut donc contrôler le démarrage de celui-ci. Les virus MS-DOS utilisaient souvent ces méthodes ; l'inconvénient, pour les développeurs de virus, de l'arrivée de la famille des Windows NT (donc NT, 2000, XP, 2003, par opposition à 95, 98 et Millenium) est que cette phase MS-DOS lors du démarrage a été supprimée.

Premières preuves de concept : BootRoot (XP) et Vboot Kit (Vista)

En août 2005, Derek Soeder and Ryan Permeh de la société eEye présentent à la conférence Black Hat USA 2005 la preuve de concept BootRoot : il s'agit d'un MBR "maison" permettant de modifier le noyau de Windows pour y insérer des fonctionnalités de rootkit, sans affecter son bon fonctionnement. On peut ainsi parler d'un "portage" des concepts de modification de la MBR dans un contexte Windows NT. L'exemple présenté agissait au niveau NDIS (Network Driver Interface Specification, interface Windows en charge des communications réseau) afin d'y ajouter une porte dérobée réseau. En se basant sur BootRoot, les chercheurs d'eEye ont aussi développé SysRQ2, un live-cd ayant pour effet de pouvoir lancer un interprète de commandes avec les droits SYSTEM (ça peut toujours servir...) par une simple combinaison de touche Ctrl+Shift+SysRq.

Afin de bien comprendre comment se place un rookit MBR, il n'est peut-être pas inutile de rappeler les grandes étapes du processus de démarrage de Windows depuis un disque dur (la procédure depuis une disquette, un CD-ROM, un périphérique USB ou le réseau diffère légèrement) :

1. Après l'exécution du BIOS, celui-ci charge le premier secteur du disque, c'est-à-dire le MBR ;
2. Le code présent dans le MBR s'exécute en mode réel : traditionnellement, il localise une partition "bootable" dans sa table et exécute le premier secteur de celle-ci ;
3. Le "bootstrap loader" de Windows prend la main : il charge les 16 premiers secteurs de sa partition, puis charge et exécute NTLDR, toujours en mode réel 16 bit ;
4. NTLDR bascule en mode protégé 32 bit puis charge et exécute OSLOADER ;
5. OSLOADER analyse "boot.ini", exécute NTDETECT en mode virtuel 8086 (détection du matériel), met en place la pagination, charge HAL et NTOSKRNL, les pilotes de boot et met en place les ruches du registre ;
6. NTOSKRNL initialise le noyau et lance le processus utilisateur SMSS (Session Manager Subsystem) pour la gestion des sessions.

On voit donc que le code présent dans le MBR arrive en premier lieu dans le processus et que sa modification permet de contrôler toute la suite des événements.

Les rootkits MBR sont réalisables car Windows (sauf TPM) part du principe que rien de ce qui s'est exécuté avant son chargement n'est malicieux ; en particulier, il fait une confiance aveugle au BIOS. De plus, il considère que l'image mémoire d'un exécutable n'a pas pu être corrompue par l'INT 13 lors du chargement et lui passe directement la main (Vista effectuant quelques vérifications supplémentaires avant l'exécution). Aucun fichier n'est modifié sur le disque, tout est fait en RAM à la volée.

Pour mettre en place un rootkit MBR, BootRoot détourne l'interruption 13h. Lors de l'exécution de NTLDR, il pourra ainsi modifier OSLOADER en mémoire. La modification faite a pour but de localiser la liste des modules et d'y repérer "ndis.sys". Lorsqu'un paquet réseau est reçu, la macro "NdisMIndicateReceivePacket" est appelée et utilise une fonction sauvegardée dans le champ "PacketIndicateHandler" de la stucture "NDIS_MINIPORT_BLOCK" du pilote de miniport de la carte réseau, fonction appelée "ethFilterDprIndicateReceivePacket()". BootRoot modifie cette fonction par un simple JMP au point d'entrée et se garde ainsi un accès aux structures contenant les paquets afin de mettre en place une porte dérobée réseau.

En 2007, une nouvelle étape est franchie avec la démonstration, par Nitin et Vipin Kumar de NVLabs, à Black Hat USA 2007 de la preuve de concept Vboot Kit. Il s'agit grosso modo d'un portage des concepts de BootRoot sur Windows Vista, avec des vérifications d'intégrité supplémentaires à contourner. L'exemple donné modifie périodiquement le jeton de sécurité des processus "cmd.exe" pour leur donner les privilèges SYSTEM, en parcourant la liste chaînée de structures "E_PROCESS" décrivant chaque processus.

Le premier malware de ce type détecté dans la nature

Lors de l'infection, le logiciel malveillant retrouvé dans la nature remplace donc le MBR par sa propre version, et garde une copie de l'original dans le secteur 62 (voir ci-dessous pour l'explication). Un pilote Windows malicieux est stocké dans un espace libre, dans les derniers secteurs du disque. Le code présent dans le MBR aura pour effet de charger ce pilote de manière furtive, sans modifier le système, en particulier sa base de registre (sans modifier une clé Run ou ajouter un service par exemple), ni ajouter de fichier. Le rootkit MBR sera pleinement fonctionnel au prochain redémarrage.

Gmer donne la description suivante pour chaque étape de l'infection :

1. installation : en utilisant l'API "CreateFile()" sur le disque dur physique, copie du MBR original dans le secteur 62, écrasement du MBR par une version malicieuse, puis écriture dans le secteur 61 de la partie noyau du chargeur (voir plus bas) et écriture du pilote malicieux ;
2. exécution du code MBR au prochain redémarrage : détournement de l'interruption 13h pour contrôler les secteurs lus par NTLDR en vue de la modification du noyau de Windows (et non pas du pilote NDIS comme dans BootRoot), en particulier pour le chargement du pilote après appel à la fonction "nt!IoInitSystem" ;
3. chargeur de pilote : ouverture de "\??\PhysicalDrive0" pour récupérer le pilote malicieux caché, chargement avec une routine "maison" et exécution ;
4. pilote : mise en place d'une porte dérobée réseau et des fonctionnalités de rootkit (ex : détournements des IRP, voir ci-dessous).

Afin d'éviter une détection triviale, le rootkit détourne en effet certaines fonctions de la table "MajorFunctions" (MJ) du pilote de disque dur "\Driver\Disk" ("disk.sys"). Lorsqu'un IRP (I/O Request Packet) de type IRP_MJ_READ (lecture) est créé, il l'intercepte et si le secteur demandé est le premier, c'est-à-dire le MBR, il renvoie le MBR original qu'il avait pris soin de stocker dans le secteur 62. De même, un IRP dont la MajorFunction est de type IRP_MJ_WRITE (écriture) sera aussi contrôlé par le malware afin que le MBR ne puisse pas être modifié. Par contre, un anti-rootkit comme Gmer teste depuis longtemps si la table des IRP_MJ_* n'a pas été modifiée (ainsi que les premiers octets de chaque fonction), ce qui lui permet de détecter ce malware.

Comme précisé plus haut, ce malware particulier n'affecte pas Windows Vista car son processus de démarrage est assez différent de celui de Windows 2000 ou XP.

Comment se protéger contre ce type de logiciel malveillant ?

Tout d'abord, les cas réels d'infection ont eu lieu en exploitant des failles corrigées depuis longtemps par Microsoft ; l'application d'une veille sécuritaire sérieuse reste donc le premier rempart efficace. De plus, certains BIOS proposent d'empêcher la modification du MBR : cette fonctionnalité avait été créée du temps des premiers virus de boot, mais était un peu tombée en désuétude depuis. Enfin, il reste toujours possible de restaurer le MBR depuis un live-cd, la tâche étant facilitée par la sauvegarde créée par le virus lui-même dans le secteur 62. Mieux, la commande "fixmbr" ou "fdisk /mbr" depuis un CD d'installation de Windows remplace le MBR malicieux par une version saine.

Le problème de base est que Windows 2000/XP autorise depuis l'espace utilisateur la lecture et l'écriture de n'importe quel secteur du disque dur. L'argument "lpFileName" de la fonction de l'API Windows "CreateFile()" peut en effet prendre comme argument "\\.\PHYSICALDRIVE0" afin d'obtenir un accès "en dur" à tous les secteurs de ce disque. Dans Vista, l'écriture grâce à cette méthode n'est plus possible en espace utilisateur depuis l'attaque de Joanna Rutkowska sur le fichier d'échange ("pagefile.sys"), mais cette restriction ne s'applique pas aux premiers secteurs du disque, dont le MBR... Par contre, la fonctionnalité UAC (User Account Control) de Vista peut bloquer cette attaque si l'utilisateur refuse l'action.

Le malware repéré dans la nature en décembre dernier s'inspire de BootRoot. Est-ce à dire qu'eEye, par la publication d'une preuve de concept fonctionnelle, a facilité le travail des développeurs de virus (mode Troll ) ? Non, l'avancée vers ce type de logiciel malveillant était inéluctable car il s'agit de l'étape suivant les rootkits en mode utilisateur, puis les rootkits en mode noyau. BootRoot a peut-être simplement accéléré l'apparition du premier virus fonctionnel utilisant cette technologie, et donc aussi des protections pour le contrer.

Les campagnes de phishing ciblant les utilisateurs français de Paypal ne faiblissent pas. Nous avons identifié depuis le début de l'année au moins 12 sites frauduleux différents usurpant le site Paypal.fr. Le dernier en date est actif à l'adresse suivante.

Il utilise la nouvelle charte visuelle du site Paypal.fr, modifiée il y a 2 mois environ :

Il est signalé par les principales toolbars anti-phishing (Netcraft, Google Safebrowsing...) et le support de l'hébergeur anglais a été prévenu. Cet opérateur avait déjà hébergé un cas similaire le 13 décembre dernier.

Il est intéressant de noter que la racine du faux site présente un autre cas, mais qui utilise l'ancien template du site Paypal : http://warringsecurity.users47.XXXXXX.co.uk/

Le fichier processing.php de transmission des informations ne fonctionnent cependant pas/plus dans ce cas.

Les 2 kits de phishing Paypal France coexistent actuellement, mais la plupart utilise encore l'ancienne version Web du site Paypal et des spams francophones de mauvaise facture. Quelques phisheurs sont donc plus réactifs/professionnels que d'autres (ou moins fainéants. Voir à ce sujet cet article de Netcraft).

Microsoft a publié hier ses bulletins de sécurité mensuels en guise d'étrennes. Ceux-ci ne sont qu'au nombre de deux, dont un critique et un important, impactant toutes les versions supportées de Windows, de 2000 à Vista.

Là où les choses deviennent plus intéressantes pour qui aime les vulnérabilités croustillantes, c'est lorsque l'on apprend que le bulletin connu sous la référence MS08-001 corrige une vulnérabilité permettant d'exécuter du code arbitraire en mode noyau en envoyant plusieurs paquets malformés à un système vulnérable.

Les deux bulletins de ce mois-ci sont les suivants :

MS08-001 : vulnérabilités critiques dans la pile TCP/IP (Réf. Lexsi 9542), permettant :

• l'exécution de code arbitraire en mode noyau via des paquets IGMPv3 et MLDv2 spécialement formés ;
• un plantage du noyau via des paquets ICMP de type "Router Discovery Protocol" fragmentés spécialement formés.

MS08-002 : vulnérabilité permettant une élévation de privilèges dans le service LSASS, pouvant survenir lors du traitement d'appels de procédures locales (Réf. Lexsi 9541).

Si, comme dit précédemment, la vulnérabilité permettant l'exécution de code arbitraire en mode noyau et à distance peut paraître extrêmement critique au premier abord, Microsoft a publié sur son nouveau blog "Security Vulnerability Research & Defense" une analyse de la possibilité d'exploitation qui brise rapidement les rêves du script-kiddie s'imaginant déjà pirater la planète. En effet, les points suivants rendent l'exploitation assez difficile :

• consommation importante de ressources CPU lorsque la machine est attaquée, ce qui pourrait conduire au rejet de certains paquets ;
• la présence d'un "timer" aléatoire dans l'implémentation du protocole IGMP empêche les paquets de ce type de rester trop longtemps dans la pile du système.

La première condition va empêcher un attaquant d'envoyer ses paquets trop rapidement, sous peine d'en voir rejetés et de rater son attaque, tandis que la seconde l'oblige tout de même à les envoyer assez rapidement, sous peine de voir ses paquets supprimés de la pile avant la fin de l'attaque.

Malgré les publications rassurantes de Microsoft, il ne faut pas négliger l'impact de ces vulnérabilités, et penser à appliquer les correctifs au plus tôt.

Le Cert-Lexsi vous souhaite une très bonne année 2008 ! The Cert-Lexsi Team wishes you a happy new year 2008 !