Módulos órfãos no PrestaShop: o código que ninguém vê e que continua a responder

Uma loja com anos de funcionamento acumula módulos como uma arrecadação acumula caixas. Experimentou-se um módulo de avaliações, mudou-se de gateway de pagamento, instalou-se algo para uma campanha de Natal. Foram desinstalados a partir do back office, mas as pastas continuam lá, em modules/, com todo o seu código.

A essas pastas chamamos módulos órfãos. Não aparecem no gestor de módulos, ninguém as atualiza e, em muitas lojas, o seu PHP continua a responder a quem o pedir por URL.

Porque ficam órfãos

• Desinstalar não é apagar. No PrestaShop, desinstalar executa o uninstall() do módulo (que remove as suas tabelas e a sua configuração), mas a pasta pode ficar no disco. Apagá-la é outra ação, e muitas vezes não se faz.
• Migrações e cópias. Ao migrar ou restaurar, copiam-se pastas de módulos que na loja nova nunca chegam a ser instalados.
• Carregamentos por FTP. Alguém carregou um módulo por FTP para o experimentar e nunca o chegou a instalar.
• Restos de temas. Alguns temas comerciais trazem os seus próprios módulos; ao mudar de tema, os do anterior ficam.

Porque são um risco

Código vulnerável que nunca é atualizado

Um módulo instalado, mesmo que antigo, pelo menos aparece na lista e alguém pode ver que tem atualização. Um órfão não aparece em lado nenhum. Se a sua versão tinha uma vulnerabilidade conhecida, vai continuar a tê-la para sempre.

O seu PHP continua a ser executado

Aqui está o importante. O módulo não estar instalado não impede que os seus ficheiros respondam. Muitos módulos antigos trazem ficheiros PHP pensados para serem chamados diretamente por URL: um ajax.php, um validation.php, um script de importação. Esses ficheiros arrancam o PrestaShop por conta própria e fazem o seu trabalho, estejam registados ou não.

No PrestaShop 8 e anteriores, a pasta modules/ não traz de origem nenhuma proteção que impeça executar esses .php. O PrestaShop 9 já inclui um .htaccess em modules/ que recusa os .php pedidos diretamente, o que fecha grande parte do problema em Apache e LiteSpeed. Mas os controladores front que passam pelo dispatcher do PrestaShop continuam acessíveis se o módulo estiver instalado, e em Nginx o .htaccess é ignorado.

Um esconderijo cómodo

Para um atacante, uma pasta que ninguém vê é o sítio ideal para deixar uma porta traseira. Um ficheiro novo dentro de um módulo órfão tem muito menos probabilidades de ser visto do que um na raiz.

Como fazer o inventário

A ideia é cruzar duas listas: as pastas de modules/ no disco e os módulos registados na base de dados.

1. Tire a lista de módulos registados. Na base de dados: SELECT name, active, version FROM ps_module ORDER BY name;
2. Tire a lista de pastas de modules/, a partir do gestor de ficheiros do alojamento ou por SSH.
3. As pastas que não estão na primeira lista são órfãs. Anote de cada uma: se tem ficheiros .php fora de controllers/, a sua versão (em config.xml ou no ficheiro principal) e a data dos seus ficheiros.
4. Distinga os instalados mas desativados. Esses estão na lista, mas também merecem revisão: se não são usados, convém desinstalá-los e apagá-los.
5. Marque os suspeitos. Um módulo de autor desconhecido, sem documentação, com uma compatibilidade declarada impossível ou com uma descrição que não descreve nada provavelmente não foi instalado por ninguém da sua equipa.

Como retirá-los sem estragar o tema

Apagar uma pasta parece trivial, mas há casos em que algo depende dela:

• Templates do tema que incluem ficheiros de um módulo. Alguns temas chamam diretamente templates ou CSS de módulos concretos. Procure o nome do módulo na pasta do tema antes de apagar.
• Overrides órfãos. Um módulo desinstalado pode ter deixado ficheiros em override/ que continuam a ser executados. Reveja essa pasta e, se retirar um override, limpe também a cache de classes.
• Módulos que outro módulo usa como biblioteca. Acontece com alguns pacotes que partilham uma pasta comum entre vários módulos do mesmo autor.
• Crons externos que chamam um ficheiro do módulo. Se o painel do alojamento tiver uma tarefa agendada que aponta para essa pasta, vai falhar; é melhor sabê-lo antes.

O procedimento seguro:

1. Faça uma cópia de segurança dos ficheiros e da base de dados.
2. Em vez de apagar, mova a pasta para fora do diretório web (ou mude-lhe o nome se não tiver outra opção) e deixe passar uns dias.
3. Navegue pela loja, faça uma encomenda de teste, reveja o back office e os registos de erros.
4. Se nada se queixou, apague-a definitivamente.
5. Repita o inventário de poucos em poucos meses, ou sempre que se desinstale algo.

O que convém fazer além disso

• Bloqueie a execução direta de PHP em modules/ se a sua loja for anterior ao PrestaShop 9, com exceções apenas para os ficheiros que realmente precisem.
• Analise os órfãos antes de os apagar: se algum contiver uma porta traseira, apagar sem mais deixa-o sem saber como entraram nem o que mais fizeram.
• Aproveite uma migração para começar com modules/ limpo: numa loja nova só entra o que é realmente instalado. É uma das vantagens menos faladas de deixar para trás uma 1.6 ou uma 1.7 com anos de restos.

Como resolvê-lo no PrestaShop

O RKR Security Alert procura dentro de modules/ as pastas sem registo na base de dados e gradua a sua gravidade pelo que contêm: informativo se só tiverem recursos, crítico se houver PHP alcançável com achados. Também verifica que extensões o .htaccess de modules/ recusa de facto e cruza-as com os pontos de entrada que vai encontrando, para responder a quantos ficheiros de módulo qualquer pessoa pode pedir de fora, e conta os módulos instalados que não estão cobertos pela linha de base de integridade. Se preferir que sejamos nós a fazê-lo, com um pacote de horas de suporte da Rekire fazemos o inventário dos módulos da sua loja, retiramos os que estão a mais verificando que não estragam o tema e deixamos-lhe a lista do que convém atualizar.