IIStealer : Une menace côté serveur pour le commerce électronique

Les chercheurs d'ESET ont découvert et analysé un cheval de Troie  jusqu'alors non documenté qui vole les informations de paiement des clients des sites de commerce électronique. Le cheval de Troie, que nous avons nommé IIStealer, est détecté par les solutions de sécurité ESET comme Win64/BadIIS.

Ce billet de blog est le premier de notre série dans laquelle les chercheurs d'ESET passent les menaces des serveurs web IIS au crible. Pour un guide complet sur la manière de détecter, d'analyser et de supprimer les logiciels malveillants IIS, reportez-vous à notre White paper Anatomy of native IIS malware, qui inclut IIStealer au nombre des familles de logiciel malveillant étudiées (Groupe 5).

Anatomy of native IIS malware

Read full report

Résumé de l'attaque

IIStealer est implémenté comme une extension malveillante pour Internet Information Services (IIS), le logiciel serveur web de Microsoft. Faisant partie intégrante du serveur, IIStealer est capable d'accéder à toutes les communications réseau passant par le serveur et de voler les données qui intéressent les attaquants - dans ce cas, les informations de paiement des transactions de commerce électronique.

Comme l'illustre la figure 1, IIStealer fonctionne en interceptant le trafic régulier entre le serveur compromis et ses clients (le vendeur et les acheteurs), en ciblant les requêtes HTTP POST effectuées vers des chemins URI spécifiques : /checkout/checkout.aspx ou /checkout/Payment.aspx.

IIStealer est implémenté comme une extension malveillante pour Internet Information Services (IIS), le logiciel serveur web de Microsoft. Faisant partie intégrante du serveur, IIStealer est capable d'accéder à toutes les communications réseau passant par le serveur et de voler les données qui intéressent les attaquants - dans ce cas, les informations de paiement des transactions de commerce électronique.

Chaque fois qu'un visiteur légitime d'un site Web effectue une requête vers ces pages de paiement (1), IIStealer enregistre le corps de la requête HTTP dans un fichier journal (2), sans interférer en aucune façon avec la réponse HTTP générée par les composants du site Web légitime (3).

Les adversaires peuvent ensuite exfiltrer les données collectées en faisant une demande HTTP spéciale au serveur IIS compromis : dès qu'IIStealer détecte une demande faite à un URI spécifique (/privacy.aspx) avec un mot de passe d'attaquant inclus dans l'en-tête X-IIS-Data (4), il incorpore les données collectées dans la réponse HTTP pour cette demande (5,6).

Figure 1. IIStealer : mécanismes de collecte et d'exfiltration

Grâce à ces capacités, IIStealer est en mesure de voler les informations de carte de crédit envoyées aux sites Web de commerce électronique qui n'utilisent pas de passerelles de paiement tierces. Notez que les protocoles SSL/TLS et les canaux de communication cryptés ne protègent pas ces transactions contre IIStealer, car le logiciel malveillant peut accéder à toutes les données manipulées par le serveur - où les informations de carte de crédit sont traitées dans leur état non chiffré.

Les échantillons de ce logiciel malveillant que nous avons analysés semblent être conçus pour des sites de commerce électronique spécifiques (avec des URI de page de paiement codés en dur). Selon notre télémétrie, un petit nombre de serveurs IIS ont été ciblés aux États-Unis, entre septembre 2020 et janvier 2021, mais ce chiffre est probablement affecté par notre visibilité limitée sur les serveurs IIS - il est encore courant que les administrateurs n'utilisent aucun logiciel de sécurité sur ces serveurs.

Analyse technique

IIStealer est implémenté en tant que module IIS natif malveillant - une DLL C++ déposée dans le dossier %windir%\system32\inetsrv\ du serveur IIS compromis et configurée dans le fichier %windir%\system32\inetsrv\config\ApplicationHost.config. Dans certains cas, IIStealer est déployé sous le nom de dir.dll et, comme le montre la figure 2, utilise une ressource VERSIONINFO falsifiée pour imiter un module Windows IIS légitime appelé dirlist.dll.

Figure 2. La ressource VERSIONINFO de IIStealer (à gauche) imite le module légitime dirlist.dll (à droite)

Comme il s'agit d'un module IIS, IIStealer est chargé automatiquement par le processus IIS Worker (w3wp.exe), qui traite les demandes envoyées au serveur Web IIS - c'est ainsi qu'IIStealer obtient la persistance et qu'il peut affecter le traitement des demandes entrantes.

Nous ne disposons d'aucune information sur le mode de propagation du logiciel malveillant, mais nous savons que des privilèges administrateurs sont nécessaires pour l'installer en tant que module IIS natif, ce qui réduit le nombre de candidats à la compromission initiale. Une faiblesse ou une vulnérabilité de configuration dans une application Web, ou le serveur lui-même, sont probablement les coupables.

Quant à ses caractéristiques techniques, IIStealer met en œuvre une classe de base héritée de CHttpModule  (classe de module) et surcharge la méthode CHttpModule:OnPostBeginRequest avec son code malveillant. Comme tous les modules natifs d'IIS, IIStealer exporte une fonction appelée RegisterModule  (voir Figure 3), dans laquelle il instancie la classe du module et enregistre ses méthodes pour les événements du serveur - plus précisément, il s'enregistre pour la notification post-événement RQ_BEGIN_REQUEST  qui est générée chaque fois que le serveur commence à traiter une requête HTTP entrante. En conséquence, la méthode OnPostBeginRequest est appelée à chaque nouvelle demande, ce qui permet à IIStealer d'affecter le traitement de la demande.

Figure 3. Le point d'entrée RegisterModule d'IIStealer

Dans le gestionnaire OnPostBeginRequest, IIStealer filtre les demandes HTTP entrantes par URI de demande. Toutes les requêtes POST envoyées à /checkout/checkout.aspx ou /checkout/Payment.aspx sont enregistrées - avec leur corps HTTP complet - dans un fichier nommé C:\Windows\Temp\cache.txt. Ces requêtes sont effectuées par des visiteurs légitimes des sites d'e-commerce compromis et peuvent contenir des informations sensibles telles que des détails personnels et des numéros de carte de crédit.

Les données collectées peuvent être exfiltrées via une requête HTTP spécifiquement conçue par l'attaquant. Cette requête doit avoir une en-tête HTTP X-IIS-Data défini sur un mot de passe alphanumérique de 32 octets codé en dur (que nous avons choisi de ne pas divulguer), et doit être envoyée vers un chemin URL spécifié dans l'échantillon du logiciel malveillant :

• /privacy.aspx
• /checkout/Payment.aspx

Une fois que le module malveillant a détecté une telle demande, il utilise la méthode IHttpResponse::Clear pour supprimer toute réponse HTTP préparée par le serveur IIS, et copie le contenu non chiffré du fichier journal dans le corps de la réponse HTTP à l'aide de la fonction API IHttpResponse::WriteEntityChunks, comme le montre la Figure 4.

Figure 4. IIStealer remplace le corps de la réponse HTTP par ses propres données

Cela permet aux opérateurs d'IIStealer d'accéder aux données collectées et de les exfiltrer en envoyant simplement une requête spéciale au serveur IIS compromis - le logiciel malveillant n'a pas besoin de mettre en œuvre des canaux C&C supplémentaires ou d'intégrer des domaines de serveur C&C dans sa configuration.

Atténuation

IIStealer est une menace côté serveur qui écoute les communications entre un site de commerce électronique compromis et ses clients, dans le but de voler des informations de paiement sensibles - mais bien sûr, les modules IIS malveillants peuvent également cibler des informations d'identification et d'autres informations. Même si SSL/TLS est vital pour sécuriser la transmission des données entre le client et le serveur, il n'empêche pas ce scénario d'attaque car IIStealer fait partie du serveur. Cela devrait être inquiétant pour tous les portails web sérieux qui veulent protéger les données de leurs visiteurs, y compris les informations d'authentification et de paiement.

La meilleure façon de renforcer un serveur IIS contre IIStealer et d'autres menaces est la suivante :

• Utiliser des comptes dédiés avec des mots de passe forts et uniques pour l'administration du serveur IIS.
• Appliquez régulièrement des correctifs à votre système d'exploitation et examinez attentivement quels services sont exposés à Internet, afin de réduire le risque d'exploitation du serveur.
• N'installez que des modules IIS natifs provenant de sources fiables.
• Envisagez l'utilisation d'un pare-feu pour les applications Web et/ou d'une solution de sécurité des points d'accès sur votre serveur IIS.
• Vérifiez régulièrement le fichier de configuration %windir%\system32\inetsrv\config\ApplicationHost.config, ainsi que les dossiers %windir%\system32\inetsrv\ et %windir%\SysWOW64\inetsrv pour vous assurer que tous les modules natifs installés sont légitimes (signés par un fournisseur de confiance ou installés volontairement).

Pour les développeurs Web : Même si vous n'avez pas le contrôle du serveur IIS où est hébergé votre service web, vous pouvez toujours prendre des mesures pour réduire l'impact sur les utilisateurs de votre service web en cas de compromission, notamment :

• N'envoyez pas le mot de passe lui-même au serveur (même pas via SSL/TLS) ; utilisez un protocole tel que Secure Remote Password (SRP) pour authentifier les utilisateurs sans qu'il soit nécessaire de transmettre le mot de passe non crypté au serveur, ni les données qui pourraient être utilisées pour se réauthentifier. Les voleurs d'infos IIS sont un bon exemple de la raison pour laquelle le hachage côté serveur ne suffit pas.
• Évitez d'envoyer inutilement des informations sensibles depuis l'application web ; utilisez des passerelles de paiement.
• Si vous identifiez une compromission réussie : informez toutes les parties concernées par une violation de la sécurité afin qu'elles puissent prendre des mesures rapides.

Pour les consommateurs : du point de vue du visiteur, il est impossible de savoir si un serveur IIS est compromis, mais ces conseils vous aideront à réduire le risque :

• Faites attention à l'endroit où vous saisissez votre numéro de carte de crédit. Envisagez d'utiliser des passerelles de paiement par des fournisseurs tiers de confiance sur des sites de commerce électronique dont vous ne connaissez pas la réputation : avec les passerelles de paiement, ces sites ne traiteront pas les informations de paiement sensibles.
• Surveillez votre relevé de compte pour repérer les petits paiements ou les paiements inhabituels : souvent, de petits montants sont traités pour tester la validité des cartes.
• Si vous repérez quelque chose d'inhabituel, prévenez immédiatement votre banque.

Des détails techniques supplémentaires sur le logiciel malveillant, les indicateurs de compromission et les règles YARA sont disponibles dans notre white paper complet et sur GitHub. Pour toute demande de renseignements ou pour soumettre des échantillons liés à ce sujet, contactez-nous à l'adresse suivante : threatintel@eset.com.

Suivez les prochains volets de cette série où nous couvrirons les extensions IIS malveillantes utilisées pour le cyberespionnage et la fraude au référencement.

Indicateurs de compromission (IoCs)

Nom de détection d'ESET

Win64/BadIIS.F
Win64/BadIIS.O

SHA-1

706EAB59C20FCC9FBC82C41BF955B5C49C644B38
7A2FA07A7DC05D50FE8E201A750A3DC7F22D6549
A1C5E7424E7C4C4C9902A5A1D97F708C6BB2F53A

Nom de fichier et chemin

dir.dll
isapicache___.dll
isapicache_.dll_
C:\Windows\Temp\cache.txt

Indicateurs de réseau

URIs ciblés

/checkout/checkout.aspx
/checkout/Payment.aspx
/privacy.aspx

En-tête HTTP

X-IIS-Data

Techniques MITRE ATT&CK

Note : Ce tableau a été construit en utilisant la version 9 de MITRE ATT&CK