Pirater les élections allemandes
jeudi 11 février 2021, par Gregory Fabre
Ceci est le résumé d’une conférence donnée le 27 décembre 2020 au RC3, le congrès annuel du Chaos Computer Club, qui cette année avait lieu en ligne uniquement.
Les auteurs de cette conférence sont le Dr Johannes Obermaier et Tobias Madl.
J’ai réalisé un résumé en vidéo en français de cette conférence pour l’OSSIR que j’ai présenté par visioconférence à une cinquantaine de membres le 12 janvier 2021. Il existe une vidéo enregistrée de cette présentation, cet article en est le résumé écrit.
Élections municipales en Bavière
Les deux auteurs de la conférence étaient bénévoles pendant le dépouillement des élections municipales en Bavière au début de 2020.
Le décompte des voix en est informatisé.
C’est un peu compliqué en Allemagne, on compte 599 candidats et 9 partis. Une personne détient 70 votes, et peux voter pour plusieurs partis. Elle a la possibilité de barrer des noms d’un parti, et peut voter jusqu’à trois fois pour la même personne.
Logiciel de décompte
Le logiciel se prénomme « OK Vote », il détient 75% des parts de marché en Allemagne. Il ne permet que le décompte des votes, pas le vote lui-même, cela n’étant légalement pas possible en Allemagne.
Le logiciel est censé être très « sécurisé », suivant les recommandations de l’OWASP et de l’Office fédéral de la sécurité des technologies de l’information, et hébergeant ses données dans un datacenter certifié. En pratique, lorsque les auteurs ont allumé l’ordinateur pour le faire tourner, ils ont constaté qu’il utilisait Windows XP, un système d’exploitation âgé, qui n’est plus maintenu par Microsoft et qui dispose de ce fait de nombreux trous de sécurité non résolus. Ça commençait mal…
En pratique
Comment se déroule une séance de décompte des voix ? On compte les votes puis on saisit le décompte dans le logiciel, chacun des auteurs de la conférence étant dans une équipe différente. L’équipe principale portait le numéro 1, l’autre le numéro 2.
Une fois le décompte réalisé, l’équipe 2 exporte les résultats vers une clef USB. Puis la clef USB est placée dans le PC principal qui doit centraliser les votes. On importe alors les résultats de l’autre équipe, puis on engendre un rapport qu’on exporte vers un fichier.
Déjà des risques
Les problèmes à première vue sur ce mode de fonctionnement sont les suivants :
- Il y a un grand manque de transparence
- Le logiciel est propriétaire et donc pas publiquement audité
- Les PC qui hébergent le soft ne sont pas administrés, ils sont mis à disposition par le centre de vote, par exemple une école. Ils peuvent donc être compromis.
Ensuite les clefs USB sont apportées par un volontaire en voiture jusqu’à un bureau central. Cela ouvre la porte à des problèmes, comme la manipulation des fichiers pendant le transport. Il n’y a malheureusement pas de contrôle particulier au central à part des mécanismes trop simples, et pas de réelle authentification :
- Uniquement un contrôle d’intégrité (CRC32 et SHA-2 à 256 bits)
- Pas de signature cryptographique efficace
Si on modifie les données on peut facilement calculer un nouveau hash. Enfin, une personne unique transporte les clefs et peut donc modifier les données.
Architecture du logiciel
Voici l’architecture du logiciel de décompte des votes :
- Apache Tomcat
- MariaDB
- Firefox portable
L’utilisateur se connecte au logiciel en lançant Firefox. Cette architecture protège-t-elle de l’utilisateur lui-même et du réseau ?
Attaque simple par URL
Lorsque l’on est connecté en administrateur au logiciel, on voit apparaître des possibilités supplémentaires dans les menus, par exemple l’export des données.
Voici deux URLs permettant d’effectuer deux tâches d’administration :
- Rouvrir l’élection
- Effacer des données
Si on essaie d’y accéder en tant qu’utilisateur on s’aperçoit… qu’elles sont accessibles aux non administrateurs !!! Donc s’il connaît l’URL un utilisateur standard peut accéder aux fonctions sans restriction…
En fait il y a une fonction censée effectuer la vérification mais… elle n’est pas codée ! Elle renvoie NULL !
Facile d’éviter les bugs dans la vérification d’accès : il suffit de ne pas la faire...
Comment éviter cela ? Il ne faut jamais imaginer qu’une information cachée est protégée. De plus, il faut impérativement implémenter les contrôles d’accès !
Attaque numéro 2 : inter site (Cross-site attack)
Le principe est de faire quelque-chose sur un site à la place de quelqu’un d’autre. Le logiciel étudié présente une protection minimale dans les en-têtes HTTP :
SAME ORIGIN // On ne peut pas inclure dans une frameX-XSS-Protection : 1
Malheureusement il n’offre pas de protection contre les attaques Cross-site request forgery. L’utilisateur visite un site web malveillant, qui contient un formulaire qui ressemble à un des formulaires du logiciel de comptage des votes.
Le formulaire est renvoyé depuis le site malicieux, et Tomcat est trompé : il ne peut pas faire la différence puisque c’est l’utilisateur qui envoie les données.
C’est une attaque assez ancienne, elle date de 2001. Beaucoup de sites sont donc protégés contre elle... mais pas ce logiciel là, alors que nous étions en 2020 !!!
Une interaction minimale est nécessaire : le clic sur un lien, ce qui est relativement facile à engendrer chez un utilisateur. L’impact est énorme on peut modifier les réglages du logiciel et insérer des faux votes : on peut donc manipuler l’élection !!!
Démonstration
On se connecte à l’interface d’administration du logiciel. Nous sommes “admin321934”.
Sur cet écran on visualise les bulletins qui ont été saisis, pour l’instant il n’y en a pas.
Puis on saisit on saisit un bulletin, pour cet exemple on a deux partis imaginaires : – Les gentils (Good Party) – Les méchants (Bad Party) qui veulent truquer l’élection et prendre le pouvoir
L’électeur a voté pour les gentils, on saisit donc trois bulletins de la sorte. Quand on revient au menu, on voit les trois bulletins apparaître.
Si on affiche les résultats temporaires de l’élection, on voit que trois bulletins ont été dépouillés, et que les trois votes pour le parti gentil ont été correctement comptabilisés.
Maintenant l’utilisateur fait une pause, et va visiter un profil Twitter et s’émeut d’une jolie photo d’un chat mignon ! Il y a un lien dans le tweet sur lequel l’utilisateur clique et arrive sur page présentant des photos a-do-rables !
Oh comme c’est mignon ! Regardez ces adorables photos d’animaux trop chou !
Bon fermons maintenant ces onglets et retournons à notre logiciel de dépouillement de scrutin.
Oups ! Il semble que je ne m’appelle plus « admin » mais que mon nom a changé… Le site a exécuté une attaque CSRF sur le logiciel de décompte…
Trois bulletins sont toujours dépouillés mais… dans les résultats, le nombre de bulletins dépouillés a augmenté, on en voit maintenant 8 !!! Cela en fait 5 de plus que nous n’avions pas saisis.
Le parti gentil a toujours 3 votes mais... le parti méchant a maintenant gagné 5 votes et il est placé en tête !!!
Cette attaque a manipulé le résultat des élections. Nous l’avons remarqué car nous nous y attendions mais nous ne l’aurions pas remarqué sinon !
Analyse de sécurité réseau
Passons à un autre sujet, une attaque de l’application depuis le réseau. Un petit scan de l’application laisse rêveur : tout est ouvert et notamment Tomcat et MariaDB...
Tentons alors une vulnérabilité qui date de 2020 nommée Ghostcat.
Apache a un répertoire racine qui sert du statique et du python. Il peut aussi servir des classes java qui sont combinées au statique et envoyées à l’utilisateur.
Voici l’attaque :
– Destination – Fichier à lire : la classe java privée, qui est une fonction utilisée pour des tests unitaires – Fonction : « lire »… parce-qu’il serait également possible de l’évaluer et d’y exécuter du code…
On exécute l’attaque, et elle fonctionne, on reçoit le code binaire de la classe demandée. On l’ouvre dans java-decompiler (JD) et on peut ainsi visualiser son code source et on y trouve... la chaîne de connexion à la base de données. Et ce n’est pas un test, c’est le mot de passe réel de production de l’accès root de la base de données !!!
Donc cette attaque a permis d’accéder à tout le code source de l’appli dans lequel on a retrouvé des mots de passe codés en dur.
Comment éviter ce qui est arrivé et réduire la surface d’attaque ?
– Ne jamais exposer de ports inutiles – Mettre à jour les composants de toute l’architecture – Ne pas utiliser de mots de passe de production pendant les tests unitaires
Sécurité de la base de données
Maintenant que nous avons le mot de passe de root de la base essayons d’attaquer la base de données.
Si on jette un œil à la table des utilisateurs, on voit qu’il faut avoir le mot passe de root depuis localhost, mais que depuis la machine qui s’appelle « PCI90309 » sur le réseau, on peut accéder à la BDD sans mot de passe en tant que root. Bizarre non ? On dirait une porte dérobée.
Mais pourquoi pas maintenant qu’on a une porte d’entrée par le réseau essayer d’aller plus loin… Et par d’autres vulnérabilités essayer d’exécuter du code sur la machine cible ?
On a donc le serveur cible. On nomme une autre machine « pci90309 », et on se connecte directement comme root à la base... sans mot de passe. On demande à MariaDB d’activer un plugin qui s’appelle « ha_connect » qui permet de faire correspondre un fichier au contenu d’une table.
Puis on crée une table qui s’appelle « PWN ». On demande au plugin de mapper un fichier, au joli nom de « pwn.dll » sur cette table, puis on demande à MariaDB d’activer un nouveau plugin contenu dans cette DLL et nous voici avec une exécution de code à distance sur le serveur !!!
Nous voici maître du serveur, on peut tout y faire.
Encore une petite démo
Voici le serveur qui héberge le système de comptage de votes. On lance le serveur Tomcat, la machine malveillante sur le réseau se connecte et uploade la DLL malveillante sur le serveur.
Pour la démo, la dll en question est la calculatrice de Windows. La voilà qui apparaît à l’écran, donc l’exécution de code a fonctionné sur le serveur... le système de comptage de votes est sous le contrôle de l’attaquant.
Responsible disclosure
Les chercheurs ont prévenu l’éditeur du logiciel, qui a été très professionnel et rapide : il a répondu immédiatement. Il a indiqué que le logiciel était destiné à être utilisé dans un environnement réseau sûr… mais nous avons vu que cela n’était pas le cas. Par ailleurs ce n’est pas une bonne solution ni une bonne réponse. L’éditeur a ensuite annoncé des mises à jour.
Résumé
Si on résume : – Le logiciel tourne sur des PC non sûrs qui auraient pu être manipulés avant l’élection – Le logiciel manque de transparence – Le logiciel serveur est vulnérable à des attaques
On peut donc manipuler le résultat du vote.
Note de l’auteur de cet article : cela devrait nous inciter à la plus grande prudence au sujet du vote électronique.