Archives mensuelles : mai 2012

Vote par Internet, le Conseil Constitutionnel alerté

Laurent Grégoire, qui avait démontré qu’il était possible de changer le vote d’une personne à son insu s’il décidait d’utiliser la procédure de vote par Internet vient de me transmettre un courrier qu’il a envoyé hier au Conseil Constitutionnel (qui est en charge de valider ou non le scrutin). Le voici :

Monsieur le président du Conseil Constitutionnel,
Messieurs les membres du Conseil Constitutionnel,

Les français résidents à l’étranger ont la possibilité, pour le
premier et second tour des élections législative de 2012, de voter par
internet. Étant personnellement résident à l’étranger, et ayant eu la
possibilité de le faire, j’ai pu démontrer et vérifier in-situ que la
sécurité du scrutin était mise en défaut par une faille technique dite
« d’injection de code ». Vous trouverez toutes les informations
techniques détaillés dans l’article que je viens de publier (1).

Cette alerte à été prise très au sérieux par les milieux spécialisés
dans la cyber-sécurité (2), ainsi que des médias plus traditionnels
comme le Monde, le Figaro, Libération, Ouest-France, LCI (3), ainsi
que certaines organisations politiques. Que conclure de mon étude? Si
l’ordinateur du votant est compromis par la présence d’un logiciel
malveillant, il est possible, par une méthode assez simple, de
modifier le vote de l’électeur, à son insu.

Une étude récente de l’INSEE montre que 34% des ordinateurs personnels
en France ont subis des contaminations par un virus (4). D’autre
études montrent, lors d’une analyse portant sur 22 millions
d’ordinateurs, que 48% d’entre-eux étaient infectés par un logiciel
malveillant (5). Il est de notoriété publique que des réseaux mafieux
exploitent en ce moment même des réseaux d’ordinateurs zombies
(botnet) composés de plusieurs millions d’ordinateurs personnels
infectés (6), ce en France et dans le monde entier. Ces réseaux
vendent leurs services aux plus offrant, et une manœuvre visant à
corrompre un scrutin est largement à leur portée technique.

Tout ceci laisse donc la possibilité théorique d’exploiter cette
faille afin de réaliser une fraude massive du vote par internet. Je
n’affirme pas que cette fraude existe réellement; j’affirme cependant
qu’il en existe la possibilité, et que malheureusement on ne pourra
sans doute jamais affirmer le contraire. Dans le domaine de la
sécurité informatique, on ne peut jamais démontrer par la positive
l’infaillibilité d’un système. Ce n’est qu’en trouvant une faille que
l’on peut montrer par la négative que le système n’était pas sécurisé.
Et contrairement à d’autres domaines où des vérifications ultérieures
permettent de détecter et de corriger les problèmes après leur
détection, la nature même d’un scrutin à bulletin secret empêche toute
post-analyse et ne permet donc pas d’en affirmer la validité.

Je me permet donc de vous alerter et vous faire part de mon inquiétude
sur ce sujet, que malheureusement une grande majorité d’experts en
sécurité informatique partagent avec moi.

Veuillez agréer mes salutations respectueuses,

Laurent GRÉGOIRE
Ingénieur diplômé de l’Institut Catholique d’Arts & Métiers
Informaticien spécialisé en systèmes embarqués
Amsterdam, Pays-Bas

—————–
(1) – http://www.scribd.com/doc/94990325 (document ci-joint),
https://vimeo.com/42935480
(2) – http://www.undernews.fr/reseau-securite/le-systeme-de-vote-electronique-des-legislatives-francaises-vulnerable.html
http://www.numerama.com/magazine/22721-vote-par-internet-une-faille-demontree-et-illustree.html
http://www.zataz.com/news/22179/voter–internet–dangereux–piratage.html
(3) – http://www.lefigaro.fr/flash-actu/2012/05/29/97001-20120529FILWWW00445-vote-par-internet-une-faille-decouverte.php
http://www.ecrans.fr/Legislatives-le-vote-par-Internet,14761.html
http://www.ouest-france.fr/actu/actuDet_-Vote-par-internet.-Un-Nantais-montre-qu-il-peut-etre-pirate-[Video]_39382-2081688_actu.Htm
http://www.wat.tv/video/lci-est-vous-mardi-29-mai-528rx_2exyh_.html
(4) – http://www.insee.fr/fr/themes/document.asp?ref_id=ip1340#inter6
(5) – http://zd.net/cM9btD
(6) – http://fr.wikipedia.org/wiki/Botnet

 

L’applet de vote par Internet aurait été modifié pendant la procédure

Hier un commentaire sur ce blog m’a glacé le sang : Oumph (Benoit Sibaud, excusez du peu) a en effet eu le bon réflexe de calculer la checksum de l’applet à plusieurs moments du vote et en a relevé un autre sur Twitter. Le résultat est inattendu…

La checksum, somme de contrôle, est calculé à partir d’un fichier et permet de générer une chaine unique en fonction de la composition dudit fichier. Ce qui permet par exemple de vérifier si un fichier téléchargé (une distribution Linux par exemple) est bien arrivé intègre. Si la checksum fournie sur le site de l’éditeur est bien la même que celle générée par l’utilisateur sur le fichier téléchargé, celui-ci est bien identique (bit à bit) et le transfert en l’a pas alteré.

Ici la question était de savoir si le fichier utilisé pour organiser le vote était bien le même tout du long… La réponse semble être non !

Ce qui veut simplement dire que le fichier aurait été modifié pendant la procédure de vote, soit intentionnellement par l’éditeur Scytl, soit par le ministère des affaires étrangères ou, et c’est là que cela deviendrait très inquiétant, par un acteur étranger qui a pu y injecter par exemple le code de son choix…

Le commentaire soulève aussi des problèmes de certificat déjà relevés par Hardkor

EDIT 13h30 : Si vous avez une version en cache de votre navigateur de l’applet merci de comparer le sha256 à ceux fournis ici et si vous en avez un différent de me contacter ou de contacter Oumph pour que l’on puisse essayer de comprendre ce qui a changé dans les différentes versions.

Les sha256 relevés pour le moment sont :

  • 26f313d6cdf87e33ee553d1ce9e78b4cb3371ac34ee7682a38d112c748fc9286 : site de test, certificat erroné
  • 6599ec2e599fc0016baabfb9abd378893abc111cbe6928e7b943546fde048c43 : version de prod
  • d8c4b7f64c2726ca5db146772ea85ce575e0392aa43f72b822ccb3388abc6ed3 : l’intruse

Par ailleurs, les recherches de Oumph sont centralisées ici sur son site perso.

Comment mon ordinateur a voté à ma place, les fichiers

Laurent Grégoire nous avait gratifié d’un document de 20 pages et d’une vidéo expliquant comment il avait pu simplement créer un programme qui substituerait le vote d’un citoyen par celui qu’un attaquant aurait choisi. Il m’a transmit les sources de son « Proof of Concept » pour que celles-ci soient examinées, décortiquées et permettent éventuellement de déceller d’autres soucis (vote multiples, vote pour plusieurs candidats, …).

EDIT (01/06/2012) : la vidéo a été censurée par Vimeo – se référer à cet article.

Pour rappel la vidéo et le document initiaux :

Comment mon ordinateur a voté à ma place (et à mon insu)

Et le travail de Laurent (n’hésitez pas à partager celui-ci, à le dupliquer de partout… Bref Streisand it).

Ce serait quand même drôle que je reçoive un courrier pour violation de la « propriété intellectuelle » de Scytl ou du MAE non ? 🙂

Vote par Internet, un long dossier d’échecs techniques et philosophiques

Depuis quelques jours un faible nombre de personnes s’en prend à une « expérience » du ministère des affaires étrangères : le vote par Internet pour les législatives 2012. Près de 700.000 personnes sont concernées, certains ne voient pas le danger, d’autres (moi le premier) avancent des arguments techniques pas toujours évidents. Cet article se veut une centralisation des sources sur le sujet, des problèmes soulevés et une vulgarisation des problématiques techniques.

De quoi parle-t-on ?

La problématique soulevée est juste : il s’agit de permettre aux Français vivant à l’étranger de voter depuis chez-eux alors qu’autrement ils feraient face à des soucis techniques parfois lourds (plusieurs témoignages d’expatriés devant parcourir des centaines de kilomètres jusqu’à un consulat pour voter fleurissent sur la toile). La mise en pratique consiste à la sous-traitance d’une application de vote en ligne à une société (Scytl) dont on sait peu de choses mais dont il s’agit de la « spécialité ». Le tout est supervisé (à un niveau que l’on ignore) par le ministère des affaires étrangères.

L’ensemble des ressortissants Français inscrits sur les listes électorales et vivant à l’étranger a donc reçu un courrier à entête du ministère pour lui préciser la démarche et son identifiant de vote. Celui-ci est valable pour les deux tours des législatives et est couplé avec un mot de passe envoyé par un autre biais (par email ou sms en l’occurence, en fonction des témoignages toujours). Ce mot de passe lui changera pour le second tour.

Ce couple identifiant / mot de passe est ensuite à utiliser sur la fameuse application créée par Scytl et hébergée (visiblement) par le ministère sur ses serveurs. A la fin de chacun des scrutins le décompte est réalisé (visiblement là aussi) par Scytl et communiqué au ministère. Les votes effectués via internet sont comptabilisés au même titre que ceux effectués par courrier, dans les consulats ou par procuration en consulat.

D’un point de vue idéologique

Il y a donc beaucoup d’inconnues sur l’ensemble du procédé, une mise en place potentiellement compliquée pour les technophobes (à qui il reste les « anciens » moyens de voter) et d’ores et déjà une pléiade de témoignages de complications constatées par les citoyens usagers.

Mais pire encore, une entreprise privée, Scytl, se retrouve à être au cœur du système démocratique et devient toute puissante au regard des résultats sur son système de vote dont elle seule a le contrôle total.

Le vote est en effet effectué sur un système qui semble ne pas pouvoir garantir les conditions nécessaires au vote : au minimum sa confidentialité (rien ne nous permet d’attester que l’identifiant n’est pas directement attaché au vote et que Scytl, au moins, n’a pas accès aux informations) et sa transparence (présence d’une urne, vérification de la présence de son enveloppe à l’intérieur et possibilité d’assister au dépouillement) ou sa sécurité (on y revient juste après).

Le système en lui-même étant centralisé, il est très simple de le répliquer, d’en faire un fac similé et de mettre en place un site de phishing pour un budget moindre mais qui nous permettrait de mettre la main sur les identifiants et mot de passe de tous les votants inscrits. A ce sujet l’ami Ploum a écrit un magnifique tutoriel sur comment gagner un siège pour 12€.

En l’état nous avons donc un système completement opaque, simple à reproduire, et qui est contrôlé par une seule et unique entité : la société qui fournit le service.

D’un point de vue technique

Et c’est là que cela va bien vite se gater : la conclusion du paragraphe précédent pourrait laisser penser que tant que la société, dont il s’agit de la spécialité, sait faire son boulot il ne devrait pas y avoir de problème. Sauf que bien sûr, dans la réalité, ce n’est pas le cas : l’application présente de graves problèmes de sécurité qui ont été ignorés par le ministère (qui se targue d’avoir fait vérifier le code par l’ANSSI et des experts indépendants) et ces divers impairs laissent à penser qu’elle ne sait absolument pas ce qu’elle fait…

Un contexte douteux

J’avais hurlé il y a peu que le service d’aide présentait une vulnérabilité de type injection SQL ainsi qu’un problème d’exposition d’informations. Cela n’est probablement pas lié au système de vote de façon directe mais d’ores et déjà ça respire l’amateurisme. Les problèmes soulevés ici sont présents sur beaucoup de sites internet de particuliers ou de PME mais les trouver sur un site ayant ce type d’enjeux démocratique est plus qu’inquiétant.

L’application étant conçue en Java une série de vérifications est faite pour s’assurer que l’ordinateur de l’utilisateur utilise bien les bonnes versions de logiciel avant de lancer l’application en elle-même. De même il est vérifié (de façon très sommaire) si l’utilisateur n’essaye pas d’accéder au système via un terminal mobile dont la sécurité est assumée comme plus faible (le réseau 3G est potentiellement plus simple à sniffer). Ces vérifications sont en fait cosmétiques et il est possible d’accéder à l’application sans passer par ses vérifications dès lors que l’on connait le lien à utiliser… Il devient possible de voter depuis n’importe quel terminal, n’importe quel OS, n’importe quelle version de Java…

Une connexion non chiffrée

Non vérifié pour le moment mais il semblerait qu’il soit possible d’effectuer l’ensemble de la procédure de vote depuis une connexion non chiffrée (le petit cadenas dont on vous a appris de toujours vérifier la présence avant de payer en ligne est absent) ce qui veut dire que l’on peut potentiellement transmettre son vote via une connexion en clair, que la confidentialité du vote n’est plus garantie, mais qu’en plus le vote devient altérable pour peu qu’une autre personne que vous soit sur le même réseau et bien équipé…

Si le processus de vote présente encore des doutes sur ce point (bien que le code source semble prouver que c’est le cas), la partie du site servant à demander un nouveau mot de passe est-elle bien capable de fonctionner aussi bien en HTTP qu’en HTTPS.

Le mot de passe semble être récupérable

Le mot de passe entre dans la clef servant à chiffrer les échanges avec un certain nombre d’autres informations qui sont récupérables depuis le code source. Connaissant la forme du mot de passe : des lettres, minuscule, entre 6 et 10 il devient possible de bruteforcer le mot de passe en essayant de déchiffrer des informations qui auraient été échangées entre le système de vote (l’applet java) et le serveur de traitement.

Si le mot de passe est connu il devient possible de recréer la clef de chiffrement et donc de déchiffrer à la volée toutes les communications pour les lire ou les modifier (man in the middle).

Une attaque menée avec succès

Ce midi Laurent Grégoire nous a gratifié d‘un proof of concept permettant de voir comment un virus (par exemple) pourrait altérer le fonctionnement de l’applet de vote en forçant, quel que soit le choix du citoyen usager, le vote à l’un des candidats présents dans les choix proposés. L’ensemble de la méthode est décrite dans un document de 20 pages, code compris et ne nécessite pour fonctionner que de récupérer la liste des votants et de les infecter avec un virus spécialement crafté pour l’occasion.

La sécurité n’existe pas

D’autres problématiques techniques seront surement levées dans les prochains jours (je vous rappelle que ma boite mail comme les commentaires de ce blog ne logguent pas les IPs donc faite vous plaisir) mais la conclusion est déjà là : à tous les niveaux possibles cette application a été compromise et dans tous les cas il devient possible de compromettre au moins un des aspects essentiels du vote.

Quand bien même l’application en elle-même pouvait être sécurisée (ce qui est techniquement impossible), on ne serait pas à l’abri d’un site de phishing ou d’un virus sur l’ordinateur de l’électeur qui mettraient en péril l’intégrité du scrutin et poseraient systématiquement la question de sa légitimité.

Conclusion

Je n’ai volontairement pas développé sur le côté philosophique du vote par internet dans le cas où il viendrait à se généraliser. Mais il est clair qu’une solution comme celle-ci, permettant de se désintéresser un peu plus encore de la vie politique (je vote entre le petit dej et téléfoot) parait une très mauvaise idée.

En l’état la seule solution raisonnable semble d’annuler les quelques 45.000 votes déjà enregistrés et proposer aux votants de se replier sur les solutions historiques présentant un bien meilleur niveau de fiabilité. Dans le cas où ce ne serait fait, il s’agirait d’une magnifique mascarade élisant des députés selon un système qui a été prouvé bancal et dont on ne sait finalement pas s’il a réellement été abusé ou pas pour le moment, s’il le sera ou pas.

Sources, aller plus loin

Le vote électronique, suite technique…

Il y a 15 jours je vous ai révélé la présence d‘une injection SQL sur le site de vote par internet destiné à élire les représentants des Français établis hors de France. Selon mes sources, aujourd’hui à 15h, se tient un plan média d’urgence au quai d’Orsay pour vanter les mérites de ce système… Ou pas ?

NB: cet article est très technique, faute de temps j’ai préféré livrer les conclusions sans les vulgariser. Je prendrai ce temps dans le week-end pour en faire une version plus… digeste…

J’ai regardé quelques peu le code java de l’applet servant à voter ainsi que l’environnement dans lequel il se trouve (le site en lui-même). De plus j’ai reçu deux emails de gentils anonymes ([email protected] et [email protected] merci :)) – voici quelques conclusions :

Sur l’environnement

Il est théoriquement impossible de passer l’étape de vérification de la configuration technique si vous avez fait le choix de travailler avec des logiciels open-source (donc pas Java lui-même mais un portage libre tout aussi sécurisé, si ce n’est plus). Théoriquement donc puisqu’il suffit de connaitre l’adresse de la page du vote pour bypasser cette sécurité (genre ici ;)) et toutes les autres vérifications sur la configuration matérielle (vote depuis un smartphone inclu).

Si on se penche un peu plus en détail sur le code de ladite page on constate d’ailleurs qu’il est possible de pré-remplir certaines variables (réinjectées dans des champs ensuite) de l’applet lui-même depuis l’url de la page appelante (la vraie, passée en iframe pas celle que vous avez dans votre navigateur) :

https://scrutin.diplomatie.gouv.fr/portail/client_welcome.html?siteLanguage=&electionId=&electionEventId=&institutionId=&pin=&j_username=toto&password=

Cette possibilité s’étend aussi au mot de passe (pin ici) et à un mystérieux « password » que je n’ai pas réussi à faire réagir…

Sur le système de recouvrement de mot de passe il est possible assez simplement de provoquer des « internal error » sans que je ne sois trop sûr de savoir à quel point elles sont gérées ou pas et ce qu’elles provoquent comme dégats exacts dans les logs ou autres parties du système :

https://mdp-scrutin.diplomatie.gouv.fr/portail/defis.html?wicket:interface=:d:challengeForm::IFormSubmitListener::

Sur ces deux systèmes il est possible de passer par du https (connexion chiffrée) ou pas. Il est donc possible de voter en utilisant par exemple un wifi ouvert du burger king du coin (c’est pour les Français établis à l’étranger on a dit… chanceux !) et qu’un utilisateur du même réseau, malveillant celui-là, surveille ce qu’il se passe sur le réseau… en clair…

Sur l’applet lui-même

On constate assez vite que le code n’a pas été le moins du monde obfusqué, ce qui rend la décompilation des binaires java un jeu d’enfant… Auquel je me suis livré brièvement (découvrant des copyright 2004 à certains endroits, des codes qu’un stagiaire n’oserait pas pondre à d’autres, …) et auquel deux anonymes ont donné un peu plus de temps avant de me soumettre leurs trouvailles.

[email protected] said :

Quelques commentaires sur l’applet de vote:
-le mot de passe est hashé avec du SHA256 et un salt hardcodé. Pas terrible, mais ça ne change rien, on est côté client. S’il y a du SSL, ça diminue le problème. (le code pourrait éventuellement supporter de l’authentification par certificat client dans des smartcards).

-le fichier ./com/scytl/pnyx/client/communication/ application/message/SecureMessageHelper.java contient un gros paquet de code chargé de l’envoi du vote (dénommé Ballot dans le code). Une clef AES est générée aléatoirement et utilisée pour chiffrer la structure de donnée envoyée. Cette clef est elle-même chiffrée avec une clef publique. J’ai l’impression que la clef publique est téléchargée à la volée. Les données peuvent donc être déchiffrées côté serveur. Impossible de savoir s’ils ont une gestion des clefs correcte.

-le vote envoyé a un identifiant, un « BallotId » généré aléatoirement. Ce n’est pas un GUID (identifiant unique), mais aléatoire. Il pourrait donc y avoir des
conflits, voire même l’écrasement d’un autre vote 😀

-le vote contient le login (et le certificat de l’utilisateur si présent). La confidentialité du vote n’est donc pas assurée. De plus, rien n’empêche un administrateur de forger un vote. A tester: modifier l’applet pour qu’elle envoie le vote avec un autre username 😀

En résumé, ça pourrait être presque sécurisé pour une application normale, mais c’est largement insuffisant pour du vote électronique. Les systèmes de vote électronique évolués utilisent généralement du chiffrement homomorphique, garantissent l’anonymat du vote et génèrent un résultat vérifiable par tous les
votants.

Un beau fail, quoi 🙂

[email protected] said (j’ai enlevé les bouts de code ici – parties marquées /* … */):

Analyse succinte de l’applet de vote electronique
————————————————-

1. Utilisation du protocole HTTP

La classe HTTPPostTransport.class (com.scytl.pnyx.client.communication.transport) contient une routine d’envoi d’information:

public String sendMessage(Map<String, String> paramMap, URL paramURL) throws TransportException
/* … */

Cette routine vérifie si le protocole de l’URL est HTTP ou HTTPS, et autorise l’envoi des données via la méthode POST. Le fichier de properties contient aussi un commentaire intéressant:

## The kind of transport. Currently only HTTP POST
pnyx.transport=HTTP

La classe HTTPPostTransport est utilisée par l’applet pour effectuer l’envoi des informations. Le choix d’HTTP et d’HTTPS se fait à partir de l’URL d’origine, un votant accédant via le protocole HTTP cause l’utilisation du protocole HTTP par l’applet. Ce point a déjà été identifié auparavant.

2. Implémentation cryptographique

Il y a des salts qui trainent dans le code de l’applet:

/* … */

Et en plus de cela, on retrouve une méthode de génération de hash de username:

/* … */

Grosso-modo, le nom d’utilisateur transmis est:

username_transformed = hexencode(hash(<hash(salt)><username><pin><hash(salt)>))

On a une routine similaire pour la génération du pin « transformé »:

public synchronized String transformedPin(Map<String, String> paramMap)
/* … */

Cette fois-ci c’est le nom d’utilisateur qui sert de « marqueur »:

pin_transformed = hash(<username_transformed><username><pin>)
pin_transformed2 = base64(hash(<username_transformed><username><pin><username_transformed>)
makeSecretKey(pin_transformed, pin_transformed2)

La routine de génération de clef est basée sur  le dernier hash calculé, généré à partir du nom d’utilisateur et du mot de passe, ainsi que le salt. Le salt est connu du client, donc peut être récupéré. Seul le mot de passe reste inconnu.

La clef ainsi générée sert à chiffrer l’ensemble des communications.

Si on couple ça au protocole HTTP, il est tout à fait possible d’intercepter une séquence d’authentification, et de bruteforcer le mot de passe (6
cars alpha minuscules).
De fait le secret du vote peut être compromis.

Je passe le fait que le salt n’est pas généré de manière aléatoire …

3. Conclusion rapide

Je n’ai pas pris le temps de regarder en détail l’intégralité du code, cette conclusion est donc quelque peu rapide et contient peut-être des erreurs, mais amha ces quelques éléments démontrent déjà que d’une part le démontre qu’il est possible d’intercepter les données du vote, et potentiellement de casser un mot de passe si on dispose de l’identifiant, et ainsi de pouvoir générer une clef permettant le déchiffrement des données. D’autre part, l’implémentation des routines crypto laisse entrevoir un possible amateurisme (il n’y a qu’à voir l’enchevetrement des appels aux fonctions de hachage imbriquées), mais cela reste à confirmer.

N’hésitez pas à contribuer ci-dessous (je désactive le log d’IP des commentaires le temps des législatives internet) ou via le formulaire de contact (même chose, il ne log pas les IP).

Vous pouvez aussi, si vous avez voté et avez rencontré des difficultés en témoigner sur le site dédié mis en place par le Parti Pirate.

Et pour vous renseigner sur le sujet : Hardkor ou Bastamag.