SSTIC 2023 - J1

20 ans de SSTIC ! ça ne nous rajeunit pas…

15 years of oss-security @solardiz

L’orateur est l’un des premiers à publier sur le re15 years of oss-security @solardizturn-into-libc et un des contributeurs à John the ripper, et le fondateur de la communauté openwall.

Le vulnerability disclosure à fait un gros chemin depuis les années 80 et les mailinglist usenet net.unix-wizards. Le disclosure était coordonné par des volontaires qui servait d’intermédiaire entre les revendeurs de distributions linux et ceux qui découvrait des vulnérabilités. Il fallait parfois préserver l’anonymat du chercheur pour lui éviter des mésaventures avec les services juridiques des sociétés concernés par la vuln.

La problématique de disclosure d’une vuln et un vieux problème qu’ont déjà rencontré les serruriers au 19ème siècle. La communauté à progressivement migré du non-disclosure à la divulgation « responsable », porteuse d’un jugement moral à géométrie variable, pour finir par n’être que des bugs à corriger.

L’essentiel de la communication se faisait sur des mailing-listes fermées où ouvertes, avec des guidelines sur quels sujets peuvent être abordés ou non. Les mailing-listes publiques pouvaient être rejointes par n’importe qui, et faisait parfois l’objet d’une modération ou non. oss-security était plus rapide à la modération que Bugtraq, et heureusement il y avait très peut d’off-topic. Pendant une période limitée, il était possible de réclamer un n° de CVE via oss-security, ce qui a eu pour conséquence un accroissement des échanges.

Le timing du disclosure était parfois très court, parfois les chercheurs était très patients, voir n’en avait rien a faire du délai pris par le fix. L’approche des dev varie concernant la mise à disposition d’un patch conjointement à une alerte. Certains projets préfèrent faire précéder le patch d’une alerte de sécurité, et le disclosure à lieu après la mise à disposition du patch. D’autres corrigent la vulnérabilité silencieusement, sans alerte de sécurité. Dans ce cas il est possible que la vulnérabilité soit inférée des patchs, laissant les utilisateurs dans l’ignorance.

Openwall à tourné endant 15 ans sans financement, en se basant à 100% sur le bénévolat. Mais indirectement, les entreprises qui laissent leurs employés contribuer à l’effort de traitement des message et de suivis des vulns d’openwall fournissent une forme de soutien indirect.

Bien que corriger des bugs soit important, la réduction de la surface d’attaque et la défense en profondeur sont plus impactants sur la sécurté globale des systêmes d’information. L’orateur à observé une amélioration significative de la qualité des rappports de bug userland.

From dusk till dawn: toward an effective trusted UI

Les orateurs sont de la société Ledger, et leur taff c’est de sécuriser des clefs privés de portefeuilles crypto. Une TUI, trusted user interface, est un ensemble hard/soft permettant à l’utilisateur d’interagir avec la solution de façon sûre. C’est un vieux problème connu du monde bancaire ou de la sécurité physique. L’idée c’est d’éviter le skimming, ou toute interception de l’interaction entre l’utilisateur et le composant de sécurité.

La TUI est implémentée dans un Trustend Execution Environment, un processeur avec une zone d’exec sécurisée, mais elle doit partager des périphériques avec du code non-trusté qui s’exécute dans l’environnement « standard ». Parfois sur des composants sur étagère, certaines lignes d’alimentation électrique peuvent être partagées entre code trusté et code non-trusté provoquant des fuites d’information (les fameux canaux auxiliaires).

Les orateurs sont parti sur une conception hardware maison dédiée pour répondre à leur besoin. Clavier/Ecran c’est des protocoles lents et simples à attaquer. Un Secure Element, enclave sécurisée contenant les clefs, n’a pas le CPU pour dessiner des interfaces graphiques. Mais il peut demander des composants types à afficher. L’idée c’est de placer un CPU trusté pour gérer l’UI qui traduira les commandes du Secure Element en interface. Pour l’affichage, les orateurs passent par l’interface drm_ du noyau linux. Lorsque l’utilisateur doit interragir avec le TUI, le système d’exploitation n’a plus la main sur l’interface et ne reçoit plus d’inputs. Seul les périphériques cablés sur le TUI peuvent fonctionner, et le reste des sources d’inputs de l’OS sont ignorés.

Le PoC fonctionne et la performance graphique n’est pas impactée par l’insertion de la TUI entre l’OS et l’écran tactile.

Ultrablue: Attestation distante sur Bluetooth

Le cas d’usage: s’assurer que la machine n’a pas été modifiée induement (evil-maid attack n’ co). Pour cela on s’appuie sur une chaîne de démarrage « trustée » qui vous alertera si jamais les composant du boot ont été modifiés avant de saissir la passphrase du disque dur. Pour ça on utilise un TPM. Bon pour que ça marche, il faut pouvoir disposer d’un serveur d’attestation. Ultrablue sert de serveur d’attestation accessible en bluetooth qu’on exécute sur un smartphone. Le code est sur Github.

GMSAD

Un outil pour utiliser les comptes gMSA Active Directory sous linux. L’authentification kerberos pour les serices nécessite le partage d’un secret Kerberos. On connait bien les comptes de services avec un SPN qui fini kerberoasté parceque l’admin à choisis un mdp pourri. Dans le cas d’un load-balancing, on utilise un compte gMSA. Les machines qui ont besoin du mdp du compte gMSA vont le récupérer via des requêtes LDAP chiffrés. Le mot de passe est stocké dans un blob binaire avec le vieux mdp, et le mdp courrant.

La documentation MS étant limité sur cette structure, les orateurs ont observé comment cette dernière évoluait dans le temps. Après expérimentation, les orateurs observent que le mot de passe du gMSA ne change pas entre deux tests. A partir de UnchangedPassword ils peuvent récupérer le futur nouveau mot de passe, pour éviter un fail a l’authent avant le changement effectif de mot de passe.

Les orateurs on dev un script python pour gérer la récupération du mot de passe gMSA et l’ont publié sur Github. L’outil est aussi utilisable en Pentest pour bidouiller les keytab.

OpenWEC

La collecte de logs Windows peut se faire soit via l’installation d’un agent de collecte locale type winlogbeat. L’autre approche et d’utilsier l’agent WEF pour pousser les logs vers un collecteur WEC. Le protocôle WEF est une surcouche à WSMAN, soit du SOAP over HTTPs.

La collecte fonctionne soit en push, soit en pull. Les orateurs se sont concentré sur la méthode push, ou le forwarder vient pousser ses logs vers le WEC. Le WEC ne permet pas la redondance by design.

Le client WEF utilise un header kerberos pour l’authentification. Les données sont chiffrées, et peuvent être déchiffrées avec une keytab dans WireShark. Dans le protocole WEF, il y a la notion de bookmark, un pointeur qui permet de s’assurer qu’on ne perde pas de logs. C’est le serveur qui va causer avec le client pour lui demander de lui renvoyer les logs depuis le dernier bookmark.

La solution est codée en RUST et permet un fonctionnement en équilibrage de charge. Elle permet une sortie fichiers en JSON ou en XML, et une sortie TCP pour ballancer les logs dans un Splunk.

Supply Chain Attack sur Suricata

Suricata est une sonde de détection réseau multi-fonctions à grande vitesse. Landlock est un outil de sandboxing userland sans configuration. Pour ce faire, l’application doit causer avec Landlock pour lui expliquer ou elle va écrire des fichiers, et où elle va écrire. Cela nécessite une modification de l’application pour qu’elle soit capable d’exprimer ses besoins en lecture & écriture.

Suricata permet en plus de la gestion de règles basés sur des patterns réseau, de prendre en charge des listes d’IoC par protocole, tel que les IP, noms de domaines, etc… Le problème c’est que sur la base d’une règle de détection basée sur un dataset permet d’écraser le contenu d’un fichier, ou de sauvegarder les sorties d’une détection dans un fichier arbitraire. Le support lua de Suricata permet de lancer un script au moment de la détection. Ce code peut être mis dans les signatures. Le risque porte alors sur les sources de signatures qui pourrait être compromises.

Du coup ce passage du modèle du SOC qui crée ses règles vers l’achat de règles à un fournisseur tiers expose le SI à une attaque de type supply chain via l’éditeur des règles. Il faut donc prendre garde lorsqu’on récupère des règles Suricata, et contrôler les règles contenant du LUA ou des Datasets.

Comment anticiper la menace, l’exemple de Mustang Panda.

ANSSI/SDO/DCA – Pour analyse la menace, il faut essayer de la comrendre. Une menace à des capacités au service d’intentions qui viennent à saisir des opportunités pour mener à bien leurs objectifs.

En Threat Intel, on va pouvoir se baser sur des bases de connaissances internes issues d’incidents, de rapports externes issue d’éditeurs d’AV ou autre, et de bases OSINT type shodan & cie.

Dans le modèle STIX on distingue le Threat Actor des Intrusion Set, c’est à dire des ensemble de campagnes menés avec un ensemble de techniques donnéees.

Mustang Panda est un MOA réputé d’origine chinoise en source ouverte ciblant des entités gouvernementales en europe. Ses TTP consistent en un mail de phishing avec un lien dropbox ou autre qui contient une archive avec un LNK qui se fait passer pour un document qui va finir par déclencher un DLL SideLoading et charger un PlugX.

En se concentrant sur les LNK de Mustang Panda, on retrouve des commandes similaires basés sur 7z ou WinRAR avec toujours les mêmes noms de fichiers cachés etc… et les métadonnées du LNK sont toujours les mêmes. On va donc pouvoir hunter avec une Yara ces LNK et les retrouver dans différentes bases.

L’infra de C2 de PlugX de Mustang Panda communiquent avec une infrastructure qui semblent propre à ce MOA avec le même certificat TLS avec une OU symilaire. En suivant ça dans le temps, on peut découvrir de nouveaux serveurs.

Randomness of random in Cisco ASA

Analyse de la génération d’aléas des firewall cisco ASA. Lors de leur tests de leur parser X-509, ils ont découvert 82k certificats avec des nonces ré-utilisés qui provennait de matériel Cisco.

Ecdsa est vulnérable si jamais le nonce est ré-utilisé, permettant à l’attaquant de récupérer la clef privée. Une fois la clef privée récupérée, on peut faire tomber toute les clefs et bye bye la confidentialité. Ce problème de nonce-reuse à donné lieu à pas mal de vulnérabilités dont la compromission des clefs privés de la PS3.

Les orateurs ont donc récupéré une appliance matérielle et une vm. Ils ont reset l’appliance et récupéré les certificats en boucle et ont pu mettre en exergue la présence de ce problème de ré-utilisation de nonce.

Avec les appliances virtuelles, on a accès au système. Par contre dedans on trouve des gros binaires de 180Mo avec des sécurités. NCC Group à publié des outils pour injecter un gdb dans ces vm et désactiver les contrôles de sécurité ce qui permet de débug l’appliance. Avec cette instrumentation, il est possible d’orchestrer le redémarrage et la config du firmware pour dumper les certificats.Le problème c’est que gdb et l’asrl perturbent la génération de l’aléa. Les orateur on donc du instrumenter l’appliance via QEMU.

Les sources d’aléa contiennent des sources pourries et des sources de qualité. Tout ça part dans de l’algo compliquée. Cette graine sert en suite à un RNG déterministe dont la qualité dépend de la source d’entropie. Et la génération de clefs repose sur se RNG. Quand une plateforme cisco démarre, elle lance un RNG et lui demande des octets. Certains de ces octets partent dans le module de génération RSA, puis de clefs ECDSA pour les certificats, et enfin un nonce issue de deux tirages de la BSAFE. BSAFE dépend du CTR-DRBG et de son démarrage dépend de 32 bits de RDTSC.

Comme le random de ces fonctions est « rafraichi » à partir d’une quantité de random beaucoup trop faible, et trop fortement dérivés qui finie par dégrader la sécurité de la crypto.

Exploring OpenSSL Engines to Smash Cryptography

La migration oblige parfois de supporter du legacy. Pour se faire, il faut modifier des portions de crypto petit à petit afin de ne pas tout révolutionner et de ne pas casser les chaînes de confiance existante. Soit vous poussez des patchs, soit vous utilisez les « engines » OpenSSL. Il exist des « engine » post-quantiques publiés par des académiques. D’autres les utilisent pour augmenter les capacités d’OpenSSL, ou bien d’y adjoindre des accélérateurs.

OpenSSL, c’est des applications cryptographiques, une lib crypto, une CLI et des Engines qui peuvent modifier les fonctions de libcrypto via une API.

Les orateurs ont ensuite implémenté un Engine OpenSSL malicieux qui fait de la ré-utilisation de nonce, mettant en péril la confidentialité de la clef privée.

CRY ME: un challenge crypto sur une messagerie.

CRY.ME est une application de messagerie cryptographique contenant des vulnérabilités volontaires utilisée pour un challenge inter-CESTI. Il s’agit d’un outil pédagogique sur les failles crypto.

Les orateurs sont parti d’Element, et y ont ajouté pas mal de vulns. L’appli est disponible sur Github

TurboTLS

TLS c’est l’application crypto la plus connue, puisqu’elle sert de base à HTTPS et toutes les versions « sécurisés » des protocoles TCP classiques passées « over SSL » pour en garantire l’intégrité et la confidentialité.

Du coup quand un navigateur charge des ressources over SSL, il va devoir faire plein de handshakes TLS, ce qui à un impact sur les performances. Forcément quand on fait de la crypto post-quantique, ça fait des opérations plus longues et donc des délais de handshakes plus longs. TCP c’est déjà très optimisé.

TurboTLS fait le handshake over UDP tandit que les échanges se font sur TCP quand la connexion est établie. Au pire si UDP passe pas on peut re-basculer sur TCP. Le temps que TCP fasse son handshake, le handshake crypto over UDP est terminé.

TurboTLS peut être identifé par un Flag DNS supporté par Chrome et Bientôt Firefox.

Construction et analyse de passe-partout biométriques.

La biométrie, c’est des caractéristiques physiologiques comme l’empreinte digitale, le visage ou la dynamique d’une signature. Une capture biométrique à de la variabilité, et c’est une donnée sensible à caractère personnel. La génération d’une signature biométrique produit un vecteur de caractéristiques à partir de l’entrée biométrique. Par exemple une empreinte sera résumée en une série de nombres.

Ces données n’étant pas modifiables à volonté, il faut les protéger. Pour ce faire le vecteur des caractéristiques est transformée en un « gabarit » soit une version plus légère de ce vecteur, ce qui détruit de l’information, et ne permet théoriquement pas de remonter à l’empreinte.

La construction d’un passe-partout c’est la génération d’un gabarit qui match sur plusieurs empreintes différentes. Sur une base d’utilisateurs, on peut produire une image qui correspondrait à une empreinte universelle permettant d’usurper l’empreinte de tous les utilisateurs de la base.

Batterie à bord: quand les jauges de carburant dépassent les limites

Dans les périphériques embarqués, la gestion de l’énergie et l’autonomie c’est le nerf de la guerre. On fait souvent ça en regardant la tension aux bornes de la batterie. Cependant la température, l’age de la batterie, la dernière charge extraite et la qualité du lithium joue sur son autonomie et sa durée de vie. Ajoutez à ça la sécurité du circuit de puissance pour éviter qu’elle fasse boom. Ces circuits appellé fuel-gauge ou jauge de carburant en françait sont des petits circuits qui contrôlent le cycle de vie de la batterie.

Ces circuits sont présents dans des composant haut de gamme comme les consoles portables ou les smartphones chers… Ces circuits ne sont pas très connus, et il n’y a aucun travaux sur leur sécurité. Ces capteurs sont très précis et très sensibles, à tel point qu’ils peuvent détecter le toucher d’un doigt sur une dalle tactile.

Dans le modèle de sécurité Androïd, on n’accède pas n’importe comment aux capteurs et autres composants matériels sensibles. Cet accès est géré au niveau applicatif, et dans le cas des jauges de carburants c’est via le batteryManager. La permission foreground_service permet à une application de fonctionner en continue. Lorsqu’on veut accéder à des capteurs sensibles qu’on va poller à haute fréquence, il faut des permissions supplémentaires, mais les jauges de carburant en sont exclues. Cerise sur le gateau, il existe une API JavaScript qui permet de requêter l’état de la batterie, et donc certaines valeurs de ces capteurs.

Côté attaques possible par un canal auxilliaire passant par la jauge de carburant, on peut viser la saisie du code PIN d’un utilisateur. Ce vecteur d’attaque est discret, et ne nécessite pas d’entrainement. L’attaque se base sur la consomation en temps réel de la batterie. L’application attaquante mesure la consomation, et l’application attaquée demande la saisie d’un code pin. Lorsque l’utilisateur saisie son PIN, l’animation de l’écran provoque des pics de consomation électrique.

Sur la base de ces données l’orateur est capable d’identifier des PIN probables sur la base de la consommation en fonction des distances parcourues entre les touches.