Auditoria de segurança de uma loja PrestaShop: o que rever e por que ordem

Há dois momentos para auditar uma loja: quando suspeita que algo está mal e quando tudo parece estar bem. O primeiro é urgente; o segundo é o que evita o primeiro. Nos dois casos a lista é a mesma, e a ordem importa: primeiro o que permite entrar e ficar, depois o que permite cobrar e, no fim, o que permite recuperar.

Isto não é uma lista de boas práticas de configuração, mas de verificações concretas: o que abrir, o que procurar e o que significa o que encontrar.

Antes de começar: não destrua provas

Se a auditoria for por suspeita, faça primeiro uma cópia completa dos ficheiros e da base de dados tal como estão, e trabalhe sobre ela sempre que puder. Se houver uma infeção, vai precisar de saber desde quando e em que mexeu, e isso perde-se ao limpar.

Outra regra: não dê nada por bom enquanto revê. Se a sua ferramenta de vigilância cria uma linha de base de «estado normal», não a crie até ter terminado. Uma linha de base feita sobre uma loja comprometida dá a infeção por boa para sempre.

1. Funcionários

• Liste todos os funcionários e os seus perfis. Reconhece todos os superadministradores?
• Procure contas com identificadores consecutivos no fim da lista, emails alheios ou nomes vazios: é o rasto típico de uma injeção SQL.
• Reveja as contas de pessoas que já não trabalham consigo, de agências antigas e de testes. Uma conta inativa esquecida é uma porta.
• Confirme que todos os que devem têm a autenticação de dois fatores ativada.

2. Contas de webservice

É a porta de que ninguém se lembra. Reveja em Parâmetros Avançados → Webservice:

• Quantas chaves há, para que serve cada uma e se alguma não tem descrição.
• Que permissões têm. Escrita sobre a configuração ou qualquer permissão sobre funcionários é muito poder.
• Se o webservice estiver ativo sem HTTPS forçado, a chave viaja em claro.

Não desative uma chave «por via das dúvidas» sem saber o que é: costuma ser a integração com o ERP ou com um marketplace.

3. Módulos

• Liste os módulos instalados com a sua versão e compare-a com a última publicada pelo autor.
• Procure os que têm avisos de segurança publicados e os abandonados.
• Procure pastas em modules/ sem módulo registado: os órfãos.
• Desconfie dos módulos sem autor reconhecível, com compatibilidades impossíveis ou com descrições que não explicam nada.
• Reveja override/: cada ficheiro lá dentro modifica o núcleo.

4. Ficheiros alterados

A verificação mais valiosa não depende de reconhecer nenhum padrão:

• Compare o núcleo com o ZIP oficial da sua versão exata, incluindo vendor/. Um ficheiro do núcleo nunca deveria mudar, a não ser por uma atualização.
• Compare cada módulo com o seu pacote original. O que não estava no pacote foi posto por alguém.
• Procure PHP onde não deve haver: upload/, download/, img/, imagens com código lá dentro.
• Procure ficheiros JavaScript com linhas desproporcionadas coladas no início ou no fim.
• Desconfie das datas, que podem ser falsificadas. O que conta é o conteúdo.

5. Templates e configuração de pagamento

É aqui que o atacante cobra, por isso merece um ponto próprio:

• Reveja os templates do checkout de todos os temas instalados, não apenas o ativo, à procura de etiquetas <script> que não reconheça.
• Confirme os dados de cada método de pagamento: o IBAN da transferência, as chaves dos gateways, as contas PayPal.
• Reveja os módulos que permitem inserir HTML ou código no cabeçalho ou no rodapé.
• Compare as encomendas pagas das últimas semanas com o que chegou ao banco ou ao gateway.

6. Configuração da loja

• Os URL da loja (domínio e caminhos): uma alteração aqui redireciona o tráfego.
• A configuração do correio de saída: um SMTP alterado permite ler ou desviar os emails.
• O modo de depuração desativado em produção e a pasta install/ apagada.
• A pasta do back office com um nome que não seja o de origem.

7. Tarefas agendadas

Um cron malicioso vive fora da árvore web, por isso nenhum varrimento de ficheiros o vê. Reveja as tarefas do painel do alojamento e, se tiver acesso, o crontab da conta. Uma linha que descarrega algo e o passa a uma shell, que descodifica base64 ou que executa PHP em linha não tem uso legítimo. Reveja também as chaves SSH autorizadas da conta.

8. .htaccess e permissões

• O .htaccess da raiz: procure redirecionamentos condicionados ao navegador ou à proveniência, que só afetam telemóveis ou quem chega de um motor de pesquisa.
• Os .htaccess de upload/, img/, download/ e var/: que existam e que bloqueiem de facto a execução.
• No PrestaShop 8 e anteriores, se modules/ permite executar .php por URL.
• Que não haja pastas com permissão de escrita para todos nem ficheiros de configuração legíveis por qualquer um.

9. Registos

• Registos de acesso do servidor web: pedidos POST a ficheiros de módulos que não conhece, ou muitos pedidos a um mesmo controlador mesmo antes de uma alteração.
• Registos de FTP e do painel do alojamento, que são independentes dos web.
• Registos de erros do PHP e do PrestaShop: um erro novo num ficheiro que não mudou de versão é uma pista.
• Confirme que nenhum registo é acessível por URL a partir de fora.

10. Cópias de segurança

• Existem, são diárias e estão fora do servidor?
• Já foram restauradas alguma vez para confirmar que funcionam?
• Há cópias antigas soltas na raiz do site, descarregáveis por qualquer pessoa?
• Até quando chegam? Se a infeção tiver meses, precisa de uma cópia anterior.

E no fim

Com tudo revisto e limpo, agora sim: crie a linha de base de integridade, mude as credenciais e deixe a vigilância a funcionar. E anote o que tiver surgido sobre as versões: se a loja está num PrestaShop ou num PHP sem suporte, ou com módulos que não se podem atualizar, a próxima auditoria vai encontrar o mesmo. Manter a loja atualizada é o que faz com que a revisão seguinte seja curta.

Como resolvê-lo no PrestaShop

O RKR Security Alert automatiza boa parte desta lista: vigia funcionários, módulos, configuração (com as alterações de pagamento marcadas como críticas), URL da loja e contas de webservice; compara o núcleo com o ZIP oficial; analisa os ficheiros à procura de portas traseiras, web shells e skimmers; controla o hash dos templates de checkout de todos os temas; revê as tarefas agendadas e a blindagem das pastas, e faz 14 verificações da configuração do servidor. Instala-se em modo de primeira auditoria, sem linha de base até dar o relatório por revisto. O RKR Sentinel acrescenta a vigilância de erros e de pagamentos que não acabam em encomenda. E se quiser a auditoria feita por pessoas, com um pacote de horas de suporte da Rekire fazemo-la nós, limpamos o que aparecer e entregamos-lhe o que fica pendente.