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 :

root@serveur:/tmp$ ls -l
total 148
[...]
-rw-r--r--  1 proftpd nogroup   1554 juin  28 18:30 passwd.copy
-rw-r--r--  1 proftpd nogroup     87 juil.  5 02:11 .<?php eval($_REQUEST[cmd]); echo GOOD;?>
-rw-r--r--  1 proftpd nogroup     80 juin  30 19:22 ...<?php passthru($_GET['img']);?>

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 :

root@serveur:/tmp# ftp localhost
Connected to localhost.localdomain.
220 ProFTPD 1.3.5rc3 Server (Debian) [::ffff:127.0.0.1]
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> SITE HELP
214-Les commandes SITE suivantes sont reconnues (* => non supportée)
214-CPFR <sp> pathname
214-CPTO <sp> pathname
214-UTIME <sp> YYYYMMDDhhmm[ss] <sp> path
214-SYMLINK <sp> source <sp> destination
214-RMDIR <sp> path
214-MKDIR <sp> path
214-The following SITE extensions are recognized:
214-RATIO -- show all ratios in effect
214-QUOTA
214-HELP
214-CHGRP
214-CHMOD
214 Envoyer les commentaires à root@ks212160.kimsufi.com
ftp> SITE CPFR /etc/passwd
350 Fichier ou répertoire existant, prêt pour le nom de destination

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 :

ftp> SITE CPTO /MON/DOCUMENT/ROOT/WWW/passwd.copy
550 cpto: Permission denied

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 :

root@serveur:~$ sed -i /etc/proftpd/modules.conf -e "s/^LoadModule mod_copy/# LoadModule mod_copy/"

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

<Anonymous ~ftp>
  [...]
  <Limit SITE_CPFR>
    DenyAll
  </Limit>

  <Limit SITE_CPTO>
    DenyAll
  </Limit>
  [...]
</Anonymous>

• 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…) :

<Anonymous ~ftp>
  [...]
  <Limit ALL>
    DenyAll
  </Limit>
  [...]
</Anonymous>

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.