Attaquer un client FTP : obtenir plus que prévu avec MGET

Introduction

On entend souvent parler de vulnérabilités dans les clients HTTP, comme les navigateurs Web, généralement exploitées par du contenu Web malveillant : rien de nouveau jusque-là. Mais saviez-vous que les clients FTP eux-mêmes peuvent aussi présenter des vulnérabilités exploitables ? Des serveurs malveillants auxquels les clients se connectent peuvent les cibler.

Dans cet article, je vais vous présenter une vulnérabilité intéressante de traversée de répertoires que nous avons identifiée et signalée de manière responsable à plusieurs fournisseurs concernés en novembre 2017. Cette vulnérabilité peut toucher plusieurs applications et bibliothèques, et permettre à un serveur FTP malveillant de créer ou d’écraser des fichiers n’importe où dans le système de fichiers local. Comme vous le verrez dans les détails ci-dessous, cette vulnérabilité découle d’une absence de validation. Elle concerne non seulement les clients FTP, mais aussi de nombreuses autres applications et bibliothèques dans différents écosystèmes, notamment Java, npm et d’autres.

La vulnérabilité

D’accord, examinons le problème ! Nous voulons coder une fonction qui télécharge le contenu d’un dossier FTP distant vers un dossier local. Comme la plupart d’entre nous le savent déjà, le protocole FTP ne propose pas de commande de téléchargement de dossier, mais nous pouvons combiner plusieurs autres commandes pour atteindre notre objectif.

Nous pouvons :

1. Lister tous les fichiers du dossier distant (commandes FTP LIST ou NLST)

2. Pour chaque fichier de la liste ci-dessus : télécharger le fichier et l’enregistrer dans un dossier local (commandes FTP GET ou MGET)

Voici à quoi pourrait ressembler un exemple de code Java effectuant cette opération avec la bibliothèque Apache commons-net :

1private void downloadDirectory(FTPClient ftpClient, String remoteDir, String localDir) throws IOException
2{
3  FTPFile[] subFiles = ftpClient.listFiles(remoteDir);
4  for (FTPFile aFile : subFiles)
5  {
6    if (!aFile.isDirectory())
7    {
8       String remoteFile = ftpClient.printWorkingDirectory() + File.separator + aFile.getName();
9       String localFile = localDir + File.separator + aFile.getName();
10
11       OutputStream downloadedStream = new BufferedOutputStream(new FileOutputStream(new File(localFile)));
12       boolean success = ftpClient.retrieveFile(remoteFile, downloadedStream);
13       outputStream.close();
14    }
15  }
16}

Le code ci-dessus parcourt chaque fichier renvoyé par le serveur et le télécharge dans un dossier de destination local. Par exemple, si le premier fichier du dossier distant s’appelle passwd et que notre dossier de destination local est /var/data/sync/, le fichier sera téléchargé sous /var/data/sync/passwd.

Mais que se passe-t-il si le serveur FTP devient malveillant et, au lieu de répondre à la commande LIST avec passwd, renvoie ../../../../etc/passwd comme nom de fichier ? Le code ci-dessus placera alors le fichier dans /var/data/sync/../../../../etc/passwd, écrasant de fait /etc/passwd avec le fichier nouvellement téléchargé.

Vous pourriez dire que ../../../../etc/passwd n’est pas un nom de fichier valide, et c’est vrai. Mais la RFC ne dit pas qu’il ne l’est pas. En théorie, elle reste neutre vis-à-vis du système de fichiers et laisse au client comme au serveur le soin de déterminer eux-mêmes ce qui est valide. Par exemple, la réponse d’un serveur FTP Windows à une commande LIST pourrait ressembler à :

1"05-26-95  10:57AM               143712 $LDR$",
2"05-20-97  03:31PM                  681 .bash_history",
3"12-05-96  05:03PM       <DIR>          absoft2",
4"11-14-97  04:21PM                  953 AUDITOR3.INI",
5"05-22-97  08:08AM                  828 AUTOEXEC.BAK",
6"01-22-98  01:52PM                  795 AUTOEXEC.BAT",
7"05-13-97  01:46PM                  828 AUTOEXEC.DOS",
8"12-03-96  06:38AM                  403 AUTOTOOL.LOG",
9"12-03-96  06:38AM       <DIR>          123xyz",
10"01-20-97  03:48PM       <DIR>          bin",
11"05-26-1995  10:57AM               143712 $LDR$",

Tandis que celle d’un système Unix ressemble à :

1"zrwxr-xr-x   2 root     root         4096 Mar  2 15:13 zxbox",
2"dxrwr-xr-x   2 root     root         4096 Aug 24  2001 zxjdbc",
3"drwxr-xr-x   2 root     root         4096 Jam  4 00:03 zziplib",
4"drwxr-xr-x   2 root     99           4096 Feb 23 30:01 zzplayer",
5"drwxr-xr-x   2 root     root         4096 Aug 36  2001 zztpp",
6"-rw-r--r--   1 14       staff       80284 Aug 22  zxJDBC-1.2.3.tar.gz",
7"-rw-r--r--   1 14       staff      119:26 Aug 22  2000 zxJDBC-1.2.3.zip",
8"-rw-r--r--   1 ftp      no group    83853 Jan 22  2001 zxJDBC-1.2.4.tar.gz",
9"-rw-r--r--   1ftp       nogroup    126552 Jan 22  2001 zxJDBC-1.2.4.zip",
10"-rw-r--r--   1 root     root       111325 Apr -7 18:79 zxJDBC-2.0.1b1.tar.gz",
11"drwxr-xr-x   2 root     root         4096 Mar  2 15:13 zxbox",

Il existe en réalité de nombreux autres formats de systèmes de fichiers. Voici la liste de ceux pris en charge par la bibliothèque apache commons-net :

1OS400, AS400, L8, MVS, NETWARE, NT, OS2, UNIX, VMS, MACOS_PETER

Le client FTP classique ne valide donc pas les noms de fichiers et les renvoie tels quels, laissant aux développeurs le soin de les valider. Inutile de dire que cette validation est souvent oubliée. Cela saute aux yeux quand on consulte des projets hébergés sur GitHub ou divers sites proposant des extraits de code et des exemples, comme StackOverflow et CodeJava.

Étude de cas : Apache HIVE

Apache Hive est un projet d’entrepôt de données reposant sur Apache Hadoop, qui permet de résumer, d’interroger et d’analyser des données. Hive propose une interface de type SQL pour interroger des données stockées dans diverses bases de données et divers systèmes de fichiers intégrés à Hadoop. Il permet notamment de copier des données depuis des serveurs FTP à l’aide de la commande COPY-FROM-FTP.

1COPY FROM FTP host [USER user [PWD password]] [DIR directory] [FILES files_wildcard]
2  [TO [LOCAL] target_directory] [options]
3
4options:
5  OVERWRITE | NEW
6  SUBDIR
7  SESSIONS num

En examinant le code, nous voyons l’appel retrieveFileList().

1/**
2* Run COPY FROM FTP command
3*/Integer run(HplsqlParser.Copy_from_ftp_stmtContext ctx) {
4  trace(ctx, "COPY FROM FTP");
5  initOptions(ctx);
6  ftp = openConnection(ctx);
7  if (ftp != null) {
8    Timer timer = new Timer();
9    timer.start();
10    if (info) {
11      info(ctx, "Retrieving directory listing");
12    }
13    retrieveFileList(dir);
14    timer.stop();
15    if (info) {
16      info(ctx, "Files to copy: " + Utils.formatSizeInBytes(ftpSizeInBytes) + ", " + Utils.formatCnt(fileCnt, "file") + ", " + Utils.formatCnt(dirCnt, "subdirectory", "subdirectories") + " scanned (" + timer.format() + ")");
17    }
18    if (fileCnt > 0) {
19      copyFiles(ctx);
20    }
21  }  
22  return 0;
23}

Dans la fonction retrieveFileList, le nom de fichier renvoyé par le serveur est ajouté au nom du répertoire sans aucune validation (name = dir + name;). Le fichier est ajouté à une file d’attente pour être téléchargé ultérieurement.

1void retrieveFileList(String dir) {
2  if (info) {
3    if (dir == null || dir.isEmpty()) {
4      info(null, "  Listing the current working FTP directory");
5    }
6    else {
7      info(null, "  Listing " + dir);
8    }
9  }
10  try {
11    FTPFile[] files = ftp.listFiles(dir);
12    ArrayList<FTPFile> dirs = new ArrayList<FTPFile>();
13    for (FTPFile file : files) {
14      String name = file.getName();
15      if (file.isFile()) {
16        if (filePattern == null || Pattern.matches(filePattern, name)) {
17          if (dir != null && !dir.isEmpty()) {
18            if (dir.endsWith("/")) {
19              name = dir + name;
20            }
21            else {
22              name = dir + "/" + name;
23            }
24          }
25          if (!newOnly || !isTargetExists(name)) {
26            fileCnt++;
27            ftpSizeInBytes += file.getSize();
28            filesQueue.add(name);
29            filesMap.put(name, file);
30          }
31        }

Plus tard, dans le thread de téléchargement, le fichier est extrait de la file d’attente et téléchargé depuis le serveur.

1java.io.File targetLocalFile = null;
2File targetHdfsFile = null;
3if (local) {
4  targetLocalFile = new java.io.File(targetFile);
5  if (!targetLocalFile.exists()) {            
6    targetLocalFile.getParentFile().mkdirs();            
7    targetLocalFile.createNewFile();
8  }
9  out = new FileOutputStream(targetLocalFile, false /*append*/);
10}

Une attaque possible consiste à remplacer le fichier authorized_keys SSH de l’utilisateur root, afin de pouvoir se connecter ultérieurement en tant que root. Imaginons qu’une instance Apache Hive se connecte à notre serveur FTP pour télécharger chaque jour des données marchandes. Pour mener cette attaque, nous modifierions notre serveur FTP afin qu’il renvoie au client des noms de fichiers malveillants comportant des chemins traversant les répertoires. Par exemple, nous pourrions répondre à une commande LIST avec ../../../../../../../home/root/.ssh/authorized_keys.

Lorsque Hive exécute cette instruction (en supposant qu’il s’exécute en tant que root), le fichier SSH authorized_keys de root sera remplacé par un fichier connu de l’attaquant.

1COPY FROM FTP remote.merchant.domain.com
2USER 'foo' PWD '***'
3DIR data/sales/in FILES  '.*'
4TO /data/sales/raw OVERWRITE

La vulnérabilité ci-dessus a été signalée de manière responsable à l’Apache Foundation. Voici la chronologie :

Les détails ont également été publiés dans la base de données CVE le 4/4/2018 pour le projet Apache Hive.CVE-2018-1315 : l’instruction « COPY FROM FTP » dans HPL/SQL peut écrire à n’importe quel emplacement si le serveur FTP est compromis :

• Gravité : Modérée

• Fournisseur : The Apache Software Foundation

• Versions concernées : Hive 2.1.0 à 2.3.2

• Description : Lorsqu’une instruction « COPY FROM FTP » est exécutée avec l’extension HPL/SQL de Hive, un serveur FTP compromis ou malveillant peut faire écrire le fichier à n’importe quel emplacement du cluster depuis lequel la commande est exécutée. En effet, le code du client FTP dans HPL/SQL ne vérifie pas l’emplacement de destination du code téléchargé. Cela ne concerne pas les utilisateurs hivecli et hiveserver2, car hplsql est un script en ligne de commande distinct qui doit être appelé différemment.

• Mesures d’atténuation : Les utilisateurs de HPL/SQL avec Hive 2.1.0 à 2.3.2 doivent effectuer la mise à niveau vers la version 2.3.3. Il est également possible de désactiver HPL/SQL par d’autres moyens.

Résumé

Nous avons montré comment une vulnérabilité présente dans certains clients et bibliothèques FTP est due à l’absence de validation correcte des données provenant du serveur FTP. Des problèmes similaires ont déjà été observés. Par exemple, en 2002, Steve Christey, Principal Information Security Engineer chez MITRE, a découvert que le problème touchait plusieurs clients FTP, notamment le client FTP natif de Linux et wget.

Il est essentiel de valider les entrées, et pas seulement pour des raisons de sécurité. En tant que développeur, il est facile de penser à la façon dont une personne ordinaire pourrait utiliser nos API, mais il est tout aussi important de s’attendre aux entrées imprévues que pourraient envoyer des attaquants. Lorsque vous traitez des listes de répertoires provenant de serveurs FTP, veillez à les valider en bloquant les noms de fichiers qui commencent par / ou qui contiennent ...