Perils and Pitfalls of IIS Web Security

1. Perils and Pitfalls of IIS Web Security Eugene Schultz, Global Integrity Corporation (an SAIC Company) and Purdue University Black Hat Conference Las 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. Agenda Introduction Vulnerabilities Solutions Conclusion

3. Surprise, surprise? 25 June 1999: Federal Computers Vulnerable “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

4. About the IIS Web server • Very widely used Web server package • Main advantages • Price • Ease of development and maintenance • Server itself can be implemented using • CGI • ISAPI • ASP

5. A related component---Front Page • Supports development and maintenance of Web pages • Consists 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

6. 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

7. MSV1_0 authentication 4. Retrieval of entries from SAM database 5. Encryption of nonce 6. Comparison of encrypted nonces 1. Authentica- tion request 2.8-bytenonce SERVER 3. Encrypted nonce CLIENT

8. Choosing IIS Web authentication WWW Service Properties for EXCELSIOR X 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 OK Cancel Apply Help

9. Basic IIS access control methods • Authentication • Limited execution environment • NTFS permissions • Internet Service Manager settings

10. Exposures in IIS Web services • Incompatibility 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

11. Exposures in IIS Web services • Buffer 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 limited • Front 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

12. Exposures in IIS Web services • Vulnerabilities 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

13. Example 1 • A 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 checking • Solutions: Apply hot fix, or remove the script mapping for .HTR files from ISAPI.DLL

14. Example 2 • A 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 exist • Found in IIS 3.0 and 4.0 • Patch is available (but best solution may be to remove all default .asp pages)

15. Example 3 • A bug allows CGI scripts that require authentication to be run without any authentication • Version affected: IIS 3.0 • Is really more of a limitation in an intended security feature than a vulnerability • Upgrade to IIS 4.0

16. Example 4 • Someone can discover the path to a virtual directory • Requires 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 affected • No patch available yet

17. Example 5 • A malformed GET request can crash IIS, causing data corruption • Requires 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 releases • Hot fix (see Q192296) available

18. Example 6 • An 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 net • All versions are affected • Solution: do not allow users to load CGIs

19. Example 7 • An 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?

20. Example 8 • An 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 file • This bug is found in all versions of IIS • Problem: failure to recheck credentials after a cached file is initially accessed • Solutions: Allow only one virtual server on any machine, or disable caching

21. Example 9 • IIS 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

22. Example 10 • Under 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

23. IIS-specific Web security measures • Consider running a Web server that does not run as SYSTEM • Run the most recent version of IIS Web server • Avoid running IIS on domain controllers • Ensure that the IUSR_<servername> account has a strong password • Dedicate Web-accessible volumes to HTTP-based access

24. 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)

25. 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...

26. INTERNET OR EXTERNAL NETWORK ROUTER DMZ FIREWALL INTERNAL NETWORK SECURITY PERIMETER Placement of external IIS servers SERVER SHOULD NOT BE PART OF ANY NT DOMAIN IIS WEB SERVER

27. TFTP • Trivial File Transfer

28. TFTP • Trivial File Transfer

29. 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)

30. 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

31. 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 Fronting server Cache box (continued from previous slide)

32. 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

33. INTERNET ROUTER NT FIREWALL INTERNAL NETWORK SECURITY PERIMETER TCP/IP Services and NT Domains SERVERS THAT ARE NOT PART OF AN NT DOMAIN NT EXTERNALWEB SERVER Continued

34. Sniffer Attacks • Logical or physical sniffers • Data in packet headers for NT logon packets is vulnerable • FTP and telnet-based logons are in cleartext • Network Monitor (NM) tool part Back Office • Solution: inspecting for unauthorized sniffers, use of VPN’s, limiting use of NM and similar tools

35. Password Transmission in Heterogeneous Environments Windows NT Unix Cleartext password

36. PPTP-Protected Transmissions Host Host PPTP RAS Server RAS Server

37. 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

38. Password Cracking • Solutions • PPTP • Exceptionally strong passwords • Third-party authentication

39. Exploitation of SMB • SMB servers have weak authorization requirements for file transfers • SMB has numerous back-door mechanisms • Concerns: • 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

40. Considerations for Access toOther Platforms • Windows 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

41. CaseStudy: GatewayServicesforNetware • 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 directories • Users can connect to directories using NT share mechanism

42. So What’s The Problem? • “Gaps” in the Windows NT security model • Faulty implementations that result in security exposures • Security weaknesses in logic of design of network service programs • Backdoors in protocols • Immaturity of Windows NT as an operating system

43. 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

44. Conclusion • Windows 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

45. Conclusion • The 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