Une conférence nommée Hack.lu !

Sécurité de l'information
Une conférence nommée Hack.lu !

Nous voici de retour du Luxembourg où s‘est tenue la 11e édition de la désormais réputée Hack.lu. Cet événement de 3 jours dédié à la sécurité informatique s’est déroulé au Parc hôtel Alvisse du 20 au 22 Octobre 2015.

Comme chaque année, 300 à 400 personnes venant des quatre coins de la planète ont pris part à l’événement. Une population essentiellement composée de professionnels de la sécurité (pentesters, chercheurs, directeurs techniques, RSSIs, consultants ou encore journalistes spécialisés) qui viennent profiter de l’expérience et de l’expertise des présentateurs.

Certains partenaires étaient également présents pour dévoiler leurs derniers produits. Nous pouvions par exemple observer des nouveautés dans le secteur des imprimantes 3D, des modules de domotique ou encore les dernières nouveautés en termes de firewalling.


Figure 1 - Salon de présentation Partenaires

La Hack.lu est considérée comme l’une des plus célèbres conférences de sécurité Européenne. Celle-ci est très technique et traite un large panel de thèmes (Forensics, analyse de malwares, Internet des objets, techniques d’intrusion…). Au total, 28 « Talks » de 45 minutes chacun permettent aux chercheurs en sécurité, pentesters, membres de CERT ou encore directeurs techniques de présenter leurs travaux et découvertes.

En dehors de ces présentations, des workshops sont organisés. Ceux-ci se présentent sous forme d’ateliers d’environ 2h30 où les participants ont la possibilité de passer à la pratique sur différents sujets (Sécurité des environnements industriels (SCADA), reverse engineering, analyse de fichiers Office malicieux…)

Il est aussi possible de participer à un concours : le célèbre CTF ou « Capture The Flag ».

Organisée depuis la création de la Hack.lu en 2004, cette épreuve peut être réalisée sur place ou en ligne. Pour cette édition 2015, 442 équipes se sont affrontées durant 48 heures en non-stop afin de résoudre de nombreux petits challenges autour du chiffrement, de la sécurité Web, des forensics…

Comme chaque année depuis maintenant 6 ans, c’est l’équipe FluxFingers de l’université de Bochum dans la Ruhr en Allemagne qui est à l’origine de cet événement toujours très convoité.


Figure 2 - Logo de FluxFingers

 


Figure 3 - L'équipe FluxFingers

L’accès à l’ensemble de ce contenu a un coût : 350€

Ce tarif n’est pas excessif au regard du contenu des 3 jours de conférence et de l’organisation. En effet, le badge d’entrée donne accès à l’ensemble des « Talks », « Workshops », « Capture The Flag » et fournit au quotidien la nourriture et les rafraichissements nécessaires tout au long de la journée. Pas d’excuses pour ne pas prendre de petit-déjeuner ! À noter que le déjeuner est également compris.


Figure 4 - Une pause déjeuner bien méritée

AU BOULOT !

Nous allons maintenant vous présenter quelques conférences que nous avons sélectionnées. Petit panel de ce qui nous a marqués durant ces 72 heures intensives.

Note : Les esprits curieux peuvent retrouver l’ensemble des sujets abordés sur le site de la Hack.lu 2015

1. "Totally Spies"

Dans cette conférence de Joan Calvet (@joancalvet), Marion Marschalek (@pinkflawd) et Paul Rascagnères (@r00tbsd), nous avons découvert que la série de malwares « Babar » ne fait que continuer.

Ce premier malware avait été arbitrairement attribué aux services secrets français (contrairement à « Regin » attribué à la NSA) d’après les documents classés publiés par Edward Snowden sur l’opération « Snowglobe » et d’après les différentes empreintes trouvées dans le fonctionnement des différents binaires par des reversers.

« Babar » serait en réalité à l’origine d’une longue série nommée « Animal Farm » suivie par :

  • « Nbot » la même année
  • « Bunny » en 2011
  • « Dino », découvert en Iran en 2013
  • « Casper » découvert en Syrie en 2014
  • « TaFaCalou » en 2013/2014 conjointement utilisé en tant que premier stage d’infection suivi par « Dino » et « Casper »

L’attribution à la France et à ses services secrets est de plus renforcée par la corrélation des faits suivants :

  • Les noms des paramètres, des fonctions et des méthodes appelées par les binaires contiennent des fautes d’anglais basiques, pouvant ressembler à celles que font les Français en général:

  • Un des serveurs de contrôle (ou « C&C ») des malwares contient des répertoires pouvant être les acronymes de 3 des 6 noms de ces malwares (« bb » pour « Babar », « tfc » pour « TaFaCalou », « d » pour « Dino »), ils seraient donc à priori liés
  • Le nom d’utilisateur du développeur serait « titi », pouvant être le surnom du prénom français « Thierry »
  • Bernard Barbier (Directeur technique de la DGSE de 2006 à 2013) aurait à demi avoué l’attribution dans une interview sur ce sujet en affirmant que la France aurait « été jugée assez efficace finalement »
  • Le malware émet des requêtes http avec l’en-tête « Accept-Language : fr »
  • Les chemins des sources du malware contiennent le terme Français « arithmetique » :

De plus, une information donnée par Kaspersky et ne figurant pas dans la conférence :

  • Un des stages d’exécution de Dino et Babar serait le malware nommé « TaFaCalou » qui serait ensuite mis à jour vers ces derniers. « Ta Fa Calou » pourrait être une interprétation en français de l’Occitan se rapprochant de « ça devient chaud ».

Nous avons pu d’autre part découvrir que les techniques d’évasion du malware contre les solutions de sécurité évoluent au fil du temps, ce qui rend de plus en plus complexe la détection et la rétro-ingénierie :

  • Tous :
      > L’API est offusquée
      > L’antivirus est détecté via la lecture de clés en WMI
      > Les « bacs à sable » (ou « sandbox ») sont détectés via les noms des exécutables
  • Dino:
      > les modules sont entièrement chiffrés sur le disque
      > il utilise un système de fichier temporaire chiffré, chargé en mémoire et déchiffré à la demande lors d’appels aux modules
  • Casper:
      > l’exploit, le binaire, et le C&C étaient hébergés sur le site du Ministère de la Justice syrienne pour masquer son origine, et pour que la rétro-ingénierie puisse l’attribuer à la Syrie
      > ses techniques d’évasion s’adaptent en fonction de l’antivirus présent
      > il termine son processus si les adresses mémoire prévues sont altérées
      > la charge malveillante s’adapte en fonction du système où le binaire original est lancé

Malgré ces nombreuses traces aucun service français n’a officiellement confirmé cette hypothèse et aucune preuve incontestable n’a pour l’instant était relevée. Le mystère reste donc entier.

2. « Learn from Malwares, A Practical guide of spear phishing for Red Teams »

Paul Jung (Excelium) nous a fait un retour sur l’état de l’art et les techniques les plus utilisées afin de mener des campagnes de phishing efficaces.

Une campagne bien menée commence par la collecte d’informations en plusieurs étapes :

  • La récupération d’adresses email via les moteurs de recherche, par exemple avec le programme « The Harvester » disponible sur Internet
  • La recherche, par exemple sur Linkedin ou Viadeo, une fois qu’on a trouvé le format des adresses de l’entreprise et le nom de domaine, ou par exemple avec les Google « dorks » : « Advens inurl:linkedin.com +LinkedIn +"Entreprise actuelle" »

Puis la seconde étape :

  • La validation des adresses email via les relais SMTP : peu d’administrateurs surveillent en temps réel les journaux des services SMTP, et de plus ceci ne nécessite qu’une seule connexion TCP et c’est donc plutôt discret :

  • Tester les noms de famille les plus connus : difficile à réaliser dans certains pays du fait des différentes langues parlées

Il est alors possible de mener l’attaque, en utilisant également des techniques augmentant la probabilité de réussite :

  • Utiliser le nom de destinataire en temps qu’expéditeur : difficile à réaliser aujourd’hui car la plupart des serveurs mails bloquent ce comportement
  • Utiliser le « punycode » pour un nom de domaine en Cyrillique :

  • Les en-têtes sont souvent filtrés, par contre le contenu « body » l’est rarement, on peut donc essayer de tromper le destinataire en forgeant le contenu du mail spécialement :

  • Utiliser un nom de domaine ressemblant à l’original, par exemple : http://www.mybank.com.id.fa3bf54.param.34234.evil.com
  • Faire attention aux heures, aux dates d’envoi et aux personnes ciblées car :
      > Si envoyé au « top management », les emails sont souvent ouverts sur tablette type « iPad », si envoyé trop tard ou le weekend end : les emails sont souvent ouverts sur un smartphone. Ceci réduit en général les possibilités d’infection par un malware ou en tout cas les données sensibles récupérées sur ce type de support.
      > Les cibles type « médias » ou « médicales » ouvrent en majorité leurs emails sur des Apple (Mac), ce qui limite également les probabilités d’infection de manière générale

Afin de contourner la détection du malware :

  • Les exploits sont en général compliqués à mettre en œuvre
  • Les macros Office restent le meilleur vecteur d’attaque car faciles à utiliser et à développer, et passent mieux les solutions de sécurité car les employés ont en général besoin de ce type de contenu pour leur travail. Ceci a notamment été utilisé pour les campagnes d’infection du vers « Dridex » et qui a très bien fonctionné.
  • Les nouvelles versions de « Dridex » utilisent l’extension MHTML et des macros offusquées, ce qui reste très mal contrôlé par les solutions de sécurité
  • Utiliser un binaire offusqué avec un « packer » maison reste la méthode la plus fonctionnelle et la plus efficace de manière générale. Utiliser le packer UPX est beaucoup trop vite détecté aujourd’hui car les signatures sont très connues.
  • Obtenir un email en provenance de la cible avant de mener une attaque permet d’obtenir des informations techniques sur la configuration de son poste et du service de messagerie dans les en-têtes SMTP, et donc de cibler les attaques
  • Pour passer les contrôles de bac à sable (« sandbox ») : utiliser une boucle assez longue avant de lancer le vrai exécutable malveillant est une technique efficace. Pour détecter une sandbox il est possible de le faire simplement : en détectant si la machine est dans un domaine par exemple.
  • Pour passer les contrôles des antivirus : lancer une condition improbable ou un second exécutable inoffensif afin d’empêcher la détection
  • Utiliser l’API Windows WinInet afin de ne pas avoir à détecter la configuration d’un éventuel proxy web nécessaire pour exfiltrer les données par Internet, et de plus cette technique réduit les risques de détection
  • Utiliser le protocole DNS : les requêtes DNS sont rarement journalisées et rarement surveillées par les administrateurs et les pare-feu
  • Enfin, étudier les techniques d’évasion de « Babar » (et ses amis) ainsi que les documents fuités de « Hacking Team » reste une bonne technique rapide pour rendre indétectable un malware

Paul nous a ensuite fait un retour d’expérience sur une campagne de phishing d’un an :

  • Est-ce que les utilisateurs continuent de cliquer sur des liens malveillants ? la réponse est « OUI » !
  • Sur 1200 emails envoyés avec un lien très mal forgé (remarquable avec peu de connaissances techniques) et en utilisant une adresse mail expéditrice ressemblant à celle d’un collaborateur interne :
      > Succès d’infection de 33% des personnes ciblées
      > 44% de femmes et 56% d’hommes : « la secrétaire » n’est donc pas la plus vulnérable contrairement aux mauvaises idées reçues !
      > En demandant une action à l’utilisateur ciblé dans le contenu du mail, le succès est uniquement de 14%
      > En envoyant simplement un lien sans aucun contenu supplémentaire, le succès est de 42% !

Pour contrer ce type d’attaque, les recommandations à appliquer et données par Paul sont les suivantes :

  • Surveiller la passerelle de messagerie et consulter les journaux régulièrement
  • Configurer les mécanismes anti force brute empêchant de lister les adresses email valides
  • Refuser les emails provenant de noms de domaine inexistants
  • Utiliser le mécanisme Sender Policy Framework (SPF) afin de vérifier l’authenticité du service émettant l’adresse email pour un nom de domaine
  • Imaginer tous les scénarios d’attaque possibles et mettre en place une configuration adaptée
  • Bloquer les fichiers « containers » (zip par exemple)
  • Désactiver les macros : difficile à appliquer dans un milieu d’entreprise ou les macros sont légion
  • Réduire l’utilisation de l’authentification « automatique »
  • Intercepter et analyser les requêtes SSL
  • Journaliser et contrôler les requêtes DNS
  • Éduquer les employés : les campagnes de phishing peuvent de manière générale être détectées par toute personne, il suffit de savoir comment le faire. Dans le doute, demander à un administrateur reste la meilleure des solutions.

Les campagnes de phishing évoluées ou non restent donc le moyen le plus efficace et le moins couteux pour des attaquants déterminés à s’introduire dans un réseau d’entreprise ; il est important de se préoccuper de ce point d’entrée dans les audits de sécurité.

3. « How not to build an electronic voting system »

Quentin Kaiser (@QKaiser) nous a ensuite fait découvrir les systèmes de vote électronique CODI et Smartmatic, qui ont été mis en place en Belgique.

Un peu d’historique :

  • 1991 : premiers tests du e-voting dans 2 villes
  • 1994 : élargissement à 20% du Pays
  • 1999 : élargissement à 44% et introduction de la reconnaissance des bulletins par reconnaissance automatisée (OCR)
  • 2003 : premiers tests avec la billetterie dans 2 cantons
  • 2007 : rapport « BeVoting »
  • 2012 : Introduction du système Smartmatic

Ces systèmes dits « sécurisés » doivent, en théorie, respecter un nombre non négligeables de contraintes de par leur but sensible :

  • La confidentialité des données
  • La preuve (aucune donnée ne doit être contestable)
  • L’authenticité : un électeur ne doit pas pouvoir voter pour un autre
  • L’intégrité : les votes ne doivent pas pouvoir être altérés
  • La non-coercition : les données ne doivent pas être influençables
  • L’unicité : les votants ne doivent pas pouvoir voter plusieurs fois
  • Les possibilités d’audit : les données doivent pouvoir être vérifiées
  • La simplicité : le mécanisme ne doit pas être compliqué à utiliser
  • L’équité : les élus ne doivent pas être avantagés d’aucun moyen
  • La vérifiabilité : les votes doivent pouvoir être revérifiés rapidement

Afin de respecter ce cahier des charges, un premier système a été déployé : le système CODI, composé des éléments suivants : une authentification par carte magnétique et par disquette (oui !), et les « briques » Jites, Digivote, PGM2, PGM3 et Election Management System.

Dans celui-ci, des méthodes d’authentification et de vérification d’intégrité sont présents :

  • les stations de votes sont démarrées avec le mot de passe du responsable du bureau en plus de la disquette
  • l’intégrité de la disquette est vérifiée
  • un jeton et un algorithme MAC sont utilisés pour contrôler l’autorisation du votant et des données de sa carte magnétique. Ceci complexifie notamment la fraude.

Cependant, Quentin a pu nous prouver que les algorithmes de chiffrement, et en particulier leur implémentation n’est pas parfaite, et qu’il est possible de créer des cartes magnétiques « pirates » afin de frauder et de voter plusieurs fois pour un candidat.

De plus, les briques du système CODI étant accessibles à tous, il a pu les analyser et découvrir des failles parfois assez énormes :

  • des identifiants d’administration sont présents dans les fichiers PHP, permettant alors d’accéder à une interface de supervision des votes
  • une clé privée et son mot de passe, utilisés pour chiffrer les fichiers des votes sont également présents
  • les comptes utilisateurs CODI sont stockés en clair dans le système
  • une vulnérabilité de téléchargement de fichier arbitraire a pu permis de découvrir que du code a directement été copié depuis internet, les développeurs n’ont donc pas tout développé eux-mêmes et ont pu introduire des bogues connus

Ensuite, un autre système a été mis en place : le système Smartmatic.

Sur celui-ci, de bonnes pratiques semblent avoir été appliquées au premier abord :

  • pas de service d’administration accessible à distance (pas de SSH, FTP...)
  • les permissions des fichiers ont été durcies
  • un pare-feu iptables avec des règles de bases assez cohérentes
  • le fichier sudoers limite les droits de l’utilisateur
  • pas de mot de passe défini pour les comptes de services
  • le service RMI a été durci
  • l’accès à la base PostgreSQL est limité à une adresse IP autorisée

Cependant, des défauts ont tout de même été relevés :

  • le trafic PostgreSQL n’est pas chiffré
  • les comptes PostgreSQL n’ont pas de mot de passe

Il serait donc possible d’attaquer le système en 4 étapes :

  • obtenir un accès au réseau physique
  • mettre en place une attaque ARP afin de se placer entre l'hôte JBoss et l'hôte PostgreSQL
  • se connecter au service PostgreSQL à la place de JBoss
  • exfiltrer la base de données et/ou exécuter des commandes sur le serveur via une élévation de privilège UDF

Quentin n’a pu (pour le moment) tester ce scénario, la suite peut donc être attendue à la prochaine conférence !

Il a également rappelé qu’il ne faut pas se fier aux apparences et que tout système peut avoir des vulnérabilités, et celui-ci doit obligatoirement et systématiquement être audité, avec comme exemple CODI qui a été « cassé » au bout d’un seul jour par une seule personne.

4. « Key-logger, Video, Mouse – How to turn your KVM into a raging key-logging monster »

Yaniv Balmas (@ynvb) et Lior Oppenheim (@oppenheim1) de Checkpoint nous ont présenté un nouveau vecteur d’attaque : la compromission d’un équipement KVM (ou « Keyboard Video Mouse », un équipement permettant de contrôler plusieurs machines depuis un seul « bureau ») :

Ce type de périphérique étant aujourd’hui présent dans tout datacenter afin de simplifier le travail des administrateurs systèmes, embarque un processeur et peut donc exécuter du code malveillant.

En cas de compromission de cet équipement, il est alors théoriquement possible de prendre le contrôle des serveurs connectés à celui-ci.

Ils ont essayé différentes méthodes afin d’obtenir et comprendre le firmware de l’équipement KVM :

  • La rétro-ingénierie du firmware donné par le constructeur : sans succès car le binaire est offusqué

  • L’analyse des données obtenues via le port série lors d’une mise à jour du firmware : même résultat, les données ne sont pas compréhensibles par un humain non initié :

  • L’analyse logique du fonctionnement du circuit via la connexion à un port UART et l’analyse des signaux :

 

Dans un premier temps ils n’ont pas réussi à comprendre leurs relevés de données, puis ils ont essayé de détecter des empreintes de code assembleur lié à une architecture :

Ils ont alors découvert que c’était de l’assembleur 8051 :

Ils ont donc pu essayer de comprendre l’offuscation, en utilisant la comparaison de deux versions de firmware pour un même équipement, ce qui a permis de retrouver des points communs et donc des empreintes facilitant la rétro-ingénierie.

La méthode d’offuscation a ensuite pu être cassée en plusieurs étapes et relativement simplement pour un reverser ayant une bonne motivation, notamment via la conversion de caractères d’après les codes ASCII et la remise en ordre des caractères présents dans les chaines.

Il est alors possible de créer son propre firmware KVM malveillant, en comprenant tout d’abord le code assembleur découvert.

Le nouveau vecteur d’attaque présenté est le suivant :

  • Accès physique au boitier KVM ou via son adresse IP si une mise à jour est possible selon la version de l’équipement utilisé
  • Installation en 30 secondes d’un firmware malveillant créé au préalable (via le port série ou la mise à jour via l’interface réseau)

L’attaquant peut alors :

  • contourner toute restriction d’accès réseau dans le cas où le KVM serait connecté à deux serveurs connectés sur deux réseaux cloisonnés
  • obtenir une porte dérobée persistante puisque le firmware du KVM n’est pas contrôlé par le système d’exploitation des systèmes et les éventuelles solutions de sécurité logicielles en place

Ce nouveau vecteur doit être donc aujourd’hui être intégré dans les audits afin de s’assurer de la sécurité des équipements KVM et empêcher leur compromission par un attaquant.

La vérification de l’authenticité du firmware peut notamment être effectuée, bien qu’aujourd’hui aucune méthode simple et rapide n’ait été mise en place par les fabricants pour la comparaison du firmware installé avec le firmware officiel accessible depuis leur site web par exemple.

5. « Keys? Where we’re going, we don’t need keys »

Damien Cauquil (@virtualabs) de Sysdream a présenté la rétro-ingénierie d’une serrure connectée (non nommée) :

Au préalable, il a rappelé les différentes méthodes d’attaques pour les serrures mécaniques classiques :

  • Le « Lockpicking » ou attaque avec aiguilles permettant de relever les cylindres montés sur ressorts et présents dans une serrure classique
  • L’utilisation de « bump keys » : la création d’une fausse clé adaptée à chaque serrure et permettant par un choc de relever tous les cylindres d’un seul coup. Ceci pouvant également être réalisé à l’aide d’un « pistolet » spécial émettant de fortes vibrations
  • L’impression : l’attaque avec une clé « molle » permettant de faire imprimer le dessin des différents cylindres sur celle-ci, et permettant ensuite de créer une clé adaptée
  • Le décodage : l’utilisation d’un outil spécifique permettant de trouver le schéma de la serrure et de l’ouvrir

Aujourd’hui, il existe maintenant des serrures dites « connectées » et permettant l’envoi d’une clé sous forme de jeton logiciel, pour de donner un accès temporaire à une connaissance par exemple.

Ces nouvelles serrures donnent notamment des avantages non négligeables :

  • Donner des accès limités dans le temps : pour une femme de ménage, pour louer son appartement un week-end…
  • « Révoquer » une clé lors de sa perte, sans être obligé de changer la serrure complète
  • Un smartphone peut être utilisé comme clé via Bluetooth, et ce dernier consomme peu d’énergie
  • S’adapte sur tout type de porte

Il est alors possible de dresser une liste de risques associés : le risque d’interception des communications Bluetooth pouvant potentiellement permettre l’ouverture d’une porte par un attaquant, le risque de ne pas pouvoir ouvrir la porte en cas de coupure de courant, et enfin le risque de vol de clé en cas de piratage de la plateforme hébergeant les données.

Damien a analysé un type de serrure vendu aux États-Unis et en Europe, qu’il n’a pas voulu nommer pour éviter les éventuelles représailles du constructeur.

Il a découvert les informations suivantes :

  • une puce CC2540 permet la communication BLE (Bluetooth Low Energy)
  • un microcontrôleur STM32F103 est le « cerveau » logique de la serrure
  • une application smartphone héberge les clés dans le cloud
  • un serveur GATT (Generic Attribute Profile) est utilisé :
      > il permet la gestion des données Bluetooth
      > il utilise un système de « notification » en communication asynchrone pour réduire la consommation d’énergie
      > les données hébergées, dites « caractéristiques », sont normalement accessibles en écriture et en lecture Le premier challenge rencontré est que les vendeurs de serrures connectées implémentent leur propre protocole, ce qui peut être complexe à comprendre sans documentation accessible.

L’interception et l’analyse des trames Bluetooth peut être effectuée via des outils tels que l’Ubertooth ou Adafruit BLE sniffer, ou encore en modifiant le code de l’application smartphone.

Il a quant à lui choisi le sniffer d’Adafruit qui permet de produire une capture au format PCAP (lisible après avoir corrigé le dissecteur Wireshark) et il a également mené des tests via la modification d’une application Android.

Il a ensuite développé un programme Python afin que Scapy supporte ce format.

Ses premiers tests lui ont permis de tirer les conclusions suivantes :

  • Le « sniffing » est compliqué car de nombreux parasites sur la fréquence du Bluetooth apportent des fausses données dans les captures des trames de la serrure
  • La modification du code Smali Android est la méthode la plus rapide pour mener des analyses des trames envoyées (en modifiant les "callbacks" et les méthodes pour ajouter du "debugging" via java.util.Log). Les applications offusquées peuvent toutefois complexifier cette démarche.
  • Il a pu relever 2 couches de communication sur le modèle testé:
      > La couche de transport d’une taille maximum de 19 octets :

  • La couche applicative qui accuse réception des messages Bluetooth Low Energy et la communication synchrone entre le smartphone et la serrure :

  • Dans les données interceptées se trouve le journal des événements, en clair et sans authentification ! Damien note qu’un cambrioleur pourrait trouver cette information très intéressante pour préparer ses actes.
  • Les données liées à la clé sont quant à elle bien chiffrées, (ouf !) :

Il a ensuite essayé de « fuzzer » chacun des octets de cette trame, c'est-à-dire en menant une attaque en force brute en hexadécimal sur chacun des identifiants… et là c’est le drame : la serrure s’est ouverte après avoir attaqué les 2 premiers octets !

Il s’est ensuite renseigné auprès du vendeur sur le type de chiffrement utilisé, et ce dernier a affirmé utiliser l’algorithme AES et donc les données chiffrées devraient être un multiple de 16.

  • On a une trame de 20 octets, Damien s’est alors demandé ce que les 4 premiers octets sont

En regardant les journaux de la serrure, il s’est aperçu de plusieurs défauts après son attaque :

  • Le userid est passé de « 1 » à « ffff02 »
  • Le comportement de la serrure peut être dû à l’utilisation d’une vérification par opérateur logique XOR (eXclusive OR). Celui-ci associe un résultat qui a la valeur VRAI seulement si les deux valeurs testées ont des valeurs différentes, ce qui expliquerait le comportement relevé :

  • Ou à l’utilisation d’algorithme AES avec CBC et une combinaison de « padding », cependant ceci n’a pu être vérifié pour le moment

Il a ensuite découvert un paramètre dans les trames Bluetooth, nommée « SPECIALCMD ». En envoyant des trames avec ce paramètre, il a découvert qu’il est possible de provoquer une attaque de déni de service sur les serrures, qui de plus vide complètement les batteries de celles-ci.

Damien a pu dresser une liste de scénarios d’attaque possibles sur la serrure connectée qu’il a testée :

  • Scénario 1 : capture et rejeu d’une clé : scénario difficile à mettre en œuvre car les écoutes Bluetooth sont très parasitées et il est nécessaire d’être proche de la serrure et de la clé. De plus des traces apparaissent alors dans les journaux d’événements lors de l’ouverture.
  • Scénario 2 : se faire passer pour une serrure et jouer le signal à la place du smartphone : seul un pc portable et une clé Bluetooth BLE sont nécessaires, de plus les serrures ayant un faible signal il est aisé d’émettre un signal plus fort et de se faire passer pour elles. Ceci nous rappelle alors les expériences de Samy Kamkar et les portes de garage.
  • Scénario 3 : provoquer un déni de service sur la serrure et vider les batteries

Nous pouvons conclure que les serrures connectées dites « sécurisées » nécessitent encore du travail afin de pouvoir affirmer être « inviolables ».

Il existe encore peu de travaux accessibles à tous sur ce type d’équipement, et des chercheurs en sécurité commencent sérieusement à s’y intéresser. On peut donc attendre d’autres conférences du même type dans les prochains mois.

6. Marie Moe, ou comment vivre avec un implant médical faillible

Une des conférences les plus humaines et éthiques auxquelles nous ayons pu assister est sans conteste la présentation de Marie Moe (@MarieGMoe) nommée « Unpatchable : Living with a vulnerable implanted device ».

Marie Moe est une chercheuse en sécurité Norvégienne du SINTEF Infosec. Souffrant de problèmes cardiaques, elle est amenée il y a quelques années à subir une opération chirurgicale afin de se faire implanter un pacemaker.

Passionnée par son métier, elle se pose donc une question qui est naturellement personnelle : mon nouvel appareil me permettant de vivre est-il sécurisé ?

Les pacemakers sont des outils contrôlés grâce aux technologies sans fils. Le médecin règle la fréquence d’assistance cardiaque sur son ordinateur et ceci, bien évidemment, sans toucher physiquement à l’appareil. De plus, toute personne possédant un appareil de ce type a chez lui un système de monitoring Wi-Fi permettant, au quotidien, de transmettre à son médecin toutes les données nécessaires au suivi de son activité cardiaque.


Figure 5 - Les données sont envoyées de chez soi au médecin

Ainsi, plusieurs éléments peuvent potentiellement présenter des vulnérabilités :

  • Le pacemaker lui-même,
  • Les points d’accès
  • Le serveur de l’éditeur
  • Les communications entre le pacemaker et le médecin

Marie Moe en est persuadée : les objets, systèmes médicaux possèdent des vulnérabilités, et l’implant située sur son cœur ne fait pas exception à la règle. Elle-même a fait l’expérience d’un problème de conception du logiciel de réglage de l’implant. En effet, lors d’une visite chez le cardiologue, des réglages ont été effectuées sur son pacemaker et, les jours suivants, un essoufflement intense et inhabituel se faisait ressentir lors d’un effort réalisé.

Il s’est avéré que le programme possédait un défaut de conception. La fréquence envoyée à l’assistant cardiaque n’était pas celle entrée par le médecin sur son ordinateur et se révélait donc inappropriée pour le patient.

À cette mésaventure peuvent s’ajouter les découvertes de Barnaby Jack. Ce chercheur en sécurité avait réalisé de nombreux travaux à ce sujet et s’apprêtait à dévoiler de nombreux problèmes de sécurité dans le domaine de la santé et des équipements médicaux (pacemakers, pompes à insuline…). Il avait notamment réussi à créer un programme permettant de déclencher des chocs électriques sur certains assistants cardiaques et donc potentiellement provoquer la mort de quelqu’un par ce biais. La présentation du piratage devait se dérouler à la Black Hat de 2013 mais Barnaby Jack est décédé quelques jours plus tôt à l’âge de 35 ans. L’aspect symbolique, même si ce n’est pas la cause de sa mort, est que le chercheur Néo-Zélandais portait lui aussi un pacemaker…

Au final, le mot d’ordre que cherche à nous faire passer Marie Moe est de prendre en compte, à tout point de vue, la sécurité dans le milieu médical et d’insister sur ce point. En effet, la présence de vulnérabilités peut être catastrophique, voire mortelle. La réflexion en amont est d’autant plus importante que, naturellement, les implants ne peuvent pas être corrigés sans intervention chirurgicale en cas de découverte de faille de sécurité.

7. Saumil Shah : Stegosploit – Vous ne verrez plus les images comme avant

Saumil Shah (@therealsaumil) est un chercheur Indien réalisant des travaux sur la capacité de cacher du contenu malveillant dans une image. Comme il aime à le dire, « A good exploit is one delivered with style ». Nous allons donc ici parler de stéganographie. La stéganographie est l’art de la dissimulation, autrement dit faire passer de façon inaperçue un élément dans un autre élément.

Vous l’aurez compris, ici le but du jeu est d’insérer, dans une image, du code sans que cela ne détériore le fichier et que cette insertion soit invisible.

Saumil Shah a développé Stegosploit, une technique pour transmettre et faire exécuter des exploits dans une image par le navigateur d’une victime.


Figure 6 - Logo de Stégosploit

Mais comment cela fonctionne-t-il ?


Figure 7 - Démarche de Stegosploit

Il faut dissimuler le code d’exploitation dans les pixels de l’image, autrement dit, l’encoder dans l’image.

Pour ce faire, un encodage des pixels est nécessaire avec en entrée l’image utilisée et le code à faire exécuter sur le navigateur de la victime.

Nous avons alors en sortie une image contenant le payload malicieux.

Ensuite, il faut ajouter le décodeur afin que la charge s’exécute à l’ouverture de l’image.

Ici, du code Javascript est inséré dans l’image qui devient alors une IMAJS, contraction, vous l’aurez deviné, de « Image » et « Javascript ». Nous avons alors un fichier nommé « Polyglot » puisqu’intégrant plusieurs types de fichiers en un seul (JPEG/PNG, HTML, JS, CSS).

L’avantage de cette méthode est qu’un simple clic sur l’image déclenche l’attaque. Auparavant, la stéganographie impliquait l’utilisation d’un Loader externe afin d’exécuter le code, ce qui s’avérait plus complexe et moins efficace dans le cas d’une attaque réelle.

L’autre gros avantage est que cette technique n’est pas détectée par les antivirus.

Afin d’atteindre la victime, plusieurs solutions sont possibles. La plus populaire d’entre elles est l’incitation à cliquer sur une image hébergée sur le serveur web d’un attaquant. Mais d’autres possibilités sont envisageables : Attaques XSS, réduction d’URL… l’imagination humaine est sans limite !

Afin de vous rendre compte par vous-même des effets et du fonctionnement de cette technique, découvrez les vidéos ci-dessous :

&

Dans ces vidéos, Saumil Shah nous montre comment cacher du contenu dans une image en utilisant la stéganographie (vidéo 1) et comment Stegosploit fonctionne (vidéo 2). Dans ce second extrait, vous verrez que l’exploit fonctionne lorsque le processeur de la machine de test arrive à saturation et que la victime reçoit un petit message « You are hacked ! »

8. Fitbit Flex : un traqueur d’activité et bien plus

Les objets connectés sont très tendances en cette fin d’année 2015. Ils sont toujours plus nombreux attachés au poignet de leur propriétaire et sont dotés de plus en plus de fonctionnalités : traqueur d’activité, suivi du sommeil, cardiofréquencemètre…

Axelle Apvrille (@cryptax), chercheuse en sécurité chez Fortinet, nous fait part de ses recherches et travaux réalisés sur le Fitbit Flex, l’un des traqueurs d’activité Bluetooth les plus vendus sur le marché.


Figure 8 - Fitbit Flex

Traquer l’activité de personnes, c’est bien. Faire plus de choses et s’amuser un peu, c’est mieux. En dehors de ces fonctions basiques, Axelle Apvrille nous apprend qu’il est en effet possible de détourner l’usage du Flex comme par exemple vous faire passer pour un magicien auprès de vos enfants en faisant clignoter les diodes suivant une séquence précise.

Le travail pour arriver à ce genre de résultat a été très important et difficile pour la simple et bonne raison que le Fitbit Flex embarque un système propriétaire. Ce dernier n’est ainsi aucunement documenté et c’est tout en reverse-engineering que la chercheuse Française a découvert des aspects très intéressants du système embarqué.

Après avoir démonté le bracelet, elle a pu en détail étudier le protocole Bluetooth utilisé et réaliser un programme capable d’interagir avec l’équipement.


Figure 9 – Démontage et ouverture du traqueur

S’en sont suivis plusieurs travaux afin de mettre en pratique les découvertes sous-jacentes.

Tout d’abord, la compréhension du protocole Bluetooth a permis la découverte du format des trames communiquées entre le bracelet et le dongle et ainsi d’envoyer une séquence de clignotement des diodes.

Une faiblesse d’implémentation du mécanisme d’authentification supporté par le traqueur a permis de le transformer en générateur de nombre aléatoire (Nous vous conseillons de ne pas l’utiliser pour réaliser du chiffrement!)

Le bracelet peut aussi servir à verrouiller votre ordinateur en cas d’éloignement. En pratique, ce procédé fonctionne grâce à l’ID du bracelet (son adresse MAC) et la force du signal reçu par le dongle USB.

Mais ceci reste une utilisation ludique et pratique de l’objet.

La présentation s’est poursuivie par une démonstration de ce que pourrait tenter de faire un individu malveillant grâce au Fitbit Flex.

En effet, il s’avère possible d’envoyer un contenu au traqueur afin que ce dernier le relaie au Dongle USB, se synchronisant avec lui. Vous devinez la suite ?

La chercheuse découvre qu’il est possible d’envoyer une charge malveillante sur l’ordinateur d’une victime par le biais de son bracelet. Cependant, cette charge ne peut pas excéder 17 octets. Ceci est de façon certaine une limitation dans le cadre d’une attaque. Mais gardons en mémoire qu’il y a une dizaine d’années en 2004, 4 octets ont suffi pour faire tomber un processeur Pentium !

Aujourd’hui, Fitbit a édité les correctifs nécessaires suite à ces découvertes. Si votre bracelet est à jour, n’ayez donc aucune crainte. Si ce n’est pas le cas, nous ne pouvons que vous conseiller de faire la démarche dès que possible.

9. Pour finir…

Sans conteste, la Hack.lu est l’une des meilleures conférences en Europe et mérite le déplacement : ambiance sérieuse mais détendue, contenu ultra riche, organisation au top, cadre luxembourgeois calme et verdoyant, les 350€ requis pour cet événement valent amplement d’être dépensés.

Au carrefour de la France, la Belgique, les Pays-Bas et l’Allemagne, la Hack.lu est aussi une bonne opportunité de rencontrer de nombreux spécialistes Européens dans le domaine de la sécurité.

Un conseil cependant que nous pourrions vous donner est de bien planifier votre événement et de faire des choix. En effet, il est impossible de réaliser l’ensemble des activités proposées : participer au CTF, aux différents ateliers tout en assistant à un maximum de conférences.

De ce fait, nous ne pouvons que vous inviter à prioriser vos souhaits afin de profiter un maximum de l’événement !

Attention également à vos agissements et tout ce que vous diffusez via votre smartphone ou ordinateur. En effet, vous vous retrouverez peut-être sur le Wall of Shame de l’événement en cas de connexion à un des nombreux réseaux Wi-Fi disponibles à la Hack.lu !


Figure 10 - Wall of Shame by #Hack.lu

Sources

http://2015.hack.lu
http://archive.hack.lu/2015/2015-10-21-Keynote-Hack-lu-Marie-Moe.pdf
http://archive.hack.lu/2015/stegosploit_hacklu2015.pdf
http://stegosploit.info/images/stegosploit_logo_256.png
http://archive.hack.lu/2015/fitbit-hacklu-slides.pdf
http://archive.hack.lu/2015/keys_where_we_re_going_we_dont_need_keys.zip
http://archive.hack.lu/2015/hacklu2015_qkaiser_hownottobuildanevotingsystem.pdf
http://archive.hack.lu/2015/TotallySpies.pdf
http://archive.hack.lu/2015/Practical_Spear_Phishing.pdf
http://archive.hack.lu/2015/key-logger-video-mouse.pdf
http://samy.pl
http://www.wikileaks.org

Jérémy et Thomas, Consultants Sécurité, Advens