Réponse à une intrusion PrestaShop : contenir, enquêter et rétablir

Ce que nous ferions

Nous définirions d'abord les responsabilités de confinement et de notification, puis choisirions une méthode de reprise à partir des preuves concernant votre boutique actuelle. Le périmètre dépend de son hébergement, de ses versions de PrestaShop et PHP, de ses modules, intégrations, thème, contenus et données stockés, ainsi que des marchés desservis et de l'équipe disponible pour intervenir. Incluez les autres boutiques partageant le compte et les personnes chargées des paiements, de l'expédition et du service client.

En cas de compromission confirmée, nous préparerions un environnement de reprise sain et répéterions l'opération sur un site de préproduction privé, avec des données examinées et des intégrations contrôlées. Une copie de la boutique compromise reste non fiable tant qu'elle n'a pas été examinée. Ne planifiez la bascule qu'après la réussite des contrôles ci-dessous, avec l'approbation d'un responsable désigné, le rapprochement des commandes et un déploiement réversible vers un état connu et fiable.

Pour une évaluation au périmètre défini, le service PrestaShop Security Audit & Hardening Report fournit des constats et un plan hiérarchisé ; le périmètre de correction est défini séparément.

Stopper les préjudices en cours et tenir une chronologie de l'incident

Notez le moment où vous en avez pris connaissance, les faits signalés, les hôtes touchés et les premières preuves. Désignez un responsable d'incident et, en parallèle, des responsables du confinement, des preuves, du contact avec le prestataire de paiement et de l'évaluation juridique. Tenez un journal d'actions horodaté en UTC.

Fournissez aux intervenants une fiche d'incident concise : domaines touchés, symptôme observé, déploiements récents, contacts de l'hébergeur et emplacement des preuves préservées accessibles de manière sécurisée. Convenez d'un canal de communication indépendant de tout compte e-mail ou employé suspecté d'être compromis, et ne consignez pas les identifiants dans le journal d'actions.

Si les clients sont exposés à un dispositif actif de vol de données de paiement ou à une autre attaque en cours, restreignez rapidement l'accès. Coordonnez-vous avec votre hébergeur et votre spécialiste pour préserver les preuves volatiles lorsque c'est possible, mais ne retardez pas l'arrêt des préjudices pendant l'enquête.

Le mode maintenance de PrestaShop se trouve dans Paramètres de la boutique > Paramètres généraux > Maintenance sur les versions modernes. Il peut afficher une page d'attente et autoriser certaines IP de maintenance. Ce n'est pas une isolation de l'hôte : des fichiers PHP malveillants autonomes, des tâches planifiées et d'autres services peuvent rester accessibles.

Les noms des paramètres de configuration sous-jacents sont PS_SHOP_ENABLE et PS_MAINTENANCE_IP. Si le back-office est indisponible, demandez à l'hébergeur ou au développeur de confirmer le contexte boutique applicable et la méthode de confinement sûre ; n'appliquez pas une modification de base non examinée à l'ensemble d'une installation multiboutique.

• Demandez à l'hébergeur de restreindre les accès entrants d'administration, le trafic sortant et les services touchés selon les besoins.
• Utilisez une page d'attente externe en périphérie ou au niveau de l'hôte si l'application elle-même n'est pas fiable.
• Prévenez rapidement le prestataire de paiement ou l'acquéreur si les données de paiement ou l'intégrité de la commande peuvent être touchées. Suivez ses instructions d'incident.
• Impliquez un spécialiste qualifié, l'assureur ou l'équipe interne concernée selon votre dispositif de gestion des incidents.
• Évitez de vous connecter au système compromis avec de nouveaux secrets que l'attaquant pourrait lire.

Les paniers indésirables et le spam de formulaires ne prouvent pas à eux seuls une compromission, mais peuvent générer des coûts, perturber le service ou dissimuler d'autres abus. Traitez ces symptômes comme des éléments à examiner, pas comme la preuve que l'événement est sans gravité.

Collecter les preuves avec des permissions restrictives et des empreintes vérifiées

Privilégiez les instantanés du prestataire et des outils de collecte fiables avec votre spécialiste. Copiez la racine web, y compris les fichiers cachés, la base de données, les journaux web/PHP/applicatifs et les enregistrements pertinents du plan de contrôle. Capturez les processus, connexions réseau et sessions volatils avant l'arrêt lorsque le spécialiste le juge utile. Les outils de l'hôte compromis peuvent ne pas être fiables.

Incluez les journaux applicatifs configurés pour cette installation et les éventuelles destinations distinctes des journaux de modules. Les chemins tels que var/logs/ et log/ sont des exemples à confirmer pour votre version. Demandez à l'hébergeur de conserver les journaux archivés par rotation et les enregistrements externes au serveur, tels que les historiques des services en périphérie, d'authentification et de déploiement, avant l'expiration de leur durée de conservation. Consignez les lacunes dans l'inventaire.

L'exemple GNU/Linux suivant collecte les fichiers et journaux ordinaires. Ce n'est ni une image disque forensique ni une acquisition complète de l'incident. Définissez d'abord les chemins, la base et le fichier d'options client MySQL protégé. La destination des preuves doit se trouver hors de la racine web et être inaccessible à l'utilisateur web. Exécutez bash -n collect-evidence.sh avant utilisation.

#!/usr/bin/env bash
set -u -o pipefail
umask 077

evidence_root='/srv/incident-evidence'
webroot='/var/www/html'
database='prestashop'
mysql_options='/root/incident-mysql.cnf'

mkdir -p -- "$evidence_root" || exit 1
chmod 700 -- "$evidence_root" || exit 1
case_dir=$(mktemp -d "$evidence_root/prestashop-incident-$(date -u +%Y%m%dT%H%M%SZ)-XXXXXX") || exit 1
chmod 700 -- "$case_dir" || exit 1
failures=0

if ! tar --xattrs --acls -czf "$case_dir/files.tgz" -C "$webroot" . 2>"$case_dir/files-errors.log"; then
  printf '%s\n' 'File archive incomplete or failed.' >&2
  failures=$((failures + 1))
fi
if ! mysqldump --defaults-extra-file="$mysql_options" --single-transaction \
     --routines --triggers "$database" >"$case_dir/database.sql" 2>"$case_dir/database-errors.log"; then
  printf '%s\n' 'Database dump failed or incomplete.' >&2
  failures=$((failures + 1))
fi
mkdir -- "$case_dir/logs" || exit 1
for log_path in /var/log/nginx /var/log/apache2 /var/log/php*; do
  if [[ -e "$log_path" ]]; then
    if ! cp -a -- "$log_path" "$case_dir/logs/" 2>>"$case_dir/log-copy-errors.log"; then
      printf 'Failed to copy: %s\n' "$log_path" >&2
      failures=$((failures + 1))
    fi
  fi
done
printf 'UTC: %s\nCollection failures: %s\n' "$(date -u +%FT%TZ)" "$failures" >"$case_dir/COLLECTION-STATUS"

if ! (
  cd -- "$case_dir" || exit 1
  find . -type f ! -path './SHA256SUMS' ! -path './HASH-ERRORS' -print0 |
    LC_ALL=C sort -z |
    xargs -0 -r sha256sum
) >"$case_dir/SHA256SUMS" 2>"$case_dir/HASH-ERRORS"; then
  printf '%s\n' 'Hashing failed; inspect HASH-ERRORS.' >&2
  exit 1
fi
printf 'Evidence directory: %s\n' "$case_dir"
if (( failures > 0 )); then
  printf '%s\n' 'Collection is incomplete; resolve recorded failures.' >&2
  exit 1
fi

Les permissions sont restreintes avant la collecte. Le manifeste calcule récursivement les empreintes des fichiers ordinaires et exclut son propre fichier de sortie ainsi que le fichier d'erreurs de calcul. Chaque exécution crée un nouveau répertoire. Examinez chaque journal d'erreurs et l'inventaire attendu des preuves même si le script se termine avec succès. L'absence de chemins de journaux facultatifs n'établit pas que tous les journaux pertinents ont été collectés.

Une archive des fichiers actifs et un export de base ne constituent pas nécessairement un instantané atomique. La cohérence de --single-transaction dépend des tables transactionnelles et des changements simultanés de la base. L'archivage peut signaler des fichiers en cours de modification. Coordonnez un instantané ou une acquisition avec mise au repos des services lorsque c'est nécessaire et documentez ses limites.

Copiez les preuves vers un stockage protégé inaccessible à l'attaquant. Conservez les originaux, horodatages, identifiants de source et traces d'accès et de transfert. Revérifiez les empreintes après transfert avec sha256sum -c SHA256SUMS depuis le répertoire des preuves. Les empreintes détectent les modifications ultérieures par rapport au manifeste ; elles n'établissent pas que la source était saine ou complète.

Examiner les fichiers PrestaShop, les comptes et le contenu stocké

Les modèles Employee natifs de PrestaShop 1.7.8 et 9.1 ne fournissent pas de champ date_add de création de compte. Construisez la chronologie des comptes à partir d'autres enregistrements. Recoupez les listes de comptes avec les sauvegardes, journaux d'authentification et d'audit et l'historique de base disponible.

Un relevé par date de modification est utile pour un premier tri :

find . -type f -name "*.php" -mtime -30 -ls

Exécutez-le si possible sur une copie des preuves. Les horodatages peuvent être manipulés, et les mises à niveau légitimes modifient aussi les fichiers. Un nom suspect n'est pas une preuve ; l'absence de résultat dans cette recherche n'est pas une preuve de sécurité.

Recherchez les éléments script inattendus, les domaines externes et les exécutions encodées suspectes. Utilisez ces résultats comme pistes. Les recherches par mots-clés peuvent manquer du contenu malveillant en base. Faites examiner par une personne compétente en sécurité les charges utiles décodées, les différences avec les sources fiables, les réglages, les accès utilisateurs et les enregistrements métier modifiés. N'ouvrez pas les pages potentiellement hostiles dans le navigateur habituel du personnel.

Étendez la comparaison des fichiers aux chemins accessibles en écriture tels que img/, upload/, download/, var/cache/ et les dossiers d'envoi du thème. Un nom apparemment banal comme config.php ne justifie pas de faire confiance à un fichier. Comparez modules/, override/classes/ et override/controllers/ avec les paquets fiables des éditeurs et le code personnalisé examiné. Examinez les modules inattendus et les mécanismes susceptibles de recréer des fichiers ou des comptes supprimés.

Après préservation des preuves, Security Scan peut fournir des constats hiérarchisés et des emplacements à examiner sur une copie de travail isolée. Son installation modifie les fichiers et l'état de la base, même si son analyse ne corrige pas les fichiers et ne change pas les réglages. Recoupez les constats avec des sources fiables ; un résultat issu d'un environnement d'exécution compromis ne peut pas établir que l'environnement est sain.

Exemple : une commande qui paraît normale au personnel

Un client signale un formulaire de carte bancaire inhabituel, mais l'administrateur ne le voit pas lorsqu'il est connecté. Traitez ce signalement comme un élément à examiner. Transmettez à l'intervenant l'URL concernée, l'heure approximative et le contexte du visiteur, sans demander au client ses données de carte. Avant d'afficher du contenu non fiable, utilisez une copie d'investigation jetable dont les identifiants de production ont été retirés, les intégrations réelles désactivées et le trafic sortant restreint. Avec un navigateur isolé à accès réseau contrôlé, comparez le rendu du passage de commande, les scripts chargés et les destinations réseau tentées aux sources fiables du thème et des modules pour la boutique et la langue concernées.

Si une charge malveillante est trouvée dans un bloc HTML stocké, remplacer uniquement les fichiers du thème laisse cette source dans la base. Examinez le contenu concerné et l'accès ou le chemin de code qui l'a écrit, puis répétez le parcours visiteur concerné sur la copie reconstruite. Confirmez indépendamment la destination du paiement auprès du prestataire avant de rétablir ce parcours.

Restreindre l'exécution avec des règles propres au serveur

Restreignez l'exécution dans les répertoires d'images et d'envoi dans le cadre du confinement et du durcissement. Adaptez les règles au serveur, à la racine web, au gestionnaire PHP et au parcours légitime de téléchargement. Ne supposez pas que tout fichier PHP dans un répertoire accessible en écriture est malveillant ; les fichiers légitimes de la version nécessitent toujours une comparaison avec une source fiable.

Exemple Apache 2.4

Cet exemple de configuration serveur vise un répertoire. Adaptez-le et répétez-le pour les autres répertoires confirmés comme réservés aux données. Il ne nécessite pas la directive php_flag engine off propre à mod_php :

<Directory "/var/www/html/img">
    <FilesMatch "(?i)\.(php[0-9]*|phtml|phar)(\.|$)">
        Require all denied
    </FilesMatch>
</Directory>

Si vous placez plutôt une règle FilesMatch dans .htaccess, confirmez la configuration AllowOverride pertinente et les règles existantes. Ne placez pas de conteneurs Directory dans .htaccess. Testez la configuration avec l'outil de contrôle Apache installé avant de recharger.

Exemple Nginx

# Place before a generic PHP regex location in the applicable server block.
location ~* ^/(img|upload|download)/.*\.(php[0-9]*|phtml|phar)([./]|$) {
    return 403;
}

Adaptez le préfixe d'URI aux boutiques en sous-répertoire. Vérifiez la priorité des blocs location, y compris les préfixes ^~, les alias et les blocs imbriqués qui pourraient contourner la règle. Exécutez nginx -t, rechargez par votre procédure habituelle de gestion des services et vérifiez que des fichiers de test connus comme sûrs sont refusés sans être exécutés.

Testez ces motifs avec votre configuration serveur et votre gestionnaire PHP avant de vous y fier. Interdire l'exécution ne retire pas les scripts injectés dans les modèles légitimes et ne ferme pas la vulnérabilité d'écriture initiale.

Renouveler les secrets et révoquer les accès depuis un environnement sain

Déterminez ce que l'attaquant pouvait lire ou contrôler, puis renouvelez les identifiants exposés depuis un appareil de confiance et un système reconstruit ou sécurisé. Coordonnez les changements afin de révoquer les anciens accès et de fournir les nouveaux secrets aux applications conjointement.

• Réinitialisez les identifiants des employés, examinez les profils et supprimez ou désactivez les accès non autorisés après préservation des preuves.
• Examinez le panneau de contrôle de l'hébergement, les utilisateurs SSH/SFTP, les clés autorisées, les jetons de déploiement, le DNS et les identifiants des sauvegardes.
• Renouvelez les identifiants de base et mettez à jour atomiquement la configuration applicative locale appropriée.
• Renouvelez les identifiants exposés de paiement, livraison, e-mail et autres API, y compris les secrets de vérification des webhooks.
• Planifiez les réinitialisations de mots de passe clients, la révocation des sessions actives et la notification selon l'exposition.

PrestaShop 1.6 stocke l'ancienne configuration dans config/settings.inc.php ; les versions modernes utilisent app/config/parameters.php. Examinez le stockage réel des clés de votre version plutôt que d'appliquer une commande globale de remplacement.

Le renouvellement des cookies et des clés nécessite un plan propre à la version. Les implémentations de hachage 1.7.8 et 9.1 conservent la vérification MD5 historique avec un sel statique associé à la clé de cookie. Modifier cette clé peut empêcher les clients aux anciens hachages de se connecter. Coordonnez la migration ou réinitialisation des mots de passe, l'invalidation des cookies, les sessions côté serveur et la gestion du cache pour les clients comme pour les employés.

Ajoutez une authentification à deux facteurs prise en charge, des mots de passe uniques, une limitation de débit et des accès surveillés lorsque c'est possible. CAPTCHA peut réduire certaines automatisations, mais ne constitue pas un contrôle complet contre les identifiants volés ou l'exploitation du code des modules.

Après la reprise, Security Revolution peut fournir une connexion du personnel avec application d'authentification et des limites de requêtes ; examinez ses observations du trafic avant d'activer le blocage. Configurez et testez ces contrôles sur la boutique rétablie pour qu'ils ne bloquent pas les intervenants et ne perturbent pas les requêtes légitimes des intégrations.

Évaluer les obligations de notification pendant le confinement

Évaluez le champ territorial du GDPR pour votre entreprise. Tenez compte de son lieu d'établissement, de l'offre de biens ou services à des personnes dans l'UE et du suivi éventuel de leur comportement. Le seul recours à un prestataire de paiement européen ne rend pas le GDPR applicable à une boutique située hors d'Europe. Consultez les indications de la Commission sur le champ d'application.

Pour une violation de données personnelles relevant de ce cadre, notifiez l'autorité de contrôle sans retard injustifié et, si possible, dans les 72 heures suivant la prise de connaissance, sauf s'il est peu probable qu'elle entraîne un risque pour les droits et libertés des personnes. Justifiez le retard lorsque c'est requis et fournissez les informations par étapes si nécessaire.

Informez les personnes touchées sans retard injustifié lorsqu'un risque élevé est probable, sous réserve des exceptions applicables. Une catégorie de données comme les mots de passe ou les données de paiement ne tranche pas automatiquement l'évaluation du risque : les mesures de protection, l'exposition et les conséquences probables comptent. Documentez la violation et l'évaluation même si la notification à l'autorité n'est pas requise. Suivez les instructions du CEPD sur les violations.

Le travail de notification se mène parallèlement à l'enquête. Consignez l'heure de prise de connaissance, les systèmes et données touchés, les conséquences probables, les mesures de protection, les décisions et les suites. Vérifiez avec les spécialistes responsables les autres obligations de notification imposées localement, par les contrats, le secteur des paiements et les assurances.

Communiquez clairement avec les clients : faits connus, données touchées, risques probables, mesures de protection et moyen de contact. Indiquez honnêtement les incertitudes. Ne demandez pas aux clients d'envoyer leurs mots de passe ou leurs données de carte. Expliquez vos canaux officiels de contact et de réinitialisation pour faciliter l'identification des tentatives d'hameçonnage opportunistes.

Désignez une personne chargée d'une adresse de contact d'incident surveillée, accessible uniquement à l'équipe d'intervention. Conservez un message approuvé et son historique de mise à jour pour que le support apporte des réponses cohérentes, consigne les questions non résolues et oriente les informations sensibles vers le canal sécurisé convenu. Traduisez le message pour les marchés touchés que vous desservez.

Reconstruire depuis des sources fiables et définir les contrôles de réouverture

Une sauvegarde récente peut déjà contenir la compromission. Déterminez la période probable d'exposition et vérifiez les sauvegardes candidates plutôt que de restaurer les fichiers de la nuit précédente sans examen.

1. Construisez un environnement de confiance et fermez le point d'entrée démontré, y compris l'accès au niveau de l'hôte s'il est touché.
2. Installez le cœur, le thème et les modules depuis des sources éditeurs authentifiées. Ne restaurez que le code personnalisé et les surcharges examinés.
3. Corrigez les composants vulnérables et retirez ceux qui ne sont plus pris en charge ou fournissez un plan de transition testé.
4. Validez les données migrées, la configuration, les accès employés, les destinations de paiement et le HTML stocké. Utilisez la comparaison des sources, des enregistrements de référence fiables et un examen expert, pas grep seul.
5. Confirmez le renouvellement des secrets, la révocation des sessions, les restrictions sortantes et le bon fonctionnement des interdictions d'exécution.
6. Testez la commande, les paiements, notifications de retour, e-mails, remboursements et accès administratifs sous surveillance.
7. Documentez les preuves, les incertitudes non résolues, la validation des responsables et les actions de surveillance ou de retour arrière avant la réouverture.

Si une mise à niveau immédiate est impossible, une mesure d'atténuation testée au niveau des requêtes peut réduire temporairement l'exposition à une exploitation connue. Elle ne supprime pas la persistance existante et ne remplace pas un correctif pris en charge.

Une fois le confinement établi, le service PrestaShop Upgrade Service: Any Version to PrestaShop 9 peut accompagner le remplacement planifié d'une installation ancienne ; convenez séparément du périmètre de reprise et d'examen des données.

Répéter la reprise et rapprocher les données à la bascule

1. Gardez l'archive des preuves séparée de la copie de travail de reprise. Restreignez l'accès à cette copie et désactivez les e-mails réels, les opérations de paiement, les tâches planifiées et les exports d'expédition tant que leurs parcours de test ne sont pas délibérément configurés.
2. Consignez le point de reprise des données et identifiez les commandes, paiements, remboursements et mouvements de stock intervenus ensuite. Vérifiez les enregistrements du prestataire de paiement et de l'ERP ainsi que la base de la boutique.
3. Répétez le transfert final des données et les contrôles de réouverture avec vos véritables thème, modules, langues, devises et processus d'intégration. Consignez les échecs et répétez les contrôles concernés après correction.
4. Convenez du gel final des écritures et de la manière de retenir, relancer ou rapprocher les notifications entrantes des prestataires et les mises à jour externes. Désignez un responsable pour chaque file plutôt que de supprimer silencieusement les mises à jour pendant la bascule.
5. Basculez dans le créneau convenu, vérifiez le front-office public et les destinations des notifications, et suivez les premières transactions réelles jusque dans les systèmes en aval. Si les contrôles échouent, arrêtez les traitements concernés et utilisez la solution de repli fiable convenue.

Par exemple, une base restaurée peut ne pas contenir un paiement déjà encaissé par le prestataire ou une commande déjà expédiée par l'entrepôt. Rapprochez les références du prestataire, les identifiants de commande et les enregistrements d'expédition avant de rejouer les événements en attente ou d'autoriser les expéditions. Réimporter une ancienne commande ne doit ni débiter à nouveau le client ni renvoyer les marchandises. La reprise comprend un rapprochement des données métier en plus de la restauration des fichiers.

Gardez des sauvegardes isolées avec une durée de conservation suffisante pour vos besoins de détection et de reprise et testez la restauration. Trente jours peuvent être un exemple de planification, pas la preuve que tous les incidents seront couverts. Préservez le dossier d'incident et examinez les contrôles défaillants après rétablissement du service. Ne promettez ni une absence garantie de compromission résiduelle ni un délai fixe avant une nouvelle compromission.

Utilisez le guide des sauvegardes et de la reprise après sinistre pour documenter la procédure de restauration, et transformez les constats de l'incident en actions attribuées dans votre plan de durcissement de la sécurité. Consignez le responsable de chaque correction, sa méthode de vérification et la surveillance permettant de détecter une récidive.

Questions à poser à votre développeur ou agence

• Quelles preuves étayent l'évaluation du point d'entrée, et que reste-t-il à éclaircir ?
• Quels paquets du cœur, du thème et des modules ont servi à la comparaison et à la reconstruction, et quelles modifications personnalisées ont été examinées ?
• Les comptes d'hébergement, les autres boutiques, les accès de déploiement et les identifiants des intégrations étaient-ils inclus dans le périmètre ?
• Où sont conservés l'inventaire des preuves, le journal d'actions, le relevé des révocations d'identifiants et les décisions de notification ?
• Quels résultats de test justifient la réouverture, comment les enregistrements métier manquants ont-ils été rapprochés et qui a approuvé la bascule ?
• Quels symptômes déclencheront un nouveau confinement, qui reçoit les alertes et vers quel état fiable pouvons-nous revenir ?

Demandez des preuves et des responsabilités nominatives lors de la transmission. Une liste de fichiers supprimés ou un score d'analyse sans anomalie n'explique ni le point d'entrée, ni la période d'exposition, ni les raisons de la réussite des contrôles de reprise.

Questions des commerçants

Puis-je laisser la boutique ouverte pendant l'enquête ?

Fondez cette décision sur l'exposition des clients et les conseils de confinement de l'hébergeur. Le mode maintenance seul ne permet pas d'établir un périmètre de confiance ; utilisez la section sur le confinement pour convenir des parcours à restreindre et de la personne qui les vérifie.

Une mise à niveau majeure est-elle nécessaire avant la reprise ?

Le besoin immédiat est un environnement fiable dont le point d'entrée a été fermé. Une boutique ancienne peut nécessiter un remplacement pris en charge pour y parvenir, mais convenez des contrôles de compatibilité et de données avant de choisir la méthode.

Puis-je réutiliser la base des clients et des commandes ?

Éventuellement, après examen des contenus stockés, de la configuration, des comptes et des enregistrements métier. Une installation saine connectée à une base non vérifiée peut charger à nouveau le même contenu injecté.

Faut-il attendre la fin de l'enquête avant de notifier l'incident ?

Non. Confiez l'évaluation des obligations de notification pendant que le travail technique se poursuit, consignez les faits connus et suivez la procédure applicable avec les mises à jour nécessaires. La section sur la notification distingue le signalement à l'autorité de la communication aux personnes touchées.

Et si personne ne peut prouver la date exacte d'arrivée de l'attaquant ?

Consignez cette incertitude et utilisez tous les enregistrements indépendants disponibles pour évaluer les sauvegardes candidates et les données touchées. Le premier événement découvert marque la limite des preuves disponibles, sans prouver que tout était sûr auparavant.