CVE-2019-20085
Corrija agora. Ela está sob exploração confirmada pelo CISA e tem exploit funcional público.
Apply updates per vendor instructions.
Resumo
Falha de directory traversal (CWE-22) nos dispositivos TVT NVMS-1000 que permite a um atacante não autenticado, via rede, ler arquivos arbitrários do sistema usando sequências '../' em uma requisição GET ao serviço web do equipamento. O CVSS 7.5 reflete impacto restrito à confidencialidade (leitura de arquivo), mas a ausência total de autenticação, a simplicidade do ataque (uma única requisição HTTP) e a presença no catálogo KEV da CISA — com exploração confirmada em campo — tornam essa CVE mais perigosa na prática do que sua nota isolada sugere.
Detalhamento técnico
A vulnerabilidade está no componente de servidor web embarcado nos dispositivos NVMS-1000 da TVT, usado para expor a interface de gerenciamento do NVR/DVR. O serviço não sanitiza adequadamente o caminho solicitado em requisições GET, permitindo que sequências de travessia de diretório ('../') repetidas escapem do diretório raiz configurado para a aplicação web e alcancem qualquer ponto do sistema de arquivos subjacente ao qual o processo tenha permissão de leitura.
O PoC público demonstra a leitura do arquivo 'windows/win.ini' através de uma cadeia longa de '../', o que indica que o serviço web roda sobre um ambiente Windows (ou emula esse layout de caminhos) — um detalhe relevante porque várias linhas de NVR/DVR baseadas nesse firmware OEM rebatizam o produto sob marcas diferentes, mantendo o mesmo componente vulnerável.
O vetor CVSS (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) confirma que o impacto documentado é só de confidencialidade: não há evidência, nas fontes catalogadas, de que a falha permita escrita de arquivo ou execução de código por si só. O risco real vem do que pode ser lido — arquivos de configuração, credenciais em texto claro, chaves ou strings de conexão que viabilizam movimento lateral ou escalonamento posterior.
As fontes disponíveis não detalham o componente exato (binário, porta, framework HTTP) nem apontam a linha de código responsável — o advisory formal do fornecedor não está entre as referências levantadas, e a descrição oficial do NVD é genérica ('TVT NVMS-1000 devices allow GET /.. Directory Traversal'), sem versão ou changelog associado.
Como é explorada
A exploração é trivial: uma única requisição GET não autenticada contendo sequências de travessia de diretório, enviada à porta do serviço web do NVMS-1000, basta para extrair o conteúdo de um arquivo arbitrário do sistema. Não há necessidade de sessão, token, cookie ou qualquer interação do usuário — condição refletida no PR:N/UI:N do vetor CVSS. O único pré-requisito real é acesso de rede ao serviço HTTP do dispositivo, o que é comum: esses NVRs frequentemente são expostos direto à internet por configuração de fábrica ou por usuários que abrem a porta para acesso remoto às câmeras.
O PoC público (Exploit-DB 47774) mostra o padrão de exploração: dezenas de '../' encadeados até atingir a raiz do sistema de arquivos, seguidos do caminho do arquivo alvo. A mesma técnica pode ser redirecionada para arquivos de configuração do próprio NVMS-1000 (credenciais, strings de conexão de banco, chaves de API) em vez de arquivos de sistema genéricos, ampliando o impacto prático além da simples leitura de 'win.ini'.
A CISA lista a CVE no catálogo KEV como de exploração confirmada em campo, existe módulo Metasploit e template Nuclei publicados, o que reduz drasticamente a barreira técnica para scanners automatizados e campanhas de varredura em massa contra dispositivos expostos. As fontes consultadas não detalham a campanha específica de exploração (grupo, botnet, volume), apenas confirmam o status de exploração ativa via KEV.
Versões
Como se proteger
Nenhuma das fontes levantadas aponta um advisory formal do fornecedor com número de versão corrigida — a entrada da CISA KEV recomenda genericamente 'aplicar atualizações conforme instrução do fornecedor', sem especificar release. Isso é um sinal de alerta em si: não há confirmação pública de que exista patch oficial disponível ou de qual versão do firmware/software NVMS-1000 o corrige. Antes de declarar o sistema corrigido, confirme diretamente com o fabricante/OEM do equipamento específico (muitos DVRs/NVRs de marcas diferentes usam esse mesmo software rebatizado) se existe firmware atualizado que trate esse endpoint.
Como esses dispositivos raramente recebem patch em tempo hábil, o controle compensatório mais efetivo é isolar a interface de gerenciamento: nunca expor a porta do serviço web do NVMS-1000 diretamente à internet, restringir acesso por firewall/ACL apenas a IPs de administração confiáveis, e colocar o dispositivo em VLAN segregada sem rota direta para a internet. Um WAF ou proxy reverso com filtro de sequências de travessia ('../', '..%2f', variantes codificadas) na frente do serviço reduz a superfície, mas é paliativo — não corrige a falta de sanitização no binário do dispositivo.
Desabilitar a interface web de administração quando não usada, e monitorar/logar todo acesso a ela, são medidas de baixo custo e alto valor enquanto não há confirmação de patch. Não existe mitigação client-side ou de rede que elimine 100% o risco sem controle de acesso na camada de rede — apenas reduzem a exposição.
Como detectar
Em logs de servidor web ou WAF, procure por requisições GET contendo sequências repetidas de '../' (ou variantes URL-encoded como '..%2f', '%2e%2e%2f') direcionadas ao serviço de gerenciamento do NVMS-1000, especialmente tentativas de acessar caminhos de sistema como '/windows/win.ini', '/etc/passwd' ou arquivos de configuração do próprio dispositivo. Como a exploração não requer autenticação nem gera erro de login, não há sinal de força bruta associado — a única marca de tentativa é o padrão de travessia no path da requisição HTTP.
A existência de template Nuclei e módulo Metasploit públicos significa que scanners de vulnerabilidade e ferramentas de red team vão gerar tráfego característico e repetitivo contra o endpoint; IDS/IPS com assinatura para CWE-22 genérico ou para esse CVE específico deve capturar essas tentativas. Não há, nas fontes revisadas, indicação de um indicador de comprometimento pós-exploração (por exemplo, alteração de configuração) além do próprio log de acesso ao arquivo sensível — a ausência de tal sinal deve ser tratada como lacuna de visibilidade, não como garantia de que não houve exploração.