CVE-2021-33045

Falha de autenticação (CWE-287) em câmeras IP, NVRs, DVRs e intercomunicadores Dahua que permite bypass completo do login remoto sem credenciais, explorando o protocolo proprietário DHIP. Está no catálogo KEV da CISA por exploração ativa confirmada, e o CVSS 9.8 reflete bem a realidade: não exige autenticação, não exige configuração especial, só acesso de rede ao serviço.

A vulnerabilidade está no processamento do comando global.login do protocolo DHIP, usado por dispositivos Dahua para autenticação de clientes (apps, NVRs, consoles de gerência). O pesquisador bashis (mcw0) demonstrou que, ao montar uma requisição de login informando os campos "ipAddr": "127.0.0.1", "loginType": "Loopback" e "clientType": "Local", o dispositivo interpreta a sessão como uma conexão de loopback originada localmente — categoria de cliente que o firmware trata como implicitamente confiável e dispensa de verificação de senha.

O problema é que esses valores são fornecidos pelo próprio cliente no payload JSON da requisição, sem qualquer validação de que a conexão TCP realmente se origina do endereço 127.0.0.1 ou de um processo local do dispositivo. Um atacante remoto simplesmente declara no pacote que é 'loopback' e o firmware aceita a afirmação sem checagem cruzada com a origem real da conexão de rede — um caso clássico de confiar em dado controlado pelo cliente para decisão de autenticação.

O resultado de um login bem-sucedido por esse caminho é uma resposta {"id":1,"params":{"keepAliveInterval":60},"result":true,"session":}, ou seja, uma sessão autenticada válida entregue ao atacante, com os mesmos privilégios de um login administrativo legítimo.

A CVE-2021-33045 é irmã da CVE-2021-33044, que explora o mesmo mecanismo de login mas declarando "clientType": "NetKeyboard" em vez de loopback — outra categoria de cliente tratada como confiável por dispositivos que não implementam suporte real a NetKeyboard. Ambas foram reportadas juntas pelo mesmo pesquisador.

O vetor é remoto e não exige credenciais: basta acesso de rede à porta do serviço DHIP do dispositivo (normalmente exposta na interface de gerência). O atacante monta uma requisição global.login com os campos de loopback/local descritos e recebe uma sessão válida de volta — não há elevação de privilégio adicional necessária, a sessão retornada já é equivalente a uma sessão autenticada normal, com acesso a video stream, configuração e, dependendo do modelo, execução de comandos administrativos do dispositivo.

A Dahua publicou advisory e passou a liberar atualizações de firmware em lotes por linha de produto a partir de setembro de 2021 (dahuasecurity.com/support/cybersecurity/details/957 e o boletim atualizado em dahuasecurity.com/aboutUs/trustedCenter/details/582, referenciado pela CISA). A lista exaustiva de modelos e as versões de firmware corrigidas por linha de produto está no advisory oficial e no portal de firmware do fornecedor — não há aqui uma tabela de versões consolidada confiável para reproduzir sem risco de erro; o caminho correto é conferir diretamente o modelo específico no portal do fabricante.

Segundo o pesquisador, o firmware vulnerável é aquele anterior ao início/meados de 2020, o que dá uma janela aproximada, mas não deve ser tomado como corte exato — modelos diferentes tiveram ciclos de patch diferentes.

Onde atualizar não é viável, a mitigação real é isolar a porta de gerência DHIP (e HTTP/HTTPS de administração) da internet e de redes não confiáveis, restringindo acesso a VLAN de gerência com firewall/ACL. Trocar a senha padrão não mitiga nada aqui: a falha ocorre antes da verificação de senha, então o bypass funciona independentemente de a senha ser forte ou fraca — esse é o mito mais importante a desfazer nessa CVE.

Em tráfego de rede ou logs do serviço DHIP, o indicador mais confiável é uma requisição global.login contendo "loginType":"Loopback" e/ou "clientType":"Local" (ou "clientType":"NetKeyboard" no caso da CVE irmã 33044) chegando de um endereço IP de origem que não é 127.0.0.1 — esse é logicamente impossível em uso legítimo e denota tentativa de exploração. Não há assinatura de payload único porque o ataque é apenas manipulação de campos JSON legítimos do protocolo; ambientes sem captura de payload da camada de aplicação (apenas NetFlow/IP) não terão visibilidade alguma dessa exploração.