Wordpress site piraté à plusieurs reprises
En raison de l'identité du site Web, je ne souhaite pas fournir trop d'informations d'identification sur l'organisation réelle, mais je peux essayer de fournir autant d'informations de base que possible sur le serveur.
Je gère un site de presse Word et tout semblait aller bien jusqu'en août dernier, lorsque le site a été piraté pour la première fois. En raison de la quantité de fichiers compromis, il est apparu qu'il existait une sorte de vulnérabilité qui permettait à un robot d'injecter en masse du code dans tous les fichiers php. Avant chaque balise d'ouverture <php?, il y avait un bloc de code chiffré que j'ai montré ici .
Le lien ci-dessus montre le code php rangé, décrivant le flux de travail du script. Si je tente plus avant de décoder les chaînes, cela devient plus lisible, mais il semble très difficile de discerner exactement ce que ça fait.
Here est un peu décodé avec l'outil "Eval + gzinflate + Base64" de unphp et ici est un mais décodé avec l'outil "récursif de-obscurcissement" de unphp qui semble être un html publicité pour le site Web de quelqu'un d'autre.
Le contenu, cependant, est relativement peu important. Après ce piratage initial, j’ai restauré à partir d’une sauvegarde sur github et j’ai veillé à ce que le site ne contienne aucun script. J'ai également créé un nouvel utilisateur avec un nouveau mot de passe et changé le fichier racine du domaine en ce nouvel utilisateur.
Je pensais que cela résolvait le problème, mais le site Web a été piraté de manière très similaire deux fois de plus. Chaque fois que j'ai eu recours à une sauvegarde de Github et que je me suis assuré que le répertoire était propre.
Au début, je pensais que les hacks étaient en corrélation avec les mises à jour de presse Word et qu’il s’agissait de vulnérabilités Wordpress. Je me suis donc assuré de maintenir le site à jour en termes de mises à jour Plugin et Wordpress. En fin de compte, cela semble ne pas être le problème.
OS: Debian 3.1.9
Fournisseur d'hébergement: Dreamhost
Il convient également de noter que j'ai hérité de l'administration du site de quelqu'un, il existe donc une grande partie du code hérité qui est un peu bâclé.
tl; dr Ma question est comment puis-je diagnostiquer cela? Quelles mesures puis-je prendre pour trouver la source de la vulnérabilité? Je suis vraiment désemparé en ce moment et vraiment frustré que cela continue.
Merci pour tout conseil ou soutien que vous pouvez offrir, je suis désespéré à ce stade.
METTRE À JOUR:
Depuis ce temps, j'ai tenté une restauration. Environ deux heures après, le site était compromis de la même manière. Les différences cette fois-ci sont que j'avais sécurisé toutes les autorisations de fichiers et supprimé un utilisateur suspect de la table wp_user. Clairement, aucune de ces choses n'a semblé aider.
Plusieurs points à vérifier lors de l’auto-hébergement de WordPress:
- Vos plugins sont-ils en sécurité? Les avez-vous obtenus dans le référentiel wordpress.org ou ailleurs? Si ailleurs sont ces bons développeurs (par exemple, Gravity Forms) ou quelque chose qui n’est pas lié à Envato/Themeforest?
- Les mêmes questions sur votre thème. D'où vient-il? At-il été minutieusement vérifié pour les problèmes de sécurité avec le plugin Theme Check et autres?
Les deux questions couvrent la majorité des problèmes de sécurité générés par WordPress. C'est presque toujours un plugin ou un thème mal codé (ou parfois un avec une porte dérobée délibérée) qui est le vecteur de l'attaque. Mis à part non seulement l'installation d'un thème ou d'un plugin aléatoire et la recherche de tout le reste, je vous recommande fortement d'installer BruteProtect (bientôt livré avec Jetpack) et WordFence . Les deux sont gratuits et vous aideront à vous protéger. Si vous voulez/pouvez dépenser de l'argent, un abonnement à Sucuri (en particulier leur produit pare-fe ) ou StopTheHacker ira encore plus loin pour empêcher les attaques de style drive-by.
Comme l’indiquent les autres réponses, il se peut que la sécurité du serveur soit mauvaise. Si l'attaquant peut compromettre un utilisateur du shell, toutes sortes de méchancetes en découlent et WordPress, en raison de sa popularité, devient la cible d'attaques basées sur des scripts, car vous êtes pratiquement assuré de tirer le meilleur parti d'un script ciblant WordPress. Si votre serveur est cloué encore et encore, peut-être qu'il est temps d'envisager un basculement dans l'hébergement? Les hôtes WordPress dédiés (y compris l'offre propre de Dreamhost, WP Engine, Rackspace, Page.ly, Synthesis) se chargent de la sécurité pour vous en contrepartie d'une augmentation des frais mensuels et pour certaines personnes, c'est vraiment la meilleure option.
Honnêtement, il peut y avoir un vrai virus sur votre site. Celles-ci existent uniquement pour pirater Wordpress sites Web et aucune réinstallation ni redéploiement ne l'empêchera de se lancer dans une analyse antivirus complète, y compris le rootkit, et éventuellement de nettoyer le disque dur et de recommencer si nécessaire.
De même, assurez-vous que TOUS de votre logiciel est entièrement à jour, en particulier Wordpress. Wordpress est le logiciel le plus piraté qui soit. Aucun ne vient près. Assurez-vous également que tous les services inutiles sont arrêtés et qu'il n'y a pas de ports ouverts, sauf ceux que vous souhaitez. FTP et DNS sont particulièrement dangereux en raison d'attaques par réflexion. Cela ne signifie pas que vous ne pouvez pas les utiliser, assurez-vous simplement de les avoir en prison si possible et à jour.
Il y a de bonnes chances que le problème n'ait rien à voir avec un utilisateur/login, mais avec les permissions définies pour les fichiers. Si un fichier php a trop de droits et qu'il sait en abuser, vous avez une violation comme vous l'avez décrite.
Dans les paramètres normaux, les répertoires doivent être 0755 et les fichiers 0644.
Répertoires dont le contenu est modifiable (il faut y placer des fichiers) 0777 et fichiers 0666.
Assurez-vous également que tous les fichiers ont les propriétaires appropriés (par exemple: NEVER root).
Quelques commandes (peut-être) pratiques pour la ligne de commande/Shell:
find -type d -exec chmod a+x -R {} \; // set dirs +excecute
find -type f -exec chmod a-x -R {} \; // set files -excecute (only dirs are exce.)
find -type f -exec chmod a-w -R {} \; // set files -writable/changeble
chmod a+rw -R ./somedir // will set all files and dirs (read- and) writable
chown username.username -R ./somedir // will set ALL owners to username
En outre, il existe divers outils et sites décrivant comment vous verrouillez votre site WP, quels fichiers sont vulnérables, etc. Je ne suis pas un WPer moi-même, mais nous hébergeons quelques WP sites.
J'ai eu WordPress sites sur Dreamhost également piratés. J'utilisais leur forfait d'hébergement partagé, et je suppose que vous l'êtes également. Les pirates sont arrivés en compromettant un autre utilisateur sur le serveur, puis en lisant mon wp-config.php (qui avait les autorisations 0644, lisible par tout le monde), en accédant à la base de données et en créant leur propre utilisateur administrateur dans le wp_users table. Une fois qu’ils sont administrateurs, il leur est beaucoup plus facile de trouver un moyen d’exécuter le code PHP en tant qu’utilisateur (installer des plugins, écrire dans les fichiers de thème, etc.).
Étant donné que Dreamhost fonctionne sous suEXEC/suPHP (en tant qu'utilisateur que vous utilisez pour FTP), vous pouvez modifier les autorisations sur le wp-config.php en 0600 ou 0640 . Je voudrais également modifier les autorisations de votre répertoire personnel pour interdire à tout utilisateur d’en répertorier le contenu, ce qui est probablement la façon dont il l’a trouvé en premier lieu. Donc, chmod 710 ~. Vous remarquerez peut-être que Dreamhost dispose d'autorisations similaires sur le répertoire /home puisque vous ne pouvez pas utiliser ls /home. Les hackers peuvent cependant faire cat /etc/passwd pour obtenir une liste d'utilisateurs à cibler, ce qui est probablement la façon dont ils ont trouvé le vôtre. Vous devriez également vérifier si des clés SSH sont installées dans ~/.ssh/authorized_keys (il y en avait pour moi, c'est comme cela qu'elles se sont produites une seconde fois).