Re: Advisory: IIS FTP Exploit/DoS Attack

[mattc () enigma repsec com (Matt Conover)]

> > 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
***************************************************************************