ROOTKIT ET NOYAU LINUX 2.6.

28
Etat de lart et dtournement dappels systme
MARTIN Benjamin PAULIAT Romain PELLETIER Alexandre
"The greatest trick the devil ever pulled o was convincing the world he didnt exist."
Keyser Sze, Usual Suspects
Table des matires
1 Introduction 3
2 Rappels 4
2.1 Gnralits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Notion de Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Notion dappel systme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.3 Les registres de debuggage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Rootkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Cycle de vie dun rootkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3 Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Moyens de corruption dun systme 9
3.1 Ring 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Ring 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 Exploration de la mmoire noyau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2 Corrompre la table des appels systmes . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3 Subtil inline Hooking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.4 Debug Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Ring -1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 Systmes virtualiss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2 Blue Pill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.3 SubVirt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4 Elaboration dun rootkit 17
4.1 Gnralit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Implmentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1 Recherche dinformations gnrales . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.2 Recherche complmentaire pretty hook . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.3 Mise en place dirty hook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.4 Mise en place pretty hook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5 Conclusion 23
2
Chapitre 1
Introduction
Anne 2005. Sony-BMG met sur le march des millions de CDs contenant la mesure technique de
protection contre la copie, nomme "XCP", ce programme a principalement pour fonction dempcher le
CD dtre lu avec un autre logiciel que celui fourni par Sony et dempcher le CD dtre copi en plus de
trois exemplaires ou converti au format mp3 .
Cependant, une fois insr dans le lecteur, le CD procdait automatiquement linstallation,
linsu de lutilisateur, dun programme espion indtectable et non dsinstallable. Celui-ci tait destin
recueillir les identiants des CD couts et les communiquer Sony-BMG par le biais de son site
internet. Aprs avoir pendant quelques jours ni lvidence, la raction du PDG de Sony-BMG, Thomas
Hesse, a t dexpliquer que la plupart des gens ne savent pas ce quest un "rootkit", alors pourquoi
devraient-ils sen proccuper ? .
"On nomme rootkit un programme ou ensemble de programmes permettant un tiers (un pirate
informatique, par exemple, mais pas ncessairement) de maintenir - dans le temps - un accs frauduleux
un systme informatique. La fonction principale du rootkit est de camouer la mise en place dune
ou plusieurs portes drobes . Ces portes drobes (utilisables en local ou distance) permettent au
pirate de sintroduire nouveau au cur de la machine sans pour autant exploiter une nouvelle fois la
faille avec laquelle il a pu obtenir laccs frauduleux initial."
1
Ils ont t concus la base pour des plateformes Linux mais existent maintenant aussi bien sous
Solaris, *BSD ou Windows et des utilisations industrielles sont donc dj connues. Dicile de dterminer
la date de cration du premier dentre eux mais des outils de dtection existent depuis 1997. Ils ont donc
eu le loisir de samliorer avec le temps, de se multiplier, prenant diverses formes et sattaquant des
endroits de plus en plus sensibles pour le systme. Nous allons donc prendre le temps dtudier plus en
dtails lapparition de ces rootkits, de leur complexication au cours du temps ainsi que les moyens mis
en place pour arriver corrompre une machine.
Avec la mise disposition du noyau linux 2.6.28, n dcembre 2008, lintrt pour les rootkits a t
relanc. En eet, cette nouvelle version du noyau, utilisant de nouvelles structures ou champs associs,
rend impossible lutilisation directe de rootkits comme EnyeLKM, DR rootkit ou autres moins connus.
Nous allons essayer deectuer les modications ncessaires an de pouvoir mettre en place un rootkit
sapparentant ces derniers et pour ce type de noyau.
Les direntes notions voques au cours des chapitres suivants ncessitent, si ce nest une connaissance
approfondie, tout du moins une certaine aisance avec le fonctionnement du systme dexploitation utilis.
Lintrt du chapitre qui suit sera dvoquer les aspects nous concernant avant se plonger au coeur du
sujet.
1
Source : Wikipedia
3
Chapitre 2
Rappels
2.1 Gnralits
An de comprendre comment intervenir sur les mcanismes des appels systmes pour les dtourner, il
est ncessaire de comprendre un certain nombre de concepts au niveau du systme dexploitation. Nous
allons tudier ces concepts dans cette section.
2.1.1 Notion de Ring
Pour leur fonctionnement, les logiciels applicatifs ont besoin dutiliser les fonctions du systme
dexploitation qui dpendent en partie de larchitecture des processeurs. Cet ensemble complexe se situe
dirents chelons dont chacun correspond un mode de fonctionnement et un anneau de protection
ou ring .
Les processeurs les plus courants ce jour, de type x86, permettent quatre modes dont deux seulement
sont utiliss par les systmes Linux et Windows.
Les programmes des utilisateurs et les outils communs (processus) fonctionnent en mode utilisateur
(user mode), au niveau ring3 , dans un espace mmoire particulier qui est gr par le systme
dexploitation.
Les fonctions fondamentales du systme (gestion du processeur, de la mmoire, des entres-sorties,
des communications ...), sexcutent en mode superviseur (supervisor mode) aussi appel
mode noyau ( kernel mode), au niveau ring0 , un chelon privilgi o toutes les ressources
matrielles et logicielles sont accessibles.
Les autres modes ou niveaux de protection ne sont pas utiliss.
Les processeurs les plus rcents permettent la virtualisation qui correspond un nouveau mode
hyperviseur (hypervisor mode) au niveau ring -1
1
. Le plus haut degr de privilges est accord
ce niveau o il est possible dexercer un contrle complet tant des applications que du(des) systme(s)
dexploitation qui fonctionne(nt) sur le PC.
2.1.2 Notion dappel systme
Un appel systme est une routine excute par le noyau. Chaque application peut demander un travail
raliser au systme dexploitation. Il peut sagir dune lecture en mmoire, ou daccs un priphrique
ou autre. Sauf exception prvue par les dveloppeurs pour des liens privilgis entre deux logiciels, il ny
a pas de relation directe entre leurs processus ou entre un processus et les ressources du systme.
Cest par lintermdiaire dappels systmes (system calls) que les logiciels communs peuvent
solliciter les fonctions du noyau. Les relations entre les dirents lments se font grce aux interfaces de
programmation (API) et une srie de tables en mmoire qui permettent de situer chaque composant
1
Certains considrent que lanneau de protection de niveau le plus privilgi devrait tre le ring0 qui dans ce cas de
processeur, deviendrait celui du mode hyperviseur. Celui du noyau serait alors le ring1 et celui des logiciels applicatifs le
ring4.
4
ou de lister les oprations eectuer.
On peut voir tous les appels systmes demands par une application myApp laide de la commande :
strace ./myApp
Lapplication informe le noyau de sa demande dappel systme en invoquant la commande assembleur
int 80h qui correspond lexecution de linterruption logicielle numro 80.
Pour sinterfacer avec le noyau, lapplication utilise les registres du processeur. Elle stocke le numro
de lappel systme demand dans le registre eax, les paramtres dans dautres registres. Chaque appel
systme est caractris par son numro dappel. Les adresses de chaque appel sont stocks dans la table
des appels systme (syscall_table ou SCT). Cette table est indxe par chaque numero dappel.
Le noyau dispose de ladresse de l Interrupts Description Table (IDT) dans ses registres, cest--dire
constamment. Il sut quil excute la routine localise ladresse crite dans la 80me case du tableau
IDT, system_call. Lors du droulement de cette routine, le noyau va appel le bon appel systme
demand, laide du registre eax. Lensemble des appels systmes sont stocks dans la system call table
(SCT). De la mme facon que les interruptions, system_call va ensuite appel la Nime case du tableau
SCT, dont le noyau connait ladresse ou loset.
La gure 2.1 dcrit le droulement dun appel systme standard. Un dtournement dappel systme
consiste reprer certaines adresses dans ce cheminement (tape 1) et rcrire certaines instructions
directement en mmoire an de modier le cheminement du ux dexcution (tape 2).
Fig. 2.1 Droulement dun appel systme apres int80h
Le problme qui se pose prsent est de pouvoir lire la mmoire du noyau. Selon les versions du noyau
linux, divers stratagmes sont mettre en oeuvre, selon les protections de la mmoire noyau.
2.1.3 Les registres de debuggage
Sur larchitecture x86, les debug registers sont aux nombres de 8, numrot de DR0 DR7. Ils ne
sont accessibles qu partir du ring 0 et permettent au processeur de grer le mcanisme de dbuggage.
On les utilise en se servant de linstrucion MOV.
Lutilit de ces registres est de poser 4 breakpoints (nots 0 3) sur des adresses linaires et de piloter
ces derniers laide des registres spciaux DR6 et DR7. Dans chaque breakpoint, on peut stocker les
infomations suivantes :
Ladresse laquelle le breakpoint est plac
La longueur de lemplacement du breakpoint. (1, 2 ou 4 octets)
Lopration qui sera eectue ladresse par lexception gnre
Si le breakpoint est actif
5
Si la condition du breakpoint tait prsente lorsque lexception a t gnre.
Les registres DR0 DR3 contiennent chacun une adresse 32 bit du breakpoint qui lui est associ. DR4
et DR5 tant en quelque sorte des alias de DR6 et DR7, cest pourquoi dans les deux parties suivantes
nous ne parlerons que de ces deux registres.
Le registre DR6
On lutilise pour dterminer quelle condition de debug est apparue. On peut galement noter que le
processeur ne vide jamais ce registre. Il contient les informations suivantes :
B0 B3 : Ce sont les bits 0 3, ils servent signaler que la condition de breakpoint a t dtecte.
Ces ags sont actifs si les ags LENn et R/Wn de DR7 le sont. Et ils le restent mme si on nallume
pas les ags Gn et Ln de DR7.
BD : Cest le bit 13, il indique si la prochaine instruction dans le ot dexcution veut accder aux
debug registers. Il est activ si le ag GD de DR7 est mis.
BS : Cest le bit 14, il nous dit, si on lactive, que lexception de debug a t attrape par le mode pas
pas.
BT : Cest le bit 15, sil est actif et que le ag debug trap de TSS de la tache est mis, il permet de
rvler que lexception est le fait dun changement de tche.
le registre DR7
Il sert piloter les breakpoints : les activer ou non et poser leurs conditions. Les ags de DR7
sutlisent de la manire suivante :
L0 .. L3 : Ce sont les bits 0,2,4,6, ils activent les breakpoits de faon local. Quand on allume un de ces
bits, la condition pos pour ce breakpoint concerne seulement la tache courante. Le processeur vide
automatiquement ces ags, pour quils nempitent pas sur la tche suivante.
G0 .. G3 : Ce sont les bits 1,3,5,7, eux activent les breakpoints de faon global. Quand ils sont 1, la
condition de breakpoint reste quelque soit la tache. Si on voit une condition de breakpoint, et que
son drapeaux est lev, on gnere une exception de debug. Le processeur ne vide jamais ces ags, ils
peuvent donc tre utilis pour toute les taches.
LE et GE : Ce sont les bits 8 et 9, ils grent lactivation exact local ou global des breakpoints. Ils reprent
quelle est linstruction exacte qui a caus la condition du breakpoint.
GD : Cest le bit 13, il soccupe de la dtection gnrale. Il lance une xception de debug des quune
instructuin MOC tente daccder un debug register. Quand ceci se produit, le ag BD de DR6 est
activ avant de gnr lxception.
R/W0 .. R/W3 : Ce sont les bits 16 et 17 (DR0), 20 et 21 (DR1), 24 et 25 (DR2), 28 et 29 (DR3), ils
servent commander la condition de breakpoint pour un breakpoint donn. On les utilise ainsi : si
les deux bits sont zro, on arrte sur lexcution, sils valent 01 la condition est que lon essaie
dcrire des donne et enn ils sont gaux 11, si on essaie de lire ou crire sur une certaine donne.
LEN0 .. LEN3 : Ce sont les bits 18 et 19 (DR0), 22 et 23 (DR1), 26 et 27 (DR2), 30 et 31 (DR3), ils
indiquent quelle longueur de mmoire est surveille par les breakpoints. On associe chacun des
breakpoints deux bits dont la valeur 00 reprsente un octet de mmoire surveill, 01 deux octets,
10 quatre octets et enn 11 huit octets.
2.2 Rootkits
Lintrt de cette partie sera deectuer une premire prsentation des rootkits nottament dans leur
principe de fonctionnement mais aussi de leurs apparitions au cours des dernires annes. Nous revien-
drons plus prcisment, dans le chapitre suivant, sur les mthodes quils utilisent pour parvenir leurs ns.
6
2.2.1 Cycle de vie dun rootkit
Comme dirai Alfred de Musset, Quimporte le acon, pourvu quon ait livresse .
Ainsi, quel que soit le rootkit tudi, et peu importe les fonctionnalits quil permet, son principe est
toujours le mme, se composant essentiellement de quatre grandes tapes :
Collecte dinformation
Avant de pouvoir commencer corrompre le systme, le rootkit doit tout dabord rcuprer les
informations essentielles son excution, le plus souvent, cest loset de la table des appels
systmes qui est primordiale, an de pouvoir les dtourner par la suite aux moyens des routines
corrompues.
Dploiement des composantes
Celui-ci consiste essentiellement linstallation proprement parler du rootkit, par chargement du
module dans le noyau ou injection de code dans la mmoire volatile, puis grce un mcanisme
de hook des appels systmes, il dissumule sa prsence (omission du module dans le lsmod pour un
LKM rootkit par exemple).
Mise disposition de services
De la mme manire que lors de son dploiement, le crochetage des appels systmes permet de
mettre disposition des services qui seront dissimuler la pauvre victime. Il ny a pas tellement
de limite aux services proposs si ce nest lingniosit de lattaquant. On peut malgr tout les
dcomposer en deux types : passif (espionnage, keylogger ...) et actif (suppression, modication de
donnes sensible, DOS ...).
Survie au sein du systme compromis
Le but dun rootkit est avant tout de prniser un accs une machine corrompue. Pour cela, il
tentera de se protger des logiciels de dtection tel que chkrootkit ou autre mais aussi de survivre
un redmarrage par le biais dun script qui sera cach au systme.
Les rootkits ne sont pas en eux mmes des exploits . Mme sils cachent souvent des maliciels, leurs
techniques peuvent aussi tre utilises par des logiciels sains, commencer par les utilitaires de dfense.
La mthode pour mettre un appel systme ou le rceptionner peut varier. Nanmoins un rootkit con-
siste se positionner entre lappelant et lappel. Ainsi il sera possible de modier le contenu de la rponse.
Nous verrons plus en dtails dans le chapitre suivant les diverses manires que peut utiliser celui-ci.
2.2.2 Historique
Au fur et mesure de leurs apparitions, les rootkits ont entran une rponse de la part des
dveloppeurs informatique sous forme de nouveaux moyens de protection du systme dexploitation. Le
jeu du chat et de la souris a alors commenc, les pirates tentant de contourner ces nouvelles rgles en
complexiant de plus en plus leurs programmes malicieux. En lespace dune dizaine dannes, les rootkits
sont donc passs de lespace utilisateur (Ring 3) lespace noyau (Ring 0) et enn la virtualisation
(Ring -1). Dans chacun de ces anneaux , un nombre considrable de variantes dun mme principe ont
t dveloppes, comme le rsume la liste non exhaustive de la gure 2.2.
Ri ng -1
Knark
Module noyau
Adore
Module noyau
EnyeLKM
Module noyau
DR rootkit
Module noyau
Blue Pill
Virtual
SubVirt
Virtual
Suckit
Module noyau
Torn
Binaire
Ark
Binaire
Lrk
Binaire
1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007
Ri ng 3
Ri ng 0
Fig. 2.2 Chronologie et complexication des rootkits sous Linux
7
Il est dicile de lister lintgralit des rootkits existant ou ayant exists, et ce, principalement pour
trois causes.
Premirement, une majeure partie des rootkits cits a volu au cours du temps pour donner lieu
des version 2.0, 3.0 ou autres appellations semblables. Il faut donc essayer de les voir en tant que famille
plutt que dans leur individualit.
Deuximement, les rootkits sont des structures souvent organises de faon modulaire (coeur +
fonctions annexes) et donc facilement modiables. Les concepteurs ont donc eu le loisir de sappuyer
sur des modles prexistants, crant ainsi des drivs - probablement non connus - des rootkits cits
prcdement.
Et troisimement, il faut tenir compte du fait que certains rootkits nont pas encore t rendus public
, tant au niveau de la preuve de concept que de limplmentation, car constituant une trop grande menace
du point de vue de la dfense ou trop utile pour tre dvoil si lon se place au niveau de lattaquant .
Les quelques exemples de la partie qui suit nauraient probablement pas t connus si un utilisateur
navait pas dcouvert, de manire relativement inopportune, leur prsence au sein dun sytme suppos
sain.
2.2.3 Exemples
Il existe, en eet, des exemples dutilisation industrielle de rootkits. Comme voqu lors de lintro-
duction, en 2005, un de ces programmes a t dcouvert dans des CD audio de marque Sony-BMG,
linstallation se faisant, lors de lcoute, comme composant de gestion numrique des droits (DRM).
Ce rootkit permettait, une fois charg, de cacher tous les chiers dont le nom commenait par $sys$.
Cette fonctionnalit a t exploite par des virus pour cacher leur code malveillant et chapper ainsi aux
programmes anti-virus.
Durant lanne 2006, cest au tour de Symantec Corporation dtre dmasqu pour avoir tent
dinsrer un rootkit dans son anti-virus Norton. Celui-ci cachait le rpertoire NProtect et son contenu,
permettant ainsi de rcuprer des donnes senses avoir t supprimes par lutilisateur. Le scandale
provoqu par laaire Sony-BMG un an plus tt les incitera publier un patch correctif an dviter une
action juridique de la part des clients concerns.
On aurait alors pu croire que ces rvlations auraient dissuad dventuels successeurs. Il nen ft
rien et cest nouveau Sony-BMG qui se retrouva au centre de la polmique, courant 2007, aprs la mise
en circulation de ses cls USB biomtrique reclant elles aussi un rootkit. Pour sa dfense, Sony-BMG
rejettera la faute sur un sous traitant taiwanais qui laurait incorpor leur insu et ce malgr le devoir
de vrication dont aurait d faire preuve Sony-BMG.
Lintgration de rootkit aux softwares nest donc plus simplement rserv aux pirates informatique
en qute dexploits mais se dmocratise au point dtre utilis directement par les producteurs de ces
logiciels ou quipements commerciaux.
Lattaque par DOS subie par la Gorgie lors de son conit avec la Russie (perte de plus de 80% de
ses services informatiques), lors de lanne 2008, repose elle aussi sur lutilisation de rootkits. Ceux-ci
permettant la prise de contrle de milliers de machines, il ft alors facile lattaquant de synchroniser
lensemble des requtes eectues an de saturer les serveurs cibls.
8
Chapitre 3
Moyens de corruption dun systme
Il existe dirents vecteurs dattaque pour infecter un systme, sappuyant sur chacun des rings dcrits
lors du chapitre prcdant. Le but de cette partie sera donc de faire un tat de lart des techniques de
corruption misent disposition.
3.1 Ring 3
Les rootkits visant le ring 3 - ou espace utilisateur - sont les premiers avoir t dvelopps
massivement. Ce sont les plus facile mettre en place mais aussi dtecter. Il en existe essentiellement
deux familles :
1. Les rootkits "Applicatifs"
Ils modient ou remplacent des logiciels applicatifs sains par leur "code" qui inclut gnralement un
cheval de Troie. Sous Linux, au moment de leur installation, ils remplacent souvent les utilitaires
de systme suivants : nd, ifcong, login, ls, netstat, ps, etc ... an de masquer leur prsence et
un programme permettant de mettre la machine "en coute" est dmarr, dans le but de pouvoir
"parler" au rootkit. Ceux-ci sont donc simple concevoir mais en contrepartie une simple mthode
dempreinte tel MD5 permet de sen prmunir.
2. Les rootkits "Bibliothque"
Cette technique de rootkit en mode utilisateur , qui naltre pas le noyau, est connue sous le
nom de "API hooking". Ils modient ou remplacent les appels ("system calls") aux ressources du
systme dexploitation pour les orienter vers eux. Cette mthode pour but de toucher un maximum
dapplications grce un minimum de modication. De mme que les rootkits applicatifs, il est facile
de dtecter et de contrer ce genre dattaque via une compilation statique des programmes.
Comme rootkit en mode utilisateur, on trouve lrk, tOrn, ark et autres. Prenons tr0n comme exemple.
Celui-ci excute une srie dactions pour cacher sa prsence dans le systme au moment de son installation :
1. stoppe syslogd-demon,
2. remplace les utilitaires de systmes : du, find, ifconfig, login, ls, netstat, ps, top, sz,
3. une version trojan de syslogd-demon est rajoute dans le systme,
4. un snieur est demarr en tche de fond,
5. le lancement des daemons telnetd, rsh, finger est rajout dans inetd.conf.
Dordinaire, tr0n se situe dans /usr/src/.puta mais grce la commande ls dj installe, ce
dossier est invisible.
Des contre-mesures ayant t trouves et les possibilits oertes tant restreintes, les concepteurs de
rootkits se sont donc naturellement tourns vers un espace plus privilgi du systme, savoir lespace
noyau.
9
3.2 Ring 0
Au contraire de lespace utilisateur, le ring 0 correspond un niveau privilgi du systme. En eet,
celui-ci rend possible un accs des ressources que les rootkits dcrits ci-dessus ne permettaient pas, car
ne bnciant pas des droits susants.
3.2.1 Exploration de la mmoire noyau
An de lire la memoire noyau il est possible dutiliser, si le noyau le permet, le priphrique /dev/kmem.
Cest la technique utilis par le rootkit suckIT, dont la dernire version est estime a 2003. On ouvre ce
priphrique la manire de nimporte quel chier :
kmem = open(KMEM_FILE, O_RDONLY, 0);
Deux routines sont implmentes pour accder la mmoire noyau via /dev/kmem :
rkm() permet de lire la mmoire une adresse spcie et rcuprer le motif dans un buer.
wkm() permet dcrire dans la mmoire une adresse spcie en paramtre.
Comme le montre limplmentation dcrite dans la gure 3.1, an de lire la mmoire on se place a
ladresse offset et on copie size octets dans buf et pour crire, il sut de se placer au bon oset mmoire,
puis dutiliser les fonctions standards.
static inline int rkm(int fd, int offset, void *buf, int size){
if (lseek(fd, offset, 0) != offset) return 0;
if (read(fd, buf, size) != size) return 0;
return size;
static inline int wkm(int fd, int offset, void *buf, int size){
if (lseek(fd, offset, 0) != offset) return 0;
if (write(fd, buf, size) != size) return 0;
return size;
Fig. 3.1 Implmentation des routines de lecture/criture en mmoire en espace noyau via /dev/kmem
La premere tape de reprage dadresse mmoire est ralise via la premire fonction rkm(). Dans
notre exemple, ceci est implment par le module extract.c de suckIT. Ce module est donc responsable
de rcuprer ladresse de la syscall_table.
ulong get_sct(ulong *i80){
struct idtr idtr;
struct idt idt;
int kmem;
ulong sys_call_off;
char *p;
char sc_asm[INT80_LEN];
asm("sidt %0" : "=m" (idtr)); // Recuperation de IDT
// Ouverture du peripherique /dev/kmem
kmem = open(KMEM_FILE, O_RDONLY, 0);
// Lecture de la 80eme case de IDT (routine syscall_call)
if (!rkm(kmem, &idt, idtr.base +
sizeof(idt)*SYSCALL_INTERRUPT, sizeof(idt))) return 0;
// mise en forme de ladresse syscall_call
sys_call_off = (idt.off2 << 16) | idt.off1;
// recuperation de lensemble de la routine syscall_call
if (!rkm(kmem, &sc_asm, sys_call_off, INT80_LEN)) return 0;
close(kmem);
// Recherche en local par pattern de ladresse de la table dans le code
p = memmem(sc_asm, INT80_LEN, "\xff\x14\x85", 3) + 3;
// mise en forme de ladresse de la syscall_table
10
if (p){
*i80 = (ulong) (p - sc_asm + sys_call_off);
return *(ulong *)p;}
return 0;
Cette tape nous a permis deectuer des reprages mmoires. La deuxime tape consiste poser
des hooks pour dtourner le ux dexcution. Dans notre exemple, les adresses de la syscall_table sont
modies. On crit directement dans cette table ladresse de notre propre fonction, cette action eace donc
la vritable adresse de lappel systme, il est donc ncessaire de la sauvegarder, pour pouvoir lutiliser
potentiellement par la suite lors de limplmentation de notre propre fonction (troisime tape).
3.2.2 Corrompre la table des appels systmes
Comme le montre la gure 3.2, la syscall_table est modie directement. rkm() est utilise pour
sauvegarder ladresse de lappel systme dtourner, et wkm() est utilise pour recrire ladresse de la
fonction. Ladresse crire est celle de notre propre fonction. Dans notre exemple, suckIT tient jour
une structure handlers contenant chaque numro dappel systme, permettant de trouver ladresse
rcrire partir de ladresse de la syscall_table et le pointeur de fonction corrompue, crire en
mmoire lors du hook. Ceci permet de hooker tous les appels systmes en parcourant la structure handlers.
//Mise en place du hook par ecrasement des addresses
while (handlers->nr) {
if ((ulong) handlers->handler){
// Sauvegarde de ladresse
rkm(kmem, sct + (handlers->nr * 4),
handlers->old_handler, 4);
// Ecrasement de ladresse
wkm(kmem, sct + (handlers->nr * 4),
handlers->handler, 4);
}
handlers++;
}
Fig. 3.2 Hook par altration de la syscall_table
3.2.3 Subtil inline Hooking
Il existe un autre moyen de dtourner les appels systmes de manire plus subtile. Cela ncessite de
comprendre en dtail la faon dont fonctionnent les routines bas-niveaux du noyau. La gure 3.3 est issue
dun dump du noyau 2.6.28. La colonne de gauche reprsente les adresses mmoire, au milieu lopcode
et droite linstruction assembleur traduite.
c0403c88 <system_call>:
c0403c88: 50 push %eax
c0403c89: fc cld
--- snip --- snip --- snip --- snip --- snip --- snip ---
c0403cbd: 0f 83 4d 01 00 00 jae c0403e10 <syscall_badsys>
c0403cc3 <syscall_call>:
c0403cc3: ff 14 85 00 3b 65 c0 call *-0x3f9ac500(,%eax,4)
c0403cca: 89 44 24 18 mov %eax,0x18(%esp)
c0403cce <syscall_exit>:
Fig. 3.3 Dsassemblage du noyau dans la zone des appels systmes issus de int 80h
11
La premire tape consiste rcuprer trois pointeurs prcis :
adresse davant lexcution de lappel, not before_call (BC).
adresse daprs lexcution de lappel, not after_call (AC).
adresse de la n de lapel (syscall_Exit), note exit
Ces adresses rcupres, une pseudo table des appels systmes va tre implmente. Une fonction
new_sct va eectuer un switch sur le registre eax pour savoir quel appel est invoqu. Si lappel ne
concerne pas le rootkit, on saute vers before_call. Si lappel est concern, on excute la routine hooke,
puis on saute vers after_call.
Fig. 3.4 Inline hooking sans altration de la SCT
La gure 3.4 rsume les dirents endroits o vont se greer les hooks. On peut aussi distinguer sur
la gure les trajectoires du ux dexcution dans le cas :
dun appel systme normal non concern par le dtournement (COND2).
dune erreur normale dans le systme (COND1).
dun appel systme normal concern par le dtournement.
La faon daccrocher les routines seectue en assembleur directement dans le code du noyaux. Deux
cas sont possibles :
Patch du noyaux : il existe des contraintes de taille, pour ne pas rcrire du code noyau important.
Assembleur dans notre routine : aucune contrainte dans ce cas.
Il existe plusieurs techniques pour accrocher une fonction :
on peut crire un jump en assembleur.
on peut faire un push puis un ret.
on peut faire un call.
La gure 3.4 montre bien quaucune structure de la mmoire noyau nest altre, lexception de
quelques octets pour le premier hook. En ce sens, cette technique est plus subtile, car elle ne touche pas
la tables des appels systmes.
12
3.2.4 Debug Register
Le mcanisme de hook utilisant les registres de debuggages unix ore une ultime furtivit. La gure
3.5 nous montre le droulement de dtournement dun appel systme :
Fig. 3.5 Mise en place du mcanisme de hook via les registres de debug
On peut dcouper quatre phases dans le processus de hook via les debugs :
hook de la routine de debuggage unix.
positionnement de breakpoints xs sur le chemin de tout appel systme.
positionnement dun breakpoint temporaire et sous condition.
dtournement du ux via le registre %eip.
En suivant la chronologie dun appel systme tudi dans une section prcdente, il existe deux
endroits par lesquels le ux dexcution passera obligatoirement. Les breakpoints sont positionns sur
ces deux endroits, sur la routine dinterruption 80 system_call et sur linstruction sysenter. Ainsi,
quelques soit lappel systme dclench, le ux dexcution va se retrouver sur le breakpoint xe et, par
consquent dans la routine de debuggage qui a t pralablement hooke.
Une fois dans notre routine de debuggage, nous avons accs au registre du processeur et nous pouvons
donc savoir si lappel systme est concern par notre hook via le registre %eax. Sil nest pas concern,
rien ne se passe. Sil est concern, un breakpoint est plac prcisment ladresse de lappel systme.
Le ux dexcution reprend son cours, passe par la table des appels systme qui demeure inchange,
puis arrive sur ladresse de lappel systme. Le breakpoint est donc lev et la routine de debuggage
sexcute nouveau. Ce breakpoint est dtruit, do lappellation breakpoint temporaire, puis le registre
%eip contenant ladresse de la prochaine instruction excuter, qui doit tre gale ladresse de lappel
systme, est eac puis remplac par une autre de notre choix.
Cest ici que se situe la force du rootkit. En eet, la table des appels systme nest pas altere, le
systme de debbugage est un systme standard sous unix. Les eets de bord se limitent donc un seul
hook et deux breakpoints. Le breakpoint temporaire nexiste quentre larrive sur system_call et
larrive sur ladresse de lappel systme original i.e. quelques instructions assembleurs. Nous allons dans
la partie implmentation nous baser sur ce mcanisme, en adaptant le code de DR rootkit au noyau
2.6.28.
13
3.3 Ring -1
3.3.1 Systmes virtualiss
La virtualisation est un ensemble de procds logiciels et/ou matriels permettant le fonctionnement
de plusieurs systmes dexploitation sur une mme machine. Ceux-ci se comportent alors comme sils
taient des machines physiques distinctes. Bien que ces techniques datent de 1960, la popularisation des
machines virtuelles a eu lieu au dbut des annes 2000 avec VMware et donna naissance tout un panel
de logiciels libres ou propritaires.
Ensuite, les constructeurs ont quip leurs processeurs dun nouveau jeu dinstructions, ainsi, avec
lapparition des derniers processeurs AMD64 et Intel Dual Core, des mcanismes facilitant la virtualisation
totale ou dfaut la para-virtualisation permettent de raliser le passage entre les direntes machines
virtuelles directement au niveau du processeur.
Il existe donc direntes catgories de virtualisation listes et schmatises ci-dessous :
mulation,
virtualisation totale,
para-virtualisation,
virtualisation matrielle.
GUEST OS
DRI VERS
HYPERVI SOR
Vi r t ual Machi ne
GUEST OS GUEST OS
HOST OS
HYPERVI SOR
DRI VERS DRI VERS DRI VERS
VM
GUEST OS GUEST OS GUEST OS
Emul at i on Vi rt ual i sat i on t ot al e
HOST OS
HOST OS
HYPERVI SOR
Paravi rtual i sati on Vi rt ual i sat i on hardware
HOST OS
DRI VERS DRI VERS
GUEST OS GUEST OS
HYPERVI SOR
HARDWARE HARDWARE
HARDWARE HARDWARE
DRI VERS DRI VERS
GUEST OS
Fig. 3.6 Les dirents modes de virtualisation
Lmulation, qui soppose la simulation ou modlisation, est la reproduction du comportement dun
systme matriel, logiciel ou autre. Les deux points suivants sont les techniques utilises par les logiciels
comme VMware ou Virtualbox et leurs machines virtuelles. Quant au dernier point, il correspond cette
nouvelle gnration de virtualisation lie au processeur.
Le problme pos par les rootkits de type HVM (Hardware Virtual Machine) est quils ninstallent
aucun hook en mmoire, se satisfaisant du rle dhyperviseur leur permettant de grer entirement la
machine et ainsi de brouiller toutes pistes.
Nous allons en voquer deux, Blue Pill, fond sur ce principe de virtualisation matrielle et SubVirt,
reposant sur le principe de virtualisation totale.
14
3.3.2 Blue Pill
BluePill est le premier rootkit HVM public, ralis par Joanna Rutkowska en 2006, et a fait lobjet
de nombreuses publications. La premire version publique (0.11) de BluePill ne supportait que la
virtualisation sur les processeurs AMD. La dernire version (0.32) permet une plus grande souplesse, en
supportant les processeurs AMD et Intel, et galement en crivant directement dans les logs systmes.
Son principe est simple, il permet de faire passer un systme dexploitation en tant que systme
invit et ce, au niveau du processeur. Du fait quil neectue aucun hook, on le prtend indtectable
mais il na malheureusement pas que des avantages. En eet, il ne peut contenir aucune fonction active.
Soit il hooke des fonctions ou structures pour raliser le comportement de rootkits dits classique et
permet des mcanismes de dtection bien connus, soit il surveille les entres/sorties. Cette dernire so-
lution est envisageable dans la thorie mais le cot en temps de traitement serait alors largement augment.
Les deux schmas ci-dessous dcrivent la mthode dinfection de Blue Pill :
RI NG 0
RI NG 3
CPU
Bl ue Pi l l
VMCB
HOST
3
2
1
Fig. 3.7 Avant infection par Blue Pill
RI NG 0
Bl ue Pi l l
VMCB HOST
RI NG 3
CPU
Bl ue Pi l l Hypervi sor 4
6
5
Fig. 3.8 Aprs infection par Blue Pill
1. Chargement du driver,
2. Vrication/Activation la virtualisation matrielle,
3. Allocation des espaces mmoire ncessaire et initialisation des structures,
4. Transfert de lexcution au code de lhyperviseur,
5. Appel de linstruction qui lance la machine virtuelle,
6. Dchargement du driver.
15
Ce genre de rootkit est donc pratiquement indtectable dans la thorie mais en pratique, les ressources
et le temps consomm pour masquer sa prsence pourraient le trahir. On pourrait vouloir se pencher
plus amplement sur ce sujet, malheureusement, la partie la plus intressante du code de Blue Pill nest
disponible que contre la modique somme de 200 000$ payable son auteur. On peut donc se demander
ce que justie ce prix, soit protger linnovation quapporte Blue Pill, soit dissuader la communaut de
dcouvrir lintox quil constiturai.
3.3.3 SubVirt
SubVirt est aussi un rootkit prenant appui sur la virtualisation mais il fonctionne sur un principe
dirent.
Il modie la squence de boot de lOS pour tre lanc avant lui et dmarre son tour le systme
dexploitation en tant que machine virtuelle. Il peut alors intercepter les communications de son invit
1
avec les composants matriels.
La gure 3.9 rsume le principe dinstallation et de fonctionnement de SubVirt :
Avant
HARDWARE
TARGET OS
Aprs
HARDWARE
HYPERVI SOR
TARGET OS
APP APP APP
APP
HOST OS
APP
BAD APP
Fig. 3.9 Avant/aprs infection par SubVirt
Ce rootkit permet de faire passer un systme dexploitation cible dans une machine virtuelle tout
en contrlant le systme hte. Il sassure ainsi de lincapacit de dtection par la cible, celle-ci tant
emprisonne dans la machine virtuelle et nayant pas connaissance du systme hte corrompu.
Comme tout rootkit sappuyant sur la virtualisation, il est dicilement dtectable mais, le fait quil
modie la squence de boot de lOS an de survivre au redmarrage le rend moins furtif. Au contraire de
Blue Pill, il existe quelque moyens de dtections mais ceux-ci restent relativement inecaces.
1
guest OS
16
Chapitre 4
Elaboration dun rootkit
Nous allons dcrire dans cette section les modules noyaux que nous avons crit et qui fonctionnent.
Ceux ci ont t completement rcrit mais largement inspirs des codes sources des rootkits enyelkm et
dr rootkit.
4.1 Gnralit
Nous avons tent au cours de ce projet dlaborer plusieurs implmentations de dtournement dappels
systme en utilisant plusieurs techniques - actuelles - dveloppes dans les sections prcdentes.
Cette implmentation a pour but dtayer nos propos et deectuer une preuve de concept de dtourne-
ment dun appel systme sur un noyau linux 2.6.28.
Les contraintes prises en comptes peuvent se ramener aux propositions suivantes :
compilation et excution stable sur un noyau linux 2.6.28.
modularit relative aux fonctions hookes (voir section suivante).
pouvoir dcrire et tester plusieurs principes de hook et montrer leurs limites.
Nous allons tudier dans la section suivante la conception des modules :
4.2 Conception
Lide gnrale de notre projet est de permettre facilement lajout dun hook dun appel systme
de faon simple. Notre rootkit va se composer de deux modules, un modules gnral et un module client.
Le module gnral soccupe de mettre en place le hook. Nous avons pour linstant autant de modules
gnraux que de mcanismes de hook. Idalement, ces mcanismes pourraient tre fusionns dans un seul
module qui proposerait le choix de la mthode de hook.
Le module client contient lensemble des fonctions hookes. On dispose dans ce module de variables
globales pointant sur des adresses prcises en mmoire
1
. Pour recrire un appel systme, aucune informa-
tion spciale nest ncessaire. Un ensemble de macro, dni dans arch/x86/include/asm/unistd_32.h,
dnissent lindex de chaque appel systme dans la table des appels systme en fonction de leur nom.
Par exemple, lappel systme kill est dans la 37eme case de la syscall_table, une macro est denie
pour permettre dutiliser ce nombre sans le connaitre :
#define __NR_kill 37
Ainsi lors de lcriture de notre routine, il est trs simple de savoir ladresse de la fonction originale
que lon rcrit, elle se situe ladresse sct_glb[__NR_kill], avec sct_glb ladresse de la table des
appels systme, qui est une variable globale.
1
cf la section sur les variables globales.
17
La gure 4.1 montre comment les modules intragissent entre eux. Aprs avoir choisi, avant compila-
tion, la mthode de hook utilise, bleu ou rouge sur la gure, et aprs avoir crit et link lensemble des
fonctions hookes, le module noyau sera fonctionnel et dtournera les appels systmes demands et crits
dans les chiers prxs par hook_, avec la mthode slectionne.
Fig. 4.1 Dcoupage de nos implmentations
4.3 Implmentations
Deux techniques ont t implmentes dans ce projet.
altration de la table des appels systme (dirty hook).
utilisation des breakpoints unix sans altration de la table des appels (pretty hook).
Les deux techniques abordes ncessitent une phase de recherche dinformations ou dadresses. Nous
allons traiter dans une premire sous-section les direntes implmentations ralises dans le but de
rechercher ces adresses, qui sont communes nos deux implmentations. Ensuite nous tudierons le dirty
hook, et enn nous dcrirons notre implmentation du hook utilisant les registres de debug.
4.3.1 Recherche dinformations gnrales
Nous avons dcrit dans la premire section, sur les rappels, le cheminement dun appel systme. Toutes
les implmentations de rootkits LKM doivent, obligatoirement, connaitre un certain nombre dadresses :
adresse de linterruption 80 system_call.
adresse de lentre sysenter ia32_sysenter_target.
adresse de la table dappel systme sys_call_table.
De faon gnrale, un hook va remplacer ladresse dune fonction dorigine par une fonction hooke. Sil
est facile daccder ladresse de la fonction hooke, car nous la codons dans notre module, il est moins
18
facile de trouver celle dorigine. Cela devient trs simple avec ladresse de la table des appels systme.
En eet, pour xer les ides, le numro de lappel systme kill est 37. Ladresse originale sobtient
donc en sommant ladresse de la table avec 37 * 4 octets, car la table contient des cases de 4 octets,
qui correspondent aux adresses des appels. Plus simplement, en copiant ladresse de la table directement
dans un pointeur de tableau, on peut accder la fonction kill originale en prenant la 37me case. Nous
utilisons la deuxime mthode comme le montre la gure 4.2.
asmlinkage static int hacked_kill(int pid, int sig)
{
void **sys_p = (void **)sct_glb; /* prealablement calculee */
asmlinkage long (*original_sys_kill)(int pid, int sig) = sys_p[37];
Fig. 4.2 Rcupration de la fonction dorigine
Interrupt Descriptor Table
Cest la premire adresse trouver, et aussi la plus simple. Cette table contient toutes les routines
dinterruption. Le processeur stocke son adresse dans un registre, il est donc possible de la rcuprer via
une commande assembleur :
asm ("sidt %0" : "=m" (idtr));
base = *((uint32_t *) &idtr[2]);
Comme dcrit dans une section prcdente, chaque case de lIDT est compose de 8 octets. On trouve
par consquent les interruptions 1 et 80 avec :
sys = (uint32_t *)(base + (0x80*8));
deb = (uint32_t *)(base + (0x01*8));
Les premiers octets reprsentent les bits de poids forts, les derniers octets ceux de poids faibles, on
choisit de mettre toute la case dans une structure, et de calculer ladresse :
memcpy(&desc, (void *) sys, sizeof(desc));
sum_up = (uint16_t)(desc.off_high) << 16 ;
sum_down = (uint16_t) desc.off_low ;
int80_glb = sum_down + sum_up;
Rcupration de la table des appels
Il sut dobserver la gure 3.3 pour dcouvrir quil sut de partir de la routine dinterruption
80 system_call, puis rechercher le motif ff 14 85 pour avoir ladresse de la table des appels
sys_call_table. Le code suivant ralise cette tche.
uint8_t *p = (uint8_t *) int80_glb;
while (!((p[0] == 0xff) && (p[1] == 0x14) && (p[2] == 0x85)))
p ++;
sct_glb = (uint32_t **)*(uint32_t *)(p+3);
Variables Globales
Nous avons dcid dans un premier temps, de globaliser les variables-cls prcedemment dcrites :
extern uint32_t int1_glb; /* Adresse interruption 1 */
extern uint32_t ** sct_glb; /* Adresse table des appels */
extern uint32_t int80_glb; /* Adresse interruption 80 */
extern uint32_t do_deb_glb; /* Adresse routine de debuggage unix */
extern uint8_t *pointer_offset; /* Adresse de base pour le calcul dun offset */
19
4.3.2 Recherche complmentaire pretty hook
Dans le cas du pretty hook, il nous faut des informations supplmentaires, sur le droulement des
routines de debuggage unix :
adresse de la routine dinterruption 1 debug.
adresse de la routine de debuggage unix do_debug
Linterruption 1 se calcule de la mme faon que linterruption 80.
rcupration de do_debug
Aprs avoir observ le chier entry.S ou bien objdump le noyau et regard ladresse de linterrup-
tion 1, on constate que cette routine appelle la routine de debuggage unix do_debug.
On recherche donc lopcode e8 responsable du call an de rcuprer loset de la fonction. Comme
le montre la gure 4.3, lorsque la routine debug est excute, lappel de la sous-routine do_debug est
calcule ladresse c064e602, en sommant ladresse de base c064e607 avec loset, entre crochets sur la
gure. Cet oset est 6dd. Ainsi, ladresse de do_debug est rcuprable via le rsultat de laddition. En
eet, 0xc064e607 + 0x6dd = 0xc064ece4.
c064e5c0 <debug>:
c064e5c0: 81 3c 24 64 3b 40 c0 cmpl $0xc0403b64,(%esp)
c064e5c7: 75 17 jne c064e5e0 <debug_stack_correct>
c064e5c9: 66 83 7c 24 04 60 cmpw $0x60,0x4(%esp)
c064e5cf: 75 0f jne c064e5e0 <debug_stack_correct>
--- snip --- snip --- snip --- snip --- snip --- snip --- snip --- snip ---
c064e602: e8 [dd 06 00 00] call c064ece4 <do_debug>
c064e607: e9 14 55 db ff jmp c0403b20 <ret_from_exception>
--- snip --- snip --- snip --- snip --- snip --- snip --- snip --- snip ---
c064ece4 <do_debug>:
c064ece4: 55 push %ebp
c064ece5: 89 e5 mov %esp,%ebp
Fig. 4.3 Dump du noyau dans la plage dadresse relative au debug
4.3.3 Mise en place dirty hook
Le premier hook consiste altrer la table des appels systme. La gure 4.4 dcrit notre implmenta-
tion, basique, du hook. Il sagit dcrire brutalement ladresse de notre fonction l o le noyau appelle la
fonction originale. Notons quun module noyau calculant un checksum de la table des appels systmes a
intervalles rguliers peut reprer ce hook de faon immdiate.
void set_dirty_hook(int num, uint32_t hook)
{
old_sys_glb = (uint32_t)sct_glb[num];
sct_glb[num]= (uint32_t)hook;
}
void unset_dirty_hook(int num)
{
sct_glb[num] = old_sys_glb;
}
Fig. 4.4 API dirty hook
20
En eet, ladresse de la fonction hooke persiste longuement en mmoire. An de passer outre ce
problme, nous pouvons penser deux solutions :
changer cette adresse uniquement dans le laps de temps o seectue lappel. Quelques microsecondes
rendent le diagnostic plus complexe. Cest une solution dcrite dans Phrack.
crer une autre table des appels. Cest la solution adopte par Enyelkm.
modier en temps rel la valeur du registre eip an que pile au moment o la fonction est appele,
nous mettons ladresse de notre fonction dans ce registre. Cest la solution que nous pensons plus
subtile, dveloppe dans le rootkit DR rootkit. Nous avons adapt cette solution au noyau 2.6.28.
4.3.4 Mise en place pretty hook
Utilisation des breakpoints
Nous avons construit pour lutilisation des breakpoints, une API en langage C, dcrite par la gure 4.5.
uint32_t get_dr0();
uint32_t get_dr1();
uint32_t get_dr2();
uint32_t get_stat();
uint32_t get_ctrl();
void set_dr0(uint32_t addr);
void set_dr1(uint32_t addr);
void set_dr2(uint32_t addr);
void set_ctrl(uint32_t ctrl);
void set_stat(uint32_t stat);
uint32_t build_ctrl_glb_dr0();
uint32_t build_ctrl_glb_dr1();
uint32_t build_ctrl_glb(void);
uint32_t build_ctrl_dr2(void);
Fig. 4.5 API permettant de piloter les breakpoints unix
Elle est constitue de trois sous-ensembles de fonctions :
fonctions permettant de positionner les breakpoints en crivant dans les registres de debuggage unix :
set_*
fonctions permettant de lire les registres de debuggage unix : get_*
fonctions permettant de construire le ag responsable du pilotage des breakpoints
2
build_*
Le positionnement des breakpoints, xes ou variables peut ainsi se faire facilement. On positionne ainsi
facilement un breakpoint sur linterruption 80 :
set_dr0(int80_glb);
set_ctrl(build_ctrl_glb_dr0());
Hook de do_debug
Le hook de do_debug est ralis par la fonction hack_offset. La gure 4.3 dcrit le dclenchement
de la routine de debuggage lorsquun breakpoint a t relev. Le hook de cette fonction va consister
modier loset, encadr dans la gure, pour quil pointe sur notre propre fonction.
2
cf : section 2.1.3
21
Les informations ncessaires pour mener bien ce hook sont :
adresse de loset (adresse de base).
adresse de notre fonction debug_hooked.
Ladresse de base nous a t donne par la phase de reprage. Ladresse de debug_hooked est
immdiate. Une fois loset calcul, il faut le mettre en forme, comme le montre la gure 4.6.
Les huit premiers bits sont rcuprs avec loperateur & (ET bit--bit). Ce nombre de 32 bit est ensuite
cast en nombre de 8 bits, (les seuls non nuls).
De la mme faon, on rcupre ensuite les bits 8-16, on dcale droite pour former un nombre de 32
bits dont seul les 8 premiers sont non-nuls et on est ramen au cas prcdent, et ainsi de suite.
On commence par les bits de poids faibles car le concept intel (little endian) place les bits de poids
faible dabord, dans le sens de lecture.
pi[1] = (offset & 0x000000ff);
pi[2] = (offset & 0x0000ff00) >> 8;
pi[3] = (offset & 0x00ff0000) >> 16;
pi[4] = (offset & 0xff000000) >> 24;
Fig. 4.6 Mise en forme dune adresse en little endian
22
Chapitre 5
Conclusion
Au cours de ce projet, nous avons pu acqurir une vision plus prcise des mcanismes de hook
et des fonctionnements bas-niveaux des appels systme. La lecture de plusieurs codes, nous a permis
dapprhender de faon globale le problme des detournement.
Nous avons recueilli pour ce mmoire un ensemble dinformations prexistantes dans le but de les
catgoriser selon certains critres, comme leur localisation ou leur furtivit. Lintrt tait de donner au
lecteur une vue globale et actuelle des rootkits.
Aprs avoir tudi les mcanismes de hook avec des exemples concrets dimplmentation, nous avons
dans ce projet pu eectuer une preuve de concept pour dtourner un appel systme sur les noyaux
2.6.28. En nous inspirant de DR rootkit et Enyelkm, nous avons construit notre module noyau, dont la
conception permettra de greer assez aisment dautres fonctionnalits.
Techniquement et a fortiori, nous avons pu constater que linstallation de ce type de rootkit ne
constitue pas une grande dicult, malgr les modications mises en place dans les dernires versions du
noyau. Notons que nous avons travaill sur un noyau dont la protection dcriture sur les pages mmoires
a t dsactive lors de la compilation. Il est nanmoins possible doutrepasser cette protection laide
des mmes mcanismes qui la ralisent.
On peut supposer, du fait de lapparition exponentielle des rootkits lors de ces dernires annes,
que de nombreuses nouvelles techniques seront - ou sont dj - dveloppes, notamment celles lies la
virtualisation.
23
Table des gures
2.1 Droulement dun appel systme apres int80h . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Chronologie et complexication des rootkits sous Linux . . . . . . . . . . . . . . . . . . . 7
3.1 Implmentation des routines de lecture/criture en mmoire en espace noyau via /dev/kmem 10
3.2 Hook par altration de la syscall_table . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Dsassemblage du noyau dans la zone des appels systmes issus de int 80h . . . . . . . . 11
3.4 Inline hooking sans altration de la SCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5 Mise en place du mcanisme de hook via les registres de debug . . . . . . . . . . . . . . . 13
3.6 Les dirents modes de virtualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.7 Avant infection par Blue Pill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.8 Aprs infection par Blue Pill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.9 Avant/aprs infection par SubVirt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1 Dcoupage de nos implmentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Rcupration de la fonction dorigine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 Dump du noyau dans la plage dadresse relative au debug . . . . . . . . . . . . . . . . . . 20
4.4 API dirty hook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5 API permettant de piloter les breakpoints unix . . . . . . . . . . . . . . . . . . . . . . . . 21
4.6 Mise en forme dune adresse en little endian . . . . . . . . . . . . . . . . . . . . . . . . . . 22
24
Bibliographie
[1] Eric Filliol Anthony Desnos. Dtection oprationnelle des rootkits hvm ou quand la recherche remplace
le buzz. MISC, 42, 2009.
[2] D. Bovet, M. Cesati, and A. Oram. Understanding the Linux kernel. OReilly & Associates, Inc.
Sebastopol, CA, USA, 2002.
[3] Eddy Deligne. Rootkit lkm : Enyelkm. 2009.
[4] Halfdead. Mystifying the debugger for ultimate stealthness. Phrack, 61(0x08), 2006.
[5] J. Kong. Designing BSD Rootkits. No Starch Press San Francisco, CA, USA, 2007.
[6] E. Lacombe, F. Raynal, and V. Nicomette. De linvisibilite des rootkits : application sous Linux.
25