CVE-2021-40870

Falha crítica no Aviatrix Controller (linha 6.x) que permite a um atacante não autenticado enviar um arquivo PHP arbitrário para dentro do diretório web via travessia de diretório em um parâmetro de API, e depois executá-lo simplesmente acessando a URL correspondente. Não exige autenticação nem configuração especial — qualquer instância exposta na internet com a versão vulnerável está em risco direto de execução remota de código como root/serviço web.

O Aviatrix Controller expõe um conjunto de endpoints de API (ex.: /v1/backend1) que deveriam exigir um CID (session token) válido, mas várias ações — entre elas set_metric_gw_selections — não fazem a checagem de autenticação corretamente. Isso é a raiz do problema: falta de controle de acesso em endpoints de backend pensados para uso interno da aplicação.

Um segundo defeito se combina com o primeiro: o parâmetro account_name dessas chamadas é usado para compor um caminho de arquivo no filesystem sem sanitização de sequências '../' (CWE-25, path traversal), e o conteúdo enviado no parâmetro data é gravado nesse caminho sem validação de tipo/extensão (CWE-434/CWE-96, unrestricted upload). O atacante controla integralmente o caminho de destino (podendo sair da pasta de upload esperada e cair dentro da webroot servida pelo PHP) e o conteúdo do arquivo (podendo embutir código PHP arbitrário).

O resultado é escrita de arquivo arbitrário fora do diretório pretendido, seguida de execução, porque o arquivo gravado fica acessível e é interpretado pelo servidor web front-end (PHP). Não há isolamento entre a área de upload legítima da aplicação e o restante da árvore web.

Vale notar uma pequena divergência de score entre fontes: a NVD calcula CVSS 9.8 com Scope Unchanged (S:U), enquanto o advisory do pesquisador que reportou a falha (Tradecraft) calcula 10.0 com Scope Changed (S:C) — mesma cadeia de exploração, avaliação de impacto de escopo diferente.

A exploração documentada publicamente consiste em uma requisição HTTP direta ao endpoint /v1/backend1 do controller, informando um CID qualquer (não validado), a ação set_metric_gw_selections, e usando o parâmetro account_name para atravessar diretórios até um local dentro da pasta servida pelo PHP (ex.: var/www/php), gravando um arquivo com extensão .php cujo conteúdo (parâmetro data) contém código PHP. Uma segunda requisição, um simples GET ao caminho do arquivo recém-criado, dispara a execução do código.

Pré-requisitos reais: apenas acesso de rede à interface HTTPS de gerenciamento do controller — nenhuma credencial, nenhuma interação de usuário, nenhuma configuração não padrão. Isso explica o CVSS alto e por que a falha é tratada como crítica de fato, não só no papel. A complexidade técnica de exploração é baixa: a cadeia (bypass de auth em API interna + path traversal + upload) é direta e já foi publicada como PoC.

A CISA confirmou exploração ativa em ambiente real (entrada no catálogo KEV desde 18/01/2022, com prazo de correção definido para 01/02/2022), e existe template Nuclei público, o que indica varredura automatizada em massa contra instâncias expostas. O resultado final da exploração é execução arbitrária de código no host do controller, tipicamente com privilégios do processo web — na prática, controle total do controller, que por sua vez gerencia infraestrutura de rede/cloud (gateways, VPCs, contas cloud) — o que amplia o impacto muito além do host afetado.

A correção definitiva é atualizar para a versão de cada branch indicada pelo fornecedor/pesquisador: UserConnect-6.2-1804.2043 ou posterior, UserConnect-6.3-1804.2490 ou posterior, UserConnect-6.4-1804.2838 ou posterior, ou UserConnect-6.5-1804.1922 ou posterior (a NVD resume isso como 'antes de 6.5-1804.1922' sendo a versão corrigida na linha principal). Não há patch de configuração documentado que neutralize a falha sem atualizar — o problema está na própria lógica dos endpoints de API, não em uma opção que possa ser desligada.

Como controle compensatório até a atualização, restringir o acesso de rede à interface de gerenciamento do controller (permitir apenas de redes administrativas confiáveis, nunca exposta livremente à internet) reduz a superfície de ataque, já que toda a cadeia depende de conseguir alcançar o endpoint HTTPS do controller. Isso não corrige a vulnerabilidade, apenas limita quem pode tentar.

Mito a descartar: exigir autenticação na UI não protege contra esta falha — o próprio advisory do pesquisador destaca que a UI pede login, mas várias chamadas de API de backend usadas internamente pela aplicação não validam sessão, então a presença de tela de login não é indicativo de proteção.

Em logs do servidor web/controller, procurar requisições POST para /v1/backend1 com o parâmetro action=set_metric_gw_selections combinado com valores de account_name contendo sequências de travessia de diretório ('../') e extensão .php — isso é o padrão de exploração publicado. Em seguida, requisições GET a caminhos .php incomuns dentro da webroot (fora dos scripts legítimos da aplicação) indicam a etapa de execução. Também vale auditar o filesystem do controller por arquivos .php recém-criados fora das pastas esperadas da aplicação. Não há um único indicador de rede confiável além desse padrão de payload, já que o tráfego é HTTPS para o mesmo endpoint usado legitimamente pela aplicação — sem decriptação/inspeção de payload na camada de aplicação, a detecção via NIDS puro é limitada.