CVE-2020-11651

Falha de autenticação na classe ClearFuncs do salt-master (SaltStack Salt) permite que qualquer atacante com acesso de rede às portas do master invoque métodos que deveriam exigir autenticação. Com isso é possível extrair tokens de usuários autenticados e executar comandos arbitrários nos minions geridos por aquele master — comprometimento total da infraestrutura gerenciada, não só de um host isolado. O CVSS 9.8 é justificado: não há pré-requisito de autenticação, complexidade é baixa e o impacto é execução de código em toda a frota de minions.

O salt-master expõe duas interfaces RPC: uma autenticada (AESFuncs, cifrada com a chave da minion) e uma "clear" (ClearFuncs), usada para operações que precisam ocorrer antes da autenticação completa, como o próprio processo de autenticação. O problema é que o ClearFuncs não validava corretamente quais métodos um cliente remoto podia invocar sem apresentar credenciais — a superfície de métodos acessíveis "em claro" era maior do que deveria, incluindo funções que retornam segredos (tokens de usuários) ou disparam execução de jobs nos minions.

A classificação de CWE varia entre as fontes: o advisory da Cisco rotula CWE-20 (validação de entrada imprópria), mas a natureza do defeito — chamar método sensível sem checar se o chamador está autenticado — é essencialmente um problema de controle de acesso ausente/insuficiente sobre operações RPC expostas na rede.

O atacante não controla parâmetros de payload no sentido de injeção; ele controla qual método RPC do ClearFuncs deseja invocar e com quais argumentos esse método aceita nativamente. Como alguns desses métodos aceitam instruções de publicação de jobs para minions, o resultado prático é execução de comandos arbitrários nos minions conectados àquele master, além de leitura de tokens de sessão que dão acesso equivalente a um usuário legítimo do salt.

A correção oficial (releases 2019.2.4 e 3000.2) introduziu uma lista explícita ('whitelist') de métodos que ClearFuncs e AESFuncs podem expor sem autenticação completa. O próprio changelog da 3000.2 registra um efeito colateral da correção: um typo na whitelist (`_minion_runner` em vez de `minion_runner`) quebrou o módulo `publish.runner`, corrigido apenas na release Sodium subsequente.

O vetor é rede: o salt-master escuta por padrão nas portas TCP 4505 (publish) e 4506 (request/ClearFuncs). Se essas portas estiverem alcançáveis por um atacante — situação comum em ambientes onde o master foi exposto à internet ou a redes internas amplas sem segmentação — a exploração não exige nenhuma credencial, interação do usuário ou configuração não padrão adicional: basta enviar as chamadas RPC ao ClearFuncs. Isso está refletido no vetor CVSS (AC:L, PR:N, UI:N).

Há exploração ativa confirmada: a falha está no catálogo KEV da CISA, existe módulo Metasploit público e PoCs publicadas (incluindo análises técnicas referenciadas via PacketStorm descrevendo RCE contra Salt Master/Minion). O advisory da Cisco documenta um caso concreto: servidores salt-master mantidos pela própria Cisco para dar suporte ao Cisco VIRL-PE (us-1 a us-4.virl.info, vsm-us-1/2.virl.info) foram efetivamente comprometidos antes de serem corrigidos em maio de 2020, ilustrando que a exploração em campo ocorreu em produção, não só em laboratório.

O resultado final da exploração é: (1) exfiltração de tokens de autenticação de usuários do salt, que podem ser reutilizados para operações autenticadas subsequentes; e/ou (2) execução arbitrária de comandos em qualquer minion conectado ao master vulnerável — na prática, controle total sobre toda a frota gerenciada por aquele master, já que o salt-master é o ponto central de orquestração.

A correção definitiva é atualizar para Salt 2019.2.4 (branch 2019.2.x) ou 3000.2 (branch 3000.x), que implementam a whitelist explícita de métodos RPC acessíveis sem autenticação completa. Distribuições fizeram backport: Debian LTS (Jessie) corrigiu em 2014.1.13+ds-3+deb8u1; Ubuntu corrigiu via USN-4459-1 nas versões 2017.7.4+dfsg1-1ubuntu18.04.2 (18.04) e 2015.8.8+ds-1ubuntu0.1 (16.04); openSUSE publicou avisos equivalentes. Produtos que embarcam Salt, como Cisco CML/VIRL-PE, receberam patches próprios do fornecedor.

Se a atualização imediata não for viável, o controle compensatório real é restringir o acesso de rede às portas 4505/4506 do salt-master a apenas hosts que precisam se comunicar com ele (firewall/segmentação), já que a exploração depende de alcançar essas portas sem autenticação. A própria Cisco recomenda, como workaround, desabilitar o serviço salt-master quando ele não for necessário para a operação do produto. Nenhuma dessas medidas substitui o patch: elas apenas reduzem a superfície exposta enquanto a atualização não ocorre.

Vale notar que a correção desta CVE está atrelada à mesma release que corrige a CVE-2020-11652 (directory traversal na mesma classe ClearFuncs) — atualizar para 2019.2.4/3000.2 resolve ambas simultaneamente. Um mito a descartar: apenas restringir acesso via ACL de aplicação Salt (eauth) não é mitigação suficiente, porque a falha está no nível do ClearFuncs antes da camada de autenticação ser aplicada — o controle precisa ser de rede ou de patch.

O sinal mais direto é monitorar conexões de rede às portas TCP 4505 e 4506 do salt-master vindas de origens não esperadas (fora da rede de minions/administração legítima) — a exploração depende de acesso direto a essas portas sem autenticação prévia. Logs do próprio salt-master podem registrar chamadas RPC anômalas ao ClearFuncs (por exemplo, invocações de métodos de gerenciamento de token ou disparo de jobs vindas de IPs que não são minions cadastrados), mas a granularidade desses logs varia por versão e configuração, e não há um indicador único e confiável documentado nas fontes revisadas — presença de PoC pública e módulo Metasploit tornam plausível que scanners de rede genéricos testem essas portas, então tráfego de reconhecimento nessas portas por si só já é um sinal de atenção.