CVE-2019-11001

Câmeras IP Reolink dos modelos RLC-410W, C1 Pro, C2 Pro, RLC-422W e RLC-511W, em firmware até a versão 1.0.227, permitem que um administrador já autenticado injete comandos de sistema via o parâmetro addr1 da funcionalidade de teste de e-mail (TestEmail), obtendo execução como root. O CVSS de 7.2 reflete a exigência de privilégio alto (PR:H) para explorar, mas o impacto é total: controle irrestrito do dispositivo. Está no catálogo KEV da CISA com exploração confirmada, e a própria CISA já trata o produto como possivelmente EoL/EoS.

A falha é uma injeção de comandos OS (CWE-78) no processo que trata a funcionalidade 'TestEmail' da interface administrativa da câmera, provavelmente exposta via uma API HTTP/JSON usada para validar configurações de SMTP antes de salvá-las. O campo addr1 (endereço de e-mail/servidor usado no teste) é concatenado sem sanitização em uma chamada de shell no lado do dispositivo, permitindo que metacaracteres de shell (como ; , | , `` ` `` ou $()) quebrem o contexto do comando original e injetem comandos arbitrários.

O processo que executa esse comando roda como root — não há isolamento de privilégio nem sandboxing entre o serviço web/administrativo e o restante do firmware embarcado, algo comum em dispositivos IoT baseados em Linux embarcado com pouca segregação de processos. Isso significa que qualquer injeção bem-sucedida resulta em comprometimento total do sistema operacional do dispositivo, não apenas do serviço de e-mail.

O PoC público (bashis/mcw0) mostra o fluxo completo: autenticação via endpoint de login que retorna um token de sessão, seguida pelo envio da requisição TestEmail com o payload malicioso no campo addr1, e confirmação da execução (retorno HTTP 200) — a shell reversa obtida no PoC evidencia uid=0(root) gid=0(root).

Pré-requisito central, muitas vezes esquecido ao ler só o CVSS: o atacante precisa de credenciais administrativas válidas na câmera (PR:H) — não é uma falha pré-autenticação. Uma vez autenticado, o exploit é trivial e determinístico: uma única requisição HTTP para o endpoint de teste de e-mail com metacaracteres de shell no campo addr1 é suficiente, sem interação do usuário-alvo (UI:N) e sem necessidade de condições de rede especiais além de acesso à interface administrativa (geralmente porta 80/443 do dispositivo).

Na prática, o vetor de ataque real não é 'roubar' credenciais complexas — muitas dessas câmeras são implantadas com credenciais padrão ou fracas, e há histórico de outras falhas de autenticação em produtos Reolink da mesma geração de firmware. Isso reduz a barreira de PR:H a algo alcançável por scanners de credenciais padrão combinados com esse exploit, o que provavelmente explica a exploração confirmada registrada pela CISA.

O resultado final é execução de comando arbitrário como root no firmware embarcado da câmera: persistência, pivô para a rede interna (a câmera fica tipicamente na LAN), exfiltração ou manipulação do stream de vídeo, e inclusão do dispositivo em botnets — padrão comum de abuso de câmeras IP vulneráveis.

O fornecedor não publicou, nas fontes disponíveis, uma versão de firmware específica que corrija esta CVE. A própria CISA, ao adicionar o CVE ao catálogo KEV em dezembro de 2024, orienta que o produto pode estar em fim de vida (EoL/EoS) e que, se não houver mitigação atual disponível, o uso deve ser descontinuado — aponta para as páginas de EoL e download center da Reolink como referência, sem indicar versão corrigida confirmada.

Como paliativo real na ausência de patch: eliminar credenciais padrão/fracas na conta admin (reduz a chance de um atacante alcançar a pré-condição de autenticação), restringir o acesso à interface administrativa da câmera exclusivamente a redes de gerência isoladas (nunca expor a porta de administração à internet), e desabilitar a funcionalidade de e-mail/TestEmail se não for utilizada. Segmentação de rede (VLAN dedicada para câmeras, sem rota para a rede corporativa) limita o dano em caso de comprometimento, mas não elimina a vulnerabilidade.

O que não funciona como mitigação: trocar só a senha do e-mail configurado ou desativar notificações de alerta não impede a injeção, pois a falha está no processamento do campo addr1 pelo binário administrativo, não na lógica de envio de e-mail em si. Um WAF de borda também não ajuda aqui, já que o tráfego é para a interface de gestão do próprio dispositivo, normalmente não passando por um proxy corporativo.

Não há assinatura ou log nativo documentado nas fontes consultadas para detectar tentativas de exploração. Como indicador de rede, é possível monitorar requisições HTTP/HTTPS destinadas à interface administrativa da câmera direcionadas ao endpoint de teste de e-mail (TestEmail) que contenham metacaracteres de shell (;, |, `, $(), &&) no campo addr1 — presença desses caracteres num campo que deveria conter apenas um endereço de e-mail/servidor é um forte indício de tentativa de injeção.

Na ausência de logging de auditoria detalhado no próprio firmware Reolink (comum em dispositivos IoT desse porte), a detecção prática depende de captura de tráfego de rede (mirroring de porta ou IDS na VLAN das câmeras) e de correlação com tentativas de login administrativo bem-sucedidas seguidas imediatamente por chamadas ao endpoint de e-mail — sinal de automação típica de exploit conhecido/PoC público.