Encore des vulnérabilités sur SMB : SMBleed (CVE-2020-1206) et SMBLost (CVE-2020-1301)

Encore des vulnérabilités sur SMB : SMBleed (CVE-2020-1206) et SMBLost (CVE-2020-1301)

⚠️ 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/encore-des-vulnerabilites-sur-smb-smbleed-cve-2020-1206-et-smblost-cve-2020-1301/
👍 Vous y retrouverez toutes les nouvelles publications

TL;DR : encore des vulnérabilités touchant le protocole de partage de fichiers (mais pas que) de Microsoft : SMB.

SMBGhost, SMBleed, SMBLost, quelle imagination pour ces noms de vulnérabilités 😉.

Je rappelle les règles de base :

  • Désactiver autant que possible SMBv1 ;
  • Ne jamais exposer du SMB sur internet (que ce soit SMBv1, v2 ou v3) ;
  • Mettre à jour rapidement quand les correctifs sont publiés (en analysant le contexte des composants touchés, leur criticité, leur exposition…) ;
  • Ne jamais exposer du SMB sur internet… ah je l’ai déjà dit ?

SMBleed (CVE-2020-1206)

Cette vulnérabilité permet une fuite de mémoire sans authentification, touchant SMBv3 (3.1.1 pour être exact) : https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1206

Cette vulnérabilité touche les dernières version de Windows 10 et Windows Server, si SMBv3 est activé avec la compression.

La vulnérabilité a été découverte par ZecOps : https://blog.zecops.com/vulnerabilities/smbleedingghost-writeup-chaining-smbleed-cve-2020-1206-with-smbghost/

Le code de démonstration nécessite un partage accessible en écriture et un compte, mais cela fonctionne également sans authentification car cela fonctionne avec la quasi-totalité des messages « SMB ».

Fait amusant, la vulnérabilité se trouve dans la même fonction de décompression (Srv2DecompressData) que la vulnérabilité SMBGhost de mars 2020 (cf. « [Sécurité] SMBGhost, Vulnérabilité critique sur SMBv3 et rapide historique de SMB / CVE-2020-0796 »). C’est assez surprenant pour une fonction faisant à peine 10 lignes de code effectif !

Il s’agit d’un dépassement d’entier permettant d’allouer une petite zone mémoire dont il est possible de récupérer le contenu, le « bleed » de la mémoire.

Comme il semble possible de contrôler partiellement l’endroit de l’allocation et que SMB est exécuté par le noyau de Windows, il est donc possible de lire une partie de la mémoire du noyau et donc de récupérer des clefs, des condensats de mot de passe des sessions passé ou en cours (sauf si Credential Guard est activé), des adresses en mémoire…

SMBLost (CVE-2020-1301)

Cette vulnérabilité permet une exécution de code à distance avec authentification, touchant SMBv1, ancienne version qui ne devrait plus être utilisée nulle part 😉 : https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1301

Cette vulnérabilité touche les dernières version de Windows 10 et Windows Server, si SMBv1 est activé.

La vulnérabilité a été découverte par Nicolas Delhaye d’AIRBUS, qui a rédigé un article complet sur le sujet : https://airbus-cyber-security.com/diving-into-the-smblost-vulnerability-cve-2020-1301/

Il s’agit d’un dépassement d’entier générant une écrite arbitraire en mémoire avec la particularité que le nom du répertoire partagé ciblé finisse par « \ », comme par exemple le partage « c:\ » mais plus souvent local que distant.

L’article présente un code d’exploitation en Python 2 qu’il faut un peu adapter si vous utiliser Python 3. Il génère un déni de service (plantage) et pour le faire fonctionner, il faut bien suivre les instructions de l’article (vous sentez le gars qui a eu un peu de mal😉).

Ma cible dispose bien du port SMB accessible :

Il s’agit d’un Windows 10 avec les conditions du test :

Et il plante bien quand j’exécute le PoC :

SMBGhost (CVE-2020-0796)

Cette vulnérabilité a déjà été présentée en mars mais je trouvais intéressant de présenter un code d’exploitation complet qui vient d’être publié sur github : https://github.com/chompie1337/SMBGhost_RCE_PoC/blob/master/README.md

Solutions

Je ne vais pas répéter les habituels « cloisonnez », « mettez à jour » et « n’exposez pas SMB », donc je me limiterai à un simple « ayez une connaissance précise de votre système d’information avec l’exposition et la criticité de chaque composants afin d’être capable de faire une analyse rapide quand ce type de vulnérabilité sort ».

Bon courage tout de même 😉.