CVE-2019-18988
Corrija agora. Ela está sob exploração confirmada pelo CISA e tem exploit funcional público.
Apply updates per vendor instructions.
Resumo
TeamViewer Desktop usa uma chave AES fixa, idêntica em todas as instalações do mundo, para criptografar valores sensíveis armazenados no registro do Windows (ou em arquivos de configuração exportados) — incluindo, em versões anteriores à 9.x, a senha de Unattended Access que permite login remoto e navegação de arquivos sem interação do usuário. Como a chave é estática e foi extraída por engenharia reversa, qualquer um que consiga ler essas entradas de registro consegue decifrá-las offline, sem precisar quebrar criptografia nenhuma. O impacto real depende muito da versão e de como esses dados chegam ao atacante — o CVSS 7.0 (AV:L) já reflete que isso não é exploração remota direta.
Detalhamento técnico
A falha (CWE-521, uso de mecanismo de proteção de senha inadequado/compartilhado) está no esquema de criptografia local do cliente TeamViewer para Windows. Diversas chaves de registro — SecurityPasswordAES, SecurityPasswordExported, ServerPasswordAES, ProxyPasswordAES, LicenseKeyAES e OptionsPasswordAES — são cifradas com AES-128-CBC usando uma chave e um IV hardcoded no binário, iguais para toda instalação do produto, documentados publicamente pelo pesquisador como key 0602000000a400005253413100040000 e IV 0100010067244F436E6762F25EA8D704. A engenharia reversa foi feita depurando o processo durante a decriptação (instrução aesdec) até localizar a rotina responsável, sem precisar de acesso a servidores da TeamViewer — a chave está estática no cliente, não é baixada em runtime.
O alcance de cada chave de registro varia: SecurityPasswordAES guardava a senha estática de Unattended Access em versões anteriores à TeamViewer 9 (modelo pré-SRP); ServerPasswordAES nunca chegou a ser usada em produção; ProxyPasswordAES guarda credencial de proxy configurado manualmente (uso raro); LicenseKeyAES guarda a chave de licença perpétua (irrelevante em modelos de assinatura, TeamViewer 15); e OptionsPasswordAES — a que segue vulnerável na versão então atual do produto — protege apenas o acesso ao painel de configurações locais, não a autenticação de conta. A partir da versão 9, a TeamViewer passou a usar Secure Remote Password (SRP) para a senha de conta e para o PermanentPassword, o que o próprio fornecedor confirma não estar afetado por este problema.
É importante notar a divergência entre o CVE (que fala em 'bypass de controle de acesso de login remoto') e o que o fornecedor caracteriza como escopo real: segundo a TeamViewer, não há elevação de privilégio direta nem comprometimento do mecanismo de autenticação de conta — o único vetor de escalonamento de privilégio depende de reuso de senha em outros serviços, não da vulnerabilidade em si.
Como é explorada
O pré-requisito central, e o ponto mais subestimado da CVE, é que o atacante já precisa ter acesso de leitura ao registro (ou a um arquivo de configuração/.reg exportado) da máquina-alvo — via sessão local com privilégio de usuário padrão, compartilhamento de rede mal configurado, backup exposto, ou repositório online onde essas chaves tenham sido deixadas. Não é uma vulnerabilidade explorável pela rede contra o serviço TeamViewer em execução; é decriptação offline de dados já obtidos por outro meio. Uma vez com as entradas de registro em mãos, a decriptação usando a chave AES fixa é trivial e determinística — não há brute-force nem dependência de senha do usuário.
Na prática documentada pelo pesquisador, o caso mais grave envolveu encontrar um backup de chaves de registro do TeamViewer em um compartilhamento de arquivos da rede de um cliente, decifrar OptionsPasswordAES com uma ferramenta de terceiros (BulletPassView) e usar isso para acessar o painel de configuração do TeamViewer instalado — não diretamente uma conta ou sessão de vítima. Para a senha de Unattended Access (SecurityPasswordAES), o vetor só se aplica a instalações em versão anterior à 9.x, onde essa senha estática ainda existe; em versões modernas o valor equivalente (PermanentPassword) usa SRP e não é afetado por esta chave AES.
O catálogo KEV da CISA confirma exploração ativa in-the-wild (motivo de estar listado), e existem PoC pública e módulo Metasploit para automatizar a decriptação uma vez obtidas as chaves de registro. Isso reduz a barreira técnica: um atacante com acesso local ou a um dump/backup de registro não precisa reverter nada — só rodar a ferramenta pública contra os valores capturados.
Versões
Como se proteger
As fontes consultadas não trazem um número de versão específico anunciado pela TeamViewer como 'corrigida' para esta CVE — o fornecedor publicou um plano de mitigação por chave de registro (fortalecer a criptografia de SecurityPasswordAES, SecurityPasswordExported e OptionsPasswordAES; remover ServerPasswordAES do cliente; remover LicenseKeyAES do fluxo de assinatura da v15) mas não citou um número de build corrigido nesse anúncio. Não afirme uma versão fixa que você não verificou diretamente no changelog atual do fornecedor.
Controles compensatórios reais: restringir permissão de leitura no registro (HKLM/HKCU) das chaves do TeamViewer para usuários não administrativos onde a política do ambiente permitir; nunca exportar configurações do TeamViewer para arquivos .reg armazenados em compartilhamentos de rede ou repositórios acessíveis; auditar backups e file shares por arquivos de configuração do TeamViewer expostos; desabilitar Unattended Access com senha estática em instalações legadas (pré-v9) e migrar para autenticação baseada em conta/SRP, que não é afetada. Trocar a senha do Unattended Access não neutraliza o problema estrutural — a chave AES continua compartilhada entre todas as instalações do mundo — mas reduz a janela de reuso caso as chaves já tenham sido vazadas.
O que não funciona como mitigação: assumir que o problema está resolvido só porque a instância usa autenticação por conta (SRP) — isso protege a conta, não o OptionsPasswordAES local, que continua usando a mesma criptografia fraca. Também não é mitigação apenas trocar a senha de configuração sem revogar/rotacionar backups de registro já existentes fora da máquina.
Como detectar
Não há assinatura de rede confiável para detectar exploração, porque o ataque é decriptação offline de dados já extraídos (registro ou arquivo de configuração) — não há tráfego malicioso característico contra o serviço TeamViewer. Os sinais possíveis são indiretos: acesso ou cópia das chaves de registro HKLM/HKCU relacionadas ao TeamViewer (SecurityPasswordAES, OptionsPasswordAES, ProxyPasswordAES, LicenseKeyAES) por processos ou contas fora do padrão administrativo, exportação de configurações do TeamViewer para .reg, presença de arquivos de configuração/backup do TeamViewer em compartilhamentos de rede, e uso de ferramentas conhecidas de extração de senha do registro (ex.: NirSoft) em hosts com TeamViewer instalado. Monitoramento de EDR para leitura anômala dessas chaves de registro por usuários não administrativos é o controle de detecção mais próximo de confiável disponível.