The Twenty Most Critical Internet Security Vulnerabilities (Updated) ~ The Experts Consensus
 

Version 4.0 October 8, 2003 Copyright (C) 2001-2003, SANS Institute
Questions / comments may be directed to top20@sans.org.
 

 

-----Jump To Index of Top 20 Threats -----

download vulnerabilities_top20.zip (91 Kb)


Introduction
The SANS Top 20 Internet Security Vulnerabilities

The vast majority of worms and other successful cyber attacks are made possible by vulnerabilities in a small number of common operating system services. Attackers are opportunistic. They take the easiest and most convenient route and exploit the best-known flaws with the most effective and widely available attack tools. They count on organizations not fixing the problems, and they often attack indiscriminately, scanning the Internet for any vulnerable systems. The easy and destructive spread of worms, such as Blaster, Slammer, and Code Red, can be traced directly to exploitation of unpatched vulnerabilities.

Three years ago, the SANS Institute and the National Infrastructure Protection Center (NIPC) at the FBI released a document summarizing the Ten Most Critical Internet Security Vulnerabilities. Thousands of organizations used that list, and the expanded Top Twenty lists that followed one and two years later, to prioritize their efforts so they could close the most dangerous holes first. The vulnerable services that led to the examples above Blaster, Slammer, and Code Red, as well as NIMDA worms - are on that list.

This updated SANS Top Twenty is actually two Top Ten lists: the ten most commonly exploited vulnerable services in Windows and the ten most commonly exploited vulnerable services in UNIX and Linux. Although there are thousands of security incidents each year affecting these operating systems, the overwhelming majority of successful attacks target one or more of these twenty vulnerable services.

The Top Twenty is a consensus list of vulnerabilities that require immediate remediation. It is the result of a process that brought together dozens of leading security experts. They come from the most security-conscious federal agencies in the US, UK and Singapore; the leading security software vendors and consulting firms; the top university-based security programs; many other user organizations; and the SANS Institute. A list of participants may be found at the end of this document.

The SANS Top Twenty is a living document. It includes step-by-step instructions and pointers to additional information useful for correcting the security flaws. We will update the list and the instructions as more critical threats and more current or convenient methods are identified, and we welcome your input along the way. This is a community consensus document -- your experience in fighting attackers and in eliminating the vulnerabilities can help others who come after you. Please send suggestions via e-mail to top20@sans.org.


Notes for Readers
CVE Numbers
You'll find references to CVE (Common Vulnerabilities and Exposures) numbers accompanying each vulnerability. You may also see CAN numbers. CAN numbers are candidates for CVE entries that have not yet been fully verified. For more data on the award-winning CVE project, see http://cve.mitre.org.

The CVE and CAN numbers reflect the top priority vulnerabilities that should be checked for each item. Each CVE vulnerability reference is linked to the associated vulnerability entry in the National Institute of Standards and Technology's ICAT vulnerability indexing service (http://icat.nist.gov). ICAT provides a short description of each vulnerability, a list of the characteristics of each vulnerability (e.g. associated attack range and damage potential), a list of the vulnerable software names and version numbers, and links to vulnerability advisory and patch information.

Ports to Block at the Firewall
 
---- Jump to index of Ports to Block at the Firewall or Gateway ----


At the end of the document, you'll find an extra section offering a list of commonly probed and attacked ports. By blocking traffic to these ports at the firewall or other network perimeter protection devices, you add an extra layer of defense that helps protect you from configuration mistakes and oversights. Note, however, that using a firewall or router to block network traffic directed to a port does not protect the port from disgruntled co-workers who are already inside your perimeter or from hackers who may have penetrated your perimeter using other means. It is also a far more secure practice implementing a default deny or block that which is not explicitly allowed stance in firewall and router configurations than individually blocking specific ports.

back to top ^


Top Vulnerabilities to Windows Systems
 

  • W1 Internet Information Services (IIS)
  • W2 Microsoft SQL Server (MSSQL)
  • W3 Windows Authentication
  • W4 Internet Explorer (IE)
  • W5 Windows Remote Access Services
  • W6 Microsoft Data Access Components (MDAC)
  • W7 Windows Scripting Host (WSH)
  • W8 Microsoft Outlook and Outlook Express
  • W9 Windows Peer to Peer File Sharing (P2P)
  • W10 Simple Network Management Protocol (SNMP)
    Top Vulnerabilities to UNIX Systems
     
  • U1 BIND Domain Name System
  • U2 Remote Procedure Calls (RPC)
  • U3 Apache Web Server
  • U4 General UNIX Authentication Accounts with No Passwords or Weak Passwords
  • U5 Clear Text Services
  • U6 Sendmail
  • U7 Simple Network Management Protocol (SNMP)
  • U8 Secure Shell (SSH)
  • U9 Misconfiguration of Enterprise Services NIS/NFS
  • U10 Open Secure Sockets Layer (SSL)

     


     

  • Top Vulnerabilities to Windows Systems (W)

    W1 Internet Information Services (IIS)

    W1.1 Description
    Default installations of Internet Information Services (IIS) have proven vulnerable to a number of serious attacks over time. The impact of these vulnerabilities can include:
    • Denial of service
    • Exposure or compromise of sensitive files or data
    • Execution of arbitrary commands
    • Complete compromise of the server

    IIS uses a programming hook known as ISAPI to associate files having certain extensions with DLLs (known as ISAPI filters). Preprocessors such as ColdFusion and PHP use ISAPI, and IIS includes many ISAPI filters to handle functions such as Active Server Pages (ASP), server-side includes, and web-based printer sharing. Many ISAPI filters installed with IIS by default are not required in most installations, and many of those filters are exploitable. Examples of malicious programs which use this type of propagation mechanism include the well-known Code Red and Code Red 2 worms.

    Like many web servers, IIS includes sample applications that were designed to demonstrate the functionality of the web server. These applications were not designed to operate securely in a production environment. Some IIS sample applications have allowed remote viewing or overwriting of arbitrary files as well as remote access to other sensitive server information, including the administrator's password.

    An IIS installation that is not maintained is also subject to vulnerabilities discovered since the software release date. Examples include the WebDAV ntdll.dll vulnerabilities in IIS 5.0, which enabled denial of service attacks and could allow any web site visitor to create and execute scripts on the server, and the Unicode exploit vulnerability, which allowed any web site visitor to execute arbitrary commands on the web server merely by requesting carefully crafted URLs.

    Third-party web add-ons such as ColdFusion and php can introduce further vulnerabilities in an IIS installation, either through misconfiguration or through vulnerabilities inherent in the product.

    Additionally: More information on the latest WebDAV specific vulnerabilities (CAN-2003-0109 CA-2003-09) can be found at the following sites.

    http://www.cert.org/advisories/CA-2003-09.html
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0109
    http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q241520

    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

    At the time of this writing, no vulnerabilities have been reported in Windows 2003 running IIS 6; however, it is reasonable to anticipate that vulnerabilities will be found and reported as production environments adopt the new platform in significant numbers.

    W1.3 CVE/CAN Entries
    CVE-1999-0264, CVE-1999-0278, CVE-1999-0874, CVE-1999-0237, CVE-1999-0191,
    CVE-2000-0770, CVE-2000-0778, CVE-2000-0884, CVE-2000-0886, CVE-2000-0226,
    CVE-2001-0151, CVE-2001-0241, CVE-2001-0333, CVE-2001-0500, CVE-2001-0507

    CAN-1999-0509, CAN-1999-0736, CAN-1999-1376, CAN-2002-0071, CAN-2002-0073,
    CAN-2002-0079, CAN-2002-0147, CAN-2002-0149, CAN-2002-0150, CAN-2002-0364,
    CAN-2002-0419, CAN-2002-0421, CAN-2002-0422, CAN-2002-0869, CAN-2002-1180,
    CAN-2002-1181, CAN-2002-1182, CAN-2002-1309, CAN-2002-1310, CAN-2003-0109,
    CAN-2003-0223, CAN-2003-0224, CAN-2003-0225, CAN-2003-0226, CAN-2003-0227,
    CAN-2003-0349

    W1.4 How to Determine if You Are Vulnerable
    Default or unpatched IIS installations should be presumed vulnerable.

    System and network administrators in charge of IIS deployments should familiarize themselves with Microsofts extensive collection of tools and security documents relating to the proper administration of Internet Information Server.

    The main repository for IIS related security documentation is the Internet Information Sever (IIS) Security Center.

    It is suggested that you download and run the Microsoft Baseline Security Analyzer which contains detection procedures specifically tailored to IIS.

    Administrators should compare their systems against the many checklists, hardening guides, and vulnerability remediation documentation that Microsoft offers to get a sense of vulnerability status.

    W1.5 How to Protect Against It
    Patch the system and keep it current.

    Patching a server on installation is necessary but not sufficient. As new IIS weaknesses are uncovered, you will need to patch accordingly. Windows Update and AutoUpdate are options for single-server installations. 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.

    If you use third-party add-ons such as ColdFusion, PerlIIS, or PHP, remember to check the third-party vendors' web sites for patches and configuration tips as well. For obvious reasons, Microsoft does not include third-party patches in Windows Update and related update services.

    Use IIS Lockdown Wizard to harden the installation
    Microsoft has released a simple tool to aid in securing IIS installations known as the IIS Lockdown Wizard. The current version can be downloaded from Microsoft at http://www.microsoft.com/technet/security/tools/locktool.asp.

    Running the IIS Lockdown Wizard in "custom" or "expert" mode will allow you to make the following recommended changes to an IIS installation:

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

    Use URLScan to 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.

     

    back to top ^


     

    W2 Microsoft SQL Server (MSSQL)

    W2.1 Description
    The Microsoft SQL Server (MSSQL) contains several serious vulnerabilities that allow remote attackers to obtain sensitive information, alter database content, compromise SQL servers, and, in some configurations, compromise server hosts.

    MSSQL vulnerabilities are well-publicized and actively under attack. Two recent MSSQL worms in May 2002 and January 2003 exploited several known MSSQL flaws. Hosts compromised by these worms generate a damaging level of network traffic when they scan for other vulnerable hosts. Additional information on these worms can be found at

    SQLSnake/Spida Worm (May 2002)

    SQL-Slammer/SQL-Hell/Sapphire Worm (January 2003)

    Port 1433 and 1434 (MSSQL server and monitor default ports) have also been regularly registered as two of the most frequently scanned ports by the Internet Storm Center.

    SQLSnake's exploit routine depends on the default administrative account, or "sa" account, having a null password. It is essential to the proper configuration and defense of any system to ensure that all system accounts are password protected, or completely disabled if not in use. You can find more information regarding setting and managing sa account passwords in the Microsoft Developer Network documentation under Changing the SQL Server Administrator Login, as well as Verify and Change the System Administrator Password by Using MSDE. The sa account should have a complex, hard-to-guess password even if it is not used to run your SQL/MSDE implementation.

    SQL Slammer's exploit routine is based upon a buffer overflow in the SQL Server Resolution Service. This buffer overflow is brought to bear and host security is thus compromised when the worm sends crafted attack packets to UDP port 1434 of vulnerable target systems. If a machine runs SQL services that are subject to this stack buffer overflow and it receives packets of this nature, it will usually result in total server and system security compromise. The most effective means of defense against this worm is diligent patching, proactive system configuration practices, and ingress/egress UDP port 1434 filtering at network gateways.

    The Microsoft Server 2000 Desktop Engine (MSDE 2000) can be thought of as "SQL Server Lite". Many system owners don't even realize that their systems are running MSDE and that they have a version of SQL Server installed. MSDE 2000 is installed as a part of the following Microsoft products:

    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

    In addition there are many other software packages that make use of the MSDE 2000 software. For an up-to-date list please check http://www.SQLsecurity.com/forum/applicationslistgridall.aspx. Since this software uses MSDE as its core database engine, it has the same vulnerabilities as SQL/MSDE Server. MSDE 2000 can be configured to listen for incoming client connections in a multitude of different ways. It can be configured such that clients can use named pipes over a NetBIOS session (TCP port 139/445) or sockets with clients connecting to TCP port 1433, or both. Whichever method is used, SQL Server and MSDE will always listen on UDP port 1434. This port is designated as a monitor port. Clients will send a message to this port to dynamically discover how the client should connect to the server.

    The MSDE 2000 engine returns information about itself whenever presented with the single byte packet 0x02 on UDP port 1434. Other single byte packets cause a buffer overflow without ever having to authenticate to the server itself. 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.

    Since SQL Slammer exploits a buffer overflow on the target system, following best practices of timely patching and conscientious system configuration helps to mitigate this threat. By downloading and using defensive tools such as theMicrosoft SQL Critical Update Kit, one can check local systems for vulnerability to this exploit, scan entire domains or networks for the existence of vulnerable systems, and automatically update affected files with SQL Critical Update.

    Please see the report and analysis on incidents.org for more details on the SQL/MSDE Slammer worm. This particular attack affected the Internet Backbone for a few hours on the morning of January 25, 2003.

    W2.2 Operating Systems Affected
    Any Microsoft Windows system with Microsoft SQL/MSDE Server 7.0, Microsoft SQL/MSDE Server 2000 or Microsoft SQL/MSDE Server Desktop Engine 2000 installed, as well as any system which uses the MSDE engine separately.

    W2.3 CVE/CAN Entries
    CVE-1999-0999, CVE-2000-0202, CVE-2000-0402, CVE-2000-0485, CVE-2000-0603,
    CVE-2001-0344, CVE-2001-0879

    CAN-2000-0199, CAN-2000-1081, CAN-2000-1082, CAN-2000-1083, CAN-2000-1084,
    CAN-2000-1085, CAN-2000-1086, CAN-2000-1087, CAN-2000-1088, CAN-2000-1209,
    CAN-2001-0509, CAN-2001-0542, CAN-2002-0056, CAN-2002-0154, CAN-2002-0186,
    CAN-2002-0187, CAN-2002-0224, CAN-2002-0624, CAN-2002-0641, CAN-2002-0642,
    CAN-2002-0643, CAN-2002-0644, CAN-2002-0645, CAN-2002-0649, CAN-2002-0650,
    CAN-2002-0695, CAN-2002-0721, CAN-2002-0729, CAN-2002-0859, CAN-2002-0982,
    CAN-2002-1123, CAN-2002-1137, CAN-2002-1138, CAN-2002-1145, CAN-2003-0118

    W2.4 How to Determine if you are Vulnerable
    Microsoft has published a set of security tools at http://www.microsoft.com/sql/downloads/securitytools.asp. The toolkit named the SQL Critical Update Kit contains valuable tools such as SQL Scan, SQL Check, and SQL Critical Update.

    Chip Andrews of sqlsecurity.com relgased a tool called SQLPingv2.2. This tool sends a single byte UDP packet (byte value of 0x02) to port 1434 of either a single host or an entire subnet. SQL Servers listening on UDP 1434 will respond by divulging system details such as version number, instances, etc. SQLPingv2.2 is considered a scanning and discovery tool much like Microsoft's SQL Scan, and will not further compromise your system and network security. Additional SQL security tools can be found at Chip Andrew's SQL/MSDE Security Web site.

    W2.5 How to Protect Against It
    Summary:

    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.

    Detail:

    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:


       

    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:


       

    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.

    Additional information on securing Microsoft SQL/MSDE Server can be found at

    back to top ^


     

    W3 Windows Authentication

    W3.1 Description
    Passwords, passphrases and security codes are used in virtually every interaction between users and information systems. Most forms of user authentication, as well as file and data protection, rely on user-supplied passwords. Since properly authenticated access is often not logged, or even if logged not likely to arouse suspicion, a compromised password is an opportunity to explore a system from the inside virtually undetected. An attacker would have complete access to any resources available to that user, and would be significantly closer to being able to access other accounts, nearby machines, and perhaps even administrative privileges. Despite this threat, accounts with bad or empty passwords remain extremely common, and organizations with good password policy are far too rare.

    The most common password vulnerabilities are:
    • 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.

    Microsoft Windows does not store or transmit passwords in clear text - it uses a hash of password for authentication. A Hash is a fixed-size result obtained by applying a mathematical function (the hashing algorithm) to an arbitrary amount of data (also known as the message digest). (MSDN Library) There are three Windows authentication algorithms: LM (least secure, most compatible); NTLM and NTLMv2 (most secure and least compatible). Although most current Windows environments have no need for LAN Manager (LM) support, Microsoft Windows locally stores legacy LM password hashes (also known as LANMAN hashes) by default on Windows NT, 2000 and XP systems (but not in Windows 2003). 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.

    http://www.msdn.miscrosoft.com/library/default.asp?url=/library/en-us/security/
    Security/h_gly.asp


    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.

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

    W3.3 CVE/CAN Entries
    CVE-2000-0222

    CAN-1999-0504, CAN-1999-0505, CAN-1999-0506

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


    A few of the best cracking tools available are: LC4 (l0phtcrack version 4) and John the Ripper

    Regarding the issue of a locally stored LAN Manager hash:

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

    W3.5 How to Protect Against It
    The best and most appropriate defense against password weaknesses is a strong policy which includes thorough instructions to engender good password habits and proactive checking of password integrity.

    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 PromiScan or 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:

    back to top ^


     

    W4 Internet Explorer (IE)

    W4.1 Description
    Microsoft Internet Explorer (IE) is the default web browser installed on Microsoft Windows platforms. All existing versions of Internet Explorer have critical vulnerabilities if they are not kept up-to-date with current patches. A malicious web administrator can design web pages to exploit these vulnerabilities in the context of a user's Internet Explorer while browsing these web pages.

    The vulnerabilities can be categorized into multiple classes including web page or Windows interface 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.

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

    W4.3 CVE/CAN Entries
    CVE-2001-0002, CVE-2001-0154, CVE-2001-0339, CVE-2001-0727, CVE-2001-0875,
    CVE-2002-0022, CVE-2002-0027, CVE-2003-0344

    CAN-2002-0190, CAN-2002-0193, CAN-2002-1258, CAN-2003-0111, CAN-2003-0113,
    CAN-2003-0114, CAN-2003-0233, CAN-2003-0309, CAN-2003-1328

    W4.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 Update is enabled on your machinery, 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 may also find online Internet Explorer analysis tools, such as the Qualys Browser Check, to be very valuable in assessing the security state of IE on your systems.

    W4.5 How to Protect Against It
    Patches for these vulnerabilities are available for Internet Explorer version 6.0. Earlier versions of Internet Explorer are also vulnerable; however patches may not be available for earlier versions. If you are using IE 5.5 or earlier, upgrading to IE 6.0 is strongly recommended as service packs for earlier versions of Internet Explorer are no longer available. If you are using IE 6.0, start by upgrading to the most recent service pack for Internet Explorer which can be found at this Internet Explorer 6 SP1 link.

    You should also add the latest cumulative security patch (828750) which repairs additional vulnerabilities. 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.

    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.

    W4.6 How to secure Internet Explorer
    To configure the Security settings for Internet Explorer:
    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.

    Please also ensure that no un-trusted sites are in the Trusted sites or Local intranet zones as these zones have weaker security settings than the other zones.

     

    back to top ^


     

    W5 Windows Remote Access Services

    W5.1 Description
    The family of Windows Operating Platforms support a variety of different networking methods and technologies. There is native support for most industry standard networking protocols and built-in functionality for many Microsoft specific networking methods and techniques. Among these MS specific network technologies are notoriously insecure or misconfigured items such as NETBIOS Network Shares, Anonymous Logon NULL sessions, remote registry access, and remote procedure calls. These items make up a large share of the more common network level exploits on Windows and are outlined in the following text.

     

    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.


    W5.2 Operating Systems Affected
    Windows 95, Windows 98, Windows NT Workstation and Server, Windows Me, Windows 2000 Workstation and Server, Windows XP Home and Professional, and Windows 2003 are all vulnerable.

    W5.3 CVE/CAN Entries

    NETBIOS
    CVE-2000-0979

    CAN-1999-0518, CAN-1999-0519, CAN-1999-0621, CAN-2000-1079

    Anonymous Logon
    CVE-2000-1200

    Remote Registry Access
    CVE-2000-0377, CVE-2002-0049

    CAN-1999-0562, CAN-2001-0045, CAN-2001-0046, CAN-2001-0047, CAN-2002-0642,
    CAN-2002-0649, CAN-2002-1117

    Remote Procedure Calls
    CAN-2002-1561, CAN-2003-0003, CAN-2003-0352, CAN-2003-0528, CAN-2003-0605,
    CAN-2003-0715

    W5.4 How to Determine if you are Vulnerable

    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.


  • W5.5 How to Protect Against It

     

    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


     

    back to top ^


     

    W6 Microsoft Data Access Components (MDAC)

    W6.1 Description
    Microsoft Data Access Components (MDAC) are a series of database technologies which are present in many recent versions of Windows. There are a number of different instances where an attacker can exploit vulnerabilities in MDAC to run malicious commands and code. There are both older RDS related issues outlined below as well as newer problems where an attacker masquerading as a SQL server can cause a buffer overflow and potential complete system compromise with a carefully crafted UDP packet.

    The Remote Data Services (RDS) component in older versions of Microsoft Data Access Components (MDAC) has a program flaw which allows remote users to run commands locally with administrative privilege. Combined with a flaw in Microsoft Jet Database Engine 3.5 (part of MS Access), this exploit may also provide anonymous external access to internal databases. These flaws are well-documented and solutions have been available for more than three years, but outdated or misconfigured systems remain exposed and subject to attack.

    More recent vulnerabilities that affect many versions of Windows have surfaced as well, such as the buffer overflow in MDAC outlined in Microsoft Security Bulletin MS03-033 and CAN-2003-0353 that affects most versions of MS Windows is use today. The MDAC implementation in Windows 2003 does not appear to be vulnerable to this exploit.

    W6.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. Systems Running Windows 2000 and XP, as well as systems with Office 2000 SR1 or greater installed. SQL Server 7 SP2 and later, and SQL Server 2000 also include vulnerable MDAC technology.

    Most versions of Windows should be considered vulnerable.

    W6.3 CVE/CAN Entries
    CVE-1999-1011, CVE-2002-0700

    CAN-2002-1142, CAN-2003-0353

    W6.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). If you meet this criteria, then an upgrade and patching regimen would be the wisest direction to go in, since there have proven to be multiple other vulnerabilities in these outdated software packages.

    If you are running any of the previously mentioned software or using any of the operating systems oultined above, then you are most likely vulnerable to the latest MDAC exploits. Detailed information on identifying and eliminating the most recent MDAC vulnerabilities can be found in the detailed overview of Microsoft Security Bulletin MS03-033.

    One of the easiest ways to determine if you have this vulnerability to MDAC issues is to visit the Windows Update site, and check your machine for outdated software. The Windows Update tool will identify outdated MDAC versions and give you the ability to upgrade.

    W6.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/txt/rfp9907.txt.

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

    Alternatively, you can prevent this problem by upgrading to MDAC components version 2.8 (although this may introduce compatibility issues). The most recent MDAC versions and additional stand alone data access downloads are available at http://msdn.microsoft.com/library/default.asp?url=/downloads/list/dataaccess.asp.

    Using Windows Update (http://windowsupdate.microsoft.com) to identify this problem and upgrade your systems or manually updating your MDAC implementation are the suggested remedies to this vulnerability.

     

    back to top ^


     

    W7 Windows Scripting Host (WSH)

    W7.1 Description
    Windows Scripting Host (WSH) is a Microsoft technology that serves to extend the functionality of Windows, supporting both JavaScript and Visual Basic Script. First introduced into the Windows platform by Internet Explorer 5, it became a standard feature in the Windows operating systems starting with Windows 98.

    The Windows Scripting Host enables the automation of Windows tasks by providing access to the Windows shell, file system, registry, and more through the use of relatively simple scripting code. Scripts can be run directly from the desktop by clicking on a script file, or from within a program - such as an email client.

    It is this auto-execution feature of WSH that was exploited in the spring of 2000 by "The Love Bug" (also known as "ILOVEYOU") Visual Basic script (VBScript) worm, causing millions of dollars in damages. This worm, and others which have since followed it, took advantage of Windows Scripting Host (WSH) which permits any text file with extensions .vbs,.vbe, .js, .jse, and .wsf to be executed as a Visual Basic Script/JScript with the application or system level privileges.

    While administrators should endeavor to keep all applications and operating systems suitably up-to-date with the latest patches and security roll-ups, a more direct approach should be taken to address the threats posed by WSH - as detailed in section 'W7.5 How to Protect Against It'.

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

    You can find the most recent version on Microsoft's MSDN site here:
    Download Windows Script (includes Windows Scripting Host)

    W7.3 CVE/CAN Entries
    CVE-2001-0149

    CAN-2001-1325

    W7.4 How to Determine if you are Vulnerable
    Computers running Windows 95 or NT with IE 5 or higher or those running Windows 98, ME, 2000, XP or 2003 without explicitly disabled WSH are vulnerable to WSH threats. It is recommended that individuals check their systems manually in line with the recommendations outlined in section 'W7.5 How to Protect Against It' to see if corrective action is necessary.

    W7.5 How to Protect Against It
     

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

    Disable Windows Scripting Host

    Symantec Security Response gives the following description of the WSH and the possibility of disabling it.

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

    The program Noscript.exe, from Symantec, will disable the Windows Scripting Host by renaming the file association classes for any class that has either Wscript.exe or Cscript.exe in its Shell\Open\Command or Shell\Open2\Command registry keys. This actively prevents all scripts from running on the system whether they are malicious or intentional.

    Install Instructions derived from Symantec Security Response

    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.

    Change default behavior of Windows Scripting Host
    In order to preserve functionality of WSH for administrative and desktop automation purposes while safeguarding against potential threats, it is possible to change default behavior of the Windows Operating System with respect to script files (with extensions: .vbs, .vbe, .js, jse, .wsf). By default, Windows treats script files similar to standard Windows executable files with extensions .exe and .com - it immediately executes them.

    By removing the default action of Automatic Execution for WSH scripts it is possible to prevent the unintended execution of all scripts. The recommended approach is to change the configuration so that by default all scripts are opened in a text editor. In addition to ensuring that scripts cannot be executed without suitable permissions, it also allows users to review code on a script-by-script basis before deciding whether it should be run. Similarly, this approach can help trap scripts trying to masquerade as innocent file-types through the use of double (or multiple) extensions.

    Legitimate WSH scripts may still be executed by explicitly specifying the filename as argument for cscript.exe or wscript.exe, i.e:

    cscript.exe myscript.vbs
    or
    wscript.exe myscript.vbs

    Reference: Symantec Security Response How to Disable or Remove the Windows Scripting Host http://www.symantec.com/avcenter/venc/data/win.script.hosting.html

    Anti-Virus
    It is recommended that up-to-date Anti-Virus solutions be installed at gateways, servers and hosts - in addition to the disabling of WSH - to provide tiered levels of assurance and security and to block or remove email that contains file attachments that are commonly used to spread viruses, such as .vbs, .vbe, .js, .jse, .wsf, .bat, .exe, .pif and .scr files. Such screening can also help filter out files that make use of double (or multiple) file-type extensions, which are almost exclusively malicious in nature. For example, Norton AntiVirus 2001 and later provides Script Blocking functionality that can help protect individual hosts against WSH viruses and related malware.

    Update Script Engine
    WSH has been upgraded several times over the years, providing greater in-built stability and security. The most recent version is available at Microsoft's MSDN: Download Windows Script (includes Windows Scripting Host)

    NTFS Permissions
    NTFS access permissions may be used to define the level of access available to wscript.exe and cscript.exe, the Windows Scripting Host executables, from specific users and groups of users with valid Windows accounts.

    When sharing a directory or file, the default access settings for NTFS directories and files grants Full Control access to the Windows user group Everyone, including all users. This means that all users have permission to modify, move, and delete files or directories and to change NTFS permissions. This default setting is inappropriate for the wscript.exe and cscript.exe. Securing files and folders involves removing unnecessary users and groups or groups that have no specific need to access the resource.

    To change NTFS permissions for a directory or file.

    Instructions Derived from the Microsoft Windows Server Documentation - Setting NTFS Permissions for a Directory or File:

    1. Open My Computer, select the drive, directory, or file you want to secure, and open its property sheets.
    2. On the Security property sheet, select the Windows account you want to change permissions for.
    3. Under Permissions, select the types of access for the selected user or group. Use Allow to specifically allow access and Deny to specifically deny access. For more choices, click Advanced. For more information about setting and configuring permissions for files and directories refer to the Windows documentation.

      Note: If you do not see the Security tab in the drive, directory, or file property sheets, the host file system is not configured as NTFS.

    To convert the file system to NTFS, refer to the Windows documentation. In addition, be careful when using the Deny option - this takes precedence over Allow. Applying Deny to the Everyone group might close the resource to that level of access by anyone, including the Administrator.

    Reference: Setting NTFS Permissions for a Directory or File - http://www.microsoft.com/windows2000/en/server/iis/htm/core/iidfpsc.htm

     

    back to top ^



     

    W8 Microsoft Outlook and Outlook Express

    W8.1 Description
    Microsoft Outlook, part of the Microsoft Office suite, is a personal information manager and email client program from Microsoft. Whilst primarily an e-mail application, it also provides calendar, task and contact management. When used in conjunction with a Microsoft Exchange Server, Microsoft Outlook can provide additional and enhanced functionality, such as supporting multiple users, helping to co-ordinate meeting times,and providing shared calendars and mailboxes.

    Outlook Express (OE), a less functional but free version of Outlook, has been bundled with Internet Explorer since version 1.0, an integral part of Microsoft Windows 95. By integrating products such as Internet Explorer and Outlook Express into other product lines, including Office, BackOffice, and the Windows operating system, common technologies and code may be used across the platform. For instance, Microsoft Outlook 98 like its cousin Outlook Express uses Internet Explorers HTML parsing and rendering engine. Therefore, if you install Outlook 98 onto a computer without version 4 or higher, Internet Explorer gets installed as well. This foundational approach makes sense and allows for more efficient code usage. However, this practice introduces both single points of failure and heightens the impact that any single security vulnerability may pose, thus adding to the mounting challenges of maintaining a safe and secure operating environment.

    One of Microsoft's goals has been to develop a usable and intuitive email and information management solution. Unfortunately, the embedded automation features are at odds with the built-in security controls (often disregarded by end-users). This has led to exploitation, giving rise to e-mail viruses, worms, malicious code to compromise the local system, and many other forms of attack.

    W8.2 Operating Systems Affected
    Outlook Express (OE) is a free, basic mail client that is bundled with all versions of Internet Explorer and Microsoft Windows.

    To identify the current version of OE, start Internet Explorer and then select About Internet Explorer from the Help menu. Versions below 5 should be upgraded immediately in line with the recommendation in section 10.5 How to Protect Against It.

    Outlook is a full-featured information manager that ships both as a stand-alone product and as part of the Office family. Its only installed on a machine if the user has specifically installed it. Versions of Outlook for Microsoft Windows include:
    • Outlook 95
    • Outlook 97
    • Outlook 2000, also known as Outlook 9
    • Outlook XP, also known as Outlook 10 or Outlook 2002


    To identify the current version of Outlook, start the program and then select About Outlook from the Help menu. Versions below Outlook 2000 should be patched or upgraded immediately.

    Reference:
    Outlook Express    http://www.microsoft.com/windows/oe/
    Outlook                http://www.microsoft.com/office/outlook/

    CVE-1999-0967, CVE-2000-0036, CVE-2000-0567, CVE-2000-0621, CVE-2000-0662,
    CVE-2000-0753, CVE-2000-0788, CVE-2001-0149, CVE-2001-0340, CVE-2001-0538,
    CVE-2001-0660, CVE-2001-0666, CVE-2001-0726, CVE-2001-1088, CVE-2002-0152,
    CVE-2002-0685, CVE-2002-1056

    CAN-1999-0004, CAN-1999-0354, CAN-1999-1016, CAN-1999-1033, CAN-1999-1164,
    CAN-2000-0105, CAN-2000-0216, CAN-2000-0415, CAN-2000-0524, CAN-2000-0653,
    CAN-2000-0756, CAN-2001-0145, CAN-2001-0945, CAN-2001-0999, CAN-2001-1325,
    CAN-2002-0285, CAN-2002-0481, CAN-2002-0507, CAN-2002-0637, CAN-2002-1121,
    CAN-2002-1179, CAN-2002-1255, CAN-2003-0007, CAN-2003-0301

    W8.4 How to Determine if you are Vulnerable
    All computers running Microsoft Windows operating systems or that have Internet Explorer installed will contain Outlook Express. Manual installations of Microsoft Office suite applications may include Outlook with the more common productivity packages such as Word, Excel, PowerPoint and Access.

    Microsoft Outlook and Outlook Express for Macintosh have also been identified as having a variety of security issues.

    It is recommended that individuals check their systems manually, in line with the guidelines outlined in section W10.2 Operating Systems Affected, to see if corrective action is necessary.

    A system is vulnerable if either

    1. it is not fully up-to-date, which can be tested by visiting MS update or
    2. the security settings are inappropriately set.


    W8.5 How to Protect Against It
    There are a couple of things you can do to configure Outlook and/or Outlook Express so as to minimize the security risks posed.

    Secure Outlook / Outlook Express
    By default Outlook and Outlook Express have fairly open security and configuration settings. It is important to tighten these down and make sure that the core software is up-to-date.

    1. Routinely visit the Microsoft Update site, http://windowsupdate.microsoft.com, and apply all critical patches.
    2. Disable the Message Preview Pane by clicking on View > Layout and un-checking the Show preview pane option.
    3. Tighten the settings relating to the Security zone associated with incoming E-mail.
      Select Tools > Options and then click on the Security Tab. Click on the "Restricted sites zone (More secure)" radio button and then manually adjust the setting to high. Click on Apply and OK to lock in your choice.


    User Behavior
    Since it is the human element that is often the weakest link in the security process, it is important to follow some Best Practice guidelines when dealing with electronic mail.

    When receiving an attachment, even if it has originated from a trusted source, it is important to ensure that it is screened for viruses and other malware as detailed in the following section entitled Anti-Virus.

    Upon receipt of an attachment, save it to a folder other than your My Documents, since that is what many viruses use as a starting point. Select another folder, or even another partition, to separate incoming attachments from the rest of your files.

    Don't open unexpected attachments even if they are from friends. Even DOC and XLS files can contain embedded Basic programs that can cause harm to your system. If you must open the document with another Microsoft product, such as Word, be sure to go under Tools > Options > Security and select the radio button next to High to disable macros unless they are signed.

    Always check all available digital signatures associated with executable files to ensure file integrity and that it has originated from a trusted source.

    Anti-Virus
    Antivirus software can help protect computers against most viruses, worms, Trojan horses, and other malicious code including scripting attacks documented in W10 Windows Scripting Host. It is crucial that antivirus signature databases be updated at least weekly (and ideally automatically and daily) to help ensure protection against even the newest threats. Most modern antivirus solutions fully automate this task. It is prudent to be cautious and ensure that all files are scanned as a precautionary measure, regardless of file-type or origin.

    Modern anti-virus solutions have the ability to scan all incoming and outgoing mail to ensure that malicious file-types and scripts are blocked before they can harm the local system.

    It is highly recommended that up-to-date virus protection tools are installed before using e-mail or the Internet, as many viruses spread through e-mail clients in the form of attachments or malicious scripted code that is run when the message is previewed.

    Reference:
    Microsoft Antivirus Reference    http://www.microsoft.com/security/protect/antivirus.asp

    Update Outlook and Outlook Express
    Outlook Express has been upgraded several times over the years, providing greater built-in functionality, stability and security. The most recent version is available freely from Microsoft: Outlook Express http://www.microsoft.com/windows/oe/

    To ensure that Outlook and all of your other Office programs are completely up-to-date, visit the Office Product Updates page. This site automatically detects critical and recommended updates that are necessary.

    For detailed information about other security features and settings in Office XP, read the Office XP Security white paper.

    Note: If your computer is part of a managed network, please contact your organization's system administrator before making changes to your computer. Administrators can find detailed technical information about the Outlook E-Mail Security Update in the Office Resource Kit.

    Uninstall Outlook and Outlook Express
    If a separate e-mail or information management client is used on you computer, Outlook and/or Outlook Express may be safely uninstalled.

    Outlook on all versions of Windows
    Outlook may be removed from the computer by clicking on Start > Settings > Control Panel and double clicking on the Add/Remove Programs icon. When the Add/Remove Program Properties dialog box opens, click on the appropriate tab, entitled Outlook, and select the Remove button.

    Outlook Express on Windows 98/ME
    Outlook Express may be removed from the system by clicking on Start > Settings > Control Panel and double clicking on the Add/Remove Programs icon. When the Add/Remove Program Properties dialog box opens, click on the Windows Setup tab and scroll down the window to Microsoft Outlook Express and remove the check mark in the box next to it.

    Click on the Apply and OK buttons to lock in your changes and Windows will uninstall Outlook Express.

    Outlook Express on Windows 2000/XP or Updated versions of Internet Explorer
    The steps necessary to remove Outlook Express under Windows 2000/XP or for users who have upgraded their browser to a later version are much more complex. Refer to the following Microsoft guides for full details:

    Windows 2000 users running Microsoft Outlook Express versions 5.x/6.0
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;q263837

    Windows 98/Me and updated to Microsoft Outlook Express versions 5.x/6.0
    http://support.microsoft.com/default.aspx?scid=kb;EN-US;q256219

    Note: Outlook Express may be re-installed silently if a service pack, significant roll-up, or operating system upgrade is installed.

     

    back to top ^



     

    W9 Windows Peer to Peer File Sharing (P2P)

    W9.1 Description
    This vulnerability is different from many of the others, given that Peer to Peer programs are user mode applications. Peer to Peer File Sharing Programs (P2P) are used extensively by a rapidly growing user base. These applications are used to download, and distribute many types of data (e.g. music, video, graphics, text, source code, and proprietary information to name a few). Often, the data is either of a questionable nature or is copyrighted. With the legal troubles experienced by Napster, the majority of these programs now operate through a distributed network of clients, sharing directories of files or entire hard drives of data. Users enter search parameters through the client software, and then one or more channels of communication are opened between participants as the client software contacts other network participants to locate the desired file. Clients participate both by downloading files from other users, by making their data available to others, and in some models by functioning as supernodes which can coordinate searches for multiple users.

    Peer to Peer communication consists of get requests, replies, and file transfers. A participant can concurrently perform multiple downloads while also serving multiple uploads. Searches for content can use almost any text string the user can conceive. Most of these programs currently use default ports, but can automatically or manually be set to use different ports if necessary to circumvent detection, firewalls, or egress filters. The trend seems to be moving towards the use of http wrappers to more easily bypass corporate restrictions. The multithreaded nature of searches and transfers can generate significant traffic on densely populated LANS and can completely saturate WAN links.

    A number of vulnerabilities exist when using P2P software. They can be categorized into three types. Technical vulnerabilities are those that can be exploited remotely. Social vulnerabilities are those that are exploited by altering or masquerading binary content that others request. And legal vulnerabilities are those that can result from copyright infringement or objectionable material.

    As mentioned above, technical vulnerabilities are those that can be exploited remotely and result simply from a user downloading, installing, and running one of these programs. The CVE and CAN entries listed below all address technical vulnerabilities. These range from Denial of Service to arbitrary file access, and should be taken very seriously. Not addressed in the CVE database, but of serious concern, are the privacy and confidentiality issues that P2P applications can cause. Many of these applications include "spyware" or "adware" components that can consume even more bandwidth as they report web-surfing habits back to their makers. A poorly configured P2P client can provide unauthenticated access to your entire network by sharing mapped drives through the P2P application. There is little to no restriction on the type of data files that can be shared. Compromise of confidential information, intellectual property, and other data can result.

    Social vulnerabilities exist when a malicious or previously infected user creates or alters a file to resemble something desired by another user. Virii, trojan horse programs, worms, and other malware can result. The victim of such attacks is usually the less technical user, who will "double-click" a file without noticing that the extension or icon is not what is normally associated with the data type, or that can be duped into launching an executable.

    Legal vulnerabilities must be taken seriously by both the corporate user and the home user. Content available through P2P applications includes copyrighted music, movies, and program files. Organizations including the MPAA, RIAA, and BSA are all actively seeking to put an end to the copyright infringement occurring through P2P networks. Subpoenas for user id's, injunctions, and civil suits have all been brought in courts across the country. The success of these efforts, or lack thereof, and the morality or immorality of downloading such material must all be secondary to the costs for a company to respond to and defend against allegations of wrongdoing. Pornographic content is also widely available through the P2P networks. Whether such material is legal in your jurisdiction or not is irrelevant if a sexual harassment lawsuit is brought against your company because an employee downloaded material using a company computer that another employee found offensive.

    W9.2 Operating Systems Affected
    There are versions of P2P software available for all Windows operating systems currently in use, along with versions for UNIX and Linux systems.

    W9.3 CVE/CAN Entries
    CVE-2001-0368

    CAN-2000-0412, CAN-2002-0314, CAN-2002-0315, CAN-2003-0397

    W9.4 How to Determine if you are Vulnerable
    Discovering P2P activity on your network can prove to be challenging. You can look for P2P software running on your network by monitoring traffic for common ports used by the software or by searching traffic for certain application layer strings commonly used by P2P software. Please see the end of this article for a listing of ports often used by P2P applications and links to Snort rules which may be helpful. PacketPup from Pallisades Software can monitor for P2P traffic. You may also wish to scan network storage locations for content commonly downloaded by users, including *.mp3, *.wma, *.avi, *.mpg, *.mpeg, *.jpg, *.gif, *.zip, and *.exe. Monitoring volumes for sudden decreases in free disk space can also be useful.

    W9.5 How to Protect Against It
    Corporate policy:
    1. Your company should have and enforce a policy against the downloading of copyrighted material.
    2. Your company should have and enforce an acceptable use policy for the corporate Internet connection.
    3. Regular scanning of network storage and company workstations for unauthorized materials should be performed.

    Network restrictions:

    1. Regular users should not be able to install any software, especially peer to peer applications.
    2. Consider using a proxy server to control Internet access.
    3. Egress filtering should restrict access to any ports not required for business purposes, although as more p2p applications move to http this will prove less effective.
    4. Monitor your network for P2P traffic and address violations of policy through appropriate channels.
    5. Utilize enterprise-wide antivirus software and ensure that updates are performed daily.

    Common ports used by peer to peer applications
     


    Napster eDonkey Gnutella Kazaa
    tcp 8888 tcp 4661 tcp/udp 6345 tcp 80 (WWW)
    tcp 8875 tcp 4662 tcp/udp 6346 tcp/udp 1214
    tcp 6699 udp 4665 tcp/udp 6347
        tcp/udp 6348  
        tcp/udp 6349  

    Snort signature database entries at http://www.snort.org/cgi-bin/sigs-search.cgi?sid=p2p

     

    # 549 # 556 # 1432
    # 550 # 557 # 1669
    # 551 # 558 # 2180
    # 552 # 559 # 2181


     

    back to top ^



     

    W10 Simple Network Management Protocol (SNMP)

    W10.1 Description
    The Simple Network Management Protocol (SNMP) is used extensively to remotely monitor and configure almost all types of modern TCP/IP-enabled devices. While SNMP is ubiquitous is its distribution across networking platforms, it is most often used as a method to configure and manage devices such as printers, routers, switches, wireless access points and bridges, and to provide input for network monitoring services.

    Simple Network Management communication consists of different types of exchanged messages between SNMP management stations and network devices which run what is commonly referred to as agent software. The method by which these messages are handled and the authentication mechanism behind such message handling both have significant exploitable vulnerabilities.

    The vulnerabilities behind the method by which SNMP version 1 handles and traps messages are outlined in detail in CERT Advisory CA-2002-03. There exists a set of vulnerabilities in the way trap and request messages are handled and decoded by management stations and agents alike. These vulnerabilities are not restricted to any specific implementation of SNMP but instead affect a variety of vendors' SNMP distributions. The result of attackers exploiting these vulnerabilities may range anywhere from denial of service to unwanted configuration and management of your SNMP-enabled machinery.

    The inherent authentication mechanism of older SNMP frameworks also poses a significant vulnerability. SNMP versions 1 and 2 use an unencrypted "community string" as their only authentication mechanism. Lack of encryption is bad enough, but the default community string used by the vast majority of SNMP devices is "public," with a few supposedly clever network equipment vendors changing the string to "private" for more sensitive information. Attackers can use this vulnerability in SNMP to reconfigure or shut down devices remotely. Sniffed SNMP traffic can reveal a great deal about the structure of your network as well as the systems and devices attached to it. Intruders use such information to pick targets and plan attacks.

    Most vendors enable SNMP version 1 by default, and many do not offer products capable of using SNMP version 3's security models which can be configured to use improved authentication methods. However, there are freely-available replacements which do provide SNMPv3 support under GPL or BSD licenses.

    SNMP is not usually enabled by default on Windows, but is often found as an added service by a well-intentioned administrator. Other network management products may require the Windows service or install their own. SNMP is also often the communication method used to manage printers, UPS systems, and wireless access points and bridges. SNMP is often found running in various UNIX and Linux distributions, Netware versions, networking equipment, printers, and embedded devices. The majority of SNMP-related attacks seen thus far have occurred on UNIX systems with poor SNMP configurations.

    W10.2 Operating Systems Affected
    Nearly all versions of Windows operating systems come with the SNMP as an available installation option, though by default the service is not installed or enabled. Most other SNMP-enabled network devices and operating systems are also vulnerable.

    W10.3 CVE/CAN Entries
    CVE-1999-0294, CVE-1999-0815

    CAN-1999-0499, CAN-2002-0053

    W10.4 How to Determine if you are Vulnerable
    You can verify whether SNMP is running on network-connected devices by running a scanner or checking manually.
    SNMPing - You can obtain the free SNMPing scanning tool from the SANS Institute by emailing a blank mail message to snmptool@sans.org. You will get a return message with the URL where you can download the tool.
    SNScan - Foundstone created another easy-to-use SNMP scanning tool called SNScan which can be obtained at http://www.foundstone.com/knowledge/free_tools.html.

    If you can not use any of the above tools, you should manually verify if SNMP is running on your systems. Refer to your operating system documentation on how to specifically identify its particular SNMP implementation, but the basic service can usually be identified by checking the running services in the Services applet, in the process list, by executing the "net start" command at a command prompt, or by looking for services running on ports 161 or 162 using the "netstat -an" command.

    A running SNMP instance is probably sufficient evidence that you are vulnerable to pervasive trap and request handling errors. Please see CERT Advisory CA-2002-03 for additional information.

    If SNMP is running and any of these additional variables are met, you may have a default or easily guessable string-related vulnerability:
    1. Blank or default SNMP community names.
    2. Guessable SNMP community names.
    3. Hidden SNMP community strings.


    Please see http://www.sans.org/resources/idfaq/snmp.php for information on how to identify the presence of those conditions.

    W10.5 How to Protect Against It
    Trap and Request Handling Vulnerabilities:

    1. If you do not absolutely require SNMP, disable it.
    2. Wherever possible, employ an SNMPv3 user-based security model with message authentication and possibly encryption of the protocol data unit.
    3. If you must use SNMPv1 or v2, make sure you are running the latest patched version from your vendor. A good starting point in obtaining vendor specific information is Appendix A of CERT Advisory CA-2002-03.
    4. Filter SNMP (port 161 TCP/UDP and 162 TCP/UDP) at the ingress points to your networks unless it is absolutely necessary to poll or manage devices externally. Then, if possible, configure filtering to only permit SNMP traffic between trusted subnets.
    5. Employ host-based access control on your SNMP agent systems. While this capability may be limited by SNMP agent operating system capabilities, control of what systems your agents will accept requests from may be possible. On most Windows 2000 and later systems this can be accomplished through an IPSEC filter. An agent-based packet filtering firewall on the host can also be used to block unwanted SNMP requests.


    Default and Guessable String-Related Vulnerabilities:

    1. If you do not absolutely require SNMP, disable it.
    2. Wherever possible, employ an SNMPv3 user-based security model with message authentication and possibly encryption of the protocol data unit.
    3. If you must use SNMPv1 or v2, use the same policy for community names as used for passwords. Make sure they are difficult to guess or crack, and they are changed periodically.
    4. Validate and check community names using snmpwalk. Additional information can be found at http://www.zend.com/manual/function.snmpwalk.php. A good tutorial on this tool can be found at http://www.sans.org/resources/idfaq/snmp.php.
    5. Filter SNMP (port 161 TCP/UDP and 162 TCP/UDP) at the ingress points to your networks unless it is absolutely necessary to poll or manage devices externally. Then, if possible, configure ingress filtering to only permit snmp traffic between trusted subnets.
    6. Where possible make MIBs read-only. Additional information can be found at http://www.cisco.com/univ ercd/cc/td/doc/cisintwk/ito_doc/snmp.htm#xtocid210315.


     

    back to top ^



     

    Top Vulnerabilities to UNIX Systems (U)

    U1 BIND Domain Name System

    U1.1 Description
    The Berkeley Internet Name Domain (BIND) package is the most widely used implementation of the Domain Name Service (DNS), a critical system that allows the conversion of hostnames (e.g. www.sans.org) into the registered IP address. The ubiquity and critical nature of BIND has made it a frequent target, especially in Denial of Service (DoS) attacks, which can result in a complete loss of accessibility to the Internet for services and hosts. Whilst BIND developers have historically been quick to repair vulnerabilities, an inordinate number of outdated, misconfigured and/or vulnerable servers remain in place.

    A number of factors contribute to this condition. Chief among them are administrators who are not aware of security upgrades, systems which are running BIND daemon (called "named") unnecessarily, and bad configuration files. Any of these can effect a denial of service, a buffer overflow or DNS cache poisoning. Among the most recently discovered BIND weaknesses was a denial of service discussed in CERT Advisory CA-2002-15. In this case, an attacker can send specific DNS packets to force an internal consistency check which itself is vulnerable and will cause the BIND daemon to shut down. Another was a buffer overflow attack, discussed in CERT Advisory CA-2002-19, in which an attacker utilizes vulnerable implementations of the DNS resolver libraries. By sending malicious DNS responses, the attacker can explore this vulnerability and execute arbitrary code or even cause a denial of service.

    A further risk is posed by a vulnerable BIND server, which may be compromised and used as a repository for illicit material without the administrator's knowledge or in stepping-stone attacks which use the server as a platform for further malicious activity.

    U1.2 Operating Systems Affected
    Nearly all UNIX and Linux systems are distributed with a version of BIND. This may typically only be installed if the host is configured to act as a server. Binary versions of BIND do exist for Windows.

    U1.3 CVE/CAN Entries
    CVE-1999-0009, CVE-1999-0024, CVE-1999-0184, CVE-1999-0833, CVE-1999-0837,
    CVE-1999-0835, CVE-1999-0849, CVE-1999-0851, CVE-2000-0887, CVE-2000-0888,
    CVE-2001-0010, CVE-2001-0011, CVE-2001-0012, CVE-2001-0013

    CAN-2002-0029, CAN-2002-0400, CAN-2002-0651, CAN-2002-0684, CAN-2002-1219,
    CAN-2002-1220, CAN-2002-1221

    U1.4 How to Determine if you are Vulnerable
    If you are running a version of BIND that came with your operating system, verify that you are current with the patches released by your vendor. If running BIND as built from source from the Internet Software Consortium (ISC), ensure that this is the latest version of BIND. Unpatched or outdated versions of BIND are likely to be vulnerable.

    For most systems, the command "named -v" will show the installed BIND version enumerated as X.Y.Z where X is the major version, Y is the minor version, and Z is a patch level. There are currently three major versions for BIND: 4, 8 and 9. If you are running BIND built from source, you should eschew version 4 for version 9. You can retrieve the latest source, version 9.2.2, from the ISC.

    A proactive approach to maintaining the security of BIND is to subscribe to customised alerting and vulnerability reports, such as those available from SANS, Symantec or Afentis. In addition, an updated vulnerability scanner can be highly effective in periodically checking DNS systems for potential vulnerabilities.

    U1.5 How to Protect Against It
     
    • To generally protect against BIND vulnerabilities:
      1. Disable the BIND daemon (called "named") on any system which is not specifically designated and authorized to be a DNS server. To prevent this change from being reversed, it may be wise to also remove the BIND software.
      2. Apply all vendor patches or upgrade your DNS Server to the latest version. For more information about hardening your BIND installation, see the articles about securing name services as referenced in CERT's UNIX Security Checklist.
      3. To complicate automated attacks or scans of your systems, hide the "Version String" banner in BIND by replacing the actual version of BIND with a bogus version number in the "named.conf" file options statement.
      4. Permit zone transfers only to secondary DNS servers in your domain. Disable zone transfers to parent or child domains, using delegation and forwarding instead.
      5. The Padded Cell: To prevent a compromised "named" from exposing your entire system, restrict BIND so that it runs as a non-privileged user in a chroot()ed directory. For BIND 9, see http://www.losurs.org/docs/howto/Chroot-BIND.html.
      6. Disable recursion and glue fetching to defend against DNS cache poisoning


       

    • To protect against recently discovered BIND vulnerabilities:
      1. For the Denial of Service Vulnerability on ISC BIND 9: http//www.cert.org/advisories/CA-2002-15.html
      2. Multiple Denial of Service vulnerabilities on ISC BIND 8: http://www.isc.org/products/BIND/bind-security.html

    For excellent guides to hardening BIND on Solaris systems as well as additional references for BIND documentation, please see Running the BIND9 DNS Server Securely and the archives of BIND security papers available from Afentis.

     

    back to top ^



     

    U2 Remote Procedure Calls (RPC)

    U2.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 numerous flaws in RPC which are being actively exploited. Many RPC services execute with elevated privileges that can provide an attacker unauthorized remote root access to vulnerable systems.

    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. More recently, an MS Windows DCOM Remote Procedure Call vulnerability has played a role in one of the most significant worm propagation events to this date.

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

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

    CAN-2002-0677 , CAN-2003-0028 , CAN-2003-0252

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

     
    RPC Service RPC Program Number
    rpc.ttdbserverd 100083
    rpc.cmsd 100068
    rpc.statd 100024
    rpc.mountd 100005
    rpc.walld 100008
    rpc.yppasswdd 100009
    rpc.nisd 100300
    sadmind 100232
    cachefsd 100235
    snmpXdmid 100249


    RPC services are typically exploited through buffer overflow attacks which are successful because the RPC programs do not perform sufficient error checking or input validation. Buffer overflow vulnerabilities allow an attacker to send unexpected data (often in the form of malicious code) into the program memory space. Due to poor error checking and input validation, the data overwrite key memory locations that are in line to be executed by the processor. In a successful overflow attack, this malicious code is then executed by the operating system. Since many RPC services execute with elevated privileges, successful exploitation of these vulnerabilities can provide unauthorized remote root access to the system.

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

      For HP-UX Software Enhancements and Patch Bundles:
      http://www.software.hp.com/portal/swdepot/displayProductsList.do?category=ER
    3. Regularly search the vendor patch database for new patches and install them right away.
    4. Block the RPC portmapper, port 111 (TCP and UDP) and Windows RPC, port 135 (TCP and UDP), 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. Set up 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:



       

    U3 Apache Web Server

    U3.1 Description
    Apache has historically been, and continues to be the most popular web server on the Internet. In comparison to Microsofts Internet Information Server, Apache may have a cleaner record in regards to security, but it still has its fair share of vulnerabilities.

    In addition to exploits in Apaches core and modules (CA-2002-27, CA-2002-17), SQL, databases, CGI, PHP vulnerabilities are all potentially exposed through the web server.

    If left unsecured, vulnerabilities in the Apache web server implementation and associated components can result in denial of service, information disclosure, web site defacement, remote root access, or countless other unfavorable results.

    U3.2 Affected Operating Systems
    All UNIX systems are capable of running Apache. Many Linux and UNIX variants come with Apache installed and sometimes enabled by default. Additionally, Apache is capable of running on a host of other operating systems including Windows and is likely subject to many of the same vulnerabilities

    U3.3 CVE/CAN Entries
    CVE-1999-0021, CVE-1999-0066, CVE-1999-0067, CVE-1999-0070, CVE-1999-0146,
    CVE-1999-0172, CVE-1999-0174, CVE-1999-0237, CVE-1999-0260, CVE-1999-0262,
    CVE-1999-0264, CVE-1999-0266, CVE-2000-0010, CVE-2000-0208, CVE-2000-0287,
    CVE-2000-0941, CVE-2002-0082, CVE-2002-0392

    CAN-1999-0509, CAN-2000-0832, CAN-2002-0061, CAN-2002-0513, CAN-2002-0655,
    CAN-2002-0656, CAN-2002-0657, CAN-2002-0682, CAN-2003-0132, CAN-2003-0189,
    CAN-2003-0192, CAN-2003-0254

    U3.4 How to Determine if you are Vulnerable
    Information regarding security advisories for Apache 1.3.x is available at http://www.apacheweek.com/features/security-13 and Apache 2.0.xs security information resides at http://www.apacheweek.com/features/security-20. These links provide detailed information that describes how to determine if you are vulnerable, which versions are affected by the associated vulnerability, and what the suggested workarounds are when possible. Additionally, the above security advisory information is linked off of http://httpd.apache.org.

    U3.5 How to Protect Against It
     
    1. Ensure that you are running the latest patch level.
    2. Ensure that core operating system components that are referenced by Apache are patched. Only the modules necessary for your server to function properly should be compiled into Apache.
      note: The mod_ssl worm (CA-2002-27) is a perfect example that resulted from vulnerabilities within OpenSSL (CA-2002-23).
    3. Do not run Apache as root. A unique user and group with minimal privileges should be created for running Apache. No other system processes should be run under this user or group.
    4. Limit the server information that is revealed.
      While this suggestion tends to encounter opposition from people suggesting security by obscurity is not the way and a number of exploit attempts you will see are done in a blind sweeping fashion (proven by the fact that you will see in many Apache logs IIS exploit attempt after IIS exploit attempt), there are also some exploits that will trigger based on header information.
    5. You should consider running Apache in a chroot environment. If Apache is started chroot-ed it cannot access any part of the operating system directory structure outside of the chroot. This can often help prevent exploits. For example, an exploit may call a shell and since /bin/sh likely does not (and should not) reside in the chroot, it would be ineffective.
      WARNING: chrooting Apache may have adverse effects on CGI, PHP, databases and other modules or communications which may require the web server environment access to external libraries or binaries.
      As there are numerous methods of chrooting, software documentation should be consulted for assistance. Additional information can be found below.
    6. Efficient and thorough logging is essential to effectively track down any potential security problems or unexplained behavior you may be experiencing with your web server. It is a good practice to routinely rotate logs and keep older logs archived. This will make the log size more manageable and easier to parse through if necessary.
      Various information regarding log formats and rotation are available here:

      In many scenarios the content of these logs may not be sufficient. Especially if youre using PHP, CGI or other scripting it is a good idea to log GET and POST payloads. This can yield important data and evidence in the event of a security compromise. Logging of GET and POST payloads can be implemented via mod_security.

    7. PHP, CGI, SSI and other scripting.
      • Unless absolutely necessary, disable PHP, CGI, SSI and other scripting languages.
      • Disable Server Side Includes (SSI) which can potentially be abused and cause the web server to execute code which it was not intended to.
      • If PHP, CGI, SSI or other scripting languages are necessary, consider utilizing suEXEC. suEXEC allows scripts to be run under Apache with a user id other than the Apache user id.
        WARNING: It is imperative that suEXEC is understood thoroughly. If it is improperly utilized it can create new security holes.
        1. For Apache 1.3.x see http://httpd.apache.org/docs/suexec.html
        2. For Apache 2.0.x see http://httpd.apache.org/docs-2.0/suexec.html
      • Ensure the content of cgi-bin and other scripts directories. All sample and default scripts should be removed.
      • Securing PHP:
        This is a broad topic in and of itself. What follows gives some sound starting points for ensuring your PHP implementation is secure.
        1. Disable parameters that will cause PHP to disclose information in the HTTP header.
        2. Ensure that PHP is running in safe mode.

        Detailed information can be found here:
        http://www.securityfocus.com/printable/infocus/1706

      • Additional modules can aid in security. The mod_security (www.modsecurity.org) module can help protect against Cross Site Scripting (XSS) and SQL injection. Detailed implementation instructions can be found at their website.
      • Auditing your scripts for vulnerabilities including XSS and SQL injection is also important. There are a few open source tools that will accomplish this. Nikto (available at http://www.cirt.net/code/nikto.shtml) is one of the more comprehensive CGI scanning tools.
    back to top ^



     

    U4 General Unix Authentication Accounts with No Passwords or Weak Passwords

    U4.1 Description
    Passwords, passphrases and/or security codes are used in virtually every interaction between users and information systems. Most forms of user authentication, as well as file and data protection, rely heavily on user or vendor supplied passwords. In addition, since properly authenticated access is often not logged, or if logged not likely to arouse suspicion, a compromised password is an opportunity to explore a system virtually undetected. An attacker in possession of a valid user password would have complete access to any resources available to that user, and would be significantly closer to being able to access other accounts, nearby machines, and perhaps even obtain root level access on this system. Despite this threat, user and administrator level accounts with poor or non-existent passwords are still very common. As well, organizations with a well-developed and enforced password policy are still uncommon.

    The most common password vulnerabilities are: (a) user accounts that have weak or nonexistent passwords; (b) users accounts with widely known or openly displayed passwords; (c) system or software created administrative level accounts with widely known, weak, or nonexistent passwords; and (d) weak or well known password hashing algorithms and/or user password hashes that are stored with weak security and are visible to anyone.

    The best defense against all of these vulnerabilities is a well developed password policy that includes: detailed instructions for users to create strong passwords; explicit rules for users to ensure their passwords remain secure; a process in place for IT staff to promptly replace weak/insecure/default or widely known passwords and to promptly lock down inactive or close down unused accounts; and a proactive and regular process of checking all passwords for strength and complexity.

    U4.2 Operating Systems Affected
    Any operating system or application on any platform where users authenticate via a user ID and password.

    U4.3 CVE/CAN Entries
    CVE-1999-0502

    U4.4 How to Determine if you are Vulnerable
    If there are commonly known user accounts shared by many individuals or temporary personnel and/or openly displayed passwords written on notes on desktops or monitors, these are obvious openings into your network for anyone with physical access to your systems.

    Likewise, configuring new user accounts with the same initial password or an easily-guessed initial password (even if the initial password is to be changed after first login) can also give attackers a window of opportunity to gain access to your systems.

    Determine if password hashes are stored in either /etc/passwd or /etc/shadow on each local system. The file /etc/passwd needs to be readable by all users on the network to permit user authentication. However, if that file also includes the password hashes, then any user with access to the system can read those hashes and attempt to break them with a password cracker. The file /etc/shadow by design is to be only readable by root and where available should be used to store the hashes. If your local accounts are not protected by /etc/shadow, then the risk to your passwords is extremely high. Most new operating systems by default will use /etc/shadow to store password hashes unless this is overridden by the installer. You may also be able to use the MD5 algorithm to hash your passwords; this is somewhat more secure than the older crypt algorithm.

    NIS is a set of services that work as a database service to provide location information, called Maps, to other network services, such as Network File System (NFS). By nature of its design, NIS configuration files contain NIS password hashes and as a result, the hashes are readable by all users and the passwords are at risk. This may also be the case with some implementations of LDAP as a network authentication service. Newer implementations of NIS, such as NIS+ or LDAP, are generally more rigorous at protecting password hashes unless this is overridden by the installer. However, these newer implementations may be more difficult to setup and configure which may discourage their use.

    Even if password hashes are protected by /etc/shadow or other implementations, passwords can be guessed by other means. There are other common areas of password weakness, including the existence of unused accounts for users that have departed an organization. Organizations are commonly negligent in closing down old user accounts unless there are procedures in place or the administrator is particularly diligent.

    Default installations (either from the manufacturer or by an administrator) of operating systems or network applications may introduce a wide range of unneeded and unused services. In many cases the uncertainty about operating system or application needs leads many manufacturers or administrators to install all of the software in case it is needed in the future. This simplifies the installation process significantly but also introduces a wide range of unneeded services and accounts that have default/weak/or known passwords.

    U4.5 How to Protect Against It
    The best and most appropriate defense against password weaknesses is a strong policy which provides detailed instructions to engender good user password habits and also entails regular proactive checking of password integrity by system administrators with complete support from the organization. The following steps should be used as guidelines for a good password policy:
    1. Assure that passwords are consistently strong. Given enough hardware resources and enough time, any password can be cracked using brute force guessing. Password crackers that are employed by attackers use what are known as dictionary-style attacks. Since common password encryption methods are widely known, the cracking utilities simply compare the encrypted form of a target password against the encrypted forms of all dictionary words (in many languages), along with proper names, and various common permutations of both. Therefore a password that in any way resembles a word (or words in almost any documented language) 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 (e.g., password) and converting letters to numbers or special characters (e.g., 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 a longer title of a book or song. By concatenating a longer phrase into a string (i.e., taking the first letter of each word in the phrase (preferably in mixed case), or substituting a special character for a word in the initial phrase, and/or replacing all the vowels in that concatenated phrase with various special characters, etc.), users can generate sufficiently long password strings which combine alphanumeric and special characters in a way that dictionary attacks will have greater difficulty cracking. And if the initial phrase is easy to remember, then the resulting password string should be as well.

      Once users are given the proper instructions for generating good passwords, detailed 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. Most flavors of UNIX/LINUX can use Npasswd as a front-end to check entered passwords against your password policy. PAM-enabled systems can also be extended to include cracklib (the libraries which accompany Crack) to check passwords as they are generated. Most new PAM-enabled systems can also be setup to refuse bad passwords that do not meet certain guidelines.

      However, if passwords cannot be verified against dictionary libraries when they are entered using tools such as Npasswd or PAM-enabled libraries, then cracking utilities should be run by the system administrator in a stand-alone mode as part of a regular proactive procedure. Tools like those used by potential attackers are generally the best choice. On a UNIX/LINUX-based platform, that would include Crack and John the Ripper.
       

      Please Note: Never run a password scanner, even on systems for which you have root-like access, without explicit and preferably written permission from your employer/organization. Administrators with the most benevolent of intentions have been fired for running password cracking tools without the authority to do so. This authority should be in the form of a written letter that forms part of the organizations strong password policy and allows for regular scheduled password checks.

      Once you have acquired authority to run cracking utilities on your system, do so regularly on a physically protected and secure machine. The tools on the machine should not be openly accessible to anyone but the authorized system administrator. Users whose passwords are cracked should be notified confidentially and given instructions on how to choose a better password. As part of the organizations password policy, both administrators and management should develop these notification procedures together, so that management can provide guidance and/or assistance when users do not respond to these notifications.

      Other possible options to protect against nonexistent or weak passwords and/or to maintain password policy procedures are (a) to use an alternative form of authentication such as password-generating tokens or biometrics. These are effective if you are having trouble with weak passwords and can be used as an alternative means of authenticating users. It should be noted that some password-generating tokens need procedures in place to ensure they are not openly accessible to unauthorized users and if stolen they are promptly denied from the system. Biometrics is a developing area and depending on the type of authentication (e.g., fingerprints versus facial recognition), some of the technology has not been perfected and errors in authentication may be common. (b) There are many comprehensive third party tools (free and commercial) available to help manage good password policy.

       

    2. Protect Strong Passwords. If you store password hashes in /etc/passwd, update your system to use /etc/shadow. If your system runs NIS or LDAP in such a way that hashes cannot be protected, anyone (even non-authenticated users) can read your password hashes and attempt cracking. You should look for more secure alternatives to the NIS and LDAP version you are running. Until those insecure applications can be secured/replaced, you should secure proper permission and run proactive cracking as a regular procedure against those applications as well. Consider using the MD5 algorithm to hash your passwords instead of crypt.

      However, even if passwords themselves are strong, accounts can be compromised if users do not protect their passwords. A good password policy should include detailed procedures for a user that require that a user should never tell his or her password to anyone else, never write a password down where it could be read by others, properly secure any files in which a password is stored for automate authentication, and if a password is known to be stolen or known by others, to promptly notify the system administrator. 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. Administrators should make sure that the users are given warning of a pending password change and several 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 if possible removed completely. Any service-based or administrative accounts which are used should be given new and strong passwords as soon as the service or account is installed or activated. Configure new user accounts with randomly-generated initial passwords, and force users to change them when they first log in. Audit the accounts on your systems on a regular and proactive basis, and maintain a master list of all of these accounts detailing the service requiring the account and the intended need. Develop stringent procedures for adding/removing authorized accounts to/from the list. Have rigid procedures for removing accounts when employees or contractors leave or when the accounts are no longer required. Validate the master list on a regular scheduled basis to make sure no new accounts have been added and that unused accounts have been removed. In addition, do not forget to check the accounts and passwords on supporting systems like routers, switches, and Internet-connected digital printers, copiers and printer controllers.
    back to top ^



     

    U5 Clear Text Services

    U5.1 Description of the Vulnerability
    Many network services utilized by UNIX systems are clear-text (also known as "plain text"). That means that there is no encryption used by those services. Lack of encryption allows everybody who is observing network traffic ("sniffing") to gain access to either communication contents and/or authentication credentials.

    For example, to steal the FTP or telnet login information, an attacker needs to place a network sniffer somewhere along the connection path, such as on the FTP server LAN or on the client LAN. The transmission of information between R-command clients and R-services in plain-text permits data or keystrokes to be intercepted as well. Attackers have often deployed sniffers in recent security incidents and often on compromised machines. Finding usernames and passwords in sniffed data is very easy.

    Here is a summary table of most common UNIX network services which are transmitted in clear text.

     
    Service Port Clear Content Clear Auth What is transferred

    FTP 21,20 y y Text, binary
    TFTP 69 y N/A Text, binary
    telnet 23 y y Text
    SMTP 25 y N/A Text, binary
    POP3 110 y y Text, binary
    IMAP 143 y y Text, binary
    rlogin 513 y y Text
    rsh 514 y y Text
    HTTP 80 y y Text, binary


    Services such as telnet and FTP where both contents and authentication credentials are transmitted in clear text present the highest risk, since attacker will be able to reuse the credentials and access the system at their leisure. Additionally, command session run in clear text may also be hijacked and used by the attacker to run commands without authentication.

    Here is the risk summary from clear text services:

     

    Activity possible Risk

    Sniffing the username Simplifies brute-forcing attacks
    Sniffing the password Gives remote access
    Sniffing FTP content File stealing
    Session hijacking Run commands on a target system
    HTTP session sniffing Discloses web authentication credentials


    U5.2 The Operating Systems Affected
    All UNIX flavors contain clear-text services (telnet and FTP being the most common). All UNIX/Linux flavors with the possible exception of the latest editions of Free/OpenBSD ship with some of the services enabled by default.

    U5.3 CVE/CAN Entries
    CVE-2000-0087

    CAN-2002-0322, CAN-2000-0086

    U5.4 How to Determine if you are Vulnerable
    The most effective and reliable way to determine whether clear text services are in use is to use a sniffer tool similar to those used by attackers.

    The most commonly used sniffer is "tcpdump" Run it as:

    # tcpdump -X -s 1600

    to detect any clear text communication. "Tcpdump" may be obtained at http://www.tcpdump.org.

    Another such tool is "ngrep" which allows one to look for specific patterns in network communication, such as "sername" or "assword" (the first letters are removed to accomodate for possible capitalization). Run the tool as:

    # ngrep assword

    "Ngrep" may be obtained at http://www.packetfactory.net/projects/ngrep/.

    There are also more sophisticated tools specifically designed to detect authentication credentials on the network. "Dsniff" is the most popular tool of that sort. Simply running:

    # /usr/sbin/dsniff

    will make the tool to detect and print all username-password pairs detected on the network in a large number of plain text protocols, such as FTP, telnet or POP3. Dsniff may be obtained at http://www.monkey.org/~dugsong/dsniff/.

    U5.5 How to Protect Against It
    Using end-to-end or at least link-level encryption will help. Some protocols have encrypted equivalents such as POP3S and HTTPS. For the protocols which do not have native encryption capabilities, one can tunnel them over SSH (Secure Shell) or SSL connection.

    As an example: FTP might be replaced with more secure software solutions such as SFTP or SCP (parts of the Secure Shell software package) and use a web server to distribute files to a wide audience.

    The most popular and flexible SSH implementation is OpenSSH (available at http://www.openssh.org). It runs on most UNIX variants and may be used for remote interactive sessions (replaces telnet, rlogin and rsh) and tunneling (of POP3, SMTP, X11 and many other protocols).

    Here is how one can tunnel POP3 over SSH connection. The POP3 server needs to be also running the SSH server. First run this on the client machine:

    # ssh -L 110:pop3.mail.server.com:110 username@pop3.mail.server.com

    Now, point your email client to localhost, TCP port 110 (unlike the usual 'pop3.mail.server.com', port 110). All communication between your machine and the POP3 mail server will be tunneled over SSH and thus encrypted.

    Another popular encrypted tunneling solution is "stunnel". It implements SSL protocol (via OpenSSL toolkit) and may be used to tunnel various plain text protocols. Stunnel may be obtained at http://www.stunnel.org/.

     

    back to top ^



     

    U6 Sendmail

    U6.1 Description
    Sendmail is the program that sends, receives, and forwards most electronic mail processed on UNIX and Linux systems. Sendmail is the most popular Mail Transfer Agent (MTA) and its widespread use on the Internet has historically made it a prime target of attackers, resulting in numerous exploits over the years.

    Most of these exploits are successful only against older or unpatched versions of the software. Despite the fact that the known vulnerabilities are well documented and have been repaired in newer releases, there remain so many outdated or misconfigured versions still in use today that Sendmail remains one of the most frequently attacked services. Among the most recent critical vulnerabilities are:
    • CERT Advisory CA-2003-12 Buffer Overflow in Sendmail
    • CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail
    • CERT Advisory CA-2003-25 Buffer Overflow in Sendmail

    CERT Advisory CA-2003-12 Buffer Overflow in Sendmail gives the following excellent description of a Sendmail buffer overflow and the danger it poses to network integrity.
     

    This vulnerability is message-oriented as opposed to connection-oriented. That means that the vulnerability is triggered by the contents of a specially-crafted email message rather than by lower-level network traffic. This is important because an MTA that does not contain the vulnerability will pass the malicious message along to other MTAs that may be protected at the network level. In other words, vulnerable sendmail servers on the interior of a network are still at risk, even if the site's border MTA uses software other than sendmail. Also, messages capable of exploiting this vulnerability may pass undetected through many common packet filters or firewalls.


    The risks presented by running Sendmail can be grouped into two major categories: privilege escalation caused by buffer overflows, and improper configuration that allows your machine to be a relay for electronic mail from any other machine. The former is a problem on any system still running older or unpatched versions of the software. The latter results from using either improper or default configuration files, and is a chief obstacle to fighting the proliferation of spam.

    U6.2 Operating Systems Affected
    Nearly all UNIX and Linux systems come with a version of Sendmail installed that is enabled and running by default.

    U6.3 CVE/CAN Entries
    CVE-1999-0047, CVE-1999-0095, CVE-1999-0096, CVE-1999-0129, CVE-1999-0131,
    CVE-1999-0203, CVE-1999-0204, CVE-1999-0206, CVE-1999-1109, CVE-2000-0319,
    CVE-2001-0653, CVE-2001-1349, CVE-2002-0906

    CAN-1999-0098, CAN-1999-0163, CAN-2001-0713, CAN-2001-0714, CAN-2001-0715,
    CAN-2002-1165, CAN-2002-1278, CAN-2002-1337, CAN-2003-0161, CAN-2003-0285

    U6.4 How to Determine if you are Vulnerable
    Sendmail has had a large number of vulnerabilities in the past. Do not always trust the version string returned by the daemon as that is just read from a text file on the system that may not have been updated properly.

    Any outdated or unpatched version of the software is likely to be vulnerable.

    To determine the version of Sendmail, use the following command:

    echo \$Z | /usr/lib/sendmail -bt -d0

    Depending on your system, the path to Sendmail may be different and you have to modify the above command accordingly to point to the right path.

    To determine whether the version you are running is current, check the current release of Sendmail version at:
    http://www.sendmail.org/current-release.html

    U6.5 How to Protect Against It
    The following steps should be taken to protect Sendmail:

    1. Upgrade to the latest version and/or implement patches. The source code can be found at http://www.sendmail.org/. If your version of Sendmail came packaged with your operating system, patches should be available at your operating system vendor's website (various vendor-specific information, including compile-time and configuration suggestions, is also available at http://www.sendmail.org).
    2. Sendmail is typically enabled by default on most UNIX and Linux systems, even those which are not acting as mail servers or mail relays. Do not run Sendmail in daemon mode (turn off the "-bd" switch) on these machines. You can still send email from this system by configuring it to point to a mail relay in the sendmail configuration file, sendmail.cf (which is typically located at /etc/mail/sendmail.cf).
    3. If you must run Sendmail in daemon mode, ensure that your configuration is designed to relay mail appropriately and only for systems under your purview. See http://www.sendmail.org/tips/relaying.html and http://www.sendmail.org/m4/anti_spam.html for assistance in properly configuring your server. Starting with Sendmail 8.9.0, open relaying was disabled by default. However, many operating system vendors re-enabled it in their default configurations. If you are using the version of Sendmail which shipped with your operating system, take special care to ensure that your server is not used for relaying.
    4. When you change to a new version of Sendmail, it is also recommended to change the configuration files that are provided with that version as older configurations may still allow relaying even when running the newest code. It is now possible to build a Sendmail configuration file (sendmail.cf) using the configuration files provided with the Sendmail release. Additional details on Sendmail configuration can be obtained at http://www.sendmail.org/m4/readme.html.
    5. When you download the Sendmail distribution you must verify the PGP signature to ensure it is an authentic copy. Do not use Sendmail without verifying the integrity of the source code. Trojan copies of Sendmail have existed in the past. Please read the CERT Advisory CA-2002-28 Trojan Horse Sendmail Distribution to learn more. Keys used to sign Sendmail distributions can be obtained at http://www.sendmail.org/ftp/PGPKEYS. In the absence of PGP, you should use the MD5 checksums to verify the integrity of the Sendmail source code distribution.
    6. Additional information on how to configure and run Sendmail in a more secure manner can be obtained at:
      http://www.sendmail.org/secure-install.html
      http://www.sendmail.org/m4/security_notes.html
      http://www.sendmail.org/~gshapiro/security.pdf
    back to top ^



     

    U7 Simple Network Management Protocol (SNMP)

    U7.1 Description
    The Simple Network Management Protocol (SNMP) is used extensively to remotely monitor and configure almost all types of modern TCP/IP-enabled devices. While SNMP is rather ubiquitous in its distribution across networking platforms, it is most often used as a method to configure and manage devices such as printers, routers, switches, access points, and to provide input for network monitoring services.

    Simple Network Management communication consists of different types of exchanged messages between SNMP management stations and network devices which run what is commonly referred to as agent software. The method by which these messages are handled and the authentication mechanism behind such message handling both have significant exploitable vulnerabilities.

    The vulnerabilities behind the method by which SNMP version 1 handles and traps messages are outlined in detail in CERT Advisory CA-2002-03. There exists a set of vulnerabilities in the way trap and request messages are handled and decoded by management stations and agents alike. These vulnerabilities are not restricted to any specific implementation of SNMP but instead affect a variety of vendors' SNMP distributions. The result of attackers exploiting these vulnerabilities may range anywhere from denial of service to unwanted configuration and management of your SNMP-enabled machinery.

    The inherent authentication mechanism of older SNMP frameworks also poses a significant vulnerability. SNMP versions 1 and 2 use an unencrypted "community string" as their only authentication mechanism. Lack of encryption is bad enough, but the default community string used by the vast majority of SNMP devices is "public," with a few supposedly clever network equipment vendors changing the string to "private" for more sensitive information. Attackers can use this vulnerability in SNMP to reconfigure or shut down devices remotely. Sniffed SNMP traffic can reveal a great deal about the structure of your network as well as the systems and devices attached to it. Intruders use such information to pick targets and plan attacks.

    Most vendors enable SNMP version 1 by default, and many do not offer products capable of using SNMP version 3's security models which can be configured to use improved authentication methods. However, there are freely-available replacements which do provide SNMPv3 support under GPL or BSD licenses.

    SNMP is not unique to UNIX; it is extensively used on Windows, in networking equipment, wireless access points and bridges, printers and embedded devices. But the majority of SNMP-related attacks seen thus far have occurred on UNIX systems with poor SNMP configurations.

    U7.2 Operating Systems Affected
    Nearly all UNIX and Linux systems come with SNMP installed, and often by default it is enabled. Most other SNMP-enabled network devices and operating systems are also vulnerable.

    U7.3 CVE/CAN Entries
    CVE-2001-0236, CVE-2002-0797

    CAN-1999-0186, CAN-1999-0254, CAN-1999-0516, CAN-1999-0517, CAN-1999-0615,
    CAN-2002-0012, CAN-2002-0013, CAN-2002-0796

    U7.4 How to Determine if you are Vulnerable
    You can verify whether SNMP is running on network-connected devices by running a scanner or checking manually.
    SNMPing - You can obtain the free SNMPing scanning tool from the SANS Institute by emailing a blank mail message to snmptool@sans.org. You will get a return message with the URL where you can download the tool.
    SNScan - Foundstone created another easy-to-use SNMP scanning tool called SNScan, which can be obtained at http://www.foundstone.com/knowledge/free_tools.html.

    If you cannot use any of the above tools, you should manually verify if SNMP is running on your systems. Refer to your operating system documentation on how to specifically identify its particular SNMP implementation, but the basic daemon can usually be identified by grepping for "snmp" in the process list or by looking for services running on ports 161 or 162.

    A running SNMP instance is probably sufficient evidence that you are vulnerable to pervasive trap and request handling errors. Please see CERT Advisory CA-2002-03 for additional information.

    If SNMP is running and any of these additional variables are met, you may have a default or easily guessable string-related vulnerability:
    1. Blank or default SNMP community names.
    2. Guessable SNMP community names.
    3. Hidden SNMP community strings.

    Please see http://www.sans.org/resources/idfaq/snmp.php for information on how to identify the presence of those conditions.

    U7.5 How to Protect Against It
    Trap and Request Handling Vulnerabilities:

    1. If you do not absolutely require SNMP, disable it.
    2. Wherever possible, employ an SNMPv3 user-based security model with message authentication and possibly encryption of the protocol data unit.
    3. If you must use SNMPv1 or v2, make sure you are running the latest patched version from your vendor. A good starting point in obtaining vendor specific information is Appendix A of CERT Advisory CA-2002-03.
    4. Filter SNMP (port 161 TCP/UDP and 162 TCP/UDP) at the ingress points to your networks unless it is absolutely necessary to poll or manage devices externally.
    5. Employ host-based access control on your SNMP agent systems. While this capability may be limited by SNMP agent operating system capabilities, control of what systems your agents will accept requests from may be possible. On most UNIX systems this can be accomplished through a TCP-Wrappers or Xinetd configuration. An agent-based packet filtering firewall on the host can also be used to block unwanted SNMP requests.

    Default and Guessable String-Related Vulnerabilities:

    1. If you do not absolutely require SNMP, disable it.
    2. Wherever possible, employ an SNMPv3 user-based security model with message authentication and possibly encryption of the protocol data unit.
    3. If you must use SNMPv1 or v2, use the same policy for community names as used for passwords. Make sure they are difficult to guess or crack and they are changed periodically.
    4. Validate and check community names using snmpwalk. Additional information can be found at http://www.zend.com/manual/function.snmpwalk.php. A good tutorial on this tool can be found at http://www.sans.org/resources/idfaq/snmp.php.
    5. Filter SNMP (port 161 TCP/UDP and 162 TCP/UDP) at the ingress points to your networks unless it is absolutely necessary to poll or manage devices externally. Then, if possible, configure filtering to only permit SNMP traffic between trusted subnets.
    6. Where possible make MIBs read-only. Additional information can be found at http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/snmp.htm#xtocid210315.
    back to top ^



     

    U8 Secure Shell (SSH)

    U8.1 Description
    Secure shell (SSH) is a popular service for securing logins, command execution, and file transfers across a network. Most UNIX-based systems use either the open-source OpenSSH package or the commercial version from SSH Communication Security. Although SSH is vastly more secure than the telnet, ftp, and R-command programs it is intended to replace, there have been multiple flaws found in both implementations. Most are minor bugs, but a few are major security issues that should be repaired immediately. The most dangerous of these actively exploited holes allows attackers to remotely obtain root access on a vulnerable machine.

    It should also be noted that there is a growing use of SSH clients and servers in the Windows environment and that most of the information in this section applies to both the *nix and Windows implementations of SSH.

    While SSH is presented here as one of the Top 20 vulnerabilities, it is more the case that the mismanagement of SSH, specifically misconfiguration and the failure to apply updates and patches in a timely manner, account for its inclusion in this list.

    SSH2 is actually a powerful tool that when properly configured and maintained can help remediate many of the other top 20 vulnerabilities, specifically those that send material in clear text across untrusted networks like the Internet. Many of the vulnerabilities found in protocols such as POP3, FTP (replace with SSH2s SFTP), Telnet, HTTP, and the rhost based tools (rlogin, rcp, and rsh) involve eavesdropping on clear text transmissions or manipulating client server sessions. This makes encryption and authentication key management provided by SSH2 along with its ability to forward or redirect sessions, an attractive VPN type of wrapper for otherwise vulnerable traffic.

    The SSH1 protocol itself has been demonstrated to be potentially vulnerable to having a session decrypted in transit given certain configurations. For this reason, administrators are encouraged to use the stronger SSH2 protocol whenever possible.
     

    Note: SSH1 and SSH2 are not compatible. With only a few exceptions, the version of SSH on both the client and the server must match.


    In addition, users of OpenSSH should note that the OpenSSL libraries against which OpenSSH is typically built have software vulnerabilities of their own. Please see CERT Advisory 2002-23 for more details. They should also be aware that a trojan-horse version of the OpenSSH was being distributed for a short time in the summer of 2002 (CAN-1999-0661). Please see http://www.openssh.org/txt/trojan.adv for details about ensuring that your version is not affected.

    U8.2 Operating Systems Affected
    Any UNIX or Linux system running OpenSSH 3.3 or earlier (version 3.6.1 was released on April 1, 2003), or SSH Communication Security's SSH 3.0.0 or earlier (3.2.5 was released on June 30, 2003).

    U8.3 CVE/CAN Entries
    For SSH from SSH Communications Security:
    CVE-2000-0217, CVE-2000-0575, CVE-2000-0992, CVE-2001-0259, CVE-2001-0361,
    CAN-2001-0471, CVE-2001-0553

    For SSH from OpenSSH:
    CVE-2000-0525, CVE-2000-1169, CVE-2001-0060, CVE-2001-0144, CVE-2001-0361,
    CVE-2001-0872, CVE-2002-0002, CVE-2002-0083

    CAN-2001-1380, CAN-2002-0575, CAN-2002-0639, CAN-2002-0640, CAN-2002-0765,
    CAN-2003-0386

    Multiple implementations of SSH:
    CAN-2002-1357, CAN-2002-1358, CAN-2002-1359, CAN-2002-1360

    U8.4 How to Determine if you are Vulnerable
    Use a vulnerability scanner to see whether you are running a vulnerable version, or check the software version reported by running the command 'ssh -V'.

    The ScanSSH tool is particularly useful for remotely identifying SSH servers that are dangerously un-patched. The ScanSSH command line tool scans a list of addresses and networks for SSH protocol servers and reports their version numbers. Written by Niels Provos and released under the BSD-license, the latest version was released on 2001-11-30 and is available at http://www.monkey.org/~provos/scanssh/.

    U8.5 How to Protect Against It

    1. Upgrade to the most recent version of either OpenSSH or SSH. Or if SSH or OpenSSH came installed with your operating system, retrieve the latest patches from your operating system vendor. If you use OpenSSL, be sure to use the latest version of those libraries.
    2. Where possible, upgrade from SSH1 to SSH2. SSH1 does not appear to be under further development, while SSH2 is in active development. Where migration is not possible, begin developing plans and strategies that will make migration to SSH2 possible.
    3. Both the SSH implementations include a variety of configuration options to restrict what machines can connect, what users are allowed to authenticate, and via what mechanisms. Administrators should determine how these options could most appropriately be set for their environment.
    4. Verify that each SSH client is not configured to revert back to the rsh program when connecting to a server that does not support SSH. The FallBackToRsh key should be set to No in the SSH configuration file.
    5. Specify the use of blowfish encryption rather than the 3DES, which may be the default of the version. This will provide faster operation without reducing the effective encryption strength.
    6. A host providing SSH services must itself be adequately protected otherwise vulnerabilities that allow the host to be compromised put the SSH service at risk.

    U9 Misconfiguration of Enterprise Services NIS/NFS

    U9.1 Description
    The Network File System (NFS) and Network Information Service (NIS) are two important services used in UNIX networks. NFS is a service originally created by Sun Microsystems that is designed to share files among UNIX systems over a network. NIS is also a set of services that works as a database service to provide location information, called Maps, to other network services such as NFS. The most common examples of these Maps are the passwd and group files which are used to centralize user authentication.

    The security problems with both services, represented by the continuous issues discovered over the years (buffer overflows, DoS and weak authentication), made them a frequent target of attack.

    Besides the unpatched services that are still widely deployed, the higher risks may be represented by the misconfiguration of NFS and NIS that will easily allow security holes to be exploited and accessed by users locally or remotely.

    The lax authentication offered by NIS while querying NIS maps allow users to use applications like ypcat that can display the values of NIS database, or map, to retrieve the password file. The same kind of problem occurs with NFS which implicitly trusts the UID (user ID) and GIDs (group ID) that the NFS client presents to the server, and depending on the server configuration, this may allow any user to mount and explore the remote file system.

    U9.2 Operating Systems Affected
    Nearly all UNIX and Linux systems come with a version of NFS and NIS installed and often enabled by default.

    U9.3 CVE/CAN Entries
    NFS
    CVE-1999-0002, CVE-1999-0166, CVE-1999-0167, CVE-1999-0170, CVE-1999-0211,
    CVE-1999-0832, CVE-1999-1021, CVE-2000-0344

    CAN-1999-0165, CAN-1999-0169, CAN-2000-0800, CAN-2002-0830, CAN-2002-1228,
    CAN-2003-0252, CAN-2003-0379, CAN-2003-0576

    NIS
    CVE-1999-0008, CVE-1999-0208, CVE-1999-0245, CVE-2000-1040

    CAN-1999-0795, CAN-2002-1232, CAN-2003-0176, CAN-2003-0251

    U9.4 How to Determine if you are Vulnerable
    The following steps are related to NIS/NFS software vulnerabilities:
    1. Verify that you are current with the patches released by your vendor. For most versions the command rpc.mountd -version for NFS and ypserv -version for NIS will show the version of both. Any unpatched or outdated version of the software is likely to be vulnerable.
    2. For software vulnerabilities, a more complete approach would be to use an updated vulnerability scanner to periodically check your system against new flaws.

    The following steps are related to NIS configuration:

    1. Ensure that Root password is not maintained in an NIS map.
    2. Check if the users passwords are in accord with the security practices. A password cracker can be used to accomplish this.

      Please Note: Never run a password cracker, even on systems for which you have root-like 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 following steps are related to NFS configuration:

    1. Verify if the hosts, netgroups and permissions in the /etc/exports file is up-to-date.
    2. Run the command showmount e to see what has been exported. Check to see if your mounts are in compliance with your security policy.


    U9.5 How to Protect Against It
    The following steps are related to NIS configuration:

    1. In each client you can explicitly list the NIS servers to bind to, preventing another systems from masquerading as a NIS server.
    2. While making the DBM files, activate the YP_SECURE feature to ensure that the server will only answer requests from a client on privileged ports. This can be accomplished by using the switch s with the command makedbm.
    3. Include the trusted hosts and networks in the /var/yp/securenets used by the ypserv and the ypxfrd processes, and remember to restart the daemons to get the changes to take effect.
    4. On your NFS Clients be sure to have the entry +:*:0:0::: in your password map.

    The following steps are related to NFS configuration:

    1. Use numeric IP addresses or fully qualified domain names instead of aliases when allowing clients in the /etc/exports file.
    2. A tool called NFSBug can be used to test the configuration. The tests will include finding world exported file systems, determining whether export restrictions work, determining whether file systems can be mounted through the portmapper, trying to guess file handles, and exercising various bugs to access file systems. ftp://coast.cs.purdue.edu/pub/tools/unix/nfsbug/
    3. Use the /etc/exports file to restrict access to NFS file system by adding parameters:
      • Prevent normal users from mounting an NFS file system by adding a secure parameter after the IP address or domain name of your NFS client. (e.g.: /home 10.20.1.25(secure) )
      • Export the NFS file system with appropriate permissions. This could be done by adding the appropriate permission (ro for Read-only or rw for Read-Write) after the IP address or domain name of your NFS client in the /etc/exports file. (e.g.: /home 10.20.1.25(ro) )
      • If possible, use the parameter root_squash after the IP address or domain name of your NFS client. If this parameter is enabled, the superuser ID root on NFS Client will be replaced by the user ID nobody in the NFS Server. This means that the root user on the client can't access or change files that only root on the server can access or change, preventing it from gaining superuser privileges in the server. (e.g.: /home 10.20.1.25(root_squash) )
      • A complete set of parameters can be found in the /etc/exports manpage. http://www.netadmintools.com/html/5exports.man.html
    4. On Solaris O.S. make sure to activate the Port Monitoring feature. This can be done by adding the line set nfssrv:nfs_portmon = 1 on the /etc/system file.

      A Linux system by default denies cooperation with NFS clients using a non-privileged port.

    General considerations related to NIS and NFS:

    1. Review your firewall policies and be sure to block all unnecessary ports, as well Port 111 (Portmap) and Port 2049 (Rpc.nfsd). Also allow access to the NIS and NFS servers only from authorized clients. A local measure can also be applied by restricting access through tcp_wrappers located at http://sunsite.cnlab-switch.ch/ftp/software/security/security-porcupine.org/. In your etc/hosts.allow file you should state the service and IP allowed to access the service (e.g. portmap: 10.20.1.1/16 to allow the network 10.20.0.0 to access the portmap service). Also, in the /etc/hosts.deny file, you should include the services and the IPs that are NOT allowed to access the services (e.g.: portmap: ALL, which will deny access to all other IP addresses that are not included in the /etc/hosts.allow). The Portmap service is an important service to have the access denied because it is the one that the NFS operates though.
    2. Consider the use of NFS over a secure protocol like SSH. A good start point is http://www.math.ualberta.ca/imaging/snfs/.
    3. Apply all vendor patches or upgrade your NIS and NFS Servers to the latest version. For more information about hardening your UNIX installation, see the CERTs UNIX Security Checklist.
    4. Disable the NFS and NIS daemons on any system that is not specifically designated and authorized to be a NFS and/or NIS server. To prevent this change from being reversed, it may be wise to also remove the NFS and/or NIS software.
    back to top ^



     

    U10 Open Secure Sockets Layer (SSL)

    U10.1 Description
    The open-source OpenSSL library is a popular package to add cryptographic security to applications that communicate over the network. Although Apache is probably the most well-known use of the package (to support https: connections on port 443), many other programs have been modified to use OpenSSL for security.

    The usual usage of OpenSSL is a toolkit where other applications use OpenSSL to provide cryptographic security for a connection. As a result, rather than targeting OpenSSL directly, the exploits for the vulnerabilities will target the application using it. One popular exploit attacks the Apache server's use of OpenSSL. Just because you are not running Apache with OpenSSL support does not mean you are safe. A suitable modification of the exploit may be able to attack Sendmail, openldap, CUPS, or any other OpenSSL using program installed on the target machine.

    Multiple vulnerabilities have been found in OpenSSL, of which the most serious are the set of 4 vulnerabilities listed in CAN-2002-0655, CAN-2002-0656, CAN-2002-0557, and CAN-2002-0659. These allow the remote execution of arbitrary code as the user of the OpenSSL libraries (which in some cases, such as 'sendmail', is the 'root' user).

    U10.2 Operating Systems Affected
    Any UNIX or Linux system running OpenSSL 0.9.7 or earlier. Note that quite often, OpenSSL is installed to support some other component. For instance, on a RedHat Linux 9.0 system packages such as Apache, CUPS, Curl, OpenLDAP, Stunnel, and Sendmail (among others) all use the OpenSSL libraries to secure connections.

    U10.3 CVE/CAN Entries
    CVE-1999-0428, CVE-2001-1141

    CAN-2000-0535, CAN-2002-0655, CAN-2002-0656, CAN-2002-0557, CAN-2002-0659,
    CAN-2003-0078, CAN-2003-0131, CAN-2003-0147

    U10.4 How to Determine if you are Vulnerable
    Check the output of the command 'openssl version'. If the version isn't 0.9.7a or later, you are vulnerable.

    U10.5 How to Protect Against It
    1. Upgrade to the most recent version of OpenSSL. If OpenSSL came installed with your operating system, retrieve the latest patches from your operating system vendor. Note that in some cases, re-compiling and/or re-linking of applications may be required to enable the updated libraries.
    2. If feasible for your environment, consider the use of ipfilter or other firewalling tools to restrict what systems can connect to the OpenSSL server. Note that one of the most common usages of OpenSSL is for securing HTTP traffic over the public Internet for e-commerce where restricting hosts is probably not feasible.
    back to top ^



     

    Appendix A Common Vulnerable Ports

    In this section, we list ports that are commonly probed and attacked. Blocking these ports is a minimum requirement for perimeter security, not a comprehensive firewall specification list. A far better approach is to block all unused ports, i.e. deny all traffic, then permit specific protocols (those for which you have a business requirement) to enter your network perimeter. Even if you believe these ports are blocked, you should still actively monitor them to detect intrusion attempts. A warning is also in order: blocking some of the ports in the following list may disable needed services. Please consider the potential effects of these recommendations before implementing them.

    Note: It is also important to illustrate that it is a commonly held belief that exercising a default deny or block that which is not explicitly allowed stance on firewall configurations is a far more effective security practice than blocking specific ports. This approach is also easier on router and firewall administrators in that their configurations and control lists tend to be shorter, more logical, and easier to maintain.

    Keep in mind that blocking these ports is not a substitute for comprehensive security policies and design. Even if the ports are blocked, an attacker who has gained access to your network via other means (a dial-up modem, a trojan e-mail attachment, attack by a user behind the filter point, or a compromised machine, for example) can exploit these ports if not properly secured on every host system in your organization.

     


    Name Port Protocol Description
    Small services <20 tcp/udp small services
    FTP 21 tcp file transfer
    SSH 22 tcp login service
    TELNET 23 tcp login service
    SMTP 25 tcp mail
    TIME 37 tcp/udp time synchronization
    WINS 42 tcp/udp WINS replication
    DNS 53 udp naming services
    DNS zone transfers 53 tcp naming services
    DHCP server 67 tcp/udp host configuration
    DHCP client 68 tcp/udp host configuration
    TFTP 69 udp miscellaneous
    GOPHER 70 tcp old WWW-like service
    FINGER 79 tcp miscellaneous
    HTTP 80 tcp web
    alternate HTTP port 81 tcp web
    alternate HTTP port 88 tcp web (sometimes Kerberos)
    LINUXCONF 98 tcp host configuration
    POP2 109 tcp mail
    POP3 110 tcp mail
    PORTMAP/RPCBIND 111 tcp/udp RPC portmapper
    NNTP 119 tcp network news service
    NTP 123 udp time synchronization
    NetBIOS 135 tcp/udp DCE-RPC endpoint mapper
    NetBIOS 137 udp NetBIOS name service
    NetBIOS 138 udp NetBIOS datagram service
    NetBIOS/SAMBA 139 tcp file sharing & login service
    IMAP 143 tcp mail
    SNMP 161 tcp/udp miscellaneous
    SNMP 162 tcp/udp miscellaneous
    XDMCP 177 udp X display manager protocol
    BGP 179 tcp miscellaneous
    FW1-secureremote 256 tcp CheckPoint FireWall-1 mgmt
    FW1-secureremote 264 tcp CheckPoint FireWall-1 mgmt
    LDAP 389 tcp/udp naming services
    HTTPS 443 tcp web
    Windows 2000 NetBIOS 445 tcp/udp SMB over IP (Microsoft-DS)
    ISAKMP 500 udp IPSEC Internet Key Exchange
    REXEC 512 tcp } the three
    RLOGIN 513 tcp } Berkeley r-services
    RSHELL 514 tcp } (used for remote login)
    RWHO 513 udp miscellaneous
    SYSLOG 514 udp miscellaneous
    LPD 515 tcp remote printing
    TALK 517 udp miscellaneous
    RIP 520 udp routing protocol
    UUCP 540 tcp/udp file transfer
    HTTP RPC-EPMAP 593 tcp HTTP DCE-RPC endpoint mapper
    IPP 631 tcp remote printing
    LDAP over SSL 636 tcp LDAP over SSL
    Sun Mgmt Console 898 tcp remote administration
    SAMBA-SWAT 901 tcp remote administration
    Windows RPC programs 1025 tcp/udp } often allocated
    Windows RPC programs to   } by DCE-RPC portmapper
    Windows RPC programs 1039 tcp/udp } on Windows hosts
    SOCKS 1080 tcp miscellaneous
    LotusNotes 1352 tcp database/groupware
    MS-SQL-S 1433 tcp database
    MS-SQL-M 1434 udp database
    CITRIX 1494 tcp remote graphical display
    WINS replication 1512 tcp/udp WINS replication
    ORACLE 1521 tcp database
    NFS 2049 tcp/udp NFS file sharing
    COMPAQDIAG 2301 tcp Compaq remote administration
    COMPAQDIAG 2381 tcp Compaq remote administration
    CVS 2401 tcp collaborative file sharing
    SQUID 3128 tcp web cache
    Global catalog LDAP 3268 tcp Global catalog LDAP
    Global catalog LDAP SSL 3269 tcp Global catalog LDAP SSL
    MYSQL 3306 tcp database
    Microsoft Term. Svc. 3389 tcp remote graphical display
    LOCKD 4045 tcp/udp NFS file sharing
    Sun Mgmt Console 5987 tcp remote administration
    PCANYWHERE 5631 tcp remote administration
    PCANYWHERE 5632 tcp/udp remote administration
    VNC 5800 tcp remote administration
    VNC 5900 tcp remote administration
    X11 6000-6255 tcp X Windows server
    FONT-SERVICE 7100 tcp X Windows font service
    alternate HTTP port 8000 tcp web
    alternate HTTP port 8001 tcp web
    alternate HTTP port 8002 tcp web
    alternate HTTP port 8080 tcp web
    alternate HTTP port 8081 tcp web
    alternate HTTP port 8888 tcp web
    Unix RPC programs 32770 tcp/udp } often allocated
    Unix RPC programs to   } by RPC portmapper
    Unix RPC programs 32899 tcp/udp } on Solaris hosts
    COMPAQDIAG 49400 tcp Compaq remote administration
    COMPAQDIAG 49401 tcp Compaq remote administration
    PCANYWHERE 65301 tcp remote administration

    ICMP: block incoming echo request (ping and Windows traceroute), block outgoing echo replies, time exceeded, and destination unreachable messages except "packet too big" messages (type 3, code 4). (This item assumes that you are willing to forego the legitimate uses of ICMP echo request in order to block some known malicious uses.)

    In addition to these ports, block spoofed addresses: packets coming from outside your company sourced from internal addresses, private addresses (RFC1918) and IANA reserved addresses (for details, see http://www.iana.org/assignments/ipv4-address-space). It is also suggested that you block packets bound for broadcast or multicast addresses. Specifically blocking source routed packets or any packets with IP options set will be advantageous as well.

    You should also apply egress filters on your border routers to block spoofed packets from originating from your network. Only allow packets sourced from your assigned addresses to be routed out of your organization.

    Trademark Acknowledgment: SANS Institute recognizes the importance of intellectual property, trademark, copyright, servicemark, and patent and is striving to recognize such standards in this document. The following products, systems, or applications are recognized as trademarked names. If you feel that we have overlooked any trademarked products, please email top20@sans.org with your comments and observations and we will be sure to update the document as necessary.

    Microsoft, Windows, Windows Server 2003, Microsoft SQL Server, Microsoft Outlook are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries.

    Sendmail, is a trademark or registered trademark of Sendmail, Inc. in the United States and/or other countries.

    SSH is a trademark or registered trademark of SSH Communication Security in the United States and/or other countries.

    CERT Coordination Center is a trademark or registered trademark of Carnegie Mellon; Software Engineering Institute in the United States and/or other countries.

    UNIX is a trademark or registered trademark of The Open Group in the United States and/or other countries.

    back to top ^



     

    Appendix B
    The Experts Who Helped Create The Top Twenty Vulnerable Service Lists for 2003
    Adair Collins, US Department of Energy
    Alan Paller, SANS Institute
    Alex Lucas, United Kingdom National Infrastructure Security Co-ordination Center
    Alexander Kotkov, CCH Legal Information Services
    Anton Chuvakin, Ph.D., netForensics
    BJ Bellamy, Kentucky Auditor of Public Accounts
    Bradley Peterson, US Department of Energy
    Cathy Booth, United Kingdom National Infrastructure Security Co-ordination Center - Incident Response CESG
    Chris Benjes, National Security Agency
    Christopher Misra, University of Massachusetts Amherst
    Dave Dobrotka, Ernst & Young
    Dominic Beecher, United Kingdom National Infrastructure Security Co-ordination
    Ed Fisher, CableJiggler Consulting, LLC
    Edward Skoudis, International Network Services
    Edward W. Ray, MMICMAN LLC
    Erik Kamerling, Pragmeta Networks/SANS Institute - Editor
    Gerhard Eschelbeck, Qualys
    Jeff Campione, Editor 2002
    Jeff Ito, Indus Corporation
    Jeni Li, Arizona State University
    Kevin Thacker, United Kingdom National Infrastructure Security Co-ordination
    Koon Yaw Tan, Infocomm Development Authority of Singapore (IDA)
    Pedro Paulo Ferreira Bueno, MetroRED Telecom, Brazil
    Pete Beck, United Kingdom National Infrastructure Security Co-ordination
    Richard (Rick) Wanner, InfoSec Centre of Expertise (COE) CGI Information Systems & Management Consultants Inc.
    Roland M Lascola, U.S. Dept. of Energy - Office of Independent Oversight and Performance Assurance
    Ross Patel, Afentis Security
    Russell Morrison, AXYS Environmental Consulting Ltd.
    Scott A. Lawler, CISSP, Veridian Information Solutions
    Stephen Northcutt, SANS Institute
    Valdis Kletnieks, Virginia Tech
    William Eckroade, U.S. Dept. of Energy

     
    Thanks also to the following list of people for their excellent work in helping to edit, format and produce the 2003 list.
    Audrey (Dalas) Bines, SANS Institute
    Brian Corcoran, SANS Institute
    Cara L. Mueller, SANS Institute

     
    The Top 20 team would also like to thank the following SANS Alumni who donated their time to review and comment on the 2003 draft.
    Paul Graham, CIT at the University at Buffalo (UB)
    Jerry Berkman, UC Berkeley
    Neil W Rickert, Northern Illinois University
    Travis Hildebrand, US Department of Veteran Affairs
    Christoph Gruber, WAVE Solutions
    Mark Worthington, Affiliated Computer Services (ACS), Riverside Public Library
    Matthew Nehawandian, CISSP

     
    The Experts Who Helped Create The Top Twenty Vulnerable Service Lists for 2002
    Jeff Campione, Federal Reserve Board - Editor
    Eric Cole, Editor, 2001 Edition
    Ryan C. Barnett, Department of the Treasury/ATF
    Chris Benjes, National Security Agency
    Matt Bishop, University of California, Davis
    Chris Brenton, SANS Institute
    Pedro Paulo Ferreira Bueno, Open Communications Security, Brazil
    Anton Chuvakin, Ph.D., netForensics
    Rob Clyde, Symantec
    Dr. Fred Cohen, Sandia National Laboratories
    Gerhard Eschelbeck, Qualys
    Dan Ingevaldson, Internet Security Systems
    Erik Kamerling, Pragmeta Networks
    Gary Kessler, Gary Kessler Associates
    Valdis Kletnieks, Virginia Tech CIRT
    Alexander Kotkov - CCH Legal Information Services
    Jamie Lau, Internet Security Systems
    Scott Lawler, Veridias Information Solutions
    Jeni Li, Arizona State University
    Nick Main, Cerberus IT, Australia
    Jose Marquez, Alutiiq Security and Technology
    Christopher Misra, University of Massachusetts
    Stephen Northcutt, SANS Institute
    Craig Ozancin, Symantec
    Alan Paller, SANS Institute
    Ross Patel, Afentis, UK
    Marcus Ranum, ranum.com
    Ed Ray - MMICMAN LLC
    Chris Rouland, Internet Security Systems
    Bruce Schneier, Counterpane Internet Security Inc.
    Greg Shipley, Neohapsis
    Ed Skoudis, Predictive Systems
    Gene Spafford, Purdue University CERIAS
    Koon Yaw Tan, Infocomm Development Authority of Singapore
    Mike Torregrossa, University of Arizona
    Viriya Upatising, Loxley Information Services, Thailand
    Rick Wanner, CGI Information Systems and Management Consultants

     
    People who helped prioritize the individual CVE entries to help define the tests to be used in the Top 20 scanners for 2002. For details on the process used, see www.sans.org/top20/testing.pdf
    Charles Ajani, Standard Chartered Bank, London, UK
    Steven Anderson, Computer Sciences Corporation, North Kingstown RI
    John Benninghoff, RBC Dain Rauscher, Minneapolis MN
    Layne Bro, BEA Systems, Denver CO
    Thomas Buehlmann, Phoenix AZ
    Ed Chan, NASA Ames Research Center, San Jose CA
    Andrew Clarke, Computer Solutions, White Plains NY
    Brian Coogan, ManageSoft, Melbourne Australia
    Paul Docherty, Portcullis Computer Security Limited,UK
    Arian Evans, U.S. Central Credit Union, Overland Park KS
    Rich Fuchs, Research Libraries Group, Mountain View CA
    Mark Gibbons, International Network Services, Minneapolis MN
    Dan Goldberg, Rochester NY
    Shan Hemphill, Sacramento CA
    Michael Hensing, Charlotte, NC, Microsoft
    Simon Horn, Brisbane Australia
    Bruce Howard, Kanwal Computing Solutions, Jilliby NSW Australia
    Tyler Hudak, Akron OH
    Delbert Hundley, MPRI Division of L-3COM, Norfolk VA
    Chyuan-Horng Jang, Oak Brook IL
    Kim Kelly, The George Washington University, Washington DC
    Martin Khoo, Singapore Computer Emergency Response Team (SingCERT), Singapore
    Susan Koski, Pittsburgh PA
    Kevin Liston, AT&T, Columbus OH
    Andre Marien, Ubizen, Belgium
    Fran McGowran, Deloitte & Touche, Dublin, Ireland, UK
    Derek Milroy, Zurich North America, Chicago IL
    Bruce Moore, Canadian Forces Network Operations Center, DND, Ottawa Canada
    Castor Morales, Ft. Lauderdale FL
    Luis Perez, Boston MA
    Reg Quinton, University of Waterloo, Ontario Canada
    Bartek Raszczyk, UWM Olsztyn, Olsztyn Poland
    Teppo Rissanen, Plasec Oy, Helsinki Finland
    Alan Rouse, N2 Broadband, Duluth GA
    Denis Sanche, PWGSC ITSD/IPC, Hull, QC Canada
    Felix Schallock, Ernst & Young, Vienna, Austria
    Gaston Sloover, Fidelitas, Buenos Aires Argentina
    Arthur Spencer, UMASS Medical School, Worcester MA
    Rick Squires
    Jeff Stehlin, HP
    Koon Yaw TAN, Infocomm Development Authority of Singapore, Singapore
    Steven Weil, Seitel Leeds & Associates, Seattle WA
    Lance Wilson, Time Warner Cable/Broadband IS, Orlando FL
    Andrew Wortman, Naval Research Laboratory, Washington DC
    Carlos Zottman, Superior Tribunal de Justica, Brasilia Brazil

     
    Additional security experts who helped with the 2001 Top Twenty and 2000 Top Ten lists which provided the foundation on which the 2002 Top Twenty is built
    Billy Austin, Intrusion.com
    Phil Benchoff, Virginia Tech CIRT
    Tina Bird, Counterpane Internet Security Inc.
    Lee Brotzman, NASIRC Allied Technology Group Inc.
    Mary Chaddock
    Steve Christey, MITRE
    Scott Conti, University of Massachusetts
    Kelly Cooper, Genuity
    Scott Craig, KMart
    Sten Drescher, Tivoli Systems
    Kathy Fithen, CERT Coordination Center
    Nick FitzGerald, Computer Virus Consulting Ltd.
    Igor Gashinsky, NetSec Inc.
    Bill Hancock, Exodus Communications
    Robert Harris, EDS
    Shawn Hernan, CERT Coordination Center
    Bill Hill, MITRE
    Ron Jarrell, Virginia Tech CIRT
    Jesper Johansson, Boston University
    Christopher Klaus, Internet Security Systems
    Clint Kreitner, Center for Internet Security
    Jimmy Kuo, Network Associates Inc.
    Jim Magdych, Network Associates Inc.
    Dave Mann, BindView
    Randy Marchany, Virginia Tech
    Mark Martinec "Jozef Stefan" Institute
    William McConnell, Trend Consulting Services
    Peter Mell, National Institutes of Standards and Technology
    Larry Merritt, National Security Agency
    Mudge, @stake
    Tim Mullen, AnchorIS.com
    Ron Nguyen, Ernst & Young
    David Nolan, Arch Paging
    Hal Pomeranz, Deer Run Associates
    Chris Prosise, Foundstone Inc.
    Jim Ransome
    RAZOR Research - BindView Development
    Martin Roesch, Snort
    Vince Rowe, FBI, NIPC
    Marcus Sachs, JTF-CNO US Department of Defense
    Tony Sager, National Security Agency
    Gene Schultz, Lawrence Berkeley Laboratory
    Eric Schultze, Foundstone
    Derek Simmel, Carnegie Mellon University
    Ed Skoudis, Predictive Systems
    Lance Spitzner, Sun Microsystems, GESS Team
    Wayne Stenson, Honeywell
    Jeff Stutzman
    Frank Swift
    Bob Todd, Advanced Research Corporation
    Jeff Tricoli, FBI NIPC
    Laurie Zirkle, Virginia Tech CIRT
     
    back to top ^