Analyse de code malveillant

MALWARE

Un logiciel malveillant (Malware) est un logiciel qui penetre le systeme de l’utilisateur et porte menace a ce dernier. De nos jours, les malwares continuent de croitre en nombre et en complexite. Apres etre entre dans le systeme, le logiciel malveillant recherche les vulnerabilites de ce derniers et les exploite pour mener des activites imprevues sur le systeme (Goyal et Sharma, 2015). Les codes malveillants peuvent etre classifiees en plusieurs types, que nous decrirons brievement ci-dessous :

Virus Les virus informatiques sont des programmes informatiques capables de se repliquer et d’infecter un ordinateur. Ils ont ete nommes ainsi du a leur ressemblance avec les virus biologiques en ce qui est de la capacite de se multiplier. De la meme facon qu’un virus biologique, ils trouvent un hote, puis l’infectent et se multiplient. Certains virus et autres programmes malveillants presentent des symptomes visibles pour l’utilisateur, mais beaucoup sont passent inapercus. Un virus informatique ne peut se propager d’un ordinateur a un autre que lorsque son hote l’ait transfere sur l’ordinateur cible ; par exemple, si utilisateur l’a envoye a travers un reseau ou sur Internet, ou l’a porte sur un support amovible tel qu’un CD, un DVD ou un lecteur USB. La transmission de virus peut augmenter en infectant des fichiers sur un systeme de fichiers reseau ou sur un systeme de fichiers auquel un autre ordinateur a acces. Les virus sont parfois confondus avec les vers informatiques et les chevaux de Troie, techniquement differents (Khan, 2012). Apres avoir pris controle d’une application, un virus peut modifier ses parametres, supprimer ses donnees ou meme bloquer tout le systeme. Il n’est pas evident pour un utilisateur de suivre le probleme. Il existe de nombreux types de virus, les virus fonctionnent comme des parasites qui infectent les systemes. Ces programmes sont sous la forme d’un fichier executable possedent l’extension .exe ou .com qui controle un autre programme, lorsque quelqu’un clique sur le fichier .exe dans l’ordinateur, le virus affecte le systeme, parfois bloque le systeme entier qui doit etre formate a nouveau (Evans et Twyman, 1999).

Chevaux de Troie Dans (Goyal et Sharma, 2015) un cheval de Troie (≪ Trojan Horse ≫ en anglais) est defini comme un malware injecte par son concepteur dans une application qui parait inoffensif ; L’application accomplit une action illegale, mais semble remplir certaines fonctions utiles. Les attaquants utilisent ce malware pour lancer leurs attaques a distance et utilisent les systemes cibles a leurs propres fins, ils peuvent ainsi acquerir des mots de passe, surveiller ce qui se passe sur le systeme ou corrompre les fichiers systemes (Goyal et Sharma, 2015).

Les vers informatiques

Un logiciel qui effectue ses copies en executant son propre code, independamment de tout autre programme, est appele ver (≪ worms ≫ en anglais), ils ont pour but de prendre le controle du systeme, voler des informations confidentielles de l’utilisateur, soit pour les convertir en ≪zombies≫ ou ≪bots≫ telecommandes (Barwise, 2010). Il envoie des copies de lui-meme a d’autres systemes du reseau sans l’approbation de l’utilisateur. Ces vers consomment la bande passante du reseau pour l’arreter, se propagent via des liaisons reseau et visent a infecter la plupart des systemes informatiques associes au reseau sans exiger l’existence d’un fichier contrairement aux virus (Goyal et Sharma, 2015). En consequence, il pourrait chiffrer, supprimer des fichiers, ou envoyer des courriers indesirables

INTRODUCTION AU ≪RUNTIME MONITORING≫

Pour expliquer clairement ce qu’est le ≪runtime monitoring≫, il est important de preciser la signification de quelques mots ou appellations utilises dans le domaine du ≪monitoring≫. Pour commencer, selon Leucker et Schallhart ≪ Un moniteur est un dispositif qui lit une trace finie et qui rapporte un certain verdict ≫ (Leucker et Schallhart, 2009). C’est l’entite qui va surveiller l’execution du systeme. Le moniteur peut soit etre directement integre au systeme, ou operer sous la forme d’un programme independant. Le verdict indique si une specification a ete violee ou non. Les resultats possibles sont : vrai, faux et non concluant. La trace represente l’execution du systeme. C’est a partir d’elle que le moniteur peut obtenir le verdict d’une specification qui decrit le comportement attendu du systeme et est exprimee en termes des sequences d’evenements qu’il doit produire. Une specification ou propriete est une description de ce qu’un programme est cense faire. Les specifications sont ecrites pour comprendre et affiner les applications deja bien developpees. Les specifications critiques, comme pour la securite sont souvent precisee avant le developpement des applications. Le respect des specifications est important pour que les systemes restent stables. Par exemple, la specification HasNext expliquee dans (Halle et al., 2014), specifie que l’interface Java Iterator necessite que la methode hasNext() soit appelee et renvoie true avant l’appel de la methode next(), si cela ne se produit pas, il est tres possible qu’un utilisateur repete la lecture d’une collection.

LIRE AUSSI :  Hybridation algorithmes génétiques (Réseaux de neurones)

Une autre specification appelee ReadPrint empeche un evenement print apres l’observation d’un evenement read. Certaines proprietes sont tres particulieres, comme les proprietes data race et deadlock. Dans (Boyapati et al., 2002) les auteurs specifient qu’un data race se produit lorsque deux threads accedent simultanement aux memes donnees sans synchronisation, et qu’au moins un des acces est une ecriture. Les auteurs ajoutent qu’un deadlock se produit lorsqu’il existe un cycle de la forme : ∀i ∈ 0..n−1, Threadi detient Locki et Threadi attend Lock(i+1)modn. Les erreurs de synchronisation dans les programmes multithreads sont parmi les erreurs de programmation les plus difficiles a detecter, reproduire et eliminer, ces proprietes sont generalement souhaitees etre satisfaites par tous les systemes et peuvent etre mieux mises en oeuvre algorithmiquement (Boyapati et al., 2002). Le ≪runtime monitoring≫ est une approche d’analyse de l’execution d’un systeme informatique basee sur l’extraction d’informations d’un systeme en cours d’execution et son utilisation pour detecter et eventuellement reagir a des comportements observes satisfaisant ou violant certaines proprietes (Leucker et Schallhart, 2009).

Dans une recherche conduite dans (Varvaressos, 2014), les auteurs definissent des termes lies au runtime monitoring comme suit : Le systeme monitore est le systeme que nous tentons d’analyser et detecter les anomalies presentes dedans, et ce systeme, peut consister en un systeme pour utilisation simple, comme il peut consister en un systeme a utilisation sensible tel que les banques et les gouvernements. En parallele avec l’execution du systeme monitore, des evenements indiquant l’etat du systeme, et les actions effectuees au sein de ce dernier, sont produite, ces evenements servent a instrumenter le moniteur (Varvaressos, 2014). La figure 1.1 represente le fonctionnement d’un tel systeme. Dans le runtime monitoring, les specifications de verification sont generalement exprimees dans des formalismes de predicats de trace, tels que des machines a etats finis, des expressions regulieres, des grammaires sans contexte, des expressions de logique temporelle lineaire, etc.,

Le runtime monitoring necessite une sorte d’instrumentation qui sonde le systeme en execution et rapporte les informations sur ce dernier. L’instrumentation peut etre inseree sous la forme de lignes de code dans le programme surveille, a chaque fois que le programme atteint un certain point dans l’execution, le code de l’instrumentation s’execute. Cette instrumentation a un impact considerable sur les performances, et entraine une augmentation significative de la taille du code (Tran et al., 2008). Plusieurs autres techniques permettent de realiser l’instrumentation. Parfois, l’instrumentation est assistee par materiel comme avec les points d’arret materiels du debogueur. Sur l’architecture X86, un CPU fournit quatre registres de debogage (DR0, DR1, DR2, DR3), chacun contenant l’adresse memoire a recuperer. L’execution du systeme peut etre interceptee, en manipulant les registres de debogage (Tian et al., 2017). La prise en charge materielle de la surveillance et de l’execution capture les proprietes souhaitables de l’instrumentation, avec des couts d’exploitation potentiellement inferieurs en temps d’execution (Nagarakatte et al., 2010). D’autres approches d’instrumentation existes, comme l’instrumentation basee-minuterie (p. ex., (Metz et al., 2005)), ou l’instrumentation basee-compteurs (p. ex., (Arnold et Ryder, 2001)), mais dans notre memoire nous nous concentrons sur une technique en particulier qui est l’instrumentation basee sur la programmation orientee aspect (Nusayr et Cook, 2009). La programmation orientee aspect (POA) (Kiczales et al., 1997) est une approche de developpement logiciel utilisee pour resoudre les problemes de la separation des preoccupations transversales. Dans le developpement logiciel, la separation des preoccupations transversales consiste a organiser et modulariser des parties similaires d’un logiciel, telles que l’authentification, le debogage, la securite, la gestion des transactions, la mise en cache, qui couvrent la totalite de l’ensemble des modules logiciels contenus dans les preoccupations principales. L’aspect integre toutes les fonctionnalites transversales qui ne doivent pas etre repliquees aux differents endroits dans le programme source. Cela ne peut pas etre resolus efficacement avec la programmation orientee objet (POO), la POA complete donc la programmation orientee objet (Schatten et al.2010).

Table des matières

Table des matieres
Table des figures
Liste des tableaux
Resume
Introduction
1 Notions de base
1.1 Introduction a la programmation securisee
1.2 Introduction au ≪runtime monitoring≫
2 Revue de litterature
2.1 Criteres d’analyse
2.2 Analyse de code malveillant
2.3 Critique des solutions existantes
3 Architecture de la solution
3.1 Vue globale
3.2 Instrumentation de l’execution
3.3 Le moniteur BeepBeep
4 Proprietes de securite
4.1 Propriete de securite NoNetSending
4.2 Propriete de securite LimitBytesWritten
4.3 Propriete de securite NoSendAfterReading
4.4 Propriete de securite IsaKey
4.5 Propriete de securite asReadasWrite
4.6 Propriete de securite SafeLock
4.7 Propriete CallSequenceProfiling
4.8 Propriete ByteWrittenGraph
5 Experimentation
5.1 Stethoscope
5.2 Resultats d’experimentation
Conclusion
Bibliographie

Cours gratuitTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *