Auditoria de segurança Moodle: o checklist técnico que ninguém publica

1. Por que auditar Moodle não é checklist genérico

O checklist OWASP de aplicação web cobre 80% de qualquer sistema. Mas Moodle tem particularidades que nenhum checklist genérico cobre: o ciclo de releases (LTS vs. intermediário), o ecossistema de plugins de terceiros (com varying maturity), o cron que precisa rodar a cada minuto, e o fato de que dados de aluno são dados de menor de idade em muitos casos — o que muda toda a equação LGPD/GDPR.

Auditor que aplica só ZAP+Burp em Moodle perde 70% dos riscos reais. Os riscos críticos vivem em plugins desatualizados específicos do Moodle, configurações de cron silenciosas, permissões de arquivos do moodledata, e endpoints REST específicos do Moodle (webservice/rest/server.php) que ferramentas genéricas nem sabem mapear.

Regra que aplicamos: auditoria de Moodle é auditoria de plataforma Moodle, não auditoria de "app web qualquer". O conhecimento específico do produto é o que separa relatório útil de relatório-cobertor.

2. Frente 1: Versão do core + CVEs conhecidos

A diferença que a maioria ignora: build number, não só "3.x". Entre Moodle 3.9.5 e 3.9.18 há 13 patches de segurança — incluindo um RCE conhecido numa dessas builds. Auditar "a versão" sem o build exato é olhar para o problema errado.

O trabalho real não é "descobrir a versão" — é cruzar a build exata contra o histórico completo de CVEs de três fontes (anúncios de segurança do Moodle, base NVD/CVSS e disclosures que aparecem antes do anúncio oficial), e separar o que é exploitável no ambiente real do cliente do que é ruído. É aí que a experiência separa um laudo útil de uma lista genérica de "atualize tudo".

Cada achado entra no laudo com uma severidade — o mesmo critério que vira cláusula de prazo de correção:

3. Frente 2: Inventário de plugins de terceiros

Plugin é onde vivem os surprise CVEs. E o erro do auditor inexperiente é olhar só os plugins ativos: os desativados continuam no banco — com tabelas órfãs, configurações zumbi e, às vezes, endpoints ainda expostos. Um plugin que "ninguém usa" há anos pode ser a porta aberta.

O inventário sério não é uma listagem — é um cruzamento. Para cada plugin de terceiros (ativo ou não): quem é o autor, se ainda mantém, há quanto tempo não recebe patch, se a versão bloqueia o próximo upgrade, e se o nome aparece em alguma base de CVE. É um trabalho de correlação que ferramenta genérica não faz porque não conhece o ecossistema de plugins do Moodle.

Os padrões de risco que acendem o alerta:

• Sem update há mais de 24 meses → provavelmente abandonado
• Versão atual incompatível com Moodle 5.x → bloqueia upgrade futuro
• Autor desativou o repositório → red flag (plugin comprometido?)
• Plugin desativado mas ainda instalado no banco → superfície de ataque que ninguém monitora

4. Frente 3: Configuração de servidor

O servidor é onde o Moodle "vaza" sem que ninguém perceba. Quatro sub-frentes, cada uma com um modo de falha silencioso:

Nenhuma dessas falhas aparece num scan automático genérico. Elas aparecem quando alguém que conhece a anatomia de uma instalação Moodle sabe exatamente onde olhar — e sabe distinguir o que é risco real do que é "default aceitável".

5. Frente 4: Integridade do cron e tarefas

Cron parado é o achado mais frequente — e o mais subestimado. Encontramos ambientes com o cron parado há 3, 5, até 7 anos sem ninguém notar. O motivo de ser perigoso é duplo: tarefas críticas silenciosamente não rodam (badges não emitidos, certificados não gerados, mensagens não entregues, logs nunca limpos) e as tabelas de log e de tarefas incham até virar gargalo — milhões de linhas órfãs que transformam o banco num peso morto.

O perigoso é que nada quebra na tela. A plataforma parece funcionar. Só uma auditoria que checa quando cada tarefa agendada rodou pela última vez — e cruza isso com o que deveria estar rodando — revela que metade do Moodle está, na prática, desligada. Ler essa assinatura é conhecimento de produto, não de scanner.

6. Frente 5: Exposição de endpoints sensíveis

Esta é a frente que mais varia entre instalações — os endpoints sensíveis dependem da versão e dos plugins. É também onde mora o achado que dá manchete: o painel admin sem proteção além da senha, o endpoint de webservice com token vazado, arquivos de instalação que deveriam ter sido removidos e ficaram, debug ligado em produção cuspindo caminhos internos, dumps de banco esquecidos no document root.

O ponto não é "rodar um curl" — qualquer um faz isso. É saber quais endpoints existem em cada versão do Moodle, quais um plugin específico expõe, e o que naquele ambiente é exposição real versus comportamento esperado. Esse mapa só existe na cabeça de quem trabalha a plataforma há anos. É exatamente a diferença entre um pentest genérico e uma auditoria de Moodle.

O esperado: 403 Forbidden para install/config e auth challenge para admin/REST.

7. Frente 6: Compliance LGPD / GDPR / CNPD

Compliance técnica (o que olhamos):

• Política de retenção de dados documentada e implementada (core/cleanup_old_log ativo)
• Direito de exportação — Moodle tem ferramenta nativa (tool_dataprivacy) — está ativada?
• Direito de eliminação — mesma ferramenta cobre, com sign-off do DPO
• Criptografia em trânsito — TLS 1.2+ obrigatório, HSTS configurado
• Criptografia em repouso — banco encriptado (depende do hosting)
• Log de acesso — quem acessou o quê e quando (logstore ativo)
• Cookies — banner de consentimento implementado (Moodle 4.x+ tem nativo)
• Registro de processamento — DPO mantém? Plataforma é declarada na ROPA da organização?

O que NÃO fazemos: emitir certificado de conformidade legal. Isso é função do DPO + advogado. Nossa entrega é o laudo técnico que comprova as medidas implementadas — esse laudo o DPO usa como evidência.

8. Como o relatório vira plano de remediação

Auditoria que termina em PDF de 80 páginas que ninguém lê é dinheiro jogado fora. Para virar ação, o relatório precisa duas camadas:

Camada executiva (4-6 páginas)

• Sumário executivo (1 página)
• Top 5 riscos com severidade visual (vermelho/laranja/amarelo)
• Custo estimado de remediação por risco
• Cronograma sugerido (30/60/90 dias)
• Implicações legais se incidente ocorrer (LGPD: até 2% do faturamento)

Esse documento vai para C-level, jurídico, financeiro. Eles decidem prioridades baseado em custo × risco.

Camada técnica (40-80 páginas)

• Cada achado com: severidade CVSS, descrição técnica, evidência (screenshot ou log)
• Passos de remediação com comandos exatos
• Links de referência (CVE, Moodle docs, OWASP)
• Tempo estimado de cada remediação
• Dependências entre achados (alguns precisam ser feitos antes de outros)

Esse documento vai para TI / DPO / equipe operacional. Eles executam.

Mais importante: apresentação ao vivo de 90 min com ambos os públicos. Sem isso, o relatório vira shelfware. Com isso, vira plano operacional com responsáveis e prazos.

Quer fazer essa auditoria no seu Moodle? Faça antes o diagnóstico técnico de segurança (10 perguntas, score 0-100) — ele te diz se você precisa de auditoria leve, completa ou prioritária.