A stack que auditámos
O site WordPress de uma pequena empresa chegou para uma auditoria de segurança, e os achados eram do tipo banal que silenciosamente deixa um site a um exame automatizado de distância do comprometimento. O construtor de páginas, Elementor, estava fixado na versão 3.11.1, carregando quatro CVE críticas, incluindo SQL injection e stored cross-site scripting. O Contact Form 7 corria na 5.8, exposto à CVE-2023-6449, um upload arbitrário de ficheiros. Nada de exótico, apenas plugins desatualizados, que é a forma dominante como os sites WordPress são comprometidos.
O incómodo é o quão normal isto é. O site funcionava. Tinha bom aspeto. O proprietário não tinha motivos para desconfiar de nada, porque os plugins desatualizados não dão sintomas até serem explorados. A auditoria existia para encontrar a falha antes de outra pessoa o fazer.
Os plugins desatualizados são a superfície de ataque
Um plugin é seguro enquanto recebe correções. No momento em que uma vulnerabilidade é publicada como CVE e não atualizou, o exploit é do conhecimento público e a sua versão instalada é um alvo identificado para scanners automatizados. Os ataques ao WordPress são esmagadoramente cegos e automatizados, os bots varrem a rede à procura de versões reconhecidamente vulneráveis de plugins populares, pelo que correr um Elementor ou Contact Form 7 antigo não é um risco abstrato. É um risco anunciado.
Neste site:
- O Elementor 3.11.1 carregava quatro CVE críticas (entre elas SQL injection e stored cross-site scripting), enquanto a linha corrigida já tinha avançado para a 3.17.3. Cada uma dessas quatro estava ativa.
- O Contact Form 7 5.8 estava exposto à CVE-2023-6449, uma falha de upload de ficheiros por arrastar e largar que permitia a um utilizador autenticado com direitos de editor carregar ficheiros arbitrários, um caminho direto para a execução remota de código.
Nenhum dos plugins era invulgar. Ambos estão numa enorme fatia de sites WordPress. É precisamente por isso que as suas vulnerabilidades conhecidas valem o tempo de um scanner.
O que a auditoria verifica
Uma auditoria de segurança é metódica em vez de engenhosa. O seu núcleo:
- Inventariar cada plugin e tema instalado e confrontar cada versão com as suas CVE conhecidas e a versão mínima segura. Foi isto que revelou aqui a exposição do Elementor e do Contact Form 7.
- Testar o código personalizado e do tema quanto às bases de segurança do WordPress, verificações de nonce e de permissões nas ações, entrada saneada antes de chegar à base de dados, saída com escaping antes de chegar à página e endpoints que exigem autorização.
- Verificar a exposição ao nível do servidor, um
xmlrpc.phpaberto, erros PHP exibidos em produção a revelar caminhos, cabeçalhos de segurança em falta. - Rever a postura de atualização e de cópias de segurança, porque um site sem manutenção volta a este estado em poucos meses.
O confronto de versões é a parte pouco vistosa que mais apanha, porque a vulnerabilidade WordPress mais comum não é um zero-day engenhoso. É um plugin popular três versões atrás da sua correção.
Onde as construções assistidas por IA pioram a situação
Esta auditoria incidia sobre plugins de terceiros desatualizados, o padrão de negligência. As construções assistidas por IA acrescentam uma segunda camada por cima. Instalam plugins depressa, muitas vezes sem definir qualquer rotina de atualização, pelo que as versões ficam para trás das suas correções ainda mais depressa. E o código personalizado gerado por IA é frequentemente criado sem as verificações de nonce, de permissões e de saneamento que o WordPress espera, pelo que herda ao mesmo tempo um problema de plugins desatualizados e um problema de código gerado. É por isso que este tipo de auditoria faz parte do nosso trabalho mais amplo de recuperação de sites feitos por IA, e por isso uma auditoria de segurança WordPress autónoma começa pelo aborrecido confronto de versões antes de qualquer outra coisa.
Como é a correção
A ordem da correção segue o risco, não a conveniência:
- Corrigir ou remover de imediato os plugins com CVE ativas, começando pelos caminhos de upload de ficheiros e de injection, porque são os de gravidade mais alta.
- Remover os plugins abandonados ou já desnecessários, encolhendo a superfície de forma permanente.
- Fechar a exposição ao nível do servidor (
xmlrpc.php, exibição de erros em produção, cabeçalhos em falta). - Implementar uma rotina real de atualização e de cópias de segurança, para que o site não volte a quatro CVE ativas no prazo de um ano.
Glossário
- CVE - um identificador de Common Vulnerabilities and Exposures, uma entrada pública de catálogo para uma vulnerabilidade conhecida específica.
- SQL injection - um ataque que introduz comandos de base de dados através de entrada sem saneamento.
- Stored cross-site scripting - script malicioso guardado no site e servido a outros utilizadores.
- Verificação de nonce / permissões - mecanismos do WordPress que confirmam que um pedido é intencional e que o utilizador tem permissão para o fazer.
A conclusão
Um site WordPress não precisa de ser interessante para ser atacado. Basta correr uma versão reconhecidamente vulnerável de um plugin popular, o que descreve uma grande fatia dos sites que não foram auditados. A boa notícia é que o risco dominante é também o mais aborrecido de corrigir, confronte cada versão de plugin com as suas CVE, corrija ou remova os culpados e implemente uma rotina de manutenção para que a falha não volte a abrir-se. O site desta auditoria estava a um exame de distância de problemas e não o sabia. A maioria dos sites nessa situação também não.
