OVH Mutualisé : piratage et blocage de site WEB

il y a quelques jours, on m’a demandé de l’aide pour un site WEB WordPress piraté sur un OVH Mutualisé.
Pas mal de campagnes malicieuses ces derniers temps assez actives suite à des publications de vulnérabilités touchant WordPress :

Je ne connais pas trop la gamme mutualisé d’OVH.
Dans notre cas, sur le manager OVH du propriétaire du site des tickets « Blocage HTTP de votre site » sont créés automatiquement par OVH :

OVH_mutu_site_bloque

dedans est expliqué qu’un bot (Okillerd) scanne les sites WEB du mutualisé, si ce dernier détecte des anomalies de piratage, le site est mis hors ligne et un tiquet est créé.
Ainsi on voit la création d’une commande/processus semble-t-il crond, assez typique d’un piratage.
OVH_mutu_site_bloque_2

OVH offre un guide qui explique les étapes à suivre lorsque votre site est bloqué par Okillerd : Mutualisé : guide procédure fermeture pour hack OVH
Le blocage du site WEB se fait par une modification des permissions sur les fichiers du site.

Vous devez :

  • Nettoyer le site WEB
  • Remettre les permissions à partir de l’accès FTP par exemple.

Si une piratage à nouveau lieu, le bot reblocage le site, vous serez alors dans une boucle jusqu’à ce que ce dernier soit sécurité et que les piratages s’arrêtent.

OVH offre aussi un accès SSH pour le mutualisé (OUF!) : SshMutualise

Dans le cas observé, des Backdoor PHP ont été déposées sur le site.
On liste les derniers fichiers PHP créés triés par la longueur de ligne de code :

find . -type f -name "*php" -mtime -2 -exec wc -l {} \;|sort -n

OVH_mutu_site_bloque_3

Les pages avec 0 ligne sont des Backdoor PHP assez simple, puisqu’elle permettent d’exécuter du code sur le serveur.
Il suffit de supprimer ces pages PHP.

OVH_mutu_site_bloque_4

moins sympa, certaines pages PHP du site ont été modifiés, le même type de code a été ajouté en début de fichier.
J’ai nettoyé ces pages avec le code suivant :

for file in `cat file.txt` ; do echo $file ; sed -r -i 's/<\?php.*\{eval\(\$.*;\}\?>//g' $file ; done

OVH_mutu_site_bloque_5


Au niveau de l’origine de l’attaque, j’ai noté deux POSTS très suspicieux qui ont eu lieu avant les blocages du site par OVH :

xxxxx.com-14-09-2014.log.gz:78.46.203.72 xxxxx.com - [14/Sep/2014:07:19:40 +0200] "POST / HTTP/1.1" 200 35609 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.72 Safari/537.36"
xxxxx.com-14-09-2014.log.gz:78.46.203.72 xxxxx.com - [14/Sep/2014:07:19:41 +0200] "POST / HTTP/1.1" 200 35609 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.72 Safari/537.36"
xxxxx.com-14-09-2014.log.gz:78.46.203.72 xxxxx.com - [14/Sep/2014:07:19:41 +0200] "POST / HTTP/1.1" 200 35609 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.72 Safari/537.36"

xxxxx.com-21-09-2014.log.gz:78.46.203.72 xxxxx.com - [21/Sep/2014:01:30:33 +0200] "POST / HTTP/1.1" 200 35638 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.72 Safari/537.36"
xxxxx.com-21-09-2014.log.gz:78.46.203.72 xxxxx.com - [21/Sep/2014:01:30:34 +0200] "POST / HTTP/1.1" 200 35638 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.72 Safari/537.36"
xxxxx.com-21-09-2014.log.gz:78.46.203.72 xxxxx.com - [21/Sep/2014:01:30:34 +0200] "POST / HTTP/1.1" 200 35638 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.72 Safari/537.36"

Le useragent utilisé est un Firefox Windows alors que la machine 78.46.203.72 héberge un Apache Ubuntu, pas logique du tout.

Le POST a dû permettre d’exploiter une vulnérabilité sur WordPress ou une extension/thème non à jour.
Encore une fois, maintenez bien votre site, ses extensions/thèmes à jour, cela est vraiment important.

Il est possible de bloquer les POSTS sur la racine du site avec un fichier .htaccess du type :

<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_METHOD} ^(delete|head|trace|track|post) [NC]
RewriteRule ^/$ - [F,L]
</IfModule>

Comme vous pouvez le constater, il faut avoir une certaine habitude pour dé-véroler son site WEB.
Le mieux est donc :

  • repartir une sauvegarde précédent le piratage.
  • changer tous les mots de passe d’accès

Pour plus d’informations sur la sécurisation de son site WordPress, reportez-vous à la page : Sécuriser WordPress

et une liste de tutorials de sécurité WEB, sur la page : Apache : sécuriser son site WEB

Comment lire d'autres tutoriels de malekal.com ?

Si le site vous a aidé, svp, débloquez les bloqueurs de publicités, n'hésitez pas non plus à partager l'article ou le site sur les réseaux sociaux.

Pour pouvoir lire plus d'articles et tutoriels, utilisez le menu en haut du site. Plein d'articles et tutos utiles vous attendent !

Besoin d'aide ?

Posez votre question ou soumettez votre problème sur le forum malekal.com pour obtenir une aide efficace : Aller sur le forum malekal.com
(Visited 220 times, 1 visits today)

4 thoughts on “OVH Mutualisé : piratage et blocage de site WEB

  1. Concernant le blocage des posts, en général il est plutôt conseillé de fonctionner avec les directives Limit et LimitExcept.

    Ex dans ce cas pour un Apache 2.4 :

    Require all granted

    Require all denied

    Pour <2.4, utilisez Allow, Deny et Order à la place de Require all Granted/Denied

  2. yep, mais là tu bloques tous les POSTS donc on ne doit plus pouvoir se logguer sur le WordPress.
    Enfin ça doit être faisaible avec Directory ou Files.
    Ca mériterait un topic, ces directives sont intéressantes.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *