Depuis quelques jours, les réseaux sociaux helvétiques sont remués par la divulgation d’une « faille » concernant le système d’e-voting produit par le canton de Genève. L’information a été initialement relayée par SRF (source pour les germanophones). Depuis, c’est une déferlante de réactions/récupérations politiques du type « la sécurité n’est pas au point ». À mon sens, la majorité de ces messages sont des réactions populistes (protégeons les honnêtes citoyens contre le méchant internet) par des personnes n’ayant que survolé le sujet. Je vous détaille ici cette faille d’un point de vue technique.
La faille d’un point de vu utilisateur
- Connexion sur le portail d’e-voting en utilisant l’url du type www.evoting-ch.ch
- Redirection sur une url de type https://hacked-evoting.ch
- Le site affiché copie le style du site légitime afin de ne pas éveiller les soupçons. Il est le vecteur principal de l’exploitation, à savoir une attaque de type Man-In-The-Middle
La faille en elle-même est l’étape 2, la redirection depuis www.evoting-ch.ch vers https://hacked-evoting.ch. Ceci exploite une attaque de type Cache-Poisoning. Pour comprendre ce type d’attaque, il faut repréciser le contexte de la requête (une requête est générée au moment où l’utilisateur accède à un site web).
Quelle est la vie d’une requête web ?
Globalement, une requête web se fait comme suit :
Il s’agit ici de la version ultra simplifiée d’une requête. L’étape DNS hélas un peu plus compliquée que ça. Malheureusement, il est nécessaire de comprendre un peu plus précisément le fonctionnement afin de comprendre l’attaque.
En quelques mots, la « traduction » DNS se fait selon un principe de délégation : Le serveur DNS « Resolver » (principalement le serveur DNS de l’opérateur) va effectuer une requête auprès de l' »autorité » du .ch afin de savoir quel serveur s’occupe de evoting-ch.ch puis effectue une requête à ce dernier serveur afin de savoir comment résoudre www.evoting-ch.ch.
L’attaque DNS Poisoning
L’attaque de type DNS Poisoning (DNS Cache Poisoning) à, en général, pour cible le serveur DNS resolver (au niveau du point rouge dans le schéma précédent). En effet, ce serveur utilise un mécanisme de cache (afin d’éviter de diminuer le nombre de requêtes sous-jacentes). L’attaque consiste à compromettre ce cache afin que les requêtes soient dirigées vers un serveur malicieux.
Comment s’en protéger ?
La majorité des réactions suite à la publication de la faille ont étées de tirer à boulets rouges sur le responsable du système d’evoting. En effet, il y a des mécanismes pour éviter ce type d’attaque qui peuvent être implantés côté fournisseur de service (DNSSEC) mais ce n’est de loin pas tout : Il s’agit de la meilleure manière de déresponsabiliser l’utilisateur final !
DNSSEC
Le DNSSEC est un mécanisme permettant de valider que la résolution dns soit effectuée de manière légitime. Un article précédent explique le concept et sa mise en place dans certains contextes.
Il est à noter que l’utilisation de DNSSEC est aujourd’hui marginale : selon les chiffres de nic.ch (https://www.nic.ch/fr/statistics/dnssec/) 2.8% des sites « .ch » implémentent DNSSEC.
HTTPS par défaut
Cette faille effectue une redirection depuis l’url http://www.evoting-ch.ch vers https://hacked-evoting.ch mais dans le cas où l’accès se fait explicitement via https://www.evoting-ch.ch, la redirection ne se fera pas (une erreur de certificats s’affichera)
HSTS et HSTS Preload
HSTS est un mécanisme qui permet d’indiquer au navigateur de se connecter par défaut en HTTPS. Grâce à un header, il indique qu’une fois la première connexion effectuée, les accès se font par défaut en HTTPS permettant d’éliminer le problème de DNS Cache poisoning. Cependant, cela laisse le problème de la première connexion: C’est pour cette raison que HSTS a été complété par HSTS Preload permettant, via une liste que consultent dynamiquement les navigateurs, d’effectuer l’ensemble des connexions en HTTPS par défaut pour un domaine donné.
Responsabiliser les utilisateurs
Cette attaque est très similaire dans son fonctionnement à du phishing. Aujourd’hui, l’attention des utilisateurs ne peut être remplacée : effectivement une vérification visuelle de l’url est laborieuse mais nécessaire pour se prémunir de ce type de problématiques.
De plus, comme l’illustre le second schéma, cette attaque s’en prend à des éléments de l’environnement utilisateur : l’utilisateur final est responsable d’utiliser un terminal non compromis. Le cas présent permet de rejeter la faute sur le fournisseur de service, mais dans le cas où le terminal d’accès est vérolé, ou que l’utilisateur utilise un navigateur compromis, il n’y aura d’autre réponse que de s’occuper de la réelle problématique qu’est le terminal. L’utilisateur choisi, majoritairement sans le savoir, les serveurs dns auxquels il fait confiance pour diriger sa navigation web (que ce soit explicitement ou par le choix de son opérateur). Si le serveur dns en question n’est pas fiable, le choix est à remettre en question et non le service distant auquel l’accès est effectué.