Attaque par Exchange Server SMTP AUTH

100, avec un nombre important de messages dans chacune d’elles. A l’aide de ESM, j’ai inspecté les messages de plusieurs files d’attente au hasard. J’ai découvert des messages dont l’envoyeur ou le destinataire ne provenait pas du domaine local, signe que le serveur de e-mail était probablement utilisé comme un relais. Par défaut, Exchange 2000 et les systèmes ultérieurs permettent le relais si l’envoyeur d’un message peut s’authentifier correctement vis-àvis du serveur de courrier électronique.

Identifier l’attaque. Les pirates peuvent obtenir un nom d’utilisateur et un mot de passe valides par différentes méthodes. Ils peuvent essayer de deviner répétitivement le mot de passe d’un invité ou d’un utilisateur, jusqu’à en rencontrer un de valide, ou bien ils peuvent lancer une action pirate pour obtenir un nom d’utilisateur et un mot de passe valides.

Un spammer n’a besoin que d’un nom d’utilisateur et mot de passe valides pour relayer du courrier, même si votre serveur de courrier n’est pas un relais ouvert. Pour trouver le compte que le spammer utilisait, j’ai démarré ESM et cliqué sur Organization, Administrative Groups, Organizational Unit, Servers, puis j’ai fait un clic droit sur Server Name, Properties. J’ai sélectionné l’onglet Diagnostics Logging. Dans la fenêtre Services, j’ai cliqué sur MSExchangeTransport et, dans la fenêtre Categories, j’ai augmenté le niveau de journalisation au maximum pour les catégories Routing Engine, Categorizer, Connection Manager, Queuing Engine, Exchange Store Driver, SMTP protocol et NTFS store driver. J’ai ensuite examiné le journal d’événements, à la recherche d’une authentification provenant d’un serveur de courrier externe ou inconnu. Les tentatives de connexion infructueuses apparaîtront dans le journal Security avec l’event ID 680. J’ai ainsi découvert qu’un intrus utilisait un compte utilisateur qui n’était pas un compte Exchange Server local, pour s’authentifier auprès du serveur de courrier électronique.

Réparer le dommage. Après avoir identifié le compte d’authentification, j’ai pris les mesures suivantes pour sécuriser le serveur Exchange :

• J’ai changé le mot de passe du compte que le spammer utilisait. Si, dans un cas semblable, vous pensez qu’un spammer pourrait avoir plus d’un ID utilisateur et mot de passe valides, changez les mots de passe de tous les utilisateurs du réseau. J’ai aussi désactivé le compte Guest et établi des comptes dédiés pour démarrer des services sur le serveur. N’utilisez pas le compte Administrator pour démarrer des services. En effet, si une machine est piratée, le compte utilisé pour démarrer le service est vulnérable.
• J’ai désactivé l’authentification sur le serveur Exchange placé face à l’extérieur. Pour cela, j’ai démarré ESM et sélectionné Organization, Administrative Groups, Organizational Unit, Servers, ServerName, Protocols, SMTP, puis j’ai fait un clic droit sur le serveur virtuel SMTP par défaut. J’ai sélectionné Properties, cliqué sur l’onglet Access puis cliqué sur Authentication . J’ai laissé Anonymous access activé mais j’ai décoché les cases Basic authentication et Integrated Windows Authentication. Le fait de décocher ces cases désactive la commande Auth sur le serveur SMTP. 3
• J’ai activé la fonction relais pour les autres serveurs Exchange internes afin qu’ils puissent envoyer du courrier au serveur Exchange face à l’extérieur. J’ai ouvert ESM, fait un clic droit sur le serveur SMTP virtual et choisi Properties. Sous l’onglet Access, j’ai cliqué sur Relay, sélectionné Only the list below et listé les serveurs de courrier internes qui sont autorisés à relayer du courrier vers le serveur face à l’extérieur.
• Une fois ces changements effectués, j’ai testé à fond la configuration. J’ai testé le courrier entrant et sortant d’Internet et entrant et sortant de tous les serveurs de courrier électronique dans l’organisation. Les changements sont susceptibles de perturber le flux du courrier entre les serveurs. C’est pourquoi il vaut mieux les effectuer pendant le week-end. Mieux encore, il est bon de tester de tels changements en laboratoire avant de les mettre en production.
• Cet incident particulier m’a donné l’occasion de découvrir une machine que j’ai complètement reconstruite alors qu’elle était gravement compromise. Dans certains cas, vous serez amenés à recenser toutes les machines compromises et à les réparer ou à les reconstruire.
• J’ai consulté le ORDB pour déterminer si le serveur de courrier du client avait été mis en liste noire au titre de relais ouvert. Heureusement, j’ai découvert et réparé le piratage avant que le serveur de courrier du client n’ait été mis en liste noire. Un serveur de courrier peut être mis en liste noire s’il est un relais ouvert ou si le serveur de courrier est repéré comme un serveur responsable de l’envoi de grandes quantités de spam. Il existe de nombreuses bases de données à relais ouvert. Vous pouvez en voir une liste à http://dmoz.org/computers/internet/abuse/spam/blacklists.

Si votre serveur de courrier est dans la liste noire, vous pouvez soit soumettre une requête visant à l’en retirer, soit changer l’adresse IP extérieure du serveur de courrier. Dans ce dernier cas, vous devez aussi mettre à jour l’enregistrement MX (mail exchanger) pour votre serveur de courrier, faute de quoi le courrier entrant sera bloqué.

Leçons apprises. Pour réparer les conséquences des attaques par Exchange Server SMTP AUTH et empêcher les prochaines, je vous conseille fortement d’effectuer les mêmes opérations que moi. Si un intrus se procure un ID et un mot de passe utilisateur valides et s’il est capable de relayer du courrier, votre serveur de courrier sera placé sur diverses listes noires de e-mail. Vous passerez beaucoup moins de temps à empêcher ces attaques qu’à corriger les problèmes de livraison de courrier électronique, enlever votre serveur des listes noires et supprimer la vulnérabilité.