CVE-2017-6327
Prioriza la corrección. Ella está bajo explotación confirmada por CISA y tiene prueba de concepto pública.
Apply updates per vendor instructions.
Resumen
Falha de RCE não autenticada no Symantec Messaging Gateway (SMG, ex-Brightmail), o appliance de anti-spam/segurança de e-mail da Symantec. A cadeia combina um bypass de autenticação na interface web com uma injeção de comando em uma função de restauração de backup, permitindo execução de comandos como root sem nenhuma credencial válida. Está no catálogo KEV da CISA com exploração confirmada e PoC pública desde 2017, o que a torna crítica para qualquer appliance ainda exposto.
Detalle técnico
A vulnerabilidade é, na prática, duas falhas encadeadas dentro da interface web do SMG (Apache Tomcat/JSP). A primeira (bypass de autenticação, CWE-287) está em LoginAction.class: o método público LoginAction.notificationLogin é acessível sem sessão via GET em /brightmail/action1.do?method=notificationLogin. Esse método decripta o parâmetro `notify` usando BrightmailDecrypt.decrypt (PBEWithMD5AndDES com uma senha estática embutida no próprio código), usa o valor decriptado como e-mail para montar um objeto UserTO, cria uma nova sessão e seta o atributo `user`. Ou seja: qualquer requisição não autenticada pode se autenticar como um usuário existente — ou fazer o sistema criar um novo — apenas conhecendo (ou extraindo do binário/jar) a senha de criptografia fixa.
Cómo se explota
Com a sessão autenticada obtida pelo bypass, o atacante explora a segunda falha: RestoreAction.performRestore aceita os parâmetros `restoreSource` e `localBackupFilename`/`localBackupFileSelection`. Esse valor percorre uma cadeia de chamadas até o daemon local `bmagent` (porta 41002), que invoca /opt/Symantec/Brightmail/cli/bin/db-restore com o valor do atacante como argv[1]. Esse script é um wrapper sudo para um script Perl (/opt/Symantec/Brightmail/cli/sbin/db-restore) que injeta o argumento sem sanitização em uma chamada a /usr/bin/du, permitindo injeção de comandos de shell (CWE-78) executados com privilégio root.
A função performRestore é protegida por um token anti-CSRF, mas o token pode ser obtido com uma simples requisição GET não autenticada a /brightmail/common.jsp e reutilizado em qualquer requisição subsequente — não há vínculo real com a sessão do usuário legítimo, então essa proteção não impede o encadeamento.
O resultado documentado publicamente (por Philip Pettersson, que reportou a falha à Symantec e publicou o advisory técnico completo) é execução de comando arbitrário como root a partir de uma requisição HTTP não autenticada contra a interface de administração exposta. Não há pré-requisito de configuração não padrão: o vetor depende apenas da interface web de gerência estar acessível na rede do atacante. A presença no catálogo KEV da CISA confirma exploração em ambiente real, embora a CISA não detalhe campanhas específicas.
Versiones
Cómo protegerse
A correção é aplicar a atualização do fornecedor — a descrição oficial do CVE cita a versão 10.6.3-267 como corrigida; o advisory técnico do pesquisador refere-se à mesma cadeia de correção como cobrindo até a versão 10.6.3-2 (numeração de build interna do fornecedor). Aplique o patch/hotfix oficial da Symantec anunciado em 10/08/2017 e confirme a versão de build pós-patch reportada pelo painel administrativo do appliance — não a versão marketing.
Como paliativo real quando a atualização não é imediata: restrinja o acesso à interface web de administração do SMG (portas HTTPS de gerência e a porta 41002 do bmagent) apenas a redes de gestão confiáveis, nunca exposta à internet ou a segmentos de usuário — isso neutraliza o vetor porque a exploração depende de conseguir alcançar /brightmail/action1.do e a função de restore pela rede. Monitorar e desabilitar a interface se não for estritamente necessária também reduz a superfície.
Não funciona como mitigação: depender apenas de autenticação forte na interface, já que a falha é justamente um bypass dessa autenticação; e não funciona confiar no token anti-CSRF como controle de segurança, pois ele é obtenível sem autenticação prévia.
Cómo detectar
Nos logs de acesso web do appliance, procure requisições GET não autenticadas a /brightmail/action1.do?method=notificationLogin contendo um parâmetro `notify` codificado — isso é o padrão do bypass de autenticação e não deveria ocorrer em uso legítimo sem sessão prévia. Combine com buscas por acessos subsequentes a /brightmail/common.jsp seguidos rapidamente por /brightmail/admin/restore/action5.do?method=performRestore com parâmetros `localBackupFileSelection` ou `localBackupFilename` contendo metacaracteres de shell (crases, ponto e vírgula, `>`, `>>`). Também vale verificar arquivos inesperados gravados sob /data/bcc/webapps/brightmail/ (webroot), já que a técnica pública de exploração grava saída de comando ali para exfiltração via HTTP, e revisar logs do daemon bmagent na porta 41002 por invocações de db-restore com argumentos anômalos.