Détection d`intrusions et lutte antivirus : deux mondes

Détection d’intrusions et lutte antivirus : deux
mondes convergents
Thomas Letan
Lundi 3 décembre 2012
Table des matières
I
II
Introduction
1
Des thématiques convergentes
2
1 La détection d’intrusion
3
2 La détection de malwares
4
III
Le virus est un attaquant
6
3 L’influence de la détection d’intrusion
7
4 Utiliser Snort comme détecteur de malwares
7
5 L’analyse des payloads d’un trafic
8
IV
8
Monitoring et analyse dynamique
6 L’analyse dynamique
8
7 L’exemple de NORT
9
V
Conclusion
10
1
Première partie
Introduction
En 2011, le Cert-IST dressait un bilan de l’année écoulée en terme de sécurité informatique et mettait en avant plusieurs constats [CI11], notamment
sur l’émergence de nouvelles menaces. Les faiblesses des systèmes SCADA 1 ,
l’ampleur nouvelle du cyber-activisme ou la prolifération des virus visant les
smartphones sont autant de préoccupations que les entreprises ou les particuliers ne peuvent ignorer. Si le début des années 2000 vit plusieurs attaques virales
massives, la tendance est désormais aux intrusions plus pernicieuses.
Les premiers « virus » n’ont pas été écrits avec malveillance mais comme un
divertissement. Réservé à une — très petite — poignée d’initiés, , il constituait
à faire s’affronter deux programmes informatiques [top]. Aujourd’hui, Stuxnet,
un ver informatique issu d’une collaboration entre les États-Unis et Israël, est
considéré comme une cyber-arme. Dans ce rapport, nous nous intéresserons aux malwares. Un virus est un malware, mais tous les malwares
ne sont pas des virus.
Le présent rapport s’intéresse aux points communs et aux différences entre la
détection d’intrusions et la détection de malwares et l’influence qu’elles peuvent
avoir l’un sur l’autre. Et elle est réelle. Depuis la fin des années 2000, les deux
communautés tendent à se rapprocher et cela se ressent dans le vocabulaire et
les techniques utilisées.
Deuxième partie
Des thématiques convergentes
La détection d’intrusions et la détection de malwares cherchent à détecter les
malveillances à l’encontre d’un système informatique. Autrement dit, savoir s’il
existe un danger pour la politique de sécurité du système. Cette dernière définit
les droits des utilisateurs d’un système sur les objets qu’il contient. Il existe
énormément de modèles de politique de sécurité, plus ou moins complexes et
expressifs.
Un modèle de sécurité est implémenté et garantit normalement qu’un utilisateur ne peut pas faire une action qui lui est interdite (typiquement, lire, écrire
ou exécuter). Dans la pratique, il est possible de contourner ces limitations en
profitant de faiblesses logicielles qui se présentent sous la forme d’erreurs ou de
négligences lors de l’implémentation d’un composant du système. On parle alors
de vulnérabilités du système. Plus formellement, le standard CVE donne une
définition précise de la vulnérabilités [GBG+ 11] :
1. Très utilisés dans l’informatique industriel et cibles de Stuxnet.
2
Définition 1 Une vulnérabilité est un état particulier du système qui permet à
un attaquant :
– d’exécuter une commande comme s’il était un autre utilisateur ;
– d’accéder à des données qu’il n’a normalement pas le droit de lire ;
– de se faire passer pour une autre entité ;
– de provoquer un déni de service.
1
La détection d’intrusion
Une attaque est la tentative de l’exploitation d’une vulnérabilité et une
intrusion sa réussite. Un IDS a pour but de découvrir quand il y a eu intrusion
(ou attaque).
Quelles sources de données ?
Pour pouvoir travailler, un IDS a besoin de données. On parle de NIDS 2
quand les données sont des paquets réseaux. On parle de HIDS 3 quand les
données proviennent du systèmes d’exploitation et du hardware. Il existe aussi
des IDS qui analysent les logs de certaines applications, comme les serveurs web
par exemple. Enfin, il arrive que l’on veuille faire collaborer des IDS, dans ce
cas, les données sont des alertes déjà émises, qu’il faut « vérifier ».
Chaque source de données à ses avantages et ses inconvénients. Un NIDS
n’aura aucun impact sur le système qu’il monitore, par exemple, mais il aura
énormément de données à analyser. L’utilisation d’un HIDS se traduira au
contraire par un overhead parfois non négligeable 4 .
L’approche par signature
Dans ce contexte, la signature d’une attaque est l’ensemble des symptômes
correspondant à une vulnérabilité, symptômes que l’on pourra trouver dans
des logs par exemple, sous forme de messages d’erreurs. C’est en parvenant à
reconnaître ces signatures dans les données qu’il analyse qu’un IDS lève ou non
une alerte. Cela implique plusieurs choses, mais les deux à retenir en particulier
sont :
– Quand l’IDS lève une alerte, on sait qu’elle est la vulnérabilité visée ;
– Impossibilité de découvrir des attaques inconnues (0-day, etc.) ;
Il s’agit de respectivement du principal avantage et de l’inconvénient majeur
de l’approche par signature. Il existe une autre approche, dite comportementale.
Dans ce second cas, l’IDS connaît le comportement normal et recherche des
déviances.
2. Network based Intrusion Detection System
3. Host based Intrusion Detection System
4. Voir section 7.
3
L’approche comportementale
L’approche comportementale propose de modéliser le comportement normal d’un système et de s’en servir comme référence. Les techniques utilisées
sont multiples mais se basent souvent sur le machine learning. Dans un premier temps, on observe un système considéré comme sain et on construit un ou
des détecteurs. Ensuite, on utilise ses détecteurs pour mesurer l’écart entre le
comportement observé et celui attendu.
Il est cependant difficile de construire un modèle précis du comportement
normal du système. Si, à l’instar de l’approche par signatures, un IDS comportemental aura un bon taux de détection (peu de faux négatifs), il aura aussi
tendance à lever des fausses alertes (faux positifs) en trop grand nombre.
Dans la détection d’intrusion, on fait face à un déséquilibre des classes. On
rencontrera beaucoup plus de négatifs (comportement légal) que de positifs
(comportement illégal). Ce fait oblige à avoir un taux de détection très haut
et un taux de faux positifs très bas. Un taux de faux positif de 1% est déjà
beaucoup trop important en conditions réelles, on cherchera plutôt des chiffres
de 0.1% voir moins.
2
La détection de malwares
Les malwares
Il existe plusieurs types de malwares, chacun possédant sa propre technique
de propagation [KN]. Le virus n’est pas un programme en particulier mais un
fragment de code qui s’attache à des exécutables. Ces exécutables deviennent
alors des programmes hôtes 5 . Ils sont proches des vers informatiques, ces derniers n’ont néanmoins pas besoin de programmes hôtes, ils sont des exécutables
indépendants. Les trojans sont des programmes souvent présentés comme des
utilitaires gratuits, dont le but réel est de donner accès au système au hacker.
Les spywares ont pour but de collecter des informations et de les envoyer au
hacker.
Contrairement à ce que son nom peut laisser penser, un antivirus ne s’intéresse pas seulement aux virus informatique mais plus globalement aux malwares.
En vingt ans, les techniques de détection visant les malwares ont grandement
évoluées. [KS92] proposait en 1992 un tour d’horizons des techniques utilisées
alors. Vingt ans plus tard, l’état de l’art proposé par [San12] permet de se rendre
compte des avancées dans le domaine.
La détection de malwares se concentre sur les exécutables et les analyse
afin de découvrir du code malicieux. Il existe deux techniques pour aborder ce
problème :
– Une analyse statique, qui nécessite que le code soit désassemblé, recherche
du code malicieux avant que le programme ne s’exécute ;
5. Une partie du vocabulaire traitant des virus informatiques est emprunté à la biologie,
on parle d’hôtes, d’infections, d’épidémie, etc.
4
– Une analyse dynamique, par émulation par exemple, recherche du code
malicieux pendant ou après l’exécution du programme.
Il est possible de combiner ces deux techniques, afin d’avoir une approche
hybride.
Un détecteur de malwares a besoin de deux données pour fonctionner : ce
qu’il sait être le comportement « normal » du malware 6 et le programme à
analyser.
Plusieurs types de classifications des méthodes de détections semblent plus
ou moins cohabiter. En 2009, [VJLG09] différenciait trois catégories différentes
(signature, comportemental, spécification) alors qu’en 2007, [IM07] différenciait
deux catégories (signature, qui n’a exactement pas le même sens que précédemment, et anomalies, possédant une sous catégorie spécifications) qui a été
reprise en 2012 par [San12] par exemple. La classification présentée ici est celle
de [VJLG09], les différences seront explicitées section 3.
Détection basée sur les signatures
À l’instar de la majorité des IDS, la plupart des antivirus du marché utilisent
des scanners ayant une approchée basée sur la signature. La signature d’un virus
peut prendre plusieurs formes. La façon de faire la plus courante est d’identifier
un virus par une suite d’instructions et de regarder le code des programmes
surveillés. Si on retrouve la séquence cherchée, alors le programme a de grandes
chances d’être infecté. Cette vérification a très rapidement montré ses faiblesses
face aux efforts des hackers à la contourner, que ce soit via l’obfuscation du
code, la création de versions du virus légèrement différentes pour tromper le
scanner ou l’émergence des virus polymorphes (qui modifient leur code à chaque
duplication). De nombreux travaux de recherches ont pour but de débusquer les
virus malgré ces techniques d’échappement.
Détection basée sur le comportement
[Ove05] propose par exemple en 2005 une approche plus générale de la signature, en se basant sur des templates qui permettent de s’intéresser à la sémantique des instructions utilisées par le virus. Ainsi, pour savoir si un programme est infecté, on ne fait plus du pattern-matching mais on vérifie que le
programme instancie la template, c’est à dire qu’ils ont tous deux le même effet sur la mémoire. Les templates représentent les comportement typiques des
virus ; par exemple, une boucle de décryptage 7 . Les templates permettent donc
de spécifier les comportements typiques d’un virus.
Cette façon de faire est behavior based [VJLG09] et n’est pas à confondre avec
l’approche comportementale d’un IDS. On se concentre ici sur le comportement
6. Attention, ici, le comportement considéré est donc le comportement anormal au sens
détection d’intrusion.
7. Une autre méthode couramment utilisée par un virus est de propager une version cryptée
de lui-même, avec une boucle de décryptage pour récupérer le code machine lors de l’exécution.
5
malicieux du virus. Si le virus utilise une technique complètement nouvelle, le
détecteur ne le verra pas.
Détection basée sur les spécifications
Comme pour la détection d’intrusion, l’approche par signature trouve rapidement ses limites, la principale étant qu’elle ne permet pas de débusquer les
nouveaux malwares.
Ici, le comportement du malware est inféré par le comportement normal du
programme analysé ou plus globalement du système considéré. Grâce à cette
approche, il est possible de détecter des malwares inconnus, utilisant des failles
inconnues. Encore une fois, on est encore très proche des techniques utilisés par
les IDS, ce qui fait que les faiblesses sont les mêmes : comme il est impossible de
décrire très précisément le comportement normal d’un programme, le nombre de
faux positifs a tendance à devenir trop important. Pour cette raison, on utilise
rarement un tel détecteur seul. Parvenir à décrire précisément le comportement
normal d’un système est un problème toujours non résolu.
Les techniques mises en avant par [IM07] ressemblent à celles de la détection
d’intrusions : utilisant des N-Grams 8 , le machine learning, le monitoring des
appels systèmes, etc.
Il existe une autre approche comportementale basée sur les spécifications
d’un programme ou d’un système.
Il n’est pas rare d’utiliser en même temps un IDS et un détecteur de malwares. Plus précisément, le détecteur de malwares n’est souvent « que » un
composant d’un IDS.
Troisième partie
Le virus est un attaquant
Il est naturel de voir un malware comme étant un attaquant. Son rôle est
en effet de s’attaquer aux machines et réseaux qu’il infecte. Si une partie des
détecteurs de malwares s’intéresse plus à la façon dont il se duplique ou se
camoufle, il est possible de se servir d’IDS pour détecter leurs méfaits.
Néanmoins, utiliser un IDS pour détecter les malwares en particulier est
rarement mis en œuvre. [Ove05] met en évidence trois raisons :
– Le potentiel des IDS n’est pas compris ;
– Il est difficile de paramétrer correctement un IDS ;
– Les IDS sont sujets à des taux de faux positifs trop importants.
8. PAYL, cité dans [IM07], est aussi utilisé dans le cadre des NIDS par exemple.
6
Un malware est constitué de deux parties : le code chargé de la propagation et
le code chargé des actions malveillantes. Chacun de ces composants est porteur
de comportement illégaux, qu’un IDS pourra normalement détecter.
3
L’influence de la détection d’intrusion
Avant de regarder des exemples précis, il peut être intéressant de s’intéresser
aux dénominations utilisées dans les différents articles. Ils sont différents d’une
année sur l’autre et parfois d’un article à l’autre. Ainsi, en 1992, [KS92] met en
avant deux démarches principales, au travers du moniteur (approche comportementale) et du scanner (approche par signature). En 2009, [VJLG09] décrit trois
démarches, l’approche par signature (utilisant des expressions régulières), l’approche comportementale (cherchant à découvrir des comportements propres au
malwares) et l’approche par spécification (qui apprend le comportement normal
du programme ou système avant de le vérifier). En 2012, [San12] ne parle plus
d’approche comportementale à proprement parler et l’englobe dans la recherche
par signature. Il fait de l’approche par spécification un cas particulier de l’approche par anomalie, typique de la détection d’intrusions. Il est d’ailleurs à noter
que l’auteur semble plus proche de la communauté de la détection d’intrusions
que de la détection de malwares.
4
Utiliser Snort comme détecteur de malwares
Snort 9 est un NIDS open-source basé sur les signatures. Il s’agit d’un projet très actif, possédant une communauté importante et proposant des versions
commerciales crédibles qui intéressent les entreprises. [Ove05] explique une démarche pour utiliser Snort comme un détecteur de malwares. Ses principaux
arguments en faveur d’une telle utilisation sont les suivants :
– La plupart des malwares utilisent Internet ce qui rend l’utilisation d’un
NIDS approprié ;
– Créer une signature pour Snort est plus rapide qu’attendre que les antivirus soient mis à jour ;
– Rajouter un niveau supplémentaire de protection est très souvent bénéfique.
Pendant un an, l’auteur de [Ove05] utilisa 500 signatures Snort de sa confection comme détecteur de malwares. Au total, ce sont 500 000 alertes qui furent
levées par l’IDS.
Malheureusement, l’article ne donne que peu de détails chiffrés sur les résultats de son expérimentation personnelle. Il se concentre sur la façon dont on
peut écrire une signature Snort pour la détection de malwares. Il ne donne aucun
taux de détections ou de faux positifs (parce qu’il s’agit d’une observation em9. http ://www.snort.org/
7
pirique basée sur une utilisation de tous les jours, ces valeurs sont difficilement
calculables).
5
L’analyse des payloads d’un trafic
De plus en plus, les malwares utilisent le réseau, que ce soit pour se propager
ou pour envoyer des informations. L’utilisation du réseau permet d’utiliser des
techniques de détection d’intrusion afin de repérer cette activité anormale. Ici,
nous allons prendre l’exemple de PAYL est un algorithme de détection d’intrusion utilisant les N-Grams [HSB+ 12], dont on peut donner une définition simple
et concise :
Définition 2 Un N-Gram d’une séquence donnée est une sous-séquence de taille
N.
PAYL fonctionne grossièrement de la façon suivante : dans un premier temps,
le but est de construire un ensemble de détecteurs, un par port écouté. Le but
de l’algorithme est de comparer la distribution des octets d’un payload. Pour ce
faire, l’ensemble des 1-Grams de chaque payload — autrement dit, l’ensemble
des octets du payload – est construit et est utilisé pour mettre la distribution
moyenne à jour. À noter que PAYL ne considère pas une distribution moyenne
par port, mais une distribution moyenne par taille de payload par port. Une
fois le détecteur construit, chaque payload lui est soumis, et en fonction de la
distance entre sa distribution d’octets et la distribution moyenne sélectionnée
par l’algorithme, le détecteur lève ou non une alerte.
[San12] cite l’algorithme PAYL comme étant capable de détecter les exploits
utilisés par les malwares. À titre d’exemple, il est révélé que PAYL a été capable
de détecter l’attaque par buffer overflow du malware Code Red II.
Quatrième partie
Monitoring et analyse dynamique
Dans les années 1990, la lutte antivirus semblait se concentrer sur la recherche du code malicieux dans les programmes pouvant être potentiellement
infecté. Le but était de recherché des séquences d’octets particulières. Si cette
approche a encore cours aujourd’hui dans de nombreux antivirus commerciaux
(pour son efficacité sur un grand nombre de malwares, pour un coût très faible),
il existe d’autres approches désormais qui se confondent avec la détection d’intrusions.
6
L’analyse dynamique
Peu importe quelle approche on utilise en détection de malwares, il existe
toujours deux techniques d’analyse possible : statique et dynamique (et hybride).
8
La seconde se prête bien à la détection d’intrusion étant donnée qu’elle analyse le
programme pendant son exécution. Plus particulièrement, il existe des détecteurs
basés sur les anomalies avec analyse dynamique.
Ces détecteurs font le même travail qu’un IDS basé sur les anomalies. Pour
[MKLP12], les deux se confondent, car le but des malwares est d’utiliser des
vulnérabilités pour se propager et/ou accomplir leurs méfaits. Une approche
basés sur les anomalies 10 permet de ne pas se soucier des méthodes d’obfuscation
toujours plus complexes écrites par les hackers.
À noter que l’analyse dynamique ne se limite bien entendu pas aux détecteurs basés sur les anomalies. Il existe des détecteurs basés sur les signatures
qui utilisent l’analyse dynamique pour trouver des signatures connues (ou plus
généralement, des templates). Là encore, on peut utiliser cette approche aussi
bien en détections d’intrusions qu’en détections de malwares.
7
L’exemple de NORT
NORT est un HIDS anomaly-based pour Windows [MKLP12]. Il permet de
détecter des exploits derrière lesquels peuvent se cacher aussi bien des attaquants
humains ou des virus. Ils se basent sur les travaux de Forrest et al [FHSL96], qui
proposaient un HIDS utilisant les séquences d’appels systèmes pour déterminer
si le programme déviait de son comportement normal.
Si un virus a réussi à infecter un programme, ce n’est pas pour le laisser se
comporter normalement mais profiter de ses droits sur le système. Il va devoir
se répliquer et corrompre des données, par exemple. Ces tâches ont de grandes
chances de ne pas faire appel aux mêmes appels systèmes. Dans le pire des cas,
si les appels sont les mêmes, les séquences d’appels pourront être différentes
(l’ordre et le nombre). Il existe cependant des attaques par mimétisme qui visent
à tromper le système.
NORT n’a pas pour but de se substituer à un antivirus classique (basé sur
les signatures) mais à être utilisé en complément. Il permet à la fois la détection
d’intrusions et la détection de malwares.
L’approche de NORT est d’aller plus loin dans le contrôle des appels systèmes. Après une phase d’apprentissage passée à construire un modèle du comportement normal, NORT va s’intéresser, entre autres, à :
– Regarder l’entropie entre deux jeux de données (ici, les séquences d’appels
systèmes) ;
– Utiliser un algorithme de data mining pour trouver des patterns intéressants ;
Les bons résultats de NORT (il parvient à détecter des malwares du « monde
réel » 11 ) ont un coût. Il est commun à tous les HIDS qui surveillent dynamiquement l’exécution des programmes : les performances du systèmes sont dégradées.
On parle d’overhead. L’overhead de NORT dépend des situations dans lesquelles
10. Pour éviter toute confusion, il est important de ne pas parler d’approche comportementale, qui possède un sens différent dans la détection d’intrusions et de malwares.
11. Aucun taux précis ne semble cependant avancé...
9
il est utilisé, mais restait faible et peu dérangeant à l’usage (dans le cas de compression/décompression 7z, l’overhead était toujours inférieur à 10%.
Cinquième partie
Conclusion
La détection d’intrusion et la détection de malwares sont deux domaines
possédant un même but : protéger un système informatique de ses agresseurs et
faire en sorte que la politique de sécurité qui le régit soit respectée. Pour autant,
les deux communautés n’ont commencé à converger que récemment.
Historiquement, les IDS s’attachaient à détecter les exploits permettant de
contourner la politique de sécurité d’un système informatique. Pour cela, la
détection s’appuie sur deux approches : la recherche d’attaques connues (on
parle d’approche basée signatures) et la surveillance du comportement connu
(on parle d’approche basée sur les anomalies, ou approche comportementale).
À l’opposé, les antivirus cherchaient à trouver dans des exécutables les comportements typiques des malwares : boucle de décryptage, envoi massif de courriels, etc. Jusqu’à récemment, on parlait de trois approches différentes : l’approche par signatures (qui consiste à recherche des séquences d’octets dans un
exécutables), l’approche comportementale (qui cherche à repérer des comportements malicieux) et l’approche par spécification (qui se rapproche de l’approche
par anomalie des IDS).
Ici, on peut voir l’une des différences les plus importantes qui existe entre
les deux communautés : l’approche comportementale n’a pas du tout la même
signification si l’on parle d’IDS ou d’antivirus.
Dans les articles les plus récents, la détection d’intrusion influence la détection de malwares, qui prend ses termes. Ainsi, on parlera de détection par
anomalie (dont la détection par spécification est un cas particulier) et de détection par signature (qui englobera l’ancien détection comportementale).
Il est un domaine dans lequel les deux détections semblent se fondre : l’analyse dynamique (ou runtime) d’exécutable basée sur les anomalies. Un HIDS de
ce type pourra servir à détecter les virus, comme le démontre NORT. Des IDS
plus traditionnels, comme SNORT, peuvent aussi être utilisés comme antivirus.
Ces derniers tendent à devenir, d’ailleurs, des composants d’IDS complets.
Références
[CI11]
Cert-IST. Bilan cert-ist 2011 des failles et attaques. 2011.
[FHSL96] S. Forrest, S.A. Hofmeyr, A. Somayaji, and T.A. Longstaff. A sense
of self for unix processes. In Security and Privacy, 1996. Proceedings., 1996 IEEE Symposium on, pages 120–128. IEEE, 1996.
+
[GBG 11] M. Garcia, A. Bessani, I. Gashi, N. Neves, and R. Obelheiro. Os
diversity for intrusion tolerance : Myth or reality ? In Dependable
10
Systems & Networks (DSN), 2011 IEEE/IFIP 41st International
Conference on, pages 383–394. IEEE, 2011.
[HSB+ 12] D. Hadžiosmanović, L. Simionato, D. Bolzoni, E. Zambon, and
S. Etalle. N-gram against the machine : On the feasibility of the
n-gram network analysis for binary protocols. Research in Attacks,
Intrusions, and Defenses, pages 354–373, 2012.
[IM07]
N. Idika and A.P. Mathur. A survey of malware detection techniques.
Purdue University, page 48, 2007.
[KN]
G. Kaur and B. Nagpal. Exploring the malware analysis landscape
for forensic investigation.
[KS92]
S. Kumar and E.H. Spafford. A generic virus scanner for c++.
In Computer Security Applications Conference, 1992. Proceedings.,
Eighth Annual, pages 210–219. IEEE, 1992.
[MKLP12] N. Milea, S. Khoo, D. Lo, and C. Pop. Nort : Runtime anomalybased monitoring of malicious behavior for windows. In Runtime
Verification, pages 115–130. Springer, 2012.
[Ove05]
M. Overton. Anti-malware tools : Intrusion detection systems. IBM,
UK, 2005.
[San12]
Lars Arne Sand. Malware detection — a review of the state of the
art malware detection techniques. 2012.
[top]
topvirus.com.
Histoire du premier
http ://www.topvirus.com/dossier1.php.
virus
informatique.
[VJLG09] P. Vinod, R. Jaipur, V. Laxmi, and M. Gaur. Survey on malware
detection methods. In Proceedings of the 3rd Hackers’ Workshop
on Computer and Internet Security (IITKHACK’09), pages 74–79,
2009.
11