Avec PiRogue, capturer le trafic HTTP(S) d'un smartphone devient plus simple

Avec PiRogue, capturer le trafic HTTP(S) d’un smartphone devient plus simple

MITM, moi non plus

Avatar de l'auteur
Guénaël Pépin

Publié dans

Internet

27/03/2018 8 minutes
30

Avec PiRogue, capturer le trafic HTTP(S) d'un smartphone devient plus simple

Brancher un boitier, connecter son smartphone à un réseau Wi-Fi et obtenir tout le trafic des applications qu'il porte. C'est ce que promet PiRogue, un projet tout juste sorti de l'œuf, qui veut simplifier la mise en place d'un proxy captant ce que reçoit et envoie un appareil. La première brique d'un système qui pourrait avoir de grandes implications.

Vous avez toujours voulu savoir ce que votre smartphone envoie sur Internet, mais pas de connaissance technique ? Le projet PiRogue pourrait être pour vous. Avec un Raspberry Pi et une distribution Linux à la configuration simplifiée, il ambitionne d'ouvrir cette activité au plus grand nombre. Il suffit de connecter le mini-PC à Internet, pour qu'il génère un réseau Wi-Fi ouvert, auquel se connecte l'appareil ciblé.

À son origine, la chercheuse indépendante Esther, qui mène déjà la conception de la plateforme d'analyse de pisteurs Exodus Privacy, sortie en novembre (voir notre entretien). « C'est une idée née quand j'ai commencé les cafés vie privée, il y a environ un an. Il y a une énorme barrière technique pour prendre conscience de l'envoi de données par les applications vers des serveurs tiers, voire du fait qu'elles sont connectées à Internet » nous explique Esther.

Tout part d'un Raspberry Pi 3 et de « mitmproxy », un proxy capable d'intercepter le trafic HTTP(S). La démarche : installer la distribution Kali Linux (conçue pour la recherche en sécurité) sur une carte SD, brancher le mini-ordinateur en Ethernet ou en Wi-Fi, puis télécharger et exécuter un script de configuration contenant quelques commandes « triviales pour des personnes administratrices système ». « Je n'ai fait que mettre du papier cadeau » assure encore Esther, qui propose une édition avec boitier dédié et écran.

Un objectif, « lever le maximum de barrières techniques »

Le projet est tout jeune. Publié il y a deux semaines, il est le fruit de trois weekends de travail, dont un pour la conception mécanique du boitier imprimé en 3D (aux plans fournis librement).  Il descend d'HotSpoot, un chaudron connecté utilisé par Esther en conférence.

« Il s'illumine de couleurs différentes en fonction des sites visités par les participants à la conférence, rappelle-t-elle. Je l'utilise en café vie privée pour mettre en lumière ces fameuses communications auxquelles on ne s'attend pas forcément. » PiRogue suit aussi le travail sur un routeur 4G et Wi-Fi, aussi à base d'un Raspberry Pi.

Le projet se destine aux personnes assez techniques pour vouloir analyser l'activité réseau d'un appareil, ne sachant pas administrer un tel proxy. Le but : « lever le maximum de barrières techniques, comme la création d'un réseau Wi-Fi, l'attribution des adresses IP via un DHCP, la redirection du trafic vers mitmproxy en jouant avec le pare-feu... ». « Il n'y avait pas grand-chose à faire pour rendre l'opération beaucoup plus accessible » pondère-t-elle

Une telle capture est déjà possible sur Android, via des applications dédiées, dont certaines demandent de « rooter » l'appareil pour obtenir les droits d'administration.  « C'est une première barrière. Puis, analyser des traces réseau sur un smartphone, ce n'est pas très folichon » estime encore la chercheuse. Par ailleurs, passer par son propre PC peut mener à bien des déconvenues en cas d'erreur de configuration.

Dans une vidéo, elle montre l'utilisation de l'outil via une invite de commandes. Créer un réseau Wi-Fi ouvert avec « mitmproxy » ne demande pas de manipulations complexes, la configuration étant prémâchée. À noter qu'il intègre mitmweb, une interface web pour visualiser le trafic en cours de capture.

Un jeune projet, une version vendue à prix coûtant

« C'est un projet tout jeune, je ne garantis pas qu'il n'y a pas de plâtre à essuyer » martèle Esther. Nous avons pu le constater sur un Raspberry Pi 2, qui a bloqué sur la configuration via une connexion SSH. Elle a par contre bien fonctionné sur un Raspberry Pi 3. Comptez tout de même deux heures pour tout installer. Notez aussi qu'un service se plaindra en permanence en l'absence du petit écran prévu.

Pour limiter certains de ces problèmes, Esther compte bientôt livrer une image complète, préconfigurée. Même si cela demandera plus de maintenance de sa part. Enfin, lors d'événements, elle vend le boitier préparé, à prix coûtant soit environ 64 euros.

Elle l'utilise actuellement dans le cadre d'Exodus Privacy, pour analyser l'activité de certaines applications. Même si, au fond, « PiRogue, c'est pour m'amuser ».

Des limites dans l'analyse du trafic

Malgré l'avancée que pourrait représenter le projet, il souffre de limites inhérentes à ses outils. Pour capter le trafic chiffré (HTTPS) d'un appareil, mitmproxy requiert l'installation d'un certificat spécifique sur celui-ci. Le « MITM » fait référence à l'attaque de l'homme du milieu, où l'attaquant se place entre Internet et sa cible.

Mais une application peut  se prémunir de cette attaque : « Si elle fait du certificate pinning, c'est-à-dire qu'elle vérifie en dur qu'elle dialogue avec le serveur attendu, elle ne fonctionnera pas avec mitmproxy au milieu » explique Esther, qui trouve surtout ce comportement sur les applications bancaires. La logique est similaire à HSTS pour les sites web.

L'autre grande limite est que mitmproxy ne capte que le HTTP(S). La majeure partie des applications dialoguent avec des interfaces de programmation (API REST) par ce biais. D'autres passent par des outils autres, comme Protobuf de Google ou MQTT, un protocole très léger d'abord conçu pour l'Internet des objets industriel, exploité par Facebook.

Enfin, le HTTP(S) n'est qu'une partie d'un trafic plus global. « On peut lui adjoindre Wireshark, qui récupère l'intégralité du trafic, comme l'UDP ou les requêtes DNS, qui font partie de l'activité réseau mais passeront sous le radar de mitmproxy » note notre interlocutrice.

La première étape d'un plus grand outil

Le projet ne serait que la première brique d'un système plus large, qui devrait se construire au fil des mois. L'idée s'est matérialisée lors de discussions entre Esther et la consultante en sécurité Rayna « MaliciaRogue » Stamboliyska. Cette dernière cherche un moyen simple, accessible et reproductible de capturer le trafic d'objets connectés (Bluetooth et Internet). Son point de départ : les sextoys connectés et l'Internet des objets à visée médicale, à la sécurité fréquemment défaillante.

« L'idée centrale est la reproductibilité scientifique. Je veux que ma méthodologie, pour le recueil des données et leur traitement soit stable » nous explique-t-elle. Or, jusqu'ici, pour capturer le trafic Bluetooth, elle se voyait plutôt passer par des smartphones reconditionnés.

« Le problème de départ est la difficulté d'émuler du Bluetooth et de simuler le comportement d'un objet connecté à un smartphone. On y arrive, mais c'est du bricolage et les résultats sont plutôt médiocres. Bien sûr, acheter un smartphone reconditionné est une solution, mais c'est un objet avec plein d'autres fonctionnalités. Donc, le risque d'effets secondaires existe. Cette approche a un coût, notamment si on commence à réfléchir à des analyses iOS : même reconditionnés, les iPhone restent onéreux. La conclusion est qu'on a un tas de plateformes Android différentes et donc, la reproduction des résultats est compliquée », estime-t-elle.

Le travail d'Esther contribue ainsi à créer une infrastructure à bas coût, mobilisant des logiciels et du matériel open source. Une garantie importante, pour Rayna Stamboliyska. « L'objectif est de donner un outil simple au plus grand nombre » nous assure-t-elle. À terme, la capture de flux Bluetooth via de nouvelles versions du protocole ne pourrait requérir qu'un changement de clé sur un Raspberry Pi.

Pour la gestion des données collectées, elle s'inspire du modèle récemment présenté par le chercheur belge Xavier Mertens dans une conférence (PDF). Il y détaille un processus, à base de logiciels libres, pour exploiter des données de supervision réseau (PCAP). Pour Rayna Stamboliyska, la technique est adaptable à bien des sujets.

Elle voit ainsi des débouchés dans l'étude de la sécurité d'objets connectés ou des changements concrets dans des applications. Bien souvent, les développeurs se contentent de déclarer la « correction de bugs mineurs », alors que des modifications importantes peuvent être appliquées, comme le retrait de pisteurs ou l'ajout de portes dérobées. Pour la consultante, un outil comme PiRogue aide à automatiser l'analyse des échanges réseau, pour déceler de nouveaux comportements. Tout cela « se fera au fur et à mesure », nous répond Esther, sans contrainte de calendrier.

Écrit par Guénaël Pépin

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Un objectif, « lever le maximum de barrières techniques »

Un jeune projet, une version vendue à prix coûtant

Des limites dans l'analyse du trafic

La première étape d'un plus grand outil

Commentaires (30)


intéressant. je vais peut-être voir pour essayer de mettre ça en place sur un pi2 .

sinon, j’achèterai le matériel indiqué dans le github, ça a l’air trivial comme montage.


ça a l’air intéressant, tant que ça rame pas trop …

<img data-src=" />


C’est INpresionnant. Bravo.<img data-src=" />


Projet vraiment très intéressant sur lequel je me pencherais à l’occasion, l’idée de voir le trafique passant me titille depuis un moment, ça va bien me faciliter la tâche, merci Esther !


Excellent pour voir avec simplicité les fuites des cameras IP.








dyox a écrit :



Excellent pour voir avec simplicité les fuites des cameras IP.







Où tout objet “made in china”, j’ai un box xiaomi qui “papotte” avec des serveurs en chine mais je ne sais si c’est pour savoir si y’a des mises à jour ou si y’a plus de données que ça. A tester dès que possible :p



C’est un peu la réflexion que je me faisais. Le projet semble très prometteur, maintenant je me demande quelle forme prend cette analyse de trafic ? Est-ce que c’est prémâché pour que cela puisse être compréhensible par un profil pas trop technique, ou bien cela simplifie l’analyse mais les résultats sont “bruts” et il faut un background admin pour savoir de quoi on parle ?


C’est encore brut. Ça récupère les appels et les liste, comme le fait mitmproxy de base. Après, même sans historique d’administration, ça m’intéresse déjà pour voir qui communique en HTTP. Et si je vois des entrées comme “UUID” ou “position”, je peux me poser des questions.



Cf la vidéo dans l’article :)


Intéressant comme concept. Je vais y jeter un coup d’œil.


Je garde ça sous le manteau, m’intéresse également.

Super projet.


Ouais bof, c’est juste un mitmproxy avec deux ligne de nat dans iptables. Révez pas, vous ne verrez pas le trafic HTTPS avec… Sauf à compromettre le terminal client en injectant une CA rogue. Et comme dit dans l’article, avec le certificate pinning, hsts, et bientôt l’identification de la CA via DNSSEC, ça va être encore plus difficile de voir quoi que ce soit.

Et le petit bonus, très bientôt tous les sites seront en HTTPS étant donné que chrome refusera de se connecter à un site http…








dyox a écrit :



Excellent pour voir avec simplicité les fuites des cameras IP.





Il faut pouvoir installer le certificat sur la machine qu’on veut surveiller. Je ne sais pas si c’est possible sur les caméras IP mais en tout cas, ça sera difficile sur certains devices.



Bon nombre d’objets connectés ne font aucune vérification de certificat pour des raisons de coût. En effet, embarquer les certificats racines représente un gros volume de données et donc un espace mémoire plus grand et donc un équipement plus coûteux.


Oui, bon, l’IPv6 et DNSSEC, spas trop sec pour la prod ;) Quant aux sites web en HTTPS, je ne comprends pas le propos : l’utilisation que j’en fais, c’est pour capturer le trafic d’applis. Et puis, en fin de compte, le principe d’un mitm, c’est de se faire passer pour le destinataire légitime, donc je ne comprends toujours pas le souci de HTTPS tout bête (je ne parle pas des cas mentionné du cert pinning/HSTS). Enfin, même si tu as n’arrives pas à déchiffrer le trafic HTTPS, tu peux avoir une approche de “guess” (taille des paquets : parfois, des apps chinoises que j’ai déjà regardées, t’envoient du binaire en HTTP ou en HTTPS, je me suis rendue compte qu’ils packagent ainsi certains protos, etc.). Donc, bon, si tu veux gratter, tu trouveras de nombreuses infos. Là le but de la chose, c’est de faire du simple, transparent, FLOSS et reproductible.

&nbsp;

Y a des façons de faire des choses sympas, je vais commencer à documenter comment et ce qu’on peut faire dans les prochaines semaines.&nbsp;


Il y a encore des gens qui n’utilisent pas ntop sur leur firewall ?


C’est révolutionnaire………… Mouais


+1 Je ne vois pas trop l’intérêt, on peu déjà le faire avec&nbsp; un access point sur sa machine, mais bon dans bien des cas comme dit dans l’article le device ne se laissera pas berner par un certificat auto signé donc bof.


Quel rapport ? Et de quel type de firewall parles-tu ?


Il y a même encore de gens qui utilisent leur box en tant que firewall


Projet intéressant, je souhaitais effectivement faire ce genre de chose suite au projet&nbsp;Exodus Privacy. Merci Esther.


Chouette projet tiens, ça peut être pratique et marrant.


Ce serait bien de simplifier l’exploitation.



Je serai le mettre en place, mais exploiter les données et comprendre c’est autre chose <img data-src=" />


Une app YunoHost ça ferait un bon combo avec la Brique Internet <img data-src=" />

Je sais, yakafokon, tout ça… :-(


Ce genre de truc me sert chez moi pour filtrer internet des enfants. C’est facile à mettre en place. Par contre j’utilise un NUC, la RPI1 ne suivait pas du tout (256Mo de RAM, j’ai la toute toute première)


Bonne idée… Jusque la j’etais limité a fiddler et ntop pour le troubleshooting mobile… A tester


Le package des CA Mozilla prend moins d’un (1) Mo <img data-src=" />


1Mo dans l’IoT c’est énorme ! Dans l’IoT, la RAM fait quelques centaines de ko et la flash (là où on stocke le programme + les données) fait quelques Mo.


Peut-être une question idiote, mais pourquoi ne pas analyser les trames réseau?



En regardant simplement les entêtes @IP-Source, @IP-Dest, et en couplant ça avec du DNS, on peut lister de manière exhaustive les serveurs impliqués.



De là, on peut imaginer pas mal de chose, comme une sorte de whitelist/blacklist publique des serveurs identifiés comme étant douteux. Un outil de post traitement pourrait alors informer l’utilisateur sur le ratio clean/douteux par appareil (via l’IP interne), voire carrément bloquer les trames connues comme allant vers des serveurs douteux.





Bon par contre ça serait en complément et pas en remplacement de PiRogue (qui lui bosse sur le contenu des trames http si je comprends bien).


Sur le PiRogue, il est tout à fait possible d’utiliser Wireshark en plus de MITMproxy. Ce duo permet d’avoir l’intégralité du trafic réseau + le trafic HTTPS en clair (lorsque c’est techniquement possible). Il est également possible de décoder, à la volée les messages protobuf. C’est que fait, entre autre, ce plugin MITMproxy :https://github.com/U039b/PiRogue/tree/master/mitmproxy



Et typiquement, le HotSpoot fait exactement ce que tu expliques : garder les IP de destinations + résolution DNS. Le projet est rapidement présenté ici :https://esther.codes/hotspoot-a-privacy-pot/



Enfin, tout dépend de l’objectif. Ici, l’objectif premier est d’analyser les messages envoyés par des applications Android.


Ce n’est pas la règle, il y a bien Windows 10 pour IoT <img data-src=" />