-----BEGIN PGP SIGNED MESSAGE-----

Hi All,

Because this report makes some rather serious claims, and was sent to
BugTraq at the start of a holiday weekend, we've been treating it as
an urgent issue.  We were concerned that, if the report were correct,
malicious users might attack web sites while the system
administrators were home for the weekend.  We therefore called the
IIS Security Team into the lab early this morning, and they worked
throughout the day and well into the night in an effort to reproduce
the denial of service the report describes.

However, even after a thorough investigation using a lab setup that
mirrors the one discussed in the report, we have not seen a denial of
service.  We contacted the author of the report, and he provided
network traces from his system.  But even when we replayed them
against our lab setup, we did not see the server become unresponsive.
 (In fact, we noticed that even in the author's network trace, the
servers continued to respond, albeit slowly, throughout the trace).
At this point, we hypothesize that what appeared to be a denial of
service have may actually been a case of flooding.  We've seen cases
today in which the high bandwidth of the lab setting enabled the
client to generate invalid requests faster than the server could
process them.  (The inclusion of the %0%0 in the URL does marginally
increase the work factor required to parse the request).  However, in
every case, the server's performance returned to normal when the
flooding ceased, and it did (eventually) respond appropriately to
every request.

Nevertheless, we are continuing to investigate this issue.  If anyone
is able to reproduce the reported denial of service, we'd be most
interested in any information you could provide.  Please contact us
at [EMAIL PROTECTED]  Regards,

Scott Culp
Security Program Manager
Microsoft Security Response Center



- -----Original Message-----
From: NtWaK0 [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 13, 2001 8:53 AM
To: BUGTRAQ; Microsoft Security Response Center
Subject: DOSSING IIS 4 or IIS5 fully patched using GET /%0%0 HTTP/1.0
Importance: High


______________________________________________________________________

                      NtWaK0,  SecurHack. Labs
                    Security Advisory  1-13-2001
    DOSSING IIS 4  or IIS5 fully  patched using GET  /%0%0 HTTP/1.0
______________________________________________________________________

oooooooooooooooooo
Vulnerable Systems
oooooooooooooooooo
IIS 4 and IIS 5 even if fully patched.

oooooooo
Synopsis
oooooooo

While playing with miner in retina I  sent this GET /%0%0 HTTP/1.0 to
one
of my
IIS  4  and IIS  5  servers, I  noticed  that retina  is  taking a
lot  of
time
to jump to the next defined variable in the brain.ini which should be
GET
/%0%1
and so on.

Retina Result
ooooooooooooo

Command: GET /%0%0 HTTP/1.0
Notes::  Connection to server lost.
Error::  10060

Command: GET  /_vti_inf.html%0%0 HTTP/1.0
Notes::  Connection  to server  lost.
Error::  10060 Command:
GET  /_vti_inf.html%0%0 HTTP/1.0
Notes::  Connection  to server lost.
Error::  10060

Pinging the box while running retina even from different subnet it
wont
answer.
You can connect to the web but you have to wait forever for it to
load.
I have tried that on IIS 4 and II 5 and same result ....

oooooooooooooooo
Proof-Of-Concept
oooooooooooooooo

1- Get Retina From eeye.com
2- Install it
3- Edit the file Brain.ini located
   C:\Program Files\Retina 2.0\Modules\Retina\Miner\brain.ini
<default
4- Put this in your brain.ini file
   [General]
   Title=HTTP Miner
   [Commands]
   1=GET /%%cgi-bin%%%%passwordfile%%%%passwordfile%% HTTP/1.0
   [Variables]
   cgi-bin=,
   passwordpath=%0,%1,%2,%3,%4,%5,%6,%7,%8,%9,%a,%b,%c,%d,%e,%f,
5- Run retina and choose miner and type your IP GO :)

Btw that will start sending GET /%0%0 HTTP/1.0 GET /%0%1  HTTP/1.0
etc
To see the result open  up your browser and point  to the IP you are
mining
and
you will notice  you can just  connect and your  LAN in my  case
cable is
almost
flooded. Ping the IP you are mining and you will get a Ping time out.

Even if you try to connect to that IP from totally a different
network you
wont
be able to view the page or it will take for-ever to load.

oooooooooo
Resolution
oooooooooo
No Idea :(

ooooooo
Credits
ooooooo

The discovery and documentation of  this vulnerability was conducted
by
NtWaK0.
For   more  information   Dalnet  channel   #security
______________________________________________________________________
The only secure computer is one that's unplugged, locked in a safe,
and buried 20 feet under the ground in a secret location... and i'm
not even too sure about that one"--Dennis Huges, FBI.
____________________________________________________________._________
_
Live Well Do Good                                           |
Accept no limitations                                     \(|)/
                                                           /`\
NtWaK0


-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBOmFUrY0ZSRQxA/UrAQFZrAf/TxrUcEZDE3TPovg0H0pPy828gRfUr1NZ
LigUuQrZFZ5pkRIcSQd7PInLLcVx0u7E+cSLWnE9B4TeZK4MOKU8+s2VTp7tJVK9
8RYQhw4Gb3k04Vs7N6Ei8tqesfOi1rU4+KECPWjkjpPRFUhQvY4Z7epsHZiqn7nm
QpyebT407+3vJzbzoNWr7IcsziNnIdH2plWHervIGkLwNOYU/T8r5bbhN23Wsvf/
nEzNKbyT7jfTC7D1+O5Z36riEe08J7H9eNEJnluTeN48zcZQtKlTjAaXQDNtlIFu
v3j1gjNvDQW7/M6LbcamNnoW4UT1e8YFGeAcOyA1YGVapA5PGEU+jQ==
=jju8
-----END PGP SIGNATURE-----

Reply via email to