CVE-2018-20062

RCE não autenticada no NoneCms V1.3, um CMS construído sobre o framework ThinkPHP, explorável com uma única requisição HTTP sem login. A falha está no roteamento de compatibilidade do ThinkPHP (thinkphp/library/think/App.php), que permite invocar diretamente métodos internos do framework e passar um callback PHP arbitrário via parâmetro 'filter' — na prática, execução de código com controle total sobre a função chamada. Está no catálogo KEV da CISA, tem módulo Metasploit e template Nuclei públicos, o que explica o EPSS próximo de 1.0: é varrida e explorada em massa até hoje.

A causa está no mecanismo de roteamento 'compatível' do ThinkPHP, que aceita a sintaxe s=módulo/controlador/ação diretamente na querystring. Isso permite ao atacante apontar o roteador para classes internas do próprio framework em vez de controladores da aplicação — no PoC documentado, para \think\Request::input(). Esse método foi projetado para ler e opcionalmente filtrar dados de entrada, recebendo o nome de uma função de filtro como parâmetro (filter) e o valor a filtrar como outro (data).

O problema (CWE-20, validação de entrada imprópria) é que o parâmetro filter não é restringido a uma lista de funções permitidas: o framework repassa a string recebida como um callable para call_user_func (ou equivalente), e o atacante controla tanto o nome da função quanto o argumento. O PoC de referência usa filter=phpinfo&data=1 só para provar execução; qualquer função nativa do PHP que aceite um argumento e produza efeito observável ou execute comando serve ao mesmo padrão — o vetor de exploração de fato observado na comunidade vai além de phpinfo para funções que resultam em execução de comando.

A raiz é dupla: (1) o roteador expõe classes/métodos internos do framework à querystring sem allowlist de controladores acessíveis externamente, e (2) uma função utilitária do próprio framework aceita nome de função arbitrário como callback sem sanitização. Isso torna a exploração independente de qualquer lógica de negócio do NoneCms — é uma falha de framework que se manifesta em qualquer aplicação que herde esse comportamento de roteamento sem desativá-lo.

O vetor é HTTP simples (GET ou POST), sem autenticação e sem interação do usuário — um único request com a querystring craftada já dispara a execução. O único pré-requisito real é que a aplicação esteja usando o modo de roteamento padrão/compatibilidade do ThinkPHP (URL no formato s=módulo/controlador/ação habilitado) sem customização que bloqueie acesso a namespaces internos do framework; instalações que desabilitaram esse modo de rota ou customizaram o roteamento não são exploráveis por este vetor específico.

A complexidade é baixa: o PoC publicado é direto (s=index/\think\Request/input&filter=&data=), e ferramentas de varredura automatizada (incluindo módulo Metasploit e template Nuclei) já encapsulam a técnica, o que faz o ataque ser trivial de reproduzir e escalar para varredura massiva na internet.

A inclusão no catálogo KEV da CISA (adicionada em 2021-11-03, prazo de correção 2022-05-03) confirma exploração ativa constatada em campo, anos após a publicação original — típico de vulnerabilidades de framework amplamente reimplantadas em CMS derivados e nunca corrigidas nessas instalações. O resultado final da exploração é execução arbitrária de código PHP no contexto do processo web, o que normalmente equivale a comprometimento total do host de aplicação.

Não foi localizado um advisory oficial do NoneCms com número de versão corrigida nas fontes analisadas; o issue do GitHub (nangge/noneCms#21) discute o problema sem confirmar um patch ou versão de destino. Como a causa raiz está no comportamento de roteamento do framework ThinkPHP subjacente (não numa lógica exclusiva do NoneCms), a correção efetiva depende de qual versão do ThinkPHP a instalação usa — e essa informação não está confirmada nas fontes disponíveis para esta página; não adivinhe a versão corrigida sem checar o changelog do ThinkPHP correspondente à sua instalação.

Paliativo real quando não é possível migrar/corrigir imediatamente: desabilitar o modo de rota de compatibilidade que aceita s=módulo/controlador/ação, restringindo o roteamento a controladores explicitamente definidos pela aplicação; isso quebra qualquer link ou integração que dependa desse formato de URL, então tem custo funcional. Um controle compensatório de rede é bloquear no WAF/proxy requisições cuja querystring contenha padrões como \think\Request, \think\App ou filter= associado a nomes de função PHP — reduz o vetor conhecido mas não fecha a causa raiz.

O que não funciona: atualizar apenas a camada de aplicação do NoneCms sem verificar e corrigir a versão do framework ThinkPHP embutido não resolve, pois o arquivo vulnerável (App.php) pertence ao framework, não ao CMS em si.

Procure em logs de acesso web por querystrings contendo s=index/\think\Request/input (ou variações de path com \think\) combinadas com parâmetros filter= apontando para nomes de funções PHP (phpinfo, system, exec, assert, call_user_func, etc.) e data= com o argumento correspondente. Presença desse padrão é forte indicador de tentativa de exploração, já que o PoC público e as ferramentas automatizadas (Metasploit, Nuclei) seguem essa assinatura quase literalmente.

Não há garantia de que todas as variantes de exploração usem exatamente esse formato — atacantes podem trocar o nome da classe/método invocado ou a função de filtro, então uma assinatura estrita baseada só em 'phpinfo' gera falso negativo; regras devem cobrir a estrutura geral do padrão de roteamento e o uso do parâmetro filter, não apenas o exemplo do PoC original.