Symposium sur la sécurité des technologies de l'information et des communications

Précisé ultérieurement.

La présentation s'articulera autour de 4 points :

- théorie sur l'exécution symbolique, hypothèses choisies, etc.

- présentation de l'outil développé permettant l'émulation et l'exécution symbolique (mélange de IDA python et de Z3)

- explication de la réunion des deux pour la reconstruction du CFG original de la fonction protégée.

- présentation des différentes améliorations possible et des limitations de la méthode tant du point de vue de l'outil créé que de l'obfuscation.

De l'exploitation à l'infection, les malwares modernes utilisent de nombreux formats de fichier binaires. Il est crucial de pouvoir correctement les identifier et les analyser, si possible de manière automatique. À priori clairement différenciés, il est malheureusement possible de combiner certains d'entre eux dans un seul et même fichier. De tels binaires polyglottes ont donc dans un premier temps été créés. Ensuite, plusieurs caractéristiques non documentées de chaque format concerné ont été rajouté, pour mettre en évidence l'importance du problème entre les limites des documentations officielles, et la réalité (du monde des virus). Les conséquences sur le fonctionnement des outils de sécurités sont finalement mises en évidence, avec ce que ça implique pour l'utilisateur final.

From exploitation to infection, modern malware rely on many binary file formats. It's critical to be able to identify them reliably, and analyze them in an automated way. While most of them are trivial to tell apart, it's sadly possible to combine some of them in a single file. As an experiment, such binary polyglots were written. Then, various undocumented yet supported characteristics were added to each file format, to highlight the difficulty to tell between a corrupted and a working file, between the limits of official documentations and the reality of the malware landscape. Finally, consequences for security software are presented, and the implications for the end-user.

Les Malware sont de plus en plus difficiles à analyser, par utilisation des outils conventionnels d'analyse statique et dynamique, dans la mesure où ils s'appuient sur des outils spécialisés du marché pour protéger leur code. Nous présentons dans ce papier un outil adapté à l'analyse de programmes binaires protégés et potentiellement hostiles. Cet outil met en oeuvre un émulateur et plusieurs fonctions d'analyse spécialisées pour observer le programme cible et son environnement d'exécution, puis extraire et simplifier sa représentation.

Iptables et Netfilter sont apparus en 2001 en même temps que Linux 2.4 dont ils constituent la couche pare-feu. Leurs fonctionnalité et leur codes ont connu des évolutions lors de cette décennie mais elles n'ont pas révolutionné l'expérience utilisateur. Ce ne sera sans doute pas le cas avec Nftables qui devrait sans doute succéder au vénérable utilitaire iptables. Cette présentation décrit les problèmes et les limites d'iptables et montre quels sont les solutions proposées dans nftables.

Dans le cadre de ses activités d'expertise, le laboratoire sécurité des réseaux et protocoles (LRP) de l'ANSSI est amené à étudier divers protocoles de communication. L'étude fine de ces protocoles passe par l'utilisation de parsers, ou dissecteurs, de confiance permettant d'analyser les messages échangés lors d'une exécution du protocole.

L'expérience a montré qu'il était nécessaire de disposer d'implémentations indépendantes et robustes pour étudier et comprendre les comportements d'un protocole donné, en particulier pour détecter et caractériser les anomalies. En effet, pour un protocole donné, les implémentations disponibles de clients, serveurs ou dissecteurs sont parfois limitées (refus de certaines options), laxistes (acceptation silencieuse de paramètres erronés) ou fragiles (terminaison brutale du programme pour des valeurs inattendues, qu'elles soient licites ou non).

Ce constat a conduit au développement d'outils, l'objectif étant de développer rapidement des dissecteurs robustes et efficaces. Pour cela, plusieurs langages de programmation ont été successivement utilisés (C, C++, python, OCaml). Le dernier d'entre eux s'appelle Parsifal, et montre les bonnes propriétés suivantes : code succinct, programmes compilés efficaces et robustes, possibilité de décrire des formats de manière incrémentale.

Le code source de Parsifal est disponible sur GitHub (https://github.com/ANSSI-FR/parsifal).

De nombreuses applications sur PC utilisent une carte à puce pour renforcer leur sécurité, par exemple dans le domaine de la signature numérique. C'est un excellent coffre-fort numérique à faible coût, mais dont la sécurité repose très souvent sur l'envoi d'un code fixe en clair : le code PIN. Il est donc impératif de le saisir dans un environnement sécurisé, et parfois hasardeux de le faire sur un PC.

De petits terminaux à connexion USB disposant d'un écran et d'un clavier proposent une solution en cloisonnant la manipulation du PIN en leur sein. Cet article s'intéresse aux attaques sur ces terminaux via l'interface carte à puce. Leur fonctionnement nécessite des attaques au niveau du protocole de communication bas niveau. Cela a nécessité la création de notre propre émulateur de carte à puce. De plus, leur architecture rudimentaire diminue les moyens d'exploitations de failles éventuelles.

Malgré ces limitations, la découverte de plusieurs failles associées à des exploitations concrètes démontre la pertinence de cette approche.

Les infrastructures critiques font face à des menaces de malwares et de fuites d'informations, y compris lorsqu’elles sont isolées d’Internet. Les attaques récentes ciblant les systèmes industriels, comme Stuxnet ou Duqu, utilisent l’USB pour contourner cette isolation et atteindre leur cible. Si de bonnes pratiques lors de la configuration des systèmes d'exploitation peuvent éviter certaines attaques véhiculées par des périphériques USB standard, cet article montre que l'usage de périphériques USB dont le logiciel embarqué a été modifié par un attaquant permet de contourner la plupart des protections connues. Les attaques USB peuvent intervenir à plusieurs niveaux (matériel, driver de l'OS, pile USB de l'OS, protocole USB comme HID ou Mass Storage, au niveau applicatif). Cet article se concentre sur les attaques au niveau applicatif, ce qui rend l'implémentation relativement simple et leur détection complexe car difficile à distinguer des actions d'un utilisateur légitime. L'article détaille les protections recommandées aujourd'hui, met en évidence leurs limites vis à vis des dernières attaques publiées, propose deux nouvelles attaques permettant d'écrire sur des clefs ou des disques dur USB même si ceux-ci sont montés en lecture seule par le système d'exploitation, et montre comment contourner certaines protections basées sur des antivirus.

Critical infrastructures face malwares and data leakage threat, even when disconnected from Internet. Latest attacks against industrial systems, such as Stuxnet and Duqu, use USB bus to get around this isolation and reach their target. Good practices in systems configuration may avoid some of these threats, but this article shows that they are mainly useless against specially designed USB peripheral firmwares (malicious USB drives). Attacks may occur at different levels (hardware, drivers, USB stack, protocols like HID or Mass Storage, applicative). This article mainly focus on applicative attacks because it facilitates implementation and makes it difficult to detect since quite similar to user legitimate behaviour. This article first describes current recommended precaution, then shows their limits next to recently published attacks, it proposes also two attacks allowing to write on a USB drive even if host operating system mount it read-only, and shows how to get around some antivirus based protections, finally some counter measures are discussed.

A venir.

A venir.

L'UEFI (Unified Extensible Firmware Interface) est issu d'un effort commun de la part de plusieurs constructeurs et acteurs de l'industrie, à l'initiative d'Intel. Il s'agit d'un nouveau composant logiciel s'interposant entre le matériel et le système d'exploitation et qui vise à remplacer le bon vieux BIOS. Le principal objectif lié à son déploiement est la modernisation du processus de boot tout en facilitant le développement d'outils s'exécutant avant le système d'exploitation.

Du point de vue l'attaquant, disposant au minimum des privilèges de l'administrateur, il peut être intéressant d'analyser les différents services proposés par le firmware afin de mettre en avant les nouvelles possibilités de corrompre un système donné par un bootkit.

Cette présentation propose d'étudier l'architecture globale de UEFI d'un point de vue sécurité et de faire un focus sur une implémentation concrète d'un bootkit pour Windows 8 x64: Dreamboot. L'implémentation choisie comporte deux charges spécifiques: une élévation de privilèges et un contournement de l'authentification locale Windows.

UEFI est une initiative qui vise à remplacer les BIOS traditionnels des architectures PC par un code logiciel disposant de nouvelles fonctionnalités, et pouvant être utilisé sur d'autres architectures.

Dans cet article, nous étudions dans quelle mesure les changements apportés par UEFI peuvent modifier les moyens disponibles pour un attaquant cherchant à élever ses privilèges. Nous montrons comment un attaquant peut adapter des mécanismes utilisés pour modifier une extension PCI avec un BIOS, et les adapter pour UEFI.

Ces fonctions seront illustrées par la création d'une extension PCI pour une carte vidéo permettant de contourner les protections d'un noyau Linux d'une distribution Debian et de permettre à un processus utilisateur d'élever ses privilèges.

Nous discutons ensuite les mécanismes existants pour se protéger contre ces attaques, et leurs limites.

Alors que la majorité des vulnérabilités critiques des noyaux trouvent leur origine dans des débordements en mémoire ou l'usage incorrect de pointeurs, l'utilisation de langages sûrs pour l'implémentation de noyaux n'a été que rarement étudiée. L'article montre la faisabilité du développement d'un noyau en Ada et met en évidence la façon dont ce noyau est protégé des vulnérabilités les plus courantes.

A venir.

Les environnements VOIP Cisco sont largement déployés. Dans cet présentation, nous démontrons comment il est possible de prendre le contrôle d'un environnement VOIP en ciblant le Call Manager.

Nous discutons des avantages de contrôler un Call Manager. Il est un composant central d'un réseau VOIP. En prendre le contrôle permet d'effectuer plusieurs attaques. Tout le trafic SSCP est envoyé à ce composant, de ce fait, une fois contrôlé il est possible de modifier ces paquets afin de mettre en écoute un réseau VOIP entier.

Nous présentons la méthodologie utilisée pour réaliser cet audit, et montrons en détail comment comment six vulnérabilités différentes peuvent être combinées et exploitées pour obtenir le contrôle complet d'un Call Manager.

Cette présentation expose une surface d'attaque intéressante sur les smartphones android: l'intérêt est porté sur l'élévation de privilèges en exploitant des vulnérabilités dans le noyau. A l'aide d'une faille de ce type, un attaquant peut obtenir le contrôle total du téléphone. Les 0days kernel android sont donc précieux du point de vue offensif. e.comet@lexfo.fr

L'Observatoire de la résilience de l'Internet français, placé sous l'égide de l'ANSSI, est une initiative, regroupant ANSSI, AFNIC et différents acteurs de l'Internet, qui vise à étudier la robustesse de l'Internet via des indicateurs techniques. Les premiers résultats de l'Observatoire ont été publiés en juin 2012, et présentés lors de différents événements, dont le FRnOG. Forts des retours très positifs, l'équipe de l'Observatoire prépare un nouveau rapport qui sera publié en juin 2013.

L'objectif de cette présentation courte est de décrire les résultats de l'Observatoire concernant les protocoles BGP et DNS. Les analyses détaillées des résultats de chacun des indicateurs montrent que la situation de l'Internet français est acceptable, mais rien ne garantit que cela suffise à l'avenir. Concernant BGP, l'Observatoire recommande notamment aux opérateurs de déclarer des objets route correspondants aux préfixes annoncés. Concernant DNS, la recommandation principale porte sur une meilleure dispersion topologique des serveurs faisant autorité.

Android est actuellement le système mobile le plus répandu. Sa sécurité est souvent remise en cause par la présence de malwares, installés principalement depuis des markets alternatifs. Un utilisateur soucieux de sa sécurité et/ou ayant eu un minimum de sensibilisation à la sécurité n'installera pas d'applications provenant de sources non sures et demandant des permissions a priori inutiles à son fonctionnement (envoi de SMS, accès aux emails, etc.). Est-il en sécurité pour autant ?

De nos jours, les smartphones de grands constructeurs (Samsung, HTC, Sony, etc.) sont fournis avec une surcouche développée par le constructeur lui-même et offrant une multitude de services, parfois jamais utilisés par un utilisateur lambda. Or, les applications fournissant ces services, dites OEM, ne peuvent être supprimées que par un utilisateur disposant des droits root sur son smartphone. De plus, la suppression de certaines applications OEM peut entraîner une instabilité, voire un dysfonctionnement du smartphone.

La présence de vulnérabilités dans ces applications OEM expose alors les utilisateurs à des attaques ciblées via des backdoors ne nécessitant aucune ou très peu de permissions car réutilisant celles des applications vulnérables.

Les tables Rainbow sont un moyen efficace pour casser des hashs de mot de passe non salés. La taille des ensembles de mots de passe pouvant être cassés est limitée par l'effort nécessaire pour créer les tables. L'utilisation de cartes graphiques a permis de repousser un peu cette limite. On trouve ainsi des tables d'une taille de l'ordre de quelques tera octets qui cassent des mots de passe complexes de 8 caractères (10^16). C'est là qu'apparaît la prochaine limitation: d'aussi grosses tables ne peuvent pas être stockées en RAM et difficilement en SSD ce qui rend les temps d'accès très lents et réduit considérablement leur efficacité.

Pour pouvoir passer la limite des 8 caractères, nous avons appliqué deux méthodes probabilistes. La première consiste à représenter les mots de passe par des patterns. Pour les suites de caractères qui apparaissent dans ces patterns, nous utilisons ensuite un modèle de Markov du deuxième ordre pour ne garder que les suites les plus probables. Finalement nous avons optimisé l'implémentation de ce modèle pour l'adapter aux spécificités des GPU.

Nous nous sommes basés sur des bases de données publiques (RockYou, ...) pour choisir les patterns et des pondérations de Markov les plus efficaces et avons créé deux jeux de tables: un de taille limitée pour un liveCD Ophcrack et un second de 60 gigaoctets dont les parties les plus importantes peuvent tenir en RAM lors du cassage des mots de passe.

1. Trucs en stock sur SSTIC
2. Sécurité du protocole MGCP
3. Quel est l'OS de Kim Jong-Hu? Conclusions hâtives et mauvaise foi
4. Complétez la phrase : la sécurité est un …
5. Une autre perspective aux darknets
6. Vulnérabilité Windows 8
7. Cloud ISO 14001 (Low power ARM-based grsec-enabled server)
8. Suricata WTF
9. PUBS
10. Raspberry spy, machine d'interception de paquets à moins de 50$
11. Me@Your.home : how I succeed in your robbery 2.0
12. Yara & IOC mon cœur balance
13. TNS bit flip attack – gangman style in the cloud
14. Démo pépin
15. Stack overflows vs stack based overflow
16. BTA
17. PandOCR, un OCR minimaliste écrit en python
18. Hack my CCTP
19. RW2 : Des photos... sans photorec
20. Photorec
21. Podium offensive

Nous présentons une approche de smart fuzzing (frelatage intelligent) en boîte noire afin de détecter des vulnérabilités de type cross-site scripting (XSS) dans des applications web. L’intelligence est fournie par deux composants principaux : l’inférence de modèle et la génération automatique d’entrées malicieuses. Le premier est un “crawler” conscient du macro-état qui modèle l’application par une machine à états finis étendue, capturant la relation entre les paramètres d’entrée et les sorties (pages HTML). Le second, appelé fuzzing évolutionaire, est implémenté par algorithme génétique (AG). Afin de limiter le domaine de recherche de l’AG, nous introduisons un facteur additionnel, la grammaire d’entrées d’attaques afin de générer des entrées sous forme de chaînes de caractères qui sont malicieuses par nature, pour reproduire le comportement d’un attaquant.

Un XSS est notamment caractérisé par une relation intrinsèque entre une entrée teintée et une sortie de l’application web. Comme nous faisons l’hypothèse de test en boîte noire, capturer précisément cette relation est une tâche difficile que nous résolvons en utilisant des techniques d’inférence de teinte. Grâce à ceci, nous pouvons - à la différence d’un fuzzing systématique - nous concentrer sur les transitions du modèle pour lesquelles cette relation semble vérifiée, en évitant intelligemment de fuzzer le système complet. L’AG automatise la génération des entrées en considérant les états de l’application et en évoluant intelligemment les entrées afin de révéler des vulnérabilités XSS, s’il y en a. Nous fournissons des preuves empiriques de l’intérêt de notre approche par des expérimentations avec des applications réelles et reportons des résultats encourageants.

De nombreuses techniques servent à l'identification d'un navigateur. Généralement le serveur web se base sur le champ User-Agent (UA) présent dans les en-têtes des requêtes HTTP. En cas de doute sur son authenticité, il est possible de retrouver cette information à partir de l'observation des spécificités de comportement du navigateur au niveau réseau, HTML, DOM, JavaScript ou CSS. Les usages réels de ces spécificités de comportement se limitent essentiellement à l'évasion de filtres anti-XSS et à l'identification du type de navigateur lors d'attaques par Drive by download.

Nous présenterons les techniques actuelles d'identification de navigateur web et leurs limites. Nous vous proposerons ensuite une nouvelle technique de prise d'empreinte axée sur l'identification du moteur HTML et son couplage avec un moteur JavaScript donné. L'étude de ces techniques permet de déjouer les mécanismes de détection mis en place par les Exploit Kits dans le cadre de la lutte contre les botnets.

Proche de Stuxnet avec lequel il partage des fonctionnalités, Duqu a fait l'objet de nombreuses analyses au cours de l'année passée. Nous nous proposons d'en étudier un élément en particulier, le driver. Notre contribution consiste en la rétroingénierie de ce composant par la reconstitution de son code source et une analyse de ses fonctionnalités. Nous avons ensuite détourné le driver pour détecter d'éventuelles injections dans les exécutables Windows et prévenir d'autres attaques. En particulier nous montrons comment le driver de Duqu modifié aurait permis de détecter Duqu.

A venir.

Après plusieurs années de réponses sur incidents, peut-on déduire une ligne de conduite pour améliorer la sécurité informatique et surtout la sécurité des logiciels malicieux? L'objectif est de montrer quelques analyses d'incident et d'en déduire des recommandations. La cible de la présentation sont les auteurs de malware pour diminuer le niveau de détection, améliorer la persistance et assurer une continuité de l'exfiltration des données. Bien entendu, ces recommandations sont réversibles pour les victimes qui désirent limiter l'impact de la dernière attaque ciblée sur leurs infrastructures informatiques.

Ce projet a pour but d'évaluer la capacité des hébergeurs web de détecter des sites web compromis et de réagir aux plaintes des utilisateurs. Durant une période de 30 jours, nous avons installé nos propres sites vulnérables sur 22 plateformes d'hébergement internationales (dont 12 parmi les plus populaires au monde), et 6 «services de sécurité» pour sites web.

À plusieurs reprises, et pendant 25 jours, nous avons exécuté cinq différents types d'attaque contre nos sites, et généré du trafic simulant des victimes de phishing et attaques drive-by-download. Après le 25ième jour, si aucune activité suspecte a été détecté, on envoie des plaintes aux hébergeurs, concernant les sites attaqués. Cela nous a permis d'étudier les réactions des hébergeurs à des plaintes légitimes et illégitimes.

Les conclusions de cette étude sont assez alarmantes. La vaste majorité des hébergeurs, et des «services de sécurité» sont incapables de détecter les signes les plus simples d'activité malveillante sur les sites web de leurs clients. Notre étude montre également qu'il est possible d'abuser le mécanisme de réponse aux abus.

Non renseigné.

En informatique de confiance, le mécanisme d'attestation distante permet à un logiciel de prouver son intégrité à une entité tierce. Cette entité est alors particulièrement sensible car elle contient les données de référence qui permettent de valider ou d’inférer l’intégrité du logiciel mesuré. Le principe de ses travaux est donc d’offrir à l’utilisateur la possibilité de baser sa confiance sur une entité qui ne quitte que rarement la poche de son propriétaire : son smartphone. Contrairement aux solutions classiques d’attestation d’intégrité, l’architecture proposée est dépendante d’aucune infrastructure de confiance sur le réseau et repose sur le simple branchement par USB de son téléphone à un poste utilisateur. Pour cela, nous avons utilisé un téléphone Android afin d'attester de l'intégrité d'une plateforme Debian disposant d'une puce TPM. La preuve de concept développée consiste à se baser sur le mécanisme de tethering USB proposé par Android, ainsi que sur la solution de sources libres OpenPTS.

A venir.