Attaque par VPN Client

présentait une grande activité disque et une forte utilisation de CPU. J’ai ouvert Windows Task Manager et trié les processus sur le critère de l’utilisation de la CPU. Store.exe accaparait la plupart des cycles de CPU. L’entreprise en question n’était pas un gros utilisateur de e-mail et n’avait que 15 utilisateurs reliés au serveur. Avec si peu d’utilisateurs, Exchange ne devait pas consommer autant de ressources que ce serveur. J’ai aussitôt subodoré un stockage de courrier corrompu.

Identifier l’action de piratage. J’ai démarré Exchange System Manager (ESM) et sélectionné Administrative Groups, Admin_Group_Name, Servers, Server_Name, Protocols, Smtp, Default SMTP Virtual Server, CurrentSessions.

J’ai constaté que six sessions avaient été connectées au serveur virtuel SMTP pendant plus de 5 minutes : un indice de grave dysfonctionnement du serveur. En principe, une session Exchange Server ne dure que quelques secondes, sauf si elle est en train d’envoyer ou de recevoir un message avec une pièce jointe volumineuse. J’ai examiné les files d’attente du serveur virtuel SMTP par défaut et découvert plus de 50 files d’attente dans divers états d’envoi de courrier ou d’attente pour réessayer. A l’évidence, quelqu’un utilisait le serveur de courrier comme relais, mais comment ? Le serveur était doté des tous derniers packs de service (Win2K SP4 et Exchange 2000 SP3) er des dernières mises à jour critiques. Donc, j’ai utilisé le test ORDB’s (Open Relay Data-base) à http://www.ordb.org, qui recherche la présence de relais ouverts dans les systèmes hôtes soumis, pour s’assurer que le relais a été fermé.

Chaque fois que j’essayais d’éliminer une connexion vers le serveur virtuel SMTP par défaut, la connexion réapparaissait, généralement avec un nom de domaine différent mais à partir du même schéma IP. J’ai utilisé l’IANA pour suivre à la trace les adresses IP jusqu’à un bloc alloué par un ISP en Chine. Après avoir vérifié que le serveur n’était pas un relais ouvert, j’en ai conclu que quelqu’un était probablement en train de s’authentifier auprès du serveur et d’envoyer du courrier à partir de là. La sauvegarde était dépassée parce qu’elle essayait de sauvegarder tout le courrier que le spammer essayait d’envoyer. J’ai donc ouvert le snap-in Active Directory Users and Computers et supprimé tous les utilisateurs illégitimes. J’ai aussi trouvé quelques utilisateurs non autorisés dans l’Administrators Group et les ai aussitôt supprimés. Après quoi, j’ai consulté le registre et n’ai trouvé aucun programme de piratage chargé dans les sous-clés Run.

J’ai aussi appliqué une détection de virus sur le serveur, pour constater qu’il était propre et net.

Pour empêcher le spammer d’envoyer d’autres messages, j’ai déconnecté le pare-feu d’Internet et supprimé toutes les sessions actives en provenance du serveur Exchange. J’ai essayé d’utiliser ESM pour supprimer les messages provenant des files d’attente de courrier électronique, mais cette opération était trop longue. J’ai donc arrêté tous les services Exchange, ouvert une invite de commande et utilisé la commande Del pour supprimer les messages du répertoire D :\exchsrvr\mailroot\vsi 1\queue. Dès que j’ai arrêté les services Exchange, la performance du serveur s’est nettement améliorée. Malgré cela, il fallu plus d’une heure pour supprimer les 10 000 messages en file d’attente. J’ai ensuite examiné le répertoire bad-mail dans D :\exchsrvr\mailroot\ vsi 1\badmail. Huit heures de plus environ pour supprimer tous ces messages. Enfin, j’ai changé les mots de passe de tous les utilisateurs du réseau et créé une règle sur le pare-feu visant à refuser le trafic provenant des plages IP d’où émanait le spam. Après tous ces changements, j’ai reconnecté le pare-feu à Internet et surveillé le serveur. La connexion spam n’est pas réapparue.

Ce réseau particulier avait plusieurs sites distants munis de tunnels VPN. Sur l’un des sites distants, j’ai constaté que la machine distante contenait les programmes de piratage suivants : Bet.Mumu.A.Worm, Hacktool, W32.Valla.2048, W32.HLLW.Lovgate.J@mm, Bat.Boohoo.Worm et NSBlast.

De l’aveu de mon client, cet ordinateur fonctionnait en permanence avec le tunnel VPN actif. Dans ce genre de situation, il ne faut pas s’étonner que quelqu’un pirate un jour. Je recommande toujours que les clients à distance se trouvent derrière un pare-feu, particulièrement s’ils utilisent une connexion à large bande. Si vous utilisez XP sur une connexion commutée ou sans fil, soyez certains d’utiliser Windows Firewall de XP (précédemment ICF, Internet Connection Firewall) pour protéger votre ordinateur pendant qu’il est relié à Internet.

Réparer le dommage. J’ai reconstruit la station de travail, l’ai placée derrière le pare-feu TELE3 de SonicWALL et j’ai laissé au pare-feu le soin de recréer le tunnel vers le siège social. Heureusement pour ce client, l’intrus n’utilisait le serveur que pour envoyer du spam. Il aurait pu causer beaucoup plus de dégâts.

Leçons apprises. Depuis ce piratage, l’entreprise ne laisse plus les machines client utiliser un client VPN mobile sur une connexion à large bande, sans la présence d’un parefeu. Si vous avez des sites distants avec des tunnels VPN et des connexions à large bande, installez un pare-feu ou, au minimum, habituez les utilisateurs à arrêter leurs ordinateurs dès qu’ils sont inactifs. Vérifiez aussi que chaque utilisateur sait comment désactiver le tunnel VPN quand il n’est pas en service.