SSTIC 2016 - Jour 3

Le vendredi matin, c’est toujours plus clairsemé. C’est d’ailleurs souvent les CR SSTIC du vendredi qui sont les plus populaire sur n0secure en nombre de visites (étrange…).

MacOS : System Integrity Protection 

SIP un mécanisme de protection dit « rootless » qui vise à réduire les privilèges d’administration sur les mac pour éviter que ne soit chargé des modules noyau non-signés. Les informations de vérification des signatures sont stockés dans la NVRAM et sont éditable seulement en mode Recovery. Ces infos peuvent aussi être mises à jour avec le mécanisme d’updates de MacOS-X. Ce mécanisme de protection souffre de problèmes de jeunesse comme la possiblité de charger des drivers pour du matériel non-certifié mac (en gros MacOSX sur autre chose qu’un Mac).

Sip viens aussi prévenir certaines application d’écrire dans /root et cie, mais il existe des applications qui ont les autorisations qui vont bien, mais dont le comportement peut être détourné. Il existe une vieille version de gdb livré avec une vieille version d’XCode avec laquelle on peut venir charger une appli privilégiée et en suite remplacer son code par celui de votre choix.

SIP est directement importé du modèle iOS ou chaque application dispose de ses privilèges, et ou il n’y a plus vraiment de « root ». Mais comme ce modèle arrive après coup, il y a plein d’applications à détourner, et de drivers pourris à exploiter pour contourner ce modèle.

Java Card security, Software and Combined attacks 

 Petits rappels sur les principe de fonctionnement des JavaCard. Attaquer les JavaCard, ça peut se faire de plein de façon, injection de fautes au laser, à l’electricité, attaque par canaux cachés, fuzzing, chargement d’un code Java malveillant, etc…

Ici l’orateur cherche à contourner le contexte de sécurité qui firewall le code java chargé dans la JavaCard et qui viens protéger les clefs crypto. Exemple d’overflow dans un code JavaCard qui viens écraser des structures sur la stack pour contourner le mécanisme de sécurité. En suite on re-utilise cet overflow pour « ranger la stack » et on obtiens un securityContext corrompu ce qui permet de contourner le firewall (corrigez moi si j’dit des conneries, c’est le vendredi matin…).

Autre technique, on place du code-mort malveillant dans l’applet Java, et on utilise une injection de faute (attaque hardware) pour faire sauter l’exécution sur le code mort. L’attaque est réalisable sur les dernières générations de JavaCard. Du coup il faut que le soft et le hard soit bien protégé pour que la sécurité soit opérationnelle.

Fuzzing and Overflows in Java Card Smart Cards

Les JavaCard utilisent un fichier .CAP avec tout plein de dépendances dans les champs qui le compose. L’orateur à donc choisit de muter ces fichiers .CAP, puis de les passer au bytecode-verifier pour s’assurer qu’il pourra être chargé par la JVM de la JavaCard. Ces fichiers sont en suite servis à une JVM de référence d’Oracle. Les fichiers qui passent le Bytecode-verifier sont re-utilisés pour la génération suivante de fichiers mutés et ainsi de suite. Du coup ça crash dans la JVM. Explication du crash dans la JVM et de comment ce fait-il que le bytecode-verifier il voit rien dediou. Exploitation en suite de la vulnérabilité, du crash vers le bug.

Noyaux Linux durcis

Mise en oeuvre de techniques de durcissement d’un noyau linux. Le noyau sait tout, tourne en ring0 et gère la sécurité du monde userland. C’est donc lui qui va isoler et sécuriser les process les uns vis à vis des autres. Les bugs noyaux impliquent des élévations de privilèges systématiquement. Corriger ces bug c’est bien, mais ça fait pas tout. Il faut donc que le noyau se protège lui-même contre les attaques.

SELinux, AppArmor sont orienté sécurité userland et ne protègent pas le Noyau. D’ou l’avènement de grSecurity qui est un patch du noyau permettant son durcissement.  PaX qui protège contre les corruptions mémoire, RBac qui est un mécanisme de contrôle d’accès userland, etc…

PaX offre énormément de protections niveau kernel (ASLR, MPROTECT, etc…) et offre aussi des plugins GCC pour protéger contre des attaques avancés comme le ROP. Ces plugins viennent enrichir le source du noyau de protections à la compilation.

Finalement, il n’y a pas tant de personnes à utiliser grSecurity. Patcher, configurer et compiler le noyau, c’est pas évident, ça demande des efforts, et à chaque maj du kernel, il faut recommancer. Sur gentoo, c’est assez bien pensé, mais c’est long. L’orateur propose donc un outil grsec-config pour récupérer grsecurity et appliquer le patch, et l’autre pour vous aider à gérer la config matérielle, logicielle et grsec séparés. L’orateur est dev debian, et propose un paquet linux-grsec en sid.

Une fois grSecurity installé, il faut le prendre en main, et ça peut casser certaines application, notamment les moteurs JIT ou JavaScript des navigateurs à cause de MProtect. Du coup il faut venir configurer grSecurity dans /etc/sysctl.d/grsec.conf (sous debian).  Il est possible de marquer un binaire spécifique avec paxctld et de lui autoriser des zones mémoire en écriture & exécution.

Dans les prochains noyaux à venir, on va avoir du kASLR et autres joyeusetés. Mot de la fin de l’orateur: grsecurity c’est pas si compliqué, et il est possible d’obtenir du support auprès de l’équipe grSecurity.

Design de cryptographie white-box : et à la fin, c’est Kerckhoffs qui gagne

Le modèle de cryptographie white-box est fait pour tourner en environnement hostile, ou la ligne de défense c’est l’implémentation à coup d’anti-debug, d’obfuscation de code etc… Quand on veut faire de la crypto dans un contexte hostile comme les drm ou les mécanismes de transaction bancaire sur des téléphone. Bon forcément la cryptographie ça sert à rien d’en cacher le code, puisqu’il est ultra connu. Chow et al. à proposé la cryptographie white-box ou l’on va diffuser la clef dans le code d’AES avec quelques manip pour éviter la lecture des états intermédiaires de l’algo.

L’histoire à fait que ces solutions ont été cassés, améliorés, re-cassés etc… Du coup l’industrie à décidé de cesser de publier ses implem (pas bieeen), d’y rajouter de l’obfuscation etc. en espérant que ça se vende. Bon, les attaques académiques sont pas forcément simples à mettre en oeuvre parcequ’il va falloir des-obfusquer, reverser, etc… galère quoi.

Les orateurs ont donc choisi de prendre une piste plus simple: obtenir des traces d’exécution du code, et partir de là pour tenter de casser une crypto white-box. En utilisant la mise en forme visuelle de Tetra (produit quarkslab), on identifie rapidement les différents « rounds » d’AES. Les données aussi présentent des patterns reconnaissables.

Les attaques par DPA consistent à exécuter plein de fois l’algo, et en suivant la conso électrique, d’identifier des bits de la clef cryptographique. L’idée c’est d’appliquer cet équivalent aux traces logicielles observés. Du coup les orateurs ont récupéré les traces d’accès mémoire particuliers et de s’en servir comme une statistique de consomation en DPA.

Du coup, c’est du Differential Computing Analysis, comme si on avait décapé la puce crypto pour observer des zones particulières avec des probe, sauf que là c’est plus simple. En 1h et 36 traces, les orateurs ont réussi à récupérer la clef de l’implémentation white-box de Chow.

Bon, ça ne fonctionne pas sur toutes les White-Box. mais ces White-box sont attaquable de manière « académique ».

Windows Error Reporting

WER c’est le remplaçant de drWatson qui va générer les crashreport pour les applications windows qui plantent. Ce rapport est envoyé à Microsoft. L’api de WER est assez simple, et contiens plein de fonctions pour générer un rapport avec les pièces jointes qui vont bien.  Lorsqu’une application cesse de répondre au bout de 5sec, un rapport est généré. Lorsqu’il s’agit d’un crash kernel, le bsod génère un crashdump qui est en suite utilisé pour générer un rapport au reboot du système.

L’objectif de microsoft derrière ça, c’est de corriger les bugs qui impactent le plus les utilisateurs. Ces rapports peuvent être aussi utile pour identifier les 0-days. Pour les SI soucieux de leur sécurité, il est possible de mettre en place un serveur de collecte de crash, et ainsi on peut filtrer les crash à remonter à Microsoft, et s’en servir comme outil de surveillance du SI.  Il est possible de modifier le comportement du collecteur WER créé par l’orateur pour obtenir beaucoup plus d’information dans les crashreports, ce qui facilitera le travail d’analyse par la suite.

Bypassing DMA remapping with DMA

(comme disent les gamers: AFK Bio …).
//YOLO
//END YOLO

Les iommu ne sont pas toujours utilisés systématiquement en dehors des contextes de virtualisation. Il est possible de faire du contrôle d’accès montant sur les host bridge, et c’est un bit à changer dans le firmware (bon faut le patcher, galère). Sinon l’autre solution contre les attaques DMA c’est Intel TxT. mais c’est super-propriétaire comme tool et ya des vulns dedans. Bref, c’est pas gagner de se protéger contre les attaques DMA.

Scapy en 15 minutes

depuis 2012 on essaye de parler dans le micro et de faire des releases régulières, ya une doc scapy maintenant. Si vous ne connaissez pas Scapy c’est bon mangez en !
Scapy est un outil de manipulation de paquets, on décrits  la structure du paquet avec ses différents layer, et ses champs et scapy génère le paquet correspondant. Scapy supporte Ipython, et on peut s’en servir pour faire des plot, et grapher de l’information sur des paquets. Il y a un mode « show » qui permet de visualiser le paquet graphiquement. la fonction world_trace() permet de situer sur une carte les résultat de votre traceroute. Dans scapy, il existe une streamsocket qui mange une socket ouverte (mange ta chaussette) et vers laquelle on va pouvoir pousser des paquets scapy.

Les automates dans scapy, ça permet d’avoir de vrais piles réseau avec des clients et des serveurs TCP, FTP etc… La fonction graph() dans scapy permet de visualiser votre graph pendant votre dev d’automate. Les pipes vont bientôt etre intégrés dans scapy pour transférer des paquets d’une interface à une autre.

Le support ASN1 et des certificats X509 arrive, pour faire de la re-génération de certificats et de signatures avec scapy (mitm facile avec scapy ?).  Bref plein de nouveaux trucs. Et la perf c’est améliorée.

Plaso & Timesketch

Présentation Digital Forensic. Plaso, en finlandais ça veut dire en gros « attrapez les tous ». Plaso est un outil de génération de timeline ou on met en entrée plein de logs, et avec les timestamps il génère une méga-timeline. Avec psort.py vous sortez votre super-timeline et vous pipez ça dans egrep pour filtrer par l’item qui vous intéresse.

Log2timeline.py ça mange de tout, du raw, du dd, du encase, si c’est bitlocké il vous demande la clef bref c’est sympa. Ya un système de worker pour répartir un peu le taff dans votre serveur d’analyse, et un système de feedback-loop qui permet de faire de l’exploration récursive des filesystem, archives etc… Pendant que les workers font leur analyse, il y a des plugins dans log2timeline pour pousser des hash sur VT.  Une fois la timeline générée vous pouvez la sortir dans tout plein de formats.

Plaso est dispo pour linux, mac, windows.

Timesketch se base sur Elasticsearch qui permet d’annoter des Events, d’avoir plusieurs systèmes sur une timeline ou de faire de l’analyse collaborative. Pour l’utiliser on claque la sortie de psort vers timesketch et c’est parti. Les recherches spécifiques effectués peuvent être sauvegardés et transféré aux collègues. Pour la démo c’est sur https://demo.timesketch.org/ demo/demo.

Graphes de dépendances : Petit Poucet style

Angr.io : Framework pour l’analyse de binaire avec un moteur d’exécution symbolique, comme miasm sauf que les auteurs savent à quoi ressemble du powerPC. L’algo implémenté s’appelle le BackwardSlice. Ce type d’algo reproduit ce que fait un analyste lorsqu’il fait l’ingénierie à rebours d’une fonction qui l’intéresse pour comprendre comment elle est appelée. Le problème de ce type d’algo, c’est qu’il retrouve un sur-ensemble des éléments influent sur les valeurs d’appel de la fonction. Du coup Angr à un autre algo pour venir réduire cet ensemble. Bon, c’est pas forcément optimum et en plus ça gère pas les boucles.

Dans MEtasm, il y a un algo de backtracking avec un seul passage dans chaque boucle. Cet algo est capable d’identifié s’il à sous-estimé la solution. Du coup les orateurs nous présentent (rapidement) un algo dans miasm qui permet de résoude ce problème d’identification des variables dont dépend l’appel de la fonction.

L’algo permet de résoudre ce problème d’analyse de dépendance et de générer le Graphe des dépendances de l’appel de la fonction (ou de la valeur du registre) sous la forme d’un script IDA dans Miasm. L’algorithme est limité par les alias et les pointeurs de pile non-résolus.

Conférence de clôture

 Equipe INRIA Prosecco.
Breaking & Fixing TLS. L’orateur fait partie de l’équipe Prosecco et à participé au développement d’une pile TLS prouvée. La vérification de protocoles cryptographique demande beaucoup d’efforts, et ils sont nécessaire pour la sécurité et la vie-privée des utilisateurs de nombreuses applications. Du coup soit on arrive à prouver que l’implémentation est failsafe, soit on découvre des vulnérabiliés aux impacts variés.  Les banques par exemple dépendent de canaux d’échanges sécurisés pour les authentifications fortes. On pense souvent que ce problème est résolu depuis longtemps, mais en fait non. Https c’est fait défoncer en boucle depuis les 5 dernières années, notamment via des attaques ciblant TLS et ses implémentations.

Comment faire pour empêcher les « chercheurs » en sécurité de sortir autant de failles avec des logos hypes ? Il faut que les developpements protocolaires soient plus agiles pour commencer. Qu’on puisse modifier les composantes des protocles crypto: fonctions de hashage, de dérivation de clef, etc… afin de suivre les évolutions de ces algorithmes et d’éviter les failles de leurs versions antérieures.

TLS date de 94, et à connu de nombreuses versions. Chaque année on à le droit à un lot de bugs, de patchs et de nouvelles attaques. Bien entendu, il existe des petits bouts de TLS prouvés et propres, mais ils ne sont pas déployés, et ils ne couvrent pas tout le protocole.

L’orateur nous fait en suite un rappel sur le fonctionnement du protocole TLS.  En fait, TLS c’est un framework cryptographique qui spécifie chaque phase de l’établissement de la session. Mais dans ce framework on peut plugguer diverses versions d’algo permettant d’implémenter chaque phase. Mais comment peut on s’assurer de la sécurité de l’ensemble face à une si grande diversité ? Et comment faire pour que le client et le serveur soient capable de communiquer sachant qu’ils ne disposent pas tous des mêmes algo pour discuter. Du coup il faut bien entendu implémenter une machine à état pour gérer les algorithmes.

L’orateur à donc travaillé à l’implémentation d’une machine à état complète qui a mené a un fuzzer nommé FlexTLS (présenté l’an dernier à SSTIC) et qui permet de fuzzer la machine à état d’OpenSSL et d’observer les transitions possibles entre tout les algos qui peuvent composer l’implémentation et de découvrir des chemins anormaux menant à de possibles failles de sécurité.

Du coup on peut se retrouver avec des situations à la con sur certaines implémentations ou on ne fait même pas d’échange de clefs et on se retrouve dans un protocole zarbi qui n’est pas TLS… et donc pas sûr. Bien entendu tout les bugs découverts ainsi ne sont pas exploitables, mais ça reste un vrai problème pour la sécurité. (ok… c’est l’hypervitesse version anglais: hyperspeed, merci de me corriger si je dit des conneries).

Exemple d’attaque en abandonnant certains messages (SKIP) qui finissent par un envoi non chiffré à la fin.

Bon on voit bien que c’est la merde, du coup ça serais pas mal d’utiliser des langages formels et quelques outils de validation logicielle solides comme F*, Frama-C etc… histoire d’avoir une implémentation de TLS qui tien la route. C’est ce que fait miTLS, une implémentation TLS de référence qui a le bon goût d’être vérifiée formellement.

Le truc marrant, c’est qu’en travaillant sur ces preuves, les créateurs de miTLS on découvert de nouvelles attaques (SMAK, SKIP, FREAK , Sloth, Logjam). Exemple avec l’algo SIGMA qui permet d’éviter la plupart des attaques MITM. La sécurité de cette solution algorithmique est mise en défaut par des implémentations qui se veulent rétro-compatibles, ou qui font des pré-suppositions pour gagner du temps ce qui donne la vulnérabilité Logjam. Et la c’est la fin de la sécurité du Diffie Hellman qui se retrouve cassable.  Autre exemples avec les attaques pré-calculés avec des histoires de groupes choisis qui font que TLS casse vite (dans certaines conditions), et la NSA le savait et forçait ces groupes pourris dans les versions exportés des implémentations US.

Fonctionnement de SLOTH

Conclusion: il faut de la preuve et utiliser TLS1.3 🙂