Hack in Paris 2016 – Résumé des conférences

Le Hack in Paris 2016 a eu lieu les 30 juin et 01 juillet 2016 à … Paris! Deux jours de conférences dédiées à la Sécurité Informatique avec des intervenants du monde entier.
Cet article contient un certain nombre de résumés de conférences ayant eu lieu durant ces deux jours. J’espère être resté fidèle aux propos des intervenants, mais il n’est pas exclus qu’une erreur se soit glissée. N’hésitez pas à commenter l’article pour indiquer une correction.

Parmi toutes les conférences, j’ai décidé de me focaliser sur cinq d’entre elles. Pour les autres conférences dont j’ai retrouvé la présentation, je mets le lien en bas de l’article. Au programme, les conférences traitées ci-dessous seront « Voting between sharks », « Whisper in the Wire: Voice Command Injection Reloaded », « What could have derailed the Northeast Regional no. 188? », « All Your Door Belong To Me – Attacking Physical Access Systems », « 3 APIs + 1000 lines of code = Super pretty OSINT ».

[Mise à jour du 20/09] J’ai mis les vidéos des conférences concernées directement dans chaque article, mais vous pouvez retrouver l’ensemble des présentations sur la Playlist YouTube : https://www.youtube.com/playlist?list=PL3UAg9Zuj1yJ_6pySNwbJWi_M1RqJU7Wf

Voting between sharks

Lien vers la présentation : Non trouvé…
Intervenants : Jesus Choliz , Sandra Guasch

La première conférence a traité des votes par Internet, soit à partir de chez soi, soit à partir d’une machine de vote.

Habituellement quand on vote, on prend tous les papiers des candidats, on se met dans l’isoloir, on met le papier du candidat retenu dans une enveloppe et on dépose l’enveloppe dans une urne. Ensuite, les enveloppes sont ouvertes et les résultats comptabilisés, sous le regard d’observateurs qui vérifient que tout se déroule bien.

Par contre, en ajoutant des machines connectées à l’Internet, comment s’assurer que le nom du candidat sur lequel j’ai cliqué est bien le nom enregistré auprès du gestionnaire du vote? Se pose ainsi tout un tas de questions sur les possibilités de sécuriser ce type de vote. Ces questions, Jesus Choliz et Sandra Guasch se les sont posées et ont décrit les solutions qui existent permettant d’assurer une sécurité de bout en bout lors d’un vote électronique. Pour cela, ils ont découpé leur présentation en sept volets.

1) La confidentialité

Un vote doit rester secret. Sauf qu’une machine fait transiter énormément d’informations sur le réseau sur lequel elle est reliée : adresse IP, informations d’authentification, timestamp, etc…

Pour sécuriser ces informations, ils préconisent l’utilisation de token anonyme ainsi que le « mix-net ». Avec ce système, tous les votes sont mélangés et la partie « vote » (bulletin) est dissociée de la partie « votant » (authentification, adressage, etc…).

2) L’intégrité

Sur le même principe que pour les échanges de mails, l’intégrité des échanges peut être respectée en utilisant des certificats ou des signatures.

3) Les Malwares

La présence d’un malware sur votre ordinateur pourrait volontairement fausser votre vote ; ainsi, vous avez beau cliquer sur PiXel pour qu’il devienne président, votre vote ira à Nan0! Ainsi, s’il réussit une attaque en masse, Nan0 sera ainsi élu avec 100% des voix. 🙂

Pour contrer ce cas, les conférenciers ont proposé la vérification d’un code alphanumérique généré par l’application et un code, normalement identique, transmis quelques jours plus tôt par voie postale. Sur le même principe, la validation du vote pourrait se faire par échange de clé entre l’application et l’utilisateur via son smartphone (SMS ou QR Code).

Ainsi, les points 1, 2 et 3 permettent de s’assurer d’une transmission de bout en bout du vote.

Mais maintenant que mon vote est transmis à l’organisateur, des personnes malveillantes de cet organisme pourraient tout à fait le modifier.

4) Les sociétés extérieures

Avec l’intervention d’intermédiaires supplémentaires, et donc de sociétés extérieures, pour gérer les infrastructures et les applications, c’est tout autant de possibilités d’entraves au bon déroulement des votes (interception des votes, blocages des flux, etc…).

5) Le secret du vote

Dans un vote classique, on rentre seul dans un isoloir. Si on rentre à plusieurs, ça devient rapidement suspect. Par contre, avec le vote électronique, les capacités d’écoute sont bien plus discrètes (keylogger, sniffer de paquets réseaux, impression d’écran à la volée, etc…).

Le même problème s’était posé précédemment avec la prise de photos depuis son smartphone dans l’isoloir. Généralement cela est fait dans un but politique (soutien à un candidat), mais on pourrait très bien penser à l’envoi d’une preuve de vote envoyée à une personne qui vous menace.

En contremesure à cela, j’avais noté l’utilisation de vote multiples. Je ne me souviens plus vraiment à quoi cela faisait allusion. Peut-être l’utilisation de plusieurs lignes de votes pour un même candidat, mais je ne suis plus sûr… Toutes mes excuses pour ce manque de concentration. 🙂

6) Le piratage

Pour lutter contre le piratage, il faut « réduire la surface ». Cela veut dire qu’il faut réduire autant que possible les possibilités d’attaques. Dit comme ça, ça a l’air simple, mais contrairement à des applications Web qui restent disponibles sur l’Internet 7j/7 et 24h/24, une application de vote ne restera en ligne que quelques heures, sur une ou deux journées (avec les deux tours).

7) L’administrateur système

L’administrateur système c’est la dernière personne qui aura accès aux informations de vote. L’accès ne sera peut-être pas « numérique », puisque toutes les données ont été correctement chiffrées et dissociées (vote/votant), mais je doute que beaucoup de serveurs résistent à des coups de batte de baseball, à une chute de quelques mètres, ou plus discrètement à une surtension électrique. Pensez à toute la sécurité logicielle d’une application est important, mais il ne faut pas oublier la sécurité physique (accès aux salles, confiance dans les personnes physiquement autorisées à accéder aux serveurs, etc…).

Whisper in the Wire: Voice Command Injection Reloaded

Lien vers la présentation : https://www.researchgate.net/publication/304789264_20160630_Whisper_in_the_Wire-Voice_Command_Injection_Reloaded

Intervenants : Chaouki Kasmi , Jose Lopes Esteves

La conférence a été présentée par deux personnes du laboratoire de sécurité sans-fil de l’ANSSI (l’Agence Nationale de Sécurité des Systèmes d’Information), Chaouki Kasmi et Lopes Esteves José.

En tant que lecteur de ce blog, je peux présager que vous savez tous ce qu’est un « assistant personnel intelligent ». Non? Et si je vous parle de « Siri », « Ok Google », « S Voice » ou encore « Cortana », ça devrait vous rappeler des choses?

Avec ces assistants, on peut donc envoyer des messages, faire une recherche sur Internet, afficher vos mails, ou bien encore passer un appel, et bien d’autres choses encore. Et dans tous les cas, excepté pour l’émission d’appel, le téléphone vous demande de vous authentifier (code pin, dessin sur l’écran, ou maintenant capture de l’iris, avec le Samsung Galaxy Note 7).

Le fonctionnement est le suivant :

  1. Appel à l’assistant (« Dis Siri », « Ok Google » ou appui sur le bouton adéquat)
  2. Énoncer un ordre
  3. Envoi de l’ordre vocal sur le Cloud
  4. Reconnaissance vocale auprès des serveurs du prestataire
  5. Retour de l’ordre « textualisé »
  6. Exécution

Le problème avec ces assistants c’est qu’une vérification du donneur d’ordre n’est pas toujours effectuée. De plus, le fonctionnement se base sur le Cloud, c’est à dire que sans accès au Web, l’assistant restera muet. Le dernier point, c’est qu’il est sensible aux attaques locales. Un exemple : j’ai entendu parlé d’une méthode qui consistait à placer des ordres vocaux dans des vidéos YouTube. L’ordre n’est pas perceptible par notre oreille humaine, mais parfaitement interprétable par le smartphone.

La méthode d’attaque présentée dans la conférence apporte la même finalité, exécuter des ordres de façon non souhaitée, mais elle est encore plus discrète. Imaginez, vous arrivez dans un bureau, ou une salle d’attente, et vous branchez votre smartphone sur une prise électrique pour le recharger. Et maintenant, à partir de là, toute la « magie » opère !

En fait, la victime pense avoir branché son portable sur une prise électrique classique. De toute façon, il n’y a pas de possibilité d’interaction entre le téléphone et une prise électrique, ce n’est pas comme s’il avait branché son smartphone sur le port USB d’un ordinateur…

Sauf qu’en fait, le câble d’alimentation, passe dans un injecteur de champs électromagnétique qui va injecter les mêmes perturbations électromagnétiques que lorsqu’un assistant est utilisé, et en prenant en compte que le connecteur USB et le microphone des smartphones sont extrêmement proches, le micro prend ces perturbations pour des paroles, ce qui entraine le « réveil ». Avec le même procédé, des ordres peuvent même être donnés à l’assistant, sans que quiconque n’entende quoi que ce soit.

En complément, les conférenciers ont rappelé qu’Apple a déclaré lors de la dernière WWDC (conférence Apple à destination des développeurs) qu’ils allaient mettre à disposition une API permettant aux applications tierces d’interagir avec Siri. Cela va peut-être apporter de nouvelles méthodes d’attaques…

What could have derailed the Northeast Regional no. 188?

Lien vers la présentation : http://fr.slideshare.net/moshez/abusing-the-train-communication-network-or-what-could-have-derailed-the-northeast-regional-188

Intervenant : Moshe Zioni

NB : il ne s’agit pas ici des résultats d’une enquête officielle. Il faut voir cette analyse plus comme la vérification d’une hypothèse. Suite à l’accident, plusieurs théories ont vu le jour à ce sujet. Celle exposée ci dessous n’est qu’une parmi d’autre. Pour information, elle n’a pas été retenue lors des résultats de l’enquête officielle.

Philadelphie, le 12 mai 2015. Un train, composé d’une locomotive et de sept wagons, déraille à la frontière du New Jersey. L’accident est tel qu’il causera la mort de huit personnes et blessera plus de deux cents autres personnes. Assez rapidement, la cause de l’accident est établie, le train roulait à une vitesse bien supérieure à ce qui était prévu, il roulait à plus de 100 mph, dans une courbe à 4° où la vitesse normale aurait dû être de 50 mph.

Plusieurs causes ont été avancées, mais une retiendra l’attention de Moshe Zioni : « et s’il s’agissait d’une cyber attaque ».

Pour étayer son hypothèse, Moshe Zioni s’est basé sur les informations techniques de la locomotive. Elle utilise le système d’automatisation Siemens SIBAS 32. Ce système permet de contrôler les fonctions de traction et de contrôleur. Les échanges s’appuient sur différents bus de dialogue pour contrôler la puissance, les freins, la climatisation, les portes, etc… Chaque bus possède son propre identifiant et tous n’ont pas les mêmes privilèges.

Par contre, en terme de sécurité, on voit rapidement que ce point n’a pas été pris en compte lors de la conception du système : toutes les transmissions se font en texte brut, sans aucune authentification, ni chiffrage, ni contrôle d’intégrité. De plus, le système vérifie régulièrement la présence de ces modules, mais lorsque de nouveaux modules sont ajoutés, il les intègre directement : il y a donc un risque d’intégrer des modules défectueux ou vérolés sans vérification préalable.

En prenant également en compte que les compagnies ferroviaires (européennes ou américaines) intègrent désormais la connexion WiFi, donc les contrôleurs sont reliés au reste du système du train, cela laisse craindre d’éventuelles dérives en ce qui concerne des accès non autorisés.

Page Wikipedia de l’événement : https://en.wikipedia.org/wiki/2015_Philadelphia_train_derailment

All Your Door Belong To Me – Attacking Physical Access Systems

Lien vers la présentation : http://fr.slideshare.net/centralohioissa/valerie-thomas-all-your-door-belong-to-me-attacking-physical-access-systems

Intervenante : Valerie Thomas

La sécurité, en Informatique, commence à bien être prise en compte lors du développement de logiciels. L’époque, pas si lointaine, où la Sécurité n’était qu’une dépense inutile dans une entreprise fait désormais parti du passé. Mais comment est pensée la sécurité des contrôles d’accès? Vous savez, ces badgeuses et autres lecteurs de cartes, qui protègent l’accès à nos salles serveurs, le lieu où les données sont le plus vulnérable. Valerie Thomas nous présente ici un état de l’art en matière de sécurité des accès physiques.

Aujourd’hui, les contrôles d’accès physiques s’intègrent de plus en plus dans notre quotidien : pass Navigo, badge d’entreprise, serrures de chambres d’hôtels, lecteurs biométriques, etc… Pour le fonctionnement, ils ont besoin de plusieurs briques :

  • Le point d’accès : porte, portique, tourniquet, sas, etc…
  • Le lecteur d’identifiant (ou credentials) : badgeuse, lecteur biométrique
  • l’identifiant : carte RFID, pass Navigo, œil
  • Le serveur de contrôle d’accès (connecté au réseau)

Par contre, parfois les informations contenues ou échangées entre les différentes briques ne sont pas chiffrées. Parfois, elles le sont, mais malheureusement, elles sont généralement faiblement chiffrées, comme les clés contenues sur les cartes qui sont codées sur 64 bits, et sont fixés par le fabricant. Et d’autre fois, la sécurité des données ou des échanges ne servent à rien, puisque le point d’accès, le dernier maillon de la chaine, est vulnérable. En exemple (en vidéo lors de la conférence), une porte vitrée qui bloque l’accès à une salle serveur, mais un petit coup sur le porte et le fait de la guider à la main, fait qu’elle s’ouvre sans résister…

Il devient donc urgent de fiabiliser ces outils, ces équipements, pour que la sécurité soit présente de bout en bout de la chaine.

3 APIs + 1000 lines of code = Super pretty OSINT

Lien vers la présentation : Non trouvé… 

Intervenant : Matias Katz

Prenez trois API : Twitter, Google Maps, et Python NLTK, ajoutez une bon millier de lignes de code et vous obtenez un excellent outil de renseignement analytique (OSINT pour Open Source Intelligency).

L’OSINT consiste à récupérer de l’information et à lui donner une valeur ajoutée. En soit, la donnée n’est pas très utile, mais si on la croise avec deux sources d’informations, elle commence à avoir de la valeur.

1) Twitter

Pour l’exemple donné lors de la conférence, Twitter sera la principale source d’information. Pour récupérer les informations souhaitées, on va utiliser l’API de Twitter, ainsi que le module twitter pour Python. Cela permettra d’automatiser la recherche de Tweets contenant les mots clés qui nous intéresse.

2) Google Maps

La plupart des Tweets contient les informations géographiques de l’utilisateur lors de son émission (à condition, bien sûr, d’avoir autorisé cela dans les paramètres du smartphone utilisé). Il est donc possible de croiser les Tweets de l’étape (1), avec une carte, afin de les placer géographiquement.

Ça commence à prendre un peu de forme, mais à quoi bon placer des Tweets sur une carte. Ce n’est pas ce qu’il y a de plus renversant comme fonctionnalité!

3) Python NLTK

La librairie Python NLTK permet de faire de l’analyse de phrase. Elle permet, par exemple, de noter une phrase entre 0 et 100 pour déterminer les avis négatifs (0) et les avis positifs (100). Elle se base sur des fichiers d’expressions positives et négatives, mais en faisant une analyse de ces expressions, ce n’est pas juste une simple reconnaissance de mots. Cela lui permet également d’apprendre par elle-même.

Maintenant, en reprenant les points (1), (2) et (3), et en se focalisant sur l’exemple choisi par le conférencier, le Brexit, on arrive à une carte du Royaume Uni avec un ensemble de points rouges et de points verts pour matérialiser les différents avis sur le Brexit, en fonction des régions. On possède dont maintenant un outil de sondage avec un échantillonnage large et actualisé en temps réel. Et parti de là, les données récoltées sur Twitter ont désormais une véritable valeur ajoutée. Ce n’est plus l’avis d’une personne isolée dans un endroit inconnu, mais l’avis de milliers de personnes réparties sur un pays. Et bien évidemment, cet exemple pourrait être repris pour toutes sortes de sujets : élections, opinions publiques, etc…

From zero to SYSTEM on full disk encrypted Windows system

Lien vers la présentation : http://fr.slideshare.net/NabeelAhmed7/from-zero-to-system-on-full-disk-encrypted-windows-system

Intervenants : Nabeel Ahmed , Tom Gilis

DIFFDroid – Dynamic Analysis Made Easier for Android

Lien vers la présentation : http://fr.slideshare.net/antojoseph007/diffdroidantojosephhip2016

Intervenant : Anto Joseph

HARDSPLOIT TOOL : The next Hardware Hacking Laboratory ?

Lien vers la présentation :  https://events.ccc.de/congress/2015/Fahrplan/system/event_attachments/attachments/000/002/859/original/32C3-HARDSPLOIT.pdf

Intervenant : Yann Allain , Julien Moinard

Because of the advancements in prosthetics

Lien vers la présentation : http://fr.slideshare.net/EC-Council/security-concerns-of-future-technology-arriving-today-gregory-carpenter

Intervenant : Gregory Carpenter

Laisser un commentaire

Votre adresse mail ne sera pas publiée. Champs requis *

Vous pouvez utiliser ces balises HTML et attributs: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Vous pourriez être intéressé par