Web shells no PrestaShop: o que são, onde se escondem e como encontrá-las

Quando alguém entra numa loja, a primeira coisa que faz quase nunca é roubar. A primeira coisa é garantir que pode voltar. Para isso deixa uma web shell: um ficheiro PHP que, chamado por URL, lhe permite listar pastas, editar ficheiros, lançar consultas à base de dados ou executar comandos no servidor. Com isso, mesmo que corrija a vulnerabilidade por onde entrou e mude todas as palavras-passe, ele continua lá dentro.

Este artigo trata de como são, onde se metem no PrestaShop e como procurá-las sem se perder entre falsos positivos.

O que é exatamente uma web shell

É um pequeno programa escrito na mesma linguagem da loja, que corre com as permissões do utilizador web. Não precisa de explorar mais nada: se o servidor executa PHP nessa pasta, a shell funciona. Há-as de muitos tamanhos:

• Carregadores de uma linha. Trinta ou quarenta bytes que apenas incluem outro ficheiro. O código malicioso está nesse outro ficheiro, que muitas vezes tem extensão de imagem.
• Gestores de ficheiros completos. Uma interface para navegar pelo servidor, editar, carregar, mudar o nome e apagar, protegida por uma palavra-passe escrita no próprio ficheiro.
• Executores de comandos. Recebem um parâmetro e passam-no ao sistema operativo.
• Módulos inteiros. Uma pasta com estrutura de módulo do PrestaShop, ficheiro principal impecável e a carga escondida num controlador.

Onde se escondem no PrestaShop

O atacante procura sítios onde um ficheiro novo não chame a atenção. No PrestaShop há vários clássicos:

Ficheiros a mais em módulos nativos

Um ajax.php ou um config.php dentro da pasta de um módulo oficial que, no pacote original, não tem esse ficheiro. Ninguém olha para dentro dos módulos que vêm com a loja, e o nome parece estar lá desde sempre. A única forma de o ver é comparar a pasta com o pacote publicado pelo seu autor.

Módulos órfãos

Pastas de módulos desinstalados que continuam no disco. Não aparecem no gestor de módulos, ninguém as atualiza e o seu PHP continua acessível por URL. São um esconderijo cómodo e, ao mesmo tempo, uma porta de entrada.

O núcleo e vendor/

Uma linha colada no fim de um ficheiro do núcleo (as classes de produto, o dispatcher, o autoloader) ou de uma biblioteca de vendor/. Muitos scanners excluem vendor/ porque gera ruído, e é precisamente por isso que é um bom sítio. Em incidentes reais foram encontradas mais de uma dezena de portas em ficheiros legítimos de uma mesma loja, todas acrescentadas no fim e sem nenhuma palavra suspeita à vista.

Imagens com PHP lá dentro

Um JPEG ou um PNG perfeitamente válido, que se vê em qualquer visualizador, com código PHP acrescentado no fim. Sozinho não é executado; quem o executa é um carregador que o inclui. Por isso, se encontrar um, procure também o outro.

Pastas de dados

upload/, download/, img/ ou translations/ nunca deveriam ter um .php executável. Se aparecer um, não há explicação inocente.

Como se camuflam

As shells que duram meses não são as que gritam eval(base64_decode(...)). São as que parecem código normal:

• Trazem o cabeçalho de licença do PrestaShop copiado de outro ficheiro, com o seu bloco de comentários e a verificação de versão no início.
• Têm nomes inofensivos: uninstall.php, index.php, cron.php, ou um título que fala de um leitor de códigos QR.
• Montam os nomes das funções perigosas em tempo de execução, apanhando letras soltas de uma cadeia longa. No texto não aparece nenhuma função proibida.
• Respondem 404 se não receberem a chave certa, tal como um URL que não existe. Varrer a loja a pedir caminhos não as encontra.
• Mantêm a data de modificação do ficheiro original, para não aparecerem ao ordenar por data.

Como procurá-las com critério

A ordem importa. Vá do mais conclusivo e barato para o mais caro:

1. É idêntico ao que o autor publicou? Compare o núcleo com o ZIP oficial da sua versão exata (o da release, não o repositório, que traz pastas de desenvolvimento e produz centenas de diferenças falsas) e cada módulo com o seu pacote. Um ficheiro idêntico byte a byte não está infetado.
2. Estava no pacote? O que não estava foi alguém que o pôs depois. Esta pergunta encontra ficheiros que nenhum padrão detetaria, porque podem estar impecavelmente escritos.
3. Mudou desde a última vez? Se tem uma linha de base de integridade de quando a loja estava limpa, qualquer alteração sem uma atualização por trás é uma resposta.
4. O que sabe fazer? Para o que não tem referência: listar diretórios e escrever ficheiros com um caminho que chega por parâmetro, executar comandos, ler ficheiros do sistema, palavras-passe comparadas com um hash guardado no próprio código.
5. De onde se alcança? Um controlador controllers/front/ de um módulo é pedido a partir da Internet sem sessão; um de controllers/admin/ exige sessão de funcionário. Isso decide se é preciso agir esta noite ou amanhã.

E uma regra para o ruído: se marcar algo como seguro, faça-o pelo hash do conteúdo, não pelo caminho. Uma exceção por caminho continuará a tapar esse ficheiro no dia em que alguém o substituir.

Porque não basta apagá-la

Apagar a shell é o último passo, não o primeiro. Antes de lhe tocar:

• Guarde uma cópia da loja tal como está, para saber o que fez e desde quando.
• Veja se deixou outras portas. Chaves em authorized_keys das contas do servidor, funcionários novos no back office, contas de webservice com permissões amplas e tarefas agendadas que descarregam e executam algo de poucos em poucos minutos. Apagar um ficheiro não fecha uma chave SSH nem um cron.
• Procure a via de entrada. Um módulo vulnerável, uma palavra-passe de FTP roubada, uma versão do PrestaShop sem patches. Se não a fechar, a shell volta em dias.
• Mude as credenciais depois de limpar, não antes: base de dados, FTP, painel, funcionários e a chave de cookies se suspeitar que leram a configuração.

E, uma vez limpa, o de sempre: PrestaShop, PHP e módulos atualizados. A esmagadora maioria das entradas aproveita falhas já corrigidas em versões que a loja não tinha instalado.

Como resolvê-lo no PrestaShop

O RKR Security Alert analisa os ficheiros da loja à procura de skimmers, portas traseiras e web shells, incluindo as que não têm assinaturas perigosas: deteta as shells pelo que sabem fazer, os carregadores que incluem uma imagem, o PHP escondido dentro de imagens válidas e os ficheiros com nomes de função montados por índices. Compara o núcleo com o ZIP oficial, indica em cada achado se é alcançável por URL e sem sessão, e mantém uma linha de base de integridade que só é construída quando dá por revista a primeira auditoria, para não dar por boa uma infeção anterior. Avisa por Telegram, guarda os avisos na loja e não envia nenhum ficheiro para fora do servidor. O RKR Sentinel complementa a vigilância avisando de erros de PHP, respostas 500 e pagamentos que não acabam em encomenda, que muitas vezes são o primeiro sintoma visível de que algo foi mexido.