Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Web Server/CGI)  >   Microsoft Internet Information Server (IIS) Web Server Vendors:   Microsoft
(A User Provides Guidance) Re: Microsoft IIS Web Server Can Be Effectively Shutdown By Certain Internal-Network Attacks When The Underlying OS Supports User Account Lockouts
SecurityTracker Alert ID:  1001502
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  May 9 2001
Impact:   Denial of service via network

Description:   Due to the intended design of Microsoft NT and Windows 2000 and due to the default account used by the IIS web server for anonymous web access, it is reported that the IIS server can be effectively shut down by a remote user on the internal network.

A user provides some guidance on related issues. Please read the Source Message for details.

For details on the original vulnerability report, please see the Message History.

Impact:   A remote user with access to the underlying server via Microsoft networking protocols can cause the IUSR_COMPUTERNAME account to become locked out, thereby prohibiting any anonymous web surfing to the IIS web server until the lockout period expires.
Solution:   No solution was available at the time of this entry. The vendor reportedly responded that this is the intended design.
Vendor URL: (Links to External Site)
Cause:   Configuration error
Underlying OS:  Windows (NT), Windows (2000)

Message History:   This archive entry is a follow-up to the message listed below.
Apr 23 2001 Microsoft IIS Web Server Can Be Effectively Shutdown By Certain Internal-Network Attacks When The Underlying OS Supports User Account Lockouts

 Source Message Contents

Subject:  Re: IIS DOS Attack

Account lockout always exposes you to some degree of denial of service
potential. I've had a couple of people ask how to maintain account lockout
on the domain users, but not encounter this situation. The key here is to
remember that account lockout properties depend on the account domain - so
if the IIS server is running as a local account, don't set the local system
for account lockout. You can then set the domain for lockout if you like.

Additionally, one work-around for a typical web server where NetBIOS/SMB
services aren't available to an attacker is to make sure that no web
directories allow NTLM authentication. This prevents both lockouts and
password guessing attacks.

Finally, if it is an internal server, you go check your audit logs, find the
system that the attacks came from, and go fire the jerk who is screwing up
your servers. Even though one cannot discount insider attacks, particularly
on very large networks, there are non-technological solutions to certain

As a last point, IPSec can be a very handy tool that will help with Win2k
systems - you could set ports 135-139,445 TCP/UDP to require IPSec, and base
that IPSec on a certificate you distribute only to people authorized to
administer the web server.

> -----Original Message-----
> From: Windows NTBugtraq Mailing List
> [mailto:NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM]On Behalf Of Nicholas Staff

> Description:
> The IUSR_COMPUTERNAME account is governed by account lockout policies
> and can be locked out. This is the default account used by IIS for
> anonymous web access and when it is locked out anonymous access is
> denied.  Any IIS server with a lockout policy that can be
> made to prompt
> for authentication is vulnerable. Additionally nearly every
> Internal/Corporate web site running on IIS can be shut down by any
> employee on their network.


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2019, LLC