Se protéger du SMB (Server Message Block)

Tout savoir sur le Server Message Block (SMB)

Le protocole SMB (ou Server Message Block) permet le partage de ressources sur des réseaux locaux. Principalement utilisé en environnement Windows, il peut aussi être utilisé en environnement Unix via l’outil Samba.
Pourquoi parle-t-on régulièrement de ce protocole ?

Créé en 1985 par IBM, il a vu rapidement son intégration par défaut pour le partage de fichiers sous Windows. Ce protocole a pris alors une place très importante dans la communication entre plusieurs machines d’un même réseau et on le place au cœur du système d’information de la plupart des entreprises. Plusieurs versions ont alors suivi la version 1 pour diverses raisons : correction de vulnérabilités, optimisation du protocole, ajouts de fonctionnalités…

Au fur et à mesure des années, la version 1 du protocole est devenue obsolète et est actuellement dépréciée. C’est d’ailleurs fin 2018, avec l’apparition de Windows 10 (1903) et Windows Server 2019, que Microsoft décide de ne plus activer par défaut la version 1 de ce protocole sur les versions ultérieures de Windows. Cela prévient alors toute possibilité de communication avec des machines ne supportant que la version 1.

I- SMBv1 face à SMBv2 et SMBv3

En effet, le protocole SMBv1 a bien vécu et de très nombreuses vulnérabilités ont pu lui être attribuées. De la plus mineure à la plus grave, ce protocole étant très utilisé au sein des réseaux locaux, il permet de donner à une personne malveillante, une surface d’attaque très grande. C’est ainsi que sont apparus de nombreuses exploitations de ces vulnérabilités comme EternalBlue (développé par la NSA).
La version SMBv2 du protocole possède les mêmes concepts sous-jacents que la version SMBv1, cependant les formats de paquet sont complètement différents. De plus, celui-ci intègre plusieurs fonctionnalités supplémentaires :

• Rétablissement d’une ouverture à un fichier après la déconnexion temporaire d’une connexion client.
• Équilibrage du nombre d’opérations simultanées en attente d’un client par le serveur.
• Évolutivité en ce qui concerne le nombre de partages, d’utilisateurs et de fichiers ouverts simultanément.
• Prise en charge des liens symboliques.
• Utilisation d’un algorithme plus puissant pour valider l’intégrité des demandes et des réponses.

Avec l’apparition de la version 3, le protocole est de nouveau optimisé (débit augmenté, faible latence et moins de cycles d’utilisation du processeur…) et ajoute la possibilité de faire des snapshots VSS (Volume Shadow Copy) pour des fichiers distants, la gestion multi canaux, ainsi que l’ajout de chiffrement qui s’appuie sur l’algorithme AES-CCM. Même s’il est conseillé d’utiliser la version 3 de SMB actuellement, dans un contexte où les échanges ne sont pas confidentiels, l’utilisation de SMBv2 est suffisante.

II- Trafic IDS (Intrusion Detection System) SMBv1

1- Communication SMBv1

L’utilisation du SMBv1 est actuellement à proscrire au sein d’un réseau.
Il y a plusieurs façons d’identifier des communications SMBv1 au sein d’un réseau. De nombreuses possibilités sont résumées sur le site de Microsoft (https://docs.microsoft.com/fr-fr/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3).
A ma connaissance, aucune règle IDS détectant explicitement la version 1 du protocole n’existe à ce jour et n’est fourni par les éditeurs de règles. La détection privilégiée est réalisée directement sur la machine cible en testant des valeurs de registre. Il y a donc eu le besoin de détecter le SMBv1 en masse sur tout un parc sans avoir nécessairement un accès sur les machines. C’est pourquoi nous allons développer à la suite, des règles de détection IDS sur un réseau (dans le cadre d’un SOC ou non). Tout d’abord, penchons-nous sur la structure d’un paquet SMB. Pour cela, la documentation de Microsoft est très complète et très simple à appréhender.

Comme nous pouvons nous en rendre compte très rapidement, la détection du protocole SMB se fait seulement via quelques octets : 0xFF534d42. Lorsque l’on compare alors la version 2 ou 3 du protocole, seul le premier octet diffère : 0xFE pour le SMBv2 et 0xFC pour le SMBv3. La logique vient toute seule. C’est donc très simplement que la détection de la SMBv1 est réalisée sur l’identifiant du protocole lui-même. Nous pourrions ajouter de la même façon la détection du SMBv2 ou SMBv3 selon les besoins, aussi simplement. Ainsi, la règle suivante a été réalisé en prenant compte de ce changement entre les versions (Tests réalisés sur la version 5.3 de Suricata mais devrait fonctionner sur Snort) :

alert smb $HOME_NET any -> any any (msg: »CNX SMBv1 Request »; flow: to_server, established; content: « |ff 53 4d 42| »; offset: 4; depth: 4; fast_pattern; content:! »|72| »; distance: 0; flowbits: set, smbv1_traffic; threshold: type limit, track by_src, seconds 60, count 1000; reference: url, docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/69a29f73-de0c-45a6-a1aa-8ceeea42217f; metadata: tag INFORMATIONAL, created_at 2022_01_20, updated_at 2022_07_11; classtype: vulnerability; sid: 677888100; rev: 5;)

Certains tests ont été rajoutés en complément dans la règle. Nous verrons pourquoi par la suite. Attention, cette règle ajoutée seule peut est très verbeuse. C’est pourquoi, en complément, la règle suivante joue avec la précédente afin de réduire grandement la verbosité et distinguer rapidement tous les flux SMBv1 :

alert smb $HOME_NET any -> any any (msg: »CNX SMBv1 Usage Detected »; flow: to_server, established; content: « |ff 53 4d 42| »; offset: 4; depth: 4; fast_pattern; content:! »|72| »; distance: 0; flowbits: isset, smbv1_traffic; threshold: type limit, track by_src, seconds 3600, count 1; reference: url, docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/69a29f73-de0c-45a6-a1aa-8ceeea42217f; metadata: tag RELEVANT, created_at 2022_01_21, updated_at 2022_07_11; classtype: vulnerability; sid: 677888101; rev: 5;)

Il est donc conseillé de cacher la première et mettre en avant la seconde.

2- Dialectes SMBv1

Cependant, après des investigations plus approfondies sur le protocole, il y a négociation du dialecte à utiliser, lors des premiers échanges de données. De nombreux dialectes ont vu leur apparition au fur et à mesure des mises à jour du protocole. Ainsi la négociation des dialectes se présente ainsi :

Nous pouvons clairement y voir tous les dialectes que le client accepte. En effet, celui-ci initie la conversation en envoyant la liste des dialectes qu’il accepte. Le serveur répond alors à son tour directement avec le dialecte qu’il souhaite parmi ceux client. S’il choisit le dialecte SMB2.???, c’est que le serveur demande la liste complète des dialectes SMBv2/SMBv3. Il y aura alors un second échange mais qui n’est pas très pertinent dans notre cas. Il s’agit là d’un piège car si le client n’utilise qu’une version de SMB supérieur à la 1 alors que le client accepte aussi la version 1, aucun flux en SMBv1 ne sera détecté (En dehors de ce paquet de négociation envoyé par le client).

L’intérêt de visualiser et de détecter ces dialectes est donc de lister tous les clients acceptant cette version sans forcément l’utiliser. C’est pour cela que sur le terrain, nous avons pu avoir des surprises après l’application de cette règle sur nos sondes de détection. Une liste des dialectes associés à la SMBv1 est facilement trouvable sur Internet. Ainsi, la règle qui permet la détection des hôtes les acceptant a été construite comme cela :

smb $HOME_NET any -> any any (msg: »CNX SMBv1 COM Negotiation Vulnerable Dialect accepted »; flow: established, to_server; content: « |53 4d 42 72| »; depth: 9; pcre: »/((?:(?:LM1\.2X002|DOS LANMAN2\.1|LANMAN[1-2]\.[0-2]|Windows for Workgroups 3\.1a|PC(?:LAN1\.0| NETWORK PROGRAM 1\.0)|xenix[a-zA-Z \.1]+?|MICROSOFT NETWORKS 1\.03|MICROSOFT NETWORKS 3\.0|NT LM 0\.12)\x00\x02{0,1})+)/iR,flow:accepted_proto« ; flowbits: set, smbv1_client_accept; threshold: type limit, track by_src, seconds 3600, count 1; reference: url, docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/69a29f73-de0c-45a6-a1aa-8ceeea42217f; reference: url, docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/80850595-e301-4464-9745-58e4945eb99b; metadata: tag RELEVANT, created_at 2022_02_10, updated_at 2022_07_11; classtype: vulnerability; sid: 677888102; rev: 5;)

Ainsi, la détection des machines acceptant le SMBv1 est réalisée grâce à une regex. Bien sûr, la limite reste le fait que seuls les clients utilisant le protocole SMB vont pouvoir être testés mais si la résolution et prévention est réalisée sur tout un réseau ou sous-réseau, la détection sur un seul hôte suffit. La plupart du temps, la détection du SMBv1 et celle des dialectes remontent une alerte en même temps car la négociation est réalisée via la version la plus ancienne accepté. C’est pour cela que des conditions ont été rajoutées afin de prévenir les deux alertes sur le même paquet. L’une doit rester pour la détection de l’usage du SMBv1 et l’autre des dialectes.

III- Prévention du SMBv1 sur Active Directory

Il faut savoir que depuis la version 1709 de Windows 10, SMBv1 n’est plus installé par défaut. Cependant, il est tout de même possible de la posséder. Sur les versions précédentes, il s’agissait de la version présente par défaut afin d’établir des communications. Certains pourront dire « Les vulnérabilités ne sont exploitables que sur les serveurs ». Je ne suis personnellement pas convaincu. Comme on dit, mieux vaut prévenir que guérir. C’est pourquoi je vais continuer par une procédure à suivre afin de désactiver correctement le SMBv1 sur votre réseau / machine.

1- Affichage des dialectes sur une machine

Tout d’abord, afin de vérifier que toutes les modifications que l’on va appliquer fonctionne, il suffit d’appliquer la commande Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol dans une console PowerShell en ayant les droits nécessaires qui montre l’état de la feature SMB1Protocol.

De plus, il est possible d’utiliser un petit script PowerShell disponible ici (https://github.com/nsacyber/Windows-Secure-Host-Baseline/blob/master/Windows/Scripts/SMB.psm1) qui permet de récupérer la plus ancienne version du protocole présente sur la machine :

En complément, la commande suivante permet de tester l’activation ou la désactivation du protocole :

Il y a bien d’autres méthodes pour tester l’activation du SMB. Cependant, il faut relativiser ces méthodes qui ne font que vérifier certaines valeurs directement dans le registre.

2- Résolution du problème sur une machine

Afin de désactiver SMBv1 sur une machine précise, il suffit d’exécuter la commande PowerShell suivante :

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Sur un serveur, il est aussi possible de le désactiver depuis le manager (Windows Server 2012 ou ultérieur) :

• Dans le tableau de bord Gestionnaire de serveur du serveur sur lequel vous souhaitez supprimer des SMBv1, sous configurer ce serveur local, sélectionnez Supprimer des rôles et des fonctionnalités.

• Dans la page Sélectionner le serveur de destination sous pool de serveurs, assurez-vous que le serveur pour lequel vous souhaitez supprimer la fonctionnalité est sélectionné, puis sélectionnez suivant.
• Dans la page supprimer des rôles de serveurs, sélectionnez suivant.
• Dans la page Supprimer les fonctionnalités, désactivez la case à cocher prise en charge du partage de fichiers SMB 1.0/CIFS, puis sélectionnez suivant.

Sur la page confirmer les sélections pour la suppression, vérifiez que la fonctionnalité est affichée, puis sélectionnez supprimer.

3- Ajout d’une GPO sur un groupe de machines

La seconde méthode et la plus privilégiée sera la mise en place d’une GPO afin de prévenir l’utilisation du SMBv1. Celle-ci touchera directement au registre et touchera aux clés suivantes :

– Désactivation du démarrage du service supportant le SMBv1 :
Clé : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mrxsmb10\Start
Valeur : 4
Type : Dword
Action : Update

– Activation du démarrage du service supportant le SMBv2/SMBv3 :
Clé : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mrxsmb20\Start
Valeur : 2
Type : Dword
Action : Update

– Définition des choix de version de protocole SMBv2/SMBv3 :
Clé : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\DependOnService
Valeur : Bowser MRxSmb20
Type : NSI Multistring
Action : Replace

– Désactivation du SMBv1 :
Clé : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SMB1
Valeur : 0
Type : Dword
Action : Update

– Activation du SMBv2 :
Clé : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SMB2
Valeur : 1
Type : Dword
Action : Update

Pour finir, la GPO doit ressembler à la figure suivante :

Une fois la GPO créée, il faut forcer l’application de la GPO sur toutes les machines puis les redémarrer obligatoirement pour appliquer les modifications.

4- Vérification de la résolution

Il n’est possible de vérifier que la modification client a été correctement effectuer par une seule méthode : par un dump réseau.
Pour cela, commencez à enregistrer le trafic réseau puis redémarrer le service correspondant au service client :

Restart-Service -Name LanmanWorkstation -Force

Si après lancement de la commande, un paquet de négociation SMB1 est envoyé, alors le problème n’est pas résolu. Cependant, il y a une exception pour les machines Windows Server 2008 / Windows 7. Le paquet SMB est envoyé mais avec des « NotSmb » au lieu du support des anciennes versions :

Conclusion

Il est très important de désactiver la version 1 du protocole SMB car très utilisé lors d’attaque interne sur le réseau. L’article aide à la prévention complète et immédiate du SMBv1, côté client ainsi que côté serveur. Par expérience, la résolution peut poser de nombreuses difficultés. Nous conseillons donc surveiller sur quelques jours la bonne résolution grâce à une sonde IDS.

On retrouvera dans le support de présentation joint un travail de construction et de hiérarchisation des kill chains sur un environnement-type PDIS. Un travail riche d’enseignements sur les écueils rencontrés, mais qui valide la méthode.