SSTIC 2018 - J3

Social facile, réveil difficile 😉

Edit: retours & blogs du SSTIC sur:

• le comptoir sécu
• @xme: J1, J2, J3

A practical guide to DPA

Milenage est un algo qui sert à dériver les authentifiants dans les cartes SIM. C’est grâce à ca que le téléphone peut s’authentifier sur le réseau de l’opérateur. Si un attaquant peut faire cracher ses secrets à la puce, l’atteinte en confidentialité est énorme pour l’utilisateur. Pour ce faire on peut effectuer une analyse des variations de consomation sur certaines pattes de la puce à l’aide d’un oscilloscope. On identifie alors les phases d’exécution de l’algorithme. On part de traces de références qui ne sont pas toujours très propre car l’horloge de la carte n’est pas super précise. On doit alors ré-aligner les pics afin d’avoir une base de comparaison propre. Sur la base de l’hypothèse que la donnée influe sur la consommation. Il faut un très grand nombre de traces pour valider l’hypothèse. L’attaque se fait avec un oscilloscope a 400€, et des scripts python NumPy.

Starve for Erlang cookies to gain remote code execution

Rappels sur le fonctionnement de la vm Erlang, faite pour partager des messages entre les process tournant dans des vm séparées. Ces échanges se font sur TCP/IP. L’Epmd indique à la vm sur quel port un process écoute. Une authentification mutuelle se fait par un challenge-response basé sur le Cookie Erlang. Une fois le canal établi, des messages sérialisés sont échangés. Le problème c’est que ce canal n’est pas protégé en intégrité. RabbitMQ est facile à identifier avec nmap et le script epmd-info. Pour eJabberd, l’orateur à codé un script NSE spécifique. CouchDB n’expose pas de service par défaut. Les cookies Erlang font 20 lettres majuscules, ça ne se bruteforce pas comme ça. Sauf que la graine utilisée ne fait que 64bits. L’état interne du prng fait 36 bits ce qui rend la génération de cookie bruteforçable.

Dans la conf RabbitMQ, le cookie_hash est un hash en base64 du cookie Erlang, facilement récupérable par bruteforce. La distribution des graines n’est pas cryptographiquement bonne sur RabbitMQ. L’intervale fait pas plus de 2^26bits, bah ça défonce.

Une fois le cookie trouvé, on à une RCE sur la VM Erlang. Du coup la distribution Erlang doit être faite en utilisant SSL, et par défaut RabbitMQ n’est pas sécurisé. Pour se protéger, il faut mettre du TLS sur la distribution des messages, remplacer le cookie généré par le votre.

HACL: une bibliothèque crypto formellement vérifiée

(ouch) Bon, on ne peut pas tout vérifier avec du fuzzing sur une lib crypto, du coup les orateurs sont partis sur les approches formelles. Pour coder des fonctions crypto, on peut soit faire de l’ASM, soit faire du C, soit utiliser un langage avec preuve intégrée mais c’est pas performant. Les orateurs ont donc choisi de créer une nouvelle lib crypto écrite en F* (https://github.com/mitls/hacl-star). La lib est toute petite mais elle implémente l’API de NaCL et une suite TLS 1.3. Comme c’est du F* la preuve est « offerte ». F* ça ressemble à OCaml avec des types plus riches et la possibilité d’ajouter des annotations pour exprimer ce qu’on espère que ça fera, et les backend de preuves viennent vérifier tout ça. Une fois le code F* propre, il faut générer du C clean. Pour se faire les orateurs ont choisi un sous-ensemble de F* nommé Low* et qui permet de générer un C prouvé. La compile de Low* vers C se fait par un compilateur C vérifié. Le code C à été validé à la main en // de la preuve automatique. Côté perfs ça poutre, mais en prime c’est passé par des méthodes formelles (j’suis en PLS là…).

WireGuard: next generation secure network tunnel

Jason Donenfeld – zx2c4 – Il voulait faire un VPN qui permet d’éviter tous les éceuils qu’on peut connaitre avec IPSeC, OpenVPN, etc… WireGuard est un vpn niveau 3 pour IPv4 & v6 conçu pour être builtin dans le kernel linux. Basé sur UDP pour passer les NAT et autre trucs, et qui utilise de la crypto classique & nouvelle, mais pas de truc trop exotiques. Le projet se veut super simple et auditable. L’échange de clefs est sorti du projet, mais son modèle d’authent est très similaire aux authorized_keys d’SSH. (https://www.wireguard.com/)

WireGuard ne fait que 3771Loc, contrairement aux projets comme OpenVPN ou StrongSwan qui dépassent allègrement les 100kLoC. Ce qui simplifie grandement l’audit de code. WireGuard apparaît comme une interface traditionnelle, et tout ce qui marche « classiquement » avec une interface réseau classique marche avec WireGuard. Au lieu de galérer comme en IPSec avec une table de routage de la mort, l’orateur est parti sur l’utilisation simple d’une interface réseau « standard ».

Le routage se fait en fonction de la clef crypto associée à l’interface. Chaque pair dans le réseau wireguard est identifié par sa clef publique. On à donc une relation 1:1 entre l’IP dans le vpn et la clef associée à l’interface réseau. Côté client on peut choisir quels sont les réseau « atteignables » dans la conf. Le routage est fait dans la table du kernel linux.

La création des clefs publique & privés se fait très simplement, et pour l’échange de clefs, on fait du copier-coller. Pour l’usage au quotidien, on peut utiliser des namespaces pour isoler les process du réseau et faire en sorte qu’il passent uniquement par Wireguard. Le fonctionnement de WireGuard est basé sur une machine à état avec des timeout, et l’évolution de cette machine se fait par les événements de réception de paquets. Concernant les suites cryptographiques, au lieu d’embarquer une tétrachié d’algo crypto, la suite est fixe, et si jamais un de ces algos casse, vous allez mettre à jour tout les noeuds, inutile de laisser des noeuds non-safe dans votre réseau. Le protocole à été vérifié à l’aide de l’outil Tamarin ( https://tamarin-prover.github.io/ ?) et assure toutes les propriétés de sécurité qu’on peut désirer sur un protocole d’échange crypto. (segfault: too much crypto).

ça sent le SAPin

Sécurité de SAP – devoteam & onapsis – SAP c’est un progiciel de gestion énooorme avec touplein de composants et de langages maisons ou pas. SAP c’est le leader mondial des ERP, et la boite existe depuis 46 ans. 72% des bières du monde sont produites par des entreprises utilisant SAP, c’est presque un OIV. L’application s’utilise au travers d’un client lourd appellé SAP Gui, qui cause avec un ABAP Dispatcher qui répartis la charge sur des WorkProcess qui causent avec la base de données. Et ça expose une tétrachié de services, du coup le Nmap il pique un peu.

Le service SAP est identifié par 3 lettres,  les admins sont identifiés par le trigramme adm. l’ABAP est le langage de programmation de SAP et il est stocké dans la BDD. Un report c’est un programe ABAP. Une transaction, c’est un alias qui lance un ensemble de Report. Les services SAP tournent sur sidadm, il n’y a pas d’isolation de privilèges et si vous le pétez c’est game over. Le kernel SAP c’est un gros tas de binaires qui tournent sur l’OS. Le source ABAP dans la base de données pour s’abstraire des OS. Du coup tout le code du système SAP est accessible, donc auditable. L’installation d’un système SAP implique le déploiement d’un environnement de dev complet.

Le SAP GS: Internet Graphics SErvices, est là pour générer des images, des graphiques, des fichiers zip, etc… Comme aucune CVE n’a été publiée sur le SAP IGS, les orateurs se sont dit que personne n’avait regardé.  Quand on joue sur l’interface graphique, on découvre sur l’os la création dans /tmp/ de « sap stream » avec touplein d’infos. ces streams sont passés à des binaires  non strippé, ce qui facilite la rétroconception. En rejouant des paquets IGS sur les ports qui vont bien ,on déclenche les binaires de traitement qui vont bien.

Les orateurs ont développé pySAP a base de scapy, et du coup on peut crafter des paquets IGS pour aller déclancher les fonctions qui nous intéressent. Les orateurs ont aussi contribué à un plugin WireShark pour décoder du SAP-IGS.

Une fonction à attiré l’attention des orateurs: ADM:INSTALL, en bouffant le code ABAP, ils ont découvert une fonction SAPMAP_INSTALL_SHAPEFILES qui vérifie si les shapefiles manquent à l’IGS et s’il faut les uploader. Bon coder de l’ABAP c’est galère, mais le debugger SAP vient à la rescousse des auditeurs. En jouant avec la fonction, ils ont trouvé un moyen de créer des fichiers arbitraires sans authentification => et paf la CVE.

Dans les coulisses de la security team de debian

Par un des membres de la team sécurité Debian, et qui va présenter comment ça se gère au quotidien les vulns dans Debian. L’équipe sécu compte 10 personnes dont 5 très actifs. Ils s’appuient sur les devs des paquets debian. Ils gèrent la release d’avis de sécurité et de packages de sécurité pour patcher les vulns pour la release stable. Ils regardent aussi comment durcir la distribution. Ils ne traitent pas la partie sécurité de l’infra Debian, comptes, etc.. ni la LTS.

La communication avec l’équipe sécu se fait avec l’@ [email protected], ils ont aussi un irc. Ils ont un security-tracker qui permet de naviguer dans l’état de la distribution pour connaitre l’état courant de la sécurité de la distribution. (https://security-tracker.debian.org/). Ce tracker est un repo git ouvert, quand les vulns sont sous embargo, c’est géré sur un git privé. Une partie de la veille est automatisée pour collecter les CVE, les ajouter a la liste et vérifier si Debian est concerné ou non. (détails du process dans les slides).

Les embargos, c’est pas tjs bien, parce que les patchs sont moins relus, il y a moins de monde à bosser dessus, alors l’équipe tente de limiter au maximum le traitement des vulns de ce type car c’est plus long.  Pour krak ça s’est très bien passé, ils ont pu remonter un env pour tester la validité des patchs sur hostapd & cie. Pour meltdown & spectre, l’équipe était pas dans l’embargo et n’a pas pu se préparer, du coup c’était galère.

Conclusion: l’équipe ne gère que le maintien en condition de sécurité et la gestion du tracker, et toutes les vulnérabilités ne se valent pas, d’ou les différences de traitements.

Hacking harness open-source

L’anti-forensic, c’est un objectif des attaquants type APT que tente de simuler les RED Team. Quand on regarde les outils leaké de la NSA ils ont 4 framework d’effacement de traces. L’autre solution c’est de ne pas générer de logs. « le hacking c’est un concours de boulettes, celui qui en fait le moins à gagné ». Exemple avec un shell sans TTY qui lag, source de nombreuses fautes de frappes. Ces problèmes ont été présenté par thegruq et expriment la nécessité d’avoir un « hacking harness » pour éviter ça. Démo de l’outil qui prévient le pentesteur lorsqu’il oublie de proxifier une commande.

Le hacking harness, c’est un shell augmenté pour automatiser les tâches ordinaires du pentest, avec le comfort d’un TTY. C’est facile à scripter pour que chacun puisse adapter ses méthodes de travail au harness, plutôt que d’avoir à se conformer au workflow d’un autre.  Autre intérêt, toute l’intelligence est sur la machine du pentesteur/redteamer. La ligne de commande est gérée en local jusqu’à-ce que l’utilisateur fasse entrée pour l’envoyer au travers du shell. ( https://github.com/JusticeRage/FFM )

DNS Single point of failure

Un resolver DNS chez un FAI reçoit les requêtes DNS, et va en suite demander aux serveurs racines, mettre en cache les infos et voila. C’est le cas autoroute, et ça se passe bien parceque les serveurs racines contiennent toutes les infos. Dans la pratique, parfois, il n’y a pas toutes les informations nécessaires, et dans ce cas on rajoute de la glue. Sans glue, ça demande au resolver DNS de dérouler l’ensemble de la chaîne jusqu’a trouver le bon serveur DNS. Le soucis c’est que 99% des resolveurs n’utilisent pas la Glue, et du coup ça génère bcp de traffic. La bonne nouvelle c’est qu’actuellement, le nombre de serveurs qui contrôlent les TLD est assez compact et ça se passe bien. Bon la glue c’est pas forcément simple à maintenir, parce qu’il faut mettre à jour cette glue.

Bon la délégation sans glue ça bouffe de la perf, et en prime ça pose un problème d’intégrité si les serveurs les plus fréquemment requêtés sont détournés. Du coup on peut se poser la question de quels serveurs sur ces chemins de résolutions représentent un point de passage obligé dans la résolution d’un grand nombre de noms de domaines.

Des IP qui tombent c’est fréquent, DDoS, fausse manip, oups. Un préfixe réseau peut être mal annoncé et foutre le boxon, plus rarement les AS peuvent tomber. Autre élément de risque, quand un nom de domaine devient non-disponible à cause d’un DDoS, d’une zone tronquée, couac DNSSEC parce que c’est compliqué, de l’interruption administrative, bref. ça arrive !

Là ou ça devient critique, c’est si un de ces événement surviens sur un serveur DNS qui s’avère être un SPOF, ou lorsqu’on à un effondrement par dépendances transitives. Bon parfois on peut avoir des dépendances circulaires, et ça peut mal finir.

C’est galère à analyser à la main, du coup l’orateur à développé un outil nommé transdep ( github.com/X-Cli/transdep ) en Go et qui marche un peu comme un resolver. Il va aller crawler plein de donnés DNS pour construire ce graph de dépendances entre domaines.

Tout nom de domaine est dépendant de ses parents, tout le reste est évitable. Quand on regarde bien, il y a un très grand nombre de noms de domaines qui dépendent d’élément « évitables » et qui sont donc exposés à un SPOF.

Pour éviter ces problèmes, il faut suivre les bonnes pratiques du guide de l’ANSSI.