Injeção SQL em módulos do PrestaShop: como detetar administradores falsos

Abre a lista de funcionários do back office e vê contas que não criou. Às vezes uma, às vezes várias seguidas, com emails parecidos e todas com o perfil de superadministrador. Ninguém entrou com a sua palavra-passe: foi um programa que as escreveu diretamente na base de dados, aproveitando um módulo com uma falha de injeção SQL.

É um dos padrões de ataque mais repetidos contra o PrestaShop. Vamos ver como funciona, como detetá-lo e o que fazer.

O que é uma injeção SQL, numa loja

Um módulo recebe um dado do pedido (um identificador, um texto de pesquisa, um filtro) e mete-o numa consulta à base de dados sem o limpar. Se em vez do número esperado chegar um pedaço de SQL, a base de dados executa-o. No PrestaShop a defesa básica é simples: converter em inteiro o que deve ser um número e passar por pSQL() o que é texto. O problema é que nem todos os módulos o fazem em todos os seus pontos de entrada.

Os mais perigosos são os controladores front dos módulos: URL públicos, acessíveis sem iniciar sessão, pensados para o carrinho, para uma pesquisa por Ajax, para um filtro ou para o regresso de um gateway de pagamento. Se um deles tiver a falha, qualquer pessoa na Internet a pode explorar.

Como é a campanha típica

1. Varrimento em massa. Um robô percorre milhares de lojas à procura de módulos com vulnerabilidades conhecidas. Não o escolhe a si: basta-lhe que tenha instalada a versão vulnerável.
2. Exploração. Envia o pedido que injeta um INSERT na tabela de funcionários, ou um UPDATE que sobe o perfil de uma conta existente.
3. Rajada. Como o robô não sabe se funcionou, repete. Por isso é habitual encontrar várias contas criadas quase ao mesmo tempo, com identificadores consecutivos.
4. Uso posterior. Com a conta, alguém entra no back office, instala um módulo que é na verdade uma porta traseira, altera os dados de um método de pagamento ou injeta um skimmer no template do checkout.

Como detetá-lo em ps_employee

A tabela de funcionários (com o prefixo da sua loja, normalmente ps_) é pequena e fácil de rever. A partir do phpMyAdmin ou da ferramenta de base de dados do seu alojamento:

SELECT id_employee, firstname, lastname, email, id_profile, active, last_passwd_gen FROM ps_employee ORDER BY id_employee DESC;

O que ver:

• id_profile = 1 é o perfil de superadministrador. Conte quantos tem e se os reconhece a todos.
• Identificadores consecutivos no fim da lista que ninguém da sua equipa criou.
• Emails que não são do seu domínio ou com nomes genéricos.
• Nomes e apelidos vazios ou repetidos, que uma criação a partir do back office não deixa passar.
• last_passwd_gen com datas que não batem com nenhuma criação de que se lembre.
• Contas antigas que mudaram de perfil: um funcionário da logística que de repente é superadministrador.

Na mesma visita, veja também as contas de webservice (Parâmetros Avançados → Webservice). Uma chave de API nova com permissão de escrita sobre a configuração é uma porta que sobrevive à mudança de todas as palavras-passe e que não aparece no menu de funcionários.

O que fazer se encontrar uma

1. Não apague ainda: desative. Ponha a conta inativa e guarde os seus dados. Vão servir-lhe para saber desde quando e o que fez.
2. Reveja o que foi mexido. Módulos instalados recentemente, alterações na configuração dos métodos de pagamento (IBAN da transferência, chaves do gateway), templates do checkout, funcionários e webservice, e os URL da loja.
3. Procure ficheiros novos. O habitual é que, com o acesso, tenha ficado uma porta traseira no disco. Compare o núcleo e os módulos com os seus pacotes originais.
4. Identifique o módulo vulnerável. Os registos de acesso do servidor costumam mostrar pedidos estranhos a um controlador de módulo mesmo antes do aparecimento da conta. Esse módulo tem de ser atualizado ou retirado.
5. Mude as credenciais: as palavras-passe de todos os funcionários, as chaves de webservice e, se houver indícios de que leram a configuração, a palavra-passe da base de dados.
6. Reveja as encomendas recentes com o banco ou o gateway, não vá o dinheiro ter sido desviado.

Porque a prevenção é atualizar módulos

As campanhas em massa quase nunca usam falhas desconhecidas. Usam vulnerabilidades publicadas, muitas vezes com patch disponível há meses. O robô funciona porque muitas lojas não atualizam os seus módulos, ou porque o módulo vulnerável foi abandonado pelo autor e ninguém o substituiu.

Algumas medidas concretas:

• Inventário de módulos com a versão e a origem. Saber o que tem é o primeiro passo para saber o que o afeta quando sai um aviso.
• Atualize primeiro numa cópia e depois em produção, mas atualize. Um módulo sem atualizar há dois anos é uma aposta.
• Retire o que não usa, incluindo as pastas de módulos desinstalados que continuam no disco.
• Acompanhe os avisos de segurança do PrestaShop e dos autores dos seus módulos.
• Mantenha o PrestaShop e o PHP em versões com suporte. Muitos módulos deixam de receber patches para versões antigas: se a sua loja continua na 1.6 ou numa 1.7 inicial, cada novo aviso tem mais probabilidades de ficar sem solução para si, e a migração passa a ser também uma medida de segurança.

Uma firewall de aplicação pode travar parte das tentativas, mas não substitui o patch: as variantes de uma mesma injeção são muitas, e basta uma que passe.

Como resolvê-lo no PrestaShop

O RKR Security Alert guarda uma fotografia dos funcionários, dos módulos, da configuração, dos URL da loja e das contas de webservice, e compara-a com o estado atual em cada carregamento do back office e por cron. Por isso deteta um superadministrador criado por injeção SQL mesmo que não tenha passado por nenhum hook, e avisa por Telegram como alerta máximo, separado do resto; também quando uma conta existente é promovida a superadministrador ou aparece uma conta de webservice nova. O seu scanner inclui um analisador de injeção SQL que assinala valores do pedido que chegam a uma consulta sem conversão nem escape. Se já tem a suspeita ou o incidente em cima, com um pacote de horas de suporte da Rekire fazemos a auditoria, localizamos o módulo por onde entraram, limpamos e deixamos a loja atualizada.