WordPress / Prestashop : auditer un serveur en cas de piratage

Je profite de la vague récente de piratage de vieux modules de Prestashop, à savoir simpleslideshow, columnadverts, homepageadvertise, productpageadverts, issus principalement des thèmes achetés sur Themeforest.

La situation est la suivante : vous allez au travail comme tous les lundis après un week-end passé sous les quelques rayons de soleil que vous avez pu capter en ce début d’été très mitigé. Vous remarquez en arrivant que tous les sites hébergés sur votre serveur dédié ne fonctionnent plus. C’est la panique. Du coup, rendez-vous du côté de sa boite mail pour voir si l’hébergement nous a envoyé un mail d’alerte. Effectivement, il a pris l’initiative de couper tous les sites du serveur car ils étaient source d’envois massifs de mails.

1- Un peu coup d’oeil sur l’espace de vos sites en vous connectant en FTP au serveur et vous trouvez effectivement des fichiers, modifiés ce week-end à la racine du site. Si votre hébergeur est sympa, il pourra même vous envoyer un fichier diff entre la version du matin et celle du samedi, histoire de détecter plus facilement les nouveaux fichiers PHP. L’objectif est de trouver au moins un fichier. Pour ma part, j’ai trouvé un fichier nommé The.php.

2 – Il faut maintenant trouver l’origine du piratage et qui en est à l’origine. Cela peut provenir de votre thème, de vos modules ou parce que vos accès ont fuité. Pour y arriver, il faut savoir d’où est venu le fichier The.php. J’ai donc lancé dans un premier temps la commande grep -rl ‘The.php’ /var/log/ pour identifier plus rapidement les fichiers qui contiennent l’appel à ce fichier. Pour ma part, il se situait dans 3 fichiers, mais error.log.1 m’a aidé à avancer.

nano /var/log/apache2/error.log.1 puis CTRL + W, The.php. J’ai pu récupérer l’IP qui a accédé à ce fichier.

3 – Recherchez tous les accès et erreurs liées à cette IP. Pour ma part, j’ai mis le résultat de ma recherche dans un fichier, plus facile à exploiter : cat /var/log/apache2/* | grep ‘197.0.211.32’ > file.txt. Vous devriez vous retrouver avec un fichier, plus ou moins long, avec un peu de tout :

4 – Ouvrez le fichier et tentez de découvrir ce que le pirate à fait. Rappel : le fichier The.php a été créé sur le serveur. Le seul moyen de le mettre sur le serveur est soit de l’uploader (POST), soit d’envoyer une commande à un fichier tiers, déjà présent sur le serveur pour le créer. En général, l’attaque démarre toujours par un GET, puis un POST. Le GET permet de savoir si on accède au fichier contenant la faille, et le POST sert à créer un fichier ou à l’uploader directement.

[25/Jun/2016:12:01:07 +0200] "GET //modules/simpleslideshow/slides/up.php HTTP/1.1" 200 365 
[25/Jun/2016:12:01:14 +0200] "POST //modules/simpleslideshow/slides/up.php HTTP/1.1" 200 365 "http://www.ndd.fr//modules/simpleslideshow/slides/up.php" 
[25/Jun/2016:12:01:15 +0200] "GET //modules/simpleslideshow/slides/f.php HTTP/1.1" 200 1746 
[25/Jun/2016:12:01:18 +0200] "GET //modules/simpleslideshow/slides/f.php?path=/var/www HTTP/1.1" 200 989 "http://www.ndd.fr//modules/simpleslideshow/slides/f.php"
[25/Jun/2016:12:01:23 +0200] "GET //modules/simpleslideshow/slides/f.php?path=/var/www/ndd HTTP/1.1" 200 4075 "http://www.ndd.fr//modules/simpleslideshow/slislides/f.php"
[25/Jun/2016:12:01:32 +0200] "GET /wp-installation.php HTTP/1.1" 200 374 
[25/Jun/2016:12:01:55 +0200] "GET //modules/simpleslideshow/slides/f.php?path=/var/www/ndd/wp-content HTTP/1.1" 200 1192 "http://www.ndd.fr//modules/simplesl$
[25/Jun/2016:12:01:59 +0200] "POST //modules/simpleslideshow/slides/f.php?path=/var/www/ndd/wp-content HTTP/1.1" 200 1281 "http://www.ndd.fr//modules/simples$
[25/Jun/2016:12:02:02 +0200] "GET /wp-content/ HTTP/1.1" 403 423 
[25/Jun/2016:12:02:04 +0200] "GET /wp-content/The.php HTTP/1.1" 200 696

Vous pouvez voir dans mes logs le premier GET, puis le POST qui permet de créer le fichier f.php. Ce dernier, supprimé après l’attaque, de permet pas d’être retrouvé. Cependant, on peut voir que le pirate l’utilise pour créer le fichier wp-installation.php. Etc.

Notez aussi que le pirate à très bien pu exploiter plusieurs failles. Il est important de regarder les accès au serveur de manière chronologique. Si le pirate a utilisé un proxy, cela vous compliquera encore plus la tâche.

Une fois la faille corrigé, vous devez nettoyer le serveur. J’ai rédigé un article à ce sujet. Il date un peu mais les techniques sont toujours d’actualité.

Pour finir, quelques consignes afin que ça arrive rarement :

• gardez votre Prestashop à jour
• gardez vos modules à jour
• ayez un sys admin sous la main rapidement si vous n’avez pas de connaissance en gestion de serveur
• préparez vous à perdre quelques jours pour tout nettoyer
• gardez votre serveur sécurisé et à jour
• faites appel aux bonnes personnes lors de la création de votre site