CVE-2016-3643

Falha de configuração no sudo do appliance SolarWinds Virtualization Manager (versões até 6.3.1) permite que qualquer usuário local com shell no sistema operacional execute comandos como root, sem restrição de comando ou senha adicional. Não é uma falha de código explorável remotamente — exige que o atacante já tenha uma conta e acesso a shell no appliance, o que limita bastante o cenário de risco em relação ao que o CVSS 7.8 sugere isoladamente.

A causa é uma configuração incorreta do sudoers (CWE-264, gestão inadequada de permissões) no appliance de virtualização da SolarWinds. O arquivo de configuração do sudo concede a usuários locais — aparentemente sem exigir privilégio elevado prévio — a capacidade de executar comandos arbitrários como superusuário através do sudo, sem as restrições de comando que normalmente limitariam essa permissão a tarefas administrativas específicas.

O appliance é distribuído como uma VM/imagem pré-configurada, o que significa que a falha está potencialmente presente em todas as instalações que usam a configuração padrão de fábrica até a versão 6.3.1. Não há detalhe público sobre qual regra exata do sudoers estava mal configurada (se era um NOPASSWD: ALL, um wildcard mal formado, ou permissão para um binário perigoso), apenas a demonstração de que o comando 'sudo cat /etc/passwd' funciona sem restrição para um usuário de baixo privilégio.

O atacante não controla nenhum parâmetro de entrada complexo: o vetor é a própria política de sudo do sistema, que ele invoca diretamente. Isso está mais próximo de um erro de hardening do produto do que de uma vulnerabilidade de software tradicional (buffer overflow, injection, etc.).

A exploração requer acesso local prévio: o atacante precisa já ter uma conta com shell no sistema operacional do appliance (AV:L, PR:L no vetor CVSS). Isso pode ocorrer via SSH com credenciais de baixo privilégio, acesso físico/console, ou como movimento lateral após comprometer outra aplicação que roda no mesmo host. Não há vetor de rede direto documentado que crie esse acesso inicial — a CVE trata exclusivamente da escalação de privilégios subsequente.

Uma vez com shell, a exploração é trivial e não exige senha adicional nem interação do usuário (UI:N): basta invocar sudo com qualquer comando, já que a política liberada não impõe restrição de comando nem exige reautenticação factível de bloquear o abuso. O PoC público demonstra isso com 'sudo cat /etc/passwd', mas qualquer comando arbitrário como root funciona da mesma forma — leitura de /etc/shadow, escrita em arquivos de sistema, criação de contas, etc.

A vulnerabilidade está no catálogo KEV da CISA (adicionada em 2021-11-03, prazo de correção 2022-05-03), indicando exploração confirmada em ambientes reais, apesar de ser uma CVE antiga (2016) e de baixa complexidade técnica. Isso é consistente com o padrão de apliances de gestão/monitoramento sendo usados como pivô após comprometimento inicial de credenciais de baixo privilégio.

A SolarWinds lançou um hotfix disponibilizado aos clientes em 1º de junho de 2016, que corrige a configuração do sudo; a versão corrigida é a 6.3.1 ou posterior (release corrigido incorporado a partir daí, conforme o advisory do descobridor). Aplicar esse hotfix/atualização é a correção real — não existe menção pública a um patch de código, apenas ajuste de configuração do sudoers no appliance.

Onde a atualização não for imediatamente viável, o controle compensatório é revisar manualmente o arquivo /etc/sudoers (ou /etc/sudoers.d) do appliance e restringir as entradas que concedem execução irrestrita de comandos a usuários não administrativos, removendo qualquer NOPASSWD: ALL ou equivalente genérico. Isso tem custo operacional baixo, mas exige acesso administrativo ao appliance e conhecimento de qual configuração era a legítima antes da correção — informação que o advisory público não detalha, então a auditoria deve ser feita comparando com uma instalação já corrigida ou com orientação direta do fornecedor.

Não funciona como mitigação apenas restringir acesso de rede ao appliance (firewall, segmentação): como a falha exige acesso local já estabelecido, controles de rede reduzem a superfície de obtenção desse acesso inicial, mas não corrigem a escalação em si assim que um usuário de baixo privilégio (legítimo ou comprometido) tiver shell.

Em nível de host, o sinal mais direto é auditoria do sudoers (/etc/sudoers, /etc/sudoers.d) buscando entradas que concedam NOPASSWD ou ALL sem restrição de comando a usuários não administrativos — presença dessa configuração indica exposição, independente de exploração. Em logs, o uso do sudo é registrado por padrão em /var/log/auth.log ou /var/log/secure (via syslog); comandos suspeitos executados como root por contas que normalmente não teriam essa necessidade (ex.: leitura de /etc/shadow, /etc/passwd, criação de usuários) são indício de abuso, mas como o sudo estava mal configurado para permitir qualquer comando, não há uma assinatura específica de exploração — o próprio uso legítimo de sudo se mistura ao abuso. Não há um IOC de rede aplicável, já que o vetor é inteiramente local.