Vulnérabilité critique sur SMBv3 (SMBGhost / CVE-2020-0796)

⚠️ Le blog a été déplacé vers le site Patrowl, vous serez redirigé automatiquement dans 3 secondes, sinon cliquez sur ce lien : https://patrowl.io/vulnerabilite-critique-sur-smbv3-smbghost-cve-2020-0796/
👍 Vous y retrouverez toutes les nouvelles publications

SMB est un vieux protocole de Microsoft récupéré d’IBM dans les années 90 et servant, à la base, à partager des fichiers mais également à exécuter des commandes.

Il était anciennement nommé Lan Manager (du temps d’IBM), puis SMB (Server Message Block), renommé CIFS (Common Internet File System) puis à nouveau SMB avec sa version 2.0. Aujourd’hui, SMB en est à sa 3eme version majeure, apportant, entre autre, le chiffrement des flux. Eh oui, avant SMB 3.0, sorti en 2018, les flux étaient en clair, merci Microsoft 🤦‍♂️ : https://docs.microsoft.com/en-us/windows-server/storage/file-server/smb-security

SMB est surtout connu pour être un protocole à risque et est tristement célèbre pour avoir été le vecteur de propagation des vers WannaCry (basé sur la vulnérabilité MS17-010 aussi appelée EternalBlue) et NotPetya.

Globalement, SMB 1.0 est bourré de vulnérabilité (pour le plus récentes : EternalRomance/EternalSynergy/EternalChampion) et il est très fortement recommandé de le désactiver partout ou c’est possible, ce qui peut s’avérer compliqué avec des imprimantes, des scanners, certains serveurs d’antivirus….

SMB 2.0 est à peine mieux et SMB 3.0, je vous laisse relire le titre 😉.

La vulnérabilité SMBGhost / CoronaBlue / CVE-2020-0796

Le mardi 10 mars 2020, le blog a Talos (équipe de recherche de Cisco) a publié un article annonçant le nouveau bulletin mensuel des correctifs de sécurité de Microsoft, incluant un peu trop tôt la vulnérabilité CVE-2020-0796 en ces termes :

« CVE-20200796 is a remote code execution vulnerabilityIn Microsoft Server Message Black 3.0 (SMBv3). An attacker could exploit this bug by sending a specially crafted packet to the target SMBv3 server, which the victim needs to be connected to. Users are encouraged to disable SMBv3 compressionand block TCP port 445 on frewalls and client computers. The exploitation of this vulnerability opens systems up to a "wormable" attack, which means it would be easy to move from victim to victim. »

Traduction simple : SMBv3 est vulnérable à une exécution de code à distance sans authentification, rendant cette vulnérabilité utilisable par un ver pour se rependre (WannaCry, NotPetya et autres joyeux vers du même type).

Sauf que le bulletin en question ne corrigeait pas cette vulnérabilité, ce qui a mis la communauté sécurité en émois, à la recherche de cette vulnérabilité concernant la compression sur SMBv3. Une fois l’erreur découverte, l’article a donc été corrigé mais trop tard :

Il n’aura pas fallu attendre bien longtemps pour voir apparaitre des outils permettant d’identifier les systèmes potentiellement vulnérables et … des codes d’exploitation dont le premier public date du samedi 14 mars 2020 :  https://www.exploit-db.com/exploits/48216avec le code ici : https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/48216.zip

Cette vulnérabilité est un dépassement d’entier du fait de deux valeurs de 32-bits que le client (et donc l’attaquant) maitrise : une taille (OriginalCompressedSegmentSize ) et une position en mémoire (OffsetOrLength). Ces deux valeurs sont additionnées et copiées dans un nouvel entier de 32-bits servant à réaliser une allocation, permettant ce dépassement d’entier. Voici un article de Synacktiv assez détaillé sur cette vulnérabilité : https://www.synacktiv.com/posts/exploit/im-smbghost-daba-dee-daba-da.html

A noter que les dépassements d’entier sont généralement faciles à identifier mais complexes à exploiter.

Détecter SMB 3 et l’activation de la compression, à distance

Voici un outil open source permettant d’identifier à distance si des services sont potentiellement vulnérables : https://github.com/ollypwn/SMBGhost

Cela peut également se faire avec un simple* nmapdétectant SMB 3.11 : nmap -p445 --script smb-protocols -Pn -n sous-réseau-a-scanner-ici-ou-simple-adresse-ip | grep -P '\d+\.\d+\.\d+\.\d+|^\|.\s+3.1.1\|.\s+3.11' | tr '\n' ' ' | tr 'Nmap scan report for' '@' | tr "@" "\n" | tr '|' ' ' | tr '_' ' ' | grep -oP '\d+\.\d+\.\d+\.\d+'

* enfin… quand je dis simple, c’est un peu exagéré 😉

Vous pouvez également utiliser SMBMap (généralement utilisé pour de l’offensif 😉) qui permet de lister simplement les partages SMB et droits associés, mais il est plutôt dédié à être utilisé sur un réseau interne : https://github.com/ShawnDEvans/smbmap

Vous pouvez enfin chercher dans votre Active Directory avec une commande PowerShell du type : Get-ADComputer -LDAPFilter "(|(operatingSystemVersion=10.0 \2818362\29)(operatingSystemVersion=10.0 \2818363\29))" -Properties operatingSystemVersion,operatingSystem

Solution

Suite à cette erreur de communication, Microsoft a du publier une méthode de contournement consistant à désactiver la compression, en PowerShell localement : Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force

Microsoft a proposé un article pour détecter (localement) et désactiver SMB 1 à 3 :  https://docs.microsoft.com/en-gb/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3

Mais devant les risques, ils ont fini par publier le correctif « hors bande », c’est-à-dire en dehors du cycle mensuel des publications de correctifs de sécurité : https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0796

Je vous recommande donc de : identifier, analyser les risques, corriger ou désactiver ou cloisonner.

L’ANSSI a également publié un article plein de bon sens et qui reprend ce que nous disons depuis des lustres : il ne faut JAMAIS EXPOSER de service SMBsur Internet.

https://www.cert.ssi.gouv.fr/alerte/CERTFR-2020-ALE-008/

Ils rappellent également que même en interne, les flux SMB doivent être bloqués. Ces recommandations sont tellement alignées avec ce que nous répétons depuis des années, que je me permets de recopier :

• Interdire tout flux SMB sur les ports TCP/139 et TCP/445 en entrée et en sortie du Système d'Information [2] ;
• Pour le cloisonnement interne : n'autoriser les flux SMB que lorsque cela est nécessaire (contrôleurs de domaine, serveurs de fichiers, etc.) et bloquer ce flux entre postes de travail ;
• Pour les postes nomades : interdire tous les flux SMB     entrant et sortant et n'autoriser ces flux vers des serveurs SMB qu'au travers d'un VPN sécurisé [3][4]

Sauf qu’avec Azure, vous avez peut-être de nombreux services SMB exposés sans le savoir.

Pour des solutions PaaS, Microsoft s’occupe du durcissement des configurations et de l’application des correctifs de sécurité, mais pour le IaaS c’est à vous d’identifier, analyser, corriger (cf. outils plus haut en complément de votre console Azure).

Nous sommes sauvés !

Tout est identifié et corrigé, sommes-nous sauvés ? Pas si sûr.

Comme HTTP est devenu un protocole de transport supplantant TCP (avec des overhead de folie !), QUIC, devenu HTTP/3, permet de transporter SMB : https://techcommunity.microsoft.com/t5/itops-talk-blog/smb-over-quic-files-without-the-vpn/ba-p/1183449

QUIC est une implémentation optimisée d’HTTP en UDP, bénéficiant de tous les avantages d’HTTP/2, devenant un protocole binaire et non plus texte.

L’idée de Microsoft est de se dire que pour accéder à des fichiers en SMB, il faut monter des tunnels VPN, ce qui est complexe. Avec Azure et Office 365 ils vont mettre en place des accès SMB à travers HTTP/3, en profitant de capacités d’authentification de ce protocole (dont l’authentification forte), le chiffrement (avec TLS 1.3) et le SSO.

Pourquoi ne pas supprimer SMB et développer une solution moderne et élégante, plutôt que de reprendre un vieux protocole et de lui ajouter des surcouches supplémentaires ? Bonne question 😉.

L’insécurité de SMB a de beaux jours devant elle…