The Twenty Most Critical Internet Security Threats (Updated)

The Experts’ Consensus
Version 2.6 September, 2001
Copyright 2001, The SANS Institute

Stop the Break-Ins, Continued!

A little over a year ago, SANS , with the help of the FBI’s National Infrastructure Protection Center (NIPC), released a document summarizing the Ten Most Critical Internet Security Threats. Thousands of organizations used that list to prioritize their efforts so they could close the most dangerous holes first. In response to increasingly urgent requests for an expansion of the list, SANS and the NIPC are releasing this updated and expanded version. With this version the list has been segmented into three categories: General Threats, Windows Threats and Unix Threats

The general philosophy for the Top Twenty has not changed. The majority of successful attacks on computer systems via the Internet can be traced to exploitation of one of a small number of security flaws. Most of the systems compromised in the Solar Sunrise Pentagon hacking incident were attacked through a single vulnerability. A related flaw was exploited to break into many of the computers later used in massive distributed denial of service attacks. Recent compromises of Windows web servers are typically traced to entry via a well-known vulnerability. Another vulnerability is widely thought to be the means used to compromise more than 30,000 Linux systems. Code Red compromised more than 150,000 systems using a single vulnerability path.

These few software vulnerabilities account for the majority of successful attacks because attackers are opportunistic – taking the easiest and most convenient route. They 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, by scanning the Internet for vulnerable systems.

System administrators report that they have not corrected these flaws because they simply do not know which of over 500 potential problems are the ones that are most dangerous, and they are too busy to correct them all. The Top Twenty list is designed to correct that problem by combining the information from dozens of leading security experts to identify the most critical Internet security problem areas – the clusters of vulnerabilities that system administrators need to eliminate immediately. This consensus Updated Top Twenty list represents another example of active cooperation among industry, government, and academia. The participants came together from the most security-conscious federal agencies, from the leading security software vendors and consulting firms, from the top university-based security programs, and from CERT/CC and the SANS Institute. A complete list of participants may be found at the end of this article.

Here is the experts’ updated list of the twenty most often exploited Internet security flaws along with the actions needed to rid your systems of these vulnerabilities.

Please let us know your comments and feedback.

Eric Cole

SANS Institute, Director Cyber Defense Initiative

Author of Hackers Beware

--------------------------------------------------------------------

Five Notes For Readers:

Note 1. This is a living document. It includes initial, step-by-step instructions and pointers for correcting the flaws. We will update these instructions as more current or convenient methods are identified and we welcome your input. This is a community consensus document – your experience in eliminating the vulnerabilities can help others who come after you. To make suggestions e-mail info@sans.org with the subject Top Twenty Comments.

Note 2. You’ll find references to CVE numbers – the Common Vulnerabilities and Exposures reference numbers that correspond with vulnerabilities. CAN numbers are candidates for CVE entries that are not yet fully verified. For more data on the award-winning CVE project, see http://cve.mitre.org.

Note 3. At the end of the document , you’ll find an extra section offering a list of the ports used by commonly probed and attacked services. By blocking traffic to those ports at the firewall or other network perimeter protection device, you add an extra layer of defense that helps protect you from configuration mistakes. Note however that merely firewalling a port is not sufficient, as you are still vulnerable to attacks from disgruntled employees or hackers who may have penetrated your perimeter using other means.

Note 4. For each exploit, manual methods are listed for checking a system to see if it is vulnerable. A more practical approach is to use an automated scanner. An updated version of the free Internet scanner called Sara has been built to scan a system for the new top 20 vulnerabilities across Unix and NT systems. Several commercial vulnerability scanners can also be used to scan for these vulnerabilities.

The General vulnerabilities can quickly be analyzed manually, by the methods listed below.

Note 5. For the general vulnerabilities section, the CVE numbers listed are examples of some of the vulnerabilities that are covered by each listed item. Those CVE lists ares not meant to be all-inclusive. On the other hand, for the Windows and Unix vulnerabilities, the CVE numbers reflect specific vulnerabilities that should be checked for each item.

Top Vulnerabilities That Affect All Systems (G) *

G1 - Default installs of operating systems and applications *

G2 - Accounts with No Passwords or Weak Passwords *

G3 - Non-existent or Incomplete Backups *

G4 - Large number of open ports *

G5 – Not filtering packets for correct incoming and outgoing addresses *

G6 - Non-existent or incomplete logging *

G7 - Vulnerable CGI Programs *

Top Vulnerabilities To Windows Systems (W) *

W1 - Unicode Vulnerability (Web Server Folder Traversal) *

W2 - ISAPI Extension Buffer Overflows *

W3 - IIS RDS exploit (Microsoft Remote Data) *

W4 - NETBIOS - unprotected Windows networking shares *

*

W6 - Weak hashing in SAM (LM hash) *

Top Vulnerabilities To Unix Systems (U) *

U1 - Buffer Overflows in RPC Services *

U2 - Sendmail Vulnerabilities *

U3 - Bind Weaknesses *

U4 - R Commands *

U5 - LPD (remote print protocol daemon) *

U6 – sadmind and mountd *

U7 - Default SNMP Strings *

Appendix A – Common Vulnerable Ports *

Appendix B – Signatories *

Top Vulnerabilities That Affect All Systems (G)

G1 - Default installs of operating systems and applications

G1.1 Description:

Most software, including operating systems and applications, comes with installation scripts or installation programs. The goal of these installation programs is to get the systems installed as quickly as possible with the least amount of work being performed by the administrator. To accomplish these goals the scripts typically install a superset of functionality needed by a user or application. The philosophy is that it is better to have functionality there that is not needed, than to have functionality not installed that is later needed. If the additional functions were not installed, users would call the help desk and use up corporate resources and reduce corporate profits. So instead vendors configure the default installation of most software to include the superset of all needed functionality. The problem with this approach is that it creates many of the most dangerous security situations.

For operating systems, default installations nearly always include extraneous services and corresponding open ports. Attackers break into systems via these ports. In most cases the fewer ports you have open, the fewer avenues an attacker can use to compromise your network. For applications, default installations usually include unneeded programs and sample scripts. One of the most serious vulnerabilities with web servers is sample scripts; attackers use these scripts to compromise the system or gain information about it. In most cases, the system administrator whose system is compromised did not know that the sample scripts were installed. Sample scripts are a problem because they usually do not go through the same quality control process as other software. In fact they are shockingly poorly written in many cases. Error checking is often forgotten and the sample scripts offer a fertile ground for buffer overflow attacks. Sample scripts are very often also designed to showcase functionality; functionality that is often in direct conflict with the security objectives of the administrator.

G1.2 Systems impacted:

Most operating systems and applications.

G1.3 CVE entries:

(Note: This list is not complete or all-inclusive. It is a sample of some of the vulnerabilities covered by this category.)

CVE-1999-0415, CVE-1999-0678, CVE-1999-0707, CVE-1999-0722, CVE-1999-0746, CVE-1999-0954, CVE-2000-0112, CVE-2000-0192, CVE-2000-0193, CVE-2000-0217, CVE-2000-0234, CVE-2000-0283, CVE-2000-0611, CVE-2000-0639, CVE-2000-0672, CVE-2000-0762, CVE-2000-0868, CVE-2000-0869, CVE-2000-1059

G1.4 How to determine if you are vulnerable:

If you did a default install of a software package and did not perform any additional configuration or hardening, you are vulnerable. Unfortunately this is true for most applications and operating systems. Most default installations of software are not secure by default. Yet that is what most companies use to run their mission critical systems.

Even if you did perform additional configurations you could still be vulnerable. You should run a port scanner and a vulnerability scanner against any system that is to be connected to the Internet. When analyzing the results keep in mind the principle that your systems should run the fewest number of services and software packages needed to perform their job. Every extra program or service provides a tool for attackers – especially because most system administrators do not patch services that they are not actively using.

G1.5 How to protect against it:

The best way to protect against this is to properly harden each system on your network. Remove unnecessary software, turn off unneeded services and close extraneous ports. This can be a tedious task. An alternative used by most large organizations is to develop a standard "build" or standard installation guidelines for all operating systems and applications used by the organization. This standard should have the minimal number of features needed for the system to function. Then, based on the role the system is going to play, a second home-grown installation script can be run to install only the necessary services.

The Center for Internet Security (www.cisecurity.com) is developing industry consensus guidelines and hardening scripts that can be used to secure most operating systems. The Center’s work represents the combined effort of more than one hundred large government, commercial and academic organizations throughout the world.

G2 - Accounts with No Passwords or Weak Passwords

G2.1 Description:

Most systems are configured to use passwords as the first and only line of defense. User IDs are fairly easy to acquire and most companies have dial-up access that bypasses the firewall. Therefore, if an attacker can determine an account name and password, he or she can logon to the network. Easy to guess passwords and default passwords are a big problem, but an even bigger one is accounts with no passwords at all. In practice all accounts with weak passwords, default passwords, and no passwords should be removed from your system.

In addition, many systems have built-in or default accounts. These accounts are installed by default and usually have the same password across installations of the software. Attackers commonly look for these accounts, because they are well-known, and try to gain access. Therefore, any default or built-in accounts also need to be identified and removed from the system.

G2.2 Systems impacted:

Any operating system or application where users authenticate via a user ID and password.

G2.3 CVE entries:

(Note: This list is not complete or all-inclusive. It is a sample of some of the vulnerabilities covered by this category.)

CVE-1999-0291, CAN-1999-0501, CAN-1999-0502, CAN-1999-0503,

CAN-1999-0505, CAN-1999-0506, CAN-1999-0507, CAN-1999-0508,

CAN-1999-0516, CAN-1999-0517, CAN-1999-0518, CAN-1999-0519

G2.4 How to determine if you are vulnerable:

In order to know if you are vulnerable, you need to know what accounts are on your system. The following are the steps that should be performed:

1. 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.
2. Develop procedures for adding authorized accounts to the list, and for removing accounts when they are no longer in use.
3. Validate the list on a regular basis to make sure no new accounts have been added and that unused accounts have been removed.
4. Run a password cracking tool against the accounts looking for weak or no passwords (Make sure you have official written permission before employing a password cracking tool)

1. LC3 – Microsoft NT and Microsoft 2000, http://www.atstake.com
2. Microsoft Personal Security Advisor, – Microsoft NT and Microsoft 2000, www.microsoft.com/security/mpsa
3. John the Ripper – Unix, http://www.openwall.com/john
4. Pandora – Novell, http://www.nmrc.org/pandora

5. Have rigid procedures for removing accounts when employees or contractors leave, or when the accounts are no longer required.

G2.5 How to protect against it:

To eliminate these password problems, two steps need to be performed. In the first step all accounts with no password are given a password or are removed, and weak passwords are strengthened. Sadly, when users are asked to change and strengthen their passwords, they often pick another one that is easy-to-guess. This brings us to the second step. User passwords should also be validated when they change their password. Computer programs are available to reject any password change that does not meet your security policy. The most popular are described at the urls below:

1. For UNIX: Npasswd, http://www.utexas.edu/cc/unix/software/npasswd
2. For Windows NT: Passfilt, http://support.microsoft.com/support/kb/articles/Q161/9/90.asp

These programs ensure that when passwords are modified they will be of the length and composition required to make guessing and cracking difficult. Note that many vendor Unix systems include internal support for password hardening and that there are other packages available as well.

Many organizations supplement password control programs with controls that ensure that passwords are changed regularly and that old passwords are not reused. If password aging is used, make sure that the users are given warning and chances to change their password before it expires. When faced with a message: "your password has expired and must be changed", users will tend to pick a bad password.

Another important supplement is user awareness training that helps users understand why and how to pick strong passwords. The most common advice given for picking better passwords is to pick a phrase that includes a number, and construct the password from the first or second letter of each non-numeric word in the phrase, and the numeral for any numbers.

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

G3 - Non-existent or Incomplete Backups

G3.1 Description:

When an incident occurs (and it will occur in nearly every organization), recovery from the incident requires up-to-date backups and proven methods of restoring the data. Some organizations make daily backups, but never verify that the backups are actually working. Others construct backup policies and procedures but do not create restoration policies and procedures. Such errors are often discovered after a hacker has entered systems and destroyed or otherwise ruined data.

A second problem involving backups is insufficient physical protection of the backup medium. The backups contain the same sensitive information that is residing on the server and should be protected in the same manner.

G3.2 Systems impacted:

Any mission critical system.

G3.3 CVE entries:

N/A

G3.4 How to determine if you are vulnerable:

An inventory of all critical systems must be identified. Then a risk analysis should be performed identifying what the risk and corresponding threat is for each critical system. The backup policies and procedures should clearly map to these key servers. Once these systems have been verified, the following should be validated:

1. Are there backup procedures for those systems?
2. Is the backup interval acceptable?
3. Are those systems being backed up according to the procedures?
4. Has the backup media been verified to make sure the data is being backed up accurately?
5. Is the backup media properly protected in-house and with off-site storage?
6. Are there copies of the operating system and any restoration utilities stored off-site (including necessary license keys)?
7. Have restoration procedures been validated and tested?

G3.5 How to protect against it:

Backups must be made at least daily. The minimum requirement in most organizations is to perform a full backup weekly and incremental backups every day. At least once a month the backup media should be verified by doing a restore to a test server to make sure the data is being backed up. This is the minimum requirement. Some companies perform full backups every day or backups multiple times a day. The ultimate backup solution is a fully redundant network with fail-over capability – a solution required for critical real-time financial and e-commerce systems; systems controlling the critical infrastructure, and some Department of Defense systems.

G4 - Large number of open ports

G4.1 Description:

Legitimate users and attackers connect to systems via open ports. The more ports that are open the more possible ways that someone can connect to your system. Therefore it is important to keep the least number of ports open on a system in order for it to function properly. All other ports must be closed.

G4.2 Systems impacted:

Most operating systems.

G4.3 CVE entries:

(Note: This list is not complete or all-inclusive. It is a sample of some of the vulnerabilities covered by this category.)

CVE-1999-0189, CVE-1999-0288, CVE-1999-0351, CVE-1999-0416, CVE-1999-0675, CVE-1999-0772, CVE-1999-0903, CVE-2000-0070, CVE-2000-0179, CVE-2000-0339, CVE-2000-0453, CVE-2000-0532, CVE-2000-0558, CVE-2000-0783, CVE-2000-0983,

G4.4 How to determine if you are vulnerable:

The netstat command can be run locally to determine which ports are open, but the best way to have confidence in the scans is to run an external port scanner against your systems. This will give you a list of all ports that are actually listening. If the results of netstat differ from the port scanning results, you should investigate why. Once the two lists agree, go through the list and validate why each port is open and what is running on each port. Any port that cannot be validated or justified should be closed. The final list should be recorded and used to audit the ports on a regular basis to make sure no extraneous ports appear.

Among the many port scanners, the most popular is nmap. The Unix version of nmap can be found at: http://www.insecure.org/nmap/. This version will also compile on NT systems. The NT version of nmap can be found at: http://www.eeye.com/html/Research/Tools/nmapnt.html. Other port scanners also work well. Whatever scanner you use, you MUST scan both TCP and UDP ports over the entire range: 1-65,535.

You should always have written permission before comprehensive port scanning is performed on systems within an organization. Some operating systems and particularly devices with embedded TCP/IP stacks can exhibit unpredictable behavior when scanned. This activity may also trigger internal intrusion detection systems or firewalls and may be interpreted as an attack if proper notice is not given.

G4.5 How to protect against it:

Once you determine which ports are open, you have to determine what is the minimal subset of ports that must be open. Once the extraneous ports are identified you must go in and close them. To close a port that is open you have to find the corresponding service and turn it off and remove it. The best way to approach this is to determine the minimal set of services that should be running on a system.

For Unix systems many services are controlled by inetd and the corresponding configuration file is inetd.conf. That file lists which services are listening on a given port and it can often be used to close ports because removing a service from inetd.conf and restarting inetd, closes the corresponding port. Other services are started via scripts run at boot time (such as /etc/rc, /etc/rc.local, or the scripts found in the /etc/rc* directories). Consult your system’s documentation on how to disable these scripts, as the details vary between Unix versions.

For NT, a program called fport from www.foundstone.com can be used to try and determine what service/program is listening on a certain port. Starting with Windows XP, you can also determine which program is listening on a particular port by running the netstat command with the –o switch. By having this information you can turn off the service, which will close the port.

G5 – Not filtering packets for correct incoming and outgoing addresses

G5.1 Description:

Spoofing IP addresses is a common method used by attackers to hide their tracks when they attack a victim. For example, the very popular smurf attack uses a feature of routers to send a stream of packets to thousands of machines. Each packet contains a spoofed source address of a victim. The computers to which the spoofed packets are sent flood the victim’s computer often shutting down the computer or the network. Performing filtering on traffic coming into your network (ingress filtering) and going out (egress filtering) can help provide a high level of protection. The filtering rules are as follows:

1. Any packet coming into your network must not have a source address of your internal network
2. Any packet coming into your network must have a destination address of your internal network
3. Any packet leaving your network must have a source address of your internal network
4. Any packet leaving your network must not have a destination address of your internal network.
5. Any packet coming into your network or leaving your network must not have a source or destination address of a private address or an address listed in RFC1918 reserved space. These include 10.x.x.x/8, 172.16.x.x/12 or 192.168.x.x/16 and the loopback address 127.0.0.0/8.
6. Block any source routed packets or any packets with the IP options field set.

G5.2 Systems impacted:

Most operating systems and network devices

G5.3 CVE entries:

(Note: This list is not complete or all-inclusive. It is a sample of some of the vulnerabilities covered by this category.)

CAN-1999-0528, CAN-1999-0529, CAN-1999-0240, CAN-1999-0588

G5.4 How to determine if you are vulnerable:

Try to send a spoofed packet and see if your external firewall or router blocks it. Not only should your device block the traffic but it should also produce a record in the log showing that the spoofed packets have been dropped. Note however that this opens up the door to a new attack – flooding the logfile. Make sure your logging system can handle a heavy load otherwise it could be vulnerable to a DOS attack. Programs like nmap can be used to send decoy packets or spoofed packets to test this type of filtering. Once filtering is setup don’t assume that it is working effectively. Test it often.

G5.5 How to protect against it:

To defend against this type of attack filtering rules should be setup on your external router or firewall. The following are sample rules for a Cisco router:

1. inbound or ingress filtering

interface Serial 0

ip address 10.80.71.1 255.255.255.0

ip access-group 11 in

access-list 11 deny 192.168.0.0 0.0.255.255

access-list 11 deny 172.16.0.0 0.15.255.255

access-list 11 deny 10.0.0.0 0.255.255.255

access-list 11 deny <your internal network>

access-list 11 permit any

2. outbound or egress filtering

interface Ethernet 0

ip address

10.80.71.1 255.255.255.0

ip access-group 11 in

access-list 11 permit <your internal network>

G6 - Non-existent or incomplete logging

G6.1 Description:

One of the maxims of security is, "Prevention is ideal, but detection is a must." As long as you allow traffic to flow between your network and the Internet, the chance for an attacker to sneak in and penetrate the network, is very high. New vulnerabilities are discovered every week and there are very few ways to defend yourself against an attacker using a new vulnerability. Once you are attacked, without logs, you have little chance of discovering what the attackers did. Without that knowledge, your organization must choose between completely reloading the operating system from original media and then hoping the data back-ups were OK, or taking the risk that you are running a system that a hacker still controls.

You cannot detect an attack if you do not know what is occurring on your network. Logs provide the details of what is occurring, what systems are being attacked and what systems have been compromised.

Logging must be done on a regular basis on all key systems, and logs should be archived and backed up because you never know when you might need them. Most experts recommend sending all of your logs to a central log server that writes the data to a write once media, so that the attacker cannot overwrite the logs and avoid detection.

G6.2 Systems impacted:

All operating systems and network devices.

G6.3 CVE entries:

CAN-1999-0575, CAN-1999-0576, CAN-1999-0578

G6.4 How to determine if you are vulnerable:

Review the system logs for each major system. If you do not have logs, or if they are not centrally stored and backed-up, you are vulnerable.

G6.5 How to protect against it:

Set up all systems to log information locally and to send the log files to a remote system. This provides redundancy and an extra layer of security. Now the two logs can be verified and compared against each other. Any differences could indicate suspicious activity on the system. In addition, this allows cross checking of log files. One line in a log file on a single server may not be suspicious, but the same entry on 50 servers across and organization within a minute of each other, may be a sign of a major problem.

Wherever possible, send logging information to a device that uses write-once media.

G7 - Vulnerable CGI Programs

G7.1 Description:

Most web servers, including Microsoft IIS and Apache, support Common Gateway Interface (CGI) programs to provide interactivity in web pages, such as data collection and verification, and most web servers come with sample CGI programs installed by default. Unfortunately, too many CGI programmers fail to consider that their programs provide a direct link from any user anywhere on the Internet directly to the operating system of the computer running the web server. Vulnerable CGI programs present a particularly attractive target to intruders because they are relatively easy to locate, and they operate with the privileges and power of the web server software itself. Intruders are known to have exploited vulnerable CGI programs to vandalize web pages, steal credit card information, and set up back doors to enable future intrusions, even if the CGI programs are secured. When the Department of Justice web site was vandalized, an in-depth assessment concluded that a CGI hole was the most probable avenue of compromise. Web server applications are similarly vulnerable to threats created by programmers. As a general rule, sample programs should always be removed from production systems.

G7.2 Systems impacted:

All web servers.

G7.3 CVE entries:

(Note: This list is not complete or all-inclusive. It is a sample of some of the vulnerabilities covered by this category.)

CVE-1999-0067, CVE-1999-0346, CVE-2000-0207, CVE-1999-0467, CAN-1999-0509, CVE-1999-0021, CVE-1999-0039, CVE-1999-0058, CVE-2000-0012, CVE-2000-0039, CVE-2000-0208, CAN-1999-0455, CAN-1999-0477

G7.4 How to determine if you are vulnerable:

If you have any sample code on your web server, you are vulnerable. If you have legitimate CGI programs, ensure you are running the latest version and then run a vulnerability scanning tool against your site. By simulating what an attacker would do, you will be prepared to protect your systems. To find vulnerable CGI scripts, you may use a CGI scanner called whisker that can be found at:

http://www.wiretrip.net/rfp/

G7.5 How to protect against it:

The following are the key things that need to be done to protect against vulnerable CGI programs:

1. Remove all sample CGI programs from a production web server.
2. Remove unsafe CGI scripts from all web servers
3. Ensure all CGI programmers adhere to a strict policy of input buffer length checking in CGI programs.
4. Apply patches for known vulnerabilities that cannot be removed:
5. Make sure that your CGI bin directory does not include any compilers or interpreters.
6. Remove the "view-source" script from the cgi-bin directory.
7. Do not run your web servers with administrator or root privileges. Most web servers can be configured to run with a less privileged account such as nobody.
8. Do not configure CGI support on Web Servers that do not need it.

Top Vulnerabilities To Windows Systems (W)

W1 - Unicode Vulnerability (Web Server Folder Traversal)

W1.1 Description:

Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language. The Unicode Standard has been adopted by most vendors, including Microsoft. By sending an IIS server a carefully constructed URL (which contains the Unicode equivalent of certain commands), an attacker can force the server to literally ‘walk up and out’ of a directory and execute arbitrary scripts. This type of attack is also known as the web server folder traversal attack.

For example if an attacker sends the Unicode equivalents of / and \ which are %c0%af and %c1%9c, the usual checks can be bypassed, and the victim’s system will execute arbitrary programs. Additional information on the Unicode threat can be found at: http://www.wiretrip.net/rfp/p/doc.asp?id=57&face=2

W1.2 Systems impacted:

Microsoft Windows NT 4.0 with IIS 4.0 and Windows 2000 server with IIS 5.0, which do not have Service Pack 2 installed.

W1.3 CVE entries:

NOTE: This list is intended to be a complete list of all top priority CVE numbers related to this issue. While there may be other CVE numbers related to this issue, they have been excluded as they have been deemed to be of less importance than those listed here.

CVE-2000-0884

W1.4 How to determine if you are vulnerable:

If you are running an un-patched version of IIS you are probably vulnerable. The best way to tell if you are vulnerable is to run hfnetchk. For a more specific verification, test the exploit on your own system to see whether it is successful. Try typing the following command against your IIS web server: http://victim/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\

This URL may need to be modified to accurately test a particular system. If you have removed the scripts directory (which is recommended) this command will fail. You can test a system by temporarily creating a directory that has execute permissions, or by using another directory that has execute permissions, instead of the scripts directory in the exploit. For example, you may have removed the scripts directory, but have a directory called cgi-bin instead. Test your system by using cgi-bin instead of scripts.

If you are vulnerable this URL will send back a directory listing of the contents of the c drive, for the vulnerable server. You are essentially running the exploit against your system, just like an attacker would. The only difference is you are issuing a non-intrusive command (like dir), but an attacker would do significant damage or create a back door into your system.

W1.5 How to protect against it:

In order to defend against this exploit, you must install the latest patches from Microsoft. These can be found at:

•Microsoft IIS 4.0

–http://www.microsoft.com/ntserver/nts/downloads/critical/q269862

•Microsoft IIS 5.0

–http://www.microsoft.com/windows2000/downloads/critical/q269862

W2 - ISAPI Extension Buffer Overflows

W2.1 Description:

Microsoft’s Internet Information Server (IIS) is the web server software found on most web sites deployed on Microsoft Windows NT and Windows 2000 servers. When IIS is installed, several ISAPI extensions are automatically installed. ISAPI, which stands for Internet Services Application Programming Interface, allows developers to extend the capabilities of an IIS server using DLLs. Several of the DLLs, like idq.dll, contain programming errors that cause them to do improper error bounds checking. In particular they do not block unacceptably long input strings. Attackers can send data to these DLLs, in what is known as a buffer overflow attack, and take full control of an IIS web server.

W2.2 Systems impacted:

This exploit impacts Microsoft Index Server 2.0 and Indexing Service in Windows 2000.

W2.3 CVE entries:

NOTE: This list is intended to be a complete list of all top priority CVE numbers related to this issue. While there may be other CVE numbers related to this issue, they have been excluded as they have been deemed to be of less importance than those listed here.

CVE-1999-0412, CVE-2001-0241, CAN-2000-1147, CAN-2001-0500

W2.4 How to determine if you are vulnerable:

If your web server does not have at least Service Pack 2 installed, you are probably vulnerable. If you are not sure which patches have been installed, download and run hfnetchk from:

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/hfnetchk.asp

W2.5 How to protect against it:

Install the latest patches from Microsoft. These can be found at:

- Windows NT 4.0:
  http://www.microsoft.com/Downloads/Release.asp?ReleaseID=30833
- Windows 2000 Professional, Server and Advanced Server:
  http://www.microsoft.com/Downloads/Release.asp?ReleaseID=30800
- Windows 2000 Datacenter Server:
  Patches for Windows 2000 Datacenter Server are hardware-specific and available from the original equipment manufacturer.
- Windows XP:
  The vulnerability does not affect Windows XP.

Also, an administrator should go in and unmap any ISAPI extensions that are not needed. Check on a regular basis that the extensions have not become re-mapped.

Remember, the principle of least privilege, your systems should be running the least number of services needed for them to function properly. To assist with this, you can run the Microsoft IIS lockdown tool available from:

http://www.microsoft.com/technet/security/tools/locktool.asp

W3 - IIS RDS exploit (Microsoft Remote Data Services)

W3.1 Description:

Microsoft’s Internet Information Server (IIS) is the web server software found on most web sites deployed on Microsoft Windows NT and Windows 2000 servers. Malicious users exploit programming flaws in IIS’s Remote Data Services (RDS) to run remote commands with administrator privileges.

W3.2 Systems impacted:

Microsoft Windows NT systems running Internet Information Server

W3.3 CVE entries:

NOTE: This list is intended to be a complete list of all top priority CVE numbers related to this issue. While there may be other CVE numbers related to this issue, they have been excluded as they have been deemed to be of less importance than those listed here.

CVE-1999-1011

W3.4 How to determine if you are vulnerable:

If you are running an un-patched system, you are vulnerable. You can run a CGI scanner, whisker, against your web site to verify the vulnerability. Whisker can be found at: http://www.wiretrip.net/rfp/

An excellent guide to the RDS weakness and how to correct it may be found
at: http://www.wiretrip.net/rfp/p/doc.asp?id=29&iface=2

W3.5 How to protect against it:

Patches are available and can be downloaded from Microsoft’s website:

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

W4 - NETBIOS - unprotected Windows networking shares

W4.1 Description:

The Server Message Block (SMB) protocol, also known as the Common Internet File System (CIFS) enables file sharing over networks. Improper configuration can expose critical system files or give full file system access to any hostile party connected to the Internet. Many computer owners unknowingly open their systems to hackers when they try to improve convenience for coworkers and outside researchers by making their drives readable and writeable by network users. Administrators of a government computer site used for software development for mission planning made their files world readable, so people at a different government facility could get easy access. Within two days, attackers had discovered the open file shares and had stolen the mission planning software.

Enabling file sharing on Windows machines makes them vulnerable to both information theft and certain types of quick-moving viruses. Macintosh computers are also vulnerable to file sharing exploits.

The SMB mechanisms that permit Windows File Sharing may be used by attackers to obtain sensitive system information from Windows systems. User and Group information (usernames, last logon dates, password policy, RAS information), system information, and certain Registry keys may all be accessed via a "null session" connection to the NetBIOS Session Service. This information is useful to hackers because it helps them mount a password guessing or brute force password attack against the Windows target.

W4.2 Systems impacted:

Microsoft Windows NT and Windows 2000 systems

W4.3 CVE entries:

NOTE: This list is intended to be a complete list of all top priority CVE numbers related to this issue. While there may be other CVE numbers related to this issue, they have been excluded as they have been deemed to be of less importance than those listed here.

CVE-1999-0366, CVE-2000-0222, CVE-2000-0979, CAN-1999-0518, CAN-1999-0519, CAN-1999-0520, CAN-1999-0621, CAN-2000-1079

W4.4 How to determine if you are vulnerable:

A quick, free, and secure test for the presence of SMB file sharing, and its related vulnerabilities, effective for machines running any Windows operating system, is available at the Gibson Research Corporation web site at http://grc.com/. Click the "ShieldsUP" icon 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.

W4.5 How to protect against it:

Take the following steps to defend against unprotected shares:

- When sharing data, ensure only required directories are shared.
- For added security, allow sharing only to specific IP addresses because DNS names can be spoofed.
- For Windows systems (both NT and 2000), ensure that the permissions on the shared directories allow access only to those people who require access.
- For Windows systems, prevent anonymous enumeration of users, groups, system configuration and registry keys via the "null session" connection.
- Block inbound connections to the NetBIOS Session Service (tcp 139) at the router or the host.
- Consider implementing the RestrictAnonymous registry key for Internet-connected hosts in standalone or non-trusted domain environments. For more information see the following web pages:

NT4: http://support.microsoft.com/support/kb/articles/Q143/4/74.asp
Win2000: http://support.microsoft.com/support/kb/articles/Q246/2/61.ASP

W5 - Information leakage via null session connections

W5.1 Description:

A Null Session connection, also known as Anonymous Logon, is a mechanism that allows an anonymous user to retrieve information, such as user names and shares, over the network, or to connect without authentication. It is used by applications such as explorer.exe to enumerate shares on remote servers. On Windows NT and Windows 2000 systems, many local services run under the SYSTEM ID. The SYSTEM account is used for various critical system operations. When one machine needs to retrieve system data (like available shares, users, etc) from another, the SYSTEM account will open a null session to the other machine.

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

W5.2 Systems impacted:

Windows NT and Windows 2000 systems

W5.3 CVE entries:

NOTE: This list is intended to be a complete list of all top priority CVE numbers related to this issue. While there may be other CVE numbers related to this issue, they have been excluded as they have been deemed to be of less importance than those listed here.

CAN-2000-1200

W5.4 How to determine if you are vulnerable:

Try to connect to you system via a Null session using the following command:

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

where a.b.c.d is the IP address of the remote system.

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

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

W5.5 How to protect against it:

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

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

Whenever you modify the registry, it could cause your system to stop working properly. Therefore any changes should be tested before hand. Also, the system should always be backed up to simplify recovery. If you do not need file and print sharing, unbind NetBIOS from TCP/IP.

Because of this vulnerability, Internet users should never be allowed to access any internal domain controller. To stop such access, block the following ports at the external router or firewall:

TCP and UDP 135 through139 and 445

W6 - Weak hashing in SAM (LM hash)

W6.1 Description:

Though most Windows users have no need for LAN Manager support, Microsoft stores LAN Manager password hashes, by default, on Windows NT and 2000 systems. Since LAN Manager uses a much weaker encryption scheme than do the more current Microsoft approaches, LAN Manager passwords can be broken in a very short period of time. Even strong password hashes can be cracked in under a month. The major weaknesses of LAN Manager hashes is the following:

- password truncated to 14 characters
- password padded with spaces to become 14 characters
- password converted to all upper case characters
- password split into two seven character pieces

This means that the password cracking program just has to crack two seven-character passwords without even testing lower case letters. In addition, LAN Manager is more vulnerable to eavesdropping of the password hashes. Eaevsdropping can provide attackers with user passwords.

W6.2 Systems impacted:

Microsoft Windows NT and 2000 servers

W6.3 CVE entries:

N/A

W6.4 How to determine if you are vulnerable:

If you are running a default installation of NT or 2000 you are vulnerable since LAN Manager hashes are installed by default. You may test the ease of password cracking on your own systems using an automate password cracking tool like LC3 (l0phtcrack version 3) available from: http://www.atstake.com/research/lc3/download.html

W6.5 How to protect against it:

Disable LAN Manger authentication and use NTLMv2. NTLMv2 (NT LanManager version 2) challenge/response methods overcome most weaknesses in Lan Manager (LM) by using stronger encryption and an improved authentication and session security mechanisms.

With Windows NT 4.0 SP4 and newer systems, including Windows 2000, Microsoft makes it posible to use only NTLMv2 in your network (actually they finally fixed it in Windows NT 4.0 Service Pack 6). The registry key that controls this capability in both Windows NT and 2000 is HKLM\System\CurrentControlSet\Control\LSA\ LMCompatibilityLevel. If you set its value to 3, the workstation or server will present only NTLMv2 credentials for authentication. If you set it to 5, any domain controller will refuse LM and NTLM authentication and will only accept NTLMv2.

You have to carefully plan the changes if you still have older systems, such as Windows 95, in your network. Older systems won’t use NTLMv2 with the Microsoft Network Client. In Win 9x, the parameter is HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LMCompatibility and the allowed values are 0 or 3 (with Directory Services Client). The safest option is to get rid of those older systems, since they do not allow you to provide the minimun security level an organization requires.

The Microsoft Technet article "How to Disable LM Authentication on Windows NT [Q147706]" details the required changes in the registry, for Windows 9x and Windows NT/2000. "LMCompatibilityLevel and Its Effects [Q175641]" explains the interoperability issues with this parameter. Another very useful article from the Technet is "How to Enable NTLM 2 Authentication for Windows 95/98/2000/NT [Q239869]." It explains the use of the Windows 2000’s Directory Services Client for Windows 95/98 to overcome the compatibility limitation for NTLMv2.

Top Vulnerabilities To Unix Systems (U)

U1 - Buffer Overflows in RPC Services

U1.1 Description:

Remote procedure calls (RPC) allow programs on one computer to execute programs on a second computer. They are widely used to access network services such as NFS file sharing and NIS. Multiple vulnerabilities caused by flaws in RPC are being actively exploited. 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 because they had the 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 systems.

U1.2 Systems impacted:

Most versions of Unix

U1.3 CVE entries:

NOTE: This list is intended to be a complete list of all top priority CVE numbers related to this issue. While there may be other CVE numbers related to this issue, they have been excluded as they have been deemed to be of less importance than those listed here.

CVE-1999-0003, CVE-1999-0693, CVE-1999-0696, CVE-1999-0018, CVE-1999-0019, CVE-1999-0704, CAN-2001-0236, CVE-2000-0666

U1.4 How to determine if you are vulnerable:

Check to see if you are running one of the RPC services that are most commonly exploited including the following:

- rpc.ttdbserverd
- rpc.cmsd
- rpc.statd

The way these services are commonly exploited is through buffer overflow attacks. These attacks can be successful because the program does not do proper error checking. This allows an attacker to send data that the program is not expecting and because there is poor error checking, the data will be passed on for processing.

U1.5 How to protect against it:

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

1. Wherever possible, turn off and/or remove these services on machines directly accessible from the Internet.
2. Where you must run them, install the latest patches:

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

For IBM AIX Software
http://techsupport.services.ibm.com/support/rs6000.support/downloads
http://techsupport.services.ibm.com/rs6k/fixes.html

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

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

3. Search the vendor patch database for patches and install them right away.
4. Block the RPC port (port 111) at the border router or firewall.
5. Block the RPC "loopback" ports, 32770-32789 (TCP and UDP)

A summary document pointing to specific guidance about each of three principal RPC vulnerabilities may be found at: http://www.cert.org/incident_notes/IN-99-04.html

The following provides information on each of the vulnerable services:

statd: http://www.cert.org/advisories/CA-99-05-statd-automountd.html
ToolTalk: http://www.cert.org/advisories/CA-98.11.tooltalk.html
Calendar Manager: http://www.cert.org/advisories/CA-99-08-cmsd.html

U2 - Sendmail Vulnerabilities

U2.1 Description:

Sendmail is the program that sends, receives, and forwards most electronic mail processed on UNIX and Linux computers. Sendmail’s widespread use on the Internet makes it a prime target of attackers. Several flaws have been found over the years. The very first advisory issued by CERT/CC, in 1988, made reference to an exploitable weakness in Sendmail. In one of the most common exploits, the attacker sends a crafted mail message to the machine running Sendmail, and Sendmail reads the message as instructions requiring the victim machine to send its password file to the attacker’s machine (or to another victim) where the passwords can be cracked.

U2.2 Systems impacted:

Most versions of Unix and Linux

U2.3 CVE entries:

NOTE: This list is intended to be a complete list of all top priority CVE numbers related to this issue. While there may be other CVE numbers related to this issue, they have been excluded as they have been deemed to be of less importance than those listed here.

CVE-1999-0047, CVE-1999-0130, CVE-1999-0131, CVE-1999-0203, CVE-1999-0204, CVE-1999-0206

U2.4 How to determine if you are vulnerable:

Sendmail has a large number of vulnerabilities and must be kept up to date and patched. Check to see what the latest version and patch level is for sendmail and if you are not running it, you are probably vulnerable.

U2.5 How to protect against it:

The following steps should be taken to protect sendmail:

1. Upgrade to latest version of Sendmail and/or implement patches for sendmail.
   http://www.cert.org/advisories/CA-97.05.sendmail.html
2. Do not run Sendmail in daemon mode (turn off the -bd switch) on machines that are neither mail servers nor mail relays.

U3 - Bind Weaknesses

U3.1 Description:

The Berkeley Internet Name Domain (BIND) package is the most widely used implementation of Domain Name Service (DNS) -- the critical means by which we all locate systems on the Internet by name (e.g., www.sans.org) without having to know specific IP addresses -- and this makes it a favorite target for attack. Sadly, according to a mid-1999 survey, as many as 50% of all DNS servers connected to the Internet are running vulnerable versions of BIND. In a typical example of a BIND attack, intruders erased the system logs and installed tools to gain administrative access. They then compiled and installed IRC utilities and network scanning tools, which they used to scan more than a dozen class-B networks in search of additional systems running vulnerable versions of BIND. In a matter of minutes, they had used the compromised system to attack hundreds of remote systems abroad, resulting in many additional successful compromises. This example illustrates the chaos that can result from a single vulnerability in the software for ubiquitous Internet services such as DNS. Outdated versions of Bind also include buffer overflow exploits that someone can use to get unauthorized access.

U3.2 Systems impacted:

Multiple UNIX and Linux systems

U3.3 CVE entries:

NOTE: This list is intended to be a complete list of all top priority CVE numbers related to this issue. While there may be other CVE numbers related to this issue, they have been excluded as they have been deemed to be of less importance than those listed here.

CVE-1999-0024, CVE-1999-0184, CVE-1999-0833, CVE-1999-0009, CVE-1999-0835, CVE-1999-0848, CVE-1999-0849, CVE-1999-0851, CVE-2001-0010, CVE-2001-0011, CVE-2001-0013

U3.4 How to determine if you are vulnerable:

Run a vulnerable scanner, check the version of BIND, or manually check the files to see if they are vulnerable. If in doubt, err on the cautious side and upgrade the system.

U3.5 How to protect against it:

The following steps should be taken to defend against the bind vulnerabilities:

1. Disable the BIND name daemon (named) on all systems that are not authorized to be DNS servers. Some experts recommend you also remove the DNS software.
2. On machines that are authorized DNS servers, update to the latest version and patch level. Use the guidance contained in the following advisories:

For the NXT vulnerability: http://www.cert.org/advisories/CA-99-14-bind.html
For the QINV (Inverse Query) and NAMED vulnerabilities: http://www.cert.org/advisories/CA-98.05.bind_problems.html
http://www.cert.org/summaries/CS-98.04.html

3. Run BIND as a non-privileged user for protection in the event of future remote-compromise attacks. (However, only processes running as root can be configured to use ports below 1024 – a requirement for DNS. Therefore you must configure BIND to change the user-id after binding to the port.)
4. Run BIND in a chroot()ed directory structure for protection in the event of future remote-compromise attacks.
5. Disable zone transfers except from authorized hosts.
6. Disable recursion and glue fetching, to defend against DNS cache poisoning.
7. Hide your version string.

U4 - R Commands

U4.1 Description:

Trust relationships are widely used in the UNIX world, particularly for system administration. Companies frequently assign a single administrator to be responsible for dozens or even hundreds of systems. Administrators often use trust relationships and the related UNIX r-commands to switch from system to system conveniently. r commands enable someone to access a remote system without supplying a password. Instead of requiring a username/password combination, the remote machine authenticates anyone coming from a trusted IP addresses. If an attacker gains control of any machine in such a trusted network, he or she can gain access to all other machines that trust the hacked machine. The following r commands are often used:

1. rlogin – remote login
2. rsh – remote shell
3. rcp remote copy

U4.2 Systems impacted:

Most variants of Unix, including Linux

U4.3 CVE entries:

NOTE: This list is intended to be a complete list of all top priority CVE numbers related to this issue. While there may be other CVE numbers related to this issue, they have been excluded as they have been deemed to be of less importance than those listed here.

CVE-1999-0046, CVE-1999-0113, CVE-1999-0185, CAN-1999-0651

U4.4 How to determine if you are vulnerable:

Trust relationships are established by configuring two files, either /etc/hosts.equiv or ~/.rhosts. Check for both of those files on your Unix systems to determine whether trust relationships have been configured.

U4.5 How to protect against it:

Do not allow trust relationships and do not use the r commands. Authentication based on IP addresses is too easy to bypass. Authentication should be based on more secure means such as tokens or, at the least, passwords. If r commands are required, limit the access and control the perimeter of the network extremely carefully. Never allow the ".rhosts" file in the "root" account. You can use the Unix "find" command regularly to look for any ".rhosts" files that may have been created in other user accounts.

U5 - LPD (remote print protocol daemon)

U5.1 Description:

In Unix, the in.lpd provides services for users to interact with the local printer. LPD listens for requests on TCP port 515. The programmers who developed the code that transfers print jobs from one machine to another made an error that creates a buffer overflow vulnerability. If the daemon is given too many jobs within a short time interval, the daemon will either crash or run arbitrary code with elevated privileges.

U5.2 Systems impacted:

The following systems are impacted:

- Solaris 2.6 for SPARC
- Solaris 2.6 x86
- Solaris 7 for SPARC
- Solaris 7 x86
- Solaris 8 for SPARC
- Solaris 8 x86
- Most variants of Linux

U5.3 CVE entries:

NOTE: This list is intended to be a complete list of all top priority CVE numbers related to this issue. While there may be other CVE numbers related to this issue, they have been excluded as they have been deemed to be of less importance than those listed here.

CVE-1999-0032, CVE-1999-0299, CVE-2000-0917, CAN-2001-0670, CAN-2001-0668, CAN-2001-0353, CAN-1999-0061

U5.4 How to determine if you are vulnerable:

Either a vulnerability scanner can be run against your system to look for this vulnerability, or a manual check can be run. The easiest way to run a manual check is to see if you system is running lpd and check the version number.

If you are running one of the vulnerable version of the software and did not apply a patch, than you are vulnerable.

U5.5 How to protect against it:

As this went to press, Sun was still currently working on patches. Those patches should be applied once they are released. In the mean time, other options for defending against attacks using this vulnerability include:

1. Disable the print service in /etc/inetd.conf if remote print job handling is unnecessary.
2. Enable the noexec_user_stack tunable by adding the following lines to the /etc/system file, and reboot:

- set noexec_user_stack = 1
- set noexec_user_stack_log = 1

1. Block access to network port 515/tcp
2. Deploy tcpwrappers, which are part of the tcpd-7.6 package and can be downloaded from:
   http://www.sun.com/solaris/freeware.html#cd

U6 – sadmind and mountd

U6.1 Description:

Sadmind allows remote administration access to Solaris systems, providing a graphical user interface for system administration functions. Mountd controls and arbitrates access to NFS mounts on UNIX hosts. Buffer overflows in these applications, enabled by programming errors made by the software developers, can be exploited to allow attackers to gain control with root access.

U6.2 Systems impacted:

Multiple versions of Unix

U6.3 CVE entries:

NOTE: This list is intended to be a complete list of all top priority CVE numbers related to this issue. While there may be other CVE numbers related to this issue, they have been excluded as they have been deemed to be of less importance than those listed here.

CVE-1999-0977, CVE-1999-0002, CVE-1999-0493, CVE-1999-0210

U6.4 How to determine if you are vulnerable:

Use a vulnerability scanner to see whether these services are running and whether they are vulnerable to attack.

U6.5 How to protect against it:

The following actions will protect against NFS vulnerabilities, including sadmind and mountd:

1. Wherever possible, turn off and/or remove sadmind and mountd on machines directly accessible from the Internet.
2. Install the latest patches:

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

For IBM AIX Software
http://techsupport.services.ibm.com/support/rs6000.support/downloads
http://techsupport.services.ibm.com/rs6k/fixes.html

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

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

3. Use host/ip based export lists
4. Setup export file systems for read-only or no suid where ever possible
5. Use nfsbug to scan for vulnerabilities

Additional information can be found at:

http://www.cert.org/advisories/CA-99-16-sadmind.html
http://www.cert.org/advisories/CA-98.12.mountd.html

U7 - Default SNMP Strings

U7.1 Description:

The Simple Network Management Protocol (SNMP) is widely used by network administrators to monitor and administer all types of network-connected devices ranging from routers to printers to computers. SNMP uses an unencrypted "community string" as its 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 "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.

U7.2 Systems impacted:

All systems and network devices

U7.3 CVE entries:

NOTE: This list is intended to be a complete list of all top priority CVE numbers related to this issue. While there may be other CVE numbers related to this issue, they have been excluded as they have been deemed to be of less importance than those listed here.

CAN-1999-0517, CAN-1999-0516, CAN-1999-0254, CAN-1999-0186

U7.4 How to determine if you are vulnerable:

Check to see if you have SNMP running on your devices. If you do, check the configuration files for the common vulnerabilities:

- Default or blank SNMP community names
- Guessable SNMP community names
- Hidden SNMP community strings

U7.5 How to protect against it:

The following steps will help defend against SNMP exploits:

1. If you do not absolutely require SNMP, disable it.
2. If you must use SNMP, use the same policy for community names as used for passwords. Make sure they are difficult to guess or crack and that they are changed periodically.
3. Validate and check community names using snmpwalk. Additional information can be found at http://www.zend.com/manual/function.snmpwalk.php
4. Filter SNMP (Port 161/UDP) at the border-router or firewall unless it is absolutely necessary to poll or manage devices from outside of the local network.
5. 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

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 rule is to block all unused ports. And 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.

Keep in mind that blocking these ports is not a substitute for a comprehensive security solution. 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, or a person who is an organization insider, for example) can exploit these ports if not properly secured on every host system in your organization.

1. Block "spoofed" addresses-- packets coming from outside your company sourced from internal addresses, private (RFC1918 and network 127) and IANA reserved addresses. Also block source routed packets or any packets with IP options set.
2. Login services-- telnet (23/tcp), SSH (22/tcp), FTP (21/tcp), NetBIOS (139/tcp), rlogin et al (512/tcp through 514/tcp)
3. RPC and NFS-- Portmap/rpcbind (111/tcp and 111/udp), NFS (2049/tcp and 2049/udp), lockd (4045/tcp and 4045/udp)
4. NetBIOS in Windows NT -- 135 (tcp and udp), 137 (udp), 138 (udp), 139 (tcp). Windows 2000 – earlier ports plus 445(tcp and udp)
5. X Windows -- 6000/tcp through 6255/tcp
6. Naming services-- DNS (53/udp) to all machines which are not DNS servers, DNS zone transfers (53/tcp) except from external secondaries, LDAP (389/tcp and 389/udp)
7. Mail-- SMTP (25/tcp) to all machines, which are not external mail relays, POP (109/tcp and 110/tcp), IMAP (143/tcp)
8. Web-- HTTP (80/tcp) and SSL (443/tcp) except to external Web servers, may also want to block common high-order HTTP port choices (8000/tcp, 8080/tcp, 8888/tcp, etc.)
9. "Small Services"-- ports below 20/tcp and 20/udp, time (37/tcp and 37/udp)
10. Miscellaneous-- TFTP (69/udp), finger (79/tcp), NNTP (119/tcp), NTP (123/tcp), LPD (515/tcp), syslog (514/udp), SNMP (161/tcp and 161/udp, 162/tcp and 162/udp), BGP (179/tcp), SOCKS (1080/tcp)
11. 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.)

Appendix B – Signatories

Alan Paller, SANS Institute
Stephen Northcutt, SANS Institute
Eric Cole, SANS Institute

Steve Christey, MITRE
Dave Mann, BindView

RAZOR Research - BindView Development

Clint Kreitner, The Center for Internet Security

Randy Marchany, Virginia Tech
Valdis Kletnieks, Virginia Tech CIRT

Laurie Zirkle, Virginia Tech CIRT

Ron Jarrell, Virginia Tech CIRT

Phil Benchoff, Virginia Tech CIRT

Scott Conti, University of Massachusetts
Hal Pomeranz, Deer Run Associates

Bruce Schneier, Counterpane Internet Security, Inc.
Tina Bird, Counterpane Internet Security, Inc.
Gene Spafford, Purdue University CERIAS
Bob Todd, Advanced Research Corporation

Igor Gashinsky, NetSec, Inc.

Greg Shipley, Neohapsis
Matt Bishop, University of California, Davis
William McConnell, Trend Consulting Services

Viriya Upatising, Loxley Information Services Co.
Marcus Sachs, JTF-CND, US Department of Defense
Ed Skoudis, Predictive Systems
Chris Prosise, Foundstone, Inc.

Sten Drescher, Tivoli Systems
Lance Spitzner, Sun Microsystems GESS Security Team
Jim Ransome, Pilot Network Services
Frank Swift, Pilot Network Services
Jim Magdych, Network Associates, Inc.
Jimmy Kuo, Network Associates, Inc.
Tony Sager, National Security Agency
Larry Merritt, National Security Agency
Bill Hill, MITRE
Billy Austin, Intrusion.com
Christopher W. Klaus, Internet Security Systems
Wayne Stenson, Honeywell
Martin Roesch, Hiverworld, Inc.
Jeff Stutzman, Healthcare ISAC
Gene Schultz, Global Integrity
Kelly Cooper, Genuity
Bill Hancock, Exodus Communications
Ron Nguyen, Ernst & Young
Lee Brotzman, NASIRC, Allied Technology Group, Inc.
Scott Lawler, DoD Cert
Chris Brenton, Dartmouth Institute for Security Studies
Nick FitzGerald, Computer Virus Consulting Ltd.
Shawn Hernan, CERT Coordination Center
Kathy Fithen, CERT Coordination Center
Derek Simmel, Carnegie Mellon University
Rob Clyde, Axent
David Nolan, Arch Paging
Ross Patel, ViaCode Ltd

Afentis Security Team, Afentis Ltd

Mudge, @stake