Backdoors et rootkits avancs

Nicolas Dube
St Secway
ndubee@secway.com

Backdoors avances
Nicolas Dube

p. 1/19

Rsum
La confiance envers ses systmes de surveillance est un composant essentiel dune scurit
matrise. Hollywood est grand consommateur de la notion, avec lingrdient essentiel de tout
bon film daction le gardien et sa camra de surveillance tromps par une photographie
plante juste devant. Les concepteurs des logiciels actuels semblent pourtant avoir oubli ces
prceptes simples ; derrire la complexit des systmes dinformation et des moyens mettre
en uvre pour les protger se cache le vice des fondations. A qui se rfrer lorsque aucune des
composantes du systme na t prvue pour assurer cette base de confiance dont les
applications auraient tant besoin ? Cet expos tentera dillustrer la notion de base de confiance
et son application aux systmes dexploitation actuels. Au travers de lexemple de rootkits
kernel sous Solaris, nous dmontrerons comment les meilleurs logiciels de scurit sont mis
en dfaut par la compromission du systme dexploitation sous-jacent.
Abstract
Trust in your monitoring systems is a key component in a well-designed security. Hollywood
movies are great consumers of this idea, with the essential ingredient of every good robbery
movie the security guard and his security console being fooled by a picture put just in front of
the camera However, the computer industry seems to have forgotten those simple concepts;
behind the complexity of todays information systems and the means aimed at securing them
stands flawed foundations. Who can we refer to when none of the components of the system
has been designed to ensure the trust applications need? This document will show the notion of
trust base and its application to modern operating systems. Through the example of so-called
kernel backdoors, we will explain how the best security software can be defeated by the
compromising of the underlying operating system.

Backdoors avances
Nicolas Dube

p. 2/19

1.
2.

Introduction ............................................................................................................................ 4
Les systmes dexploitation modernes .................................................................................. 4
2.1
Dfinitions ...................................................................................................................... 4
2.2
Modles actuels............................................................................................................. 4
2.3
Fonctionnalits de scurit des systmes dexploitation ............................................... 7
2.4
Le paradigme de lutilisateur root................................................................................... 9
3. Compromission totale dun systme par modification du kernel .......................................... 11
3.1
Mise en vidence......................................................................................................... 11
3.2
Techniques usuelles .................................................................................................... 12
3.2.1
Dissimulation de processus ................................................................................. 13
3.2.2
Dissimulation de fichiers ...................................................................................... 14
3.2.3
Excution dtourne ............................................................................................ 14
3.2.4
Backdoors rseaux .............................................................................................. 15
3.3
Importance du problme.............................................................................................. 16
3.4
Solutions ...................................................................................................................... 17
3.4.1
Dtection post intrusion ....................................................................................... 17
3.4.2
Prvention............................................................................................................ 18
4. Conclusion ........................................................................................................................... 19

Backdoors avances
Nicolas Dube

p. 3/19

1. Introduction
La confiance envers ses systmes de surveillance est un composant essentiel dune scurit
matrise. Hollywood est grand consommateur de la notion, avec lingrdient essentiel de tout
bon film daction le gardien et sa camra de surveillance tromps par une photographie
plante juste devant. Linformatique semble pourtant avoir oubli ces prceptes simples ;
derrire la complexit des systmes dinformation actuels et des moyens mettre en uvre
pour les protger se cache le vice des fondations. A qui se rfrer lorsque aucune des
composantes du systme na t prvue pour assurer cette base de confiance dont les
applications auraient tant besoin ? Cet expos tentera dillustrer la notion de base de confiance
et son application aux systmes dexploitation actuels. Au travers de lexemple de backdoors
kernel sous Solaris, nous dmontrerons comment les meilleurs logiciels de scurit sont mis
en dfaut par la compromission du systme dexploitation sous-jacent.

2. Les systmes dexploitation modernes

2.1 Dfinitions
Une backdoor est une porte drobe logicielle permettant un pirate de revenir ou dlever ses
privilges plus facilement sur le systme.
Un rootkit est une modification non autorise dun ou plusieurs composants lgitimes existants
du systme, compromettant son intgrit et changeant son fonctionnement normal. Un rootkit
peut par exemple dsactiver les fonctions de journalisation des vnements, ou insrer des
backdoors dans les programmes critiques du systme.
De ce fait, un rootkit est souvent un pack implantant sur un systme un ensemble de backdoors.
Mme sils ne se rfrent pas strictement la mme notion, nous utiliserons les deux termes
rootkits et backdoors de faon interchangeable dans la suite du prsent document.

2.2 Modles actuels

Au cur de tout systme informatique, le systme dexploitation est devenu bien plus que la
simple interface matriels-logiciels traditionnelle et est maintenant, derrire une faade simple,
un logiciel trs complexe.

Backdoors avances
Nicolas Dube

p. 4/19

Figure 1: Modlisation d'un systme d'exploitation

Le modle de rfrence est constitu de deux niveaux ou modes de fonctionnement :

-

Un mode noyau, mode privilgi dans lequel tourne le cur mme du systme
dexploitation, souvent appel kernel et dcoup en de nombreux ples de
fonctionnalits.

Ce mode est dit privilgi car il dispose dun accs et un contrle complet toutes les
ressources matrielles ou logicielles du systme ; de ce fait le systme dexploitation est
souvent considr comme linterface entre les applications et le matriel.
Chaque ple peut mettre ses services directement disposition des processus grce
linterface des appels systmes. Les appels systmes constituent un mcanisme permettant aux
processus dappeler des fonctions donnes du kernel. Ces fonctions, environ 200 sur les
systmes Unix traditionnels, sont les primitives de base de toutes les oprations dentre-sortie,
de gestion de la mmoire, des processus, . Ainsi, louverture et la lecture dans un fichier se
font par les appels systme open() puis read(), mises disposition par le ple gestion des
fichiers (VFS) du kernel.

Backdoors avances
Nicolas Dube

p. 5/19

Le ple gestion mmoire soccupe de grer la vision mmoire de chaque processus en relation
avec la mmoire physique. Cette correspondance est faite par lintermdiaire de morceaux de
mmoire appels pages . Dautre part, le ple gestion des processus travaille pour organiser
les processus, de leur cration jusqu leur mort en exportant des fonctions de cration de
processus (fork()), de rglage des priorits, de gestion des signaux.
Le systme propose aussi un accs transparent par un mcanisme dit VFS de nombreux
types de systmes de fichiers, aussi bien des systmes de fichiers classiques servant
grer les arborescences sur des disques physiques que des systmes de fichiers virtuels
complexes comme procfs, specfs. Procfs permet, via la hirarchie dynamique /proc, un accs
aux informations dtat sur chaque processus du systme (un rpertoire par processus actif).
Sur de nombreux systmes Unix, la commande de liste des processus en cours dexcution ps
est implmente en parcourant larborescence /proc. Specfs propose quant lui un accs de
type fichiers aux ressources matrielles grce larborescence /dev.

Figure 2: Aperu de la hirarchie proc pour le processus 116

La gestion des fichiers et priphriques est implmente en utilisant largement des dispatchs,
(aiguillages) : un ensemble de fonctions de base est dfini, chaque pilote systme de fichiers ou
priphrique est tenu dimplmenter ces fonctions de base. Celles-ci incluent par exemple
open(), read(), write() et close(). Chaque pilote exporte alors au kernel la liste des fonctions qui
implmentent ces appels standards, une table des correspondances est ainsi cre :
fat_open()
implmente open() pour le systme de fichiers FAT
fat_read()
implmente read() pour le systme de fichiers FAT
fat_write()

Quand un programme ouvre un fichier, il appelle la fonction gnrique open(). Le kernel dtecte
alors quel est le type de priphrique ou de systme de fichiers derrire le fichier demand en
ouverture,et appelle grce la table des correspondances la bonne fonction open().
-

un mode utilisateur, dans lequel tournent des applicatifs appels processus, formes
vivantes des programmes stocks sur disque.

Chaque processus sexcute en tant quun utilisateur donn, dans un contexte qui lui est propre
et dans un espace mmoire virtuel gr par le systme dexploitation. Il na aucune vue directe
des autres processus, de leur mmoire, ou mme des ressources matrielles. Il doit
obligatoirement se rfrer au systme dexploitation par lintermdiaire des appels systmes
pour accder aux ressources systmes ou communiquer avec les autres processus.
Ces processus sont traditionnellement crs par un appel systme appel fork(), et le fils ainsi
cr par un appel fork() est une copie conforme mais compltement indpendante du parent,
qui continue normalement son excution. Ainsi, chaque processus cr hrite des paramtres
Backdoors avances
Nicolas Dube

p. 6/19

du pre, notamment de son contexte de scurit, cest--dire de lutilisateur sous lequel il

sexcutait.

2.3 Fonctionnalits de scurit des systmes dexploitation

Les systmes dexploitation modernes fournissent de nombreuses fonctionnalits de scurit.
Cependant, limplmentation de telles fonctionnalits nest la plupart du temps pas ralise au
cur mme du systme dexploitation (kernel), mais largement dans des applicatifs mode
utilisateur fournis avec le systme. Ainsi, linvite de login Unix nest rien dautre quun
programme aucunement particulier, sinon quil est lanc au dmarrage par un autre processus
(init) ou par les gestionnaires de liaisons rseaux (telnetd). Dun point de vue machine, rien ne
diffrencie /bin/login dautres programmes, le coeur du systme dexploitation ignore
compltement le rle si crucial de login.

Figure 3: Programmes /bin/ls et /bin/login sur Sun Solaris 2.6

On peut alors se demander comment sont ralises les oprations de scurit ncessites par
/bin/login, telles que la vrification des mots de passe et le chiffrement de donnes. Ces
fonctionnalits ntant pas considres comme des oprations canoniques, elles ne sont pas
implmentes dans le kernel du systme, mais dans un ensemble de librairies dynamiques lies
aux applicatifs eux-mmes, et sexcutant donc dans leur contexte.
Ainsi, le programme /bin/login vrifie le couple (login, mot de passe) fourni par lutilisateur qui
souhaite sauthentifier. Cette vrification est faite en interrogeant la base des utilisateurs Unix du
fichier /etc/passwd. Les fonctions getpwent(),getpwnam(),getpwuid() implmentes dans la libc
soccupent de cette interrogation ; elles vont elles-mmes appeler les appels systmes
douverture de fichier (open()) et de lecture (read()) afin de lire squentiellement les lignes de la
base des mots de passe /etc/passwd et vrifier la correspondance avec les informations
dauthentification entres par lutilisateur. Une fois lutilisateur trouv dans la base, /bin/login
construit un nouvel environnement pour excuter le shell qui sera prsent lutilisateur. Ce
nouvel environnement devant sexcuter sous lidentifiant (uid) de lutilisateur en question,
/bin/login effectue alors un appel systme setuid() permettant de positionner lidentifiant
utilisateur du processus appelant (cest--dire du nouvel environnement). Le seul contrle
effectu par le kernel avant dautoriser lopration setuid() consiste vrifier que le processus
appelant sexcute jusqualors en tant que root, le super-utilisateur Unix.

Backdoors avances
Nicolas Dube

p. 7/19

Figure 4: droulement d'une session de login

Comme nous pouvons voir du diagramme prcdent, lentre sur le systme dun utilisateur
(cest--dire, la vrification de ses informations dauthentification et la cration de son
environnement) est compltement la charge de processus sexcutant en mode utilisateurs,
avec une aide minime du kernel.
En effet, les fonctionnalits de scurit offertes par la plupart des kernels actuels ne concernent
que deux aspects :
- la protection des processus entre eux, notamment au niveau de la gestion
mmoire. De ce fait, deux processus voulant communiquer sont obligs de le faire par
lintermdiaire de fonctionnalits offertes par le kernel, aucune communication directe
purement mode utilisateur nest possible. La protection des processus est un lment
extrmement important des systmes dexploitation, notamment en terme de fiabilit et
de disponibilit du systme car cest ce mcanisme qui assure aussi quun processus
nentrane pas dans sa chute dautres processus. En terme de scurit, la
communication entre processus peut tre suivie de manire fine par le systme
dexploitation puisque toute communication impliquera des appels systmes.
- la scurit du systme de fichiers. Cest le kernel, au niveau de primitives syscall
telles que open(), read(), write(), close(), qui gre les permissions sur les objets du
Backdoors avances
Nicolas Dube

p. 8/19

systme de fichiers au sens large (dont socket rseaux, ). La notion didentifiants

utilisateurs et groupes est largement associe la scurit du systme de fichiers.
la gestion des identifiants dutilisateurs (uid) et de groupes (gid), au moyen
dalgorithmes simples (possibilit de passer de luid 0 une uid quelconque sans
restriction, opration inverse possible dans certains cas seulement).

Ainsi un outil de dtection dintrusion locale comme Tripwire1 met chronologiquement en jeu
les fonctionnalits de scurit kernel suivantes pour assurer son bon fonctionnement :
- Avant son excution, scurit du systme de fichiers, afin dviter que le binaire luimme de Tripwire ne soit remplac par un cheval de Troie ignorant les modifications
commises au systme par le pirate.
- Durant son excution
o Protection des processus, pour empcher la modification dynamique de la
mmoire (code, donnes) du processus Tripwire par un autre processus pirate
situ sur la machine. Ce processus pirate pourrait par exemple prendre au vol le
contrle de la mmoire du processus Tripwire et modifier le code de vrification
des fichiers pour quil saute les fichiers qui ont t modifis par le pirate, ceci
sans avoir besoin de toucher le binaire Tripwire prsent sur disque.
o Scurit du systme de fichiers, garantissant que les fichiers qui sont
prsents Tripwire lorsquil les ouvre pour en effectuer des vrifications sont
bien ceux stocks sur disque et utiliss par le systme. Tripwire repose ainsi sur
le fait que le kernel offre la mme vision des fichiers pour tous les processus.

2.4 Le paradigme de lutilisateur root

Le super utilisateur root est sans doute une des caractristiques les plus connues des
systmes Unix. Issus dun hritage historique fort, prcdant larrive massive des rseaux, les
utilisateurs Unix sont grs sous le modle du tout ou rien :
- dune part, des utilisateurs non privilgis, identifis par leur login/mot de passe mais
surtout de manire interne par un uid entier strictement suprieur 0 sont restreints dans
leurs actions sur les processus/fichiers/,
- dautre part un utilisateur spcial, dit root correspondant en interne luid 0 dispose
de tous les pouvoirs sur tous les objets du systme : aussi bien fichiers que ressources
et processus.
Si pour ladministrateur, qui doit accder des fonctionnalits critiques, ajouter des utilisateurs
ou des services, lutilisateur root trouve toute son application, au niveau systme lui-mme, les
attributions de root sont pour le moins obscures. On pourrait en effet rsumer par le simple fait
que lutilisateur root est, du point de vue kernel, un utilisateur fourre-tout nayant aucune
restriction :
- manipulation complte de tous les objets du systme de fichiers
- accs sans restrictions aux priphriques
- accs complet la mmoire
o mmoire utilisateur : prise de contrle dautres processus, consultation de leur
mmoire et mme modification (modification dynamique du code ou des
donnes)
1

Logiciel de vrification de lintgrit des fichiers, http://www.tripwire.com/

Backdoors avances
Nicolas Dube

p. 9/19

mmoire kernel : consultation pour surveillance de lexploitation et modification au

vol des paramtres kernel (tuning ou ajout de fonctionnalits, pilotes
priphriques, )

De ce fait, tout programme lanc avec les privilges root naura sur son chemin aucune barrire
de scurit.
Malheureusement, le modle prcdent induit des effets transitoires forts dsagrables.
Beaucoup de fonctions systmes tant lgitimement restreintes lutilisateur root, nombre de
programmes cruciaux ncessitent davoir au moins un bout de leur excution effectue en tant
que root. Tout processus devant un moment donn accder une fonction privilgie devra
tre root au minimum de son dbut jusqu lappel lui-mme de la fonction en question.
Cest par exemple le cas des processus serveurs rseaux tels que les serveurs http ou dns,
devant obligatoirement tre dmarrs en tant que root pour pouvoir sattacher au port TCP/UDP
dcoute correspondant2. Ainsi, pour environ 10 lignes de code privilgi, des serveurs rseaux
complexes ncessitent des privilges levs quils gardent bien souvent par la suite.
La suite a trs certainement dj t vcue par la plupart des administrateurs systmes :
vulnrabilit sur tel processus serveur (DNS par exemple) permettant une prise de contrle du
processus, de son chemin dexcution et donc possibilit pour le pirate dexcuter distance
nimporte quel code, directement en tant que root.
Dans la suite du document, nous nous intresserons aux possibilits qua un pirate, pass root
sur un systme Unix, pour viter dtre dtect et sy maintenir de faon aise. En particulier,
nous verrons comment un agresseur peut rendre inefficients tous les systmes de scurit et de
dtection dintrusion ds lors quil est root, en modifiant la base de confiance quest
normalement le systme dexploitation.

Ceci car les fonctions de mise en coute TCP/UDP interdisent aux utilisateurs normaux de se mettre en
coute sur les ports infrieurs 1024 (dits ports privilgis, ceci pour viter que les utilisateurs ne
simulent des serveurs lgitimes en se mettant en coute sur des ports privilgis standards).

Backdoors avances
Nicolas Dube

p. 10/19

3. Compromission totale dun systme par modification du

kernel
3.1 Mise en vidence
Nous avons pu ainsi constater que, par manque de fonctions scurit critiques, la plupart des
systmes actuels sont compltement vulnrables une faille localise sur un de leurs
composants logiciel. Afin dillustrer cette affirmation, nous allons maintenant tudier un exemple
des possibilits qua un pirate ayant obtenu laccs root sur un serveur pour le compromettre
compltement, jusqu rendre inoprants tous les moyens de scurit de la machine en
question.
Une des fonctionnalits spcifies prcdemment dans les possibilits de lutilisateur root tait
le paramtrage et la modification du kernel.
Alors que ces oprations sont impossibles pour un utilisateur normal, root dispose de plusieurs
faons pour modifier un kernel Unix :
-

modification des fichiers kernels eux-mmes

Ces fichiers (/platform/platform-name/kernel/unix et /kernel/genunix sous Solaris) constituent

les programmes du kernel stocks sur disque, exactement comme tout autre logiciel dispose
dau moins un fichier excutable sur disque. Ils sont chargs au dmarrage de la machine par
un mini programme dit bootstrap, et leur accs, lors de lexcution, est limite par permissions
comme tout autre fichier.
La modification des fichiers du kernel sera effective au prochain dmarrage du systme. Avant
cela, les modifications faites aux fichiers kernel sont facilement identifiables puisque le code de
mise en chec des logiciels de surveillance na pas encore t charg. Cette manipulation est
donc peu pratique pour un pirate qui ne peut risquer se faire dtecter en redmarrant le
systme. Dautre part, bien souvent (cas des systmes commerciaux) les sources du kernel ne
sont pas disponibles ; les modifications sont donc extrmement dlicates raliser. Cependant,
cette mthode assure que les modifications effectues survivront aux redmarrages de la
machine et seront en place longtemps, le kernel tant rarement mis jour. Elle est donc utilise
assez couramment en conjonction avec dautres mthodes.
-

Ajout au vol de pilotes priphriques ou de modules

Une des fonctionnalits attendues dun systme dexploitation actuel est quil soit modulaire :
que lajout de priphriques et donc des pilotes correspondants se fasse le plus facilement
possible. Dans cette optique, de nombreux systmes Unix proposent lajout dynamique par root,
sans redmarrage, de bouts de code dits modules ou LKM , tels que des pilotes
priphriques. Ces modules peuvent tre chargs dans le systme dexploitation la vole
Backdoors avances
Nicolas Dube

p. 11/19

grce des commandes simples. Ils sont alors digrs par le kernel et sexcutent en mode
privilgi dans ce dernier, ayant un accs complet et sans restriction lensemble du systme.
Lide dutiliser cette fonctionnalit lgitime des systmes dexploitation modernes3 a t
introduite ds 1995 sur les systmes libres et popularise par plusieurs articles4 techniques en
1997, agrments des premiers codes publics (Linux et FreeBSD). De nombreux kits sont
maintenant disponibles pour modifier de la sorte des kernels Solaris ou Linux, FreeBSD, .
-

Modification au vol de la mmoire du kernel

La mmoire tant un priphrique comme un autre, un fichier spcial /dev/mem lui est souvent
associ qui permet la lecture et la modification de la mmoire physique. Lcriture une position
donne dans ce fichier entrane la modification de la zone mmoire correspondante. De
mme, le fichier /dev/kmem est associ la mmoire virtuelle du kernel. Ces deux mthodes
permettent un accs commode la mmoire, vue comme un fichier.
Si un de ces fichiers est accessible en criture, un agresseur peut injecter du code en crivant
dans la mmoire comme dans un fichier, et remplacer par exemple certains appels systmes
sensibles par ses propres versions, pourvues de portes drobes.

Cette technique, assez peu rencontre en pratique car trs dlicate techniquement (la moindre
erreur dun octet peut dtruire le systme) a cependant t dmontre comme ralisable, et des
outils dinjection de la sorte seraient disponibles dans certains cercles pirates. La mthode de
prdilection reste celle des modules ; plusieurs kits sont disponibles dans le domaine public
utilisant les modules pour injecter du code dans le noyau et en modifier le comportement.
Un pirate ayant obtenu laccs root une machine peut donc, en utilisant des fonctionnalits
lgitimes du systme, modifier le systme dexploitation son gr afin dtre invisible aux
systmes de surveillance locaux et ladministrateur. Nous allons maintenant voir quelles sont
les possibilits et les techniques communment implmentes.

3.2 Techniques usuelles

En modifiant le cur mme du systme dexploitation, le pirate contrle tous les applicatifs qui
tournent sur la machine. Il peut leur prsenter une vue biaise de lactivit du systme, et na
donc plus, comme avec les backdoors traditionnelles, besoin de modifier tous les programmes
de surveillance un un. Les buts recherchs sont le maintien ais sur le systme (en particulier,
pouvoir revenir facilement, sans avoir drouler lintrusion une nouvelle fois) et la dissimulation
de ses fichiers, de ses processus, de son activit en gnral. Cette dissimulation doit tromper
aussi bien ladministrateur que les outils automatiques de dtection.

3
4

Quasiment aucun systme Unix moderne nest dpourvu de cette fonctionnalit.

Halflife, Bypassing integrity checking systems, Phrack 51/9
Plaguez, Weakening the Linux kernel, Phrack 52/18

Backdoors avances
Nicolas Dube

p. 12/19

3.2.1 Dissimulation de processus

Dissimuler des processus est une des premires proccupations du pirate. En effet, la
commande de listing des processus actifs ps est sans doute, avec ls, la commande la plus
utilise sur un systme Unix. En dissimulant ses propres processus, le pirate peut laisser sans
crainte sniffers5, portshell6, .
Plusieurs mthodes existent pour lister les processus actifs sur un systme. Toutes ces
mthodes reposent sur une interrogation du systme dexploitation, qui est le seul mme de
fournir cette liste.
Trs souvent, la liste des processus est obtenue en parcourant le rpertoire virtuel /proc, qui
contient un sous-rpertoire par processus actif. Afin de mettre en dfaut les programmes
reposant sur /proc, la backdoor kernel modifie la partie VFS du kernel, et en particulier les
fonctions douverture et de lecture des rpertoires. En remplaant les fonctions originales par
ses propres fonctions qui omettent de crer des sous-rpertoires pour les processus cacher, le
pirate dissimule les processus quil souhaite.

Figure 5: Remplacement par un module de la fonction systme proc_readdir par une fonction
dissimulant les processus pirates. Lorsquun processus cherche lister le contenu du rpertoire
/proc, le kernel regarde quelle fonction ralise cette opration dans un tableau des oprations
interne au kernel. Il appelle alors la fonction en question. Cet aiguillage peut tre dtourn par un
module ayant accs la mmoire kernel.

Certains codes publics utilisent mme des mcanismes assez pousss base de signaux pour
indiquer dynamiquement au code pirate dans le kernel quels processus il doit cacher, sans avoir
besoin de reprogrammer le module. Le module intercepte le signal de type spcial envoy un
processus par le pirate au moyen de la commande kill, et cache le processus en question.
Sous certains systmes comme Solaris, le listing des processus est aussi obtenu par lecture de
la mmoire du kernel au travers du priphrique virtuel /dev/kmem. Comme prcdemment, un
aiguillage indiquant au kernel quelle est la fonction appeler pour ouvrir et lire dans le

Programmes dcoute de rseaux enregistrant les mots de passe qui y transitent.

Type de programmes trs souvent utiliss par les pirates et donnant accs un shell sur un port TCP ou
UDP donn.
6

Backdoors avances
Nicolas Dube

p. 13/19

priphrique virtuel /dev/kmem. Le pirate remplace alors ces fonctions par les siennes, qui
nettoient les valeurs renvoyes au processus demandeur.

3.2.2 Dissimulation de fichiers

Les fichiers sont dissimulables exactement comme prcdemment, en modifiant les aiguillages
du pilote systme de fichiers correspondant dans le noyau. Ainsi, si lintrus cherche cacher des
fichiers stocks sur un disque dur format en UFS, il modifie la routine UFS de listing des
rpertoires afin de cacher les fichiers quil souhaite. Il veut cependant toujours pouvoir y accder
en lecture ou criture (consultation denregistrements de sniffers par exemple), il ne modifie
donc pas les autres fonctions.

Figure 6: Dissimulation d'un fichier sous Solaris par modification kernel, pour cet exemple le
programme ls n'a pas t modifi. Le fichier monfichier nest pas visible dans le listing du
rpertoire mais est toujours accessible et modifiable si lon connat son nom.

Nous avons pu aussi tudier des modules kernel Solaris pirates trs perfectionns qui
introduisaient une fonctionnalit freeze dans toute la partie gestion des fichiers du noyau.
Cette fonctionnalit permettait de modifier le systme de fichiers (accder en lecture/criture aux
fichiers) sans quaucune date daccs ou de modification ne soit change . Le code tait activ
en envoyant un signal spcial au processus sur lequel on voulait installer la fonctionnalit, et
tous les descendants du processus en hritaient. Le pirate envoyait donc trs probablement le
signal son propre shell afin que toutes les consultations/modifications de fichiers quil effectuait
partir de ce shell soient invisibles.

3.2.3 Excution dtourne

La modification de binaires systmes tels que /bin/login ou sshd est une technique favorite des
pirates. Ils peuvent en effet facilement introduire des chevaux de Troie la place des
programmes de login standard pour pouvoir se connecter sans avoir besoin de login / mot de
passe autoris. Une fois que le cheval de Troie (ou plutt, backdoor porte drobe dans ce
cas) a dtect que son matre souhaite se connecter, il lui accorde laccs comme un
utilisateur lgitime mais nenregistre nulle par de traces de cette connexion.
Cependant, la pose de backdoors la place de programmes standards ncessite leur
modification, et des outils performants tels que Tripwire existent pour dtecter de telles
modifications aux fichiers sensibles. Ces outils de vrification peuvent quand mme tre mis en
Backdoors avances
Nicolas Dube

p. 14/19

chec par des modifications au kernel. Noublions pas en effet que pour lire les fichiers et en
faire des signatures, les outils de vrification se fondent sur les informations fournies par le
kernel (ils utilisent les services du kernel pour ouvrir et lire les fichiers, et ne peuvent pas faire
autrement).
Cette constatation a t leve par plusieurs articles de la revue Phrack afin de mettre en dfaut
les outils de vrification comme Tripwire. Lide est simple : si nous pouvons contrler le noyau,
pourquoi ne pas fournir aux outils de vrification la vue quils veulent des fichiers, alors que
ceux-ci ont pu tre modifis ?
Prenons le cas du remplacement du programme de connexion scurise SSH,
/usr/local/sbin/sshd, par un cheval de Troie. Une technique pour ce faire est la suivante :
- le fichier en lui-mme /usr/local/sbin/sshd nest pas modifi. Ainsi, les programmes de
vrification ne trouveront rien redire.
- Le programme ssh de remplacement (cheval de Troie) est mis sur un autre endroit du
systme de fichiers, par exemple /var/tmp/backdoorsshd. Son existence peut tre
masque en le cachant comme vu prcdemment.
- Le module kernel pirate modifie lappel systme dexcution de programmes, execve(),
pour dtecter si on essaie dexcuter /bin/login. Si tel est le cas, on excute la place le
cheval de Troie, /var/tmp/backdoorlogin.
De ce fait, lorsque le programme sshd sera lanc au dmarrage de la machine, la backdoor sera
lance la place, tandis que si un programme de vrification ouvre le programme sshd pour le
vrifier, elle verra le fichier original.

3.2.4 Backdoors rseaux

Une des dernires avances en matire de modification des kernels est la modification des piles
rseaux elles-mmes afin dy introduire des portes drobes.
Ds janvier 1998, des exprimentations sont publies dans la revue Phrack concernant des
modules kernel dtectant les paquets UDP contenant un mot clef donn et excutant un
programme. Ces premiers exemples de dclenchements de backdoors distance par
modification des piles rseaux ont t largement amliors par la suite.
Ainsi, un article7 de la mme revue en septembre 1999 dtaille un module permettant entre
autres dinverser les bits SYN et FIN dans une connexion TCP, crant des connexions TCP non
reconnues par les systmes non quips du module, et obscures lanalyseur de trafic. Les
IDS, ntant pas capables dinterprter de tels flux, sont aussi mis en dfaut par ces
modifications des couches rseaux, idales pour raliser des covert chanels8.
La modification des couches rseaux peut aussi avoir une incidence sur le systme local luimme. Un module9 rcupr par nos soins sur une machine Linux compromise modifiait par
exemple la couche SOCK_RAW du kernel afin de masquer aux analyseurs ou sondes rseaux
situes sur la machine certains types de paquets. Normalement, la fonctionnalit SOCK_RAW
permet de remonter aux applications toutes les trames au format brut ; cest ainsi que sont
dvelopps les IDS rseaux ou les analyseurs comme tcpdump. Le systme quip du module
7

Kossak, Lifeline, Building into the Linux network layer, Phrack 55/12
http://www.phrack.com/show.php?p=55&a=12
8
Flux dissimuls permettant par exemple de faire sortir secrtement dun rseau local des informations
sensibles, en les mlangeant du trafic normal.
9
Module apparemment non connu publiquement.

Backdoors avances
Nicolas Dube

p. 15/19

en question ne signalait pas lIDS les paquets ayant un port source particulier ou contenant un
mot clef donn. Le pirate utilisait ce port source pour effectuer toutes ses connexions vers ou
partir de la machine compromise. Il tait donc impossible pour la sonde IDS qui tait installe
sur la machine de dtecter le trafic rseau gnr par lactivit du pirate.

3.3 Importance du problme

Bien que le problme des modifications kernel soit connu de longue date (il a mme fait lobjet
dun avis du CERT10), il nest pas encore matris
En particulier, il est souvent dit pour minimiser limpact de tels outils pirates que ceux-ci
ncessitent une technicit leve. Cependant, ce serait oublier que nombre de modules publics
facilement utilisables (notamment sous Linux) sont disponibles, et pas plus dlicats dutilisation
que la plupart des programmes dattaques. La littrature est de plus abondante et les exemples
dutilisation disponibles foison :
-

Adore v0.34 (Linux) par Stealth11

Module kernel Linux avec programme dinstallation et dadministration aise permettant
de gagner root par une fonction cache, dissimuler des processus, des fichiers des
connexions TCP (contre netstat) et du mode Promisc.

Kernmod 0.2 (Solaris) par Job de Haas - ITSX12

Dmonstration dun module kernel Solaris ralisant toutes les oprations de base
(dissimulation de fichiers, processus, connexions TCP, ).

Rootkit 200013 (Windows NT 4.0, Windows 2000) par Greg Hoglund & collectif
Rootkit kernel sous Microsoft Windows.

Comme le montre lexemple prcdent de kernmod et rootkit 2000, le fait que les sources du
kernel Solaris ou de Windows NT ne soient pas disponibles na pas dissuad la communaut de
dvelopper des rootkits Solaris ou NT. En effet, les fabricants de systmes dexploitation ont tout
intrt documenter les mthodes de programmation du kernel afin de favoriser le
dveloppement de pilotes priphriques pour leurs systmes dexploitations ; les mthodes
utilises pour dvelopper les pilotes priphriques sont alors reprises pour la ralisation de
modules pirates.
Aujourdhui, tous les systmes dexploitation sont modulaires et documents, pour permettre un
enrichissement fonctionnel par la communaut des dveloppeurs et fabricants de matriels.
Malheureusement, aucun de ces systmes nintgre en parallle des mcanisme de scurit
permettant de limiter limpact dune compromission privilgie (root). Les possibilits sans limites
qua un agresseur pouvant modifier un systme dexploitation montrent clairement les limites du
concept actuel de tout ou rien au niveau des privilges. Quand le kernel, normalement base de

10

http://www.cert.org/vul_notes/VN-98.02.kernel_mod.html
http://online.securityfocus.com/data/tools/adore-0.34.tgz
12
http://www.itsx.com/
13
http://www.rootkit.com/
11

Backdoors avances
Nicolas Dube

p. 16/19

confiance, a t compromis, force est de constater quil ny a plus aucun salut possible pour le
systme.

3.4 Solutions
3.4.1 Dtection post intrusion
La perte de la base de confiance quest le kernel rend alatoire toute solution a posteriori pour
dtecter et corriger une machine affecte. Le fait que les systmes de dtection se fondent sur
des informations fournies par un kernel potentiellement compromis rend la dtection trs
dlicate.
Cependant, on peut arrive dtecter quelques-uns des rootkits kernel classiques. Les mthodes
utilises sont base de signatures et mme trs largement des bugs ou oublis des rootkits.
Une mthode couramment utilise consiste parcourir larborescence /proc, en essayant daller
dans les rpertoires /proc/N/ avec N allant de 1 65535. Si lopration russie mais que le
rpertoire ntait pas dans la liste obtenue par un ls, le processus N est cach par le systme
dexploitation et une modification du kernel a sans doute t effectue. En effet, la plupart des
modules, par soucis de facilit ou mme par mauvaise connaissance du fonctionnement interne
des systmes, ne changent que certaines fonctions du kernel, laissant une fois quils sont
installs de nombreux bugs ou effets indsirables induits par lintroduction des modifications.
Cette mthode, peu fiable, dtecte uniquement les LKM simples ou mal programms. Elle reste
quand mme trs utile pour des compromissions automatiques ou agresseurs bas de gamme, et
est surtout facilement mise en uvre par des outils comme chkrootkit
(http://www.chkrootkit.org/) ou mme certains antivirus sous Microsoft Windows.

Figure 7: Compromission possible par LKM, le processus 202 n'apparat pas dans la liste pourtant
il semble exister (bug de la backdoor).

Malheureusement, les rootkits kernel bien conus peuvent tre extrmement difficiles dtecter,
et mme virtuellement impossibles sil ny a pas de grandes suspicions de compromission.
Rappelons que les outils de dtection reposent sur des informations qui leurs sont transmises
par un systme potentiellement compltement dtourn.

Backdoors avances
Nicolas Dube

p. 17/19

La seule mthode fiable pour dtecter de tels rootkits est larrt complet du systme et lexamen
de ses disques partir dune machine sre. Si une compromission est dtecte, la rinstallation
totale est de rigueur.

3.4.2 Prvention
3.4.2.1 Prvention des attaques root
Lutilisateur root tant le seul pouvoir modifier les fichiers sensibles et le noyau du systme, la
parade ultime consisterait donc viter tout pris quun agresseur ne puisse devenir root.
- dsinstallation de tous les programmes non utiliss
- installation rgulire des patchs
- filtrage des services rseaux non ncessaires de lextrieur
- restriction de lutilisateur root aux seuls endroits o cela est compltement ncessaire.
Malheureusement, cette dernire fonctionnalit, qui devrait tre de rigueur sur tout systme
moderne se prtendant scuris, est par dfaut absente et souvent bien difficile raliser soimme. Elle est mme presque impossible effectuer sans modifications drastiques au kernel.
Comme nous lavons fait remarquer dans la premire partie du document, faute des
fonctionnalits adquates, la compartimentation des rles et des processus nest ralisable en
pratique que sur les systmes ayant t spcialement crits pour14, cest--dire jamais dans les
usuels. Il est vrai que de telles fonctionnalits ajouteraient en complexit aux systmes
dexploitation, qui prfrent tort ou raison offrir aux programmeurs et utilisateurs une
convivialit plus importante (au niveau de lajout de drivers, de ladministration, ).
Cependant, les systmes Microsoft Windows NT 4.0, Microsoft Windows 2000 et successeurs
proposent une gestion des rles et permissions assez labore permettant de dployer un plan
de scurit15 limitant le recours lutilisateur Administrateur. Il est ainsi possible de dlguer
certains groupes non privilgis des attributions de scurit telles que le backup complet, vitant
ainsi le recours systmatique lutilisateur Administrateur ds quun privilge lev est
ncessaire. Remarquons quoiquil en soit que de nombreux services rseaux doivent toujours
disposer de privilges systmes, cest--dire les plus levs ; la gestion dattributions
spcifiques par processus (et non par utilisateur) ntant pas encore supporte.
3.4.2.2 Limitation des pouvoirs de root
Considrons maintenant le cas o il nest pas possible de se prmunir de lutilisation de root, et
quune compromission de cet utilisateur nest pas exclue. On peut vouloir minimiser ses
attributions et lui faire perdre un peu du modle classique tout ou rien.
Nous avons vu que la perte complte de la confiance en un systme tait due la
compromission de son systme dexploitation. Si le systme dexploitation reste sain, il pourra
toujours fournir aux applications de dtection les moyens de reprer des modifications de
fichiers par exemple. Une premire technique consiste interdire toute modification du kernel,
mme par root.
Si le systme est destin tre largement fixe (cas des systmes de production), sans
changements de configuration, les systmes BSD implmentent un tel mcanisme connu sous
14

Le noyau Linux devrait tre dot dune interface de rglages fins des permissions dans ce but. Dautre
part, des systmes commerciaux comme ceux de la socit Argus peuvent venir se greffer sur les
systmes dexploitation du march pour leur ajouter de nombreuses fonctionnalits de scurit.
15
Le site Web de la socit Edelweb possde une section scurit Windows fort propos
(http://www.edelweb.fr/EdelStuff/EdelPages/) comprenant notamment des articles par Maxime de Jabrun,
Nicolas Ruff et Patrick Chambet sur la scurisation avance de machines Microsoft Windows NT/2000.

Backdoors avances
Nicolas Dube

p. 18/19

le nom des securelevels. Des permissions tendues sur les fichiers et un identifiant spcial sont
introduits. Lidentifiant spcial, un entier appel securelevel, peut uniquement tre incrment
par des administrateurs. A ltat 0, le systme est dit non sr et le comportement est celui dun
systme classique sans securelevel. Les permissions tendues peuvent tre changes et le
kernel modifi par /dev/kmem ou /dev/mem. Aux tats srs 1 et 2, les fichiers virtuels
/dev/kmem et /dev/mem ainsi quentre autres les permissions spciales des fichiers ne sont plus
modifiables.
Sans ces mcanismes interdisant les modules (malheureusement, enlevant de ce fait une
fonctionnalit bien pratique), lcriture dans les priphriques mmoire et la modification des
fichiers kernel eux-mmes, il est quasiment impossible de protger un systme o root a t
compromis dune modification du kernel. Certaines tentatives ont t faites pour dvelopper des
outils vrifiant en temps rel la table des appels systmes, cependant il existe de nombreuses
parties dun systme dexploitation modifier part les appels systmes, et ces outils ne
feraient que rebuter les pirates moins techniques.

4. Conclusion
Nous avons pu voir comment, en dtournant des possibilits lgitimes, un agresseur peut
manipuler sa guise un systme entier au point quaucune information ne puisse plus tre
valide.
Les fonctionnalits de convivialit et de souplesse ont longtemps t privilgies par rapport
celles de scurit, comme en tmoignent les installations par dfaut des plus grands systmes
dexploitation, doffice vulnrables de nombreuses attaques. Cependant, nous avons pu
assister ces derniers mois, en raison notamment dvnements majeurs tels que larrive de
vers et virus diffusion exceptionnelle, dun retournement de la tendance. Mme si nous ne
pouvons quapprouver ces nouvelles orientations, le problme de la modification des noyaux
nous montre bien que des changements drastiques seront ncessaires aux curs mme des
systmes dexploitation, afin que la confiance perdue de longue date puisse tre restaure.

Backdoors avances
Nicolas Dube

p. 19/19