Results 1 to 1 of 1
To see the top 20 list for more OS's see SANS at http://isc.sans.org/top20.html Top Vulnerabilities to UNIX Systems (U) U1 BIND Domain Name System U1.1 Description The Berkeley Internet Name ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 10-09-2003 #1
- Join Date
- Mar 2003
Top 20 Security Unix Vulnerabilities per SANS
To see the top 20 list for more OS's see SANS at http://isc.sans.org/top20.html
Top Vulnerabilities to UNIX Systems (U)
U1 BIND Domain Name System
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 [b]security upgrades[b/], 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 [b]Linux[b/] 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,
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:
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.
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.
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.
Permit zone transfers only to secondary DNS servers in your domain. Disable zone transfers to parent or child domains, using delegation and forwarding instead.
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.
Disable recursion and glue fetching to defend against DNS cache poisoning
To protect against recently discovered BIND vulnerabilities:
For the Denial of Service Vulnerability on ISC BIND 9: http//www.cert.org/advisories/CA-2002-15.html
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.Dan
\"Keep your friends close and your enemies even closer\" from The Art of War by Sun Tzu\"