Que pourrait faire un pirate avec mon wp-config.php

11

J'essaie de sécuriser mon blog wordpress. J'ai lu quelques articles sur le Web que je devrais changer table_prefixet cacher wp-config.php. Cependant, je ne comprends pas? Que pourrait faire un attaquant avec moi wp-config.php?

Je veux dire qu'il y a mes configurations de base de données, mais l'attaquant a besoin de ma DB_HOSTpar exemple, qui n'est pas si facile à obtenir, pour se connecter à ma base de données? (Dans mon cas define('DB_HOST', 'localhost');, c'est:, que l'attaquant ne pouvait pas utiliser pour se connecter à ma base de données )

Ou me manque-t-il?

J'apprécie vraiment ta réponse!

plugins security wp-config

— Kare
source

Je suppose que ce sera facile pour lui d'injecter du SQL. Étoile. En attente de réponses d'experts.

— Robert hue

Vous pouvez également le publier sur Programming Puzzles & Code Golf beta et voir ce que les gens proposent. :)

— Joshua Taylor

1

@JoshuaTaylor S'il vous plaît non. Mis à part les problèmes éthiques évidents, ce n'est pas l'objet de notre site: nous aimons seulement les questions qui peuvent avoir un critère de gain objectif pour décider quelle solution gagne, pas seulement "Hé, écrivons tous du code et amusons-nous! Yaaaay!"

— Poignée de porte

@ Doorknob Eh bien, ce serait évidemment un concours de popularité. Mais sérieusement, j'espérais que le ":)" signifierait que je n'étais pas sérieux. Si quelqu'un a essayé de publier ses fichiers wp-config en conséquence, veuillez accepter mes excuses.

— Joshua Taylor

9

localhostfait référence à la machine sur laquelle il tourne. Par exemple, sur mon propre site, tomjn.com localhost est 127.0.0.1comme il est toujours. Cela ne signifie pas que le pirate ne sait pas où se connecter, cela signifie que le pirate remplace localhostpar tomjn.com.

Bien sûr, si j'ai un proxy devant, cela ne fonctionnera pas, mais gardez à l'esprit que si l'attaquant a accès à mon wp-config.php, ce même accès leur permettrait de faire d'autres choses sur cette machine.

Alors maintenant, l'attaquant a les détails de votre base de données, et ils peuvent lire wp-config.php. Ils ont désormais accès à tout dans votre base de données et peuvent tout changer dans votre base de données.

Selon la sécurité de votre installation, ils peuvent créer un utilisateur pour eux-mêmes, se connecter, télécharger un plugin via zip avec un script PHP Shell et commencer à émettre des commandes ou utiliser le site dans le cadre d'un réseau de robots.

Ils ont également vos sels et vos clés secrètes (si vous n'en avez pas, mauvais mauvais mauvais), donc le forçage brutal des mots de passe de vos utilisateurs devient beaucoup plus facile. Ils ont également accès à leurs e-mails.

Il suffit de dire qu'obtenir wp-config.phpest l'une des pires choses qui puisse arriver. Beaucoup plus de choses peuvent être faites avec mais il faudrait des mois pour taper toutes les attaques possibles qui en découlent.

Dans le cas où votre wp-config.phpest acquis, il est probable qu'un script d'attaque automatisé l'ait fait, pas une personne réelle. Modifiez toutes vos informations, réinitialisez tous les mots de passe et fermez le trou.

— Tom J Nowell
source

2

Cela ne signifie pas que le pirate ne sait pas où se connecter, cela signifie que le pirate remplace localhostpar tomjn.com. > Cela suppose que vous avez le port de la base de données accessible au monde extérieur. Ne seriez-vous pas en sécurité si vous fermiez le port dans les règles de pare-feu, autorisant uniquement les ordinateurs du réseau local (y compris l'ordinateur exécutant wordpress lui-même) à se connecter à la base de données?

— IQAndreas

1

Ce serait toujours le bon emplacement, mais oui les ports sont pertinents, je visais principalement la note originale dans la question

— Tom J Nowell

2

Si vous acceptez uniquement l'accès à la base de données à partir de localhost(cela ne se fait pas en définissant DB_HOSTcomme localhost)? Pas trop par lui-même (le pire des cas serait un attaquant prenant le compte administrateur), mais en combinaison avec d'autres vulnérabilités, il pourrait être utile pour un attaquant d'avoir accès à votre configuration.

Identifiants de connexion

Les gens réutilisent leurs noms d'utilisateur et mots de passe. Un attaquant vérifiera si le nom d'utilisateur et le mot de passe de votre base de données (ou des variantes de ceux-ci) fonctionnent pour votre installation wordpress, pour votre hébergeur, pour votre e-mail, etc.

À tout le moins, un attaquant a une idée du type de mots de passe que vous utilisez (totalement aléatoire, uniquement en minuscules / chiffres, longueur, etc.).

Préfixe de table

S'il y a une injection SQL possible, un attaquant doit connaître les noms des tables. Selon la base de données, cela peut être très simple ou impliquer des devinettes. Si cela implique de deviner, il est préférable d'avoir le préfixe de table.

Clés et sels

J'ai trouvé cet article suggérant que vous ne vouliez vraiment pas que ces fuites (en gros, n'importe qui puisse prendre le contrôle de votre compte administrateur), bien que je ne sache pas à quel point il est à jour.

Base de données Charset

Certaines injections SQL dépendent du jeu de caractères, il est donc bon pour un attaquant de le savoir.

Résumé

Si vous n'autorisez pas l'accès extérieur à la base de données, si vous ne réutilisez pas les mots de passe et si vous n'avez aucune injection SQL n'importe où, la principale inquiétude serait la clé et les sels.

— Tim
source

Cet article est suffisamment à jour. Vous ne voulez pas que vos sels et vos clés fuient. Ce sont des informations privées. Si vous pensez même qu'ils ont été mis à disposition, modifiez-les immédiatement en un autre ensemble de données aléatoires. Il n'y a pas vraiment d'inconvénient à les modifier, cela vous déconnectera simplement du site Web et vous devrez vous reconnecter. Vous pouvez obtenir un nouvel ensemble aléatoire de clés et de sels ici: api.wordpress.org/secret-key/1.1/salt

— Otto

1

Je suppose que vous posez des questions sur l'accès en lecture, car l'accès en écriture est essentiellement un accès pour injecter son propre code pour faire tout ce qu'il veut avec votre site.

Votre hypothèse selon laquelle les informations DB ne sont pas sensibles est fausse. Supposons que votre site soit hébergé chez godaddy. godaddy AFAIK utilise des serveurs mysql dédiés qui ne sont probablement accessibles que depuis leurs propres serveurs, mais si je connais vos coordonnées, est-ce difficile pour moi de créer un compte godaddy et d'écrire un script qui accède à votre base de données? Dans le cas de bases de données locales, il est plus difficile à exploiter, mais sur des serveurs d'hébergement partagé, vous pouvez avoir 100 sites partageant le serveur avec vous, pouvez-vous leur faire confiance pour être suffisamment sécurisés pour que M. Evil ne puisse pas les pénétrer et les utiliser pour attaquer votre site?

— Mark Kaplun
source