SSTIC 2019 - J3

Après une (très) courte nuit, nous voici reparti pour cette dernière journée de SSTIC.

Russian style (lack of) Randomness

L’aléatoire à la russe, et les standards crypto russes. Lorsqu’on crée un nouvel algo crypto, on fait un papier avec les specs de design de l’algo, et ensuite on le publie et la communauté essaye de le péter. Si le papier survit à la communauté assez longtemps, on le standardise, on l’implémente et hop. L’analyse ne s’arrête jamais, et si une attaque est trouvée sur un truc standardisé, bah faut plus s’en servir. Certains gouvernements n’aiment pas ça à cause des critiques etc… L’autre technique c’est de pondre le truc à l’arach sans demander aux autres et de dire « utilisez le ».

L’algo crypto est construit avec des boiboites L pour la diffusion (??) et des boites S pour la confusion (???). C’est aussi utilisé par AES, et c’est assez standard. Bon la question sur la boite S c’est comment elle est construite ? Bah dans la spec c’est un pov’ tableau, et les designers ont dit que cette boite était tirée aléatoirement, et du coup sans structure mathématique forte (LOL?). Ce type de construction est complètement absurde, c’était à la mode dans les années 90.

Streebog et Kuznyechik ont été poussé à l’IETF sous forme de RFC, et la standardisation ISO vient de se terminer sur Streebog, et Kuznyechik c’est en cours. En mai 2016, il y a eu une décomposition du tableau de la S box, et il a fini par être complètement décomposé cette année.  Les designers insistent en disant que la Sbox était tirée en random, si si …  (détail du fonctionnement de la Sbox T.T  )

Du coup la fonction tirée au sort en random se comporte en fait comme un logarithme, du coup c’est pas random en fait. Bon la boite S ressemble franchement à une backdoor crypto, mais on en a pas la preuve, ni d’attaque adaptée. Du coup  il ne faut pas utiliser ces deux algos, et il faudrait les virer des standards. C’est pas parceque c’est standardisé que c’est bien fait !

Le quantique c’est fantastique

(des quantiques au couvent des jacobins !)

Le calcul quantique, c’est une entrée qui s’fait secouer dans des états intermédiaires et on a une valeur finale en sortie. Certains problèmes sont plus faciles à résoudre en quantique grace à cette souplesse des états intermédiaires. Bon ça marche pas toujours super, mais pourquoi ça nous intéresse ? On estime que dans un certain temps on devrait avoir un ordi quantique fiable. On se dit que le temps qu’on trouve des algos quantiquement fiables et qu’on les standardise il ne faudrait pas que l’ordi quantique soit stable avant.

Quand on fait un calcul quantique, tous les états sont supperposés, mais lorsqu’on fait la mesure, on trash ces états pour obtenir un résultat probablement au pif (effet de sonde, le chat, etc…). Le NIST a fait un appel à candidature pour des algos qui encaissent la cryptanalyse quantique.  Sur  69 candidats, 22 se sont fait défoncer avec des ordi « classiques » (c’est con…). Comme quoi la crypto c’est très très très dur. 26 ont été sélectionnés pour le second tour d’analyse qui est toujours en cours. Fin de la standardisation estimée pour 2023.

La cryptographie quantique, c’est un échange de clef quantique. On s’échange des états quantiques, et l’échange quantique n’offre pas d’authentification donc on à toujours besoin de crypto assymétrique classique. (là je BSOD)

Ethereum: chasse aux contrats vulnérables

Une blockchain, c’est une espèce de liste chainée cryptographique. Si on a le hash du dernier block on peut reconstruire l’ensemble de la chaine. Chaque nouveau block est un instantané qui fait avancer. Les mineurs fournissent les preuvent de travail, et les transactions incluent des frais qui sont donnés aux mineurs qui font avancer le réseau et ses preuves.  Les comptes sont sous forme d’une paire de clefs crypto, la clef privée permettant de faire des transactions, et la publique de recevoir de l’argent.

Les contrats intelligents datent d’avant les années 2000. En Ethereum, il y a des addresses de comptes et des addresses de contrats intelligents associés à du code immutable. Ce code tourne sur la VM d’Ethereum, c’est une machine à pile très très simple avec une archi 256bits ce qui est pratique pour la crypto.  L’exécution de code coute du gas (frais de transactions).

Les contrats sont codés en solidity, une espèce de JavaScript que l’on compile en bytecode EVM pour être ensuite exécuté sur Ethereum. Les baleines sont les gros contrats Ethereum. La DAO, c’était un fond d’investissement contrôlé par un programme qui à levé plus de 100 millions de dollars. La DAO avait une vuln dans la fonction de retrait à cause d’un problème de récursivité ré-entrante.  Cette faille à créé un Hard fork et à créé ethereum classique.

Pakala est un outil développé par l’orateur d’exécution symbolique dispo sur Github qui simule les exécutions possibles d’un contrat intelligent. Pour faire son analyse, l’orateur à créé un noeud ethereum archive de 2TO sur SSD qui à pris 2 mois a se créer.  L’orateur à trouvé des honeypots avec un contrat à quelques milliers d’euros avec un bug trivial, mais pour le déclancher il faut envoyer de l’argent sur une addresse, et le bug est très subtil et du coup on récupère pas l’argent. Il y a des contrats très buggués avec pas beaucoup d’argent. Il y a des casino avec des sources d’entropie prévisibles donc prédictibles. L’orateur à trouvé des pyramides de ponzi.

Analyse de sécurité d’un portefeuille pour cryptomonaies

Le problème des wallet hardware, c’est qu’il faut le backuper sous forme papier ou « cryptosteel ». Du coup HTC à sorti un smartphone dédié à la blockchain (marketing) qui fait hardware wallet en plus d’être un smartphone classique.  Les seed sont stockés dans un OS sécurisé dans une trust-zone et du coup l’OS normal n’a jamais accès à ce qui se passe. Le social key recovery permet de partager la clef avec des contacts de confiance, et chaqu’un d’entre eux vont recevoir une partie de la seed. Les tiers doivent installer une application Zion, et une partie de la seed leur est envoyée chiffrée et stockée dans le keystore android. L’algo repose sur le secret partagé à seuil de Shamir. Il faut donc un nombre minimum de portions du secret pour reconstruire la seed.

Comme il y a un soucis dans le PRNG, l’orateur a pu poser un système linéaire pour casser les bits de la clefs, et du coup avec deux contacts de confiance on peut reconstituer la seed de l’utilisateur. Si un contact est malveillant, il n’a plus qu’a convaincre ou compromettre un second contact pour voler l’utilisateur.

A tale of Chakra bugs

L’orateur à pas mal bossé sur la sécurité du moteur Javascript et plus particulièrement Chakra, le moteur JS de Microsoft. Chakra est écrit en C++ dont 95% est opensource sous le nom ChakraCore. Tous les moteurs JS utilisent des tricks. Pour encoder les types, Chakra utilise du NaN boxing. Les JSObjects sont des dictionnaires comme en python, et chaque objet ne maintient pas sa propre map, et ils ont un type qui décrit le type de chaque objet. Les tableaux sont des objects comme les autres, mais les moteurs implémentent des optimisations pour les tableaux d’entiers, de floats et les autres.

Les bug avec un side-effect observable. En JS on peut utiliser pas mal de callback, et certaines d’entre elles sont observables. On peut donc gérer des getter/setter sur chaque propriété pour aller les observer.. Les moteurs JS sont plein de bugs lié à des problèmes de timing dans les accès à ces propriétés. De la même façon, le moteur JIT qui compile le JavaScript en assembleur peut lui aussi souffrir de bugs sur les types des variables. Ces erreurs sur les types génèrent des confusions de type. Une confusion de Type est souvent exploitable et peut engendrer une RCE.  Les tableaux étant stockés de 3 façons différentes, il est intéressant de confondre un tableau avec un autre. Lorsque la confusion survient, certaines valeurs du tableau sont interprétés comme des pointeurs, engendant un crash.  On va utiliser ce bug pour récupérer un pointeur de VTable valide afin de pouvoir en suite mettre la bonne addresse sur le pointeur. En jouant avec ça on obtient un Read/Write arbitraire.

Il existe aussi des bugs dont les effets de bords ne sont pas observable depuis JavaScript. Lorsque le JIT fait des optimisations, parfois il peux se foirer, et écrire la ou il y a des pointeurs, et c’est le drame.

Les bugs JS sont de moins en moins compacts, et il faut jouer avec des mécanismes de plus en plus obscurs du JIT, ce qui nécessite une bonne connaissance interne du moteur. Par exemple, certains objets peuvent être optimisés par un cache pour accélérer la résolution des types. La boucle for .. in permet de boucler sur les propriétés d’un objet, et ça déclenche des bugs subtils.

V2G Injector: whispering to cars and charging units.

Les bornes de recharge servent t’elle seulement à charger ?  Les énergies renouvelables sont difficile à gérer car la production n’est pas linéaire et il faut stocker l’énergie. Du coup les batteries des voitures pourraient former une grille de batteries pour lisser la charge par rapport à cette production. Du coup les systèmes de chargement sont bi-directionnels et vous pouvez être payé pour donner votre énergie stockée en compensation de l’usure de la batterie.

Le V2G est un standard de communication pour les véhicules électriques. Le protocole est très velu et utilise le CPL pour causer entre la voiture et la station de charge. Depuis cette couche physique, l’orateur à du dépiler toutes les couches jusqu’a arriver à la partie donnée V2G qui contient les infos de payement etc… Il est possible de chiffrer les communications, mais l’archi est très hétérogène, et du coup bah c’est l’bordel.

L’homeplug Green Phy c’est presque comme le homeplug AV utilisé dans les boitiers CPL domestiques. Dans le CPL, tout est broadcasté, et le véhicule ne sait pas à qui il est connecté. Du coup  il y a une procédure SLAC qui permet de déterminer qui est le plus près pour identifier la station de charge qui elle va répondre en Unicast.

Il y a très peu d’outils pour analyser le V2G. L’orateur à donc créé un outil qui gère l’ensemble des trucs dont il a besoin. Si on met une prise CPL en mode PEV on peut s’en servir pour communiquer avec sa station de charge. Pour 60€ on peut donc bidouiller une interface à partir d’une prise domestique. La com réseau en V2G se fait en IPv6 (si si, c’est pas des blagues, plus d’infos dans les slides). Les paquets V2G sont fait en XML avec divers protocoles plus ou moins bien documentés, pas forcément à jour etc… Le tool est sur github.

Analyse de firmwares de points d’accès

Les AP Ruckus et Aerohive disposent de backdoors root qui nécessitent une clef et l’ID du point d’accès. L’orateur détaille comment fonctionne la backdoor v54 et le calcul de clef (plus de détails dans les actes).

Under the DOM: Instrumentation de navigateurs pour l’analyse JavaScript

L’auto-blogging live de ma conf, c’est fun !!!

L’obfuscation consiste à rendre difficile à comprendre un code source, volontairement ou non. C’est très très utilisé pour éviter la détection des anti-virus notamment sur les exploit-kits. En prime le navigateur ne facilite pas la vie de l’analyste car son comportement est de plus en plus complexe et parfois pas prédictible. En prime avec les technos type Electron, les navigateurs deviennent la GUI universelle. Désobfusquer du JavaScript c’est pas très compliqué, mais c’est fastidieux et le temps de l’analyste est précieux. Mineurs de cryptomonaies, XSS, exploit-kits, fingerprinting & tracking des utilisateurs, c’est pas les menaces qui manquent. Du coup l’orateur (moi) s’est demandé comment récupérer à coup sûr l’ensemble des scripts JS qui s’exécutent dans le navigateur sans le modifier, en déjouant les éventuelles anti-analyses et en désobfusquant le JS.

Un navigateur c’est très compliqué, ça embarque des compilateurs & interpréteurs JavaScript, des libs crypto, des libs graphiques, ça fait beaucoup de code. Le moteur HTML fait régulièrement appel au moteur JavaScript pour exécuter le code qu’il trouve dans les pages. Mais parfois c’est le JavaScript qui écrit des trucs dans le HTML qui du coup doit re-analyser la page. Le moteur JavaScript et HTML s’influencent donc joyeusement l’un-l’autre durant la vie d’une page web. L’orateur va donc chercher à se placer entre le moteur HTML et le moteur JavaScript pour récupérer tout les codes JS que le moteur HTML à trouvé, ainsi que les codes JS généré par du JS.

Pour ce faire, il s’est aidé de Frida pour venir poser un hook sur l’initialisation du compilateur de bytecode du moteur JavaScript. En suivant quelques pointeurs on peut ainsi retrouver le code source à compiler et tout récupérer.

L’avantage c’est qu’on ne rate rien de ce qui s’exécute dans le moteur JS, et on à même accès au code JS privilégié qui est exécuté dans les extensions Firefox. L’approche est généralisable à tous les autres navigateurs, et est détaillée dans les actes. (Merci à François qui à géré le liveblogging et corrigé les fautes 😉

Source-Fu: désobfuscation de code source

Au quotidien, quand on traite avec des malwares, on a souvent affaire à des scripts offusqués (jscript, wsh, bat, powershell, etc…). Les outils capables de faire de la désobfuscation de source par évaluation partielles sont au nombre de deux, et sont pas à jour. Du coup l’orateur à choisi d’écrire une grammaire par langage à désobfusquer et optimise ensuite le code par des passes successives qui permettent de supprimer le code mort, de faire sauter les prédicats opaques etc.

Une fois le ménage fait, on peut faire une passe de ré-écriture pour renommer les variables en fonction de leur contexte etc… L’outil est sympa et publié sur Github.

Hyper-V – Techniques d’attaques et de défense contre la corruption de mémoire

La sécurité ne prend pas assez de place dans la formation des ingénieurs logiciel, ça devrait être un principe de base de l’ingénierie logicielle. On peut former les gens au développement, et bien les former ça n’empêche pas que lorsqu’on développe, on insère des bugs, et le niveau de complexité joue. Il y aura toujours des bugs, et il faut faire avec. Ca ne veut pas dire qu’il faut abandonner la formation et le code review, c’est juste qu’il faut rester pragmatique, et on doit donc réduire leur risque d’apparition.

L’orateur nous détaille ensuite le fonctionnement d’Hyper-V et des hyper-calls. Hyper-V utilise des espaces mémoires partagés pour échanger des infos entre l’hyperviseur et le guest sans effectuer des recopies mémoires inutiles. Le problème c’est que lorsque les recopies dans les buffers ne sont pas atomiques, on peut avoir des race condition entre les threads ce qui engendre des vulnérabilités. (l’hyper-v c’est hyper-complexe, je vous invite à regarder la vidéo dès sa publication).