CVE-2014-3120

Falha na configuração padrão do Elasticsearch anterior à versão 1.2: a execução de scripts dinâmicos (MVEL) via API REST vinha habilitada por padrão, sem autenticação, permitindo que um atacante injete expressões MVEL no parâmetro de script do endpoint _search e execute código Java arbitrário no host. É crítica porque o vetor é a interface HTTP padrão do banco de dados, exposta em milhares de instalações de desenvolvimento e produção da época, e está no catálogo KEV da CISA com exploração confirmada em campo, além de módulo Metasploit e PoC pública prontos.

O Elasticsearch permite parametrizar consultas e agregações com scripts (dynamic scripting) para calcular campos, ordenar resultados ou filtrar documentos. Antes da versão 1.2, essa funcionalidade vinha habilitada por padrão e aceitava a linguagem MVEL (Mvflex Expression Language) sem sandboxing efetivo. Qualquer requisição à API _search podia incluir um bloco 'script' com uma expressão MVEL, e o motor de scripting a compilava e executava no contexto da JVM do próprio servidor Elasticsearch.

O problema de fundo é duplo: (1) a API REST do Elasticsearch, na configuração padrão da época, não exigia autenticação nem controle de acesso — qualquer cliente com acesso de rede à porta HTTP (9200 por padrão) podia enviar a requisição; (2) o sandbox do MVEL não impedia acesso reflexivo a classes Java arbitrárias, então uma expressão bem construída conseguia alcançar java.lang.Runtime ou equivalentes e executar comandos no sistema operacional subjacente, e não apenas manipular dados dentro do índice. A CISA classifica isso sob CWE-284 (Improper Access Control) — a causa raiz não é um bug de parsing, é a decisão de design de expor uma linguagem de script Turing-completa, sem isolamento robusto, numa API sem autenticação.

A nota oficial do NVD registra que o fornecedor considerava isso violação da política de segurança apenas se o operador não rodasse o Elasticsearch em uma máquina virtual isolada — ou seja, o vendor via a execução de scripts como um recurso dentro de um perímetro de confiança esperado (a instância inteira), não como uma falha isolada. Na prática, a maioria dos deployments não isolava o Elasticsearch dessa forma, o que tornou a exploração trivialmente relevante.

O vetor é uma requisição HTTP simples ao endpoint de busca (_search) da API REST do Elasticsearch, contendo um script MVEL malicioso em campos como script_fields ou dentro da query. O módulo Metasploit (exploit/multi/elasticsearch/script_mvel_rce) confirma que a exploração não exige autenticação — basta acesso de rede à porta do serviço — e foi testado com sucesso em Elasticsearch 1.1.1 tanto em Linux quanto em Windows, retornando execução de comando arbitrário com os privilégios do processo Elasticsearch.

A complexidade é baixa: não há necessidade de engenharia social, nem de condições de corrida ou timing. O único pré-requisito real é a instância estar acessível na rede (frequentemente exposta sem firewall em ambientes de nuvem e desenvolvimento da época) e não ter desabilitado manualmente o scripting dinâmico. O CVSS informado carrega PR:L (privilégio baixo necessário), mas as fontes técnicas (Rapid7/Metasploit) descrevem a API como não autenticada por padrão — vale considerar essa divergência ao avaliar o risco real do seu ambiente: se a instância está isolada por rede ou atrás de proxy com autenticação, o cenário muda.

A presença no catálogo KEV da CISA (adicionada em 2022, bem depois da divulgação original de 2013/2014) indica exploração continuada em campo, tipicamente contra instâncias antigas ou mal atualizadas ainda expostas à internet — um padrão comum de scanners automatizados que buscam serviços Elasticsearch legados.

A correção do fornecedor foi desabilitar dynamic scripting por padrão a partir do Elasticsearch 1.2. A atualização para 1.2 ou posterior remove a exposição por padrão; versões subsequentes continuaram reforçando isolamento de scripts (sandboxing por linguagem, scripts pré-armazenados via arquivo em vez de inline) em releases posteriores da série 1.x e 2.x.

Quem não pode atualizar imediatamente deve desabilitar explicitamente a execução de scripts dinâmicos na configuração do Elasticsearch (script.disable_dynamic, dependendo da versão) e nunca expor a porta HTTP/transport da API diretamente à internet ou a redes não confiáveis — o controle de rede (firewall, bind em interface interna, proxy autenticado) é o paliativo mais efetivo quando o patch não é viável.

Um caso lateral relevante: o Logstash 1.4.2 vinha empacotado com binários do Elasticsearch 1.1.1 vulnerável, afetando especificamente quem usava o Elasticsearch output com protocolo 'node' (o node client se junta ao cluster e fica exposto ao mesmo vetor) ou a opção embedded=>true. A correção veio no Logstash 1.4.3, que passou a empacotar Elasticsearch 1.5.2 com scripting desabilitado por padrão; usuários de protocolo transport ou http no Logstash não eram afetados por essa via. Rodar a instância em VM isolada, como o fornecedor sugeriu como premissa de segurança, não é mitigação suficiente sozinha — reduz o impacto de um comprometimento mas não impede a execução de código nem exfiltração de dados do próprio índice.

Em logs de acesso HTTP do Elasticsearch, procure requisições POST/GET ao endpoint _search (ou a índices específicos com /_search) contendo os termos 'script', 'script_fields' ou 'mvel' no corpo da requisição, especialmente vindas de IPs não pertencentes à infraestrutura conhecida. Não há uma assinatura única confiável, porque o payload MVEL é livre — qualquer WAF ou IDS precisa inspecionar o corpo JSON da requisição, não apenas a URL, e scanners automatizados que testam esse vetor tendem a usar variações conhecidas de PoCs publicadas (exploit-db 33370), o que dá alguma base para regras de assinatura, mas um atacante determinado pode ofuscar a expressão MVEL para evitar padrões simples.