Faille de sécurité dans ProFTPd

Flattr this!

Je viens de découvrir l’existence d’une faille de sécurité de ProFTPd, documentée depuis plus d’un an, mais qui n’a visiblement pas été corrigée sous Ubuntu 14.04 LTS. Une faille plutôt intéressante, car elle montre comment une cascade de petits défauts de sécurité peuvent mener à une faille grave…

Tout a commencé par un petit contrôle de routine sur mon serveur. En effectuant un simple ls pour vérifier ce qui traîne dans /tmp, mon attention a été attirée par trois fichiers pour le moins étranges :

Le premier, comme son nom l’indique, est une copie du fichier /etc/passwd, les deux autres contiennent du code PHP dans leur nom… Louche, non ?

Le nom du propriétaire des fichiers laisse peu de doute sur leur origine, ils sont arrivés là via ProFTPd. Heureusement pour moi, le créateur de ces fichiers n’a pas fait preuve d’une grande originalité : une recherche sur passwd.copy m’a donné directement une description de la faille en question.

Concrètement, cette faille permet à un utilisateur non authentifié de copier des fichiers d’un endroit à un autre sur le serveur, via les commandes SITE CPFR (copy from) et SITE CPTO (copy to). Vérification faite, effectivement, mon serveur est bien vulnérable :

Vu comme ça, ça n’a pas l’air bien méchant… Mais l’inventeur de cette faille a eu quelques idées pour rendre la chose beaucoup plus méchante, si d’autres défaut de sécurité sont présents sur la machine…

Imaginons par exemple que l’attaquant connaisse le répertoire vers lequel pointe le DocumentRoot du serveur web (information qui peut parfois apparaitre dans les messages d’erreur de PHP par exemple…) et que le serveur ProFTPd s’exécute avec un compte utilisateur ayant le droit d’écrire dans ce répertoire. Il devient possible pour l’attaquant de copier un fichier dans ce répertoire, pour ensuite le télécharger via un simple navigateur web… D’où l’importance d’une bonne configuration des droits d’accès !

Heureusement, dans mon cas, les droits d’accès étaient correctement réglés :

Encore plus intéressant, l’inventeur a trouvé une astuce qui permet de créer un fichier contenant du code PHP exécutable… Pour ce faire, il commence par envoyer une commande SITE CPFR avec du code PHP à la place du nom de fichier. Cette commande provoque une erreur, puisque le fichier n’existe pas, et cette erreur est enregistrée dans le fichier de session de ProFTPd, avec le nom du « fichier » en erreur. Et hop, on n’a plus qu’à copier ce fichier de session vers un fichier PHP dans le DocumentRoot, et on peut exécuter le code… Je pense que c’est ce qu’à voulu faire mon attaquant mais qu’il s’est planté quelque part, d’où la création de fichiers dont le nom est du code PHP…

Maintenant qu’on a compris le principe de l’attaque, reste à s’en protéger. Avoir un DocumentRoot protégé en écriture contre l’utilisateur de ProFTPd est une chose, mais même sans ça, l’attaquant peut déjà faire pas mal de bêtises. À défaut de pouvoir exécuter le code PHP de son choix sur le serveur, il pourrait par exemple s’amuser à copier en boucle un fichier vers /tmp, jusqu’à remplir tout l’espace disque… Il n’est pas impossible non plus qu’il puisse parvenir à écraser un fichier existant… Une recherche rapide dans la doc de ProFTPd donne plusieurs solutions pour se protéger :

  • désactiver le module mod_copy, qui implémente les deux commandes incriminées, en commandant la ligne LoadModule correspondante dans le fichier /etc/proftpd/modules.conf :

  • désactiver les commandes SITE_CPFR et SITE_CPTO pour l’utilisateur anonyme dans /etc/proftpd/proftpd.conf :

  • désactiver toutes les commandes pour l’utilisateur anonyme dans /etc/proftpd/proftpd.conf (la commande LOGIN reste bien entendu accessible, pour quitter le mode anonyme…) :

Comme on n’est jamais trop prudent, j’ai pour ma part désactivé le module mod_copy et interdit toutes les commandes en mode anonyme.

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.