Une boutique signalée par Google Remise en état en 48 heures.
Un mot de passe administrateur volé, trois extensions piégées, un site signalé par Google et un domaine qui n’envoie plus d’e-mails. Une boutique en ligne romande, sans contrat avec Avepto, nous a demandé d’intervenir.
- Client
- Boutique en ligne Suisse romande, anonymisée
- Relation
- Intervention ponctuelle Sans contrat de service
- Périmètre
- WordPress, WooCommerce Trois sites, un hébergement
- Solution
- Nettoyage, durcissement En 48 heures, boutique ouverte
Sommaire
Une boutique en ligne qui tourne depuis plusieurs années.
La boutique vend des produits physiques sur WordPress et WooCommerce. Quelques milliers de commandes, Twint comme moyen de paiement principal, des centaines de comptes clients. Trois sites partagent le même hébergement. Le site a été construit puis retouché par des prestataires successifs, sans responsable informatique attitré. Quand l’écran d’avertissement de Google est apparu, l’entreprise n’avait personne à appeler. Elle a fait appel à Avepto.
Une connexion au premier essai, puis une boutique à l’arrêt.
Un lundi soir, peu avant 23 heures, une adresse louée chez un hébergeur étranger arrive directement sur la page d’administration. Elle ne parcourt pas le site. Trois minutes plus tard, la connexion réussit au premier essai, avec le mot de passe valide du compte administrateur. En quatre minutes, trois extensions piégées sont déposées ; l’une d’elles crée un compte administrateur caché. Rien de tout cela n’est visible depuis la boutique.
Douze jours plus tard, Google Safe Browsing classe le site en « ingénierie sociale ». Un écran rouge remplace la vitrine, les grands fournisseurs d’accès bloquent le domaine, les e-mails ne passent plus. L’Office fédéral de la cybersécurité contacte l’entreprise et son hébergeur. Deux jours après le signalement, le site est nettoyé, durci et rouvert ; certains clients ne l’atteindront pas avant deux à trois semaines.
Quatre faiblesses ordinaires, une boutique exposée.
L’attaque n’a pas exploité de faille du site. Elle enchaîne quatre faiblesses que l’on retrouve sur la plupart des boutiques construites au fil des ans.
Un mot de passe volé en amont du site
Les journaux ne montrent ni bruteforce, ni exploitation de faille : l’attaquant connaissait le mot de passe. Il a été récupéré ailleurs, par un logiciel voleur d’identifiants sur un poste, une fuite réutilisée ou un hameçonnage. Le captcha de connexion a été franchi à la main.
Un seul compte, sans double authentification
Le compte administrateur, seul capable d’installer des extensions, n’avait ni double authentification ni verrouillage après échec, et l’URL de connexion était celle par défaut. Une fois le mot de passe connu, tout était ouvert.
Des accès de prestataires restés ouverts
Deux extensions de télégestion, installées par d’anciens prestataires, donnaient toujours un accès complet au site depuis l’extérieur, dont une connexion sans mot de passe pour un développeur parti depuis longtemps. Ces accès contournent le mot de passe, l’URL masquée et la double authentification.
Une porte dérobée dormante d’un incident antérieur
Une extension piégée d’un incident plus ancien dormait encore sur le disque. Une réactivation en masse des extensions, la veille du signalement, l’a remise en service par accident. Sur une boutique, un administrateur caché voit les clients, les adresses et l’historique des commandes, et peut modifier le tunnel de paiement.
Comprendre, éradiquer, fermer, alléger, rouvrir.
Comprendre avant de nettoyer
Les journaux d’accès du serveur ont permis de reconstituer l’attaque minute par minute : l’arrivée directe sur l’administration, la connexion réussie, les trois dépôts d’extensions. Cette reconstitution a identifié le point d’entrée observé : un identifiant valide. Dans cette séquence, les journaux ne montrent pas d’exploitation d’une faille du site.
Rien n’a été supprimé à l’aveugle. Les éléments suspects ont été mis en quarantaine et conservés pour contre-expertise. Toutes les sessions ouvertes ont été détruites : un cookie volé n’ouvrait plus la porte.
Éradiquer et vérifier les trois sites
Les trois extensions piégées, la porte dérobée dormante et les deux comptes administrateurs cachés ont été retirés. Les trois sites de l’hébergement ont ensuite été passés au même contrôle : extensions malveillantes, clé de porte dérobée, motifs de webshell, comptes non autorisés.
Les sommes de contrôle du cœur WordPress et des trente extensions publiques étaient conformes. Les faux positifs ont été inspectés un à un, dont une image d’icônes de paiement et une mise à jour automatique nocturne prise pour une réinfection.
- Extensions piégées éradiquées
- Comptes administrateurs cachés supprimés
- Cœur WordPress vérifié
- Trente extensions vérifiées
- Sessions détruites
- Éléments conservés en quarantaine
Fermer les accès
Le mot de passe administrateur a été réinitialisé et remis par un canal séparé, les clés de session renouvelées sur les trois sites, la double authentification activée, l’URL de connexion masquée, le verrouillage après cinq échecs mis en place et un pare-feu applicatif Wordfence déployé.
Les deux télégestions d’anciens prestataires ont été supprimées, cinq comptes d’anciens intervenants purgés et l’inscription publique fermée : elle avait produit près de 2 000 comptes indésirables, mêlés à de vrais clients. Un seul compte à privilèges subsiste, protégé.
Alléger la boutique
Chaque extension a été confrontée à ses données réelles d’usage avant décision : commandes, tables, rendu sur les pages. Les passerelles de paiement en service ont été conservées ; un générateur de faux avis et un explorateur de fichiers ont été supprimés, sept extensions sans usage démontré désactivées.
Le site n’avait plus de cache de page depuis plus d’un an. Un cache a été installé, avec exclusion du panier, du paiement et des comptes. Le temps de réponse du serveur est passé d’environ deux à trois secondes à 0,2 seconde.
Lever le signalement
La remise en état achevée, une demande de réexamen a été soumise à Google Safe Browsing. Elle détaillait les mesures prises. L’hébergeur et l’Office fédéral de la cybersécurité ont été informés. Google a levé son avertissement dans les jours suivants.
Tous les opérateurs n’ont pas suivi au même rythme : un grand fournisseur d’accès suisse a continué de bloquer le site pour ses abonnés. Chacun tient sa propre liste ; quand l’un d’eux ne répond pas, il ne reste qu’à documenter la remise en état, relancer et attendre. Le domaine n’est sorti de toutes les listes qu’au bout de deux à trois semaines, et les e-mails ont repris.
Quarante-huit heures pour remettre en état, jusqu’à trois semaines pour sortir des listes.
Remise en état
48 h
Entre la première intervention et la remise des accès : investigation, éradication, vérification des trois sites et durcissement. Une fois le site nettoyé et rouvert, les encaissements ont pu reprendre pendant que l’analyse et le durcissement se poursuivaient. Un paiement par carte est passé le matin du second jour, alors que l’avertissement de Google était encore affiché.
Chronologie de l’intervention.
Temps de réponse du serveur
×10
D’environ deux à trois secondes à 0,2 seconde pour la page d’accueil, une fois le cache de page en place. Mesuré avant et après, sur le même hébergement.
Ce n’est pas une faille du site qui a été exploitée : c’était une clé, et cette clé traînait. Les mesures ci-dessus font qu’un mot de passe volé ne suffit plus, et qu’un accès oublié ne survit plus à celui qui l’a créé.
Une boutique fermée par un écran rouge.
Pour la boutique
Le risque, avant
Des semaines de ventes amputées, un écran rouge et des e-mails bloqués. Deux comptes administrateurs cachés avaient accès à des centaines de comptes clients : il fallait évaluer si la violation devait être annoncée au Préposé fédéral à la protection des données et à la transparence.
Le bénéfice, depuis
Un seul compte à privilèges, protégé par la double authentification. Les accès de prestataires supprimés. Une boutique plus légère, plus rapide, et un dossier de remise en état à présenter à Google, à l’hébergeur et aux partenaires de paiement.
Pour le site
Le risque, avant
Trois extensions piégées, une porte dérobée dormante, deux télégestions ouvertes sur l’extérieur, pas de pare-feu applicatif, pas de cache, des mises à jour au hasard.
Le bénéfice, depuis
Pare-feu applicatif en blocage, verrouillage des connexions, clés de session renouvelées, analyse planifiée, mises à jour formalisées et un temps de réponse divisé par dix.
Témoignage
Nous avons découvert l’attaque par l’écran rouge de Google, pas par le site. En deux jours, nous savions ce qui s’était passé, et surtout qui avait encore une clé.
Une boutique est un système d’information.
- Le compte administrateur d’une boutique donne accès aux données clients, aux commandes et au paiement. Il mérite les mêmes règles que la messagerie d’entreprise : double authentification et mot de passe unique dans un gestionnaire.
- Les accès de prestataires survivent aux prestataires. Chaque départ doit se solder par une révocation, et chaque site marchand mérite un inventaire de qui peut y entrer.
- Le signalement coûte plus cher que l’intrusion : vitrine, e-mails et réputation tombent ensemble, et un domaine en .ch peut même être bloqué à la demande d’une autorité fédérale. La levée des blocages ne dépend pas de l’entreprise.
Au moment de la remise du rapport, trois points restaient entre les mains de l’entreprise : analyser le poste depuis lequel le mot de passe a été volé, renouveler tous ses mots de passe depuis une machine saine, et sortir ses accès d’hébergement d’un document partagé pour un gestionnaire de mots de passe. La porte est refermée ; ces trois gestes décident qu’elle le reste.
Votre boutique
Commencez par savoir qui a la clé.
Comptes, accès tiers, extensions : trois choses à vérifier sur un site marchand avant qu’un écran rouge ne le fasse pour vous. Sans engagement.
Planifier un audit de sécurité