NoSuchCon 2014 – NES was there !

NoSuchCon 2014 – NES was there !

logo

Ci-dessous, un résumé des  différentes conférences et workshop vus par l’équipe audit NES.

 ***************************************************************************************************************************************

Keynote : Program Synthesis in Reverse Engineering
Rolf Rolles

Cette année le bal était ouvert avec Rolf Rolles qui nous a fait part de ses avancées en matière de Reverse Engineering et plus particulièrement de désobfuscation de binaires.
Le point fort de cette conférence est qu’il était question d’automatiser le procédé de désobfuscation en se basant sur le mécanisme de ‘Program Synthesis’ ou synthèse de programme.

Par définition, la synthèse de programme est un procédé dédié à la création de programmes dont on aura fourni le comportement souhaité.
En pratique, un comportement peut être décrit par un couple d’états entrée/sortie et le programme recherché (appelé synthétiseur) effectue la transformation correspondante.

Mais alors, comment applique-t-on ce procédé à du reverse engineering et surtout dans quel objectif ?
L’objectif clairement affiché de Rolf Rolles est de simplifier la lecture du code désassemblé d’un binaire qui aura été volontairement obfusqué.
Lorsque que l’on rencontre un tel code, il est en général nécessaire d’écarter le code inutile pour ne garder que les lignes qui manipulent les opérandes cruciaux, puis de condenser les lignes restantes pour obtenir une version compactée et plus lisible du code.
Ce procédé sera souvent long, fastidieux et devra être répété à de nombreuses reprises jusqu’à pouvoir repérer des motifs répétitifs.

La synthèse de programme propose une alternative dans laquelle il n’est pas nécessaire de comprendre ce que fait le code étudié ni d’opérer une quelconque simplification de celui-ci.
En effet, le synthétiseur se contente d’observer un état d’entrée et un état de sortie à partir desquels il nous fournira une fonction correspondante.
Dans notre situation, un couple entrée/sortie s’obtient facilement car cela revient à choisir aléatoirement un contexte d’exécution où les registres ont une valeur quelconque, il s’agira de notre état d’entrée.
L’état de sortie sera ce même contexte une fois exécuté le code obfusqué dans celui-ci.
Muni de plusieurs paires entrées/sorties, le synthétiseur établira des hypothèses par essais successifs jusqu’à ce que l’une d’elle valide tous les prérequis, la fonction ainsi obtenue sera ainsi considérée équivalente au bloc de code obfusqué et viendra remplacer celui-ci.
En suivant ce cheminement, notre synthétiseur va donc étudier au fur et à mesure le code obfusqué qu’il rencontre et mettre à jour une table de règles contenant les motifs qu’il aura établi.

Bien que ce procédé d’automatisation semble prometteur, il rencontre cependant de sérieuses limitations.
La première qui se pose est qu’un tel synthetiseur n’est pas capable d’analyser des boucles. Il sera nécessaire de le coupler avec d’autres procédés pour pouvoir progresser face à elles.
Un autre problème se pose face au code inutile rajouté par les obfuscateurs : le synthétiseur n’effectuant pas d’analyse rétroactive, il n’est pas en mesure d’établir si un registre est crucial au programme où si il s’agit juste de junk code (code parasite), il ne pourra au mieux que fournir une version simplifiée du code…

***************************************************************************************************************************************

Your Q is my Q
Georgi Geshev

Introduction

Cet article est un résumé de la conférence « You Q is My Q » qui s’est déroulé durant la NoSuchCon 2014 à Paris. Les points développés dans cette publication tourneront autour des « Messages Queues » et des technologies Java que l’on peut rencontrer dans les entreprises.
Une petite définition s’impose afin de planter le décor.

 

Définition

Les « Messages Queue » connues sous le nom de file d’attente de messages en français est une technique de programmation permettant l’échange de messages de façon asynchrone. Ainsi, lors d’une communication entre un client et un serveur, les deux parties n’ont pas besoin d’attendre la réponse de l’autre afin d’échanger des données.
Le principe de fonctionnement de ce système tourne autour du design pattern Producteur/Consommateur.
Le client et le serveur échangent des messages en écriture et lecture via un système de file. Dans le système illustré ci-dessous, le composant qui gère les files de messages est appelé « broker ». On peut trouver des systèmes plus complexes utilisant des brokers connectés en cluster afin de partager des files.

Infrastructures simple d’échange de message via file d’attente

Infrastructures simple d’échange de message via file d’attente

Dans le cadre de la conférence, les technologies abordées tournent autour de l’écosystème Java telles que :
– JMX (API de gestion d’application Java)
– RMI (Interface de programmation permettant d’appeler des méthodes distantes)
– JDWP (Outils permettant entre autre de débugger du code à distance)
Le but des files de messages est d’exposé des interfaces qui seront implémentées comme la possibilité de s’abonner à des évènements ou encore de créer des messages.
Une mauvaise implémentation de ces interfaces implique un certain nombre de vecteurs d’attaque côté applicatif, infrastructure ou encore au niveau du transport des données.

Erreurs rencontrées

Les vecteurs d’attaque potentiels sont assez classiques. Voici un petit échantillon de ce que l’on peut trouver :

  • Identifiant par défaut sur les systèmes
  • Connexion au broker sans authentification (compte anonyme)
  • Accès à la console d’administration du serveur depuis l’extérieur (VLAN non dédié / JMX console accessible)
  • Entrées utilisateur non vérifiés (Objet sérialisé aboutissant à de l’exécution de code)
  • Echange des données en clair
  • Entités XML activés (XXE)
  • Services vulnérables lancés avec les droits administrateurs

 

Scénario d’attaque

En règle générale, dans le cas de communication client/serveur, un système d’authentification est mis en place. Bien souvent, il est courant de trouver l’utilisation d’une authentification LDAP souffrant d’une mauvaise implémentation.

Simple injection LDAP sur l’authentification

Simple injection LDAP sur l’authentification

Le but de l’injection va être de demander au serveur d’authentification LDAP de nous chercher s’il existe un utilisateur avec le mot de passe arbitrairement choisi.
Pour demander de nous chercher parmi tous les utilisateurs, il suffit de rentrer comme nom d’utilisateur le caractère *. En pratique, le login du premier utilisateur présent dans l’annuaire est choisi. Il est possible de cibler un utilisateur spécifique via l’utilisation de filtres LDAP.
Ensuite, il ne reste plus qu’à « bruteforcer » le mot de passe et d’observer les réponses du serveur.

Recommandations

Les bonnes pratiques suivantes sont plutôt classiques et génériques mais permettent d’élever le niveau de sécurité de ces systèmes d’informations. De plus, dans un important nombre de cas, le non-respect de ces recommandations est un risque potentiel d’une intrusion des systèmes.

  • Limiter le nombre de protocoles autorisés pour l’échange des données
  • Utiliser une couche de chiffrement dans les communications (Tunnel SSL)
  • Désactiver les services tels que JMX, RMI ou JDWP s’ils ne sont pas utilisés
  • Séparer l’accès aux panneaux et outils d’administration (création d’un VLAN dédié)
  • Désactiver les entités XML (dans le cadre d’échange de messages en XML)
  • Vérifier les données utilisateurs (vérification des objets sérialisés)
  • Lancer des services avec des droits spécifiques

Conclusion

L’audit de systèmes utilisant des files de messages correspond à ce que l’on peut trouver dans un test d’intrusion de tous les jours. Les vecteurs d’attaques sont présents sur différentes couches et ouvrent la porte à un grand nombre de scénarios d’exploitation.

 

 ***************************************************************************************************************************************

 

HomePlugAV PLC: practical attacks and backdooring
Sebastien Dudek

Sébastien Dudek a rejoint la société SOGETI en 2012. Il travaille sur des sujets qui ont principalement attrait aux communications sans fils (comme par exemple les technologies GSM, WiFi, RFID, DECT, …). Mais il aborde aussi d’autres thèmes tels que les applications, le « web », et la sécurité des réseaux informatiques et les systèmes Linux.

Sebastien Dudek a commencé son exposé par un petit rappel sur les travaux effectués par d’autres chercheurs et passionnés sur le monde des transmissions de données par courant porteur PLC. Le constat est que peu de recherches ont été entreprises et beaucoup sont théoriques.

1

Extrait des slides de la présentation de Sebastien Dudek (sources).

 

Il a rapidement abordé la version professionnelle de la transmission de données par courant porteur (Ex : compteurs EDF, tarification, gestion du réseau).

Il a ensuite détaillé la solution «SOHO » pour les particuliers principalement basée sur le standard HomePlugAV.

Exemple d’une installation CPL pour un particulier.

Exemple d’une installation CPL pour un particulier.

Les recherches ont été menées sur de nombreux Plugs CPL achetés dans le commerce (Ex : Netgear, Dlink, Devolo, …) ainsi que sur des Plugs CPL fournis avec les Box de certains opérateurs (Ex : Freeplugs, Plugs « Orange »).

  1

Modèles testés par Sebastien Dudek.

 

Le constat qui ressort de l’analyse du hardware est que de nombreux Plugs partagent le même chipset (Ex : Qualcomm Atheros), l’hypothèse est donc qu’une vulnérabilité qui serait découverte sur l’un puisse affecter de nombreux autres modèles (pouvant être de marques différentes).

Sebastien Dudek a conduit ses recherches selon 2 axes :

  • l’analyse des communications entre le logiciel du constructeur et les Plugs CPL (à l’aide de Wireshark principalement car il dispose d’un dissecteur pour le protocole HomePlugAV et à l’aide d’un module qu’il a développé pour scapy afin de supporter la manipulation de trames HomePlugAV).

  • L’analyse du logiciel du constructeur (reverse engineering, décompilation de certaines dll intéressantes).

Ces recherches ont conduit à la découverte de deux « vulnérabilités » majeures :

  • la clef de configuration de nombreux Plugs CPL (DAK) est dérivée de la MAC address du Plug (Attaque KO.DAK).

1

 

Lors des essais, les Freeplugs et certains plugs Orange se sont révélés non vulnérable à l’attaque.

Les Freeplugs ne sont pas vulnérables à KO.DAK (Ouf !).

Les Freeplugs ne sont pas vulnérables à KO.DAK (Ouf !).

Le protocole HomePlugAV dispose d’une fonction « sniff » qui permet à un Plug CPL « attaquant » de découvrir la MAC d’un Plug « maître » sans besoin que le Plug « attaquant »  fasse partie du réseau CPL de la victime.

1

 

La combinaison de ces deux attaques peut conduire à la prise de contrôle du Plug CPL « maitre » à distance, puis une fois l’accès établit, la découverte de la clef du réseau CPL (NMK). Une fois cette clef obtenue, l’attaquant n’a plus qu’à configurer son Plug CPL « attaquant » avec la NMK et il rejoint le réseau CPL de la victime. On se trouve alors sur le même segment ethernet et on peut lancer des attaques classiques (ARP spoofing, DHCP snooping, LLMNR poisoning, …).

1

Ce que j’ai compris de l’attaque en un petit dessin …

En outre pendant la conférence, Sebastien Dudek a fait tomber le mythe du compteur électrique qui bloque le signal CPL.

1

En effet lors de ses recherches, il a testé de nombreux modèles de compteurs électriques et aucun n’est équipé d’un filtre spécifique pour bloquer les hautes fréquences employées par les Plugs CPL. En conséquence dans un immeuble par exemple il est très possible de capter les émissions du réseau CPL de son/ses voisin(s). Le seul moyen de bloquer le signal CPL est de placer à l’arrivée électrique de son installation (après le compteur EDF) un filtre spécifiquement adapté constitué de selfs « choc ».

Une petite revue des outils libres et propriétaires existants pour administrer les Plugs CPL compatibles à la norme HomePlugAV a été menée.

D’autres découvertes ont été réalisées lors de l’exploration des fonctions du protocole HomePlugAV (entre le logiciel du constructeur et le Plug CPL).

Il existe une fonction qui permet de lire une zone mémoire arbitraire du HomePlug (offset, longueur) et qui peut être utilisée pour « dumper » le microcode complet du plug (bootloader, programme, applets, config, …).

Une autre fonction existe pour écrire une zone mémoire arbitraire (offset, longueur, data, crc).

Il est alors envisageable de réaliser le dump, le reverse et placer une backdoor dans le firmware d’un Plug CPL.

Après la conférence, je suis allé poser quelques questions à Sebastien Dudek (retranscription des conversations de mémoire).

AV : Les Plugs LEA (Ex LEA 500Mbps) sont ils vulnérable ?

SD : Oui

AV : Certains plugs CPL disposent d’un bouton d’association automatique, avez-vous exploré cette piste pour conduire des attaques de type association malicieuse au réseau CPL.

SD : Oui j’ai déjà vu un article qui traite de ce moyen, mes recherches actuelles me permettent d’établir l’hypothèse que le mécanisme d’association n’est pas complètement sécurisé. Il serait alors possible lors d’un scénario en Man In The Middle de se faire passer pour l’un des plugs et de s’associer ou de forcer sa propre clef NMK.

SD : De plus j’ai déjà récupéré le firmware de plusieurs modèles de plug CPL grâce à la fonction de lecture de la mémoire. Le code semble être pour une architecture de type ARM, le reverse est en cours.

AV : Merci.

Le futur de la technologie CPL et du standard HomePlugAV s’annonce sombre si les constructeurs ne trouvent pas rapidement des solutions aux failles découvertes par la communauté …

Il reste des pistes laissées pour une exploration future dans la présentation de Sébastien Dudek qui laissent présager de nouvelles découvertes croustillantes 

1

3

 

Mini glossaire :

DAK : clef de configuration du Plug (Master Key).

MAC : Adresse matérielle de l’équipement

NMK : clef secrète partagée par tous les Plugs d’un même réseau CPL.

PLC : Power Line Communication (CPL en français).

SOHO : Small Office Home Office (Équipement à destination des particuliers et des petites organisations).

Sources :

Slides : http://www.nosuchcon.org/talks/2014/D1_03_Sebastien_Dudek_HomePlugAV_PLC.pdf

Sebastien Dudek : http://esec-lab.sogeti.com/pages/People

Rédaction de l’article : A.V.

 

 ***************************************************************************************************************************************

 

The Nitty Gritty of Sandbox Evasion
Rob Rachwald

Rob Rachwald est un des speakers de cette année qui a plus de 15 ans d’expérience dans le domaine de la sécurité. Lors de sa carrière, il a travaillé notamment chez Intel, Fortify, Coverty et Imperva. Il détient actuellement le poste du directeur de recherche sénior à FireEye. Lors de sa présentation à la NoSuchCon, il nous offre une vue globale de quelques méthodes d’évasion de sandbox utilisées par les malwares. 

Remettons les idées en place : 
– Pourquoi a-t-on besoin de sandbox? L’antivirus ne devrait-t-il pas suffire?

Et bien, il s’avère que l’antivirus ne suffit pas. En se basant sur une étude de Imperva nommé ‘Ghost-Huntig with Anti-virus’* mené en octobre 2012, il semblerait qu’uniquement 5% de l’ensemble des malwares ont été bloqué par un antivirus. De plus, d’après l’étude de FireEye:
– 85 pourcent des malwares disparaissent après une heure
– 67 pourcent existe qu’une seul fois

D’après Rob, les antivirus ne sont donc pas aptent à répondre au besoin d’une protection contre malware en temps réel car ils agissent trop tard (un malware donné est détectable par un antivirus que quelques mois après sa première apparition).

– L’évasion de sandbox, de quoi s’agit-t-il?

Dans le scénario décrit, l’objectif est de trouver des moyens de détection de sandbox à partir de l’environnement dans lequel s’exécute le malware, afin qu’il puisse adapter son comportement en conséquence.

– Comment ceci se fait en pratique?

Quatre grand axes de détection et d’évasion de sandbox sont présentés :

1) la détection du facteur humain:

    Souvent, lors d’une analyse anti-malware, l’exécution de celui-ci se fait dans un milieu dans lequel l’interaction avec un utilisateur humain n’a pas lieu. Ceci est un des signes pour un concepteur de malware, que l’environnement d’exécution est une sandbox. La détection du facteur humain peut se faire de différentes façon, par exemple à l’aide d’affichage de boite de dialogue sur l’écran ou l’analyse du comportement des périphériques (souris, clavier).

Des malwares qui illustrent bien cette technique sont BaneChant* ou encore Upclicker* qui ont basé leur mécanisme de détection de sandbox sur l’analyse des cliques de la souris. Upclicker par exemple, déclenche ses fonctionnalités malicieuses qu’après la détection d’un clique de la souris (plus précisément d’un relâchement du clique de la souris). Ceci, a permis à ces malware d’avoir un meilleure taux d’efficacité.


2) l’évasion lié à la configuration

    Certains malwares peuvent tenter de jouer sur des hypothèses concernant la configuration de la sandbox. Par exemple, il est possible que leur fonctionnement soit totalement inoffensifs pendant une longue période de temps et se déclenche qu’après un certain intervalle de temps, ou bien à une date précise. Ceci a notamment été le cas lors des cyber attaques sur la Corée du Sud* qui ont déstabilisé une grande partie des serveurs de plusieurs chaines de télévision et banques le 20 mars 2013. Les attaques ont toutes commencé autour de 14h.


3) évasion spécifique à l’environnement d’exécution d’une sandbox

    Le malware peut parfois déterminer s’il est dans une sandbox en effectuant des vérifications des numéros de version de logiciel qui tourne sur le système. En effet, il est parfois possible d’exclure l’utilisation de certaines sandbox en confirmant que des numéro de versions des logiciels ne correspondent pas à ceux utilisé par la sandbox.

Une autre manière d’évasion utilisée par certains malware est de stocker le code de malware dans des fichiers de types non offensifs (tel que des images .gif ou .jpeg).


4) la détection d’hyperviseurs

    De nos jours, les logiciels de virtualisations telles que VMware ou bien Virtual Box sont fréquemment utilisés. Ces solution de virtualisation n’ont pas nécessairement étaient conçu pour des analyse de sécurité de malware ce qui facilite leur détection pour les concepteurs de malware. En pratique, il est par exemple possible de détecter une machine virtuelle VMware en cherchant des services du type propre à VMware (vmicheatbeat, VMTools, vmci, vmdebug). 

Conclusion:
La problématique d’évasion de sandbox est en perpétuelle évolution et pour l’instant il n’est pas évident d’indiquer une solution parfaite de protection anti-malware. Les techniques d’évasion de sandbox ont notamment permis de ressusciter certains anciens malwares (comme PushDo ou Khelios).

En ce qui concerne la protection, les sandboxs apportent une partie de la réponse, mais ne sont surement pas une solution parfaite.

 

* Ghost-Hunting With Anti-virus – https://www.fireeye.com/blog/executive-perspective/2014/05/ghost-hunting-with-anti-virus.html
* upclicker –
 http://threatpost.com/upclicker-trojan-evades-sandbox-detection-hiding-mouse-click-121412/77320
* banechant –
 http://threatpost.com/stealthy-banechant-trojan-lurks-word-file-relies-multiple-mouse-clicks-040213/77690
* ‘South Korea on alert for cyber-attacks after major network goes down’ –
http://www.theguardian.com/world/2013/mar/20/south-korea-under-cyber-attack
* Nitty Gritty of Sandbox Evasion –
 http://usuaria.org.ar/sites/default/files/documentos/1245_SYMANTEC_FIREEYE.pdf

 

 ***************************************************************************************************************************************

Google Apps Engine security
Nicolas Collignon

Qu’est-ce que le Google App Engine ?

Il s’agit d’un service orienté « cloud computing » mis à disposition par Google pour héberger des applications WEB.
Ces applications peuvent être écrites dans différents languages (Python, Java, PHP et Go) et seront hébergées dans les datacenters de Google.

Nicolas Collignon, en charge du pôle pentest et R&D chez Synacktiv, nous a rapporté les differentes vulnérabilités qu’il a pu rencontré au cours de ses audits et qui affecte cette plate-forme.
Avant de rentrer dans les détails de celles-ci, il est important de rappeler que la plate-forme GAE a pour vocation l’hébergement d’applications et que leurs développeurs restent soumis aux bonnes pratiques usuelles de sécurité.
Ainsi, les différentes vulnérabilités qu’un développeur pourrait introduire dans l’application (injection SQL, cross-site scripting, …) ne sont pas du ressort de la plate-forme et ne sont pas traitées ici.

Les premières vulnérabilités remontées concernent les requêtes de l’application aux web services Google.
La validation des certificats SSL est par défaut désactivée dans la configuration de base du SDK.
Si l’application n’est pas encore en phase de production sur les serveurs de Google mais au contraire toujours présente sur la machine du développeur, il sera possible d’usurper l’identité des web services et d’extraire des données sensibles de l’application.

Par ailleurs, ces mêmes requêtes sont accompagnées d’un header HTTP (X-Appengine-Inbound-Appid ou X-Appengine-Cron) permettant à l’application d’identifier leurs origines.
Bien que l’utilisation de ce champ soit fortement recommandée par Google, en pratique, il semble que de nombreux développeurs ont fait le choix de vérifier l’identité de l’appelant en se basant, à la place, sur le champ User-Agent.
Une nouvelle possibilité d’usurpation d’identité apparaît ainsi.

Si l’on regarde maintenant parmi les API mises à disposition, l’API « Channel » offre des fonctionnalités intéressantes aussi bien pour les développeurs que pour un attaquant potentiel.
En effet, afin de pouvoir lire les données échangées au sein de ces canaux, il faut être muni d’un token qui transite dans les requêtes HTTP.
Si l’application présente une vulnérabilité exploitable de type cross-site scripting, ce token et le contenu des canaux tomberont entre vos mains.

Il a été mentionné plus tôt que plusieurs languages sont supportés par la plate-forme.
Parmi ceux-ci, on retrouve notamment Python dont la sandbox mise en place n’est pas à toute épreuve : en exploitant les éléments classiques (eval, unserialize, pickle), il est possible d’obtenir de l’exécution de code voire un shell interactif sur le serveur.

Par la suite, il est intéressant de voir que les mesures de protection mises en place par Google peut être contournées voire retournées contre lui.
Les serveurs formant l’architecture GAE partagent un même pool de ressources : CPU, mémoire, stockage, traffic réseau …
Afin qu’une application ne sature pas les ressources à disposition, un quota d’utilisation réglable est généralement mis en place.
En forçant l’application à faire des appels répétés à ses sources, ses quotas seront rapidement atteint conduisant ainsi à un déni de service.

Une protection proposée par Google consiste à filtrer les utilisateurs autorisés grâce à leur adresse IP.
Les serveurs d’hébergement sont configurés pour prendre en charge aussi bien l’IPv4 que l’IPv6, laissaint ainsi d’autres portes ouvertes.

Enfin, les développeurs ont tendance à oublier de nettoyer leur environnement de production lorsque leur application est aboutie.
Il sera souvent possible d’accéder à différentes versions de l’application dans le même domaine, des versions qui ne seront pas aussi bien sécurisées ou ayant un mode debug actif.
L’isolation des ressources partagées par ces différentes versions est possible mais rarement implémentées, il sera ainsi possible d’exploiter ces anciennes versions pour atteindre celle en production.

 

***************************************************************************************************************************************

Blended Web and Database Attacks on Real-time, In-Memory Platforms
Ezequiel Gutesman

Introduction

Lors de ce second jour à la NSC 2014, Ezequiel Gutesman nous a parlé d’une technologie de SAP se nommant HANA.

Cette technologie se base sur le principe de base de données en mémoire soit en anglais In-Memory DataBase (IMDB).

Définition

Ce type de système stocke les données en mémoire contrairement aux systèmes traditionnels qui stockent les données sur le disque. Ainsi, la manipulation des données se fait plus rapidement car les données sont directement accessibles en mémoire et non sur le disque.

En règle générale, les systèmes de base de données traditionnels mettent en place une gestion de cache pour accélérer l’accès des données en lecture. Cependant, les contraintes sont inchangées lors d’une opération d’écriture comme l’insertion ou la mise à jour de données.

De plus, la plupart des systèmes IMDB ont prévu des alternatives en cas d’interruption inopiné du serveur. Par exemple, il existe des systèmes de réplications ou de « snapshots » des données pour palier à ce genre de problèmes.

L’inconvénient de ce genre de système est qu’il est gourmand en mémoire. De plus, il n’est pas adapté à toute les problématiques. Seules les applications ayant une contrainte de temps importante dans la manipulation de données peuvent répondre au besoin de ce genre de système.

Découverte de HANA

Authentification

Sur un système d’authentification traditionnel à une base de données, on peut voir apparaître des chaînes de connexion en dur dans le code des applications ou de fichiers de configurations.

Pour pallier à ce problème, avec HANA, l’utilisateur de l’application est le même que l’utilisateur de la base de données. Il faut donc bien configuré les permissions des utilisateurs sur le système.

Back-end code

SAP a développé son propre langage de programmation afin de gérer toute la logique côté serveur. Ce langage nommé XSJS est basé sur SpiderMonkey qui est un moteur JavaScript.

On a donc du code JavaScript côté serveur gérant les données comparable à ce que l’on pourrait trouver avec NodeJS.

Vecteur d’attaque

Dans le cadre d’un pentest de ce genre de système, les axes d’attaques sont les mêmes que pour une application Web. Cependant, les impacts peuvent être différents.

De plus, comme la gestion de l’authentification d’un utilisateur se fait via le compte utilisateur de l’application. Ainsi, dans le cas d’une injection SQL, il est donc possible d’avoir plus ou moins accès à des données selon le compte utilisateur utilisé. (Dans le cas où les permissions des utilisateurs ont bien été configurées)

Par conséquent, l’exploitation d’une injection SQL peut prendre des tournures intéressantes couplée à du Social Engineering.

Ci-dessous liste des vecteurs d’attaques éventuels :

  • SQL injection
  • XSS (Utilisation de blacklist côté serveur facilement bypassable)
  • RCE (utilisation de la fonction eval dans le code côté serveur)

De plus, HANA a été développé en C/C++. Un système nommé XSCFUNC est disponible afin d’appeler des fonctions C/C++ depuis le navigateur Web. Cette fonctionnalité est disponible pour les utilisateurs authentifiés.

Un scénario d’exploitation serait d’arriver à uploader sur le serveur son propre code C/C++ et de l’exécuter via cette interface de communication.

Conclusion

Le système HANA semble vouloir innover dans sa façon de gérer des problématiques dans le traitement des données des entreprises. Cependant, ces objectifs ne doivent pas délaisser l’aspect de la sécurité sur les systèmes d’informations.

 

Pour plus d’informations, voici les sources utilisées pour rédiger cet article :

http://www.nosuchcon.org/talks/2014/D2_04_Ezequiel_Gutesman_Blended_Web_and_database_Attacks_on_real_time.pdf

http://www.mcobject.com/in_memory_database

Rédaction de l’article : L.M.

 

***************************************************************************************************************************************

USBArmory
Andrea Barisani

Petit retour sur la conférence de Andrea Barisani sur le parcours depuis l’idée jusqu’à la conception d’un outil selon l’approche Open Hardware (USB Armory).

A gauche l’USB Armory dans sa dernière version (Release Candidate).

A gauche l’USB Armory dans sa dernière version (Release Candidate).

Andrea Barisani est un chercheur en sécurité de renommée internationale. Depuis qu’il a possédé son premier Commodore-64, il n’a jamais cessé d’étudier les nouvelles technologies, le développement de vecteurs d’attaques non conventionnelles et d’explorer ce qui fait que les choses fonctionnent … puis plantent. Ses expériences se concentrent sur l’administration des infrastructures à grande échelle, de la défense, du forensic, des tests de pénétration et le développement de logiciels ; avec plus de 14 années d’expérience professionnelle dans le conseil en sécurité. Il est un membre actif de la communauté internationale de la sécurité Open Source, il a contribué à plusieurs projets, à des livres et à des standards ouverts. Il est maintenant le fondateur et le coordinateur de l’oCERT, l’équipe de réponse aux incidents de sécurité informatique Open Source. Il a été conférencier et formateur à BlackHat, CanSecWest, DEFCON, Hack In The Box, PacSec et beaucoup d’autres, ses exposés traitent principalement des attaques TEMPEST, du piratage du système GPS, des 0days, du durcissement d’OS et de nombreux autres sujets.

Andrea Barisani nous a exposé le parcours emprunté pour passer d’une idée à un objet « prêt » pour une fabrication en masse (industrialisation). Il a évoqué l’idée de base, les choix qui ont été opérés, les difficultés qui ont été rencontrées, les échecs, les bugs, les découvertes, les apprentissages et l’enrichissement apporté par l’approche open hardware ainsi que ses contraintes.

2

L’idée de départ était de concevoir un genre de « couteau suisse » USB. Le but étant de créer une sorte de mini ordinateur qui pourrait fonctionner indépendamment de l’hôte auquel il est connecté et qui pourrait se transformer en tout ce que son concepteur à imaginé.

Exemple d’applications évoquées par Andrea Barisani :

3

– Clef usb sécurisée (USB Mass Storage), le concept ici est poussé très loin car avec l’USB Armory il est envisageable de réaliser un scan des fichiers avant qu’ils soient écrits sur la zone de mémoire de masse (le périphérique étant autonome, il est par exemple capable de scanner les fichiers au moyen de clamav et en fonction du résultat d’autoriser ou non la copie). Il est possible de réaliser le chiffrement/déchiffrement des fichiers à la volée sur le média de stockage exposé (USB Mass Storage).

4

Une méthode d’auto destruction des données peut même être imaginée (Par exemple en détectant la copie d’un fichier au nom particulier qui déclencherait la procédure de destruction des données).

5

– Routeur réseau local, le concept ici est d’émuler au niveau du stack USB un équipement virtuel tel qu’une carte réseau virtuelle (USB CDC network card). Il est ainsi envisageable de router le trafic réseau du poste auquel est branché l’USB Armory vers ce dernier qui peut par exemple faire fonctionner un nœud TOR ou un VPN et ainsi appliquer une couche de sécurité supplémentaire transparente pour l’utilisateur.

– Mini système linux embarqué (de la même manière que l’utilisation précédente USB CDC network card) on peut imaginer accéder à un système linux (ex kali, debian, …) fonctionnant sur l’USB Armory via ssh. Il est alors possible de le transformer en outil de pentest, placer ses applications scripts dessus, placer par exemple son porte monnaie électronique qui contient des bitcoins, … Les utilisations sont possibles sont très nombreuses.

6

– Authentification du poste de l’utilisateur : un peu comme pour un token sécurisé, l’USB Armory peut vérifier de son propre chef un certain nombre de paramètres du poste auquel il est connecté avant d’autoriser son utilisation (Ex : vérification de l’empreinte du serveur SSH du poste hôte, demande d’un PIN code, …).

Une fois l’idée définie, il a fallu choisir une solution simple et peu coûteuse pour la concrétiser. C’est ici qu’intervient la méthodologie Open Hardware.

L’USB Armory devait donc se conformer à plusieurs critères :

  • De taille raisonnable (a peu près aussi gros qu’une clef USB)

  • Ayant une faible consommation électrique (il doit pouvoir être auto-alimenté par un port USB standard (500mA<).

  • Il doit avoir un CPU puissant et beaucoup de RAM.

  • Il doit pouvoir disposer d’une séquence de boot sécurisée

  • La connectique USB doit être standard (pas de connectique exotique ou propriétaire)

  • Il doit exister une documentation bien fournie pour les composants employés.

  • Il doit pouvoir faire fonctionner des systèmes open-source directement (stock kernel, stock bootloader).

  • Il doit adhérer au concept Open Design (les schémas, le pcb et les sources doivent pouvoir être fournies à la communauté).

Les choix opérés ont été les suivants :

7

  • Un SoC Freescale i.MX53 qui contient un CPU ARM Cortex A8 supportant des fréquences d’horloge entre 800 et 1200 MHz. Ce SoC dispose d’un nombre impressionnant d’interfaces (Serie, I2c, USB, JTAG, …).

8

  • Il supporte la trust Zone ARM (très utile pour implémenter un boot sécurisé). La documentation est bien fournie.
    Ce SoC supporte nativement (Ubuntu, Debian, Android, FreeBSB et quelques RTOS). Les stocks sont abondants et la production peut répondre à une forte demande.

  • Une mémoire RAM DDR2 de 512 Mo.

  • Un circuit de petite taille (65mm x 16mm x 6mm)

  • Une faible consommation (500mA<)

  • Un slot micro-SD

  • 5 points de connexion (5 GPIO)

  • 1 led (accessible uniquement par la Trusted Zone ARM ce qui permet d’indiquer visuellement si l’USB armory se trouve en mode sécurisé).

  • Le support de l’émulation de périphériques USB virtuels (CDC Ethernet, HID, mass storage, …).

  • Hardware et Software ouverts.

Ensuite Andrea Barisani a expliqué les problèmes qu’ils ont rencontrés lors de la conception de l’USB Armory.

Lors de la phase de prototypage, il a fallu tester le SoC Freescale i.MX53 pour s’assurer qu’il réponde aux exigences.

Voici le SoC (NDR : ça va être dur de poser des points de test là-dessus !)

Voici le SoC (NDR : ça va être dur de poser des points de test là-dessus !)

A gauche, le SoC Freescale i.MX53 recto et verso, à droite un lego, en haut Dark Vador.

Il a donc été nécessaire de concevoir une carte imprimée pour éclater les connexions très rapprochées du SoC pour pouvoir travailler à « l’échelle humaine ».

Voici le prototype finalisé de la carte pour « éclater » les connexions du SoC.

Voici le prototype finalisé de la carte pour « éclater » les connexions du SoC.

Donc le SoC se place au centre de cette carte et il est maintenu en place et en contact avec les pistes du circuit au moyen d’un connecteur complexe qui l’immobilise et le presse de façon homogène sur toute ça surface. Pour info la conception de cette carte à couté dans les 300 à 400 euros.

Le problème qui s’est posé c’est que les tests effectués avec cette carte n’on jamais fonctionnés ! En effet la documentation du SoC indique que ce dernier est particulièrement pointilleux sur les longueurs des connexions entre le SoC et la RAM (Ah oui on travaille en haute fréquences – plusieurs centaines de MHz – et donc une différence de quelques millimètres dans la longueur de deux pistes reliant le SoC et la RAM et tous les « timings » sont foutus, les bits arrivent dans le désordre sur le bus). Résultat une carte de prototypage fabriquée pour rien.

Ensuite est venu un problème lors des tests sur l’alimentation du SoC …

Cartes prototypes pour les tests d’alimentation du SoC (au centre un « super régulateur »).

Cartes prototypes pour les tests d’alimentation du SoC (au centre un « super régulateur »).

Un SoC est un composant très complexe qui ne s’alimente pas simplement avec les 5v du port USB il lui faut un nombre impressionnant de tensions (5v, 3,3v, 1,8v, …).

Pour cela on utilise un « super-régulateur » qui prend en entrée les 5v du port USB et restitue toutes les tensions nécessaires au SoC. Le souci est que pas moins de 10 cartes comme celles-ci-dessus ont été conçues lors des multiples essais « infructueux » d’alimentation du SoC avant d’en trouver finalement la cause. En fait les connexions (fils) pour relier la carte au SoC sont tellement longues (quelques dizaines de cm) que les tensions les plus faibles sont tellement affaiblies qu’elles sortent de la zone de tolérance du SoC. Ce dernier ne recevant pas la bonne tension il reste muet (refuse de démarrer).

12

Au final le prototype (version alpha) a ressemblé directement au produit fini. Pour concevoir le circuit, Andrea Barisani a utilisé le logiciel libre KiKad. Il nous explique ensuite les avantages et les inconvénients lors de l’utilisation d’un logiciel libre de conception électronique par rapport à son « concurrent » propriétaire.

Une première statistique est qu’il a fallu 7 fois plus de temps pour concevoir le prototype sur KiKad qu’il en n’aurait fallu sur un logiciel professionnel propriétaire. Cela tiens au fait que pour ce degré de complexité de schéma il manque à Kikad certains outils de routage automatique, notamment pour le routage des pistes en « hautes fréquences », rappelez vous la longueur de toutes les pistes qui relient la RAM au SoC doivent faire la même longueur !

En blanc les pistes qui relient la RAM au SoC.

En blanc les pistes qui relient la RAM au SoC.

Donc avec un logiciel professionnel un routeur automatique s’occupe de tout avec les contraintes qui sont imposés. Mais avec KiKad il faut le faire manuellement ! Router et mesurer chaque piste d’où la perte conséquente de temps.

En revanche avec KiKad on peut réaliser de très belles vues en 3D du prototype pour voir comment ça rends avant de le réaliser pour de bon (et obtenir un aperçu des encombrements de certains composants ou encore les placer de manière aligné pour que ce soit esthétiquement plus beau). Ce qui n’est pas le cas des solutions propriétaires, de toute façon l’esthétique du circuit n’étant pas leur but 😛

Rendu 3D dans KiKad !

Rendu 3D dans KiKad !

Suite à tout cela, le prototype alpha était enfin prêt !

Version alpha placé sur une carte de test (JTAG en haut et port série en bas, déportés).

Version alpha placé sur une carte de test (JTAG en haut et port série en bas, déportés).

Andrea Barisani fut ensuite confronté a un bug des plus étranges dont il nous a conté l’histoire :

Sur le modèle alpha nous avons constaté un retard de 5 secondes lors du démarrage du SoC lorsque l’USB armory était inséré dans le port USB. Mais si on branchait l’USB armory sur une rallonge USB et que l’on connectait cette dernière au port USB de l’hôte alors le démarrage du SoC était immédiat !

Quelle était donc cette sorcellerie ?

Après 3 jours éreintant de recherches et de tests en tout genre, Andrea Barisani décida de rechercher dans tous les datasheets des composants une caractéristique de temps de 5 secondes. Et il trouva une allusion à un temps de 5 secondes dans la documentation du circuit régulateur de tension. « Lors de la détection d’une condition de sous-alimentation en entrée du circuit, le régulateur attends une durée fixe de 5 secondes avant de mettre a disposition les tensions régulés sur sa sortie ». Ceci pointa les recherches dans la direction du connecteur USB de la platine. En effet lors de son insertion, les pistes externes d’alimentation ne venant pas tout au bord de la platine, les contacts du connecteur de l’hôte rebondissent que quelques micromètres pendant son insertion ce qui cause des micro-coupures dans l’alimentation, d’où la détection d’une condition de « sous-alimentation » par le régulateur de tension.

Zoom sur le connecteur USB conçu à même le PCB.

Zoom sur le connecteur USB conçu à même le PCB.

Une autre leçon apprise lors de la conception de ce projet et de bien tenir compte des tailles, poids et contraintes imposés aux composants d’un montage qui sera manipulé « avec très peu de délicatesse ». En effet après une dizaine de manipulation du circuit alpha, quelques composants de taille raisonnables se sont détachés de leurs pastilles !

17

C’est sur ces sages enseignements que s’est terminée la présentation de l’USB Armory.

Pour finir, à la fin de la présentation, je suis allé poser quelques questions à Andrea Barisani.

AV : Ce projet me fait penser au projet USB Dancer, avez-vous prévu de vous rapprocher de l’équipe qui développe USB Dancer pour par exemple intégrer les scripts python sur le mini linux embarqué sur l’USB Armory et ainsi le transformer en plateforme de Pentest pour l’USB ?

La carte FaceDancer.

La carte FaceDancer.

AB : Oui je connais l’outil FaceDancer mais il est assez lent, par exemple l’émulation d’un périphérique USB Mass Storage en python ralentit considérablement les temps de transfert d’un fichier. L’USB Armory est beaucoup plus puissant que FaceDancer et il est tout à fait possible de porter les scripts tels que « umap » dessus. Je note votre remarque merci.

AV : J’ai vu que le SoC Freescale i.MX53 intègre un GPU, savez vous si il est possible d’émuler un périphérique virtuel de type « Carte vidéo USB » et de par exemple réaliser de l’analyse vidéo sur le flux reçu au moyen du GPU.

AB : Je ne comprends pas bien le but visé, mais ce doit être possible.

AV : En fait c’était dans l’optique de transformer l’USB Armory en un outil de pentest par exemple en instanciant les périphériques virtuels suivants (HID mouse, HID Keyboard, Virtual VGA card) dans l’optique de lancer des attaques complexe au moyen des périphériques tels que le clavier et la souris puis d’obtenir un retour de l’affichage qui puisse être analysé. (Un exemple en particulier serait le bypass de captcha, la capture de l’écran de la victime, …).

AB : Ah ok, oui en effet c’est intéressant.

AV : Merci.

AB : Merci à vous aussi.

Rédaction de l’article : A.V.

Mini Glossaire :

SoC : System On Chip (sorte de micro ordinateur intégré dans une puce).

USB : Universal Serial Bus, Bus de communication informatique très répandu.

JTAG : L’interface Jtag est utilisée, entre autre, pour la programmation in situ de composants.

UART : (Universal Asynchronous Receiver Transmitter), plus vulgairement un Port Série.

I2c : Acronyme de Inter Integrated Circuit. Un bus qui permet la communication entre des circuits intégrés sur de faibles distances (quelques centimètres à un mètre).

GPIO : Les ports GPIO (General Purpose Input/Output, littéralement Entrée/Sortie pour un Usage Général) sont des ports d’entrée/sortie très utilisés dans le monde des microcontrôleurs, en particulier dans le domaine de l’électronique embarquée, qui ont fait leur apparition aux débuts des années 1980

OSC : Abréviation d’Oscillateur.

RAM : La mémoire vive, ou mémoire système aussi appelée RAM de l’anglais Random Access Memory, est la mémoire informatique dans laquelle un ordinateur place les données lors de leur traitement.

ARM : Les architectures ARM sont des architectures RISC 32 bits (ARMv1 à ARMv7) et 64 bits (ARMv8) développées par ARM Ltd depuis 1990 et introduites à partir de 1983 par Acorn Computers.

HID : La spécification HID (Human Interface Device) est une couche d’abstraction plus élevée que le protocole USB.

Sources :

Slides NoSuchCon : http://www.nosuchcon.org/talks/2014/D2_05_Andrea_Barisani_forging_the_usb_armory.pdf

FaceDancer : http://goodfet.sourceforge.net/hardware/facedancer21/

Rédaction de l’article : A.V.

 

 ***************************************************************************************************************************************

Cryptographic Backdooring
Jean-Philippe Aumasson

Jean-Philippe Aumasson a partagé avec nous sa vision des backdoors d’un point de vue assez inhabituel.
Lorsque beaucoup se focalisent sur la façon de s’en protéger ou bien de les détecter, il était ici question de déterminer les caractéristiques nécessaires à une backdoor de qualité.
Dans un second temps, l’orateur nous a montré comment ces différentes caractéristiques pourraient être appliquées dans son champ de prédilection : la cryptographie.

Voici la présentation qui nous était donnée : une backdoor est une fonctionnalité ou un défaut qui permet un accès dissimulé aux données.
Au delà de cette définition, il est important de prendre en compte certains aspects supplémentaires.
Par exemple, une backdoor a pour vocation de n’être utilisée et connue que de par son seul concepteur. Dans le cas contraire, il serait plutôt question d’une « trapdoor » ou d’une « bugdoor » toujours d’après l’auteur.

Des considérations similaires ont amené à établir la liste de charactéristiques suivantes :
– « Plausibilité » : si la backdoor vient à être découverte, elle doit pouvoir être vue comme une erreur de programmation sans trop de soupçons.
– Indétectable : dans l’idéal, seule son auteur connait son existence.
– « NOBUS » (No one but us) : terme employé par la NSA signifiant clairement que son usage n’est destiné qu’à ses créateurs.
– Réutilisable : la backdoor ne doit pas perdre l’une de ses autres caractéristiques après une première utilisation.
– Immodifiable : personne d’autre ne doit pouvoir modifier ces caractéristiques.
– Sécurisé : protection contre les accès non autorisés ou le reverse engineering.
– Simple : plus sa complexité augmente, plus le risque de d’y introduire des bugs est élevé.

Voyons à présent comment implémenter une telle backdoor au nez et à la barbe de tous dans la cryptographie de tous les jours.

Le premier exemple qui nous était donné concerne l’algorithme SHA-1.
Bien que l’algorithme ne puisse pas être inversé, il peut être exploité si l’on peut trouver des collisions.
Il est possible de considérablement augmenter les chances de trouver de telles collisions dans l’algorithme en effectuant une modification minime et d’apparence anodine dans celui-ci : il suffit pour cela de modifier seulement 40 bits parmis les constantes utilisées par l’algorithme.

Au delà de l’aspect aléatoire d’une constante dans un algorithme, les chercheurs à l’origine de cette étude ont introduit la notion de rigidité permettant d’estimer la qualité de ces constantes (dans le domaine des courbes elliptiques seulement).
Des tests de rigidité ont été effectués contre les constantes utilisées dans de nombreux algorithmes. Pour ne citer que celui-ci, la courbe FRP256v1 (recommandée par l’ANSSI) a reçu la qualification de « trivialement manipulable ».

Une autre possibilité très simple et facilement implémentable consisterait à omettre « involontairement » une vérification qui intervient dans l’algorithme.
Qu’en serait-il si le protocole d’échange TLS effectuait une validation incomplète des certificats qui lui sont soumis ..?
La désormais célèbre faille connue sous le nom d’ « Heartbleed » a été mentionnée quelques instants, tout se résume à un (innocent ?) « goto » qui a causé bien des torts. A chacun de se faire sa propre idée sans tomber dans la paranoïa

Un dernier exemple particulièrement efficace consisterait à introduire une backdoor au niveau du matériel électronique.
Détecter un comportement inhabituel dans une puce électronique effectuant une opération banale peut être difficile. Pour vous en convaincre, imaginons un composant effectuant une simple multiplication X * Y = Z.
S’il existait une paire « magique » unique (X, Y) pour laquelle cette multiplication avait un comportement contrôlé, il serait possible de compromettre des algorithmes tels que RSA ou ECC avec des efforts moindres.

***************************************************************************************************************************************

Hardware Workshop – Fun with RF remotes
Damien Cauquil

Ce Workshop s’est déroulé en deux parties :

  • Une partie théorique que tout le monde pouvais suivre (1h)
  • Une partie pratique (assemblage d’un « mod » électronique) ou seuls 10 participants inscrits depuis le site web avant la NSC#2 ont été conviés. Les autres personnes présentes pouvaient tout de même assister à la partie d’assemblage du « mod » (1h).

Ce workshop s’est déroulé entre 12h00 et 14h00. J’ai eu la grande chance de pouvoir prendre part à la seconde partie bien que n’étant pas inscrit, grâce au désistement d’un participant et l’absence de personnes en liste d’attente secondaire (sans doute tiraillés par la faim après les 1h de théorie).

  • La partie théorique a présenté rapidement mais avec brio les concepts nécessaires à une première prise en main de la SDR.
    – fréquence d’un signal (les bandes autorisés en France 433MHz et 886 MHz)
    – méthodes de transmission (AM, FM)
    – méthodes d’encodage (OOK, PWM, PSK, QAM)
    – chiffrement / codes tournants (circuits spécialisés, microprocesseurs, …)


12

Une démonstration avec un récepteur SDR (Clef USB TNT) et les logiciels GNU Radio et Audacity a mis en évidence le fait qu’il est possible de capturer facilement et simplement le signal d’une télécommande « bas de gamme » (Ex : bouton de sonnette sans fil) pour peu que l’on connaisse sa fréquence d’émission. Le logiciel Gnu Radio est très puissant et permet de réaliser les premières étapes de traitement du signal (démodulation) et permet sa sauvegarde sous la forme d’un fichier WAV. Une fois un échantillon du signal capturé, il est possible de l’analyser avec le logiciel Audacity sous forme d’un oscillogramme, et ainsi de zoomer et identifier les parties du signal ou le code de la télécommande est transmis.

Bien sur, le simple récepteur SDR ne permet que la capture du signal, il n’est pas en mesure d’émettre. Mais étant donné son cout très modique (10 à 30€) il est parfait pour débuter !
En revanche il existe des projets de SDR conçus pour émettre et recevoir :

  • Hack RF (réception et émission half duplex) environ 300€
  • Blade RF (réception et émission full duplex) environ 400 à 600€
  • USRP (réception et émission full duplex) environ 1500 à 3000€

La présentation enchaine ensuite sur l’esprit « hacker », qu’est ce que l’on pourrait bien faire de cette petite télécommande ?

  • Un brouilleur de signal 433MHz ! En retirant la limitation de puissance d’émission et en émettant de façon continue. En effet ainsi cela causera un déni de servie si le brouilleur est placé assez près d’un récepteur, ce dernier ne pouvant entendre le code d’un émetteur valide parmi le bruit créé par le brouilleur. Mais nous somme en France et la loi est assez stricte quand au brouillage des fréquences (Article L. 39-1) !
  • Un « bruteforceur » de code. En effet le code de l’émetteur est configuré par un bloc de 6 cavaliers (2^6 = 64 combinaisons). Serait-il possible de concevoir un montage électronique qui viendrait se greffer sur l’émetteur et qui placerait successivement toutes les combinaisons possibles, permettant ainsi d’émettre tous les codes sur un cours laps de temps.

 

3

Schéma de principe de l’émetteur sans fil.

Et c’est sur ce dernier postulat que la seconde partie du Workshop s’enchaine !

 

4

Schéma de principe du circuit à assembler.

Votre but chers participants est d’assembler le circuit qui va vous être remis (souder les composants) et de faire sonner le carillon (placé sur la table de l’organisateur et dont la mélodie est « trololo ») dont vous ne connaissez pas le code. Vous avez 1h, 4 organisateurs sont là pour vous assister en cas de problème, les étapes du montage sont passés sur le projecteur et une version finalisé de l’émetteur modifié circule sur la table (pour servir de modèle) et des sandwichs ont été distribués. Les participants on reçu une formation rapide au maniement du fer à l’ordre d’implantation et des consignes de sécurité lors de la soudure (ne pas respirer la fumée qui se dégage quand l’étain fond !), je n’ai écouté d’une oreille car j’attaquais déjà l’implantation des résistances et des circuits intégrés …

J’ai constaté que le niveau des participants est très disparate, certains n’avais jamais soudé de leur vie, d’autres avaient une petite expérience et certains (comme moi) avaient un très bon niveau.

Mon camarade de gauche n’avait jamais soudé et en plus Murphy semblait lui en vouloir car il a hérité de deux fers à souder hors d’usage (le 3ème fut le bon). Je lui ai appris à souder en quelques minutes et le voila parti ! Le résultat qu’il à obtenu pour sa première fois était très respectable (son montage à fonctionné du premier coup). D’autres s’en sont moins bien sortis. Personnellement j’ai opté pour une modification du mod afin de rendre le parcours des codes plus rapides (en effet un défaut de conception dans le montage faisait qu’il se superposait au dessus du bouton de la télécommande lors de l’assemblage final), les organisateurs ont donc demandés aux participants de décaler les branchements entre la sortie du compteur binaire et le circuit de l’émetteur de deux bits pour ne pas chevaucher le bouton. Quant à moi j’ai décidé de réaliser la soudure des diodes signal en biais pour disposer des bits de poids faible (opération chirurgicale réalisé avec un fer à grosse panne et sans 3ème main, les experts me comprendront ^_^).

La seconde partie du workshop a durée plus longtemps que prévu, entre les montages qui ne marchaient pas à la fin, les participants qui essayaient en même temps (brouillage inter bruteforceur). Mais au final les 10 participants sont repartis chacun avec leur bruteforceur et un carillon sans fil MP3.

6

5

 

 

 

 

 

 

 

 

 

 

 

 

Le récepteur du bouton de sonnette sans fil.

7Configuration du code sur le récepteur au moyen de 6 interrupteurs miniatures.

8910

L’émetteur une fois le « mod » attaché (soudé).

J’ai remercié plusieurs fois tous les organisateurs et suis parti manger (enfin).

Mini Glossaire :
SDR : Une radio logicielle, en anglais Software Radio ou Software Defined Radio (SDR), est un récepteur et éventuellement émetteur radio réalisé principalement par logiciel et dans une moindre mesure par matériel.
AM : Amplitude Modulation, La modulation d’amplitude est une technique utilisée pour moduler un signal. Elle consiste en la multiplication du signal à moduler par un signal de fréquence plus élevée.
FM : Frequency Modulation, La modulation de fréquence ou MF ou FM est un mode de modulation consistant à transmettre un signal par la modulation de la fréquence d’un signal porteur (porteuse).
OOK : On Off Keying, désigne la forme la plus simple de modulation d’amplitude (Shift Keying ou ASK) qui représente des données numériques par la présence ou l’absence d’une onde porteuse. Dans sa forme la plus simple, la présence d’une porteuse pour une durée particulière représente un « 1 » binaire, alors que son absence pendant la même durée représente un « 0 » binaire.
PWM : La modulation de largeur d’impulsions (MLI ; en anglais : Pulse Width Modulation, soit PWM), est une technique couramment utilisée pour synthétiser des signaux continus à l’aide de circuits à fonctionnement tout ou rien, ou plus généralement à états discrets.
PSK : Le Phase-shift keying (ou PSK, soit « modulation par changement de phase ») désigne une famille de formes de modulations numériques qui ont toutes pour principe de véhiculer de l’information binaire via la phase d’un signal de référence (porteuse), et exclusivement par ce biais.
QAM : La modulation d’amplitude en quadrature (en anglais, Quadrature Amplitude Modulation : QAM) est une forme de modulation d’une porteuse par modification de l’amplitude de la porteuse elle-même et d’une onde en quadrature (une onde déphasée de 90° avec la porteuse) selon l’information transportée par deux signaux d’entrée.
TNT : Télévision Numérique Terrestre.

Rédaction de l’article : A.V.