Laboratoire de Haute Sécurité, Virologie Informatique (2016, axe 4)

Opération au titre de l’année : 2016
Titre : Laboratoire de Haute Sécurité, Virologie Informatique
Site(s) : LORIA
Porteur(s) : Guillaume Bonfante (MCF UL, LORIA)
Financement : 32 k€

Contexte et motivations

Le laboratoire de haute sécurité informatique (LHS) a pour vocation d’accueillir des travaux de recherche déterminants pour sécuriser le réseau, les échanges sur internet et les équipements de télécommunications associés. Le LHS offre le cadre technologique et réglementaire nécessaire aux avancées scientifiques accompagnant les évolutions de notre société numérique. Ouvert aux partenaires industriels, le laboratoire représente également un cadre propice aux tests de fiabilité requis avant toute mise sur le marché de différents produits ou solutions technologiques. Les recherches entreprises sont menées en partenariat entre Inria, l’Université de Lorraine, le CNRS et la Délégation Générale à l’Armement.

Le LHS est une structure inédite pour l’étude notamment de malwares en France, impliquant de nombreux partenaires, et a bénéficié des financements d’Inria, du FEDER, de la Région Lorraine, de la Communauté urbaine du Grand Nancy et du Ministère de l’Enseignement Supérieur et de la Recherche via la Délégation Régionale à la Recherche et à la Technologie.

Nous avons développé une technique d’analyse de code dite analyse morphologique. Elle consiste à extraire des formes abstraites du graphe de contrôle de flot. Nous avons montré au cours des années passées que l’analyse donne des résultats pertinents. Ils le sont à tel point que nous avons pu envisager de commercialiser l’idée, c’est le projet SATT, avec création d’une startup en 2016. De nouveaux problèmes se posent.

Toutefois, le souci de la méthode est qu’il faut disposer de bonnes entrées. Or, les auteurs de malwares, ou plutôt les auteurs de compilateurs de malwares (des programmes qui permettent de synthétiser des malwares), ont tout intérêt à cacher le code de leur malware (pour se prémunir contre les anti-virus, mais aussi pour protéger leur « propriété intellectuelle »). Ils font appel à de nombreuses techniques d’obfuscation. Le problème général de la désobfuscation est indécidable (cf Barack par exemple). Pour passer outre les auto-modifications de code, une analyse dynamique reste très efficace. Néanmoins, les auteurs de malwares ont prévu des contre-mesures.

Afin de résoudre ce problème, nous proposons d’acquérir une plateforme d’analyse de code par instrumentation matérielle.

Description de l’investissement réalisé

Nous avons mis en place des contre-contre-mesures logicielles pour passer outre les techniques d’anti-debug et d’anti-virtualisation des malwares dont la plupart sont référencées dans le « The Ultimate Anti-Debugging Reference ». Mais celles-ci doivent être synthétisées à la main, et elles restent vulnérables à de nouvelles techniques d’anti-debug.
Accéder à l’instrumentation matérielle permet de s’affranchir de manière beaucoup plus complète de ce type de soucis. Notre objectif n’est pas d’abandonner l’analyse logicielle, mais d’être en mesure de la calibrer. En effet, l’analyse logicielle à l’avantage d’être beaucoup plus souple, mais surtout de pouvoir être dupliquée pratiquement à l’infini sur des machines virtuelles.

L’analyse matérielle nous servira de test de vérité pour l’analyse logicielle. C’est vraisemblablement le moyen le plus fiable pour parvenir à des traces d’exécutions correctes. Or, l’ensemble des indicateurs et des mesures que l’on peut proposer dans des publications dépendent de cette correction.
Elle pourra également être employée directement pour les cas difficiles d’analyse.
En conséquence, nous proposons une plateforme d’instrumentation matérielle utilisant deux technologies différentes. La première purement physique en se positionnant au niveau du processeur. Celle-ci est composée essentiellement de :

  • Le logiciel de débugagge SourcePoint qui servira dans un premier temps à exécuter le système en mode pas à pas afin d’extraire la trace d’exécution d’un processus en particulier. Par la suite une application sera développée afin d’automatiser la tâche.
  • L’adaptateurpourlacommunicationavecleprocesseurquisecomposed’unberceaudeconnexion (TSP-H3-ULGA d’Intel) ou d’un connecteur XDP (ITP-XDP 3BR kit) et du boitier d’acquisition (Arium LX-1000e avec le module INT). En effet à la différence des processeurs ARM, le processeur Intel ne dispose pas d’interface JTAG en natif.

Nous prévoyons également une autre plateforme équipée celle-ci de processeur ARM pour tracer des processus sous le sysème d’exploitation Android (Arium LX-1000e avec le module Arium LX-SER, Arium LC-500Se et JTAGulator).
La seconde technologie sera développée au coeur du gestionnaire de la carte mère (Unified Extensible Firmware Interface). Ainsi il sera possible de définir notre propre routine de gestion du système. Le matériel nécessaire au développement de celle-ci est composé de :

  • Un dispositif d’écriture et de lecure de mémoire flash afin de remplacer le programme UEFI (SF600 SPI Flash IC Programmer et les connecteurs TOOL-012A SOIC8 SMD Programming/Testing Clip).
  • Un analyseur logique (LAP-C16128+).
  • Un logiciel de compilation C/C++ (Intel System Studio Professional) afin de développer nos
    propres modules composant l’UEFI.
  • Des cartes de développement hardware à des fins de tests de bon fonctionnement (607-GALILEO2, MinnowBoard Turbot Dual Core Board).

La totalité du matériel a été livrée en 2017.

CV du ou des porteurs de l’opération

Guillaume Bonfante est Maître de Conférences à l’Université de Lorraine à l’École des Mines de Nancy et au LORIA. Il est ancien élève de l’École des Mines de Nancy, docteur en informatique de l’INPL en 2000 et titulaire d’une Habilitation à Diriger les Recherches (HDR) de l’Université de Lorraine depuis 2011. Ses domaines de recherche incluent la virologie informatique, la complexité implicite des calculs et le traitement automatique de la langue.

Galerie

Les commentaires sont clos.