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
l 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
l 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
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:
¡ Statd: http://www.cert.org/advisories/CA-2000-17.html
snmpXdmid 100249
http://www.cert.org/advisories/CA-1999-05.html http://www.cert.org/advisories/CA-1997-26.html
¡ Tooltalk: http://www.cert.org/advisories/CA-2002-26.html http://www.cert.org/advisories/CA-2002-20.html http://www.cert.org/advisories/CA-2001-27.html
¡ Calendar Manager: http://www.cert.org/advisories/CA-2002-25.html http://www.cert.org/advisories/CA-1999-08.html
¡ Cachefsd: http://www.cert.org/advisories/CA-2002-11.html
¡ Sadmind: http://www.cert.org/advisories/CA-1999-16.html http://www.cert.org/advisories/CA-2001-11.html
¡ Mountd: http://www.cert.org/advisories/CA-1998-12.html
¡ SnmpXdmid: http://www.cert.org/advisories/CA-2001-05.html
¡ Rwalld: http://www.cert.org/advisories/CA-2002-10.html
¡ XDR: http://www.cert.org/advisories/CA-2003-10.html
¡ Microsoft RPC: http://www.cert.org/advisories/CA-2003-16.html http://www.cert.org/advisories/CA-2003-19.html
back to top ^
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.
¡ http://httpd.apache.org provides the most recent versions and patch levels available.
¡ Source code for the most recent version(s) of Apache is available at http://httpd.apache.org/download.cgi
¡ The latest patches are available at http://www.apache.org/dist/httpd/patches/
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.
¡ Modify the default Apache HTTP response token.
1. For Apache 1.3.x see
http://httpd.apache.org/docs/mod/core.html#servertokens http://httpd.apache.org/docs/mod/core.html#serversignature.
2. For Apache 2.0.x see http://httpd.apache.org/docs-2.0/en/mod/core.html#servertokens.
¡ Ensure that mod_info is not accessible from the Internet.
¡ Directory indexing should be disabled.
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.
¡ http://www.w3.org/Security/Faq/wwwsf3.html#SVR-Q5
¡ http://www.modsecurity.org/documentation/apache-internal-chroot.html
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:
¡ For Apache 1.3.x see: http://httpd.apache.org/docs/logs.html
¡ For Apache 2.0.x see: http://httpd.apache.org/docs-2.0/logs.html
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.
¡ http://www.modsecurity.org
¡ http://www.securityfocus.com/infocus/17064.152.44.126 152.44.126 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
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