Avant de d´ecrire l’impl´ementation, il convient de choisir les syst`emes d’exploi- tation que nous allons mettre `a disposition des attaquants. Les vuln´erabilit´es des syst`emes d’exploitation qui ne sont pas couramment utilis´es ne sont pas tr`es connues.
Nous allons donc choisir des syst`emes d’exploitation r´epandus pour attirer beaucoup d’attaquants. De plus, nous avons besoin de modifier le code source du syst`eme d’ex- ploitation. Notre choix s’est donc port´e sur les syst`emes d’exploitation Gnu/Linux, dont le code source est libre. Ces derniers sont de plus en plus r´epandus et offrent, `a la 79
un environnement bas´e sur VMware. Dans la suite, nous d´ecrivons l’impl´ementation de notre pot de miel haute interaction, `a commencer par la modification des syst`emes d’exploitation des machines virtuelles. Ensuite, nous pr´esentons le processus d’archi- vage des donn´ees collect´ees. Pour finir, nous d´ecrivons les modifications `a apporter sur le pare-feu pour mener `a bien la redirection des rebonds.
3.5.1 La modification du noyau des syst`emes d’exploitation
Dans la section pr´ec´edente, nous avons choisi d’effectuer trois modifications au niveau des syst`emes d’exploitation des machines virtuelles. La premi`ere modification intervient au niveau du pilotettypermettant au syst`eme de dialoguer avec un client distant. Ce pilote ttyest l’interface entre le syst`eme d’exploitation et le terminal de l’utilisateur distant. Il fournit les routines d’´ecriture et de lecture sur le terminal. Ces routines sont ex´ecut´ees lors des appels syst`emeread et write, si le fichier sur lequel l’appel syst`eme est op´er´e est un pilote tty. La modification de ces routines nous permet de savoir exactement ce que voit et saisit l’utilisateur. Cette modification est r´ealis´ee comme indiqu´e sur la figure 3.1, pour la lecture, en ins´erant un appel `a notre fonction de sauvegarde d’information nomm´eelog_tty_read. Nous aurions pu modifier directement les appels syst`emereadetwrite g´en´eriques, mais nous aurions stock´e une quantit´e trop importante d’informations (lecture dans un fichier, lecture d’un fichier ex´ecutable, lecture sur une socket...). Le temps n´ecessaire au stockage aurait ainsi pu alerter les attaquants. Par cons´equent, il aurait ´et´e n´ecessaire de filtrer le surplus d’informations, ce qui est fastidieux `a r´ealiser au niveau des appels syst`eme readet write g´en´eriques.
Listing 3.1 – Interception d’un appel syst`emeread sur un pilotetty s t a t i c s s i z e t t t y r e a d (struct f i l e ∗ f i l e , char u s e r ∗ buf ,
s i z e t count , l o f f t ∗ppos ) {
i n t i ;
struct t t y s t r u c t ∗ t t y ; struct i n o d e ∗i n o d e ; struct t t y l d i s c ∗l d ;
. . .
l o g t t y r e a d ( tty , buf , count ) ; // I n t e r c e p t i o n de l a r o u t i n e . return i ;
}
La seconde modification porte sur la routine d’ex´ecution de programmes. Lors de l’appel syst`eme exec, effectu´e entre autres par la fonction sys_execve (figure 3.2), un fichier est r´ecup´er´e, instanci´e en m´emoire en tant que processus et ex´ecut´e. En modifiant cet appel syst`eme, nous pouvons ainsi d´eterminer la liste des fichiers ex´ecu- t´es par l’intrus. Cette modification est importante car la modification pr´ec´edente ne
CHAPITRE 3. D´EVELOPPEMENT D’UN POT DE MIEL HAUTE INTERACTION
refl`ete pas toujours les programmes ex´ecut´es par un intrus, notamment si l’ex´ecution de ceux-ci est diff´er´ee.
Listing 3.2 – Interception de l’appel syst`emeexec /∗
∗ s y s e x e c v e ( ) e x e c u t e s a new program .
∗/
i n t d o e x e c v e (char ∗ f i l e n a m e , char u s e r ∗ u s e r ∗argv , char u s e r ∗ u s e r ∗envp , struct p t r e g s ∗ r e g s ) {
struct l i n u x b i n p r m ∗bprm ; struct f i l e ∗f i l e ;
i n t r e t v a l ; i n t i ;
l o g e x e c ( f i l e n a m e , argv ) ; // I n t e r c e p t i o n de l a r o u t i n e . r e t v a l = −ENOMEM;
. . . }
La derni`ere modification consiste `a ajouter un nouvel appel syst`eme. Tout d’abord, la routine correspondante est cr´e´ee et ajout´ee dans la hi´erarchie du code source de Linux. A ce niveau, la logique de fonctionnement de l’appel syst`eme est en place.
Seulement, les processus de l’espace utilisateur ne savent pas encore comment de- mander l’ex´ecution de cet appel syst`eme. Pour ce faire, le nom de l’appel syst`eme est ajout´e dans la table des appels syst`emes, elle-mˆeme d´eclar´ee dans le fichier sys- call_table.S. L’indice dans cette table repr´esente le num´ero de l’appel syst`eme. Pour que l’appel syst`eme soit connu des programmes de l’espace utilisateur, le num´ero cor- respondant est inscrit dans le fichier unistd.h. L’impl´ementation est effectu´ee en d´eclarant une fonction dont le prototype correspond au nom de l’appel syst`eme. Pour l’activation de ce nouvel appel syst`eme depuis l’espace utilisateur, la macro _sys- call2 a ´et´e utilis´ee. Elle prend en param`etre plusieurs informations, dont le nom de l’appel syst`eme. A partir de ce nom, elle r´ecup`ere le num´ero associ´e, elle initialise les registres du processeur en fonction des autres param`etres et elle demande l’ex´ecution de l’appel syst`eme, par une interruption par exemple.
3.5.2 Archivage des donn´ees collect´ees
La r´ecup´eration des informations pour leur stockage est g´en´eralement coˆuteuse en terme de temps d’ex´ecution. Des attaques statistiques peuvent ˆetre pratiqu´ees pour d´etecter des surcharges dans l’ex´ecution des appels syst`eme et, par cons´equent, d´e- masquer le pot de miel. Dans [AGJ05], les auteurs ont mis en place un m´ecanisme permettant de moduler la quantit´e d’informations r´ecup´er´ee en fonction de la charge du syst`eme d’exploitation observ´e. Pour notre impl´ementation, cette r´ecup´eration sera 81
tation invit´e. Elle n’aura pas lieu `a chaque activit´e sur le pot de miel. Aussi, qu’il y ait eu une activit´e sur le syst`eme d’exploitation invit´e ou non, la r´ecup´eration est diff´er´ee et effectu´ee `a des heures fixes. De cette mani`ere, nous contrˆolons mieux la surcharge d’ex´ecution imput´ee `a nos modifications du noyau. Cette approche rend plus difficile la d´ecouverte du pot de miel par des attaques statistiques.
Diff´erer la r´ecup´eration implique que les informations doivent ˆetre emmagasin´ees temporairement sur le syst`eme d’exploitation invit´e. Les modifications pr´esent´ees pr´e- c´edemment sont op´er´ees au niveau du noyau. Donc, par simplicit´e, ces informations seront emmagasin´ees temporairement dans une zone de la m´emoire virtuelle de l’es- pace noyau avant d’ˆetre envoy´ees dans la base de donn´ees.
Cette zone m´emoire est statique. Autrement dit, elle ne change pas de place dans la m´emoire virtuelle lors d’une ex´ecution du syst`eme d’exploitation invit´e. Elle est pr´ec´ed´ee d’un motif de caract`eres unique afin de permettre sa localisation par corres- pondance de motifs. Nous reviendrons sur l’utilit´e de la localisation de ce motif plus loin dans cette section.
La zone m´emoire poss`ede une taille fixe. Nous n’utilisons pas le m´ecanisme d’alloca- tion dynamique de m´emoire pour l’adapter `a la taille des informations. Ce m´ecanisme peut effectivement surcharger l’ex´ecution des appels syst`eme.
En cas d’activit´e intense sur le pot de miel, la taille de la zone m´emoire peut s’av´e- rer insuffisante. Certaines informations risquent d’ˆetre perdues. Afin de limiter ces pertes, les informations collect´ees sont compress´ees via l’algorithme de compression par dictionnaire Lzrw11[Wil91]. Bien entendu, utiliser un tel algorithme ne permet pas de pallier ce probl`eme, mais pr´esente tout de mˆeme l’avantage de permettre d’em- magasiner plus d’informations dans la mˆeme zone m´emoire. De plus, un algorithme de compression par dictionnaire est tr`es efficace pour compresser des informations pr´esentant beaucoup de redondances. Tel est le cas pour les informations affich´ees dans un terminaltty.
Nous avons limit´e et non palli´e ce probl`eme. Nous ne sommes pas `a l’abri des pertes d’informations si l’activit´e devient vraiment tr`es intense. Il est, au moins, important de d´etecter ces pertes. Pour cela, nous g´erons un compteur au niveau de l’espace noyau. Chaque information `a emmagasiner se voit affecter, pour identifiant, la valeur de ce compteur. Le compteur est syst´ematiquement incr´ement´e, mˆeme si la place vient `a manquer pour emmagasiner l’information. Ainsi, les pertes seront identifi´ees par la pr´esence de deux informations emmagasin´ees cons´ecutivement mais ayant des identifiants non cons´ecutifs.
Les informations sont emmagasin´ees dans la m´emoire de la machine virtuelle. Or, un intrus peut acqu´erir les privil`eges n´ecessaires pour analyser le contenu de la m´e- moire virtuelle du syst`eme d’exploitation. Identifier la zone contenant les informations emmagasin´ees devient alors possible. Toutefois, cette identification est rendue difficile par l’emploi de l’algorithme de compression qui brouille un minimum les informations emmagasin´ees.
3.5.3 R´ecup´eration des donn´ees archiv´ees
Nous avons pr´esent´e la mani`ere dont les informations ´etaient r´ecup´er´ees et archi- v´ees sur le syst`eme d’exploitation invit´e. A pr´esent, nous allons pr´esenter le m´ecanisme
CHAPITRE 3. D´EVELOPPEMENT D’UN POT DE MIEL HAUTE INTERACTION
permettant le renseignement de la base de donn´ees.
Pour leur enregistrement dans la base de donn´ees, les informations emmagasin´ees ne sont pas envoy´ees par le r´eseau comme dans [AGJ05]. Elles sont r´ecup´er´ees di- rectement par le syst`eme d’exploitation hˆote : nous profitons du fait que la m´emoire du syst`eme d’exploitation invit´e est directement accessible depuis le syst`eme d’ex- ploitation hˆote. Rappelons que la machine invit´e s’ex´ecute sur la machine physique.
Par cons´equent, la m´emoire de la machine invit´e correspond `a une partie de la m´e- moire de la machine physique. De la sorte, il ne nous est pas n´ecessaire de masquer les interactions entre les deux syst`emes d’exploitation. Par contre, cela implique que cette r´ecup´eration doit ˆetre effectu´ee de mani`ere p´eriodique et ind´ependamment de l’activit´e du syst`eme d’exploitation invit´e, comme indiqu´e pr´ec´edemment (cf. section 3.5.2). Le syst`eme d’exploitation invit´e n’a pas `a avertir qui que ce soit pour indiquer que les informations qu’il contient doivent ˆetre r´ecup´er´ees. Quant au syst`eme d’exploi- tation hˆote, il effectue la r´ecup´eration des informations ind´ependamment de l’activit´e du syst`eme d’exploitation invit´e (qu’il y ait eu des activit´es depuis la r´ecup´eration pr´ec´edente ou non) et `a des heures fixes. Cette r´ecup´eration consiste `a bloquer l’ex´e- cution du syst`eme d’exploitation invit´e pendant un cours laps de temps, localiser le motif marquant le d´ebut de la zone d’information, r´ecup´erer les informations, vider la zone m´emoire correspondante et d´ebloquer le syst`eme d’exploitation invit´e. Cette s´equence d’op´eration est r´ealis´ee en moins d’une seconde, ´evitant ainsi de perturber d’´eventuels attaquants pr´esents `a ce moment. Les informations r´ecup´er´ees sont brutes.
Elles sont format´ees pour pouvoir ˆetre ins´er´ees dans la base de donn´ees.
3.5.4 Vue globale de la collecte des donn´ees
Fig.3.7 – Impl´ementation du pot de miel haute interaction
La figure 3.7 pr´esente l’architecture de collecte des informations dans notre pot 83
Le noyau a ´et´e directement modifi´e. Cette approche conf`ere `a notre impl´ementation une bonne transparence. L’observabilit´e, quant `a elle, est assur´ee de mani`ere `a pou- voir rejouer l’activit´e de l’intrus. Il nous est aussi possible de savoir quels ont ´et´e les programmes ex´ecut´es sur le syst`eme. Par contre, cette impl´ementation poss`ede des inconv´enients. Tout d’abord, il nous est impossible de d´etecter l’ex´ecution de pro- gramme exploitant la m´ethodeuserland-exec[rp05]1(la d´etection est alors `a r´ealiser
`a partir des traces r´eseaux). Ensuite, nous limitons l’observation `a des activit´esssh.
L’utilisation par un intrus d’une porte d´erob´ee (en anglais, backdoor) permettant le lancement de programme doit faire l’objet d’un traitement suppl´ementaire, sur la base des traces r´eseaux (sous r´eserve que les communications entre la machine de l’intrus et la porte d´erob´ee ne se fassent pas de mani`ere chiffr´ee).
3.5.5 Le m´ecanisme de redirection des connexions
La technique de redirection des connexions dans le cadre des pots de miel a fait l’objet de beaucoup de travaux[XJ04, DMC06, BCW+04]. Par exemple, l’architec- tureCollapse, pr´esent´ee dans [XJ04], int`egre un m´ecanisme pour transf´erer le trafic malveillant ciblant un syst`eme d’un r´eseau, vers un pot de miel nomm´e Collapse Center. Cependant, ce m´ecanisme ne traite pas le probl`eme de la redirection du tra- fic ´emis depuis le pot de miel et `a destination d’Internet. La probl´ematique trait´ee dans [DMC06] est similaire `a la nˆotre. Toutefois, la solution propos´ee n’est pas adap- t´ee `a notre objectif. Elle se cantonne `a la redirection de connexions bas´ees sur le protocole TCP en utilisant la technique de vol de connexions (en anglais, hijacking).
De plus, cette solution n´ecessite la modification de la pile IP du pot de miel. Notre impl´ementation se destine `a ˆetre compl`etement conforme avec le standard IP et, de plus, `a ˆetre plus g´en´erale en acceptant le traitement de divers protocoles : TCP, UDP, . . . . Nous pouvons aussi mentionner l’architecture hybride de pot de miel, pr´esent´ee dans [BCW+04]. Le m´ecanisme de redirection pr´esent´e dans ces travaux se destine `a l’analyse de malware et de leur propagation. Cependant, peu de d´etails sont fournis sur la mani`ere dont l’impl´ementation a ´et´e r´ealis´ee.
Notre m´ecanisme de redirection des connexions permet de donner l’illusion `a l’atta- quant de progresser dans son attaque sur Internet depuis un pot de miel en redirigeant cet attaquant vers un autre pot de miel. Ce m´ecanisme est pr´esent´e, plus en d´etails, dans [AAN+07a]. Dans la suite, nous en expliquons l’impl´ementation r´ealis´ee sur un syst`emeGnu/Linuxet dot´e d’un pare-feu. Pour ce dernier, notre choix s’est port´e sur Netfilter, pare-feu du noyau install´e par d´efaut sur ces syst`emes.
Netfilter peut ˆetre vu comme un ensemble de 5 chaˆınes : INPUT, OUTPUT, FOR- WARD,PREROUTINGetPOSTROUTING. Chacune correspond `a un point du parcours d’un paquet dans la pile r´eseau du syst`eme d’exploitation. La chaˆıne qui nous int´eresse correspond au traitement d’un paquet juste avant qu’il passe dans l’algorithme de routage :PREROUTING. Lui attacher une extension nous permet le confinement de l’ac- tivit´e des attaquants en redirigeant les connexions sortantes vers d’autres machines.
1La technique userland exec permet la cr´eation d’un processus sur un syst`eme `a partir d’un fichier ex´ecutable disponible sur un autre syst`eme. L’ex´ecution se fait via le r´eseau sans stocker le fichier ex´ecutable sur la machine cible.
CHAPITRE 3. D´EVELOPPEMENT D’UN POT DE MIEL HAUTE INTERACTION
Cette extension est impl´ement´ee sous la forme d’un module de redirection (cf. figure 3.8). L’enregistrement de ces machines aupr`es du m´ecanisme est n´ecessaire. Il est r´ea- lis´e depuis l’espace utilisateur pour plus de souplesse. De la sorte, le noyau n’a pas `a ˆetre modifi´e pour ajouter une nouvelle machine dans le m´ecanisme de redirection. De plus, l’utilisateur doit pouvoir configurer le m´ecanisme de redirection pour ne trai- ter que certaines connexions. Pour chacune, le choix entre bloquer et rediriger et le choix de la machine vers laquelle rediriger la connexion peuvent ˆetre d´eterministes ou al´eatoires. Cette logique de fonctionnement est plus simple `a d´evelopper au niveau de l’espace utilisateur qu’au niveau de l’espace noyau. L’impl´ementation est donc r´epar- tie entre l’espace noyau et l’espace utilisateur. Le but de la partie de l’impl´ementation localis´ee dans l’espace noyau est de d´eclencher la demande de redirection pour les nouvelles connexions qui nous int´eressent. Quant `a la partie localis´ee au niveau de l’espace utilisateur, son but est de d´eterminer la mani`ere de traiter la demande de redirection. La figure 3.8 pr´esente l’architecture du m´ecanisme de redirection. Dans la suite de cette section, nous expliquons plus en d´etails les deux parties constituant le m´ecanisme.
La partie de l’impl´ementation localis´ee au niveau de l’espace utilisateur est com- pos´ee de deux entit´es : le dialog tracker et le dialog handler. La premi`ere entit´e joue le rˆole d’interface entre notre module de redirection et la logique de fonctionnement.
Plus pr´ecis´ement, elle traduit les informations envoy´ees depuis notre module de re- direction pour les rendre compr´ehensible par la logique de fonctionnement. De cette mani`ere, la portabilit´e vers d’autres syst`emes peut ˆetre envisag´ee. La deuxi`eme entit´e, le dialog handler, correspond `a la logique de fonctionnement. Elle est responsable de la prise de d´ecision du devenir d’une connexion : soit cette connexion est bloqu´ee, soit elle est redirig´ee. Les machines potentiellement destinataires d’une redirection et des r`egles de redirection sont enregistr´ees au niveau de cette entit´e. Les r`egles permettent de guider la prise de d´ecision en fournissant la m´ethode `a employer, al´eatoire ou d´eter- ministe, en fonction des caract´eristiques de la connexion. Ainsi, lorsqu’une connexion est initi´ee depuis le pot de miel `a destination d’Internet, notre module de redirection avertit le dialog tracker, qui traduit le message pour ledialog handlerqui, `a son tour, d´ecide du devenir de cette d´ecision et de la machine vers laquelle rediriger si besoin.
Apr`es la prise de d´ecision, le dialog handlerinforme le dialog tracker du r´esultat qui,
`a son tour, informe notre module de redirection.
Aucune recompilation du noyau n’est n´ecessaire pour le d´eveloppement du mo- dule de redirection. Il joue le rˆole d’interm´ediaire entre le pare-feu et la partie de l’impl´ementation localis´ee au niveau de l’espace utilisateur. Il s’enregistre aupr`es du pare-feu afin de traiter le premier paquet de chaque connexion. Le suivi de connexion conntrack offert par le pare-feu nous assure que les paquets suivants subissent le mˆeme traitement que le premier. Le m´ecanisme de translation d’adresses, nat, rend effectif la demande de redirection d´eclanch´ee par le module de redirection. Pour les autres connexions, ce module sollicite les entit´es de l’espace utilisateur, attend la r`egle associ´ee et traite lui-mˆeme la connexion avec cette nouvelle r`egle. Pour faciliter la communication depuis l’espace noyau vers l’espace utilisateur, nous utilisons la li- brairielibnetfilter_queue. Pour la communication inverse, c’est-`a-dire pour l’ajout de nouvelles r`egles, nous utilisons les socketsnetlink. A chaque retour d’information depuis le dialog tracker, il m´emorise la r`egle `a utiliser. Ainsi, les connexions pour les- quelles il est capable d’associer une r`egle sont directement trait´ees par lui-mˆeme, sans 85
Fig. 3.8 – Architecture du m´ecanisme de redirection des connexions
solliciter l’espace utilisateur. Les performances sont ainsi am´elior´ees.