Compte MySQL 'root' @ 'localhost' non sécurisé accessible à distance?

Petit rappel: nous venons de voir notre système PBX piraté. Le serveur lui-même semble sécurisé (pas d'accès non autorisé à la console - SSH, etc.), mais les pirates ont réussi à injecter un nouvel utilisateur administrateur dans le logiciel PBX (FreePBX, soutenu par MySQL). Les journaux Apache impliquent que les pirates ont réussi à ajouter l'utilisateur sans utiliser l'interface Web (ou aucun exploit dans l'interface Web).

Maintenant, j'ai découvert depuis que MySQL fonctionnait sans mot de passe root (!!) et ouvertement lié à l'adresse IP externe (évidemment, je l'ai verrouillé maintenant). Cependant, le seul utilisateur de niveau racine dans MySQL était 'root'@'localhost'et 'root'@'127.0.0.1', qui n'auraient dû être accessibles que localement.

Voici donc ma question:

Existe-t-il un moyen d'usurper une connexion à MySQL afin qu'il permette la connexion à l'utilisateur 'root' @ 'localhost' à partir d'une adresse IP distante, SANS exécuter aucun autre exploit localement?

Pour référence, la boîte est Centos 5 (Linux 2.6.10) exécutant Mysql 5.0.95.

mysql security hacking

— TFk
source

Serait mieux adapté à ServerFault - offtopic ici.

— kapa

Je n'étais pas sûr - mon sentiment personnel était que, comme il s'agissait moins de problèmes de configuration / d'administration du serveur et plus d'essayer d'exploiter un bogue potentiel dans MySQL, il pourrait mieux convenir ici. Toutes mes excuses si les gens pensent que je suis sur le mauvais site / section pour cela.

— TFk

En fait, il appartient probablement à security.stackexchange.com

Vous dites que "le seul utilisateur au niveau racine était root @ localhost", mais y avait-il d'autres utilisateurs? Vous n'avez pas besoin d'un utilisateur de niveau racine pour ajouter un enregistrement. En outre, vous devriez rechercher des vulnérabilités dans FreePBX comme celle-ci .

— Marcus Adams

L'exploit de votre lien a été corrigé dans ma version FreePBX, mais oui, je conviens que les vulnérabilités FreePBX sont le point d'entrée le plus probable, sauf que je ne trouve rien dans mes journaux d'accès Apache cohérent avec l'une des vulnérabilités connues (non corrigées) . Bon point avec les autres utilisateurs - le seul autre utilisateur de la base de données était l'astérisque, qui a un mot de passe (non par défaut). Si tel était le point d'entrée, cela pointe à nouveau vers une vulnérabilité FreePBX (éventuellement inédite). Le "pas de mot de passe root" semblait juste un si gros trou, comparé à un nouvel exploit FreePBX non documenté. Par conséquent, ma question / poste.

— TFk

Réponses:

Non.

MySQL ne vous connectera jamais à un utilisateur avec la spécification d'hôte localhostou 127.0.0.1si vous ne venez pas du système local. Notez que cela couvre également la vulnérabilité de contournement d'authentification, CVE 2012-2122; la comparaison des mots de passe peut être trompée, mais pas la comparaison des hôtes.

Vous auriez besoin de quelque chose sur le système pour effectuer un proxy pour "tromper" la vérification de l'hôte source. Quelque chose comme phpmyadmin, ou un équilibreur de charge comme HAProxy fonctionnant devant le port TCP MySQL me vient à l'esprit.

— Shane Madden
source

C'est ce que je soupçonnais, ce qui signifie, aussi mauvais qu'un mot de passe root vide, ce n'était probablement pas l'exploit. Toujours bon d'avoir des opinions éclairées - Merci beaucoup.

— TFk

Le nom rootest créé par défaut et est très bien connu. La racine de valeur littérale n'a aucune signification dans le système de privilèges MySQL. Par conséquent, il n'est pas nécessaire de continuer avec le nom d'utilisateur root.

Vous devez changer rootle nom d'utilisateur pour autre chose afin que le monde extérieur ne puisse pas l'identifier (deviner) facilement, cela réduira les tentatives de piratage.

Par exemple: si vous avez un utilisateur comme root@ localhostqui est bien connu de tout le monde, les pirates essaieront de le connecter, vous devez le changer en quelque chose de spécifique comme admin_db_name@ localhostpour une meilleure sécurité.

Surveillez une variable d'état appelée Aborted_connectspériodiquement pour connaître la Refusedconnexion à votre serveur MySQL, elle devrait être 0 après la Flush status;commande et ne devrait pas augmenter davantage.

afficher le statut comme «Aborted_connects»;

— Mahesh Patil
source

Est-ce que «aucun accès non autorisé enregistré» inclut les tentatives d'échec de connexion? Sinon, ce pourrait être CVE 2012-2122 .

. valeur de retour.

— samuirai
source

Mon "accès non autorisé non connecté" était terriblement ambigu - je voulais dire qu'aucun attaquant n'avait réussi à obtenir l'accès de la console au serveur (par exemple via SSH). En outre, il semble que les versions de Centos ne soient pas affectées (< community.rapid7.com/community/metasploit/blog/2012/06/11/… ), mais certainement le genre de chose que je cherchais.

— TFk