W1.1 Description
IIS is prone to vulnerabilities in three major classes: failure to handle unanticipated requests, buffer overflows, and sample applications. Each will be addressed briefly here.

1. Failure to Handle Unanticipated Requests. Many IIS vulnerabilities involve a failure to handle improperly (or just deviously) formed HTTP requests. A well-known example is the Unicode directory traversal vulnerability, which was exploited by the Code Blue worm. By crafting a request to exploit one of these vulnerabilities, a remote attacker may:
   • View the source code of scripted applications.
   • View files outside of the Web document root.
   • View files the Web server has been instructed not to serve.
   • Execute arbitrary commands on the server (resulting in, for example, deletion of critical files or installation of a backdoor).
   
   
2. Buffer Overflows. Many ISAPI extensions (including the ASP, HTR, IDQ, PRINTER, and SSI extensions) are vulnerable to buffer overflows. A well-known example is the .idq ISAPI extension vulnerability, which was exploited by the Code Red and Code Red II worms. A carefully crafted request from a remote attacker may result in:
   • Denial of service.
   • Execution of arbitrary code and/or commands in the Web server's user context (e.g., as the IUSR_servername or IWAM_servername user).
     
   
   
3. Sample Applications. Sample applications are generally designed to demonstrate the functionality of a server environment, not to withstand attacks, and are not intended to serve as production applications. Combined with the facts that their default location is readily known and their source code is readily available for scrutiny, this makes them prime exploit targets. The consequences of such exploits can be severe; for example:
   
   • A sample application, newdsn.exe, allowed the remote attacker to create or overwrite arbitrary files on the server.
   • A number of such applications allow remote viewing of arbitrary files, which may be used to gather information such as database userids and passwords.
   • An iisadmin application, ism.dll, allows remote access to sensitive server information including the Administrator's password.

W1.2 Operating Systems Affected

• Windows NT 4 (any flavor) running IIS 4
• Windows 2000 Server running IIS 5
• Windows XP Professional running IIS 5.1

W1.3 CVE Entries
CVE-2001-0241, CVE-2001-0333, CVE-2001-0500, CAN-2002-0079, CVE-2000-0884,
CVE-2000-0886, CAN-2002-0071, CAN-2002-0147, CAN-2002-0150, CAN-2002-0364,
CAN-2002-0149, CVE-1999-0191, CAN-1999-0509, CVE-1999-0237, CVE-1999-0264,
CVE-2001-0151, CAN-1999-0736, CVE-1999-0278, CAN-2002-0073, CVE-2000-0778,
CVE-1999-0874, CVE-2000-0226, CAN-1999-1376, CVE-2000-0770, CVE-2001-0507

W1.4 How to Determine if you are Vulnerable
Given the number of vulnerabilities, some of which are addressed only in a cumulative security roll-up package from Microsoft, it is simplest to presume that you are vulnerable if the cumulative roll-up has not been applied. To determine whether the cumulative roll-up has been applied on your server, check the registry for the entry listed for your platform below.

Windows NT 4:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Q319733

Windows NT 4 Terminal Server Edition:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Q317636
  

Windows 2000:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP3\Q319733
  

Windows XP:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP1\Q319733
  

Alternatively, you may use HFNetChk (see "Stay Current" under W1.5) to verify the presence of the corresponding patch:

• NT 4: Q319733
• NT 4 Terminal Server Edition: Q317636
• 2000 or XP: Q319733

You are probably vulnerable to sample application exploits if any of the following files resides in your %wwwroot%/scripts directory (e.g., C:\inetpub\wwwroot\scripts or D:\web\scripts) or any subdirectory thereof:

• code.asp
• codebrws.asp
• ism.dll
• newdsn.exe
• viewcode.asp
• winmsdp.exe

W1.5 How to Protect Against It

1. Apply the current patches. In the case of IIS 4 on NT 4 with Service Pack 6a, this means applying a cumulative security roll-up package and a single hotfix. In the case of IIS 5 or 5.1 on Windows 2000 or XP (respectively), the roll-up and the hotfix are included in service packs. URLs are provided below.

   IIS 4 on NT 4:

   • Service Pack 6a: http://www.microsoft.com/ntserver/nts/downloads/recommended/SP6/allSP6.asp
   • Security Rollup: http://www.microsoft.com/ntserver/nt s/downloads/security/q319733/
   • Hotfix: http://www.microsoft.com/ntserver/nts/downloads/security/q321599/
     

   IIS 4 on NT 4 Terminal Server Edition:
   

   • Service Pack 6: http://www.microsoft.com/ntserver/terminalserver/downloads/recommended/tsesp6/
   • Security Rollup: http://www.microsoft.com/ ntserver/terminalserver/downloads/critical/q317636/
   • Hotfix: http://www.microsoft.com/ntserver/nts/downloads/security/q321599/
     

   IIS 5 on Windows 2000:
   

   • Service Pack 3: http://www.microsoft.com/windows2000/downloads/servicepacks/sp3/
     

   IIS 5.1 on Windows XP:
   

   • Service Pack 1: http://www.microsoft.com/WindowsXP/pro/downloads/servicepacks/sp1/
     
     
2. Stay Current. These service packs, rollup patches and hotfixes only remedy vulnerabilities that are already known. As new IIS weaknesses are uncovered, you will need to patch accordingly. HFNetChk, the Network Security Hotfix Checker, assists the system administrator in scanning local or remote systems for current patches. The tool works on Windows NT 4, Windows 2000, and Windows XP. The current version can be downloaded from Microsoft at http://www.microsoft.com/technet/security/tools/hfnetchk.asp.
   
   
3. Eliminate Sample Applications. Sample applications, including the iisadmin tool, may be used to verify that a server installation works as expected, but should be deleted immediately thereafter. These applications can be found in the %wwwroot%/scripts directory. Ideally, however, the administrator should choose not to install the sample applications and Web-based administration tools at all.
   
   
4. Unmap Unnecessary ISAPI Extensions. Most IIS deployments have no need for most of the ISAPI extensions that are mapped by default, particularly .htr, .idq, .ism, and .printer. All unused ISAPI extensions should be unmapped. This can be done by hand through the Internet Services Manager, but the IIS Lockdown Wizard from Microsoft will also do the job. The current version can be downloaded from Microsoft at http://www.microsoft.com/technet/security/tools/locktool.asp.
   
   
5. Filter HTTP Requests. Many IIS exploits, including Code Blue and the Code Red family, use maliciously formed HTTP requests in directory traversal or buffer overflow attacks. The URLScan filter can be configured to reject such requests before the server attempts to process them. The current version has been integrated into the IIS Lockdown Wizard, but can be downloaded separately from Microsoft at http://www.microsoft.com/technet/security/tools/urlscan.asp.

W2.2 Operating Systems Affected
Most Microsoft Windows NT 4.0 systems running IIS 3.0 or 4.0, Remote Data Services 1.5, or Visual Studio 6.0.

W2.3 CVE Entries
CVE-1999-1011

W2.4 How to Determine if you are Vulnerable
If you are running Microsoft Windows NT 4.0 and IIS 3.0 or 4.0, then check for the existence of "msadcs.dll" (this is typically installed in "C:\Program Files\Common Files\System\Msadc\msadcs.dll", but that may vary depending on your system).

W2.5 How to Protect Against It
An excellent guide to the RDS and Jet weaknesses and how to correct them is available at http://www.wiretrip.net/rfp/p/doc.asp?id=29&iface= 2.

Microsoft has also issued several security bulletins detailing this exploit and how to repair it via configuration changes:

• http://support.microsoft.com/support/kb /articles/q184/3/75.asp
• http://www.microsoft.com/technet/secur ity/bulletin/ms98-004.asp
• http://www.microsoft.com/technet/secur ity/bulletin/ms99-025.asp

• http://isc.incidents.org/analysis.html?id=157
• http://www.eeye.com/html/Research/Advisories/AL20020522.html
• http://www.cert.org/incident_notes/IN-2002-04.html

• http://isc.incidents.org/analysis.html?id=180
• http://www.nextgenss.com/advisories/mssql-udp.txt
• http://www.eeye.com/html/Research/Flash/AL20030125.html
• http://www.cert.org/advisories/CA-2003-04.html

1. SQL/MSDE Server 2000 (Developer, Standard and Enterprise Editions)
2. Visual Studio .NET (Architect, Developer and Professional Editions)
3. ASP.NET Web Matrix Tool
4. Office XP
5. Access 2002
6. Visual Fox Pro 7.0/8.0

1. Disable SQL/MSDE Monitor Service on UDP Port 1434.
2. Apply the latest service pack for Microsoft SQL/MSDE server and/or MSDE 2000.
3. Apply the latest cumulative patch that is released after the latest service pack.
4. Apply any individual patches that are released after the latest cumulative patch.
5. SQL Server Authentication Logging
6. Secure the server at system and network level.
7. Minimize privileges of the MSSQL/MSDEServer service and SQL/MSDE Server Agent

1. Disable the SQL/MSDE Server Monitor on UDP Port 1434.
   
   This can be easily accomplished by installing and using the functionality within SQL Server 200 Service Pack 3a. Microsoft's database engine MSDE 2000 exhibits two buffer overflow vulnerabilities that can be exploited by a remote attacker without ever having to authenticate to the server. What further exacerbates these issues is that the attack is channeled over UDP. Whether the MSDE 2000 process runs in the security context of a domain user or the local SYSTEM account, successful exploitation of these security holes may mean a total compromise of the target system. MS-SQL/MSDE Slammer sends a 376 byte long UDP packet to port 1434 using random targets at a very high rate. Compromised systems will immediately start sending identical 376 byte packets once they are infected. The worm sends traffic to random IP addresses, including multicast IP addresses, causing a Denial of Service on the target network. Single infected machines have reported traffic in excess of 50 Mb/sec after being infected
   
   
2. Apply the latest service pack for Microsoft SQL/MSDE serve and MSDE 2000r.
   
   The current Microsoft SQL/MSDE Server service pack version is:
   • SQL/MSDE Server 7.0 Service Pack 4
   • MSDE/SQL Server 2000 Service Pack 3a
   To ensure that you are current with any future upgrades, monitor Make Your SQL/MSDE Servers Less Vulnerable from Microsoft TechNet.
   
   
3. Apply the latest cumulative patch that is released after the latest service pack.
   
   The current cumulative patch for all versions of SQL/MSDE/MSDE Server is available at MS02-061 Elevation of Privilege in SQL/MSDE Server Web Tasks (Q316333/Q327068).
   
   To ensure that you are current with any future upgrades, you can check for the latest cumulative patch for Microsoft SQL/MSDE Server at:
   1. Microsoft SQL/MSDE Server 7.0
   2. Microsoft SQL Server 2000
   3. MSDE Server Desktop Engine 2000 (MSDE 2000)
   
   
4. Apply any individual patches that are released after the latest cumulative patch.
   
   Currently, there is no individual patch after the release of the MS02 -061 Elevation of Privilege in SQL/MSDE Server Web Tasks (Q316333/Q327068). But to ensure that you are current with any future upgrades, you can check for any newly released individual patches at:
   1. Microsoft SQL/MSDE Server 7.0
   2. Microsoft SQL Server 2000
   3. MSDE Server Desktop Engine 2000 (MSDE 2000)
   
   
5. Enable SQL Server Authentication Logging
   
   Enable SQL Server Authentication Logging (commonly not enabled). This can be done through Enterprise Manager (Server properties; tab Security)
   
   
6. Secure the server at system and network level.
   
   One of the most commonly attacked MSSQL/MSDE exposures is that the default administrative account (known as "sa") is installed with a blank password. If your SQL/MSDE "sa" account is not password-protected, you effectively have no security and can be affected by worms and other exploits. Therefore, you should follow the recommendation from the "System Administrator (SA) Login" topic in SQL/MSDE Server Books Online to make sure that the built-in "sa" account has a strong password, even if your SQL/MSDE server does not run using this account. Microsoft Developer's Network has documentation on Changing the SQL Server Administrator Login and how to Verify and Change the System Administrator Password by Using MSDE.
   
   
7. Minimize privileges of the MSSQL/MSDEServer service and SQL/MSDE Server Agent
   
   Run the MSSQL/MSDEServer service and SQL/MSDE Server Agent under a valid domain account with minimal privileges, not as a domain administrator or the SYSTEM (on NT) or LocalSystem (on 2000 or XP) account. A compromised service running with local or domain privileges would give an attacker complete control of your machine and/or your network.
   1. Enable Windows NT Authentication, enable auditing for successful and failed logins, and then stop and restart the MSSQL/MSDEServer service. If possible, configure your clients to use NT Authentication.
   2. Packet filtering should be performed at network borders to prohibit specifically non-authorized inbound or outbound connections to MSSQL specific services. Ingress and egress filtering of TCP/UDP ports 1433 and 1434 could prevent internal or external attackers from scanning and or infecting vulnerable Microsoft SQL/MSDE servers on your network or the networks of others that are not explicitly authorized to provide public SQL/MSDE services.
   3. If TCP/UDP ports 1433 and 1434 need to be available on your Internet gateways, enable and customize egress/ingress filtering to prevent misuse of this port.

• Microsoft SQL/MSDE Server 7.0 Security
• Microsoft SQL/MSDE Server 2000 Security

Although this is a powerful and useful feature of Windows, improper configuration of network shares may expose critical system files, or may provide a mechanism for a nefarious user or program to take full control of the host. One of the ways in which both the Sircam virus (see CERT Advisory 2001-22) and Nimda worm (see CERT Advisory 2001-26) spread so rapidly in the summer of 2001 was by discovering unprotected network shares and placing a copy of itself in them. Many computer owners unknowingly open their systems to hackers when they try to improve convenience for co-workers and outside researchers by making their drives readable and writeable by network users. But when care is taken to ensure proper configuration of network shares, the risks of compromise can be adequately mitigated.

W4.2 Operating Systems Affected
Windows 95, Windows 98, Windows NT, Windows Me, Windows 2000, and Windows XP are all vulnerable.

W4.3 CVE Entries
CAN-1999-0519, CVE-2000-0979, CAN-2000-1079, CAN-1999-0621, CAN-1999-0520,
CAN-1999-0518
W4.4 How to Determine if you are Vulnerable
For Windows NT (SP4), Windows 2000 or Windows XP, the Microsoft Baseline Security Advisor, will report hosts are vulnerable to SMB exploits, and may be used to fix the problem. The tests can be run locally or on remote hosts.

Most commercially-available network-based scanners will detect open shares. A quick, free, and secure test for the presence of SMB file sharing and its related vulnerabilities, effective for machines running any Windows operating system, is available at the Gibson Research Corporation web site at http://grc.com/. Follow links to "ShieldsUP" to receive a real-time appraisal of any system's SMB exposure. Detailed instructions are available to help Microsoft Windows users deal with SMB vulnerabilities. Note that if you are connected over a network where some intermediate device blocks SMB, the ShieldsUP tool will report that you are not vulnerable when, in fact, you are. This is the case, for example, for users on a cable modem where the provider is blocking SMB into the cable modem network. ShieldsUP will report that you are not vulnerable. However, the 4,000 or so other people on your cable modem link can still exploit this vulnerability.

W4.5 How to Protect Against It
Several actions can be taken to mitigate the risk of exploitation of a vulnerability through a Windows Networking Shares:

• Disable sharing wherever it is not required. If the host does not need to share files, then disable Windows network shares in the Windows network control panel. If an open share should be closed, you can disable it through Explorer's properties menu for that directory, in Server Manager for Domains or in Group Policy Editor.
• Do not permit sharing with hosts on the Internet. Ensure all Internet-facing hosts have Windows network shares disabled in the Windows network control panel. File sharing with Internet hosts should be achieved using FTP or HTTP.
• Do not permit unauthenticated shares. If file sharing is required then don't permit unauthenticated access to a share. Configure the share so a password is required to connect to the share.
• Restrict shares to only the minimum folders required. Generally only one folder and possibly sub-folders of that folder.
• Restrict permissions on shared folders to the minimum required. Be especially careful to only permit write access when it is absolutely required.
• For added security, allow sharing only to specific IP addresses because DNS names can be spoofed.
• Block ports used for Windows shares at your network perimeter. Block the NetBIOS ports commonly used by Windows shares at your network perimeter using either your external router or perimeter firewall. The ports that should be blocked are 137-139 TCP and 137-139 UDP, and 445 TCP and 445 UDP.

The SYSTEM account has virtually unlimited privileges and it has no password, so you can't log on as SYSTEM. But SYSTEM sometimes needs to access information on other machines, such as available shares, user names, etc. -- the type of functionality offered by Network Neighborhood. Because it cannot log into the other systems using a UserID and password, it uses a Null session to get access. Unfortunately attackers can also log in as the Null Session.

W5.2 Operating Systems Affected
All flavors of Microsoft Windows NT, 2000 and XP.

W5.3 CVE Entries
CVE-2000-1200

W5.4 How to Determine if you are Vulnerable
Try to connect to your system via a Null session using the following command:

net use \\a.b.c.d\ipc$ "" /user:""

If you receive a "connection failed" response, then your system is not vulnerable. If no reply comes back that means that the command was successful and your system is vulnerable.

"Hunt for NT" can also be used. It is a component of the NT Forensic Toolkit from http://www.foundstone.com.

W5.5 How to Protect Against It
Domain controllers require Null sessions to communicate. Therefore, if you are working in a domain environment, you can minimize the information that attackers can obtain, but you cannot stop all leakage. To limit the information available to attackers, modify the following registry key:

HKLM/System/CurrentControlSet/Control/LSA/RestrictAnonymous=1

Setting RestrictAnonymous to 1 will still permit certain information to be made available to anonymous users, but will minimize leakage. This is the tightest host-level restriction in NT. In Windows 2000 and XP, you can set the value to 2 instead. Doing so will bar anonymous users from all information where explicit access has not been granted to them or the Everyone group, which includes null session users. But this higher setting may affect domain synchronization or other services, and therefore should be thoroughly tested. For this reason, it is recommended that only those machines which are visible to the Internet have this value configured. All other machines should be protected by a firewall configured to block NetBIOS and CIFS.

If you do not need file and print sharing, unbind NetBIOS from TCP/IP.

Note here that configuring RestrictAnonymous on domain controllers and certain other servers can disrupt many normal networking operations.

Internet users should never be allowed to access any internal domain controller or other computer not specifically built for external access. To stop such access, block TCP and UDP ports 135, 137, 138, 139 and 445 at the external router or firewall.

W6.1 Description
Although most current Windows environments have no need for LAN Manager (LM) support, Microsoft locally stores legacy LM password hashes (also known as LANMAN hashes) by default on Windows NT, 2000 and XP systems. Since LM uses a much weaker encryption scheme than more current Microsoft approaches (NTLM and NTLMv2), LM passwords can be broken in a very short period of time. Even passwords that otherwise would be considered "strong" can be cracked by brute-force in under a week on current hardware.

The weakness of LM hashes derives from the following:

• Passwords are truncated to 14 characters.
• Passwords are padded with spaces to become 14 characters.
• Passwords are converted to all upper case characters.
• Passwords are split into two seven character pieces.
  

This hashing process means that an attacker needs only to complete the trivial task of cracking two seven-character, upper-case passwords to gain authenticated access to your system. Since the complexity of cracking hashes increases geometrically with the length of the hash, each seven-character string is at least an order of magnitude simpler to attack by brute-force than would a combined fourteen-character string. Since all strings are exactly seven characters (including spaces) and entirely upper-case, a dictionary-style attack is also simplified. The LM hashing method therefore completely undermines good password policies.

In addition to the risk posed by having legacy LM hashes stored in the SAM, the LAN Manager authentication process is often by default enabled on clients and accepted by servers. As a result, Windows machines capable of utilizing stronger hash algorithms instead send weak LM hashes across the network, making Windows authentication vulnerable to eavesdropping by packet sniffing, and therefore easing the efforts of an attacker to obtain and crack user passwords.

W6.2 Operating Systems Affected
All Microsoft Windows operating systems.

W6.3 CVE Entries
N/A

W6.4 How to Determine if you are Vulnerable
If you are running a default installation of NT, 2000 or XP, you are vulnerable since LAN Manager hashes are stored locally by default.

If you have legacy operating systems in your environment that require LM authentication in order to communicate to servers, then you are vulnerable because those machines send LM hashes which can be sniffed off the network.

The more sophisticated Windows-based automated password cracking tools like LC4 (l0phtcrack version 4, available at http://www.atstake.com/research/lc/download.html) will show all hashes found in the SAM database (LM, NTLM or NTLMv2), and distinguish between the success cracking each. PLEASE NOTE: Never run a password scanner, even on systems for which you have administrative access, without explicit and preferably written permission from your employer. Administrators with the most benevolent of intentions have been fired for running password cracking tools without authority to do so.

W6.5 How to Protect Against It

1. Disable LM Authentication Across the Network. The best replacement in Windows for LAN Manager authentication is NT Lan Manager version 2 (NTLMv2). NTLMv2 challenge/response methods overcome many weaknesses in LM by using stronger encryption and improved authentication and session security mechanisms. The registry key that controls this capability in both Windows NT and 2000 is:
   
   Hive: HKEY_LOCAL_MACHINE
   Key: System\CurrentControlSet\Control\LSA
   Value: LMCompatibilityLevel
   Value Type: REG_DWORD - Number
   Valid Range: 0-5
   Default: 0
   
   Description: This parameter specifies the type of authentication to be used.
   0 - Send LM response and NTLM response; never use NTLMv2 session security
   1 - Use NTLMv2 session security if negotiated
   2 - Send NTLM authentication only
   3 - Send NTLMv2 authentication only
   4 - DC refuses LM authentication
   5 - DC refuses LM and NTLM authentication (accepts only NTLMv2)
   
   If all of your systems are Windows NT SP4 or later, you can set this to 3 on all clients and 5 on all domain controllers to prevent any transmission of LM hashes on the network. However, legacy systems (such as Windows 95/98) will not use NTLMv2 with the default Microsoft Network Client. To get NTLMv2 capability, install the Directory Services Client. Once installed, the registry value name is "LMCompatibility," and the allowed values are 0 or 3.
   
   If you cannot force your legacy clients to use NTLMv2, you can gain a slight improvement over LM hashing by forcing NTLM (NT Lan Manager, version 1) at the domain controller (set "LMCompatibilityLevel" to 4). But the most secure option with regard to legacy systems is to migrate them to newer systems, since the older operating systems do not allow this minimum security level to be supported.
   
   
2. Prevent the LM Hash from Being Stored. One major problem with simply removing the LM hashes being passed over the network is that the hashes are still created and stored in the SAM or Active Directory. Microsoft has a mechanism available for turning off the creation of the LM hashes altogether, but only in Windows 2000 and XP.
   On Windows 2000 systems, the following registry key controls this function:
   
   Hive: HKEY_LOCAL_MACHINE
   Key: System\CurentControlSet\Control\LSA\NoLMHash
   
   If this key is created on a Windows 2000 Domain Controller, the LanMan hashes will no longer be created and stored in Active Directory.
   On Windows XP, the same functionality can be implemented by setting the registry value:
   
   Hive: HKEY_LOCAL_MACHINE
   Key: System\CurrentControlSet\Control\Lsa
   Value: NoLMHash
   Type: REG_DWORD - Number
   Data: 1
   
   After making these modifications to the registry, the system must be restarted in order for the change to take effect. IMPORTANT NOTE: This only prevents new LM hashes from being generated. Existing LM hashes are removed individually the next time each user changes his or her password.

• How to Disable LM Authentication on Windows NT [Q147706] details the required changes in the registry for Windows 9x and Windows NT/2000.
• LMCompatibilityLevel and Its Effects [Q175641] explains interoperability issues with this parameter.
• How to Enable NTLMv2 Authentication for Windows 95/98/2000/NT [Q239869] explains how to use Windows 2000's Directory Services Client for Windows 95/98 to overcome the compatibility limitation for NTLMv2.
• New Registry Key to Remove LM Hashes from Active Directory and Security Account Manager

The most common password vulnerabilities are that (a) user accounts have weak or nonexistent passwords, (b) regardless of the strength of their password, users fail to protect it, (c) the operating system or additional software creates administrative accounts with weak or nonexistent passwords, and (d) password hashing algorithms are known and often hashes are stored such that they are visible by anyone. The best and most appropriate defense against these is a strong password policy which includes thorough instructions for good password habits and proactive checking of password integrity.

W7.2 Operating Systems Affected
Any operating system or application where users authenticate via a user ID and password.

W7.3 CVE Entries
CAN-1999-0506, CAN-1999-0504, CVE-2000-0222, CAN-1999-0505

W7.4 How to Determine if you are Vulnerable
Although there are observable symptoms of general password weakness, such as the existence of active accounts for users who have departed the organization or services which are not running, the only way to know for certain that each individual password is strong is to test all of them against the same password cracking tools used by attackers. PLEASE NOTE: Never run a password scanner, even on systems for which you have administrative access, without explicit and preferably written permission from your employer. Administrators with the most benevolent of intentions have been fired for running password cracking tools without authority to do so.

The best cracking tools available are:

• LC4 (l0phtcrack version 4)
• John the Ripper
• Symantec NetRecon

1. Assure that Passwords are Strong. Given enough hardware and enough time, any password can be cracked by brute force. But there are simpler and very successful ways to learn passwords without such expense. Password crackers employ what are known as dictionary-style attacks. Since encryption methods are known, cracking utilities simply compare the encrypted form of a password against the encrypted forms of dictionary words (in many languages), proper names, and permutations of both. Therefore a password whose root in any way resembles such a word is highly susceptible to a dictionary attack. Many organizations instruct users to generate passwords by including combinations of alphanumeric and special characters, and users more often than not adhere by taking a word ("password") and converting letters to numbers or special characters ("pa$$w0rd"). Such permutations cannot protect against a dictionary attack: "pa$$w0rd" is as likely to be cracked as "password."

   A good password, therefore cannot have a word or proper name as its root. A strong password policy should direct users to generate passwords from something more random, like a phrase, or the title of a book or song. By concatenating a longer string (taking the first letter of each word, or substituting a special character for a word, removing all the vowels, etc.), users can generate sufficiently long strings which combine alphanumeric and special characters in a way which dictionary attacks will have great difficulty cracking. And if the string is easy to remember, then the password should be as well.

   Once users are given the proper instructions for generating good passwords, procedures should be put in place to assure that these instructions are followed. The best way to do this is by validating the password whenever the user changes it by employing Passfilt.

   Cracking utilities should be run in a stand-alone mode as part of routine scanning. AGAIN PLEASE NOTE: Never run a password scanner, even on systems for which you have administrative access, without explicit and preferably written permission from your employer. Administrators with the most benevolent of intentions have been fired for running password cracking tools without authority to do so. Once you have acquired authority to run cracking utilities on your system, do so regularly on a protected machine. Users whose passwords are cracked should be notified confidentially and given instructions on how to choose a good password. Administrators and management should develop these procedures together, so that management can provide assistance when users do not respond to these notifications.

   Another way to protect against nonexistent or weak passwords is to use an alternative form of authentication such as password-generating tokens or biometrics. If you are having trouble with weak passwords, use an alternative means of authenticating users.

2. Protect Strong Passwords. Even if passwords themselves are strong, accounts can be compromised if users do not protect their passwords. Good policy should include instructions that a user should never tell his or her password to anyone else, should never write a password down where it could be read by others, and should properly secure any files in which a password is stored to automate authentication (passwords are easier to protect when this practice is only used when absolutely necessary). Password aging should be enforced so that any passwords which slip through these rules are only vulnerable for a short window of time, and old passwords should not be reused. Make sure that the users are given warning and chances to change their password before it expires. When faced with the message: "your password has expired and must be changed," users will tend to pick a bad password.

3. Tightly Control Accounts.
   • Any service-based or administrative accounts not in use should be disabled or removed. Any service-based or administrative accounts which are used should be given new and strong passwords.
   • Audit the accounts on your systems and create a master list. Do not forget to check passwords on systems like routers and Internet-connected digital printers, copiers and printer controllers.
   • Develop procedures for adding authorized accounts to the list, and for removing accounts when they are no longer in use.
   • Validate the list on a regular basis to make sure no new accounts have been added and that unused accounts have been removed.
   • Have rigid procedures for removing accounts when employees or contractors leave, or when the accounts are no longer required.
     
     
4. Maintain Strong Password Policy for the Enterprise. In addition to operating system or network service-level controls, there are comprehensive tools available to help manage good password policy. Symantec's Enterprise Security Manager (ESM) is a host-based monitoring tool that monitors any changes in policy, new account creation, and password strength. ESM will also attempt to crack passwords as it is performing a policy run on your network. ESM uses a client-manager environment: the agent is placed on the servers or workstations which in turn report to a centralized manager. Using a remote console, logs can be viewed and reports generated of the current status of the enterprise. ESM will monitor the audit logs and any change that has been made to the baseline of your network.

The vulnerabilities can be categorized into multiple classes including web page spoofing, ActiveX control vulnerabilities, Active scripting vulnerabilities, MIME-type and content-type misinterpretation and buffer overflows. The consequences may include disclosure of cookies, local files or data, execution of local programs, download and execution of arbitrary code or complete takeover of the vulnerable system.

W8.2 Operating Systems Affected
These vulnerabilities exist on Microsoft Windows systems running any version of Microsoft Internet Explorer. It is important to note that IE is installed with a wide variety of Microsoft software, and is therefore typically present on all Windows systems, even on servers where browsing is rarely necessary.

W8.3 CVE Entries
CAN-2002-0193, CAN-2002-0190, CVE-2002-0027, CVE-2002-0022, CVE-2001-0875,
CVE-2001-0727, CVE-2001-0339, CVE-2001-0154, CVE-2001-0002


W8.4 How to Determine if you are Vulnerable
If you are using Internet Explorer on your system and have not installed the latest cumulative security patch, you are most likely vulnerable. If Windows Updates are enabled on your network, you can verify whether IE is installed and which Internet Explorer patches are installed on your system by visiting http://windowsupdate.microsoft.com. If Windows Updating is not available for your system, you can use HFNetChk, the Network Security Hotfix Checker, or the Microsoft Baseline Security Analyzer (MBSA) to do the same.

You can also go to http://browsercheck.qualys.com to assess the impact of these vulnerabilities on your system.

W8.5 How to Protect Against It
Patches for these vulnerabilities are available for Internet Explorer versions 5.01, 5.5, 6.0. Earlier versions of Internet Explorer are also vulnerable, however patches may not be available for earlier versions. If your system is running an earlier version of IE, you should consider upgrading.

If you are running IE 5.01 or later, start by upgrading to the most recent service pack for Internet Explorer. The latest versions can be found at:

• Internet Explorer 6, service pack 1
• Internet Explorer 5.5, service pack 2
• Internet Explorer 5.01, service pack 2

After upgrading IE 5.5 or IE 5.01 to service pack 2, you should also add the latest cumulative security patch (Q323759), which repairs additional vulnerabilities. (This patch is already included in IE 6 service pack 1.) For more information about the vulnerabilities this patch repairs and appropriate changes to your configuration which can mitigate the risks, please see the related Security Bulletin and Knowledge Base article.

Each of these articles discusses a variant on a cross-site scripting vulnerability, some aspects of which may not yet be completely solved by the patch. Please see http://sec.greymagic.com/adv/gm010-ie/ for more information. If possible, it is generally good strategy to disable scripting wherever it is not necessary.

To maintain your system's protection, keep abreast of any new IE updates with Windows Update, HFNetChk, or the Microsoft Baseline Security Analyzer (MBSA). You can also get general IE update information from Microsoft's Internet Explorer Home.

W9.1 Description
Microsoft Windows 9x, Windows CE, Windows NT, Windows 2000, Windows ME and Windows XP employ a central hierarchical database, known as the Registry, to manage software, device configurations and user settings.
Improper permissions or security settings can permit remote registry access. Attackers can exploit this feature to compromise the system or form the basis for adjusting file association and permissions to enable malicious code.

W9.2 Operating Systems Affected
All versions of Microsoft Windows 9x, Windows CE, Windows NT, Windows 2000, Windows ME and Windows XP.

W9.3 CVE Entries
CAN-1999-0562, CVE-2000-0377, CVE-2000-0663, CVE-2002-0049, CAN-2001-0045,
CAN-2002-0642

W9.4 How to Determine if you are Vulnerable
NT Resource Kit (NTRK) available from Microsoft contains an executable file entitled "regdump.exe" that will passively test remote registry access permissions from a Windows NT host against other Windows NT/Windows 2000 or Windows XP hosts on the Internet or internal network.

In addition, a collection of command line shell scripts that will test for registry access permissions and a range of other related security concerns is available for download at http://www.afentis.com/top20.

W9.5 How to Protect Against It
To address this threat, access to the system registry must be restricted and the permissions set for critical registry keys reviewed. Users of Microsoft Windows NT 4.0 should also ensure that Service Pack 3 (SP3) has been installed before adjusting the registry. PLEASE NOTE: Editing the system Registry can have serious effects on the performance and operation of the computer and in extreme cases may cause irreparable damage and require reinstallation of the operating system.

• Restrict Network Access. To restrict network access to the registry, follow the steps listed below to create the following Registry key:

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg
  Description: REG_SZ
  Value: Registry Server
  

  Security permissions set on this key define the Users or Groups that are permitted remote Registry access. Default Windows installations define this key and set the Access Control List to provide full privileges to the system Administrator and Administrators Group (and Backup Operators in Windows 2000).

  Changes to the system registry will require a reboot to take effect. To create the registry key to restrict access to the registry:

  1. Start Registry Editor ("regedt32.exe" or "regedit.exe") and go to the following subkey:

     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control

  2. On the "Edit" menu, click "Add Key".

  3. Enter the following values:

     Key Name: SecurePipeServers
     Class: REG_SZ

  4. Go to the following subkey:

     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers

  5. On the "Edit" menu, click "Add Key".

  6. Enter the following values:

     Key Name: winreg
     Class: REG_SZ

  7. Go to the following subkey:

     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
     SecurePipeServers\winreg

  8. On the "Edit" menu, click "Add Value".

  9. Enter the following values:

     Value Name: Description
     Data Type: REG_SZ
     String: Registry Server

  10. Go to the following subkey:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
      SecurePipeServers\winreg

  11. Select "winreg." Click "Security" and then click "Permissions." Add Users or Groups to which you want to grant access.

  12. Exit Registry Editor and restart Microsoft Windows.

  13. If you at a later stage want to change the list of users that can access the registry,
      repeat steps 10-12.

• Limit Authorized Remote Access. Enforcing strict restrictions upon the registry can have adverse side effects upon dependent services, such as the Directory Replicator and the network printer Spooler service.

  It is therefore possible to add a degree of granularity to the permissions, by adding either the account name that the service is running under to the access list of the "winreg" key, or by configuring Windows to bypass the access restriction to certain keys by listing them in the Machine or Users value under the AllowedPaths key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\
winreg\AllowedPaths

Value: Machine
Value Type: REG_MULTI_SZ - Multi string
Default Data: System\CurrentControlSet\Control\ProductOptionsSystem\
              CurrentControlSet\Control\Print\PrintersSystem\CurrentControlSet\
              Services\EventlogSoftware\Microsoft\WindowsNT\CurrentVersionSystem\
              CurrentControlSet\Services\Replicator
Valid Range: (A valid path to a location in the registry)
Description: Allow machines access to listed locations in the registry provided
             that no explicit access restrictions exist for that location.

Value: Users
Value Type: REG_MULTI_SZ - Multi string
Default Data: (none)
Valid Range: (A valid path to a location in the registry)
Description: Allow users access to listed locations in the registry provided
             that no explicit access restrictions exist for that location.

Value: Machine
Value Type: REG_MULTI_SZ - Multi string
Default Data: System\CurrentControlSet\Control\ProductOptionsSystem\
              CurrentControlSet\Control\Print\PrintersSystem\CurrentControlSet\
              control\Server ApplicationSystm\CurrentControlSet\Services\Eventlog\
              Software\Microsoft\Windows NT\CurrentVersion
Value: Users (does not exist by default)

While administrators should always keep applications like browsers, mail clients and productivity suites patched and updated, patching these applications to eliminate their susceptibility to a particular worm is an incomplete (and no better than reactive) solution to the risks posed by scripting. Windows Scripting Host can be safely disabled on most systems in a proactive effort to prevent worms from spreading.

W10.2 Operating Systems Affected
Windows Scripting Host can be installed manually or with Internet Explorer 5 (or higher) on Windows 95 or NT. It is installed by default on Windows 98, ME, 2000 and XP machines.

W10.3 CVE Entries
CAN-2001-1325, CVE-2001-0149

W10.4 How to Determine if you are Vulnerable
If you are running Windows 95 or NT with IE 5 or higher, or are running Windows 98, ME, 2000 or XP, and have not disabled WSH, then you are likely vulnerable.

W10.5 How to Protect Against It

• Disable or remove Windows Scripting Host as outlined instruction sets provided by Symantec and Sophos.

• Always keep your Anti-Virus software and definitions up-to-date. Some Anti-Virus software includes options to block scripts.

U1.1 Description
Remote procedure calls (RPCs) allow programs on one computer to execute procedures on a second computer by passing data and retrieving the results. RPC is therefore widely used for many distributed network services such as remote administration, NFS file sharing, and NIS. However there are multiple flaws in RPC which are being actively exploited. In many cases, RPC services execute with root privileges, and as a consequence, systems that offer vulnerable RPC services can provide an attacker with unauthorized remote root access. There is compelling evidence that the majority of the distributed denial of service attacks launched during 1999 and early 2000 were executed by systems that had been victimized through these RPC vulnerabilities. The broadly successful attack on U.S. Military systems during the Solar Sunrise incident also exploited an RPC flaw found on hundreds of Department of Defense computer systems.

U1.2 Operating Systems Affected
Nearly all versions of Unix and Linux come with RPC services installed and often enabled.

U1.3 CVE Entries
CVE-1999-0166, CVE-1999-0167, CVE-1999-0168, CVE-1999-0170, CVE-1999-0211,
CVE-1999-0977, CVE-1999-0018, CVE-2000-0666, CVE-1999-0002, CVE-2001-0803,
CVE-1999-0493, CAN-2002-0573, CVE-2001-0717, CVE-1999-0003, CVE-1999-0019,
CVE-1999-0208, CVE-1999-0696, CVE-1999-0693, CVE-1999-0008, CVE-2001-0779,
CAN-2002-0033, CAN-2002-0391, CAN-2002-0677, CAN-2002-0679,

U1.4 How to Determine if you are Vulnerable

Use a vulnerability scanner or the 'rpcinfo' command to determine if you are running one of the most commonly exploited RPC services:

U1.5 How to Protect Against It

Use the following steps to protect your system against RPC attacks:

1. Turn off or remove any RPC service which is not absolutely necessary for the function of your network.

2. Install the latest patches for any services you cannot remove:

   For Solaris Software Patches:
   http://sunsolve.sun.com

   For IBM AIX Software Patches:
   http://www.ibm.com/support/us
   http://techsupport.services.ibm.com/server/fixes

   For SGI Software Patches:
   http://support.sgi.com

   For Compaq (Digital Unix) Software Patches:
   http://www.compaq.com/support

   For Linux Software Patches:
   http://www.redhat.com/apps/support/errata
   http://www.debian.org./security

3. Regularly search the vendor patch database for new patches and install them right away.

4. Block the RPC port (port 111) at the border router or firewall.

5. Block the RPC "loopback" ports, 32770-32789 (TCP and UDP).

6. Enable a non-executable stack on those operating systems that support this feature. While a non-executable stack will not protect against all buffer overflows, it can hinder the exploitation of some standard buffer overflow exploits publicly available on the Internet.

7. For NFS exported file systems, the following steps should be taken:
   1. Use host/IP based export lists.
   2. Setup exported file systems for read-only or no-suid wherever possible.
   3. Use 'nfsbug' to scan for vulnerabilities.

A summary document pointing to specific guidance about three principal RPC vulnerabilities - Tooltalk, Calendar Manager, and Statd - may be found at: http://www.cert.org/incident_notes/IN-99-04.html

Summary documents pointing to specific guidance about the above RPC vulnerabilities may be found at:

• Statd: http://www.cert.org/advisories/CA-2000-17.html
  http://www.cert.org/advisories/CA-1999-05.html
  http://www.cert.org/advisories/CA-1997-26.html

• Tooltalk: http://www.cert.org/advisories/CA-2002-26.html
  http://www.cert.org/advisories/CA-2002-20.html
  http://www.cert.org/advisories/CA-2001-27.html

• Calendar Manager: http://www.cert.org/advisories/CA-2002-25.html
  http://www.cert.org/advisories/CA-1999-08.html

• Cachefsd: http://www.cert.org/advisories/CA-2002-11.html

• Sadmind: http://www.cert.org/advisories/CA-1999-16.html
  http://www.cert.org/advisories/CA-2001-11.html

• Mountd: http://www.cert.org/advisories/CA-1998-12.html

• SnmpXdmid: http://www.cert.org/advisories/CA-2001-05.html

Exploits of core Apache or its modules in the recent past have been few, but they have been well-documented and quickly utilized in attacks. Among the most recent:

• Apache/mod_ssl Worm (CERT Advisory CA-2002-27)
• Apache Chunk Handling Exploit (CERT Advisory CA-2002-17)

Moreover, no web server can be considered secure until it is considered in the context of its interaction with web applications, especially CGI programs and databases. A hardened Apache configuration can still yield unauthorized access to data if CGI scripts are not themselves verified or database access controls not properly set. CGI scripts execute with the same permissions as the web server, so a malicious or just poorly written CGI script is just as dangerous as a software flaw in Apache. Unfortunately, these weaknesses on the back end of the web server remain problems today.

It is also imperative to harden the OS to truly prevent a web content from being modified or stolen. Although that is true for all running services, the fact that web services tend to have an external exposure lends itself to a false impression that they and the data they protect are somehow independent of the rest of the system. How failure to address this issue left one system vulnerable to attack is explained in http://www.wired.com/news/technology/0,1282, 43234,00.html.

U2.2 Operating Systems Affected
Nearly all Linux systems and many other Unix systems come with Apache installed and often by default enabled. All Unix systems are capable of running Apache. (Windows administrators should be aware that the version of Apache for Windows is likely subject to the same or similar vulnerabilities.)

U2.3 CVE Entries
CAN-2002-0392, CAN-2002-0061, CVE-1999-0021, CVE-1999-0172, CVE-1999-0266,
CVE-1999-0067, CVE-1999-0260, CVE-1999-0262, CVE-2000-0010, CVE-1999-0174,
CVE-1999-0066, CVE-1999-0146, CAN-2002-0513, CAN-2002-0682, CAN-2002-0257,
CVE-2000-0208, CVE-2000-0287, CVE-2000-0941, CAN-2000-0832, CVE-1999-0070,
CVE-2002-0082, CAN-2002-0656, CAN-2002-0655, CVE-2001-1141, CAN-2002-0657,
CAN-1999-0509, CVE-1999-0237, CVE-1999-0264

U2.4 How to Determine if you are Vulnerable
Check to see what the latest version and patch level is at the Apache web site: http://httpd.apache.org. If your version is not the most recent, then your server is likely vulnerable. This site also maintains a list of most recent vulnerabilities and documentation on how to determine if y