Users login

Create an account »

JOIN XATRIX

Users login

Home » Hacking News » Hacker Tools and Their Signatures - Part One

Hacker Tools and Their Signatures - Part One

by phiber on April 15th, 2001 This article is the first in a series of papers detailing hacker exploits/tools and their signatures. This installment will examine the Berkley Internet Name Domain exploit bind8x.c. The discussion will cover the details of bind8x.c and provide signatures that will assist an IDS analyst in detecting it. This paper assumes that the reader has some basic knowledge of TCP/IP and understands the tcpdump format.




BIND and DNS



"DNS is a distributed database that is used by TCP/IP to map between hostnames and IP addresses."[1] In short, this means when a user types in www.securityfocus.com on his/her browser, the computer does not automatically know what the user is requesting. The user's computer then goes out to the DNS server that was assigned to it and asks the DNS server to tell it the IP address of the requested URL. This also holds true for resolving IP addresses to hostnames. A good example of what really happens is shown in Figure 1. Figure 1 shows a TCPDUMP read-out from my home computer as it talks to its DNS server.



2:12:51.704487 > my.computer.net.1025 > my.isp’s.DNS.domain: 23838+A?
www.securityfocus.com. (39) (ttl 64, id 217)

4500 0043 00d9 0000 4011 8f3a xxxx xxxx

xxxx xxxx 0401 0035 002f 12ea 5d1e 0100

0001 0000 0000 0000 0377 7777 0d73 6563

7572 6974 7966 6f63 7573 0363 6f6d 0000

0100 01



22:12:51.884600 > my.isp’s.DNS.net.domain >
my.computer.net.1025:23838 q:

www.securityfocus.com. 1/1/1 www.securityfocus.com. A
www.securityfocus.com

(89) (ttl 55, id 2916)

4500 0075 0b64 0000 3711 8d7d xxxx xxxx

xxxx xxxx 0035 0401 0061 62e9 5d1e 8180

0001 0001 0001 0001 0377 7777 0d73 6563

7572 6974 7966 6f63 7573 0363 6f6d 0000

0100 01c0 0c00 0100 0100 0129 9100 0442

2697 0ac0 1000 0200 0100 020b cd00 0603

6e73 32c0 10c0 4300 0100 0100 00ba 4c00

0442 2697 02



22:12:51.887833 > my.computer.net.1050 >
www.securityfocus.com.www S

1691535048:1691535048(0) win 32120
0,nop,wscale 0> (DF) (ttl 64, id 218)

4500 003c 00da 4000 4006 9f04 xxxx xxxx

4226 970a 041a 0050 64d2 c6c8 0000 0000

a002 7d78 e813 0000 0204 05b4 0402 080a

0007 1791 0000 0000 0103 0300





Figure 1: DNS Communications



By looking at the first packet we can see that the destination port is 53 and that the packet itself is a UDP packet. I think that part of the packet is pretty clear. It's the DNS part of the packet that we need to make sense of. Before we look at DNS lets look at the header for DNS in Figure 2.





1 1 1 1 1 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| ID |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

|QR| Opcode |AA|TC|RD|RA| Z | RCODE |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| QDCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| ANCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| NSCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| ARCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+







Figure 2: DNS Header Format [2]



Figure 2 gives us a good idea at what we are looking at in the packet. From this header we can see that 23838(hex 5d1e) is the identification number in the DNS packet. The ID number is sent to the server by the client and is then returned to the client by the server. The purpose of this is to allow the client to match responses with requests.



The next item we want to look at is the + sign. In the math world this is the addition sign; however, in the DNS world it means that the RD (recursion desired) flag is set. The 'A' means that we want an IP address.



Packet number 2 only has one area that needs explaining. That is the letter q - possibly meaning a query.



Finally, in the third packet we see that my computer was able to obtain the IP address of www.securityfocus.com and had began making its initial connection.



BIND



BIND stands for Berkley Internet Name Domain. In the Linux environment BIND can usually be found under named. The configuration file is located at /etc/named.conf. Named (if enabled at startup) normally runs on UDP/TCP port 53. I am not going to get into details on how to set up DNS or even security best practices related to DNS. As of this writing the most current version of BIND available that is considered safe is BIND 8.2.3. The program (bind8X.c) we will look at exploits 8.2.2.



Bind8x.c

Bind8x.c was written by Ix and lucysoft. It exploits vulnerabilities found in BIND 8.2.2. When run, Bind8x.c gives you root access to the victim machine (providing it is running a vulnerable version of BIND). If you would like to see the code, see http://packetstorm.securify.com/0102-exploits/bind8x.c.



Compiling this program is relatively easy - all you need to do is gcc -o bind8x bind8x.c. That provided me with the program I needed. I ran this program on my home network, against a Red Hat 6.1 box (192.168.1.25) that had no patches applied and all services wide open. Figure 3 is a TCPDUMP trace of the packets that we will analyze.



16:01:44.760778 < 192.168.1.5.1042 >
192.168.1.25.domain: 48879 inv_q+

[b2&3=0x980] (476) (ttl 64, id 4626)

4500 01f8 1212 0000 4011
e374 c0a8 0105

c0a8 0119 0412 0035 01e4 b242
beef 0980

0000 0001 0000 0000 3e00 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 003e 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000
0000
16:01:44.761921 > 192.168.1.25.domain >
192.168.1.5.1042: 48879 inv_q FormErr

[0q] q:

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@.^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@ 1/0/0 . (719) (ttl 64, id 2)

4500 02eb 0002 0000 4011 f491 c0a8 0119

c0a8 0105 0035 0412 02d7 6a17 beef 8981

0000 0001 0000 0000 3e00 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 003e 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000
0000
16:01:44.773774 < 192.168.1.5.1042 >
192.168.1.25.domain: 57005+ [b2&3=0x180]

[7q] [1au] (510) (ttl 64, id 4627)

4500 021a 1213 0000 4011 e351 c0a8 0105

c0a8 0119 0412 0035 0206 b5c3 dead 0180

0007 0000 0000 0001 3f00 0102 0304 0506

0708 090a 0b0c 0d0e 0f10 1112 1314 1516

1718 191a 1b1c 1d1e 1f20 2122 2324 2526

2728 292a 2b2c 2d2e 2f30 3132 3334 3536

3738 393a 3b3c eb0a 0200 00c0 0000 0000

003f 0001 eb44 5e29 c089 4610 4089 c389





Figure 3: TCPDUMP of Bind8x.c



What's so interesting about these packets? First, we see that the packets are inverse queries. What are inverse queries? Inverse queries are the reverse mappings of standard query operations[3]. Another interesting item we want to look at is '48879', which is the ID. If you look closely at the packet we see that 48879 = beef (great signature!). By looking at 0980 in the first packet we also see a few items of interest. Figure 4 is a print out from ethereal:



Domain Name System (query)

Transaction ID: 0xbeef

Flags: 0x0980 (Inverse query)

0... .... .... .... = Query

.000 1... .... .... = Inverse query

.... ..0. .... .... = Message is not truncated

.... ...1 .... .... = Do query recursively

.... .... ...0 .... = Non-authenticated data is
unacceptable

Questions: 0

Answer RRs: 1

Authority RRs: 0

Additional RRs: 0

Answers
type unused, class unknown

Name: packet>

Type: unused

Class: unknown

Time to live: 0 time

Data length: 0

Data





Figure 4: Inverse Query Packet Read Out



Figure 4 shows the normal DNS items. But let us look at 'Answers'. 'Answers' shows us that the Name goes past end of captured data in packet. This is where the overflows are beginning. The next packet is the victim's reply. To sum it up in a few short words it's saying "Name goes past end of captured data in packet>: type unused, class unknown". In other words, it has no clue what's going on.



Lets take a look at the ethereal output for the next packet.



Domain Name System (query)

Transaction ID: 0xdead

Flags: 0x0180 (Standard query)

0... .... .... .... = Query

.000 0... .... .... = Standard query

.... ..0. .... .... = Message is not truncated

.... ...1 .... .... = Do query recursively

.... .... ...0 .... = Non-authenticated data is
unacceptable

Questions: 7

Answer RRs: 0

Authority RRs: 0

Additional RRs: 1

Queries

the packet>: type unused, class unknown

Name: the end of the packet>

Type: unused

Class: unknown

:

type A, class unknown

Name:

Type: Host address

Class: unknown





Figure 5: Ethereal Output



Once again we can look inside the packet and come up with a great signature. If you look at the ID you will see 'dead'. Remember 57005 == dead. This time though, look at how many questions were sent over - seven(7). These little items are great if you are trying to develop IDS signatures for specific "hacker" tools. The reply to that packet looks like this.



16:01:44.774845 > 192.168.1.25.domain >
192.168.1.5.1042: 57005

[7q] q:


^@^A^B^C^D^E^F^G^H^I^J^K^L^M^N^O^P^Q^R^S^T^U^V^W^X^Y^Z^[^^]^^^_
!"#$%&'()*+,-./0123456789:; id 3)

4500 0231 0003 0000 4011 f54a c0a8 0119

c0a8 0105 0035 0412 021d 6fbc dead 8180

0007 0000 0000 0001 3f00 0102 0304 0506

0708 090a 0b0c 0d0e 0f10 1112 1314 1516

1718 191a 1b1c 1d1e 1f20 2122 2324 2526

2728 292a 2b2c 2d2e 2f30 3132 3334 3536

3738 393a 3b3c eb0a 0200 00c0 0000 0000

003f 0001 eb44 5e29 c089 4610 4089 c389
460c




Figure 6: TCPDUMP Output of .25's Reply



The next couple of packets we see here show us 192.168.1.5 making a connection with 192.168.1.25. Then we will see 192.168.1.25 give .5 root access (the gold). The initial connection is shown in Figure 7.


16:01:44.789072 <: 192.168.1.5.1373 >
192.168.1.25.36864: S

3252931087:3252931087(0) win 32120
1741083 0,nop,wscale 0> (DF) (ttl 64, id 4629)



16:01:44.790474 > 192.168.1.25.36864 > 192.168.1.5.1373: S

3700394557:3700394557(0) ack 3252931088 win 32120 1460,sackOK,timestamp 33477
1741083,nop,wscale 0> (DF) (ttl 64,
id 4)



16:01:44.790849 < 192.168.1.5.1373 > 192.168.1.25.36864: . 1:1(0)

ack 1 win 32120 (DF) (ttl 64,
id 4630)





Figure 7



Notice the high port (36864) that 192.168.1.5 is trying to connect to. To save some space I will omit ACK packets, unless they are vital to the sequence of events. Here comes root!!



16:01:44.809078 < 192.168.1.5.1373 > 192.168.1.25.36864: P
1:16(15) ack 1 win 32120 (DF)

(ttl 64, id 4631)

4500 0043 1217 4000 4006 a52f c0a8 0105

c0a8 0119 055d 9000 c1e3 ca10 dc8f 8a3e

8018 7d78 90b5 0000 0101 080a 001a 911d

0000 82c5 756e 616d 6520 2d61 3b20 6964
3b0a 00





Figure 8



The bolded hex numbers in bold come out to 'uname -a; id;'. Again, notice the high destination port.



16:01:44.912351 > 192.168.1.25.36864 >
192.168.1.5.1373: P

1:73(72) ack 16 win 32120 <:nop,nop,timestamp 33490 1741085> (DF)

(ttl 64, id 6)

4500 007c 0006 4000 4006 b707 c0a8 0119

c0a8 0105 9000 055d dc8f 8a3e c1e3 ca1f

8018 7d78 9af8 0000 0101 080a 0000 82d2

001a 911d 4c69 6e75 7820 7374 6565 6c65

7273 3132 2032 2e32 2e31 322d 3230 2023

3120 4d6f 6e20 5365 7020 3237 2031 303a

3235 3a35 3420 4544 5420 3139 3939 2069

3538 3620 756e 6b6e 6f77 6e0a





Figure 9



Note that .25 is now sending all of its computer information to .5.



16:01:44.944313 > 192.168.1.25.36864 >

192.168.1.5.1373: P
73:97(24) ack 16 win 32120 (DF)
(ttl 64, id 7)

4500 004c 0007 4000 4006 b736 c0a8 0119

c0a8 0105 9000 055d dc8f 8a86 c1e3 ca1f

8018 7d78 bd97 0000 0101 080a 0000 82d5

001a 9127 7569 643d 3028 726f 6f74 2920
6769 643d 3028 726f 6f74 290a





Figure 10



Ok, we now have root. The bolded hex numbers above = uid=0(root) gid=0(root).





Written by Toby Miller for SecurityFocus.com. You can see the original text here.


Newsletter signup

Signup to our monthly newsletter and stay in touch with IT news!

Free E-books

We've got ebooks! But they're not online. :( Please give us a few days to bring downloads back.

Contact

Have something to say or just wanna drop us a line? Please keep this in mind: to spam, we reply with spam.

Contact us »