Uma falha do WordPress que chegou ao banco do Moodle

Caso real de produção, contado sem identificar o cliente e sem detalhar nada que sirva de receita. No mesmo servidor, sob a mesma raiz, conviviam duas aplicações: um WordPress (site institucional) e o Moodle (a plataforma de treinamento). Pareciam vizinhos independentes. Não eram. Uma vulnerabilidade conhecida do WordPress, do tipo que aparece em plugin ou tema desatualizado, abriu a porta. E a porta não dava só no WordPress.

Por que "no mesmo servidor" não é o problema: "na mesma raiz" é

Ter WordPress e Moodle na mesma máquina não é, por si só, um erro. O erro foi o arranjo: mesma raiz, mesmo usuário do sistema, acesso cruzado a arquivos. Nesse cenário, o WordPress deixa de ser "só o site". Ele vira o elo mais fraco de um espaço que também contém o Moodle, e, em segurança, o conjunto é tão forte quanto o seu elo mais fraco.

Como uma coisa levou à outra

A lógica do incidente, no nível certo de detalhe: comprometido o WordPress, o invasor passou a enxergar os arquivos que dividiam aquele mesmo espaço, inclusive os do Moodle. E o Moodle, como toda aplicação, guarda em um arquivo de configuração as credenciais de acesso ao seu banco de dados. Estando tudo sob a mesma raiz e o mesmo usuário, ler esse arquivo, e, a partir dele, alcançar o banco do Moodle, passou a ser um passo curto. Não houve nenhuma falha do Moodle: o Moodle foi atingido pelo vizinho.

É a definição de escalada por contaminação cruzada: a fraqueza de uma aplicação vira o dano de outra, só porque estavam no mesmo cercado.

O diagnóstico

O problema de fundo não era um plugin específico: era arquitetural. Duas aplicações com ciclos de vida, responsáveis e riscos diferentes empacotadas no mesmo espaço, sem fronteira entre elas. Enquanto essa fronteira não existisse, qualquer falha futura de qualquer das duas continuaria contaminando a outra. Trocar o plugin culpado resolveria o sintoma daquela semana, não a causa.

As resoluções recomendadas

A correção é de isolamento, e vale como princípio para qualquer operação que empilha aplicações:

• Separar contas de sistema: WordPress e Moodle sob usuários distintos, sem enxergar os arquivos um do outro.
• Bancos e usuários de banco distintos, com permissões mínimas: cada aplicação só acessa o seu.
• Ambientes separados sempre que possível: o ideal é cada aplicação no seu próprio espaço.
• Manter tudo atualizado: especialmente o WordPress e seus plugins, que costumam ser o elo fraco.
• Monitorar, para que o próximo sinal apareça nos dados antes de virar incidente.

O resultado

Com o Moodle isolado: conta, banco e permissões próprios -, uma eventual nova falha do WordPress volta a ser um problema só do WordPress. O incidente deixou de ser "a plataforma de treinamento foi invadida" e passou a ser, no máximo, "o site institucional teve um susto". A diferença toda está na fronteira que não existia.

A lição do caso é incômoda para quem monta tudo no mesmo lugar "para simplificar": compartilhar raiz é compartilhar risco. Segurança de Moodle não termina no Moodle, como lembramos em o Moodle é seguro?, ela depende de toda a operação, e a vizinhança conta. Sobre onde e como hospedar sem esse tipo de armadilha, veja onde hospedar o seu LMS.

Perguntas frequentes

Leia também

Caso técnicoArquivos infectados chegando ao Moodle: como o monitoramento detectouCaso técnicoBackups antigos do Moodle guardando dados de quem já saiuCaso técnicoCVE-2024-43429 e CVE-2024-28593: por que um Moodle desatualizado é um risco