Nuit Du Hack 2014 – mes notes ! (part 2/2) #NDH2014

Voici la 2^nde et dernière partie de mes notes de la Nuit Du Hack 2014 (#NDH2014). La 1^ère partie de mes notes portant sur la keynote et les 5 premières présentations se trouvent ici.

#6 - la tête dans les nuages – Matthieu Bouthors (@Majin_Boo)
 

Le Cloud computing ce n’est pas uniquement des belles applications web ou mobiles. Le Cloud computing c’est aussi des API qui permettent à des programmes d’automatiser certaines actions ou d’accéder à des informations. Les API sont la partie immergée de l’iceberg du Cloud computing. La sécurité de ces API est donc essentielle.

Matthieu Bouthors nous explique que les outils disponibles pour étudier la sécurisation des API sont encore assez peu répandus car le focus a été mis sur la partie visible (c’est à dire les applications web). Deux grandes familles d’API existent : d’un côté il y a les API basées sur le standard SOAP et de l’autre celles en REST.

Du coté des API en SOAP, bien que les requêtes soient très souvent signées (via WS-Security) il existe des vulnérabilités au niveau des parsers XML. Il y a le Déni de service basé sur l’inclusion d’entités multiples et imbriquées, l’inclusion d’une entité externe dans un bloc pour un leak de fichier ou d’une ressource interne ou encore le détournement d’XSLT pour du LFI/RCE ou même de l’exécution de code Java.

Les API en REST sont plus exposées car d’un fonctionnement similaire à un protocole http. Les outils nécessaires pour intercepter et modifier les requêtes sont donc  à la portée d’un plus grand nombre. Afin d’illustrer son propos, Matthieu Bouthors a expliqué comment il a pu utiliser le « BURP Proxy» associé à un plugin « Njord »  développé spécifiquement pour recalculer la signature d’appels modifiés sur une API compatible Amazon S3.

 

#7 - coucou - tu veux voir ma domotique - Vorex et virtualabs
 

Les systèmes domotiques sont à la mode. Pour celui qui souhaite se lancer et connecter sa maison ou son appartement il a le choix entre des systèmes propriétaires ou open source.
La sécurité de ces systèmes est particulièrement importante : aucune chance que l’assurance prenne en charge un cambriolage si aucune effraction n’est constatée (cas d’une serrure ouverte via exploitation d’une faille de sécurité sur le système domotique).

En synthèse, la sécurité des solutions domotiques open source comme Domoticz ne va pas de soi car de multiples failles ont été identifiées qui permettent de récupérer des back-up du système sans authentification préalable (back-up dans lesquels il y avait le mot de passe administrateur en clair – ou presque – base64…) ou encore la possibilité de récupérer des screenshots des caméras connectées, encore une fois sans authentification.
 

Les solutions propriétaires liées avec des services dans le cloud restent « par design » assez suspectes car une compromission du fournisseur de service peut avoir des conséquences importantes. Et dans ce cas, il n’est pas possible pour un bidouilleur d’analyser si la sécurité est bien au rendez-vous…

Les manœuvres récentes d’Apple et de Google dans le domaine des protocoles pour le « home automation » sont à surveiller de près… Surtout pour notre vie privée !
 

#8 - take care of your inputs – Zakaria Rachid (@zackhimself) & Borja Berastegui (@BBerastegui)
 

Les présentateurs vous montrent comment ils arrivent à prendre le contrôle de systèmes sans aucun outil ni subterfuge technique. Tout simplement en « jouant » avec les écrans tactiles des kiosks Internet, des bornes de tickets, des écrans tactiles et même de guichets bancaires…
Réellement impressionnant ! Cette idée de venir tester la sécurité des bornes leur est venue afin d’occuper le temps passé à attendre dans les aéroports.

Parmi les techniques présentées il y a :

• le « reflected XSS » avec inclusion de code HTML dans un champ de formulaire pour provoquer l’ouverture d’un fichier en local,
• le déclenchement d’un clavier sur une borne de vente de tickets en touchant le bord supérieur gauche de l’écran,
• du « fuzzing humain » sur les « douchettes » utilisées dans la grande distribution
• le déclenchement d’une « race condition » en touchant l’écran tactile juste après la disparation du screen-saver.

Cette présentation a été la plus surprenante. Un vrai effet « whaouuu » !!!

#9 - retro-arcades protections & hacking – CrashTest
 

Avant, les jeux de qualité n’étaient présents que sur des bornes dédiées présentes dans des salles de jeu spécialisées et autres débits de boissons. Mais comment fonctionnaient les systèmes de protection sur ces bornes d’arcades ? L’intérêt de hacker ce genre de système, bien qu’ils soient désormais obsolètes face aux consoles de jeu modernes, réside tant dans le plaisir (nostalgique !) de rejouer à l’un des jeux de son enfance que d’assurer la conservation d’un « patrimoine numérique ».

Les bornes d’arcades étaient des systèmes « tous en un » ou le hardware ET le software étaient spécialement construits. Les bornes intégraient des CPU spécifiques/propriétaires, et pour certaines le logiciel (ou certaines infos critiques) était stocké en RAM avec une « batterie suicide ». Ce qui permettait de « détruire » au bout d’un certain temps le logiciel et donc de le « protéger ».

Le code exécutable des consoles Capcom CPS1 et CPS2 était chiffré en mémoire et était déchiffré à la volée au cœur même du microprocesseur propriétaire. Ce système serait resté encore inviolé (!!!) à l’heure actuelle si Capcom n’avait pas fait quelques erreurs fatales.

Le speaker, un vrai passionné, a été captivant et sa présentation d’une richesse que l’on ne trouve que rarement. Le volet technique de sa présentation a été impeccablement agrémenté de screenshots et vidéos.

Mise à jour du 09/07/2014 – Retrouvez sur archive.org les supports présentés par CrashTest.

 

#10 - defeating Memory Corruption Attacks by Replication & Diversification – Marc Nimmerrichter
 

Un attaquant souhaitant exécuter du code via l’exploitation d’une faille de sécurité doit modifier la mémoire du processus afin de provoquer l’exécution d’instructions spécifiques. Cette prise de contrôle du flux d’exécution passe via le changement de registre ou de structures mémoire. Marc Nimmerrichter a présenté une approche visant à détecter tout changement dans les appels systèmes effectués par un processus et de bloquer les attaques.

Le principe est le suivant : le processus à protéger est dédoublé en mémoire et la copie et l’original vont tous deux s’exécuter de façon simultanée, ceci sous la surveillance d’un processus dédié à la surveillance (le « monitor »). A noter que la copie du processus est positionnée dans des zones mémoires mappées à des adresses différentes.

Outre son travail de surveillance des appels systèmes, le monitor va gérer les entrées et sorties de chacun des processus. Toute déviation dans les appels systèmes entre un processus ou l’autre indiquant une tentative de prise de contrôle du flux d’exécution (exploit), ce qui va provoquer l’arrêt immédiat des deux processus (le processus à protéger et sa copie) afin de stopper l’attaque.

Cette technique, bien qu’encore expérimentale (notamment sur le volet des performances) permettrait de protéger les processus les plus sensibles d’attaques.
 

#11 - using CNC and 3D to cut your own mechanical keys - Alexandre Triffault
 

La présentation d’Alexandre Triffault a porté sur la fabrication de clefs afin d’ouvrir des serrures ou des cadenas. Après un rapide, mais très instructif rappel du principe de fonctionnement d’une serrure, Alexandre Triffault a expliqué les principes de fonctionnement d’une clef et comment les caractéristiques d’une clef « standard » pouvaient être mesurées via un pied à coulisse.

Sur la base de ces informations, il est possible de créer une nouvelle clef via une machine à commande numérique (CNC pour Computer Numerical Command). Un petit script en python pour générer 17 lignes de script G-CODE et la fabrication peut être lancée. Simple et efficace.

Via une programmation un peu plus complexe, il est même possible de fabriquer des clefs « de sécurité »… Impressionnant.

Pour ce qui concerne la fabrication des clefs via des techniques d’impression 3D, c’est techniquement possible mais pas à la portée de toutes les bourses (contrairement à l’approche CNC). En effet, l’impression en 3D à base de plastique, bien que réalisable, ne permet pas de créer des clefs suffisamment résistantes : il sera donc nécessaire de se tourner sur de l’impression 3D métallique ce qui est encore prohibitif en terme de coût.

et voilà, c’est fini !
 

Je n’ai pas pu assister aux dernières conférences (Combating evasive malware – Marco Cova / Using a basic bathroom scale to remotely follow a behive production – Electrolab). Ni participer aux ateliers qui étaient organisés le soir et durant la nuit.

Cette Nuit Du Hack a été particulièrement riche et intéressante. Un grand bravo aux organisateurs et aux sponsors ainsi qu’à tous les participants. Et encore merci à @free_man_ pour l’invitation !

Petite précision concernant le tee-shirt de la NDH 2014. Pour ceux qui se posent la question du chiffre «23 » présent sur le devant, c’est la somme de la date (28/06/2014 : 2+8+6+2+1+4 = 23). Pour ce qui concerne le « I see fnords », faut aller jeter un œil sur Wikipedia. J

Jean-François (Jeff) Audenard

PS : mon petit doigt me dit que la NDH2014 devrait être au menu d’un prochain épisode de @notlimitsecu.

Lire la première partie de cet article : Nuit Du Hack 2014 – mes notes ! (part 1/2) #NDH2014