• Denial of service
• Exposure or compromise of sensitive files or data
• Execution of arbitrary commands
• Complete compromise of the server

• Disable WebDAV (unless your environment absolutely requires it for web content publishing).
• Unmap all unnecessary ISAPI extensions (including .htr, .idq, .ism, and .printer in particular).
• Eliminate sample applications.
• Forbid the web server from running system commands commonly used in a compromise (e.g., cmd.exe and tftp.exe).

• 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. Enable 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 2000 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 server and MSDE 2000.
   
   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:
   • Microsoft SQL/MSDE Server 7.0
   • Microsoft SQL Server 2000
   • 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:
   • Microsoft SQL/MSDE Server 7.0
   • Microsoft SQL Server 2000
   • MSDE Server Desktop Engine 2000 (MSDE 2000)
   
   
5. Enable SQL Server Authentication Logging.
   
   SQL Server Authentication Logging is 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

• User accounts have weak or nonexistent passwords.
• Regardless of the strength of their password, users fail to protect it.
• The operating system or additional software creates administrative accounts with weak or nonexistent passwords.
• 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.

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

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.

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

1. Assure that passwords are consistently 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 a known 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 (NT4).
   
   Windows 2000, XP, 2003 have powerful tools for enforcing password policy. To view your current password policy on most Windows systems, follow these steps (Start - Programs - Administrative Tools - Local Security Policy - select Account Policies - Password Policy). The Local Security Policy has following settings:
   
   
   • Password must meet complexity requirements. Determines whether passwords must meet complexity requirements. Complexity requirements are enforced when passwords are changed or created. If this policy is enabled, passwords must meet the following minimum requirements:
     1. Not contain all or part of the user's account name
     2. Be at least six characters in length
     3. Contain characters from three of the following four categories:
     4. English uppercase characters (A through Z)
     5. English lowercase characters (a through z)
     6. Base 10 digits (0 through 9)
     7. Nonalphanumeric characters (e.g., !, $, #, %)
   • Enforce password history (range: 0-24): Determines the number of unique new passwords that have to be associated with a user account before an old password can be reused. The value must be between 0 and 24 passwords. Setting this parameter to 0 passwords remembered enables password recycling; setting it to 24 passwords remembered requires 24 changes of password before initial password can be recycled. This policy enables administrators to enhance security by ensuring that old passwords are not reused continually. To maintain the effectiveness of the password history, do not allow passwords to be changed immediately when you configure the minimum password age.
   • Maximum password age (range: 0-999 days): Determines the period of time (in days) that a password can be used before the system requires the user to change it. You can set passwords to expire after a number of days between 1 and 999, or you can specify that passwords never expire by setting the number of days to 0.
   • Minimum password age (range: 0-999 days): Determines the period of time (in days) that a password must be used before the user can change it. You can set a value between 1 and 999 days, or you can allow changes immediately by setting the number of days to 0. The minimum password age must be less than the maximum password age. Configure the minimum password age to be more than 0 if you want Enforce password history to be effective. Without a minimum password age, users can cycle through passwords repeatedly until they get to an old favorite. The default setting does not follow this recommendation, so that an administrator can specify a password for a user and then require the user to change the administrator-defined password when the user logs on. If the password history is set to 0, the user does not have to choose a new password. For this reason, password history is set to 1 by default.
   • Minimum password length (range: 0-14 characters): Determines the least number of characters that a password for a user account may contain. You can set a value of between 1 and 14 characters, or you can establish that no password is required by setting the number of characters to 0. Minimum password length should conform to corporate security policy (otherwise it is recommended that it be set to 8 or more characters; National Security Agency (NSA) recommends 12 characters).
   • Store password using reversible encryption for all users in the domain: Determines whether Windows 2000, 2003 and XP Professional store passwords using reversible encryption. This policy provides support for applications using protocols that require knowledge of the user's password for authentication purposes. Storing passwords using reversible encryption is essentially the same as storing plaintext versions of the passwords. For this reason, this policy should never be enabled unless application requirements outweigh the need to protect password information.
   
   An approach that can be used to automatically generate and assign complex passwords to user accounts is as follows - run the following command (from Command line prompt of Windows NT4, 2000, XP, 2003):
   
   Net user username /random
   
   Execution of this command will assign random complex (but always 8-characters long) passwords to an account and will print this password on the console screen. This method is usually more appropriate for assigning passwords for service accounts, rather than for actual users.
   
   The best way to audit the quality of passwords is to run password cracking utilities 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.
   
   
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 never tell his or her password to anyone else, never write a password down where it could be read by others, and properly secure any files in which a password is stored to automate authentication (passwords are easier to protect when this practice is only used if 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 many comprehensive tools available to help manage good password policy. Many sample policies templates, policy development guidelines, password security fundamentals, and links to numerous security policy web sites (which include password policy information) can be found at the SANS Security Policy Project site.
   
   
5. 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)
   
   On Windows 2000, 2003, and XP the same functionality can be implemented by configuring the setting LAN Manager authentication level (Windows 2000) or Network security: LAN Manager authentication level (Windows XP, 2003) (Start - Programs - Administrative Tools - Local Security Policy - Local Policies - Security Options).
   
   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 or if you use tool Local Security Policy set LAN Manager authentication level to value: Send NTLMv2 Response only\Refuse LM). But the most secure option with regard to legacy systems is to migrate them to newer operating platforms, since the older operating systems do not allow this minimum security level to be supported.
   
   
6. 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, 2003 and XP. On Windows 2000 systems (SP2 or later), the following registry key controls this function:
   
   Hive: HKEY_LOCAL_MACHINE
   Key: System\CurrentControlSet\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 and 2003, the same functionality can be implemented by enabling setting Network security: Do not store LAN Manager hash value on next password change (Start - Programs - Administrative Tools - Local Security Policy - Local Policies - Security Options).
   
   After making these modifications 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.

   
   
7. Prevent password hashes and SAM database from being copied. Password cracking tools, mentioned in this section, obtain password hashes by:
   • Sniffing passwords from the network. Countermeasures: 1. Use of switched networks; 2. Detection and removal of network cards in promiscuous mode (they can be detected by most commercial security assessment tools, such as free tools like ethereal).
   • Copying SAM file (located in %SystemRoot%\System32\Config\ folder usually C:\Winnt\System32\Config\ - on Windows NT4 and 2000 or C:\Windows\System32\Config\ - on Windows XP and 2003). This file is normally locked by Windows OS and can be copied only when system booted to alternative OS. SAM file also can be obtained by restoring backup of SAM file or System State (Windows 2000, 2003, XP). SAM file also located on NT4 Repair Disk.
   
   Countermeasures: Limit and monitor physical access to computer systems (especially domain controllers), backup media and Repair Disk.
   
   The following Microsoft articles provide useful references:
   • How to Disable LM Authentication on Windows NT [Q147706] details the required changes in the registry for Windows 9x and Windows NT/2000.
   • MS03-034 : Flaw in NetBIOS Could Lead to Information Disclosure (824105)
   • 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

1. Select Internet Options under the Tools menu.
2. Select the Security tab and then click Custom Level for the Internet zone.
   
   Most of the flaws in IE are exploited through Active Scripting or ActiveX Controls.
3. Under Scripting, select Prompt for Allow paste operations via script to prevent content from being exposed from your clipboard.
   
   Note: Active Scripting should not be disabled since it is used by many websites.
   
   ActiveX Controls are not as popular but are potentially more dangerous as they allow greater access to the system.
4. Select Prompt for Download signed ActiveX Controls.
5. Select Disable for Download unsigned ActiveX Controls.
6. Also select Disable for Initialize and script ActiveX Controls not marked as safe.
   
   Java applets typically have more capabilities than scripts.
7. Under Microsoft VM, select High safety for Java permissions in order to properly sandbox the Java applet and prevent privileged access to your system.
8. Under Miscellaneous select Disable for Access to data sources across domains to avoid Cross-site scripting attacks.

NETBIOS -- Unprotected Windows Networking Shares
Microsoft Windows provides a host machine with the ability to share files or folders across a network with other hosts through Windows network shares. The underlying mechanism of this feature is the Server Message Block (SMB) protocol, or the Common Internet File System (CIFS). These protocols permit a host to manipulate remote files just as if they were local.
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 I-Worm.Klez.a-h (Klez Family) worm, Sircam virus (see CERT Advisory 2001-22) and Nimda worm (see CERT Advisory 2001-26) spread so rapidly in 2001 was by discovering unprotected network shares and placing copies of themselves 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.

Anonymous Logon
A null session is a session established without credentials (i.e. blank username and password). Null sessions can be used to display information about users, groups, shares and password policies. Microsoft Windows NT services running as the Local System account on the local computer communicate with other services over the network by establishing null sessions. Windows 2000 and later services running as the Local System account on the local computer use the local computer account to authenticate to other servers. Active Directory running in native mode does not accept null session queries. In mixed mode, Active Directory allows Pre-Windows 2000 compatible access, accepting null session queries which, in turn, inherit the null session vulnerabilities of Windows NT.

Remote Registry Access
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.

Remote Procedure Calls
Many versions of Microsoft operating systems (Windows NT 4.0, 2000, XP, and 2003) provide an inter-process communication mechanism that allows programs running on one host to execute code on remote hosts. Three vulnerabilities have been published that would allow an attacker to run arbitrary code on susceptible hosts with Local System privileges. One of these vulnerabilities was exploited by Blaster/MSblast/LovSAN and Nachi/Welchia worms. There are also other vulnerabilities that would allow attackers to mount Denial of Service attacks against RPC components.

How to determine if you are vulnerable to NETBIOS related issues.

A number of tools are available that can help you make the determination if there are NETBIOS related vulnerabilities on your systems.

NAT' (NetBIOS Auditing Tool) is available form Afentis Security. NAT explores the NETBIOS file-sharing services available on target systems and implements a stepwise approach to gather information before attempting to obtain file system-level access. NAT is available under the GNU General Public License: http://www.afentis.com/resources/win32/nat/.

Windows 95/98/Me users can use Legion v2.11, the latest version of the Legion File Share scanner by Rhino9, to scan for Windows networking shares.

Windows 2000 Administrators can use Security Fridays Share Password Checker (SPC) to scan their Windows 95/98/Me file sharing clients to see if they are vulnerable to the Share Level Password vulnerability which will reveal the share level passwords to an attacker.

For Windows NT (SP4), Windows 2000, Windows XP, and Windows 2003, the Microsoft Baseline Security Advisor will report hosts that are vulnerable to SMB exploits and may be used to fix the problem. The tests can be run locally or on remote hosts.

Windows NT, Windows 2000, Windows XP, and Windows 2003 users can simply type net share from the cmd prompt to see what resources are being shared. For more information about the net share command, type net share /?.

IMPORTANT Note: This article contains information about modifying shared resources. Before you modify any shared resource, make that you understand how to restore the resource if a problem occurs. It is recommended that you thoroughly test any modifications before implementation in a production environment. For information about shared resources, click the following article numbers to view the article in the Microsoft Knowledge Base:

125996 - Saving and Restoring Existing Windows Shares
Special shares

308419 - HOW TO Set, View, Change, or Remove Special Permissions for Files and Folders in Windows XP
307874 - HOW TO Disable Simplified Sharing and Password-Protect a Shared Folder in Windows XP
174273 - How to Copy Files and Maintain NTFS and Share Permissions


The default permissions on new shares:

Windows NT, Windows 2000, and Windows XP (Pre Service Pack 1)    

Everyone - Full Control

Windows XP SP1
   

Everyone - Read

Windows XP by default has one shared directory called "SharedDocs." The physical location of this share is:

"C:\Documents and Settings\All Users\Documents"
   

Everyone Full Control

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

Automated Scanning tools to detect share vulnerabilities:

• Nessus--a free, powerful, up-to-date and easy to use remote security scanner
• Winfingerprint by vacuum --Win32 Host/Network Enumeration Scanner

How to determine if you are vulnerable to Anonymous Logon related issues.
Try to establish a null session to your computer by issuing the following command from the cmd prompt (Start --> Run --> type cmd):

C:\>net use \\ipaddress\ipc$ "" /user:""

The preceding syntax connects to the hidden interprocess communications "share (IPC$) at ipaddress as the built-in anonymous user (/user:"") with a null () password.

If you receive System error 5 has occurred. Access is denied., then your system is not vulnerable.

If you receive The command completed successfully., then that means that your system is vulnerable.

The list of tools above Nessus, and Winfingerprint - can also be used to detect null session vulnerabilities.

How to determine if you are vulnerable to Remote Registry Access related issues.
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 are available for download at http://www.afentis.com/top20.

How to determine if you are vulnerable to Remote Procedure Call related issues.
Microsoft has made a hotfix and patch-checking tool freely available for download; this is probably the best way to determine if Windows hosts are susceptible to any of these vulnerabilities. It is called the Microsoft Baseline Security Analyzer (MBSA) and is available from http://www.microsoft.com/technet/security/tools/Tools/MBSAhome.asp. It will scan for configuration errors and missing security updates; you should check that the relevant hotfixes have been applied. There is also a standalone scanning tool that will check for missing security patches for CAN-2003-0352, CAN-2003-0528, CAN-2003-0605 and CAN-2003-0715 only; it is available from http://support.microsoft.com/?kbid=827363. However, you are encouraged to use the MBSA, which has a wider coverage. Home or small-scale users with only a few computers to take care of will probably find it easier to visit the Windows Update site at http://windowsupdate.microsoft.com/ and check individual machines for outdated software.

How to protect against NETBIOS related attacks.
Several actions can be taken to mitigate the risk of exploitation of a vulnerability through 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.
• Windows 95/98/Me clients that are a part of a Windows NT domain are recommended to be setup with user-level file share access controls.
• 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. Shares should be 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.

How to protect against Anonymous Logon problems on your systems.
IMPORTANT Note: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. It is recommended that you thoroughly test any modifications before implementation in a production environment. For information about how to back up, restore, and edit the registry, click the following article numbers to view the article in the Microsoft Knowledge Base:

256986 - Description of the Microsoft Windows Registry
323170 - HOW TO Backup, Edit, and Restore the Registry in Windows NT 4.0
322755 - HOW TO Backup, Edit, and Restore the Registry in Windows 2000
322756 - HOW TO Backup, Edit, and Restore the Registry in Windows XP Windows Server 2003

Windows NT Domain controllers require null sessions to communicate. Therefore, if you are working in a Windows NT domain or Windows 2000/2003 Active Directory running in mixed mode, which allows Pre-Windows 2000 compatible access, you can minimize the information that attackers can obtain, but you cannot stop all leakage by setting the RestrictAnonymous registry value to 1. For example; GetAcct from Security Friday sidesteps RestrictAnonymous=1 and will enumerate the SID and UserID. The ideal solution if you have a native Windows 2000/2003 Active Directory is to set the RestrictAnonymous registry value to 2.

To restrict information available via null sessions, click the following article numbers to view the articles in the Microsoft Knowledge Base:

143474 - Restricting Information Available to Anonymous Logon Users in Windows NT
246261 - How to Use the RestrictAnonymous Registry Value in Windows 2000


To troubleshoot the RestrictAnonymous registry value, click the following article number to view the article in the Microsoft Knowledge Base:

296405 - The RestrictAnonymous Registry Value May Break the Trust to a Windows 2000 Domain

How to protect against Remote Registry Access on your systems.
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.

Important Note: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. It is recommended that you thoroughly test the modification of these settings before implementation in a production environment. For information about how to back up, restore, and edit the registry, click the following article numbers to view the article in the Microsoft Knowledge Base:

256986 - Description of the Microsoft Windows Registry
323170 - HOW TO Backup, Edit, and Restore the Registry in Windows NT 4.0
322755 - HOW TO Backup, Edit, and Restore the Registry in Windows 2000
322756 - HOW TO Backup, Edit, and Restore the Registry in Windows XP Windows Server 2003

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 at a later stage you 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.

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

It is common for there to be a lag between the time a vulnerability becomes public and the time a patch is made available. Or for other policy reasons, the vulnerability must be allowed. To mitigate the risk an organization can limit access through firewalls or routers. An additional measure would be to write new rules for an IDS (Intrusion Detection System) like Snort which would alert or trigger a response by the organization. Examples of documented rules for Snort are located here.

How to protect against Remote Procedure Call-related issues on your systems.
The best way by far is to apply the relevant patches as identified by the MBSA or Windows Update: see "How to determine if you are vulnerable to Remote Procedure Call related issues" above. Failing that there are a number of ways to disable or restrict some Remote Procedure Call functionality, and some can be found in the excellent synopsis at http://www.ntbugtraq.com/dcomrpc.asp. BE WARNED: disabling or restricting Remote Procedure Call functionality may break Windows services that you rely on, so you should always test any modifications in a non-production environment first.

If you cannot patch your systems, you should certainly block ports associated with Windows remote procedure calls (TCP ports 135, 139, 445 and 593; UDP ports 135, 137, 138 and 445) at your network perimeters. Of course, it is always best practice to block *all* unnecessary services at you network perimeter by default.

For more information:

Microsoft Knowledge Base Article Q153183. How to Restrict Access to NT Registry from a Remote Computer.

Another source is Microsofts HotFix & Security Bulletin Service.

Welcome to the MSDN Library (Search for Securing Registry)

Microsoft Knowledge Base Article 310426 : HOW TO: Use the Windows XP and Windows Server 2003 Registry Editor

Network access: Remotely accessible registry paths and subpaths

Windows Server 2003 Security Guide

• http://support.microsoft.com/support/kb/articles/q184/3/75.asp
• http://www.microsoft.com/technet/security/bulletin/ms98-004.asp
• http://www.microsoft.com/technet/security/bulletin/ms99-025.asp
• http://www.microsoft.com/security/security_bulletins/ms03-033.asp
• http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/
  bulletin/MS03-033.asp
• http://support.microsoft.com/default.aspx?scid=kb;en-us;823718

Important Note: Some applications and administrative functions require Windows Scripting Host (WSH) and will cease to function if it is disabled or removed.

Windows Scripting Host is an optional part of the Windows operating system and may be safely removed or disabled from computers in many cases. To protect against attacks and security concerns directly related to WSH it is recommended that it is always disabled unless expressly required (see section Change default behavior of Windows Scripting Host).

1. Download Noscript.exe to a folder on the hard disk.
2. Double-click the Noscript.exe icon. The Norton Script Disabler/Enabler appears.
        - If the WSH is currently enabled on the system, you will be prompted whether you want to disable it. To do so, click Disable, and then click OK.      - If the WSH is currently disabled on the system, you will be prompted whether you want to enable it. To do so, click Enable, and then click OK.