Re: Re[2]: IIS .ASP Remote Buffer Overflow [testing for vulnerable installations]

["Riley Hassell" <rhassell () eeye com>]

lets see whats up...

Do it first manually. Copy and paste the request into a telnet session with
the web server. I used the telnet.exe that came along with the machine I'm
testing. It's running Windows 2000 Server, build 5.00.2195 with SP2 all the
latest hotfixes prior to Q319733.

Here it is:
----start
POST /iisstart.asp HTTP/1.1
Accept: */*
Host: hostname-changed.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked

1
E
0
----end

If you have troubles,try hitting [enter] a few more times in your telnet
session after you have pasted the session in. Be patient, IIS may need to
load the ISAPI filter, this could take several seconds or longer depending
on the speed of the system.

Also make sure you haven't changed your iisstart.asp file, just so we have
the same test environment.

For the app you're writing what particular language are you using?
If you're writing an app to check for these, try adding a healthy timeout
limit for data reads. IIS may need to load the filter so it could take a
while.

If IIS is still not throwing the error, then (if you'd like), send me a
packet capture of your telnet session and a copy of the iisstart.asp file on
the machine you're testing. Then I should be able to tell you why it's not
working from that.

There's also the possibility that this vulnerability may have been
introduced with a  later version of the IIS related dll releases. Maybe a
underlying code change, or patch caused this issue. Only speculation of
course ;)

-R

Riley Hassell
Security Research Associate
eEye Digital Security

Get up...
and light the world on fire.

> In my case it produces no error and simply responses with page content
after
>    "\r\n"
>    "1\r\n"
>    "E\r\n"
>    "0\r\n"
>    "\r\n"
>
>
> RH> It won't overwrite anything mission critical so the dllhost shouldn't
lock
> RH> up or exit. If you're vulnerable then you'll the following string in
the
> RH> error message "(0x80004005)<br>Unspecified". When a server is patched
it
> RH> will respond with a new error, I believe it's
(0x80004005)<br>Request...
> RH> You can also try putting NULL's in strange places in you request. The
rollup
> RH> fixes a problem in parsing requests with NULLs. When IIS see's
something
> RH> invalid in a request it will error back with "parameter incorrect", on
an
> RH> unpatched system the responses will vary.
>
>
>
> --
> ~/ZARAZA
> ...áåç äóáèíêè íèêîãäà íå ïðèíèìàëñÿ îí çà ïðîãðàììèðîâàíèå. (Ëåì)