Conférence francophone sur le thème de la sécurité de
l'information.
Elle a eu lieu
à Rennes du 1 au 3 juin 2016.
Conférence d'ouverture
Présentation disponible sur le site de l'auteur / Slides are available on the author's website.
L’analyse de codes malveillants dans un cadre opérationnel pose de nombreuses problématiques. Il est ainsi nécessaire de combiner les différents problèmes propres à la rétro-ingénierie, tels que la comparaison de binaires, la possibilité d’automatiser au maximum les tâches, d’identifier les points d’intérêts au sein du code, mais également des contraintes plus génériques telles que le partage d’informations, la communication et le travail efficace en équipe.
Nous proposons une approche opérationnelle de ces besoins, en répondant séparément à chaque partie du problème.
Par la suite, nous détaillons une méthode basée sur le graphe de flot de contrôle pour effectuer des comparaisons de code, aussi bien sur un binaire complet que sur un sous-ensemble de fonctions.
Nous présentons également une plateforme répondant à ces problématiques en permettant de stocker et d’organiser un corpus d’échantillons avec les métadonnées associées. Enfin, cette plateforme facilite la rétro- ingénierie collaborative en partageant les informations produites par l’analyse automatique et par les autres intervenants de l’analyse.
Gunpack : un outil générique d'unpacking de malwares
Abstract
Product vendors sometimes develop their own cryptographic algorithms to either protect their intellectual property or ensure information confidentiality (data or communications). Many of these algorithms have been proven to contain critical weaknesses which defeat their purpose, weaken security and might expose customer data or systems.
Most research on home-made algorithms is usually done through reverse engineering of the hardware or software parts implementing these cryptographic primitives. This article tackles a different approach on an unknown and simple algorithm.
During the study of an embedded system firmware, the author was not allowed to tamper with the targeted product. With hardware-based attacks or research out of the equation, this article proposes a first-hand account on how black-box cryptanalysis was performed on a custom algorithm in order to retrieve a 40 MB firmware from an 18 MB compressed and encrypted image.
The author discloses approaches, methods, ideas and tools developed throughout the part-time 6-weeks process, and discusses explored ideas and attacks which proved to be either successful or dead-ends.
Résumé
Les constructeurs de produits développent parfois leurs propres algorithmes cryptographiques pour protéger soit leur propriété intellectuelle, soit la confidentialité de certaines informations (données stockées ou communications). Nombre de ces algorithmes présentent des faiblesses les rendant inutiles, abaissant la sécurité et mettant potentiellement en danger les données et systèmes de leurs utilisateurs.
La plupart de la recherche effectuée sur des algorithmes propriétaires se base sur la rétro-ingénierie des composants matériel ou logiciel implémentant leurs primitives cryptographiques. Cet article prend une approche différente sur un algorithme simple et inconnu.
Lors de l'étude du micrologiciel d'un système embarqué, l'auteur n'était pas autorisé à ouvrir ou modifier matériellement le produit. Les attaques matérielles étant donc exclues, cet article relate la manière dont a été effectuée la cryptanalyse, en boite noire complète, dans le but de récupérer le firmware de 40 Mo uniquement à partir d'une image compressée et chiffrée de 18 Mo.
L'auteur détaille l'approche, les méthodes, les idées et les outils développés pendant les 6 semaines du processus. Les idées et attaques mises en œuvre sont toutes présentées, y compris les tentatives infructueuses.
Cette présentation propose un retour d’expérience sur le développement d’une carte électronique mettant en œuvre une chaîne de démarrage sécurisé intégrant un mécanisme d’authentification pré-boot. Ce mécanisme original repose sur une solution utilisant un composant sécurisé certifié EAL5+ comme racine de confiance sur la carte mais également en tant qu’élément d’authentification extractible. Nous présenterons les problématiques associées à l’intégration de composants sur étagère dans une plateforme visant des objectifs de sécurité. Outre l’architecture matérielle de la carte, l’ensemble des développements logiciels réalisés - pour le System on Chip (SoC) applicatif animant la plateforme et pour les composants sécurisés - sont détaillés.
La sécurité des systèmes embarqués dans les véhicules est, depuis quelques années, un thème de plus en plus abordé lors des conférences en sécurité informatique « généralistes »; les constructeurs souhaitant ajouter de plus en plus de fonctionnalités : multimédia natif ou déport des smartphones des utilisateurs, mais aussi « platooning », « cloud car sharing » et autres automatisations du véhicule.
Nous avons donc souhaité revenir sur les différents travaux effectués pour plusieurs constructeurs au cours des dernières années, en s’appuyant sur l’étude des systèmes multimédias, et sur les problématiques de sécurité constatées.
USBiquitous se décompose en plusieurs parties: - Deux modules noyau permettant de gérer et simuler des périphériques USB - D'un ensemble de programmes userland permettant de faire le lien entre les deux modules.
Ces programmes peuvent être développés facilement par l'intermédiaire d'une API pour: - Fuzzer, scanner, bloquer, rejouer ou rechercher des vulnérabilités.
Depuis le début du premier semestre 2016, six CVE permettant l'exécution de code arbitraire ont été déposées. Ces CVE ont toutes en commun l'exploitation d'une vulnérabilité encore peu considérée la confusion de type. Elle peut, pourtant, à elle seule outrepasser les sécurités actuelles et mener à l'exploitation. Cette vulnérabilité correspond à la manipulation d'objets C++ d'une façon incompatible avec leur type réel. Son origine réside dans la mauvaise utilisation des opérateurs de conversions. Or, ces opérations sont courantes dans les logiciels où la programmation orientée objet et le polymorphisme ont une place importante. Cet article présente plus en détail l'origine de cette vulnérabilité et les mécanismes bas niveaux à l'origine de son exploitabilité.
De nos jours, simplifier la création de composants logiciels formellement vérifiés est souhaitable dans de nombreux domaines. Il s’agit d’un sujet particulièrement crucial pour les composants logiciels critiques ou sensibles. Dans cet article, nous illustrons de récentes avancées dans ce domaine grâce à l’utilisation d’un langage de programmation fonctionnelle moderne dédié à la vérification : F*. Actuellement l’objet d’un développement actif, ce langage succède à d’importants travaux ayant notamment permis la publication de la première implémentation formellement vérifiée de TLS. Nous illustrons une partie des possibilités offertes par le langage au travers de l’implémentation prouvée correcte et sûre d’une primitive de code d’authentification de messages : Poly1305, dont la version présente dans OpenSSL a été l’objet de plusieurs bugs depuis mars 2016.
This article presents the feedback and results of a distributed crawler solution based on credit card–sized single-board computers, hosted by friends with an aim at collecting and monitoring Cyber Int information.
Frozen Synapse est un jeu de stratégie sorti en 2011. Cette présentation courte retrace les recherches que j'ai effectuées pour lever le brouillard de guerre présent dans certains modes de jeu, et ainsi m'octroyer un avantage tactique significatif en ligne.
Qu’il s’agisse de recruter ou de sélectionner des candidats pour une formation, nous avons été amenés à mettre au points des questionnaires permettant non pas tant de vérifier des connaissances que d’évaluer une aptitude à appréhender la SSI. Nous revenons sur certaines de ces questions, parfois très éloignées du coeur du sujet, et leur justification
Usage of Second-Factor Authentication (2FA) solutions constitutes a valid answer to the threat against weak credentials, such as passwords. Yet many 2FA schemes are vulnerable to prominent web threats such as phishing attacks.
The Universal Second Factor (U2F) protocol, specified by the FIDO Alliance, offers phishing-resistant 2FA solution, optionally based on hardware secure elements. Some well-known websites already use this authentication scheme, including Google, Dropbox and Github. Unfortunately, the U2F protocol still lacks independent reviews.
This study is a first attempt at assessing the actual security brought by the U2F authentication scheme. It confirms that, protocol-wise, most of U2F security goals are achieved. Yet, we found that some of the specified security measures benefit only from an experimental implementation and that some recommendations from the U2F specifications are not yet followed.
This presentation draws a picture of the security brought by U2F and ultimately compares the protocol with some 2FA schemes: Short Message System (SMS) codes, Time-based One-Time Password (TOTP) and TLS client authentication using certificates.
The LTE standard defines a strong security model and architecture for protecting 4G mobile communications. However, it is yet very unclear how the various modems available on the market are implementing and enforcing the LTE security procedures.
In this paper, we first introduce the basics of LTE security. Then, we show multiple LTE security bypasses that we found in the different 4G modem implementations we tested. We also describe two issues we found in WCDMA stacks from our previous research. Finally, we dive into a few 4G modem implementations to see how they are interworking with the Android OS, and how one can try to get information out of them. To conclude, we propose improvements, on the terminal side but also on the network side, in order to increase the effective security level of 4G communications.
Slides are available in PDF here. The link on the right also contains PCAPs.
L’AIS (Automatic Identification System) est un système de balises de localisation pour bateaux particulièrement vulnérable à l’injection de fausses données. Chargé notamment de transmettre identité et position des navires entre eux, les conséquences matérielles et humaines d’une telle attaque peuvent être considérables. Avec l’avènement des outils de radio logicielle, la menace grandit et il y a un réel besoin d’outils en mesure de détecter ces malversations. Cet article cherche à déterminer s’il est possible de détecter ces attaques en analysant le signal AIS reçu.
Le protocole HTTP2 est une réalité !
Il est supporté par les principaux navigateurs et d'ors et déjà proposé par les serveurs de plusieurs grands acteurs du web (google, twitter, cloudflare, youtube, instagram, yahoo, ...). Les retours d'expérience formulés par ces acteurs peuvent raisonnablement nous amener à parier d'une adoption progressive mais rapide du HTTP2. Pour percevoir l'impact qu'aura ce protocole sur ses travaux et ses outils, un lecteur avisé pourra se rapporter aux spécifications officielles [0].
D'un point de vue serveur, les principaux acteurs du marché proposent une pile HTTP2 (nginx, apache, jetty, h2o, ...). Ces piles sont-elles conformes aux spécifications, sont-elles identiques et sont-elles robustes ? Que feriez-vous si à l'une de ces questions la réponse était non ?
Conférence invitée
De nombreux mécanismes de protection d’applications ont pour but la prévention d’exécution de code arbitraire, visant majoritairement à protéger les applications d’elles-mêmes, de leurs vulnérabilités potentielles. Mais existe-t-il pour autant des mécanismes permettant de protéger des applications de leur propre environnement ? En particulier du noyau du système d’exploitation, pièce maîtresse permettant leur exécution. Est-il possible de garantir la confidentialité du code d’une application vis-à-vis d’un noyau malveillant ? Nous avons tenté de répondre à cette question en proposant une protection reposant sur Ramooflax, solution de virtualisation légère et libre présentée à l’occasion du SSTIC 2011.
Lorsqu'un analyste souhaite réaliser l’étude du comportement d’un système sous Windows, peu de choix s’offrent à lui. Il doit passer le système en mode /DEBUG et se connecter avec le débogueur de Microsoft (WinDbg) au serveur KD qui se situe dans le noyau du système à analyser.
L'inconvénient majeur de cette solution est que le comportement du système se retrouve alors modifié par l’environnement de débogage.
Au cours de cette présentation, nous détaillons notre approche d’introspection et de débogage furtif de machine virtuelle et nous discutons de l’architecture et de l’implémentation de Winbagility.
Winbagility est une réalisation de débogueur furtif fondé sur un hyperviseur VirtualBox modifié, permettant d’utiliser la majeure partie des fonctionnalités de WinDbg sans passer le système en mode /DEBUG.
La présentation s'intéressera à l'attaque des interfaces de déverrouillage d'un terminal Android (code Pin, mot de passe, schéma de verrouillage) via la simulation d'un clavier souris en utilisant le port USB On The Go (OTG) du téléphone.
Que ce soit lors d'un pentest, d'un challenge inforensique ou CTF, vous avez souvent besoin d’enchaîner différents outils pour attendre votre but. Parfois, ces outils manquent de fonctions indispensables et vous devez scripter rapidement. The Metabrik Platform vous permettra d'atteindre vos objectifs de manière simple et rapide en utilisant un shell augmenté d'un vrai language de développement.
Bien que l’usage de diodes soit répandu sur des systèmes critiques, leur coût très élevé, se chiffrant souvent en dizaine de milliers d’euros, les rend difficilement accessibles à de nombreuses organisations.
Au cours de missions d’audits et de conseil nous avons pu constater de multiples situations, en particulier dans le cas de SI industriels, où les besoins de disponibilité de temps réel et de performances sont limités. Dans ces cas, une solution réalisée en interne pour 200 € permettrait de renforcer fortement le niveau de sécurité.
La mise en place d’une telle solution étant largement documentée, le projet DYODE se focalise sur trois aspects : un support natif de modbus pour l’application au sein de réseaux industriel, la prise en compte d’améliorations diverses indispensables pour un usage terrain et une mise en place aisée pour un administrateur système peu expérimenté ; le tout bien sûr sous licence GPLv3 et basée sur du matériel abordable pour n’importe quelle entreprise.
Présentation du challenge et de sa solution par le gagnant du classement qualité.
Liste des rumps (avec liens vers les vidéos) :
- Trump (Benjamin Morin)
- Pourquoi c'est flou ? (Pierre Capillon)
- Evolution de Fuddly depuis SSTIC 2015 (Eric Lacombe)
- NFB (Fabien Périgaux)
- RAM & Disk EFI Dumper (Solal Jacob)
- Etude d'un disque lolifiant (Julien Lenoir - Raphaël Rigo)
- De la difficulté d'implémenter des communications sécurisées (Guillaume Teisser)
- r2m2 (Guillaume Valadon)
- Comment ne plus avoir de pubs ? (x0rz)
- Fighting malware like a boss (Pierre Chifflier - Fabien Pichot)
- Amsterdam (Eric Leblond)
- AJPy (Julien Legras)
- Winning crap with Twitter's API (tlk)
- IDMEF et IODEF (Thomas Andrejak)
- Un doigté en 3D (Lucas Barthelemy - Léo Rannou)
- Objets connectés (Angelin Njakasoa - BOOZ)
- libECC (Arnaud Ebalard)
- Manalyze (Ivan Kwiatowski)
- Analyse d'un Exploit Kit Angler (Kevin Denis)
- Just do it the hard way (Dark)
- You are not alone (Aska)
- IVRE more (Florent Monjalet)
- Univershell - Attaque contre Android Face Unlock (Antoine Cervoise)
- die hard (Philippe Trébuchet)
- Dynamically detecting smart XSS with evolutionary fuzzing methods and machine learning involving cyber algorithms - Quelques échecs de GreHack (_Frky)
Principes et limitations de la fonction System Integrity Protection (SIP) dans Mac OS X 11.5.
The security of Java Card products is mainly based on the Byte Code Verifier (BCV) which is a mandatory step before loading any applet on an embedded Java Card Virtual Machine (JCVM). The BCV is therefore in charge of detecting some malicious code, preventing from software attacks. However the BCV is not sufficient against software attacks based on flaws in the JCVM implementation itself and against combined attacks. This paper presents software attacks with verified applets exploiting flaws in JCVM implementations and new techniques for combined attacks.
The Byte Code Verifier (BCV) is one of the most important security element in the Java Card environment. Indeed, embedded applets must be verified prior installation to prevent ill-formed applet loading. At the CARDIS 2015 conference, we disclosed a flaw in the Oracle BCV which affects the applet linking process and can be exploited on real world Java Card smart cards. In this article, we present how this vulnerability had been found and our exploitation of this flaw on a Java Card implementation that enables injecting and executing arbitrary native malicious code in the communication buffer from a verified applet. This attack was evaluated on several Java Card implementations with black box approach. In this case, as we cannot evaluate the effect of the control flow redirection caused by the attack, we develop a generic function which can be executed from any point.
Grsecurity est un patch de durcissement Linux bien connu (au moins dans la communauté sécurité / Linux). Il inclut entre autres le patch PaX (dont l'auteur, The PaX Team, a fait la conférence d'ouverture du SSTIC 2012), qui a introduit certaines techniques de durcissement système telles que la randomisation de l'espace mémoire (ASLR), intégrées plus tard dans la plupart des OS. Le patch grsecurity est toujours externe (il ne fait pas partie du noyau Linux), la plupart des fonctionnalités et du durcissement qu'il apporte ne bénéficient donc pas aux utilisateurs finaux qui, pour la plupart, utilisent les noyaux binaires de leur distribution.
Même si des efforts récents cherchent à améliorer la situation du noyau Linux, c'est toujours le patch grsecurity qui représente l'état de l'art de la sécurité kernel dans le monde Linux, et simplifier son adoption est une étape importante pour en améliorer la sécurité globale.
Après avoir rapidement introduit les fonctionnalités du patch grsecurity, cette présentation montrera divers efforts entrepris pour simplifier l'utilisation de celui-ci, en particulier à destination des administrateurs système.
Bien que toutes les tentatives académiques actuelles pour créer des primitives cryptographiques standard en white-box aient été cassées, il y a encore un grand nombre d'entreprises qui vendent des solutions "sécurisées" de cryptographie white-box. Afin d'évaluer le niveau de sécurité de solutions en boîte blanche, nous présentons une nouvelle approche qui ne nécessite ni connaissance des tables internes ni effort de rétro-ingénierie. Cette attaque par analyse différentielle de calcul (differential computation analysis - DCA) est la contrepartie logicielle de l'attaque différentielle de la consommation (DPA) bien connue de la communauté de cryptographie matérielle. Nous avons développé des greffons pour des outils populaires d'instrumentation binaire dynamique afin de produire des traces d'exécution qui enregistrent les adresses mémoire et les données qui sont utilisées. Pour illustrer l'efficacité de cette attaque, nous montrons comment la DCA parvient à extraire les clés secrètes de toutes les implémentations (non commerciales) publiquement disponibles d'algorithmes de chiffrement standards en white-box en analysant ces traces afin d'identifier les éventuelles corrélations. Cette approche permet d'extraire la clé d'une white-box nettement plus rapidement et sans connaissance spécifique des détails de sa conception, et celà de manière automatisée: réduisant largement la connaissance et l'effort requis par rapport aux techniques mathématiques de cryptanalyse utilisées dans les attaques précédentes. En conclusion, cela donne une fois de plus raison à Auguste Kerckhoffs : rien ne sert de cacher les détails du design d'une implémentation white-box dans l'espoir de tenir les attaquants à distance.
Avec Windows XP, Microsoft a fait évoluer Dr. Watson vers un mécanisme plus sophistiqué baptisé WER (Windows Error Reporting). WER est généralement automatiquement sollicité par Windows lorsqu'une erreur se produit dans une application ou dans le système. Dès lors, un rapport d’incident est généré et celui-ci peut, éventuellement, être transmis à Microsoft afin de résoudre un bug ou dysfonctionnement.
Cette présentation se propose de décrire le fonctionnement de WER, sa configuration, la génération et le contenu des rapports ainsi que le protocole de remontée à Microsoft. Il sera également décrit la méthodologie de mise en place d’un serveur WER d’entreprise permettant de récupérer, en lieu et place de Microsoft, tous les rapports WER émis au sein d’un parc de système Windows.
Afin d’illustrer les problèmes de configuration des mécanismes matériels d’isolation, nous proposons une attaque d’IOMMU. L’attaque mise en œuvre dans cet article met en avant une erreur de conception au sein du firmware et du driver d’IOMMU Intel pour linux. L’exploitation de cette vulnérabilité est réalisée uniquement à l’aide d’un périphérique PCI Express développé sur FPGA, des spécifications matérielles Intel et de la lecture du code source de Linux.
A l'occasion de la sortie de Scapy 2.3.2, désormais sur github, https://github.com/secdev/scapy/ cette présentation courte effectue un panorama rapide de cet outil de manipulations de paquets réseau. Elle vise à faciliter la prise en main à travers des exemples simples.
Un notebook accompagne cette présentation: https://git.io/vrxMk
Plaso aims to be the open source Swiss army knife of forensics timelining, while timesketch brings visualization, collaboration and cross-systems analysis capabilities to the busy forensics analyst.
This talk will sketch a big picture of the inner workings of the tools, as well as a summary of the features.
L’analyse manuelle de binaire est relativement longue, pénible et fastidieuse (ce n’est pas un métier facile). Elle lève souvent les mêmes questions : Combien d’arguments à cette fonction ? Quels sont leurs types ? D’où proviennent ils ? Qu’est qu’on mange à la cantine à midi ? Certaines de ces questions sont des problèmes très complexes qui dépendent d’une multitude de petits sous-problèmes. Cet article propose une tentative de réponse à une question simple précédemment posée : D’où provient la valeur d’une variable ?
Conférence de clôture