mgrube/cve-2019-9673Writeup
NOTE: J'ai entièrement divulgué ce bug à l'équipe Freenet et travaillé avec eux pour vérifier leur correctif. Le correctif est maintenant déployé dans la dernière version de Freenet.
J'ai récemment découvert une vulnérabilité de sécurité dans Freenet qui pourrait permettre à un attaquant de désanonymiser une cible ou d'envoyer des documents malveillants via Freenet.
Cette vulnérabilité affecte les utilisateurs de Freenet qui utilisent Firefox comme navigateur. Elle permet la désanonymisation et d'autres comportements malveillants sur l'ordinateur d'un utilisateur. Elle est présente dans toutes les versions jusqu'à 1483.
Cet exploit fonctionne en tirant parti d'un décalage entre Firefox et Freenet dans la gestion des types MIME. Freenet est livré avec des filtres pour de nombreux types de contenu - un effort considérable a été déployé pour s'assurer que seul du contenu bien formé et non scripté peut être rendu sans un certain nombre d'avertissements à l'utilisateur.
Freenet fait généralement du bon travail en traitant les données comme il se doit et en permettant à l'utilisateur de spécifier s'il souhaite qu'elles soient traitées d'une autre manière.
Firefox, en revanche, est un peu plus nuancé dans la façon dont il détermine le type MIME d'un fichier. Plus précisément, comme documenté ici. La majeure partie du processus documenté sur cette page échappe au contrôle de l'attaquant, surtout s'il doit attaquer via Freenet. Une chose qui est à la portée de l'attaquant, cependant, est le type MIME des données insérées. Lorsque des données sont insérées dans le réseau Freenet, un utilisateur peut spécifier le type MIME - lorsque ce champ est laissé nul, les données sont traitées comme application/octet-stream et reçoivent tout le traitement approprié concernant les avertissements.
Cependant, en naviguant vers la section HTTP de la documentation Mozilla, nous voyons que Firefox fait en fait ses propres suppositions sur le type MIME des données lorsque certaines conditions ne sont pas remplies par l'application qui sert le contenu. Plus précisément, lorsque l'en-tête Content-Encoding n'est pas envoyé par une application, Firefox renifle en fait le contenu pour décider quoi en faire. Si le premier bloc de données n'est pas du texte, Firefox traitera le fichier comme le type MIME indiqué par l'extension.
Il s'avère que Freenet n'envoyait pas cet en-tête dans ses réponses, ce qui nous permet de transformer cela en quelque chose d'utilisable. Puisque nos données peuvent être insérées en tant que type MIME text/plain, qui ne reçoit évidemment pas de filtrage sophistiqué, mais peuvent être livrées comme n'importe quel type MIME indiqué par l'extension de fichier, nous avons maintenant un moyen de livrer un document HTML non filtré (ou PDF, ou .docx...). C'est un problème important car normalement tout contenu dangereux est recommandé pour téléchargement dans un dossier ou un espace temporaire et ouvert en dehors du navigateur.
Voici une courte vidéo de l'exploit en action - dans ce cas pour livrer un fichier HTML non filtré.
Pour un exemple fonctionnel, installez la version 1483 ou antérieure et accédez à :
Pour ceux qui souhaitent jouer à la maison, vous pouvez obtenir la version vulnérable la plus récente de Freenet ici.
Alors, comment pourrions-nous utiliser cela dans le monde réel ?
Il s'avère que si vous liez votre contenu malveillant dans Freenet sur une page déjà consultée par l'utilisateur, Freenet s'assurera de traiter le fichier comme le type indiqué par son extension. Freenet verra que notre premier bit de données est binaire et avertira l'utilisateur que notre fichier est malveillant.
:(
Cela signifie que si nous voulons que notre cible voie notre page malveillante avec du JS, nous devons y faire un lien externe. C'est en fait acceptable, car les systèmes de messagerie les plus populaires de Freenet ne fonctionnent pas depuis le proxy web de Freenet.
Si, par exemple, l'URI de démonstration dans cet article était liée dans FMS, il n'y aurait pas de vérification supplémentaire et nous pourrions faire exécuter notre charge utile.
Tout ce qui serait nécessaire pour désanonymiser un certain nombre d'utilisateurs de Freenet serait de créer un contenu avec un titre intéressant, d'insérer un fichier avec le premier bloc de données en binaire, puis de créer une page Web convaincante qui signale silencieusement l'adresse IP et l'activité en arrière-plan. Combinez cela avec une boîte à outils comme le framework BeEF et vous avez des opportunités intéressantes.
Nous pouvons, bien sûr, également utiliser cela comme vecteur pour livrer un PDF malveillant, .docx ou d'autres fichiers et obtenir un point d'appui plus permanent sur la machine de l'utilisateur.
Corriger ce bug est assez simple - désormais, FProxy passera toujours l'en-tête HTTP Content-Encoding lorsqu'il délivre du contenu. Cet en-tête indique au navigateur Firefox de traiter les types MIME explicitement comme définis par FProxy. En conséquence, les données de type text/plain seront toujours rendues en texte brut et non traitées comme tout autre type MIME.
Ce bug était, dans l'ensemble, assez simple - pourtant il avait la capacité d'impacter le fonctionnement de Freenet de manière majeure. La vérification des types MIME est vraiment importante et une leçon majeure à retenir de ce bug est que les types MIME ne sont pas toujours traités de manière cohérente lorsque les données sont passées d'un programme à un autre.
Insérez simplement des données dans Freenet avec le type MIME text/plain et le premier bloc contenant uniquement des données binaires. Firefox le traitera comme le type spécifié par l'extension de fichier et il sera livré directement à l'utilisateur au lieu d'être filtré par Freenet. Envoyez-le à vos victimes sur FMS ou Frost. Collectez leurs adresses IP ou faites-leur exécuter une charge utile binaire. Profitez-en !
