Uma vulnerabilidade WordPress identificada como Click2Shell foi corrigida na versão 7.1.1 do sistema. O problema, relatado de forma responsável por Paulos Yibelo, da pwn.ai, combinava Cross-Site Request Forgery (CSRF) com injeção em seletores para transformar um único clique em um shell remoto. A correção foi incluída no lançamento de 17 September.
A falha WordPress chama atenção porque reunia fragilidades aparentemente limitadas em uma cadeia capaz de produzir um resultado grave. Embora o ataque dependesse de condições específicas, a execução bem-sucedida poderia permitir que um invasor instalasse código malicioso e obtivesse execução remota no servidor.
Como a vulnerabilidade WordPress explorava um mesmo valor
O painel administrativo do WordPress permite que administradores visualizem ou instalem temas diretamente do catálogo do WordPress.org. Nesse processo, o slug do tema é transportado pela URL e interpretado duas vezes por componentes diferentes, o que abriu espaço para a vulnerabilidade WordPress.
No servidor, a API de temas do WordPress.org sanitiza o valor recebido e remove caracteres adicionais. Assim, uma sequência como twentytwenty"]> é reduzida a twentytwenty na resposta da API. No navegador, porém, o JavaScript do wp-admin utilizava o valor original diretamente em uma string de seletor do jQuery, sem a mesma sanitização.
Essa diferença de tratamento permitia que um slug especialmente preparado confundisse a página e simulasse o clique do administrador no botão de instalação de um tema diferente. Dessa forma, a vulnerabilidade WordPress conseguia iniciar a primeira etapa do ataque sem depender de uma ação explícita de instalação.
Da instalação forçada à execução remota
Um tema instalado silenciosamente e mantido inativo, por si só, geralmente representa um risco limitado. No entanto, há uma situação em que um tema inativo é ativado: durante a visualização no Personalizador do WordPress. Foi justamente essa etapa que permitiu ampliar o impacto da vulnerabilidade WordPress.
A cadeia analisada pela pwn.ai utilizou o tema disponível no catálogo Mobile Repair Zone 2.5.4. Primeiro, o endereço manipulado forçava a instalação do tema. Depois, um segundo link carregava o Personalizador com o Mobile Repair Zone ativo, fazendo com que o arquivo functions.php executasse suas funções e registrasse seus hooks.
Entre esses hooks havia um manipulador AJAX que aceitava a URL de download de um plugin sem verificar nonce nem capacidades do usuário. Ao fornecer o endereço de um arquivo ZIP controlado pelo invasor, a ação fazia o WordPress baixar o pacote e executá-lo no servidor como se fosse um plugin legítimo. Assim, a falha WordPress deixava de representar apenas a aparição de um tema inativo e passava a oferecer um shell funcional ao atacante.
Quais condições eram necessárias para o ataque
Apesar da possibilidade de execução remota sem uma conta de invasor, a vulnerabilidade WordPress não funcionava simplesmente como um ataque automático contra qualquer visitante. O processo começava com uma URL especialmente criada e exigia que um administrador, enquanto estivesse conectado, carregasse esse endereço.
Isso poderia ocorrer por meio de um ataque de phishing direcionado, no qual o administrador fosse induzido a clicar em um link específico. Outra possibilidade seria a exploração de uma vulnerabilidade XSS já existente no site, capaz de disparar a solicitação automaticamente quando um administrador visualizasse a página. Nesse segundo cenário, o invasor já teria uma presença inicial no ambiente.
Além disso, a execução remota completa dependia da possibilidade de o site instalar temas vulneráveis. Quando a constante DISALLOW_FILE_MODS estava habilitada, a injeção ainda poderia ocorrer, mas não seria possível instalar novos temas ou plugins por esse caminho. Portanto, a vulnerabilidade WordPress tinha seu impacto condicionado à configuração e aos componentes presentes no site.
Correção da falha WordPress
O WordPress 7.1.1 corrigiu a vulnerabilidade WordPress restringindo o seletor a elementos DOM reais de temas e aplicando $.escapeSelector() ao slug antes de inseri-lo na string. Com isso, o dado passou a ser tratado como texto literal, e não como parte estrutural do seletor, impedindo que acionasse botões por conta própria.
A correção também reforça uma orientação mais ampla de segurança: quando um parâmetro de URL é processado tanto no servidor quanto no navegador, ele precisa ser sanitizado nos dois lados. Afinal, diferentes trechos de código podem interpretar a mesma entrada de maneiras distintas, criando uma cadeia de exploração semelhante à observada nessa vulnerabilidade WordPress.
A recomendação é atualizar o WordPress imediatamente para a versão mais recente disponível. De acordo com o comunicado, clientes da Patchstack estão protegidos contra essa vulnerabilidade.
Com informações de patchstack.com.
