CVE-2019-15752

Falha de escalonamento de privilégio local no Docker Desktop Community Edition para Windows, anterior à versão 2.1.0.1. Um usuário local sem privilégios pode plantar um executável malicioso chamado docker-credential-wincred.exe em um diretório de sistema gravável e esperar que um administrador (ou o próprio serviço) o execute com privilégios elevados. Importa porque está no catálogo KEV da CISA com exploração confirmada e tem módulo Metasploit público, mas o vetor é estritamente local — não é explorável remotamente nem sem uma conta prévia na máquina.

O problema é uma permissão incorreta em recurso crítico (CWE-732, classificação da CISA). O diretório %PROGRAMDATA%\DockerDesktop\version-bin\ ficava com permissões de escrita abertas para usuários de baixo privilégio, quando deveria estar restrito a administradores. Docker Desktop usa esse diretório para localizar o helper binário docker-credential-wincred.exe, responsável por integrar o cliente Docker com o Windows Credential Manager ao autenticar em registries.

Como o diretório aceita escrita de qualquer usuário local, um atacante sem privilégios pode substituir esse binário por um executável arbitrário com o mesmo nome — um clássico binary planting. O sistema não valida assinatura, hash ou origem do arquivo antes de invocá-lo; ele confia na localização do caminho.

O gatilho fica fora do controle do atacante: o binário malicioso só executa quando um processo com privilégio mais alto — o serviço Docker, um administrador que roda 'docker login', reinicia o Docker Desktop, ou autentica de outra forma — invoca o helper de credenciais. Nesse momento, o código do atacante roda no contexto de quem disparou a ação, que tipicamente é uma conta administrativa ou o serviço do Docker executando com privilégios elevados no Windows.

Pré-requisito real: acesso local à máquina Windows com uma conta de baixo privilégio (AV:L, PR:N no vetor CVSS). Não há componente de rede, não há autenticação remota, não há necessidade de configuração não padrão além da instalação vulnerável do Docker Desktop. O único elemento fora do controle do atacante é a interação humana (UI:R): é preciso que um usuário com privilégio maior — administrador ou o serviço do sistema — realize uma ação que force a chamada ao binário de credenciais, como autenticar no Docker, reiniciar o serviço, ou rodar 'docker login'.

Na prática o ataque é passivo depois do plantio: o atacante deposita o arquivo malicioso no diretório gravável e espera. Não exige engenharia social direcionada contra a vítima, só a rotina normal de uso do Docker por quem tem privilégio administrativo na máquina compartilhada. Isso é comum em ambientes de desenvolvimento com múltiplos usuários na mesma workstation Windows, VDIs corporativos, ou máquinas de laboratório compartilhadas.

O resultado final é execução de código arbitrário no contexto do usuário/serviço privilegiado, ou seja, escalonamento completo para admin/local system na máquina Windows. A presença no catálogo KEV da CISA confirma exploração em ambiente real, e a existência de módulo Metasploit e PoC pública (PacketStorm) reduz a barreira técnica para replicar o ataque uma vez identificado o alvo vulnerável.

A correção do fornecedor é atualizar para Docker Desktop Community Edition 2.1.0.1 ou posterior, que ajusta as permissões do diretório version-bin para restringir escrita a administradores. Esta é a única remediação completa confirmada nas fontes.

Se a atualização não for imediata, o paliativo tecnicamente válido é corrigir manualmente a ACL do diretório %PROGRAMDATA%\DockerDesktop\version-bin\, removendo permissão de escrita para usuários e grupos não administrativos, deixando apenas Administradores e SYSTEM com controle total. O custo é operacional: exige intervenção manual em cada máquina, pode ser revertido por reinstalações ou atualizações que recriem o diretório com as permissões originais, e não escala bem em frotas grandes sem automação via GPO ou script de hardening.

Não funciona como mitigação: antivírus genérico sem regra específica para monitorar esse caminho, ou confiar em UAC — o ataque não depende de bypass de UAC, depende de o binário malicioso já estar posicionado e ser invocado legitimamente por um processo privilegiado. Trocar senhas ou isolar contas de usuário sem revisar a ACL do diretório não resolve o vetor.

Monitorar criação ou modificação de arquivos no diretório %PROGRAMDATA%\DockerDesktop\version-bin\, em especial qualquer versão de docker-credential-wincred.exe cujo hash não corresponda ao binário oficial distribuído pelo Docker, ou cujo timestamp de criação não coincida com a instalação/atualização do produto. Auditar a ACL desse diretório para verificar se contas não administrativas têm permissão de escrita é o sinal preventivo mais confiável.

Como é um ataque puramente local e sem tráfego de rede associado, não há assinatura de rede ou IDS aplicável. Em nível de host, processos filhos inesperados originados do serviço Docker Desktop (com.docker.service) ou do processo docker.exe/dockerd, executando binários fora do padrão esperado, são indício de exploração já em andamento — mas a ausência desses sinais não garante que o sistema não foi comprometido, já que o binary planting pode ficar dormente até a próxima ação administrativa.