Analyse du Scan of the Month 27

Introduction

Depuis plus de deux ans, le projet Honeynet propose régulièrement d'étudier des outils, des tactiques utilisées par des pirates lors d'intrusion pour démontrer la réalité de ces attaques, pour apprendre comment un pirate agit pour s'en protéger et plus généralement pour améliorer les technologies et méthodes de collecte d'information. Le Scan of the Month 27 est particulièrement intéressant car il concerne le piratage au mois de mars de cette année d'un honeypot de l'Azusa Pacific University sous Windows 2000 dont le compte Administrateur avait été laissé à dessein sans mot de passe.

Analyse

Récupération des données

Commençons par récupérer sur le site du projet Honeynet http://old.honeynet.org/scans/scan27/ le fichier de log libpcap. Après téléchargement, vérifions sa somme de contrôle MD5 afin de vérifier qu'il n'a pas été altérer lors du téléchargement.

[kmaster@christophe kmaster]$ md5sum sotm27.gz
b4bfc10fa8346d89058a2e9507cfd9b9  sotm27.gz

Le fichier est intact. Le honeypot se trouve à l'adresse 172.16.134.191.

Heure de capture

La première étape est de vérifier la cohérence des heures de capture par la sonde de détection d'intrusion Snort avec celle du Honeypot.

Sous ethereal, la première trame date du 1 mars 2003 09:08:09 GMT. Dans la trame 25 daté de 12:47:47, le serveur web IIS du honeypot renvoie 12:14:31 GMT.

Frame 25 (299 bytes on wire, 299 bytes captured)
    Arrival Time: Mar  1, 2003 12:47:47.714411000
    Time delta from previous packet: 0.814035000 seconds
    Time relative to first packet: 13178.189207000 seconds
    Frame Number: 25
    Packet Length: 299 bytes
    Capture Length: 299 bytes
    ...
Hypertext Transfer Protocol
    HTTP/1.1 200 OK\r\n
    Server: Microsoft-IIS/5.0\r\n
    Date: Sat, 01 Mar 2003 12:14:31 GMT\r\n
    Connection: Keep-Alive\r\n
    Content-Length: 1270\r\n
    Content-Type: text/html\r\n
    Set-Cookie: ASPSESSIONIDGQGQGRSK=PBFPBFNCIFJHFOFDOFOKMJAN; path=/\r\n
    Cache-control: private\r\n
    \r\n

Les heures de capture et du honeypot ne correspondent pas, il y a près d'une demi-heure de décalage. Quelle heure est correcte ? Pour le savoir, recherchons une autre requete web dirigé vers un autre serveur web. Dans la trame 3096, le serveur auto.search.msn.com renvoie exactement l'heure de capture. Le honetpot sous Windows 2000 n'est donc pas à l'heure, nous utiliserons bien l'heure de capture des trames comme référence.

Frame 3096 (699 bytes on wire, 699 bytes captured)
    Arrival Time: Mar  5, 2003 05:21:09.236016000
    Time delta from previous packet: 0.062556000 seconds
    Time relative to first packet: 331979.710812000 seconds
    Frame Number: 3096
    Packet Length: 699 bytes
    Capture Length: 699 bytes
    ...
Hypertext Transfer Protocol
    HTTP/1.1 302 Object moved\r\n
    Server: Microsoft-IIS/5.0\r\n
    Date: Wed, 05 Mar 2003 05:21:09 GMT\r\n
    P3P:CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TELo"\r\n
    Location: http://auto.search.msn.com/results.asp?cfg=DNSERROR&v=1&FORM=DNSERR&q=users%2Eerol%2Ecom%2Fgmgarner%2Fforensics%2F\r\n
    Content-Length: 235\r\n
    Content-Type: text/html\r\n
    Set-Cookie: ASPSESSIONIDQSSCSCRQ=NDOINAACLPGKNIJNLHJMEELG; path=/\r\n
    Cache-control: private\r\n
    \r\n

Packet checksum

Comme toujours, l'adresse IP du honeypot a été altérée pour que celle-ci reste inconnue. Il ne faudrait pas que les vilains hackers évitent les machines de l'honeynet. Conséquence de cette modification, les checksums IP sont tous faussés.

MAC address observation

L'examen d'une réponse Netbios révele les différentes adresses MAC des éléments réseaux en présence.

Frame 2 (343 bytes on wire, 343 bytes captured)
Ethernet II, Src: 00:05:69:00:01:e2, Dst: 00:e0:b6:05:ce:0a
    Destination: 00:e0:b6:05:ce:0a (00:e0:b6:05:ce:0a)
    Source: 00:05:69:00:01:e2 (00:05:69:00:01:e2)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 172.16.134.191 (172.16.134.191), Dst Addr: 219.118.31.42 (219.118.31.42)
User Datagram Protocol, Src Port: 137 (137), Dst Port: 1025 (1025)
NetBIOS Name Service
   Answers
   Unit ID: 00:05:69:00:01:56

Les adresses MAC commençant par 00:05:69 correspondent à VMWare d'après le fichier des codes constructeurs /etc/ethereal/manuf de ethereal. Le honetpot tourne dans une machine virtuelle comme expliqué sur http://home.apu.edu/~bmccarty/honeynet.html

Protocol hierarchy

La majorité du traffic est constituée de HTTP suivie d'IRC et de traffic Netbios/SMB.

Les attaques

Alertes Snort

Comme l'adresse IP du Honetpot a été modifié, les sommes de contôle sont faussées. Snort ne vérifiera pas celle-ci grâce à l'option -k none. L'option U permet de travailler en temps universelle (UTC ou GMT).

[kmaster@p500 sotm27]$ snort -UNz -k none -A fast -c /etc/snort.conf -r sotm27 -l log
-*> Snort! <*-
Version 2.0.0 (Build 72)
By Martin Roesch (roesch@sourcefire.com, www.snort.org)
Run time for packet processing was 2.316206 seconds


===============================================================================

Snort processed 54536 packets.
Breakdown by protocol:                Action Stats:

    TCP: 54350      (99.659%)         ALERTS: 870
    UDP: 186        (0.341%)          LOGGED: 870
   ICMP: 0          (0.000%)          PASSED: 0
    ARP: 0          (0.000%)
  EAPOL: 0          (0.000%)
   IPv6: 0          (0.000%)
    IPX: 0          (0.000%)
  OTHER: 0          (0.000%)

snort_stat.pl -h log/alert > alert.html

Snort Statistics

Percentage and number of attacks from a host to a destination

Percentage and number of attacks to one certain host

Les attaques détectées par Snort se répartissent en deux catégories: les attaques contre le serveur Web et les attaques contre MS-SQL. Vérifions si elles ont abouties.

Répartition par adresse IP

Filtrons avec tcpdump les paquets TCP SYN (flag 0x02) et les paquets autres que TCP /usr/sbin/tcpdump -n -r sotm27 "tcp[13]&0x12==0x02 or ! ip proto 6" pour obtenir une idée de l'utilisation de chaque adresse IP. Le nombre d'appartitions des adresses IP sources est reporté dans le tableau suivant:

Notre pirate doit sans doute se trouver dans le début de cette liste.

Attaques MSSQL

Le ver Slammer/Sapphire, CA-2003-04, a attaqué le serveur. Si l'attaque avait réussi, il y aurait eu du traffic UDP sortant sur le port 1434.

Attaques Web

Pour vérifier si une attaque contre IIS a aboutie, vérifions les réponses du serveur web à l'aide de ngrep, http://ngrep.sourceforge.net/.

[kmaster@christophe sotm27]$ ngrep -qI sotm27 "" "tcp and src 172.16.134.191 and src port 80"
input: sotm27

T 172.16.134.191:80 -> 213.23.49.158:1445 [AP]
  HTTP/1.1 200 OK..Server: Microsoft-IIS/5.0..Date: Sat, 01 Mar 2003 12:14:31
   GMT..Connection: Keep-Alive..Content-Length: 1270..Content-Type: text/html
  ..Set-Cookie: ASPSESSIONIDGQGQGRSK=PBFPBFNCIFJHFOFDOFOKMJAN; path=/..Cache-
  control: private....

...

Aucune attaque Web n'a été concluante, pourtant le serveur a bien été piraté.

Attaques SMB

Le traffic Netbios/SMB n'a généré aucune alerte Snort. Plutôt que de rechercher ce que chaque machine a fait, faisons une analyse globale. De part l'analyse des protocoles, nous savons qu'il faut étudier le traffic SMB. Recherchons si des fichiers ont été créés sur la machine:

[kmaster@p500 sotm27]$ /usr/sbin/tethereal -r sotm27 -n "tcp.port==139 or tcp.port==445"|grep "Path"

1396 322257.318799 210.22.204.101 -> 172.16.134.191 SMB NT Create AndX Request, Path: \WINNT\System32\r_server.exe
1649 322263.704823 210.22.204.101 -> 172.16.134.191 SMB NT Create AndX Request, Path: \WINNT\System32\raddrv.dll
1688 322265.566763 210.22.204.101 -> 172.16.134.191 SMB NT Create AndX Request, Path: \WINNT\System32\admdll.dll
...
33280 412046.012158 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \System32\PSEXESVC.EXE
33368 412048.461458 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \svcctl
33480 412059.987271 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \psexecsvc
33505 412060.857491 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \svcctl
33537 412063.707330 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \System32\PSEXESVC.EXE
33612 412065.668903 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \svcctl
33676 412072.086448 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \psexecsvc
33678 412072.276580 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \System32\inst.exe
...

Nous avons deux intrusions devant les yeux. Regardons les plus en détail.

[kmaster@p500 sotm27]$ /usr/sbin/tethereal -r sotm27 -n "tcp.port==139 or tcp.port==445 and ip.addr eq 210.22.204.101"|egrep "User|Path|Error"
922 322204.982923 172.16.134.191 -> 210.22.204.101 SMB Session Setup AndX Response, Error: STATUS_MORE_PROCESSING_REQUIRED
925 322205.478544 210.22.204.101 -> 172.16.134.191 SMB Tree Connect AndX Request, Path: \\172.16.134.191\IPC$
927 322205.696613 210.22.204.101 -> 172.16.134.191 SMB NT Create AndX Request, Path: \samr
941 322207.468167 210.22.204.101 -> 172.16.134.191 SAMR EnumDomainUsers request
942 322207.471165 172.16.134.191 -> 210.22.204.101 SAMR EnumDomainUsers reply
950 322209.158518 210.22.204.101 -> 172.16.134.191 SMB NT Create AndX Request, Path: \samr
970 322212.045185 210.22.204.101 -> 172.16.134.191 SAMR OpenUser request, rid 0x1f4
971 322212.047812 172.16.134.191 -> 210.22.204.101 SAMR OpenUser reply
...
1342 322249.970650 172.16.134.191 -> 210.22.204.101 SMB Session Setup AndX Response, Error: STATUS_MORE_PROCESSING_REQUIRED
1345 322250.220565 172.16.134.191 -> 210.22.204.101 SMB Session Setup AndX Response, Error: STATUS_LOGON_FAILURE
1347 322250.469105 172.16.134.191 -> 210.22.204.101 SMB Logoff AndX Response, Error: Bad userid
1368 322253.935814 172.16.134.191 -> 210.22.204.101 SMB Session Setup AndX Response, Error: STATUS_MORE_PROCESSING_REQUIRED
1371 322254.418561 210.22.204.101 -> 172.16.134.191 SMB Tree Connect AndX Request, Path: \\172.16.134.191\IPC$
1373 322254.655965 210.22.204.101 -> 172.16.134.191 SMB NT Create AndX Request, Path: \svcctl
1386 322256.123709 172.16.134.191 -> 210.22.204.101 SMB Session Setup AndX Response, Error: STATUS_MORE_PROCESSING_REQUIRED
1390 322256.598010 210.22.204.101 -> 172.16.134.191 SMB Tree Connect AndX Request, Path: \\172.16.134.191\IPC$
1393 322256.835362 172.16.134.191 -> 210.22.204.101 SMB Transaction2 Response GET_DFS_REFERRAL, Error: STATUS_NO_SUCH_DEVICE
1394 322257.058080 210.22.204.101 -> 172.16.134.191 SMB Tree Connect AndX Request, Path: \\172.16.134.191\C$
1396 322257.318799 210.22.204.101 -> 172.16.134.191 SMB NT Create AndX Request, Path: \WINNT\System32\r_server.exe
1649 322263.704823 210.22.204.101 -> 172.16.134.191 SMB NT Create AndX Request, Path: \WINNT\System32\raddrv.dll
1688 322265.566763 210.22.204.101 -> 172.16.134.191 SMB NT Create AndX Request, Path: \WINNT\System32\admdll.dll

La machine 210.22.204.101 a collecté des informations sur les comptes et utilisateurs et a aussi déposé trois fichiers sur le Windows 2000:

• \WINNT\System32\r_server.exe
• \WINNT\System32\raddrv.dll
• \WINNT\System32\admdll.dll

[kmaster@p500 sotm27]$ /usr/sbin/tethereal -r sotm27 -n "tcp.port==139 or tcp.port==445 and ip.addr eq 61.111.101.78"|egrep "User|Path|Error"
33232 412041.927164 172.16.134.191 -> 61.111.101.78 SMB Session Setup AndX Response, Error: STATUS_MORE_PROCESSING_REQUIRED
33235 412042.283991 61.111.101.78 -> 172.16.134.191 SMB Tree Connect AndX Request, Path: \\172.16.134.191\IPC$
33237 412042.452703 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \samr
33275 412045.464250 172.16.134.191 -> 61.111.101.78 SMB Session Setup AndX Response, Error: STATUS_MORE_PROCESSING_REQUIRED
33278 412045.812234 61.111.101.78 -> 172.16.134.191 SMB Tree Connect AndX Request, Path: \\172.16.134.191\ADMIN$
33280 412046.012158 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \System32\PSEXESVC.EXE
33366 412048.281496 61.111.101.78 -> 172.16.134.191 SMB Tree Connect AndX Request, Path: \\172.16.134.191\IPC$
33368 412048.461458 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \svcctl
33480 412059.987271 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \psexecsvc
33505 412060.857491 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \svcctl
33529 412062.986957 61.111.101.78 -> 172.16.134.191 SMB Transaction2 Request QUERY_PATH_INFORMATION, Path: \System32\PSEXESVC.EXE
33531 412063.156924 61.111.101.78 -> 172.16.134.191 SMB Transaction2 Request QUERY_PATH_INFORMATION, Path: \System32\PSEXESVC.EXE
33533 412063.337170 61.111.101.78 -> 172.16.134.191 SMB Delete Request, Path: \System32\PSEXESVC.EXE
33537 412063.707330 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \System32\PSEXESVC.EXE
33612 412065.668903 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \svcctl
33676 412072.086448 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \psexecsvc
33678 412072.276580 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \System32\inst.exe
34474 412090.721007 61.111.101.78 -> 172.16.134.191 SMB NT Create AndX Request, Path: \svcctl
...

Ce second pirate, 61.111.101.78, a installé deux programmes:

• \System32\PSEXESVC.EXE
• \System32\inst.exe

D'après la description donnée par le Cert sur l'augmentation des attaques utilisant les partages Windows CA-2003-08, cela correspond au ver W32/Deloder.

Le botnet IRC

IRC, Internet Relay Chat, permet de communiquer en temps réel en envoyant de simple message en texte suivant le protocole RFC 1459. Les discussions se font dans des channels, l'équivalent de salons virtuelles.

Pour joindre un réseau IRC, le client IRC se connecte à un serveur.

• 1. il envoie le mot de passe de connexion (optionel selon les serveurs)
PASS <password>
• 2. puis le surnom de l'utilisateur,
NICK <nickname> [ <hopcount> ]
• 3. et enfin des informations sur l'utilisateur même
USER <username> <hostname> <servername> <realname>
• A partir de ce moment là, le client est authentifié. Généralement, un message JOIN est envoyé pour se mettre à l'écoute de channel spécifique.
JOIN <channel>,<channel> [<key>,<key>]

En filtrant les paquets TCP avec le flag SYN, /usr/sbin/tcpdump -r sotm27 -n "tcp[13]&2=2 and port ircd", le honeypot a cherché à contacter 5 serveurs IRC dont les deux premiers sans succès:

• 209.126.161.29:ircd
• 66.33.65.58:ircd
• 63.241.174.144:ircd
• 217.199.175.10:ircd
• 209.196.44.172:ircd

Le troisième serveur referme la connexion car le nickname eohisou est déjà utilisé.

06/03/2003 03:56:15 172.16.134.191 -> 63.241.174.144 TCP 1133->6667

NOTICE AUTH :*** Looking up your hostname...
NOTICE AUTH :*** Checking Ident
NOTICE AUTH :*** No Ident response
NICK eohisou
USER eohisou localhost localhost :eohisou
NOTICE AUTH :*** Found your hostname
:irc4.aol.com 433 * eohisou :Nickname is already in use.
ERROR :Closing Link: [eohisou@255.255.255.255] (Connection Timed Out)

Le quatrième compte trop d'utilisateurs.

06/03/2003 03:56:36 172.16.134.191 -> 217.199.175.10 TCP 1139->6667

NOTICE AUTH :*** Looking up your hostname...
NOTICE AUTH :*** Checking Ident
NOTICE AUTH :*** No Ident response
NOTICE AUTH :*** Found your hostname
NICK rgdiuggac
USER rgdiuggac localhost localhost :rgdiuggac
ERROR :Closing Link: rgdiuggac[~rgdiuggac@255.255.255.255] (Sorry, server is full - try later)

Le dernier serveur IRC est le bon! Le channel #xàéüîéðìx protégé par mot de passe est utilisé.

06/03/2003 04:23:18 172.16.134.191 -> 209.196.44.172 TCP 1152->6667

NOTICE AUTH :*** Looking up your hostname...
NOTICE AUTH :*** Checking Ident
NOTICE AUTH :*** No Ident response
NOTICE AUTH :*** Found your hostname
NICK rgdiuggac
USER rgdiuggac localhost localhost :rgdiuggac
:irc5.aol.com 001 rgdiuggac :Welcome to the Internet Relay Network rgdiuggac
:irc5.aol.com 002 rgdiuggac :Your host is irc5.aol.com[irc5.aol.com/6667], running version 2.8/hybrid-6.3.1
...
MODE rgdiuggac -x
MODE rgdiuggac +i
JOIN #xàéüîéðìx :sex0r
WHO rgdiuggac
:rgdiuggac!~rgdiuggac@pc0191.example.com JOIN :#xàéüîéðìx
:irc5.aol.com 353 rgdiuggac @ #xàéüîéðìx :rgdiuggac mikeoof riktgisli moongihli garcmobhc tixicok likenik rndvcoke mponptti moinhoyf oarcqeii cozfboy nolvped kiangiil aiiieahi idoiaiq gsrcaahh rockpdlhi stepbeyz aotkugxyc cikebocsz fgwiuglyc rositik radicioli radpneni miaeuglya ydsicoke rojigpr jiklniki kiwbcoka coloagsy mikzbovz maaenifi gaanoee rogqpenq iqonsohwh stepfakis cibesout stepupo rozijri kikiqwni pishcic rocrjouj oosirafwp rkinrahsm rldiuzl rickboyrz stenpguih mrhenik gtccugl toonyeni

Les noms des "personnes" connectées sur ce channel est des plus étranges. Il ne s'agit pas d'utilisateurs réels mais de bots IRC, de clients IRC automatisés. Une utilisation légitime des bots est d'ajouter des fonctionnalités de partage, des jeux...

Dans notre cas, les bots forment un réseau, un botnet. Les botnets sont souvent utilisés pour les DDoS, les dénis de service distribués. En comptant les logins affichés dans le WHO et lors des JOIN, le channel regroupe 3458 bots! En supposant qu'ils disposent d'une bande passante de 56 kbps chacun, ce qui est plutôt une estimation faible étant donné la popularité des connexions ADSL, la personne contrôlant le botnet dispose d'une bande passante de plus de 190 Mb (3458*56kbps=193648kbps).

Conclusion

La principale difficulté de ce challenge a été le volume de log couvrant 5 jours d'activités. Il a fallu mettre en oeuvre des méthodes pour limiter le volume d'information à analyser. Un constat: les attaques les plus fréquentes sont liés à des worms.

Christophe GRENIER
Consultant Sécurité chez Global Secure
Site perso: http://www.cgsecurity.org
Email perso: grenier@cgsecurity.org