SSTIC 2018 - J3

Social facile, rĂ©veil difficile 😉

Edit: retours & blogs du SSTIC sur:

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.