vincesafe.fr

Attention, article super technique. C’est un pavé qui fait brouillon mais j’ai envie de le partager quand même. J’en ferai un papier plus propre pour l’exposer à des professeurs.

Depuis mon dernier article sur le partage de la connexion 3G de son smartphone malgré le refus de l’opérateur, je me demande comment il est possible de déterminer qu’un paquet provient bien du smartphone et non d’un appareil connecté dessus. Aujourd’hui, je vous propose deux choses : une application pour faciliter l’astuce précédemment décrite et une réflexion sur le « truc » des opérateurs pour refuser le tethering.

SSH est trop compliqué ?

Si vous n’êtes pas à l’aise avec SSH, vous avez dû avoir des difficultés à expérimenter la technique du dernier article. Réflexion faite, je me suis dit que c’est le même principe qu’un proxy. Après, je ne sais pas du tout comment ce genre de serveur fonctionne. J’ai donc demandé à mon ami Google s’il connaissait des serveurs proxy pour Android. Je suis tombé sur Internet Sharer. Cette application est simple d’utilisation mais pas super pratique. Elle fournit un serveur proxy HTTP et SOCKS, ce qui devrait permettre de faire transiter tout ce qu’on veut (pour l’instant, je n’arrive à me servir que du proxy HTTP). On peut aussi utiliser cette application pour faire du port forwarding (on écoute sur un port et on renvoie ce qui arrive sur un autre port d’un hôte distant).

Pour faire transiter ses communications via le serveur proxy, ce qui permet de faire croire à l’opérateur qu’elles proviennent du smartphone, il faut configurer ses applications. C’est là que je ne comprends pas trop… Pour la navigation web, j’ai mis comme proxy HTTP l’adresse IP de l’interface Wi-Fi du smartphone (de la forme 192.168.X.1) et comme port 8080, et comme proxy SOCKS la même adresse et le port 1080. De cette manière, la navigation web fonctionne, mais SSL ne passe pas (autrement dit, HTTPS ne passe pas). Je creuserai sûrement si j’en ai le courage.

On ne peut donc pas à priori tout faire passer par ce proxy, alors qu’on peut techniquement tout faire passer par le tunnel SSH. Mais le mieux, ce serait encore de comprendre le truc qui fait que l’opérateur bloque les communications venant d’autres hôtes (ou demande de payer pour autoriser cette technique).

Du routage et du NAT

On part dans la technique, on part dans le réseau. Qu’est-ce qui différencie une trame émise du smartphone vers l’extérieur en passant par le réseau de données (3G) d’une trame émise d’un autre appareil, passant par le smartphone pour atteindre la même destination ?

Quand on fait du tethering sous Android, par défaut, l’interface Wi-Fi donne accès au réseau 192.168.X.0/24 et l’interface PPP (3G) au réseau 10.Y.Z.0/24 (réseau de l’opérateur). Si on regarde la table de routage du smartphone, on voit bien que l’interface PPP sert de passerelle par défaut. Toutes les communications non internes sont donc techniquement redirigées vers le réseau de l’opérateur (j’ai des doutes là-dessus, une capture de trames semble me contredire). On a donc du routage et par conséquent, des modifications au niveau de la couche 3 lors de l’acheminement.

De plus, on a 2 interfaces qui donnent sur des réseaux privés (10.0.0.0/8 et 192.168.0.0/16). On a donc obligatoirement de la translation d’adresses et de ports (NAT/PAT) puisque les adresses en question ne peuvent pas être routées. La couche 4 est donc également impactée… Sauf qu’on peut envoyer des paquets ICMP depuis son smartphone en passant par le réseau de données. Or, qui dit ICMP dit niveau 3. Il n’y a pas de niveau 4, on peut donc supposer que la couche transport (4) ne joue aucun rôle dans l’identification des paquets venant d’un hôte autre que le smartphone.

Par ailleurs, le NAT fait que l’adresse source du réseau Wi-Fi est remplacée par l’adresse source de l’interface PPP lors du routage. C’est donc comme si l’émetteur original était le smartphone. Il se pourrait donc que ce soit une autre information de la couche 3 qui soit la « taupe ». À part le TTL, je ne vois pas. Pourquoi le TTL ? Parce que lors du routage, il est décrémenté et vaut donc 63 ou 127 quand le paquet est envoyé sur le réseau de l’opérateur, alors qu’il vaudrait 64 ou 128 si le dit paquet provenait du smartphone. J’ai donc essayé d’envoyer une requête ICMP avec scapy en augmentant de 1 le TTL de base depuis mon hôte connecté en Wi-Fi, mais ça ne fonctionne pas mieux.

Si quelqu’un réussit à trouver une explication qui tient la route, même une vague idée, n’hésitez surtout pas à la proposer !