Certains membres du cabinet XMCO ont eu le privilège de participer à l’édition 2018 du SSTIC qui s’est tenue en juin dernier. Reconnue comme une des conférences les plus réputées dans le milieu de la sécurité informatique, cette édition n’a pas dérogé à la règle.
Vous pourrez ainsi retrouver dans nos colonnes, les résumés des cinq conférences que nous avons le plus appréciées. Le reste des conférences paraîtra dans le prochain numéro de l’ActuSécu.
L’ensemble des articles est disponible à l’adresse suivante : http://actes.sstic.org/SSTIC18/actes-sstic-2018.pdf
Closed, heterogenous platforms and the (defensive) reverse engineers dilemma
Le chercheur en sécurité Thomas Dullien (aka Halvar Flake) a pu présenter en début du SSTIC un résumé sur l’évolution de la rétro-ingénierie depuis près de 20 ans.
Même s’il n’a pu que constater l’évolution positive des outils (BAP, Radare, Frida) et des méthodes d’analyses (SMT solvers, scripts de la communauté …), les sujets d’aujourd’hui sont pour lui bien plus complexes qu’auparavant.
Cela est en partie dû au fait que les outils existants, même s’ils ont évolué, sont loin d’être robustes (incompatibilités avec le x64, la virtualisation, …), que les nouvelles plateformes sont de plus en plus fermées (mobile) puisque les éditeurs partageant peu d’informations sur leur fonctionnement, voire travaillent pour rendre difficile les recherches de rétro-ingénierie sur leur système.
Le fait est que pour lui ces nouvelles difficultés sont un frein au débogage applicatif et plus globalement un problème pour la communauté d’auditeurs/reverser.
Le chercheur démontre que sous couvert de “sécuriser” des systèmes il ne s’agit que de barrières supplémentaires qui ont pour la plupart du temps été contournées. En prenant pour exemple la plateforme iOS (obligation de passer par un jailbreak), le débogage de processus privilégiés sous Windows (seule une méthode non documentée par Microsoft le permet), voire la fermeture des ports JTAG sur les équipements physiques. Ces points apportent pour lui uniquement des coûts supplémentaires pour toute société souhaitant auditer ce type de plateforme et non un frein à des attaquants ayant des moyens adaptés.
Il reproche notamment à la communauté de publier des outils de mauvaise qualité souvent rarement maintenus après leur publication.
Selon ses constatations, Thomas Dullien en est venu à présenter les suggestions suivantes :
- Mettre en place des plateformes débogables
- Concevoir des interfaces entre les couches d’abstraction pour les outils de reverse
- Proposer une distribution (à l’instar de kali) dédiée au reverse
- Assurer la qualité et la maintenabilité des outils
- S’assurer de leur fonctionnement avec des cas d’études réels
Subverting your server through its BMC: the HPE iLO4 case
ILO (Integrated-Lights Out) est un BMC (BaseBoard Management Controller). Il s’agit d’un petit système d’administration raccordé sur la carte mère d’un serveur HP. Accessible dès lors que le serveur est alimenté (indépendamment de l’état du système hôte), ce système permet la remise sous tension, la supervision distante de la machine et la réalisation d’actions sur le système hôte via une console distante.
De plus, l’accès à la RAM du système hôte via DMA en fait un élément d’attaque de choix pour le rebond/la persistance sur un serveur : si la blue team peut penser à remasteriser un système, ils vont rarement vérifier du côté du BMC.
1ère démonstration : compromission du système via un dépassement de tampon
Fabien Perigaud (Synacktiv), Alexandre Gazet (Airbus) et Snorky ont commencé par identifier un chemin d’exploitation depuis le service web de l’ILO. Ce dernier analyse des éléments de la requête reçue avec du code en C. Un dépassement de tampon va permettre aux attaquants de modifier l’état de la RAM du système ILO afin de réaliser une exécution de code arbitraire.
L’utilisation de ce dépassement de tampon permet d’interagir avec le module CHIF afin d’écrire du code au sein de la RAM de l’hôte (via Direct Memory Access). L’attaque permet donc de prendre le contrôle du système hôte (avec les privilèges maximums).
2ème démonstration : Persistance via compromission de l’ILO
Profitant de défauts dans le contrôle d’intégrité des composants (du bootloader, du kernel et de la partie userland), les attaquants ont développé un firmware backdooré déposé sur l’ILO. Cette backdoor attend d’être contactée via le serveur web pour permettre de réaliser des actions sur le système hôte (et éventuellement le corrompre si le système hôte est propre).
Certificate Transparency ou comment un nouveau standard peut aider votre veille sur certaines menaces
SLIDES : https://www.sstic.org/media/SSTIC2018[…]analyse_des_menaces-broc_AR1OQsw.pdf
VIDEO : https://static.sstic.org/videos2018/SSTIC_2018-06-13_P04.mp4
L’objet de la présentation réalisée par Christophe Brocas et Thomas Damonneville était de présenter le projet Certificate Transparency (CT), poussé par Google, pour ensuite introduire un cas concret d’usage de CT en matière de maîtrise et protection de son exposition sur internet.
Concrètement, le projet CT vise à demander aux nombreuses autorités de certifications de tracer les créations de certificats dans des registres accessibles publiquement. Pour le commun des mortels, le principal contexte d’utilisation de ces registres est la navigation sur Internet. En effet, dans ce contexte, les navigateurs web font appel à ces registres pour vérifier la validité des certificats présentés par les serveurs web. Ainsi, les autorités de certification sont obligées d’enregistrer les certificats à validation étendue (EV) dans les journaux CT depuis le 1er janvier 2015. Pour tous les autres certificats, Google a fixé la date butoir au 30 avril 2018. Depuis peu, l’ensemble des autorités de certification est donc obligé d’informer publiquement l’ensemble des parties prenantes lors de l’émission d’un nouveau certificat. Dans le cas où les registres n’ont pas connaissance d’un certificat présenté par un site Web, cela engendre l’apparition d’un message d’erreur au sein de Chrome, l’un des principaux navigateurs du marché (et prochainement au sein de Firefox).
Sur la base de ces registres, il est donc désormais possible pour tout un chacun de surveiller l’émission de certificats associés à des noms de domaines similaires ou proches de ceux vous appartenant. Dans le contexte de la lutte contre la fraude reposant sur l’usurpation de nom de domaine, il est donc très important de surveiller ces éléments.
L’exemple d’utilisation de CT au sein de la DSI de l’Assurance Maladie proposé par les 2 conférenciers est plutôt explicite. Ils ont en effet industrialisé le processus d’identification des certificats émis sur les domaines de l’Assurance Maladie, ainsi que ceux émis pour des domaines « voisins ». Enfin, la conférence s’est terminée par la présentation de plusieurs cas concrets de détection issus de leur surveillance.
Smart TVs: Security of DVB-T
Tristan Claverie, Jose Lopes Esteves et Chaouki Kasmi tous trois du labo de recherche sur la sécurité des équipements sans fil de l’ANSSI, se sont regroupés autour du sujet des Télévisions intelligentes (dites “SmartTV”) et du standard associé DVB-T. Ces télévisions sont notamment amenées à remplacer un simple écran puisqu’étant désormais en vente à un coût inférieur.
Les chercheurs ont ainsi pu étudier le standard afin d’identifier de potentielles failles tout en étant en mesure de faire les propositions au consortium afin de les corriger. Leurs recherches, à savoir si ces nouvelles Télévisions intelligentes n’étaient pas un nouveau point d’entrée pour un attaquant, leur ont permis de corriger quelques scénarios exploitables. La norme de diffusions destinée aux SmartTV est dénommée DVB-T, elle permet notamment d’ajouter du contenu interactif au sein des chaînes.
Tout comme un ordinateur, elles sont composées d’une carte mère, d’un processeur, ainsi que de périphériques audio, vidéo et réseau pour la plupart. Ainsi, des applications externes peuvent être exécutées sur ces équipements.
Ce contenu interactif, pouvant être intégré grâce à la technologie HbbTV, est basé sur des technologies Web et dont les ressources peuvent être intégrées dans le flux de diffusion même, voire provenir d’Internet.
Les chercheurs ont ainsi pu remonter les différents points de sécurité suivants au consortium :
- L’absence d’obligation de signer les applications
- L’ensemble des appels à l’API HbbTV n’est pas sécurisé et peut être altéré par un attaquant
- Les signaux radio ne sont pas authentifiés et peuvent être ainsi manipulés par un attaquant
Ca sent le SAPin !
Yvan GENUER et Alexandre BOLLE REDDAT ont présents leur retour d’expérience sur l’audit d’infrastructures SAP les ayant menés à la découverte de 25 vulnérabilités.
Après une introduction rappelant les concepts et les différents composants de SAP, Yvan et Alexandre sont revenus sur l’intérêt d’analyser et d’auditer des composants pour lesquels très peu voir aucune vulnérabilité n’a été identifiée. Ce qui est le cas du composant SAP IGS (Internet Graphic Server) : module présent par défaut sur les installations SAP permettant la génération de graphique, la conversion d’images ou encore la compression de fichiers.
L’administration de ce composant est disponible via le client SAP-GUI au travers la transaction « SIGS ».
L’absence de documentation (RFC, protocole de communication, etc.) concernant le fonctionnement de ce composant a nécessité une rétro-ingénierie du service. Dans un premier temps, l’utilisation d’un protocole propriétaire par le système SAP lui-même a été observé.
La capture des trames réseau leur a permis de constater que le protocole utilisé n’est pas obfusqué ou chiffré. Les données transitent en clair et sont facilement lisibles ou altérables. Par ailleurs, un premier défaut de sécurité concernant l’absence d’authentification sur ces flux a été constaté par les deux chercheurs.
Au total, leur analyse a permis l’identification de 32 fonctions IGS. Parmi ces dernières, la procédure ADM:INSTALL a attiré leur attention.
Son analyse approfondie a permis d’identifier une vulnérabilité dont l’exploitation permet de téléverser sur le serveur des fichiers arbitraires sans être authentifié. Les fichiers déposés étant accessibles via l’interface HTTP du service, l’exploitation de cette vulnérabilité permet de voler les identifiants de sessions des usagers de l’application SAP (vol de session ou phishing).
Au total, leurs travaux de recherches ont permis l’identification de 25 vulnérabilités qui ont été remontées et corrigées par l’éditeur SAP.
