Comment espionner ou pirater les internautes qui visitent des sites Internet non sécurisés

Dans le dernier article, l’Assemblée Nationale a été alertée pour leur faire prendre conscience des risques qu’ils font prendre à leurs internautes en ne sécurisant pas toutes leurs pages avec HTTPS.
Pour bien comprendre ces risques, une courte vidéo a été réalisée. Elle explique les méthodes utilisées par les hackers pour abuser des internautes et les façons de s’en protéger.
Si vous ne pouvez pas ou ne souhaitez pas regarder un format vidéo, le script de la vidéo est disponible ci-dessous.
Script de la vidéo
Avertissement - Les explications données dans cette vidéo ont pour unique but (i) de sensibiliser les internautes à l’importance de fréquenter des sites Internet sécurisés, et (ii) de sensibiliser les éditeurs de sites Internet à l’importance de déployer le protocole HTTPS. Le fait d’intercepter, d’espionner ou de modifier les communications numériques de tierces personnes sans leur accord préalable est répréhensible par la loi française.
Bonjour à tous - Vous avez probablement déjà vu dans votre navigateur ce message vous indiquant que le site Internet que vous fréquentez n’était pas sécurisé.
Informations pour le site www.example.com : connexion non sécurisée. Votre connexion à ce site n’est pas privée.
Les informations que vous transmettez peuvent être visualisées par d’autres personnes (comme les mots de passe, les messages, les cartes bancaires, etc.).
Et avouez que vous avez probablement continué votre visite, parce qu’au final, que pourrait-il bien arriver ?
Dans cette vidéo on va voir ensemble quels sont les risques à visiter un site Internet non sécurisé et comment un hacker peut espionner ou pirater un internaute qui visiterait un tel site.
Partie 1 - La problématique
Pour commencer, et pour vous permettre de comprendre le mode opératoire, on a besoin de faire un peu de théorie.
Lorsque vous saisissez une adresse dans votre navigateur favori, votre navigateur envoie un message au propriétaire du site Internet pour lui demander de lui retourner le contenu de la page.
Dans le jargon, ce message qui est envoyé est appelé une requête. La personne ou plutôt l’ordinateur, qui initie cette requête est appelé le client, et la machine qui reçoit la requête est appelée le serveur. Un serveur, c’est quoi ? C’est ni plus ni moins qu’un ordinateur, comme le vôtre, mais qui tourne 24h/24, 7j/7, pour pouvoir répondre à toutes les sollicitations.
Pour que la communication se fasse correctement, nos deux machines doivent parler le même le langage, ou plutôt ils doivent utiliser le même protocole de communication qu’on appelle HTTP.
On a donc une requête envoyée par le client au serveur, utilisant le protocole HTTP.
En retour, si la requête est conforme et acceptée, le serveur répond en envoyant également une requête avec le contenu de la page demandée. Le client peut alors afficher la page à l’utilisateur.
Pour illustrer ce concept, imaginez que vous souhaitez écrire une lettre à un ami. Vous écrivez votre lettre, vous la mettez dans une enveloppe, vous y inscrivez son adresse, et vous l’envoyez. Après un certain temps, vous recevez la réponse et la lisez. Jusqu’ici tout semble normal, sauf qu’en réalité plusieurs problèmes se posent :
- (1) Vous n’avez aucune garantie que la personne qui vous a répondu est bien celle qu’elle prétend être. Cela pourrait très bien être son frère ou ses parents qui ont répondu à sa place.
- (2) Vous n’avez aucune garantie que le contenu de votre message ou de la réponse n’ait pas été lu pendant le transit par d’autres personnes comme le transporteur ou le livreur.
- (3) Vous n’avez aucune garantie que le message que vous envoyez ou la réponse que vous recevez n’ait pas été modifié pendant le transit.
Parce qu’au final, on n’a mis en place aucun mécanisme qui permettait de chiffrer le contenu de notre lettre, et n’importe qui aurait pu l’ouvrir et la lire.
En informatique, c’est pareil. Lorsque vous envoyez une requête à un serveur en demandant à obtenir le contenu d’une page Internet, ces mêmes risques se posent car le contenu des requêtes, tout comme le contenu des lettres, ne sont pas non plus chiffrés.
Et ces risques ne sont pas seulement des concepts théoriques, ce sont réellement des maillons faibles que des hackers peuvent exploiter pour abuser de l’utilisateur, et potentiellement le pirater.
Partie 2 - Attaque Man-in-the-middle
Ce type de communication peut fonctionner uniquement si l’on peut faire confiance à tous les acteurs de la chaîne. Si l’un des intermédiaires le décidait, il pourrait abuser de sa position et pourrait, en plus de simplement transmettre la requête, la lire ou la modifier. C’est exactement ce qu’on va faire. On va se positionner entre le client et le serveur pour nous permettre de voir les requêtes passer. Cette méthode s’appelle l’attaque Man-in-the-middle.
Imaginez qu’un utilisateur veuille afficher un site Internet non sécurisé : il allume son ordinateur, se connecte à Internet, lance son navigateur, tape l’adresse du site et attend que la réponse s’affiche à l’écran.
Lorsque la requête est envoyée au serveur, elle transite par un certain nombre d’acteurs avant d’arriver à destination. Dans l’ordre, on pourrait trouver, le fournisseur d’accès à Internet du client, éventuellement les services gouvernementaux, puis d’autres opérateurs qui vont acheminer la requête jusqu’au fournisseur d’accès à Internet du serveur.
On peut difficilement imaginer pirater le fournisseur d’accès lui-même ou les autres acteurs plus loin dans la chaîne, mais on pourrait plus aisément se placer entre le client et son fournisseur d’accès à Internet. Cela peut se faire en se connectant sur le même réseau du client, Wi-Fi ou filaire, ou en l’amenant à se connecter sur le même réseau que nous.
Ce scénario est possible si quelqu’un vient se connecter sur un réseau qui vous appartient ou si quelqu’un se connecte sur un point d’accès Wi-Fi public, gratuit ou payant, comme on peut en trouver dans les restaurants, dans les hôtels, dans les aéroports, etc.
Une fois qu’on est positionné entre le client et le serveur, on peut voir les requêtes passer. Et vu que les sites qui utilisent HTTP ne chiffrent pas le contenu de ces requêtes, on va pouvoir les lire, et potentiellement les intercepter et les modifier.
La première attaque que l’on peut réaliser, c’est simplement d’écouter et d’enregistrer le contenu des requêtes qui passent. On peut ainsi espionner l’utilisateur pour savoir exactement quels sites il visite, mais aussi consulter le contenu des messages qu’il envoie, et potentiellement récupérer ses identifiants et mots de passe s’il se connecte à ses comptes personnels. D’autant plus intéressant si l’internaute utilise ce même mot de passe sur d’autres comptes. On pourrait alors avoir accès à bien plus d’informations que simplement le site visité.
Si on est le propriétaire du point d’accès sur lequel est connecté le client, on peut même aller plus loin, et intercepter la réponse du serveur destinée au client. On peut ensuite la modifier, soit en rajoutant des éléments, soit en remplaçant totalement la réponse par une réponse factice préparée par nos soins. L’utilisateur recevrait notre réponse à la place de la réponse initiale officielle sans aucun moyen de se rendre compte de la supercherie.
Ces techniques basiques de piratage sont souvent utilisés par des entreprises ou des gouvernements peu scrupuleux à des fins d’espionnage, de censure, ou simplement pour gagner de l’argent.
Dans un passé proche, certaines compagnies aériennes[1] et certains fournisseurs d’accès[2] ont déjà été tentés par de telles pratiques. Plus grave, certains gouvernements, pour des raisons qui leur appartiennent, utilisent ces attaques pour censurer des sites qui leur déplaisent, comme cela était le cas pour Wikipédia[3] par exemple.
Partie 3 - La solution : HTTPS
Pour éviter de se faire espionner ou pirater par les techniques que l’on vient de voir, il y a une solution simple : se connecter sur les sites avec le protocole HTTPS.
HTTPS ajoute une couche de sécurité supplémentaire qu’on appelle TLS. Cette surcouche apporte des garanties aux risques identifiés précédemment :
- La garantie que la réponse provient bien du site Internet officiel, en utilisant ce qu’on appelle un certificat, une sorte de carte d’identité numérique que seul le propriétaire possède.
- La garantie que le contenu ne sera pas lu car les requêtes sont chiffrés en utilisant des clés cryptographiques qui permettent uniquement aux deux machines de chiffrer et déchiffrer les messages.
- Et enfin, la garantie que le contenu des requêtes ne sera pas modifié grâce aux deux mécanismes cités précédemment.
Ces trois notions ont un nom : identification, confidentialité et intégrité.
Pour illustrer ce concept de communication sécurisée, on peut reprendre l’exemple initial de la lettre que vous envoyez à un ami. Sauf que cette fois-ci, vous mettez cette lettre dans un coffre fermé à clé. Il existe uniquement deux clés pour ouvrir ce coffre, une que vous possédez, et une seconde que votre destinataire possède. Lorsque vous recevez le coffre, si votre clé permet de l’ouvrir, c’est que la lettre qui est contenue dans le coffre provient de votre destinataire et qu’elle n’a pas été ni lue ni modifiée.
Cet exemple de lettre est simplifié à l’extrême car le fonctionnement de HTTPS est un peu plus complexe en utilisant non pas des clés physiques mais des clés cryptographiques dites asymétriques qui consistent à avoir deux jeux de clés, une qui permet de chiffrer, et l’autre qui permet de déchiffrer, un peu comme si notre coffre avait deux clés différentes, une uniquement pour fermer le coffre, et une autre pour l’ouvrir.
HTTPS apporte aussi une solution à la problématique de l’échange de clés initial pour permettre aux deux parties de s’échanger leurs clés de manière sécurisée avant que la communication sécurisée soit établie. Car au final, la sécurité de la communication repose entièrement sur la possession de ces fameuses clés.
Évolution et conclusion
Au départ, seuls les échanges d’informations dits « sensibles » étaient protégés par le protocole HTTPS, comme l’accès aux comptes bancaires ou les paiements par carte bancaire.
Aujourd’hui, au vu des menaces grandissantes et des abus constatés, la grande majorité des échanges est sécurisée. On estime que 80 % des sites visités seraient désormais sécurisés, et on ne peut que s’en réjouir. Les utilisateurs sont mieux protégés et ne sont désormais plus à la merci de fournisseurs d’accès ou de gouvernements aux pratiques douteuses.
Ce n’est pas un hasard si certains pays ont décidé de bloquer les communications HTTPS, c’est parce qu’il est très difficile, voire impossible de déchiffrer leur contenu.
Pour conclure, et si vous deviez ne garder qu’une seule chose de cette vidéo
: Connectez-vous uniquement sur les sites sécurisés par HTTPS. C’est le seul moyen pour vous protéger et protéger vos données sur Internet.
Restez vigilants, et à la prochaine.
Notes et références
- ↑Un internaute a détecté que la compagnie aérienne Southwest a, par exemple, injecté des scripts dans le contenu des pages Internet non sécurisées (source : Blog de Joe Manna, septembre 2014, en anglais).
- ↑Un internaute a détecté que l’opérateur Orange a, par exemple, injecté des scripts dans le contenu des pages Internet non sécurisées (source : @SarhanTN).
- ↑Le site de Wikipédia est censuré par certains gouvernements (source : Censorship of Wikipedia, en anglais).