CVE-2020-5722
Corrija agora. Ela está sob exploração confirmada pelo CISA e tem exploit funcional público.
Apply updates per vendor instructions.
Resumo
O recurso de recuperação de senha ('Esqueci minha senha') da interface web dos PBX IP Grandstream UCM6200 aceita um nome de usuário e usa esse valor em uma consulta SQLite vulnerável a injeção SQL (CWE-89), sem qualquer autenticação. Em versões anteriores a 1.0.19.20 essa injeção permitia execução remota de comandos como root; a partir dessa versão o vetor de RCE foi fechado por acidente (como efeito colateral de outra correção), mas a injeção SQL em si só foi corrigida na 1.0.20.17, permitindo até então injetar HTML arbitrário nos e-mails de recuperação de senha. Está no catálogo KEV da CISA com exploração confirmada, tem módulo Metasploit e PoC pública, o que torna a probabilidade de tentativa de exploração (EPSS ~0,84) muito alta para qualquer equipamento exposto à internet.
Detalhamento técnico
A falha está na função de 'Find Password' da interface HTTP do UCM62xx. O usuário fornecido é usado para consultar a tabela de usuários em um banco SQLite sem sanitização adequada, permitindo injeção SQL clássica (CWE-89). O parâmetro username não é apenas usado na query — em versões anteriores à 1.0.19.20, ele também é passado como argumento para um script Python (sendMail.py) invocado via popen(). Isso cria duas superfícies de exploração a partir da mesma entrada não sanitizada: a query SQL e a chamada de shell.
O pesquisador Jacob Baines (Tenable, TRA-2020-15) demonstrou que um payload como 'admin' or 1=1--' sobrevive à validação de existência do usuário no banco e, ao ser passado adiante para popen(), permite injetar metacaracteres de shell (backticks, ponto-e-vírgula) que resultam em execução de comando arbitrário como root — sem autenticação, sem interação do usuário.
Em resposta a uma CVE anterior e não relacionada (CVE-2019-10662, injeção de comando autenticada), a Grandstream adicionou um filtro que bloqueia metacaracteres de shell em todos os parâmetros HTTP. Esse filtro, lançado na versão 1.0.19.20, fechou o caminho para o popen() por coincidência — mas a injeção SQL subjacente na consulta ao SQLite continuou intacta e sem correção específica.
Como o filtro de metacaracteres não bloqueava todos os caracteres usados em HTML, entre a 1.0.19.20 e a 1.0.20.17 a mesma injeção SQL ainda permitia manipular o conteúdo do e-mail de recuperação de senha enviado à conta legítima, inserindo marcação HTML arbitrária (por exemplo, um link controlado pelo atacante contendo a senha do usuário como parâmetro). A correção definitiva da injeção SQL só chegou na 1.0.20.17.
Como é explorada
O vetor é uma requisição HTTP não autenticada ao endpoint de recuperação de senha da interface de administração/usuário do UCM62xx, com o campo de username carregando a carga de injeção SQL. Não há necessidade de credenciais, interação do usuário, nem configuração não padrão — a única pré-condição real é que a interface HTTP do equipamento esteja acessível pela rede (o que é comum em instalações que expõem a administração do PBX à internet, prática frequente nesse tipo de equipamento).
Em versões anteriores a 1.0.19.20, a exploração completa (Método 1, segundo a Tenable) encadeia a injeção SQL com metacaracteres de shell que chegam até a chamada popen() do script sendMail.py, resultando em execução de comando como root — inclusive shell reverso. Esse é o cenário coberto pelo módulo Metasploit e pelo template Nuclei disponíveis publicamente, o que reduz a complexidade de exploração a praticamente zero para quem tem a ferramenta.
Em versões entre 1.0.19.20 e antes de 1.0.20.17, a mesma injeção SQL não gera mais RCE (o filtro de metacaracteres bloqueia o encadeamento com popen()), mas ainda permite injetar HTML no e-mail de recuperação enviado à conta configurada — um vetor de menor impacto direto (não é RCE), mas útil para phishing ou vazamento indireto de informação, já que o e-mail original inclui a senha do usuário. A presença no catálogo KEV da CISA confirma exploração ativa em ambiente real, presumivelmente do vetor de RCE, que é o de maior valor para um atacante.
Versões
Como se proteger
A correção definitiva é atualizar para a versão 1.0.20.17 ou posterior, que corrige a injeção SQL na origem — eliminando tanto o vetor de RCE quanto o de injeção HTML. Atualizar apenas para 1.0.19.20 remove o caminho de execução de comando, mas deixa aberto o vetor de injeção HTML nos e-mails de recuperação até a 1.0.20.17.
Se a atualização imediata não for possível, o controle compensatório real é restringir o acesso à interface HTTP de administração do UCM62xx — via segmentação de rede, VPN ou firewall — de forma que ela não seja alcançável a partir da internet pública ou de redes não confiáveis, já que a exploração exige apenas alcance de rede sem autenticação. Isso não corrige a vulnerabilidade, apenas reduz a superfície de exposição; qualquer host que consiga alcançar a porta HTTP/HTTPS da administração continua explorável.
Não há mitigação eficaz baseada em desabilitar apenas o recurso 'Esqueci minha senha' pela interface, pois isso depende de disponibilidade dessa funcionalidade em cada versão de firmware e não é uma configuração documentada como suportada; a atualização de firmware é o caminho validado pelo fornecedor. WAF genérico pode bloquear alguns padrões conhecidos de injeção SQL no campo username, mas como o Metasploit e templates Nuclei públicos existem, variações do payload podem contornar assinaturas simples — não deve ser tratado como substituto do patch.
Como detectar
Procurar em logs da interface HTTP do UCM62xx requisições ao endpoint de recuperação de senha ('Find Password'/'Forgot Password') cujo parâmetro de username contenha caracteres típicos de injeção SQL (aspas simples, `--`, `OR 1=1`) combinados com metacaracteres de shell (backtick, ponto-e-vírgula, `${IFS}`, chamadas a `nc`, `/bin/sh`) — esse padrão é característico do PoC público e do módulo Metasploit. Tráfego de saída inesperado do equipamento (conexões reversas, execução de netcat) após uma requisição a esse endpoint é forte indício de exploração bem-sucedida.
Como a exploração não deixa rastro em logs de autenticação (não há autenticação envolvida) e o SQLite não gera logs de erro por padrão na maioria das instalações, a ausência de outros sinais não indica ausência de tentativa — vale considerar qualquer acesso externo não esperado à interface de administração como suspeito, dado que exploração ativa já foi confirmada pela CISA.