Re: Advisory: IIS FTP Exploit/DoS Attack

[smm () WPI EDU (Seth McGann)]

<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