Il y a deux catégories de problèmes dans ce type de scénario. Le premier est lié aux métadatas associés au fichier, comme le chemin et le nom de fichier. Ce sont généralement des données générées durant la phase de transport entre l'utilisateur et l'application au travers de la couche d'encodage multipart http. Ces données peuvent être modifiées de maniére à piégier l'application en surchargeant des fichiers critiques par exemple en stockant le fichier au mauvaise endroit. Il est donc nécessaire de valider les métadatas avec rigueur avant de les utiliser. L'autre catégorie de problème concerne la taille des fichiers ou du contenu. La plage des conséquences dépend de l'usage du fichier. Aussi, vous devriez analyser tout ce que fait l'application avec les fichiers et réfléchir à la maniére de gérer le processus et interprété son contenu.  

De ce fait, mettre en place un upload sans restriction est une trés mauvaise idée. Si ce préambule vous a donné d'en savoir plus sur ce sujet, je vous invite à lire tout le billet. Nous allons donc continuer plus en profondeur sur les implications d'un mécanisme d'upload qui n'est pas protégé et les éléments à prendre en compte pour tenter de le protéger.

Facteurs de risques

• L'impact de ce type de vulnérabilité est trés élevé, le code est suposé être exécuté sur le serveur ou du côté client. La probabilité de ce type de détection par l'attaquant est trés importante. Aussi la prévalence est de mise. Le résultat est une vulnérabilité critique avec ce type d'attaque.
• C'est important de vérifier le mécanisme d'upload de fichiers pour s'assurer du contrôle d'accès à la fonctionnalité en examinant le risque qu'il introduit de s'assurer de n'ouvrir cette porte qu'aux personnes voulues.
• Les attaques serveurs: un serveur web peut-être compromis via l'upload et l'exécution de commandes, parcourir le systéme de fichier, les ressources locales, attaqués d'autres serveurs ou encore utilisé les failles du serveurs et bien d'autres choses encore.
• Les attaques du côté client : l'upload de fichier compromis peut rendre un site web vulnérable par les attaques côté client du type XSS ou Cross-Site Content Hijacking
• L'upload de fichiers peut-être compromis pour exploiter d'autres failles d'une application notamment lorsqu'il faut pouvoir utiliser un serveur de confiance qui n'est pas accessible directement
• L'upload de fichiers peut introduire des vulnérabilités en utilisant des librairies d'applications qui possèdent des failles côté client (Ex Iphone ImageMagick a une faille appellé ImageTragick)
• L'upload de fichiers peut rendre inefficace des solutions de surveillance en temps réel comme l'antivirus de Symantec via l'unzip des fichiers rar.
• Des fichiers compromis peut incorporé des script shell unix, un virus windows, un fichier Excel peut contenir des formules dangereuse etc, c'est un canal important pour prendre la main sur la machine d'une victime dans le temps.
• Un attaquant peut-être capable de créer une page pour simuler le site afin de pouvoir récupérer les informations des utilisateurs
• Le système de stockage peut-être détourner à d'autre fin comme l'inclusion de logiciels illégaux, contenu pour adulte, etc. Données qui peuvent ensuite être utilisées par les réseaux criminels.
• L'upload de fichiers sensible doit pouvoir être fait uniquement par les personnes autorisées et personne d'autre.
• L'upload de fichiers doit encapsuler proprement les erreurs afin de ne donner aucun indice sur son fonctionnement interne (Chemin de fichier, message d'erreur trop explicite, etc)

Exemples

Attaques selon la pateforme d'application

• Upload de fichier *.jsp dans l'arborescence de l'application. Le code sera alors executé par l'utilisateur web.
• Upload de fichier *.gif qui lors du crop pourra exploité une faille dans la librairie de crop.
• Upload de gros fichiers, le service cessera de fonctionner par manque de place sur le disque.
• Utiliser un chemin ou nom de fichier compromis pour surcharger un fichier critique sur le systéme d'exploitation du serveur
• Upload un fichier contenant des données personnelles que d'autres utilisateurs pourront avoir accès
• Upload de fichier contenant des tags qui pourront être executé car afficher lorsqu'il sont affichés dans une page web
• Uploader un fichier rar qui une fois scanné par l'antivirus le désactivera et pourra prendre le control du serveur.

Attaques par d'autres canaux

• L'upload de fichiers *.exe dans l'arborscence de l'application (introduction de cheval de troie sur le serveur)
• L'upload de virus par le biais d'un fichier qui pourra infecter les machines des utilisateurs
• L'upload de fichier *.html dans le but d'utiliser des failles XSS.
• L'upload de fichier *.jpg contenant des objects flash permettant les attaques de type Cross-site Content Hijacking
• L'upload de fichier *.rar qui une fois scanné par l'antivirus le désactivera et pourra prendre le control du post client.

Faille dans les protections ou en contournant les méthodes

Refuser les fichiers par extensions

Ce type de protection peut-être contourner en :

• Trouvant les extensions qui ne sont pas présentes dans la liste et qui peuvent être executé sur le serveur, ou qui peuvent-être dangereux côté client (*.php5, *.pht, *.phtml, *.shtml, *.asa, *.cer, *.asax, *.swf, *.xap etc)
• Trouvant les failles dans la configuration du serveur web, notamment en parsant les fichiers avec une double extension par exemple
  • /file.jpg/index.php lorsque le fichier jpg contient le fichier php qui a été uploaded
  • Avec Apache, un fichier php peut-être exécuté par la technique file.php.jpg lorsque .jpg est autorisé
  • Avec IIS6 (Ou version antérieur) un script peut-être exécuté en utilisant l'une des méthodes ci-dessous:
    • En ajoutant un caractére ; avant l'extension autorisé soit file.asp;.jpg
    • En renomant les extensions de fichier de script vers une extension autorisé *.asp en *.txt par exemple dans un répertoire avec à la fin l'extension soit mettre le fichier dans le répertoire folder.asp\file.txt. Car sous windows il est possible de créer des répertoires en utilisation un ads (Alternate data stream). Et avec cette méthode un nom de fichier qui fini par "::$Index_Allocation" ou ":$i30:$Index_Allocation" fait que le mécanisme d'upload créer un répertoire en tant que fichier...
  • Changer le nom de lettre sous une forme capital par exemple *,asp en *.aSp"
  • Utiliser les fonctionnalités Windows 8.3 qui permet de remplacer les fichiers existant par leur nom cour (web.config devient web~1.con ou .htaccess sera remplacé par HTACCE~1
  • Trouver les caractéres qui seront converti en des caractéres plus utiles durant le processus d'upload, notamment avec l'usage des " et ' qui permet de modifier le comportement du filename fia le Content-Disposition filename='web"config' sera remplacé par web.config et remplacera alors ce fichier sensible...
  • Trouver les caractéres neutre aprés un nom de fichier espace et point sous windows et les slash dans un systéme linux. Ce sont des caractéres qui sont supprimés automatiquement mais ils peuvent avoir leur important pour remonter dans l'arborescence... comme test.php.\ par exemple
  • utiliser les caractéres de control comme le caractére null (0x00) aprés une extension interdite et avant une extension autorisée qui permet de passer outre l'interdiction. 
  • Utiliser le mécanisme ADS avec NTFS, permet l'usage du caractére : ce qui permet de créer des effets inattendu :file.axax:.jpg
  • Des failles dans les protections de sécurité qui remplace les extensions dangereuses.
  • des failles avec l'utilisation du php et les include et permet de montrer les images qui ont été uploadé
  • Une combinaison de l'ensemble de ces techniques ci-dessus.

Faille avec getimagesize()

Cette méthode vérifiera lorsque c'est une image si le type mime est bien une image. De fait :

Une configuration non sécurisé :

<FilesMatch ".+\.ph(p([3457s]|\-s)?|t|tml)">  SetHandler application/x-httpd-php  </FileMatch>

Une configuration sécurisé :

 <FilesMatch ".+\.ph(p([3457s]|\-s)?|t|tml)$">  SetHandler application/x-httpd-php  </FileMatch>

Si la configuration n'est pas sécurisé, il est possible d'upload un gif compromis. Notamment sur ubuntu il est possible d'installer un outil gifsicle :

sudo apt-get install gifsicle

qui insérera des commentaire dans le gif. Pour cela, il suffit de saisir la ligne de commande : gifsicle < mygif.gif -- comment " et lorsque le php affichera l'image : 

<?php echo ‘Current PHP version: ‘ . phpversion(); ?>

” > output.php.gif

Autorisé uniquement un liste d'extensions

Les applications qui vérifient les extensions selon une liste prédéfinie ont besoin du nom complet du fichier pour gérer cette protection.

• La liste des extensions autorisées devrait être ajusté afin de ne pas contenir également les extensions compromises, par exemple un .shtml rend l'application vulnérable aux attaques ssi,
• Il existe des techniques pour contourner les restrictions à partir d'une liste notamment avec la méthode des doubles extensions.

Validation du Content-Type

Le header content-type indique à la requête le type de média et de contenu du message. Quelque fois les applications web utilise ce paramétre pour reconnaitre ceux qui sont valide. Ainsi certains, ne vont accepter que le "text/plain"

Remarque: C'est possible de contourner ce type de protection en utilisant un paramétre dans le header via un proxy web....

Utiliser un détecteur de type de fichier

Que ce soit voulu ou non les fonctions d'api doivent parfois vérifier le type de fichier pour s'assurer de pouvoir effectuer les opérations demandées. Notamment lors du besoin de redimensionner une image, il est s'assurer que c'est une bien une image dont il est question. Or ici il faut faire attention à :

• les premiers caractéres qui sont lus peuvent-être contourné en inserant un header valide ou via les métadata du fichier
• Insérer du code dans les sections de commentaires qui ne sont pas gérer sur le fichier de base peuvent amener à des contournements
• Insérer des données pouvant être masqué ou encodé si l'application détecte le code compromis en utilisant des motifs ou des signatures
• Uploader des fichiers avec du code compromis par les mécanismes de compression.

Autre cas à prendre en compte

• Uploader un fichier quand un autre fichier à déjà le même nom, cela fournir des messages intéressant pour mieux comment est fait le systéme et pouvoir par la suite le contourner
• Uploader un fichier lorsqu'un autre répertoire a le même nom, produit les mêmes circonstance que le point ci-dessus.
• Uploader un fichier avec un nom trop long permettra potentiellement d'avoir des messages d'erreurs détaillés
• Uploader un fichier plusieurs fois en même temps
• Uploader des fichiers valide et avec des formats invalide montrera parfois les messages d'erreurs détaillés
• Uploader des fichiers xml peut amenéer à lancer des traitements côté serveur
• Uploader des fichiers avec des noms réservé con, nul,com1, com2, etc, lpt1, etc.
• L'exploitation de failles Cross-site
• uploader un fichier crossdomain.xml ou clientaccesspolicy.xml