SSTIC 2013 – Jour 1

Propos recueillis par: Geoffrey Bertoli, Antoine Cervoise, Grégory Charbonneau, Romain Léonard, relu par Isabelle Feetz.

Après quelques heure de route et une courte nuit de sommeil, c’est sous un ciel bleu et un soleil de plomb que nous avons assisté à la onzième éditoin du Symposium sur la Sécurité des Technologies de l’Information et des Communications 2013 ou SSTIC.

info : les actes seront disponibles sous peu à l’adresse https://www.sstic.org/2013/actes/. Le support des présentations peut être trouvés sur le site du SSTIC pour chaque conférence.

Innovation en crypto symétrique

Par John Daemen

L’orateur a créé de nombreux algorithmes de chiffrement, comme il sera souligné ultérieurement.

John a commencé la présentation par la description de la fonction de DES : c’est une fonction f appliquée plusieurs fois à une partie du texte à chiffrer. Cette fonction f est composée de XOR et SBOX.

Ensuite, il présente le challenge AES :
Une des meilleures solutions proposées est l’algorithme Blowfish, d’après lui cet algorithme a beaucoup de potentiel. En effet, la diffusion est bonne, mais il utilise 4 S-Box différentes pour 4 parties différentes du plaintext.
Cet algorithme a été cryptanalysé en 1994 car les clés utilisées dans les S-Box étaient trop faibles. Il s’est donc demandé s’il pouvait l’améliorer. Il a donc créé un algorithme utilisant une seule S-Box répliquée 4 fois mais utilisant une clé plus forte optimisant ainsi la non linéarité, en série avec la SBOX il a mis une « Linear mixing layer » améliorant par la même occasion la diffusion de l’algorithme. Cet algorithme ainsi optimisé, nommé Rijndael, est devenu AES.

Malgré tout, les attaques bicliques de 2011 ont permis de réduire le temps de cassage de la clé par 4 environ.
L’orateur est ensuite revenu sur la manière dont il avait crée SHA-3. Contrairement aux autres algorithmes de hashage, SHA-3 n’utilise pas de « Cipher Block » mais uniquement des permutations. Son algorithme est robuste et utilise très peu de ressources, ce qui était une des demandes des organisateurs du concours SHA-3.

Il a fini par rappeler les 3 principes importants pour créer un bon algorithme de chiffrement :
- Il vaut mieux repartir de zéro plutôt que de faire des patchs de l’existant (AES n’est pas un dérivé de DES) ;
- La simplicité est primordiale : en effet, dans AES il n’y a qu’une seule S-Box, l’algorithme de hashage utilisant des permutations est lui aussi plus simple ;
- Il vaut mieux se concentrer sur le résultat que sur la publication : le résultat n’en sera que meilleur.

Mise à plat de graphes de flot de contrôle et exécution symbolique

Par Eloi Vanderbeken

L’orateur travaille comme chercheur en sécurité chez Oppida. Le sujet de la présentation est la récupération d’un Graphe de Flot de Contrôle (CFG), d’un binaire obfusqué (ou obscurci/brouillé), afin de le rendre lisible par un humain.

Il existe deux catégories d’obscurcissement :

• Des méthodes « bas niveau », qui sont réalisables après la compilation, comme l’insertion de code mort ou le chiffrement du contenu ;
• Des méthodes « haut niveau », qui nécessitent des informations contextuelles, comme l’état des variables globales ou le CFG, et qui sont réalisées lors de la compilation. Parmi ces méthodes, on compte la mise à plat des CFG : c’est ce type d’obscurcissement qui sera traité lors de cette présentation.

Qu’est ce que la mise à plat d’un graphe de flot de contrôle ?
C’est le fait de modifier un CFG de manière à ce qu’à chaque changement de bloc, on repasse par un gestionnaire, comme on peut le voir sur le schéma suivant :

Ainsi, un humain aura du mal à savoir quel bloc sera exécuté et dans quelles conditions. Pour cela Il devra avoir un accès à la valeur de chaque registre à chaque moment de l’exécution.

L’idée est donc de recréer un CFG lisible. Compte tenu de cette contrainte, il existe trois approches envisageables :

• Analyse dynamique avec suivi d’exécution ;
• Analyse dynamique avec suivi de données ;
• Analyse statique.

La première méthode permet une reconstruction facile d’un CFG en récupérant la trace d’exécution. Cependant, l’analyse ne peut être exhaustive car il y a toujours une possibilité d’oublier des traces.

Pour la seconde méthode, il faut à présent s’attacher à la transformation des données, l’idée n’étant pas de regarder les étapes de l’exécution mais de tracer les variables et leur modification.

Dans ce cas, les problèmes résultent du fait qu’on ne puisse récupérer la structure du code initial et que les expressions mathématiques de description des variables peuvent s’avérer lourdes et complexes.

La troisième méthode est celle qui a été choisie par Eloi, elle s’appuie sur une abstraction des variables et une exécution symbolique du programme. Ici, l’avantage est que l’exécution symbolique permet de récupérer l’intégralité du CFG, y compris la structure du code. En revanche, il faut faire attention aux abstractions choisies afin de ne pas induire des calculs lourds et complexes.

L’orateur présente tout d’abord comment réaliser une exécution symbolique. On exécute le code symboliquement de manière à obtenir une trace statique (celle-ci peut contenir plusieurs traces dynamiques, notamment si le code possède des conditions). On récupère ensuite le contexte symbolique correspondant aux valeurs probables de chaque variable. Ensuite, on utilise un solveur d’équation basé sur Z3 (un solveur d’équation développé par Microsoft) afin de pouvoir résoudre toutes les conditions de saut. Pour finir, on optimise la trace statique en supprimant les blocs vides et les conditions jamais atteintes.

Une démonstration a été faite en fin de présentation simplifiant notablement un CFG pourtant très complexe.

Slides dispo : https://www.sstic.org/2013/presentation/execution_symbolique_et_CFG_flattening/

Polyglottes binaires et implications

Par Ange Albertini

Ange Albertini travaille actuellement chez Avira dans une division d’ingénierie inversée. Il a déjà participé à de nombreuses conférences et challenges. Il est également connu pour des nombreuses publications traitant également d’ingénierie inversée.

La présentation, dynamique et ludique, ponctuée de démo, est axée sur l’étude de fichiers binaires dits « polyglottes ». Il s’agit de fichiers qui peuvent être interprétés différemment en fonction du programme qui les lit.

L’orateur nous explique donc les vulnérabilités de certains de ces types de fichiers :

• Pour le format PE de Windows, le fichier doit commencer par MZ et doit contenir à l’offset 0×3C du fichier l’adresse de la suite du PE ;
• Pour le format PDF, l’interprétation démarre au marqueur %PDF qui doit être placé dans les 1024 premiers octets ;
• Pour le format HTML, l’interprétation débute avec la balise qui peut se trouver n’importe où dans le fichier ;
• Pour les ZIP ou les JAR, il peut être placé n’importe où.

En partant de ces données, il est possible de créer un fichier qui aura un comportement différent en fonction de l’interpréteur.
De plus, pour un PDF donné, on peut obtenir un comportement différent sur Adobe Acrobat Reader, sur Chrome ou Sumatra.

Ces comportements pourraient, par exemple, permettre de créer un fichier qui, au choix :
- Masquera un PDF malveillant à un antivirus qui le prendra, par exemple, pour un exécutable légitime ;
- Permettra l’upload d’une image sur un site Web qui pourra ensuite être exécutée en tant qu’Applet Java malveillante.

Pour conclure, les éditeurs de logiciel et les antivirus doivent refuser l’exécution de fichiers mal formés.

Recompilation dynamique de codes binaires hostiles

Par Sébastien Josse

Sébastien Josse est un chercheur en sécurité actuellement employé dans la section Maîtrise de l’Information d’un laboratoire de recherche de la DGA.

La problématique de cette conférence réside dans la constante progression des méthodes qu’utilisent les créateurs de malware pour protéger leur code contre les antivirus, mais aussi contre l’ingénierie inversée. Malheureusement, les outils d’analyse, aussi bien statique que dynamique, ne jouent plus à armes égales avec ces méthodes de protection.

D’un côté, l’analyse statique se trouve limitée par des techniques d’obscurcissement de plus en plus perfectionnées comme l’aplatissement de graphes de flot, déjà présenté à l’avant-dernière conférence par Eloi Vanderbéken.
D’un autre côté, l’analyse dynamique est vite repérée par la présence des interruptions nécessaires aux break-points.

L’approche de Sébastien propose de descendre d’une couche système pour se placer au niveau de l’hyperviseur.
Pour ce faire, il a développé l’outil VxStripper. Celui-ci s’insère dans la fonction de réécriture de QEMU et génère un langage compatible avec LLVM.
Cet outillage lui permet d’abord de « dépacker » le binaire, puis, après une seconde passe, de simplifier le code de sortie pour obtenir un code au plus proche du code d’origine.

Pour finir, l’outil est d’ores et déjà fonctionnel et la démonstration montre qu’il est efficace sur un binaire simple. Apparemment, l’outil n’est certes pas encore disponible, mais sa diffusion est prévue : seule la date officielle manque.

Présentations courtes

nftable par Éric Leblond

Après avoir fondé EdenWall Technologies, Éric Leblond est actuellement développeur principal chez Open Information Security Foundation. Il est responsable du port du pare-feu d’Open Office vers LibreOffice =).

À l’heure actuelle, l’ajout de règle est “pourri” en termes de performance, selon l’orateur. IPSET a été introduit et permet de gérer des ensembles de manière très efficace. On peut définir une liste d’IP afin de gérer le tout de manière plus dynamique, ce qui reste à voir selon l’orateur.

Les défauts de IPtables sont principalement la présence de code similaire pour de nombreux modules Netfilter et le fait que certaines fonctionnalités sont impossibles à mettre en place (port source == port destination).

Par conséquent, un nouveau système de filtrage a été développé et présenté en 2008 (nftable) en vue de remplacer les IPtables et l’infrastructure de filtrage. Cependant, aucun changement dans les hooks, le suivi des connexions ainsi que les helpers n’est prévu.

Le langage sera basé sur une grammaire et accessible depuis une bibliothèque. De plus, la communication utilise Netlink ce qui permet de réaliser des modifications atomiques et un système de notification. Il y a donc une séparation distincte entre l’espace utilisateur et l’espace noyau.

Nftables fonctionne en mode fichier, en ligne de commande et en mode client (CLI). La gestion des ensembles anonymes ou nommés, mais : “Ça c’est trop simple, on va faire un truc encore mieux”.

Il est possible de faire du mapping anonyme et nommé, c’est-à-dire de “droper tout ce qui provient de ce réseau, sauf cette adresse IP précise”, le tout en une seule ligne.

Il est à souligner qu’il existe une bibliothèque de compatibilité avec IPtables (IPtables-Nftables) pour “ne pas perdre tout le monde”.

Disponibilité fin 2013 à l’adresse suivante http://www.netfilter.org. Le support de présentation est disponible à l’adresse suivante https://www.sstic.org/media/SSTIC2013/SSTIC-actes/nftable/SSTIC2013-Slides-nftable-leblond.pdf

Présentation courte

Parsifal, ou comment écrire rapidement des parseurs robustes et efficaces
Olivier Levillain, ANSSI

Olivier Levillain est chef du laboratoire sécurité des réseaux et protocoles au sein de la sous-direction expertise de l’Agence nationale de la sécurité des systèmes d’information (ANSSI). Ses travaux actuels portent sur la sécurité des navigateurs, mais ses centre d’intérêts couvrent également la sécurité des systèmes, les vulnérabilités liées au matériel ou encore les langages de programmation.

Pour étudier un format ou un protocole, le mieux est de l’implémenter. Cependant, de petits détails au sein des protocoles peuvent être gênants.

Wireshark, Scapy et Hachoir connaissent déjà de nombreux protocoles et sont facilement utilisables, mais deux d’entre eux sont limités au réseau. De plus, « Le Python, c’est lent ».

Plusieurs outils ont été codés en Python dans le lab. mais ils sont considérés comme lents à l’exécution donc ils sont passés à C++, plus rapide, mais ils restent trop verbeux et pénibles à mettre au point.
Un outil en OCaml a donc été développé avec un préprocesseur nommé Parsifal.

La plaquette de Parsifal est la suivante :

• Efficacité du code produit ;

• Robustesse ;
• Adaptation à l’écriture incrémentale de parseurs flexibles.

Parsifal permet également d’extraire les objets décrits en plus de pouvoir les parser (client DNS en 200 lignes).

L’orateur donne un exemple concret avec la structure d’une image PNG. Il déclare simplement la structure d’une image PNG (avec la taille, le Chunk Type, la data et le CRC) et il obtient un code permettant de parser l’objet et de l’extraire.
Cet exemple est agrémenté de démo pour prouver le peu de code demandé à l’utilisateur.

Les formats implémentés sont : X509, SSL/TLS, PE, Kerberos, TAR, DNS, PNG, PCAP ; ceux qui ne sont pas implémentés : Base64, Zlib, etc.

La v0.1 est publiée sur GitHub, la documentation reste à consolider.

Compromission d’un terminal sécurisé via l’interface carte à puce

Par Guillaume Vinet

L’utilisation d’une carte à puce est considérée comme l’équivalent d’un coffre-fort numérique à faible coût. Cependant, l’authentification nécessite la saisie d’un code PIN sur le clavier du PC, ce qui n’est pas sécurisé, comme montré au CCC 2010. Un terminal bancaire a donc été créé, avec branchement en USB sur le PC.

La saisie du code PIN est confinée dans le terminal, à l’exception des échanges avec la carte, c’est-à-dire que le code PIN ne transite pas par le PC.

Diverses attaques de terminal sont à exploiter : attaque physique, rayon électromagnétique ou démontage et analyse de la mémoire après saisie du code PIN.
L’orateur s’est penché sur l’attaque par l’interface de carte à puce car elle est rapide, non destructive, peu détectable et rarement prise en compte.

Ainsi, on pourrait débrancher le terminal en le gardant sous tension et le brancher au PC d’analyse, mais cela s’avère un peu encombrant.

L’orateur a donc visé le protocole ISO 7816-3 en utilisant l’Answer To Reset (ATR) ce qui permet de récupérer des octets historiques.
Les actions suivantes sont également possibles :

• Envoi d’un ATR => 2 octets => accès illégal en lecture ;
• Envoi d’un ATR => 33 octets => accès illégal en écriture.

Le matériel disponible pour la mise en place de l’attaque :

• Java Card : dont la couche transport est bas niveau (APDU étendue) ;
• Fun Card, prussian card, Basic Card : programmables mais via un lecteur de cartes à puce ;
• Émulateur physique de cartes à puce : problème de coût et de prise en main.

L’orateur a donc acheté un Arduino peu coûteux, rapidement pris en main, avec connexion USB, contrôle via Python et contrôle de la carte, ce qui lui a permis de réaliser des attaques par fuzzing.

Via un ATR mal formaté, il a pu trouver 4 failles avec possibilité de récupérer une partie de la réponse précédente.

Par attaque sur les octets de procédure T0, il a pu extraire le code du firmware du microcontrôleur. Il a également pu extraire la totalité de la XRAM, également grâce à une faille dans la bibliothèque du microcontrôleur qui est normalement sensée empêcher les débordements de tampon.

L’orateur conclut par une démo en live où il lit les dernières réponses et dump le firmware.

Attaques applicatives via périphériques USB modifies infection virale et fuites

Benoît Badrignans est employé chez SECLAB FR. C’est en travaillant sur le développement de périphériques USB et en constatant que le moindre problème de conception dans le périphérique entraînait un plantage de la machine que l’idée de modifier des périphériques USB lui est venue.

Dans le cadre de SI critique, les problématiques liées à l’USB sont fréquentes (cas de Stuxnet). Cela a permis une prise de conscience du risque et la mise en place de préconisations associées. Cependant, ces préconisations se concentrent sur la protection de périphériques USB classiques avec un contenu malveillant.

Les recommandations traditionnelles sont :

• Éviter l’USB ;
• Utiliser un sas de décontamination ;
• Désactiver l’autorun ;
• Utiliser un antivirus à jour ;
• Interdire certains périphériques via le descripteur,
• Etc.

La présentation débute par un rappel du modèle de fonctionnement de l’USB. Comme indiqué sur la capture ci-dessous, il existe plusieurs méthodes pour compromettre un système via un périphérique USB classique (virus sur une clé USB, driver malveillant, etc.)

Par exemple, modifier un périphérique USB en changeant le descripteur, permet d’autoriser un périphérique qui serait normalement interdit.

On peut aussi écouter les informations qui passent sur le hub USB sur lequel est branché notre périphérique modifié.

Il est également possible de contourner le sas de décontamination en modifiant la table de partition. Si on peut simuler un clavier, on peut donc se faire passer pour la personne derrière le clavier.

Pour réaliser son périphérique modifié, il y a plusieurs options :

- Acheter directement un contrôleur USB ;

- Modifier un téléphone portable (des couches d’Android permettent de faire passer un téléphone pour un clavier) ;

- Utiliser des outils de pentest prêts à l’emploi (Facedancer USB pour Fuzzing) ;

- Acheter directement une clé USB piégée.

La surface d’attaque s’avère donc supérieure à une clé USB classique !

La première démonstration se base sur le scénario ayant l’objectif suivant : voler un fichier spécifique sur un système. Le système hôte effectue un filtrage sur le descripteur USB, l’utilisateur courant n’est pas « root » et la clé USB est montée en lecture seule.

Premier contournement : on peut facilement changer le descripteur USB (besoin d’ingénierie sociale pour déterminer les descripteurs autorisés).

Notre clé dispose de deux espaces de stockage : un premier accessible depuis l’OS (donc uniquement en lecture, que l’on nommera système A) et un second caché sur la clé, qui n’est pas directement accessible (que l’on nommera système B). La clé dispose aussi d’un microcontrôleur qui lui permet d’agit sur la mémoire de masse cachée. Comme il n’est pas possible de copier directement le fichier sur le stockage A, celle-ci accède en lecture au fichier cible. Le dispositif USB lit octet par octet le contenu de la clé, à chaque octet lu, un accès en lecture est fait sur un fichier spécifique du système A. Le microcontrôleur interprète alors ces accès en lecture et écrit les octets lus (donc ceux du fichier cible) et les écrits dans un fichier présent sur le système B, donc caché.

Le second scénario est le suivant : infecter une machine cible, n’ayant pas d’antivirus. L’attaquant ne peut entrer directement sur le SI, ne connaît pas le système cible (Linux/Windows/Mac), l’autorun est désactivé et le SI dispose d’un sas de contamination.

Pour contourner le sas de décontamination, il suffit d’attendre un certains nombre de connexions (physiques) pour exécuter la charge virale.

Pour connaître l’OS, on analyse le comportement du système lorsque l’on branche le périphérique (est-ce que le système commence par lire ou écrire sur l’équipement ? où ? etc).

Une fois l’équipement branché, l’OS détecté, il suffit de déposer un logiciel malveillant en simulant des entrées clavier.

Quelles sont donc les contre-mesures ?

Pour commencer les recommandations habituelles sont à appliquer (DLP, désactiver l’autorun, etc).

Ensuite, plusieurs options existent, comme par exemple Qubes OS qui permet de déléguer à une VM de faible niveau l’USB (ou encore le réseau). Cependant, ce type de système nécessite de former les utilisateurs et impose certaines contraintes.

La proposition de l’orateur constitue une protection matérielle qui consiste à mettre un matériel de filtrage USB en rupture entre les périphériques et le contrôleur USB de la machine. Dans le cas de support amovible USB, le contenu de la clé est dupliqué sur l’équipement, la lecture des fichiers ne se fait donc plus sur le périphérique mais sur l’équipement de filtrage. Il est aussi possible de mettre en place des règles de filtrage au niveau du clavier (interdire des combinaisons de touches, détecter des saisies de touches trop rapides pour être effectuées par un humain).

En conclusion, la surface d’attaque fournie par l’USB est grande, même sans entrer dans les couches basses, et il est difficile de contrer cela au niveau logiciel. Par ailleurs, cela ne se limite pas à l’USB, on peut envisager la fuite d’information via PS/2 ou le câble audio.

Pour obtenir plus d’informations sur la présentation, l’article et les slides sont disponibles à cette adresse : https://www.sstic.org/2013/presentation/Attaques_applicatives_via_peripheriques_USB_modifies_infection_virale_et_fuites_d_informations/.

Red October

Par Nicolas Brulez

L’orateur commence par un petit rappel des différentes attaques récentes :
- 2009 : Opération Aurora ;
- 2010 : Stuxnet ;
- 2012 : Flame ;
- 2013 : Red October.

Le nom « Red October » a été choisi car l’attaque est potentiellement d’origine russe. Il s’agit d’une campagne de cyber-espionnage ayant eu lieu de mai 2007 à janvier 2013.

Les informations obtenues par le malware étaient réutilisées pour s’introduire dans d’autres systèmes. Une soixantaine de noms de domaine ont été achetés pour des modules Nokia, iPhone, Windows mobile, pour Cisco et disques amovibles, outre les postes de travail.

Le scénario de l’attaque est le suivant :
- Infection initiale ;
- Par mail (boite mail anonyme ou boite « pownée ») phishing avec document piégé (Word et Excel). Il n’y avait aucun 0day (CVE 2009-1329, à CVE 2012-0158). Les exploits utilisés ont été récupérés de Chine, en changeant le payload ;
- Le dropper extrait et exécute 3 fichiers sur la machine victime. Le fichier chiffré en RC4 et Zlib est une backdoor s’injectant en mémoire qui communique avec le C&C de manière chiffrée, après un test sur microsoft.com ;
- Des modules complémentaires sont déployés (password, persistent, mobile, exfiltration, disque amovible, etc.). Une fois la connexion faite, les modules sont chargés « hors ligne » (sur le disque) et « en ligne » (en mémoire) : 34 modules, 9 groupes et plus de 100 fichiers.

Les noms de domaine ont été enregistrés par les équipes de Kaspersky pour faire des statistiques puisque les pirates ne les ont pas renouvelés.
Avec leur serveur (KSN), ils ont pu voir que la Suisse, le Kazakhstan et la Grèce étaient les pays les plus ciblés.
La plupart des mails qui ont servi à l’enregistrement des noms de domaine sont en « .ru ». Les équipes de Kaspersky ont pu avoir accès à un serveur de proxy qui redirigeait les flux vers les serveurs réels (le port 40080 des serveurs de contrôle est ouvert).

L’originalité des modules pour mobiles : Nokia, IPhone et Windows Mobile
Le module utilise l’API du développeur, l’ID du téléphone, la version du firmware, les contacts, les journaux d’appels, le calendrier, etc.
Sur Windows mobile, le module va infecter le téléphone en plus de récupérer des informations. Une fois infecté, il se connecte par le C&C pour compléter l’infection et va modifier le téléphone pour lancer des applications non signées.

L’orateur conclut par le fait qu’aucune démo n’est disponible car « de toute façon, ça ne marche pas, je suis à l’arrache comme toujours ! ». Aucun support de présentation n’est disponible.

(L’)Embarqué entre Confiance et Défiance
Par Aurélien Francillon

La dernière conférence de la journée est présentée par Aurélien Francillon, chercheur chez Eurocom, rattaché à l’institut Mines-Télécom. La présentation est un patchwork de différentes recherches qu’il a effectuées sur l’informatique embarquée.

Pourquoi ce titre ?
Il commence par expliquer pourquoi il a choisi ce titre et pourquoi il s’est tourné vers l’embarqué.
Au départ, hormis les cartes à puce, étudier des attaques ciblées sur les systèmes embarqués était assez souvent tiré par les cheveux. Cet aspect a pas mal changé ces derniers temps. C’est aussi sa curiosité à l’égard de ces systèmes et le fait qu’ils sont plus petits, donc moins complexes, soumis à peu de sécurité qui l’ont poussé à se demander « Peut-on faire confiance à ces boites noires ? » et à s’orienter vers l’étude de l’embarqué.
Pour commencer, il illustre sa présentation en parlant d’AVR. Ce microcontrôleur est basé sur une architecture Harvard (http://fr.wikipedia.org/wiki/Architecture_Harvard), aussi utilisée dans les smartcard : les données mémoire et programme y sont indépendantes. Ce type d’architecture induit qu’il n’est pas possible d’effectuer des injections de code classiques. Cependant, en utilisant le ROP (Return Oriented Programming, http://fr.wikipedia.org/wiki/Return-oriented_programming), il est possible d’exécuter du code déjà présent en mémoire programme (des gadgets). Si l’on est en présence d’un jeu de gadgets « Turing complet », il est possible d’effectuer des injections. Un système basé sur une architecture Harvard ne protège donc pas des injections de code.

Comment faire confiance à un système embarqué ?
Pour répondre à cette question, l’orateur utilise l’exemple duHTC G1. Ce téléphone utilise deux processeurs : un ARM9 pour le baseband (le code du baseband représente environ 20 Mo de code binaire) et un ARM11 pour la gestion d’Android. L’orateur présente la séquence de Secure Boot du téléphone. Ce modèle de sécurité est basé sur une signature des différents binaires. C’est en analysant la ROM utilisée pour le baseband que l’on découvre que les certificats utilisés pour vérifier la signature sont en dur dans le code. On est en présence de deux certificats, un certificat « commercial » et un certificat « gouvernemental ». Chaque certificat correspond à un mode de fonctionnement. Les premières questions qui peuvent venir à l’esprit sont :
- Pour quel gouvernement ?
- Y-a-t-il un certificat par gouvernement ?
- Est-ce une backdoor ?

Les réponses aux deux premières questions ne sont pas données ici. Cependant, on peut affirmer qu’il ne s’agit pas réellement d’une backdoor car on a besoin d’un accès physique au téléphone. Par contre, un gouvernement peut quand même reprogrammer le baseband pour ses propres téléphones. Pour cela, il faut pouvoir modifier l’image (micronoyau OKL4). Des versions antérieures sont disponibles en open source. Il est également possible d’utiliser OKL4 comme hyperviseur (un PoC permettant de lancer le noyau Linux dans le baseband a d’ailleurs été effectué lors des recherches).

Après cet exemple, il nous est rappelé que les systèmes embarqués sont partout.
Un ordinateur est d’ailleurs une combinaison de systèmes embarqués. Par exemple, un disque dur en est un. Un papier à venir va présenter la possibilité de déposer une backdoor au sein d’un disque dur (le PoC est notamment réalisable car il n’y a pas de vérification de la signature du firmware dans le disque dur). À suivre donc !

Comment font-ils pour faire cela de manière sécurisée ?
Ici, les systèmes de clés sans contact pour les automobiles sont pris comme exemples. Dans le modèle vendu par les constructeurs, si on se trouve à proximité de notre voiture (moins de deux mètres) avec la clé, sans contact, la voiture se déverrouille et il est possible de la démarrer en appuyant sur un simple bouton. Aurélien a donc réalisé la même expérience sur plusieurs voitures (10 modèles de 8 constructeurs). L’expérience consiste à créer un relai (par câble ou sans fil) permettant de prolonger la portée de la clé. Le résultat est qu’il est possible d’ouvrir et démarrer la voiture à une centaine de mètres.

Peut-on faire confiance à ces systèmes ?
Plusieurs concepts permettent de contrôler ces systèmes : le premier présenté consiste à vérifier le code avec un autre code, contournable notamment grâce au ROP. La seconde méthode consiste à vérifier le système au démarrage, méthode ne protégeant pas contre une compromission après le lancement du système.
La dernière méthode est la méthode Secure and Minimal Architecture for (Establishing a Dynamic) Root of Trust (SMART), méthode présentée dans le document : http://www.eurecom.fr/fr/publication/3536/detail/smart-secure-and-minimal-architecture-for-establishing-a-dynamic-root-of-trust)

Pourquoi faire un système sécurisé ?
Pour terminer la présentation, on peut se poser la question : pourquoi sécuriser ces systèmes ? En effet, du coté constructeur la question peut se poser. Cela coûte plus cher, c’est plus complexe à réaliser et cela ne fait pas nécessairement vendre davantage ou plus vite.

En conclusion de ce patchwork, l’orateur tient à rappeler qu’il est important de rester curieux et de se poser des questions lorsque l’on se retrouve face à des boîtes noires.

Au moment où ces lignes sont écrites, la présentation n’est pas disponible sur Internet. Elle le sera sûrement par la suite à l’adresse : https://www.sstic.org/2013/presentation/conf_invit2_j1_2013/