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

O primeiro passo é cruzar a versão exata do Moodle instalado com o histórico de CVEs publicados. Versão exata significa build number, não só "3.x". Diferença entre Moodle 3.9.5 e 3.9.18 são 13 patches de segurança — incluindo um RCE em 3.9.10.

Onde achar a versão exata:

$ grep -E '\$release|\$version' /path/to/moodle/version.php
$release = '3.9.18+ (Build: 20231120)';
$version = 2020061518.07;

Depois, cruzar com:

• Moodle.org Security Announcements — fonte primária (filtrar por versão)
• NIST NVD — CVEs publicados com CVSS score
• HackerOne disclosures — alguns CVEs aparecem aqui antes do anúncio oficial

Critério de severidade que usamos:

• Crítico: CVE com CVSS ≥ 9.0 não patcheado
• Alto: CVE entre 7.0 e 9.0 não patcheado, ou versão EOL há mais de 12 meses
• Médio: CVE 4.0-7.0, ou versão fora de LTS
• Baixo: CVE <4.0 ou patch disponível mas não aplicado < 90 dias

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

Plugin é onde vivem os surprise CVEs. Auditor inexperiente esquece de inventariar plugins desativados — que continuam no banco com tabelas órfãs, configurações zumbi, e às vezes endpoints expostos.

Comando para listar TODOS os plugins (ativos + desativados):

$ ls -la /path/to/moodle/mod/ \
                /path/to/moodle/blocks/ \
                /path/to/moodle/local/ \
                /path/to/moodle/theme/ | \
   grep -v "^total\|^d\.\." | \
   awk '{print $NF}'

Para cada plugin de terceiros encontrado:

1. Identificar o autor (Moodle Plugins Directory ou GitHub)
2. Comparar versão instalada com versão mais recente
3. Verificar se autor ainda mantém (último commit, tickets abertos)
4. Cruzar nome do plugin com CVE database

Padrões de risco em plugins:

• 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 compromised?)
• Plugin desativado mas instalado → desinstalar limpo via php admin/cli/uninstall_plugins.php

4. Frente 3: Configuração de servidor

Quatro sub-frentes aqui:

PHP

• Versão (Moodle 5.2 LTS exige PHP 8.3+)
• display_errors — deve ser Off em produção
• expose_php — deve ser Off (esconde versão do header)
• session.cookie_httponly e session.cookie_secure — ambos On
• open_basedir — restrição de paths fora do moodle
• Módulos perigosos desativados (exec, system, shell_exec se não usar)

MySQL / MariaDB

• Versão (8.0+ recomendado para Moodle 5.x)
• Usuário Moodle com permissões mínimas (não SUPERUSER)
• Backup automático configurado E testado em restore real
• require_secure_transport = ON se banco em servidor separado

Cache

• Configurado (Redis ou Memcached como application cache, não file cache)
• Não exposto publicamente (firewall block a portas Redis/Memcached)
• Senha configurada se Redis (default em algumas distros = sem auth)

Permissões de arquivos

$ find /path/to/moodle -type f -perm -o+w  # arquivos world-writable
$ stat /path/to/moodledata/config.php       # deve ser 640 ou 600, não 644
$ stat /path/to/moodledata                  # web user precisa write, mais ninguém

5. Frente 4: Integridade do cron e tarefas

Cron parado é vetor de risco por dois motivos: tarefas críticas não rodam (badges, certificados, mensagens, limpeza de logs) e logs de auditoria acumulam lixo em vez de gerar sinal útil.

Comando para ver estado das tarefas agendadas:

$ php admin/cli/scheduled_task.php --list
Component            Task                              Last run
core/check_for_updates 2025-12-15 14:32 (3 days ago)
core/cleanup_old_log  2024-11-22 02:00 (8 months ago!)
core/badges_cron      Never

O que olhamos:

• cron.php rodando a cada minuto via cron real do servidor
• core/cleanup_old_log rodando regularmente (sem ele, logstore_standard_log cresce sem freio)
• task_adhoc com mais de 10k linhas pendentes → cron travado
• core/badges_cron rodando se a plataforma emite badges
• Logs de auditoria sendo gerados (não só armazenados)

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

Esta é a frente que mais varia entre Moodles. Os endpoints sensíveis variam por versão e por plugins instalados.

Sempre verificar

• /admin — está protegido por IP whitelist ou só por senha? Se só senha, qual a política?
• /webservice/rest/server.php — autenticação obrigatória? Algum token vazado?
• /login/index.php — tem rate limit ou WAF na frente?
• config.php — permissões 640 ou 600, web user só leitura
• /install.php e /admin/cli/install.php — devem ser removidos pós-instalação
• Arquivos .log, .bak, .sql no document root → bloqueados via robots.txt + nginx/Apache
• Debug ativo em produção ($CFG->debug = E_ALL + $CFG->debugdisplay = 1) → desligar

Comando útil

$ curl -I https://seu-moodle.com/admin/
$ curl -I https://seu-moodle.com/webservice/rest/server.php
$ curl https://seu-moodle.com/install.php
$ curl https://seu-moodle.com/config.php

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.