Networking

SANS/FBI releases latest top 10 Linux/UNIX vulnerabilities

In cooperation with the FBI, SANS has released its annual update to the most exploited Internet security vulnerabilities. This edition of The Locksmith drills down into the top 10 Linux/UNIX vulnerabilities.


SANS and the FBI have once again teamed up and released an updated version of their list of the most exploited IT security vulnerabilities. As usual, this list has been split into Windows flaws and Linux/UNIX flaws. Like the list of the top 10 Windows vulnerabilities, which I covered in a recent article, I have also put together a summary of the Linux/UNIX list.

Linux/UNIX list
The following are the top 10 Linux/UNIX flaws, listed in order starting with the most dangerous flaws.

1. BIND Domain Name System
Number one again is the well-known BIND (Berkeley Internet Name Domain). BIND is critical because it's by far the most popular DNS in use around the world and is, therefore, a popular target for hackers wanting to trigger a Denial of Service (DoS) event.

Please note that the people who developed and support BIND are not really to blame for the many successful attacks. The original holes may have been their fault, but no software is perfect and ISC BIND is quick to provide patches and/or updated versions once a problem is reported. The problem is that administrators tend to run older versions of BIND, because it continues to run well, and don't regularly update their software.

The BIND Web site is replete with warnings to update versions in order to eliminate vulnerabilities, as this is the primary reason so many successful attacks are launched against BIND—there are a vast number of very old and badly configured versions of BIND still in use.

The fact that most Linux/UNIX versions ship with BIND is the reason for its widespread use, and every Linux/UNIX administrator needs to be aware of the multiple vulnerabilities found in older, unpatched versions of BIND.

There are also some general configuration recommendations provided on the SANS/FBI Web page and applying them will greatly reduce potential vulnerabilities, even if you aren't able to keep up with the latest patches.

2. Remote Procedure Calls (RPC)
RPC is the tool that allows a program on one computer to run software on a remote computer, and it is responsible for much of the usefulness of networks. RPC can be used to remotely administer computers, making it a vital tool for managing today's complex networks.

One of the biggest threats posed by RPCs is the fact that they often unnecessarily execute with elevated privileges, which can give an attacker easy access to the root (administrator) user account. RPC is often enabled on systems and is, therefore, a threat to most Linux/UNIX installations because unneeded RPC services are often enabled. The first step in reducing RPC threats is to remove these unnecessary services.

SANS offers suggestions on how to lock down unneeded RPC services. Because most installations can't just close all RPC services, this is one of those critical features that administrators must regularly maintain. The fact that it keeps showing up on these vulnerability lists shows that many systems aren't being configured or maintained to properly handle RPC.

3. Apache Web Server
Apache is very popular and is widely used. It is also less vulnerable to hacks than Microsoft's IIS, but that doesn't mean there is no need to update Apache or regularly check for newly discovered vulnerabilities. Some administrators who get hit with Apache hacks may not even be aware it's on their systems because it's often part of the default installation.

This would seem like a no-brainer, but if you don't need the Apache server, don't run it on your system. Of course, between all the legacy systems that admins have to manage and the dozens of patches and other vulnerabilities to deal with on an urgent basis, is it any wonder that there are a lot of older Apache versions out there that either shouldn't be running or that aren't patched?

If you do need to run Apache, there are things you can do to reduce the risk even if you can't patch it every time a new vulnerability is discovered: 1.) Don't run Apache as root, 2.) Disable any scripting languages you don't really need, and 3.) Run Apache in a chroot environment whenever possible.

4. General UNIX Authentication Accounts with No Passwords or Weak Passwords
Now this one really is a no-brainer and many administrators will automatically dismiss this, but the fact is that it's still one of the most exploited vulnerabilities. I believe that my readers are probably too savvy to ignore the threat of weak passwords when configuring new systems, but consider whether you are managing legacy systems configured by someone else. I suspect that one reason so many systems are vulnerable to weak passwords are these legacy installations.

Another reason for this vulnerability is a simple and seemingly reasonable procedure that you probably don't even realize is dangerous. I'm referring to the common practice of using the same password for all new accounts. Even if you enforce a policy of resetting this at the first login, there is still a period when a password that is widely known to many current and former employees will be valid.

5. Clear Text Services
Sniffer attacks are common, and the fact that many Linux/UNIX services such as FTP don't encrypt any part of the session, even the logon information, makes this a popular attack vector. Tcpdump will show you any clear text transmissions, and administrators should use it to look for vulnerabilities; after all, hackers do. To reduce the risk, consider using HTTPS, POP2S, or other encrypted alternatives to replace the common plain text services.

6. Sendmail
The widespread use of Sendmail as a mail transfer agent means that known vulnerabilities in older or unpatched versions are a common target. Other than responsible patching policies, the main ways to reduce the risk from Sendmail are to either disable it when it is not needed or run it in daemon mode when you need it.

7. Simple Network Management Protocol (SNMP)
Since SNMP is often enabled by default, it's one of those services that must be maintained if you can't disable it. The SANS Institute offers a free SNMP scanning tool. Just send a blank e-mail to snmptool@sans.org to getmore information.

8. Secure Shell (SSH)
SSH is an important security tool, but many installations of it aren't being properly maintained or configured.

9. Misconfiguration of Enterprise Services NIS/NFS
The main threat here is probably the fact that this is often enabled by default, whether it is needed or not, and is, therefore, rarely maintained effectively.

10. Open Secure Sockets Layer (SSL)
There are a lot of holes in older OpenSSL libraries and, because it is often used by other services such as Apache or even Sendmail, it may not be maintained properly.

Final word
The newest Top 20 vulnerabilities list isn't really much different from the earlier SANS/FBI vulnerability lists, but that makes it all the more important that every administrator look it over carefully. These are the holes that hackers know they can exploit, and far too many systems remain vulnerable to them even after years of warnings.

If you're going to devote energy to fixing vulnerabilities, you should probably start with these first. Every administrator is swamped with new threat announcements and new patches, but taking the time to fix these commonly-exploited flaws will pay off. Of course, not all of these vulnerabilities can be fixed with a simple patch, but there are steps administrators can take to reduce the impact of even those basic soft spots in operating systems and applications that are inherent in the very structure of the software.

Once again, the top lesson to be learned from this list is probably the need to know what services are running on your system and disable any that aren't really needed.

Also watch out for…
The security company @Stake has announced an HREF Tag buffer overflow vulnerability in the Opera browser. The bug is identified as CVE CAN-2003-0870 and can allow a remote attacker to run arbitrary code on vulnerable systems. For those who wish to track such things, the problem was reported to Opera on September 9, acknowledged quickly, patched on October 15, and @Stake released the advisory five days later.


Editor's Picks