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 entrantet 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 IaaSc’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…
