Vulnerabilidade crítica no PrestaShop 1.6.0.10 a 1.7.8.6 (cache MySQL do Smarty)

A 22 de julho de 2022, o PrestaShop alertou para um ataque massivo contra lojas a partir da versão 1.6.0.10. Os atacantes usam uma injeção SQL (do núcleo ou de um módulo) para ativar a cache do Smarty em MySQL e, através dela, executar código na loja. Com isso costumam instalar um formulário de pagamento falso que rouba os cartões dos clientes.

• O PrestaShop 1.7.8.7 reforça a cache do Smarty contra este ataque. As versões 8 e 9 já o incluem.
• O PrestaShop 1.6 não recebeu nenhuma correção: é preciso aplicar a correção deste artigo.
• O módulo blockwishlist (lista de desejos) da versão 2.0.0 à 2.1.0 tinha uma das injeções SQL usadas. Atualize-o.

Solução definitiva: atualizar

Veja a sua versão em Advanced Parameters > Information. Se for uma 1.7 anterior à 1.7.8.7, atualize. O ideal é passar para uma versão com suporte: hoje a última é a 9.2.0, e o ramo 8 continua a receber correções (8.2.8). Atualize também todos os módulos, sobretudo os de terceiros: a injeção SQL costuma vir de um módulo.

Os guias erro ao atualizar com o 1-Click Upgrade e erro de ligação ao atualizar o PrestaShop cobrem as falhas mais habituais. Faça antes uma cópia completa (ficheiros e base de dados).

Correção para lojas que não podem atualizar já

Se a sua loja for 1.6, ou uma 1.7 que não pode atualizar de imediato, desative a cache do Smarty em MySQL. Praticamente ninguém a usa (a cache em ficheiros é mais rápida), por isso retirá-la não afeta o funcionamento da loja.

1. Abra o ficheiro config/smarty.config.inc.php da loja a partir do gestor de ficheiros do cPanel.
2. Procure este bloco (está por volta das linhas 40-43 no PrestaShop 1.6 e 43-46 no 1.7):

if (Configuration::get('PS_SMARTY_CACHING_TYPE') == 'mysql') {
    include _PS_CLASS_DIR_.'Smarty/SmartyCacheResourceMysql.php';
    $smarty->caching_type = 'mysql';
}

3. Apague-o por inteiro, as quatro linhas, e guarde.
4. Verifique se a loja carrega normalmente.

Além disso, em Advanced Parameters > Performance, na secção Smarty, verifique se Caching type está em File System e não em MySQL.

Esta correção corta a via de execução de código, mas não corrige a injeção SQL de origem. Continua a ser necessário atualizar.

Aplicá-la a muitas lojas de uma vez por SSH

Se administrar várias lojas, localize primeiro os ficheiros que têm o bloco (substitua RUTA pela pasta onde estão as lojas, por exemplo /home/usuario):

grep -rl --include=smarty.config.inc.php "PS_SMARTY_CACHING_TYPE') == 'mysql'" RUTA

E apague-o em todos eles (elimina a linha do if e as três seguintes):

grep -rl --include=smarty.config.inc.php "PS_SMARTY_CACHING_TYPE') == 'mysql'" RUTA \
  | xargs sed -i "/PS_SMARTY_CACHING_TYPE') == 'mysql'/,+3d"

Verifique depois que os ficheiros continuam a ser PHP válido:

find RUTA -name smarty.config.inc.php -exec php -l {} \;

Verificar se a loja já foi atacada

Procure estes sinais:

• Um ficheiro chamado blm.php na pasta principal da loja.
• Nos registos de acesso: um pedido POST a um módulo, seguido um segundo depois de uma visita à página inicial e de um pedido a /blm.php.
• Um formulário de pagamento com cartão que não foi colocado por si na página de pagamento, ou clientes que reportam débitos fraudulentos.
• Ficheiros PHP modificados recentemente que não correspondem a nenhuma atualização sua. Por SSH, find RUTA_TIENDA -name "*.php" -mtime -30 lista os alterados nos últimos 30 dias.

Não aparecer blm.php não exclui um ataque: os atacantes mudam os nomes. Se encontrar qualquer um destes sinais, coloque a loja em manutenção, faça uma cópia do estado em que está e abra um ticket: ajudamo-lo a localizar os ficheiros afetados. Apagar o bloco do Smarty não limpa uma loja já infetada; quando estiver limpa, altere as palavras-passe do painel do PrestaShop, da base de dados e do FTP.