SSTIC 2016 - Jour 1

Et c’est reparti pour une nouvelle session de SSTIC. Pour les recalés du 3DSecure et du copier-coller de CB vous pouvez toujours profiter de l’événement sur le stream. (sauf pour la conf d’ouverture).
Soyez rassuré, votre CR du SSTIC sera rédigé par votre serviteur ;).

Conférence d’ouverture – Brad Spengler (grsecurity)

La team PaX est venue avec l’orateur spécialement des US malgré les grèves et les inondations.

Grsecurity est un patch pour durcir le kernel Linux contre l’exploitation de vulnérabilité kernel. L’orateur nous présente donc quelques nouveautés de grsecurity, comme la randomisation de structures sensibles du noyau, empêchant les exploit kernel de trouver leur chemin dans ce dernier. De nombreuses features ont ainsi été ajoutés pour supporter les architectures Arm et x64. Coté userland, ils ont ajouté la randomisation de la stack des threads suite aux exploit d’Exodus Intel sur Asterisk. La possibilité de bloquer la reconnaissance de devices USB après le boot, et leur activation via sysctl est très sympa. PaX n’est pas en reste sur les mises à jour. La bonne nouvelle sur PaX, c’est une fonctionnalité anti-RPO appelée RAP qui effectue des adresses de retour à l’aide d’un hash.

Une des grandes difficultés lorsqu’on développe un composant de sécurité open-source, c’est de garder une indépendance intellectuelle. Ce qui implique de refuser de bosser pour des boites dont l’activité rentre en conflit avec les objectifs de grsecurity.

L’orateur à remarqué que la communauté manque de sens critique, et constate que les « trucs à la mode » prennent le pas sur l’éthique et les bonnes priorités, ce qui in-fine nuit à la sécurité en général et à sa communauté (bug bounty à tout prix, hype sur les failles de sécu « marketing », etc…).
La bonne nouvelle c’est que la sécurité s’améliore depuis les débuts de PaX/grsecurity, et l’écriture d’exploit est plus complexe. Et malgré l’augmentation des volumes de codes intégrés dans le kernel, le travail de contrôle en amont est de meilleur qualité. La même chose est vraie coté Windows, ou l’exploitation est là aussi devenue très complexe. La mode actuelle dans l’exploitation de vulnérabilités, ce n’est plus d’utiliser des shellcodes ou du ROP mais plutôt des weird–machines.

Du coté de la communauté sécurité, il y a un gros problème de qualité des présentation. Il y a beaucoup trop de conférences, avec un gros volume de présentation mais finalement pas suffisamment de fond. L’orateur regrette le manque d’articles publiés en même temps que les slides. Il y a beaucoup trop de junk-hacking (ou stunt-hacking) avec des présentations techniques dont l’utilité ou l’applicabilité est plus que douteuse. Dans notre communauté il y aussi beaucoup de charlatans qui sont là pour la popularité, et ça coûte trop cher de démontrer qu’ils ont tord (bullshit assimetry). Beaucoup trop d’experts passent leur temps à se plaindre comparativement à ceux qui créent ou publient des éléments d’amélioration ou de sécurisation.(Attaquer/casser/critiquer c’est plus facile que de construire/défendre/sécuriser).

En 2003, les discussions étaient plus ouvertes, et les techniques d’exploitation plus simples. De nos jours, les développeurs d’exploits ont tendance à garder pour eux leurs techniques parce que les entreprises pour lesquelles ils bossent ont intérêt à garder ces techniques secrètes pour mieux les vendre. Tout ceci viens gripper l’échange des savoirs dans la communauté sécurité, et du coup ralentit la sécurisation des systèmes face à ces techniques d’exploitation. L’orateur à l’impression que beaucoup de préjugés finissent par pousser l’industrie de la sécurité à avoir peur de ses propres experts. Publier des failles améliore la sécurité des logiciels -> ça demande du travail de les trouver/exploiter -> « no more free bugs » -> les failles prennent de la valeur -> moins de failles publiés = moins de sécurité.

Espérons pour le futur que les attaquants devrons se contenter d’exploiter un contrôle limité sur des données dans des weirds-machines plutôt que de l’exécution arbitraire de code grâce aux protections offertes par grsecurity. Forçant la migration des failles découvertes de l’escalade de privilèges vers l’abus de privilège, laissant seulement les failles dans la logique applicative aux attaquants. Les attaquants utilisent le chemin de moindre résistance, et nos protections doivent s’attaquer à ces chemins en priorité. Il ne sert à rien de vouloir réduire les failles à tout prix, il vaut mieux mettre cette énergie dans des protections plus pérennes qui nous sortirons de ce « whack a mole » stérile.

Comment devenir quelqu’un d’utile pour la communauté sécurité:

• Gardez un esprit critique
• N’ayez pas peur de dire « je ne sais pas »
• Prenez les critiques comme une chance de vous améliorer.
• Rejetez la course à la popularité, et soumettez des papiers riches à phrack (ou au SSTIC).
• Ne cherchez pas de raccourcis,  mettez y les efforts nécessaires et apprenez les fondamentaux.
• Cessez de vous plaindre, et réparez ce qui ne marche pas.

Démarche d’analyse collaborative de codes malveillants – ANSSI/Sogeti

L’analyse de malware présente de nombreux challenges pour les reversers: la volumétrie de malwares avec leur nombreuses variantes, le stockage des malwares, la génération d’IOC pour faciliter leur détection, etc… Il faut donc combiner des approches automatisées (sandboxes, unpackers, plugins IDA…) avec une analyse manuelle. Le problème c’est qu’en équipe, lorsqu’on est plusieurs à travailler sur un même malware, on peut vite se retrouver à reverser la même portion de code, mais pas forcément au même moment. Il faut donc pouvoir partager ces informations pour éviter le gâchis de temps de cerveau. En suite il y a l’aspect partage d’information (MISP ?).

L’outil issue de ces travaux d’automatisation s’appelle Polichombr. Il est en dev depuis 2014, et servait principalement à l’auteur pour répondre aux problématiques de stockage (regroupement par familles, etc..), de centralisation des savoirs, de reverse collaboratif, d’automatisation et de classification.

Pour la classification, chaque analyste balance des sha1, des md5 etc… sauf que le moindre changement dans le malware implique un changement dans le hash. Du coup les fuzzy-hash sont plus adaptés pour faire des rapprochements entre les samples. Mais comme on connait le format de donnée (PE), on peut y appliquer des stratégies d’analyse et de fingerprinting adaptés. L’idéal c’est que ce fingerprint puisse encaisser le re-compilations, d’ou la création de Machoc. L’idée c’est d’utiliser le CFG généré par IDA pour en faire une signature. L’ensemble des noeuds du CFG est numéroté, puis sérialisé et hashé par murmurhash3. Ce qui permet de partager des hashs de CFG sans révélé le CFG sous-jacent, et donc le leak d’information. Chaque fonction du binaire est en suite hashé avec cette méthode pour générer la signature Machoc.

A partir de là, on peut via l’interface web, faire analyser un sample, et importer l’ensemble des informations de retro issue des fonctions déjà analysées et identifiées par leur hash Machoc. L’ensemble des sources est disponible ici.

Gunpack – Airbus group inovations

Un outil d’unpacking générique de malwares sous windows 32 bits en Python. L’outil est fait pour s’attaquer à des packers « COTS » ou custom. Un packer, c’est un binaire qui contient un binaire et qui va déchiffrer ou décompresser le programme original, et l’exécuter. Gunpack va dynamiquement suivre l’exécution du packer et essaye d’identifier le moment ou le packer passe la main au code original. Il existe de nombreuses heuristiques pour identifier cet événement, et du coup Gunpack essaye de toutes les appliquer. Pour se faire il monitore les événement d’accès mémoire, ainsi que leur modification. L’invariant choisi pour identifier les manipulations faites par le packer consiste à forcer un mode Writable xor Execute, et à gérer les exceptions mémoire.

Petite démo, et retour sur le fonctionnement de la gestion mémoire sous Windows. Le développement de l’outil à du déjouer plusieurs problèmes techniques, comme les pages auto-modifiantes qui s’altèrent en boucle, levant une tonne d’exceptions. L’autre problème à gérer, c’est les modifications de la mémoire faite par le packer sans avoir à modifier la structure interne du noyau. L’orateur à donc du contrôler les appels à MmAccessFault pour gérer les fautes de pages, et KiDispatchException pour le cas des pages auto-modifiantes (ça va trop vite :/ ). Le driver communique avec du code Python dans lequel est codé la logique de suivi et d’unpacking.

Cryptanalyse en boite noire de chiffrement propriétaire : étude de cas

Bon, pas besoin de reverse-engineering, et pas besoin de math, seulement de savoir lire de l’hexa et de comprendre les transformations de base. Cette présentation fait suite à un ras-le-bol des constructeurs qui font de la custom-crypto soit-disant sûre. L’exemple parle d’un système embarqué à analyser en mode « hackathon ». L’équipement devant rester en état de fonctionnement, et étant fondu dans un radiateur géant, difficile d’accéder à la flash etc… Du coup, pas d’attaques matérielles, et obligation de l’utiliser « normalement »,  ou de l’analyser via le fichier de mise à jour. A partir des updates, l’orateur à identifié deux familles de hardware, et le downgrade est supporté. A l’aide de binwalk et de l’analyse d’entropie, on peut identifier les sections compressés ou chiffrés. En regardant l’en-tête, on peut identifier des champs et des valeurs (TLV, little indian, etc…) avec des zones textes en ROT13. On y retrouve aussi, si on a de bons yeux, un sha256 d’une chaîne vide. On retrouve ces sha256 dans plusieurs updates, probablement correspondant au hash du clair des données une fois déchiffrés.

Analyse du Chunk #1
Il semblerait qu’il y ai un mécanisme de « craptage » avec des ROL13. En s’aidant des hash découverts précédemment, en faisant des ROL successifs jusqu’à trouver des chaines significatives comme un magic ELF avec le bon sha256. Le binaire est là pour décompresser les données avec LZ et charger l’ELF issue du second chunk probablement.

Analyse du Chunk #2
L’idée consiste à déchiffrer (ROL) puis décompresser avec LZ. Pour se faire, l’orateur à du re-implémenter cette logique. Il a fallu aussi patcher la décompression avec les bugs trouvés dans le chargeur d’update ELF du chunck #1. Petite passe sur le fonctionnement d’un algo de compression et du format de fichier associé. L’idée c’est d’exploiter les mécanismes de hash de blocs compressés présent dans le format compressé pour venir valider la valeur du ROL à effectuer sur le nouveau bloc. Après 6 semaines on arrive à obtenir l’algo de décompression avec ses rotations et ses variations de tailles de blocs.

Beaucoup d’autres éléments dans les actes.

Eurisko : développement d’une carte électronique sécurisée

Retour d’expérience sur le développement d’une carte électronique avec des fonctions de sécurité. Il s’agit d’une carte avec deux interfaces Ethernet Gigabit, avec un faible dégagement de chaleur et avec des composants « COTS ». L’objectif était de déployer dessus un Linux avec grsec et du code maitrisé, et d’avoir une chaîne de boot intègre, avec pré-boot sur token externe. L’intérêt final c’est de disposer d’un retex sur le développement de composants sécurisés avec tout les problèmes qu’on peut rencontrer lors de son industrialisation.

SOC: System On Chip, c’est un composant qu’on retrouve un peu partout, box, routeurs, smartTV, RaspberryPi, etc… Il intègre pas mal d’interfaces matérielles (IO, JTAG, usb, radio, network, etc…). Le SOC boot sur une ROM, qui va en suite charger un bootloader type UBOOT. Ce type de SOC dispose de fonctions de sécurité pour empêcher le remplacement du bootloader, ou désactiver les fonctions de debug (JTAG, etc…). Les µContrôleurs eux sont moins puissant, mais disposent de fonctions de sécurités assez poussés. Du coup on peut utiliser le µC peut gérer le boot de la carte de façon plus sûre. Dans la carte développée, le µC (ST33) peut reset le SoC à volonté, et le killer s’il détecte quelque chose d’anormal. Il peut communiquer avec un composant externe via une interface I²C.

Pour le boot de la carte, le µC M0 maintient la pin de reset du SoC pendant la vérification de ses éléments internes avant d’autoriser le SoC à booter. Pour le token externe, il s’agit d’une carte à puce sur le bus I²C avec le même µC que celui qui contrôle le SoC. Une fois l’authentification faite, le SoC peut booter, et monte un canal sécurisé avec le SoC. En suite les stages suivants du boot sont récupéré ssur la carte SD, ces derniers étant chiffrés et signés.

Le boot du µC se fait par séquences. Chaque séquence vérifiant la signature du code de la séquence suivante. Pour la maj du µC, un token externe de mise à jour permet de venir modifier ces séquences, séquences elles encore cryptographiquement vérifiées par la 1ère séquence de boot du µC. Pour éviter les failles dans le code de boot, des règles strictes de développement en C99 sans malloc ni dynamisme ont été appliqués, permettant la validation des propriétés de sécurité par analyse statique (pour plus de détail, il y a les actes).

Pour le prototypage, il a fallu passer pas mal de temps pour obtenir les puces (NDA & cie), et à mettre en place l’environnement de développement. Le µC étant très petit, il dispose d’une datasheet compacte (200p), avec un volume de flash énorme. Le prototypage amont permet de lever pas mal de problèmes de conception avant d’en avoir réellement besoin. Avoir un bon sous-traitant solide techniquement, ça fait la différence. Si vous êtes en proto, et que ça foire, c’est pas grave, par contre dans le cadre d’un vrai projet ça peut vous mettre au tas. Le projet de prototypage permet aussi d’évaluer la qualité de vos fournisseurs. Prototyper c’est pas forcément très long (20 semaines), ni très coûteux, mais avec ça vous pouvez maîtriser pas mal de choses.

Evolution et dé-évolution des systèmes multimédia automobile

Un système automobile, c’est plein d’ECU qui causent sur un bus de données CAN. Les voitures multimédia connectés elles disposent d’un boitier multimédia supplémentaire qui s’interfacent avec le bus CAN multimédia, et qui communique avec le monde via une connexion GSM/2G. En fonction des constructeur, les bus CAN « automobile » dédiés aux systèmes de freinage sont parfois accessibles depuis le boitier multimédia (d’ou les différentes prez de hacking automobile). Chez d’autres constructeurs, une gateway est présente entre le bus CAN Multimédia et le bus CAN « automobile ».

Lorsqu’on veut analyser une boite noire tels que ces boitiers multimédia, on trouve des ports ADB ou console, ou JTAG identifiable avec des ports d’étain prêt à souder. En fonction des composants et des constructeurs, ces interfaces sont actives ou pas. Coté consoles, les shell dernières requièrent parfois un login, récupérable ou pas sur les fichiers de mise à jour. Parfois, il faut récupérer les infos d’authentification sur la flash/EEPROM/eMMC/NAND du composant (plus de détails dans les actes).

Une fois l’OS identifié,  on essaye d’exécuter du code sur ces composants. Ces composant disposent souvent d’un secure-boot plus ou moins bien implémenté et donc pas forcément sûrs. Parfois, les fichiers de mise à jour sont signés, parfois non, chiffrés plus rarement. Certains composants sont très sensibles, et ne démarrent plus lorsque la mise à jour est corrompue. Pour obtenir une exécution de code, l’autre méthode consiste à trouver une vulnérabilité sur le système et ses composants. Là encore, ça dépend fortement du niveau de mise à jour, de ce dernier: Android, Linux avec ou sans configuration sécurisée. Parfois le système de mise à jour peut être vulnérable.

Une fois le boitier multimédia sous contrôle, il est possible d’accéder à l’ensemble des composants multimédia du véhicule, comme par exemple de diffuser du son à pleine puissance, ou de modifier les options de confort du conducteur. L’accès à internet permet de charger du code sur le boitier et d’y récupérer des mises à jour. Ainsi sur le boitier multimédia on trouve un service DBUS qui permet de mettre à jour le composant qui communique avec le bus CAN, cetteMAJ est sans signature parce-que ça coûte cher en puissance de calcul.

Le composant télécom/GSM propose souvent un JTAG avec une console active par défaut sur l’UART. Si on dépasse les 50 chars dans la console, la pièce reboot : ça en dit long sur sa sécurité.

USB Toolkit

Un outil en développement qui a servi à la résolution du challenge SSTIC. Il y a de plus en plus de recherche orienté sécurité sur le bus USB. Du coup il peut être intéressant de développer un proxy USB pour l’analyse ou la sécurisation de l’accès au bus USB par un périphérique. En USB, la communication est toujours dirigée par l’Hôte.

L’orateur à donc développé un device USB pour faciliter ce type de travaux sous la forme d’un composant modulaire avec lequel on peut communiquer en UDP. On peut ainsi piloter le gadget USB depuis un programme Userland de la même façon qu’un composant USB communique avec le driver Kerneland.

A partir de cette base hardware et software, il est possible d’implémenter un sniffer USB, ou un pare-feux USB bloquer les périphériques autres qu’un clavier ou une souris. Autre application: un Fuzzer par mutation qui va altérer les messages USB à la volée, et si le périphérique s’arrête, le relancer. On peut aussi implémenter un keylogger USB (forcément), ou dumper le traffic USB sous forme d’un .pcap. Un autre programme permet de rejouer un .pcap USB comme pour le challenge SSTIC.

Confusion de type en C++

Je suis confus…. cf actes & archives vidéos si la prez est mise en ligne 😉

Composants logiciels vérifiés en F* : Poly1305 

Là c’est le vidéo-proj qui est confus….

My friends botnet: How to use your friends to perform Cyber Int ?

Le rêve de l’orateur, c’est d’avoir les bases d’IOC offline, en gros, Internet mais Offline. Du coup on aimerais bien crawler l’Internet à la recherche d’infos sur votre entreprise pour mieux la protéger, etc… Et on fini par monter une super-boucle d’OSINT (ici nommée Cyb-Int) ou l’on crawl, on monitore, et on vient enrichir ce qu’on recherche. Exemple avec DNS: les zone file sont pas toujours récupérable, parfois via des services publiques, parfois des scans publiques, parfois via des abonnements privés etc. Une fois les domaines récupérés, on va vouloir récupérer les pages web, et on espère le faire depuis le cloud. Hélas EC2, c’est souvent limité par les hébergeurs au niveau IP. Les hébergeurs eux viennent gueuler rapidement lorsqu’on balance 4M de requêtes DNS par jour. Alors l’orateur à essayé de se faire héberger des VPS en Roumanie, et là c’est coté requêtes Google que ça pose problème parce que le provider se fait blacklisté, et tous les utilisateurs de l’hébergeur qui râlent. Quand à TOR, bah, le temps que ça résolve, si jamais ça se résout…

Du coup l’orateur à eu l’idée d’utiliser ses amis pour avoir plein de connexions ADSL et d’y noyer ses requêtes et ses aspirations. Du coup, un coup de Rebus avec des agents et le « friendly botnet » est monté. Exemple de service cloud avec des informations intéressantes: VirusTotal avec ses commentaires, qu’il peut être intéressant à garder.

Composants logiciels vérifiés en F* : Poly1305 

La sécurité des composants crypto, c’est compliqué, c’est pour ça qu’on fait plein d’erreurs. Ex avec OpenSSL et un commentaire qui dit « pas de buffer overflow possible ici » alors que c’est faux. Et là c’est le drame. Du coup l’INRIA et MS Research proposent un langage F* « à la ML », paraîtrais même qu’on peut coder avec. Et du coup le solveur est capable de contrôler les pré & post conditions sur le code. L’orateur présente ensuite l’implémentation de l’algo Poly1305 en C toute foireuse, puis son implémentation en F* capable de vérifier des propriétés cryptographiques essentielles.

Broken Synapse

Désactivation du brouillard de guerre dans le jeu de stratégie online Frozen synapse. Il y à deux modes de jeu, un avec et l’autre sans brouillard de guerre. Du coup c’est un sacré avantage tactique. 1ère idée: analyser le protocole du jeu sous wireshark. Le protocole étant assez dégeu, bien que non-chiffré, l’orateur n’arrive pas à voir dans l’hexa les informations sur les unités ennemies.

Autre approche via debugging du jeu, malheureusement, ce dernier est codé via un moteur de jeu, et on se retrouve vite coincé dans le moteur, et non dans la logique du jeu. Le jeu est scripté avec un langage maison, le CScript, qui est ensuite compilé. L’orateur à donc choisi de dé-compiler les fichiers .cs.dso. C’est un langage qui ressemble à du bytecode Java et l’interpréteur fonctionne avec des piles et pas de registres. L’orateur à donc écrit un émulateur/dé-compilateur en python pour ce langage dans lequel, les résultats de l’opération ne sont pas pushé sur la pile, mais remplacé par leur équivalent en terme de code. De la même façon, l’affectation sur la pile génère une affectation dans le « code » de la VM. Ca se complique avec les structures de contrôle ou il faut déterminer ou se « ferme » l’accolade de la condition dans le bytecode. A la fin, on obtient un dé-compilateur « qui marche » mais en fait non… vu que la spec du langage à changé. Du coup ça s’est fini dans IDA avec la version linux non-strippé, puis patch du dé-compilateur.

Quand au moteur de jeu, il a le bon gout de compiler les fichiers CS non compilés pour mettre à jour le code du jeu, ce qui facilite le patch.

Un FizzBuzz pour le cyber

FizzBuzz, c’est un jeu pour enfant ou lorsqu’un nombre du jeu est divisible par 3 on doit dire Fizz, et quand c’est divisible par 5 on doit dire Buzz au lieu de dire le nombre. Du coup, l’idée c’est de demander à un developpeur de coder un algo FizzBuzz qui énumère les nombres de 1 à 100 et qui dit Fizz et Buzz au bon moment.

Pourquoi cet exercice: pour sélectionner les candidats sur leurs capacités logiques sans que ça nécessite un ordinateur, une connexion à internet ou un ami. Exemple de questions à tiroir pour lesquelles on peut approfondir la réflexion avec le candidat. Multiples d’un nombre, complément à deux, l’objectif est d’amener le candidat sur des problèmes de représentation de nombre en binaire, etc…

De même sur les principes de base sur la cryptographie et ses principes et ses définitions, les commandes shell, et leurs réactions face à des inputs « risqués » pour la sécurité. Ou encore les principes de fonctionnement du réseau et l’impact de certains composants sur le comportement attendu. En développement, les principes de la compilation, interprétation, etc dans les langages ne sont plus vraiment maîtrisés car les IDE masquent pas mal de choses. L’entretien se termine avec des discussions très banales qui révèlent beaucoup sur la culture SSI du candidat.