Il y a quelques jours, alors qu’il est en plein travail sur son ordinateur, un de mes collègues voit d’un coup ses logiciels se quitter et sa session se fermer. La machine a apparemment basculé en mode “prise de contrôle à distance”, et il lui est donc impossible de la débloquer autrement qu’en la redémarrant de force. Tout semble fonctionner à nouveau normalement, mais quelques minutes plus tard, rebelote. Cette fois, plus de hasard possible, il soupçonne ue attaque ou un virus. Réaction logique et saine : il débranche sa machine du réseau.
Pour ma part, jusque-là, j’observais la scène et j’ai tout vu. Il va être temps d’assumer ma casquette d’admin réseau. Comme il est peu probable qu’il s’agisse d’une attaque extérieure à la société (notre réseau est une forteresse dont la DMZ est inattaquable et le coeur insubmersible, toute la Team Rézo vous le dira, hé), nous allons voir ces messieurs de l’administration système, qui sont les principaux utilisateurs du protocole RDP, lequel permet de piloter les équipements sous Windows à distance via le réseau.
L’un d’eux étant précisément en train de pester contre une machine apparemment récalcitrante à toute prise de contrôle, nous lui demandons quelle est d’adresse de cette machine. “10.249.171.35”, nous répond-il. L’adresse du poste de mon collègue étant “10.249.171.29”, ça pourrait bien être une faute de frappe… Pour s’en assurer, mon collègue rebranche son poste et l’admin système tente à nouveau l’expérience : à nouveau c’est 10.249.171.29 qui est touchée et non 10.249.171.35.
Réflexe d’admin réseau, je vérifie les tables ARP (protocole qui permet d’identifier géographiquement une machine sur le réseau à partir de son adresse IP) des deux machines ainsi que des switchs situés entre elles. Sur celle de l’admin système, on y voit clairement l’entrée correspondant à 10.249.171.29, mais pas celle de 10.249.171.35. Conclusion : en “attaquant” l’adresse 10.249.171.35, l’admin touche en réalité 10.249.171.29. Quelle bizarrerie ! Son Windows est-il vérolé au point de perturber le fonctionnement de sa pile TCP/IP ?
Je demande à l’admin de me montrer exactement comment il s’y prend pour lancer sa prise de main à distance. Je le vois alors afficher un tableau Excel qui recense les adresses de tous les serveurs qu’il gère quotidiennement. Il copie l’une d’entre elles, 10.249.171.035, et la colle dans la fenêtre de connexion de Terminal Server. Une fois de plus, c’est la machine 10.249.171.29 qui est touchée, alors que la fenêtre de connexion sur le poste de l’admin affiche bien “10.249.171.035”.
Je commence alors à avoir l’impression d’entendre le thème des X-Files dans ma tête. Mais quand il me dit qu’avant il procédait exactement de la même façon qu’aujourd’hui. Je lui demande alors s’il a apporté des modifications à sa feuille de calcul récemment. Il m’explique que oui, la veille, mais que c’était juste pour ajouter des zéros dans les adresses IP de façon à ce qu’elles aient toutes la même longueur et que ce soit plus joli.
Et là, c’est le déclic. Des souvenirs de l’époque où je découvrais les réseaux IP surgissent dans ma tête, et plus précisément une fois où j’avais essayé de lancer des ping et des traceroute vers des adresses non conventionnelles, c’est-à-dire qui ne respectent pas le schéma des quatre nombres compris entre 0 et 255 séparés par des points. Et à l’époque j’avais constaté que mettre des zéros devant les chiffres provoquaient des comportements erratiques, mais sans chercher à en comprendre les raisons précises.
Je demande à l’admin de coller à nouveau l’adresse qui est encore dans le presse-papiers mais en enlevant le zéro de “035”. Et là, bingo, c’est la bonne machine qui est impactée ! Comme un bon admin réseau ne peut pas partir sans faire un peu la morale, je lui dis qu’il ferait mieux d’enlever ces zéros superflus de son tableau Excel.
De retour à mon bureau, je décide d’investiguer un peu, conscience professionnelle oblige. Première question : est-ce un problème lié à Windows ? Je fais quelques tests sur différentes plates-formes, et constate avec surprise que ce n’est pas le cas :
Comme vous pouvez le voir, l’effet est rigoureusement identique sous Windows, Linux et Mac OS X. Déduction logique : il s’agit du comportement du protocole TCP/IP lui-même. Mais s’agit-il de quelque chose de normal ou d’un disfonctionnement ?
J’ai alors fait quelques tests avec d’autres adresses IP :
192.168.1.01 = 192.168.1.1
192.168.1.02 = 192.168.1.2
...
192.168.1.07 = 192.168.1.7
192.168.1.08 = (adresse non valable)
192.168.1.09 = (adresse non valable)
192.168.1.010 = 192.168.1.8
192.168.1.011 = 192.168.1.9
...
192.168.1.017 = 192.168.1.15
192.168.1.018 = (adresse non valable)
192.168.1.019 = (adresse non valable)
192.168.1.020 = 192.168.1.16
192.168.1.021 = 192.168.1.17
...
Les matheux et informaticiens ont sûrement déjà compris ce qui se passe : dans une adresse IP, faire précéder l’un de ses nombres par un zéro signifie qu’on l’écrit en base octale, c’est-à-dire par un chiffre allant de 0 à 7. Et là, en effet, 192.168.1.035 en base octale signifie bien 192.168.1.29 en base décimale.
En effectuant quelques recherches pour en savoir plus, j’ai également appris que mettre “0x” devant un nombre signifie qu’il est à interpréter en base hexadécimale (16 symboles), dans laquelle 192.168.1.0×35 signifie 192.168.1.53. Sachez également qu’une adresse IP peut également s’écrire en un seul nombre, sans points, en bases décimale, octale et hexadécimale, dans lesquels notre fameux 192.168.1.35 a pour équivalents respectifs 3229614371, 030040000443 et 0xc0800123. Je laisse les sceptiques essayer par eux-mêmes.
Et il ne s’agit là que de quelques exemples parmi une foule de bizarreries qui permettent d’obscurcir allègrement la résolution d’adresses sur des réseaux IP… et donc sur le web. Bon nombre de ces astuces sont notamment utilisées par les mails de fishing, dans le but de faire croire aux internautes qu’ils sont sur le site qu’ils croient alors que ce n’est pas le cas…
