blackhat 99

Perils and Pitfalls of IIS Web Security

Eugene Schultz, Global Integrity Corporation (an SAIC Company) and Purdue University

Black Hat ConferenceLas Vegas, Nevada

July 8, 1999

Copyright 1999, Global Integrity Corporation - All Rights Reserved

Copying these materials without the explicit, written permission of Global Integrity Corporation is prohibited.

2 Copyright 1999, Global Integrity Corporation

Agenda

Introduction

Vulnerabilities

Solutions

Conclusion


Surprise, surprise?

“According to federal officials, federal websites and computer systems are particularly vulnerable to outside attacks because they lack two important elements: adherence to security plans and qualified personnel to maintain security measures.”

http://www.newspage.com/cgi-bin/NA.GetStory?story=h0624132.500 &date=19990625&level1=46510&level2=46515&level3=821

25 June 1999: Federal Computers Vulnerable


About the IIS Web serverVery widely used Web server package

Main advantages Price Ease of development and maintenance

Server itself can be implemented using CGI ISAPI ASP


A related component---Front PageSupports development and maintenance of Web

pagesConsists of

Explorer (client side) Editor (client side) Server Server Extensions (for managing and referencing

HTML pages)

FrontPage “Bots” perform tasks such as automatically creating a table of contents


IIS Web authentication*Basic authentication---to determine

identification and rights of client First check--to see if user is anonymous

If anonymous access fails, server sends back information about other types of authentication that are available

If user is authenticated, server determines whether user’s credentials are sufficient to allow access to resources

Second--challenge-response authentication If anonymous access fails, IIS will normally attempt

challenge-response authentication Last resort--cleartext authentication

* - Most events that occur are transparent to users---exception, when the type of authentication used requires users to enter a username-password sequence


MSV1_0 authentication

SERVER

CLIENT

1. Authentica- tion request

2. 8-byte

nonce

3. Encrypted nonce

4. Retrieval of entries from SAM database

5. Encryption of nonce

6. Comparison of encrypted nonces


Choosing IIS Web authentication X WWW Service Properties for EXCELSIOR

OK Cancel Apply Help

Service Directories Logging Advanced

Connection Timeout: 600 seconds

Maximum Connections 1000

Anonymous Logon

Username

Password

Password Authentication

Allow Anonymous

Basic (Clear Text)

Windows NT Challenge/Response


Basic IIS access control methodsAuthentication

Limited execution environmentNTFS permissionsInternet Service Manager settings


Exposures in IIS Web servicesIncompatibility of authentication schemes

drives cleartext authentication as the common denominator

Web users are authenticated either as local users or domain users

Local access short circuits many security controls Unauthorized access to Web server can result in

unauthorized domain-wide access

IIS runs as SYSTEM


Exposures in IIS Web servicesBuffer overflow conditions abound

IUSR_Servername account is created either in a domain or on a member server of an IIS Web server

ASP page access is not properly limitedFront Page vulnerabilities allow a variety of

undesirable outcomes, including Unauthorized, privileged access to Web server Ability to remotely read and write to any file Denial of service


Exposures in IIS Web servicesVulnerabilities in Active Server itself can result in a

wide range of undesirable outcomes from a security perspective

Denial of service Ability to modify Web page content Ability to read and/or alter files that are not part of the

Web server

Bots may allow unauthorized reads/writes of Web page content

Most Web servers themselves are not well-written from a security perspective


Example 1A potential buffer overflow condition in the ISAPI

extension ISM.DLL (a filter used to process .HTR files) allows

Someone to crash IIS by sending a long argument (FORMAT: GET /[overflow].htr HTTP/1.0)

Execution of rogue code

Version affected: IIS 4.0 (SPs 4 and 5)Problem: lack of proper bounds checkingSolutions: Apply hot fix, or remove the script

mapping for .HTR files from ISAPI.DLL


Example 2A bug allows anyone to use a default .asp page to

view and also to modify source code by requesting a file from a virtual directory (simply enter ../)

Problem: normal processing of the file is circumvented

Several variants of this bug existFound in IIS 3.0 and 4.0Patch is available (but best solution may be to

remove all default .asp pages)


Example 3A bug allows CGI scripts that require

authentication to be run without any authentication

Version affected: IIS 3.0Is really more of a limitation in an intended

security feature than a vulnerabilityUpgrade to IIS 4.0


Example 4Someone can discover the path to a virtual

directoryRequires only connecting to the

“msdownload” directory at a site, then pressing Refresh/Reload

Can facilitate an attacker’s efforts to locate resources to attack

All versions are affectedNo patch available yet


Example 5A malformed GET request can crash IIS,

causing data corruptionRequires that more than one virtual server run

on one machine Problem: quitting inetinfo.exe by one server

fails to produce a file handle for TEMP files that the other needs for data writes

Problem is robust across different releasesHot fix (see Q192296) available


Example 6An unprivileged user can create an ISAPI

extension to load rogue CGIs that run as SYSTEM

GetExtensionVersion() Default()

Applies to any Web server that supports ISAPI extensions

Exploit code posted widely over the netAll versions are affectedSolution: do not allow users to load CGIs


Example 7An anonymous user can use NetBIOS

mechanisms to remotely reach \%systemroot%\system32\inetsrv\iisadmpwd (virtual directory /IISADMPWD) to start up HTR files

Passwords can be changed without authorization Information about accounts is readable

Best solution is debatable Delete /IISADMPWD? Filter traffic bound for TCP port 139?


Example 8An unauthorized user can access cached files

without being authenticated Requires that

More than one virtual server run on one machine Both servers have the identical physical and virtual

directory for each target fileThis bug is found in all versions of IISProblem: failure to recheck credentials after a

cached file is initially accessedSolutions: Allow only one virtual server on any

machine, or disable caching


Example 9IIS may fail to log successful HTTP requests

Requests include File name Default.asp Request method (the attacker must make this very

long---at least 10140 bytes)

May be found only in particular releases (e.g., IIS 4.0 server that was upgraded)

No suitable solution so far, but try installing IIS 4.0 instead of upgrading from IIS 3.0


Example 10Under certain conditions, calling one or more

ASPs may cause 100% CPU utilization \exair\root\search\advsearch.asp \exair\root\search\query.asp \exair\root\search\search.asp

Default exair page and the DLLs it references must not be in memory

Best solution: delete \exair and everything below it


IIS-specific Web security measuresConsider running a Web server that does not

run as SYSTEMRun the most recent version of IIS Web serverAvoid running IIS on domain controllers Ensure that the IUSR_<servername> account

has a strong passwordDedicate Web-accessible volumes to HTTP-

based access


IIS-specific Web security measures

Use Internet Service Manager to set access permissions (read and/or write)

Ensure that Front Page extensions have appropriate NTFS permissions

Avoid Active Server implementations when security needs are higher

Use Active Server only to access a Microsoft transaction component (i.e., don’t put code in Active Server itself)


IIS-specific Web security measuresConsider enabling IP filtering

Disable the NetBIOS layer of networkingUse SSL, HTTP-S, or PCT to encrypt sessionsIt is generally best to deploy IIS as an internal

Web serverPatch, patch, patch...


Placement of external IIS servers

IIS WEB SERVER

SERVER SHOULD NOT BE PART OF ANY NT DOMAIN

SECURITY PERIMETER

INTERNET OR EXTERNAL NETWORK

ROUTER

INTERNAL NETWORK

FIREWALL

DMZ


TFTPTrivial File Transfer

IIS-specific Web security measures

Consider enabling IP filtering Disable the NetBIOS layer of networking Use SSL, HTTP-S, or PCT to encrypt

sessions It is generally best to deploy IIS as an

internal Web server Patch, patch, patch...

(continued from previous slide)

Conclusion We haven’t even looked into security-related

vulnerabilities in Browsers IIS FTP

Choose your poison---CGI, ISAPI, or ASP Securing IIS requires paying attention to

IIS and its many vulnerabilities The many extensions and filters that are typically part

of the IIS environment The Web application Windows NT itself

Conclusion The number of reported bugs has

increased dramatically over the last year The problem is only going to get worse in

the next version

(continued from previous slide)

Fronting server

Cache box


TCP/IP Services and NT Domains

Serious concern: NT web servers or firewalls running within an NT domain (and, thus, effectively within NT’s security perimeter)

Recommendations: Run each firewall as a domain-independent NT

platform Run Web servers as domain-independent NT

platforms or as part of a Web server domain Do not mix internal and external Web servers in

the same domain


TCP/IP Services and NT Domains

Continued

NT EXTERNALWEB SERVER

SERVERS THAT ARE NOT PART OF AN NT DOMAIN

SECURITY PERIMETER

INTERNET

ROUTER

INTERNAL NETWORK

NT FIREWALL


Sniffer Attacks

Logical or physical sniffersData in packet headers for NT logon

packets is vulnerableFTP and telnet-based logons are in

cleartext Network Monitor (NM) tool part Back OfficeSolution: inspecting for unauthorized

sniffers, use of VPN’s, limiting use of NM and similar tools


Password Transmission in

Heterogeneous Environments

Cleartext password

Windows NT Unix


PPTP-Protected Transmissions

PPTP

Host Host

RAS Server RAS Server


Password Cracking

The Windows NT security model attempts to provide strong protection against password cracking Strong password encryption algorithm Cleartext passwords are not sent over the net during conventional NT

authentication Security Accounts Manager (SAM) Database is not accessible to

interactive users Accounts Policy Settings guard against weak passwords

What Microsoft didn’t realize The NT encryption procedure itself is not that strong The SAM database can be accessed in a number of ways The challenge-response mechanism itself is vulnerable NT-based web browsers send encrypted passwords to web servers


Password Cracking

Solutions PPTP Exceptionally strong passwords Third-party authentication


Exploitation of SMB

SMB servers have weak authorization requirements for file transfers

SMB has numerous back-door mechanismsConcerns:

It is relatively easy to trick SMB into transferring files that are not otherwise available for access

SMB can be spoofed

Best solution (?): disable SMB


Considerations for Access to

Other PlatformsWindows NT does not recognize permissions from any operating system other than NTFS

Most NT-compatibility programs require that A privileged user remotely logon to the NT domain to

establish remote access All subsequent access not be interfered with by the OS

on which files are stored

Important point: the only access control is in most cases NT share permissions

Implication: move critical files to NT servers if security is a major consideration


Case Study: Gateway Services for Netware

Service that allows Windows NT access to resources on NetWare services Files Directories Printers

Allows NT Server to serve as nondedicated gateway Uses NWLink to connect to, then share NetWare

server’s directoriesUsers can connect to directories using NT share

mechanism


So What’s The Problem?

“Gaps” in the Windows NT security modelFaulty implementations that result in

security exposures Security weaknesses in logic of design of

network service programs Backdoors in protocolsImmaturity of Windows NT as an operating

system


Cracks in the NT Security Infrastructure

It takes time to learn how to compromise security in a new operating system

Much of “the new” in Windows NT is really “the old,” after all

Many network security control mechanisms don’t go far enough

New services and utilities keep getting added to Windows NT’s capabilities


ConclusionWindows NT has many security-related “bells and

whistles” that really are not so important NT domains in many respects constitute “steel

doors in grass huts”NT-based TCP/IP services will increasingly

constitute the greatest threat to security Most critical tools

Third-party authentication tools Firewalls Packet scanners Vulnerabilities scanners Network monitoring tools


ConclusionThe problem of dealing with Windows NT

network vulnerabilities is exacerbated by The immaturity of this operating system Microsoft’s approach to dealing with NT-

related vulnerabilities The lack of a clearinghouse for NT-related

vulnerability information

Windows 2000 may provide a stronger framework on which to build security

blackhat 99

Documents