Notre compte-rendu du SSTIC

 Voici notre retour sur l’édition 2019 du SSTIC, l’occasion de vous partager notre ressenti sur quelques présentations.

Nous arrivons en début de matinée ce 5 juin 2019 au réputé Couvent des Jacobins sous un ciel gris Breton !

Après les contrôles de sécurité qui nous donnent accès au lieu, nous côtoyons les différents stands d’accueil des participants : scan des billets, réception des goodies, petit passage pour un café du réveil. Ambiance chaleureuse, ce sont les retrouvailles pour beaucoup avec des sourires et des rires !9h40 : Nous entrons dans le grand auditorium et nous y installons.

L’ambiance est studieuse, les conférenciers semblent concentrés. Peut-être en attend-on beaucoup de cette conférence ou cache-t-on simplement l’enthousiasme... À suivre !

Keynote : la mort du génie logiciel

 

La première conférence est animée par Alex IONESCU – Seattle, US - CrowdStrike, Inc.

Le sujet principal de cette ouverture est l’évolution dans la gestion et le traitement des bogues de sécurité IT depuis les années 2000 (où rien n’était implémenté) jusqu’à nos jours où des sommes astronomiques sont investies dans ce sujet (parfois à tort et à travers)

 Très vite, Alex IONESCU expose une analyse sur le côté économique de la recherche de failles où le salaire gagné par l'intermédiaire des Bug Bounty par exemple est une réelle opportunité pour tout le monde (ex.: les ingénieurs en génie logiciel…). Ceci est vrai en particulier dans les pays en voie de développement ou les sommes gagnées constituent une réelle amplitude par rapport au salaire moyen.

Ainsi, par relation, la chasse à l’expertise et au talent dans ces pays est un phénomène important qui n’est pas sans avoir un impact local puisque cela appauvrit en quelque sorte l’expertise technologique au sein du pays concerné.

Lié à cette réduction des ressources humaines, un autre problème surgit quant à la capacité de correction des bogues de certaines entités dans un temps limité. Cette thématique tend à rappeler les problèmes rencontrés par beaucoup dans la remédiation de failles (« Je n’ai pas le temps de traiter ») non sans oublier d’autres contraintes (« non on ne peut pas, cela fait ralentir l’exécution du programme ! », « non, j’ai des fonctionnalités à développer ! »)

Cette tendance de recherche de failles a également un impact non négligeable au niveau de l’éducation. En effet, on trouve aujourd’hui des programmes de formation (parfois gouvernementaux) dédiés à la recherche de failles de sécurité où dans certains cas, des jeunes quittent l’école pour partir dans ce type de structure à la fin de laquelle, une embauche est quasiment promise. Cependant, Alex IONESCU relève l’inadaptation de ces cursus puisque ces jeunes sont formés sur des sujets hautement techniques alors qu’ils n’ont pas les bases requises pour bien comprendre le fondement des éléments présentés.

En découle un constat qui s’applique également au génie logiciel de nos jours : le problème de l’absence de bases nécessaires au démarrage d’un développement pour que celui-ci soit « propre » et sécurisé. Selon le présentateur, le développement au démarrage des projets est bien souvent « bâclé », car « de toute façon, il y a des personnes qui trouveront des bogues, nous les remonterons et on corrigera ».

Sauf que cela apporte parfois des failles immenses qui génèrent des problèmes et dangers telles que médiatisées lors de l'épisode Eternal* par exemple. Une réflexion de l’orateur est que certains codes n'auraient jamais dû être développés si les bases de développement correct et sécurisé avaient été respectées.

En conclusion : La domination de la recherche de failles par rapport à l’intégration de la sécurité dans les projets et le développement sécurité est donc une réalité.

Cependant, est-ce que le modèle « pay for the fix, not for the bug » est réellement viable ?

Notre avis : On démarre fort avec une présentation qui rappelle les réalités et la vitesse à laquelle notre monde économique évolue et surtout les technologies et la sécurité. Cette dernière est aujourd’hui plutôt traitée de manière réactionnelle (bug Bounty, recherche et correction de failles, de bogues) plutôt que dans le respect des concepts de bases de sécurité et de développement sécurisé.

La question reste comment investir dans un modèle économique permettant de s'adapter très vite aux changements tout en gardant les bases de connaissances solides.

 

SCA : Side Channel Attacks

 La matinée se poursuit par plusieurs présentations sur les attaques par canal auxiliaire (Side Channel Attacks). Voici une illustration de ce que représente une attaque de ce type :

Voici notre retour sur l’une d’entre elles :  

  • Side-Channel assessment of Open Source Hardware Wallets (Charles Guillemet, Manuel San Pedro, Victor Servant (Ledger))

Cette présentation est axée sur l’étude du cryptowallet open source « Trezor ». Pour rappel, ce type d’outil est utilisé pour stocker les cryptomonnaies (données privées) utiles pour la réalisation de transactions de cryptomonnaies. L’authentification se réalise par l’intermédiaire un code PIN défini pour accéder aux comptes.

Deux attaques menées sur le terminal nous ont été présentées :

La première est une attaque visant à récupérer le code PIN de l’utilisateur stocké dans la mémoire flash de l’outil. Par une analyse du code source du dispositif, les chercheurs ont pu déterminer une façon de retrouver le PIN par une analyse de la vérification « digit par digit » de ce code. Sans entrer dans les détails, il s’agit, sous forme de machine learning, d’analyser la variation de consommation de courant impliquée par l’entrée des caractères du code sur des wallets connus pour générer des probabilités de valeur (classification de 150 000 traces) puis de retransposer cette méthode d’analyse sur un wallet inconnu afin d’en retrouver le code. La conclusion de leurs recherches est la capacité de retrouver le PIN valide au bout de seulement 11 tentatives (alors que l’équipement bloque après 16 tentatives erronées).

Cette découverte a été rapportée à l’éditeur qui a d’ores et déjà corrigé son firmware. La solution a été d’ajouter une fonction de random impliquant que le PIN n’est jamais manipulé « en clair » et n’est donc pas retrouvable.

La seconde attaque concerne l’extraction de la clé privée par le biais d’une multiplication scalaire sur une courbe elliptique (Signature ECDSA générée par la crypto lib de Trezor qui OpenSource). Ici encore, la méthodologie est la même, à savoir, analyser des signaux électriques afin de retrouver des valeurs précises d’une fonction qui vont servir à retrouver la clé privée, élément critique recherché.

En soi, cette vulnérabilité n’est pas critique, car l’entrée du code PIN est nécessaire pour être exploitée. Néanmoins, le danger réside sur le fait que cette librairie, réputée comme résistante à ce type d’attaque, peut être utilisée par n’importe qui et sans l’implémentation d’un code PIN.

Notre avis : Sujet à la mode et très intéressant, démontrant des techniques d’attaques physiques aux résultats étonnants

Tools: Lascar (https://github.com/LedgerHQ/lascar) Rainbow (https://github.com/Ledger-Donjon/rainbow)

  

HSM

Jean-Baptiste BEDRUNE et Gabriel CAMPANA, LEDGER : Everybody be cool, this is a robbery!

Cette présentation est axée autour de tests concernant un module HSM.

Il s’agit d’un équipement matériel considéré comme une enclave sécurité qui protège et manipule des données sensibles dans des environnements nécessitant de hautes exigences de sécurité.

Exemples d’utilisation : IGC (chaine de certification), banque (Vérification de PIN, transactions, cartes de paiement), télécommunication, sécurisation des DNS (DNSSEC), etc.

De façon générale ce type d’équipement coute très cher : prix allant entre 10 et 30k€

Ils se présentent sous la forme d'une carte PCIe ou d’une appliance réseau), avec des contremesures mises en place contre les attaques matérielles.

 

Typiquement, le HSM étudié est certifié FIPS140-2 de niveau 3, ceci signifiant que toute atteinte à l’intégrité matérielle (physique) du dispositif déclenche l’effacement de l’ensemble de ses données.

Le contexte des attaques réalisées est celui d’une personne ayant le contrôle de la machine hôte.

Les outils utilisés sont des modules développés par les chercheurs et chargés sur le HSM. En effet, le constructeur donne la possibilité à un client d’implémenter ses propres modules.

Ainsi, des modules permettant d’accéder à un Shell sur le HSM pour exécuter des commandes et un débogueur pour des raisons de compréhension de fonctionnement ont été développés.

Le premier constat intéressant est que tous les processus tournent avec le compte root. Très peu le sont avec un compte utilisateur classique.

 

De plus, aucun durcissement n’est implémenté. Au final, un certain nombre d’informations sont récupérables :

Après une phase d’ingénierie inverse pour comprendre le fonctionnement du stockage débute la recherche de vulnérabilités : une quinzaine de vulnérabilités ont été trouvées dont une de type Heartbleed. La plus intéressante d’entre elles est une vulnérabilité de type « Confusion de type », car elle est exploitable de manière non authentifiée sur le HSM.

Impact : avec l’ensemble de ces vulnérabilités, un utilisateur non authentifié peut devenir administrateur avec une compromission persistante et on ne peut plus garantir l'intégrité du système.

Nota : Les failles découvertes lors de cet audit ont été patchées et le constructeur a émis un bulletin de sécurité.

Conclusion : les résultats sont inattendus ! Les certifications faites sur les modules HSM sont des certifications matérielles et cela permet de se rendre compte d’importantes faiblesses au niveau logiciel.  Dernier point, les attaques réalisées ici sont possibles sur la version PCIe. Quid de la version appliance réseau du HSM.

 

Notre avis : Le sujet du HSM est très bien expliqué tout au long de la présentation pour permettre une bonne compréhension des personnes n’étant pas familières avec ce type d’équipement. Nous ne pouvons qu’être surpris de la présence de telles failles logicielles sur un module de sécurité de ce type.

 

 

Conférence autour du BGP (Border Gateway Protocol)

 

Kavé SALAMATIAN, LISTIC : Le Monitoring de BGP : où la sécurité rencontre la géométrie Riemmanienne

Les mathématiques, c’est fantastique, surtout en informatique. Voilà ce qu’il faudra retenir de cette conférence pour les moins matheux. Pour les autres, l’orateur commence par introduire les concepts de graphs pendant une bonne partie de l’introduction où il n’est ici même pas question d’informatique. Puis c’est la mise en relation avec les problèmes “classiques” de BGP, quelle route est la plus rapide pour joindre deux systèmes autonomes (AS) ? En mathématique, quel lien entre deux nœuds est le moins couteux ? L’analyse des annonces BGP d’un point de vue mathématiques permet de mettre en relation les changements d’Internet et les mouvements géopolitiques, souvent amorcés par des annonces BGP particulières (comme le cas de la Russie et de l’Ukraine )

Notre avis : Cette conférence nous rappelle que les mathématiques sont une composante essentielle de l’informatique et l’application de concepts comme les graphs peut être un véritable plus.

Solution du challenge SSTIC

Cette année était célébré le 10e anniversaire du challenge ! L’occasion de faire un retour sur l’histoire de cette épreuve et son évolution.

On retient notamment le challenge de 2012 qui a été très peu résolu, ce qui a probablement impacté le nombre de téléchargements 2013, à la baisse cette année-là. L’occasion de remettre en avant le lot symbolique du SSTIC : la célèbre brosse à dents, lot phare de la toute première édition de ce challenge.

 La solution des quatre étapes a ensuite été présentée.

Plus de détails ici https://www.sstic.org/2019/challenge/

 Comme d’habitude, la remise des prix a permis de mettre en avant les meilleurs participants avec les classements de rapidité (Nicolas Iooss en un peu plus de 4 jours) et de qualité (Vincent Dehors).

 Un petit retour sur les différents rapports de solution du challenge a permis de montrer l’originalité et l’ingéniosité de certains participants dans la présentation des résultats, parfois très ingénieuses : Démonstration par des notes de musiques, des poèmes ou encore par des représentations physiques telles qu’analysées lors d’attaques par canaux auxiliaires. Toujours très impressionnant !

Merci encore à Vincent DEHORS pour la présentation de sa solution et félicitations pour sa victoire en catégorie Qualité.

Enfin, nous ne pouvons faire un retour sur le SSTIC sans mentionner les Rumps qui précèdent le très attendu « Social Event » !

De failles découvertes sur le Thermomix jusqu’à la présentation d’une plateforme OpenSource d’évaluation sécuritaire de composants électroniques, il y en avait pour tous les gouts pour ces présentations limitées à 3 minutes chrono !

 Maintenant, place à la détente et aux rencontres avec l’ensemble des participants au Social Event, moment toujours propice à la discussion et à la promotion des activités des uns et des autres autour d’une coupe de champagne et de douceurs.

 

Jérémy et Thomas, Consultants Sécurité, Advens