SSTIC 2019 - J1

Bon bah, c’est parti pour un nouveau SSTIC au couvent des Jacobins. L’amphi est bien rempli comme à l’habitude.

Alex Ionescu – La mort du génie logiciel

Vice-président des stratégies de détection chez Crowdstrike. Auteur de Windows Internals et reverser de Windows NT depuis 2000.

En NT4, Mark Russinovich a écrit NTCRASH qui faisait une boucle d’appel de syscall avec des 0x00 qui provoquait des crashs dans le kernel de windows, mais ça s’appellait pas un fuzzer. Avec Windows 2000, NTCRASH ne fonctionnait plus, du coup NTCRASH2 à été publié pour faire du push 0x00, push 0x01, etc… puis appel de syscall, et paf, BSOD. Microsoft a ensuite mis en place son SDLC, et l’axe à été mis sur la mitigation des exploits au lieu d’éviter de coder des soft vulnérables. Depuis une course à l’exploit s’est créée pour prouver que tel ou tel bug était exploitable, et ça a créé un marché noir des 0-days. Heureusement que maintenant il existe des programmes de bug-bounty qui ont légitimé ce travail de bug hunting et d’exploit writing, et ils ont permis de réduire le gap entre le bug et le patch.

Hélas, il y a toujours autant de vulnérabilités produites dans les logiciels. La recherche de vuln est devenu un business qui paye. Mais une grosse partie des vulns remontées sont des failles pourries, et on peut se poser la question de l’intérêt de les remonter ? De plus les profils de dev sont attirés par cet argent « facile ». Du coup ça réduit le nombre de dev compétents disponibles.

Les bugfix sont souvent priorisés plus bas que les bugs liés aux fonctionnalités. Comme il n’y a pas assez de dev dans les projets open-source. Et en plus certains devs ne veulent pas patcher parce qu’ils ont mieux à faire de leur temps libre. On claque des millions pour faire du bug bounty sur des projets open-source, mais on met pas 1ct dans le dev open-source visé par le bug bounty. Donc forcément ça ne peut pas bien finir.

Côté formation, il y a des écoles de Fuzz, ou les mecs utilisent les softs des autres et ne savent pas construire des logiciels corrects et sécurisés, mais peuvent crasher des softs pourris et sont certifiés OWASP, CISSP, MSCE et autres. Et du coup c’est les dev retraités qui vont patcher les softs !

Lorsqu’un dev produit un bout de code vuln pour le mettre dans le noyau d’un OS très très populaire, le compilateur moderne lève des alertes, mais certains dev utilisent des annotations pragma pour shunter l’analyse statique parce que ça va plus vite. Dans le SDLC on à pas mal de procédures de vérification des bouts de codes qui sont ajoutés dans le noyau et ça doit être reviewé, alors comment un bug comme ça peut être accepté et mis en prod ! Un kernel c’est pas une page Web !!! Lorsque l’orateur à découvert le bug, il a touché 10k$ et s’est payé des toilettes pour littéraliement se torcher avec cet argent…. mais est-ce qu’on pourrai pas plutôt mettre cet argent dans les developpeurs ? A force de chasser des bugs sexy, on en oublie de faire les vérifications DE BASE.

On enseigne mal le developpement logiciel aux étudiants. Quand on note les étudiants, s’ils soumettent un truc, ils ont la moyenne, si ça compile ils ont un peu plus que la moyenne, et si ça fonctionne ils ont une très bonne note. Alors ils font du printf et des strcpy et après ils deviennent developpeur chez Microsoft. Il faudrait changer le bug-bounty et payer pour le Patch, et pas pour le Bug.

Attaques side-channel sur des wallets hardware

Bon en gros, les wallet ça stock des clefs crypto pour vos bitcoins & cie. Lorsque l’utilisateur veut faire une transaction, il utilise une application sur son poste ou il prépare ses transactions, et c’est le wallet qui demande l’autorisation de valider la transaction, et ensuite la transaction part dans la blockchain.  Les orateurs se sont intéressés aux wallet Trezor qui est open-source. Comme c’est open source, le micro-contrôleur qui exécute le code est générique, et n’a donc pas accélérateur crypto ni de fonctions de sécurité hardware. Toute la crypto s’exécute en soft.

Une attaque side-channel consiste à observer les variations d’une valeur physique sur un circuit électronique tel qu’une consolation elec ou un champ magnétique. S’il y a une corrélation entre cette grandeur physique et le traitement du secret cryptographique, il y a vulnérabilité et possibilité de récupérer la clef.

A partir d’un wallet de référence, l’attaquant entraîne un classifieur pour reconnaître le PIN en fonction des valeurs des side channels. Et du coup avec 4-5 essais on peut récupérer le PIN d’un token volé.

Pour pouvoir analyser sans hardware ces codes embarqués face aux attaques par side-channel, les orateurs ont créé un outil d’émulation basé sur unicorn capable de simuler les traces de fuites qu’on enregistrerait avec un oscilloscope.

Side channel sur le chiffrement dans un chipset mobile

LEIA: un analyseur pour carte à puce

iDRACKAR

l’iDRAC est un outil de gestion de hardware de DELL, un peu comme le HP ILO4. Récemment, une vulnérabilité sur l’iDRAC à été présenté à la BlackHat. La question que se pose donc l’orateur : est-t-il possible de compromettre le système géré par l’iDRAC à partir de ce dernier ? Pour analyser le fonctionnement de l’iDRAC, on peut lire les firmwares qui ne sont pas chiffrés, ou aller sur opensource.dell.com pour lire le code source des composants GPL employé dans le serveur iDRAC.

A partir de la vuln BlackHat, on obtient un shell qu’on élève très facilement à root. Côté hardware, on a un processseur SuperH4, et quand on regarde les doc hardware, on à des composants bizarres, genre un bus de communication vidéo avec l’iDRAC en coupure entre le chipset graphique et le root pci-express. L’iDRAC embarque un CPLD, un espèce de FPGA simplifié, mais qui n’est pas connecté au PCIe. Il est utilisé pour implémenter l’émulation USB. Sur des doc internet de Lenovo, on croise un composant Renesas SH7758 présenté en tant que PBI. Dans l’iDRAC il y a l’outil pbitest qui permet d’afficher les registres de config PCIe. Ce périphérique peut émettre des requêtres DMA, ce qui signifie qu’il peut faire des accès directs à la mémoire du système. En PCIe il existe un système de routage des addresses mémoires PCIe. Et pour chaque périphérique PCIe, il y à une zone mémoire associée à chaque périphérique pour communiquer avec ce dernier. Le PBI peut communiquer avec un écran LCD qui affiche des informations en façade du serveur.

Quand on regarde le code de boot de l’iDRAC, on tombe sur un commentaire ou le développeur écrit dans un registre pour cacher le PBI afin d’éviter un bug. Lorsque le iDRAC démarre, il flash le firmware du contrôleur PCIe. Le firmware utilise le jeu d’instruction H8S d’Hitachi & Renesas. On retrouve ce jeu d’instruction dans des climatisations ou des legos. On peut communiquer avec ce chipset via des commandes iDRAC.

L’orateur ne sait pas si on peut accéder à la RAM depuis un iDRAC compromis, mais ça ne sent pas bon du tout, et le CERT-FR recommande de ne PAS connecter à internet ses iDRAC.

WEN ETA JB

Avec les nouveaux chipsets ARM est arrivée la solution PAC: Pointer Authentication Code, qui va signer cryptographiquement les pointeurs « dangeureux » pour éviter qu’ils soient modifiés. Cette solution est « sensible au contexte », et du coup d’un contexte d’exécution à l’autre, la signature peut être différente. (gestion du changement de contexte ?). Du coup sur des chip > A12, le ROP est mort à moins de pouvoir signer des pointeurs. On peut faire de la substitution de contexte, si les pointeurs sont signés avec un contexte null. PAC remplace progressivement la GigaCage.

Pour l’élévation de privilèges, on va cibler les daemons utilisateurs, le kernel, et ses extensions. Par contre avec la généralisation du sandboxing, les applications ont accès à de moins en moins de surface d’attaque. La sandbox KEXT est basée sur le framework MACF hérité de TrustedBSD. La sandbox hook les syscall pour vérifier que l’application à le droit ou pas d’effectuer une action.  La signature de code est activée par défaut, et sert à donner les autorisations à la sandbox. C’est un module kernel qui effectue la vérification des autorisations sur la base de la signature. Soit il s’agit d’une signature Apple, soit c’est une signature de Dev. Le daemon chargé de valider les signatures était avant Trusted dans le kernel. Maintenant il y a CoreTrust qui vient vérifier que le binaire est bien signé comme il faut AVANT exécution.

Pour limiter l’exploitation de daemon user-land, on a les classiques nx, aslr & cie, et en plus le système des platform binaries qui empéchent l’exécution de librairies arbitraires. En prime il y a PAC qui tue le ROP, il faut donc faire du JOP (Jump Oriented Programming) pour exécuter du code arbitrairement. PAC est réservé aux binaires Apple, et donc c’est plus compliqué d’attaquer un daemon depuis une appli classique que depuis une appli Apple qui peut signer des pointeurs avec PAC.

L’attaque du noyau et des extensions du noyau (KEXT) permettent une élévation immédiate, mais tout ratage provoque un crash du téléphone. Du coup Apple à rajouté des protections Kernel pour empêcher l’écriture sur des ensembles de pages mémoires. Du coup même avec un RW arbitraire, comme on ne peut pas créer de pages mémoires arbitraires pour exécuter du code Kernel. Les attaquants sont donc obligés de se contenter d’attaques « data-only ». Dans les SOC A12, Apple à ajouté une protection contre ça. (Plus d’informations dans les actes, si j’ai écrit des conneries corrigez-moi en commentaire, j’intégrerais les pull-requests)

Attaques sur un HSM

Les Hardware Security Modules, sont souvent utilisés dans les autorités de certifications ou les PKI pour la génération des clefs crypto. Les orateurs ont étudié un HSM sous la forme d’une carte PCIe. Ces cartes sont protégés physiquement par une grosse couche Epoxy. On y découvre un slot pour un connecteur Ethernet, qu’il suffira de souder pour obtenir un équivalent de la version réseau. Le HSM s’installe sur n’importe quel hôte, et on communique avec la carte PCIe via le SDK fourni avec.

Le HSM est livré avec un firmware de mise à jour signé, mais en clair. C’est un Linux PowerPC pas vraiment à jour.  Pour causer avec le HSM, on utilise une API Cryptographic Token Interface documentée avec pas beaucoup de fonctions. Par contre ces fonctions prennent en paramètre des mécanismes crypto qui eux sont très très très nombreux, et qui offrent donc une surface d’attaque plus grande.

L’API manipule des données à l’aide de Handles, et les données ne seront jamais copiés côté client. Le client doit donc utiliser ces Handle pour désigner les clefs crypto à employer, etc… Les données peuvent être marquées comme privées et comme non-extractible pour éviter l’accès non-authentifié aux données privées, et l’extraction des secrets cryptographiques tels que les clefs privées.

Les orateurs partent du principe que l’attaquant à accès au serveur contenant le HSM et qu’ils ont le plus haut niveau de privilèges dessus. Les HSM supportent aussi des modules personnalisés qu’on peut coder et compiler avec la toolchain fournie dans le SDK. Premier module: un shell sur le HSM. Une fois le shell obtenu, on constate que le noyau est périmé, et qu’il n’a aucune protection. Il n’y a pas non plus de secure boot. Les orateurs ont fait du fuzzing sur le HSM en limitant la mutation de certains octets pour éviter les crash. Ils ont trouvé un équivalent a heartbleed sur le HSM. Ils ont aussi trouvé de la confusion de type PKCS11 un peu comme en Python ou PHP. Bref, c’est gavé de vuln, et comme ya pas de secureboot, l’intégrité du HSM n’est pas garantie.

L’Audit des GPO

Les GPO servent aux administrateurs Windows pour pousser des configurations sur les postes du parc au travers de l’AD. L’orateur explique les principes de fonctionnement des GPO, puis la méthodologie d’audit de ces GPO, de leur collecte à leur priorisation. Puis les GPO sont filtrés en fonction des CSE à activer. Ces CSE sont ensuite ordonnées, puis exécutés.

Pour désactiver des GPO, on peut mettre leur révision à 0, modifier la révision, modifier le niveau fonctionnel (qui doit toujours être à 2), etc… (plus d’éléments dans les actes).

L’orateur présente ensuite son outil GPOcheck qui sert à faire l’inventaire des GPO. L’analyse des droits d’accès d’une GPO est primordiale pour l’étude des chemins de contrôle. (présenté précédemment à SSTIC). Si une GPO contrôle un poste qui lui même est employé par un admin qui a les privilèges suffisants sur le domaine, alors cette GPO permet la prise de contrôle du domaine.

L’orateur décrit ensuite le fonctionnement de son outil d’audit de GPO. On exporte d’abord des GPO à l’aide du moteur GPO au format XML.  Les fichiers XML sont ensuite transformés en .SQL puis importés dans une BDD qu’on peut ensuite requêter.

IDArling, plateforme de rencontre pour reverseur

Le principe c’est de faire de l’édition collaborative en live sur IDA. On peut soit lancer un serveur tiers pour la collaboration, soit utiliser un serveur « intégré » à IDArling. Chaque utilisateur à un curseur de couleur qui lui corresponnd. La synchronisation marche aussi pour le décompilateur, et les changements de types, d’enum ou de structures. On peut « inviter » quelqu’un à regarder une zone de code, et aussi un système de « follow » pour suivre les actions d’un autre utilisateur.

Le dev était loin d’être une partie de plaisir. Mais comme les dépendances sont réduites à 0, il suffit de drag-drop le plugin dans IDA. On peut aussi l’installer via IdaPython.  Par contre il n’y a pas d’API dans IDA pour charger un IDB. Du coup il a fallu bidouiller avec la fonction de snapshotting pour écraser l’IDB du snapshot puis le restaurer. Autre problème: comment colorer la fonction. Les orateurs ont utilisé Qt et rajouté un proxy pour modifier l’interface. Dernière difficulté, les bindings python sont complètement cassés.