|< Day Day Up >|
Identifying Security Holes in Your Systems
The thing to remember about computer security is that it is like any other kind of security. The average computer troublemaker is going to pick the targets of opportunity and ease. Yes, there are master system crackers who go after particular targets and work on them for months or even years using physical, social, and technical means. And like physical security, if someone really wants to break into your computer and they have enough money, time, and resources to dedicate to it, then they probably will succeed. However, unless you are working for a bank, government institution, or Fortune 500 company, you probably don't have to worry about these über-hackers coming after you. What you do have to worry about is the rank-and-file computer criminals and the automated worms and viruses. Your job is to make sure your network has fewer security holes than the next guy's so that they will pass you over when looking for a system to crack. Just like a car with an alarm, The Club, and an Immobilizer—only a really dedicated car thief is going to try to steal it.
Just a very small percentage of computer criminals actually research and develop their own attack methods. Most hackers operate by using published and known security holes and tools to figure out how to get into your computers. These can be found in any number of Web sites, and hacking tools are available for downloading to exploit these holes.
Of the major Internet outages caused by computer crime, all of them have come from the exploitation of security holes that been known for some time before the incident. Usually the outbreak comes months or even years after the underlying vulnerability became known. The Code Red outbreak in 2001 used a vulnerability that had had a patch available for over a year; the same with the Nimda worm. The SQL Slammer worm that went after SQL databases in February of 2003 also had had a fix available for six months before it hit. The fact is that most computer break-ins use methods and vulnerabilities that are well known and have had patches or solutions available for them. The use of so-called zero-day exploits and unpublished security holes is relatively rare.
Why don't people keep up with these things and patch their systems? If they did, then there would be a lot less computer crime and books like this probably wouldn't exist. However, for a myriad of valid reasons, there continue to be plenty of systems with plenty of vulnerabilities.
Another thing that makes hackers' jobs easy is that there are usually several different ways into a system. In fact, with lots of services running, there might be a dozen or more potential windows for entry on an Internet-connected server. If one type of attack doesn't work, they can always try another. The following sections describe some of the potential ways that someone with the right knowledge can cause havoc on your company's system. Some of them may not apply to your network, but chances are that you will have at least two or three of these potential sources of vulnerability.
As I mentioned in Chapter 4, buffer overflows are by far the most popular way to exploit a system. The first documented use of a buffer overflow was the original Internet worm released by Robert Morris on November 2, 1988. It was called the Morris worm after its author, and was designed only to prove the point that it could be done. It worked by exploiting a bug in the finger program and propagating itself from one machine to another. It used poor configuration in Sendmail and rsh to replicate itself. It was supposed to copy itself only to a few systems. However, Morris made a mistake in the coding of the worm and it rapidly spread all over the Internet, which was then only a few thousand systems. It brought major universities and other institutions to their knees as they tried to cope with the rapidly spreading bug. It was the dawn of a new age for computer hackers and opened the eyes of many who thought that the Internet was a safe and friendly place. Since then, buffer overflows have been found in just about every major program and are used frequently by those seeking unauthorized access to systems.
How do you protect yourself from buffer overflows? Well, unless you feel like debugging every piece of software you have (which assumes you have access to the source code as well!), you have to wait for someone to discover the bug and report it and then for the software company to issue a patch. Unfortunately, keeping up with patches and which ones apply to you can be a full-time task—not to mention testing and applying them. Many companies just opt not to bother, yet even companies that are diligent in the patching process often are behind by sheer virtue of scheduling downtime. Even Microsoft had some of its own systems taken down during the SQL Slammer outbreak because some of its SQL servers weren't updated with the patch that they themselves released! One good way to know if you have buffer overflow conditions on your applications is to test them with vulnerability scanning software. This will detect most known buffer overflows that exist on your system and help keep you up to date on patches that are needed to remedy these conditions.
Router or Firewall Weaknesses
These devices are the first line of defense against outsiders coming onto your corporate network. However, due to the increasing complexity of the devices and sophistication of attackers, they can be poor defense mechanisms if they aren't configured correctly. Learning the Cisco IOS router language is a career in itself. If a company doesn't have a Cisco technician on staff, it is probable that their Cisco routers are not configured optimally for security. And firewalls can be even more difficult to configure. As you learned in Chapter 3, one wrong configuration line can negate the protection a firewall offers. A harried technician trying to set up access for employees or outside parties will often err on the side of more access rather than better security in the effort to get the job done.
Even when the rule sets are well written, routers often run weak or dangerous services. Many routers still rely on Telnet for interactive logins rather than a secure application such as SSH. This opens the door for sniffer attacks to grab login and password combinations. Some routers still run finger and other information-leaking services as well.
And even though firewalls are supposed to be the most secure devices, they are not immune to attacks. Some firewalls sit on top of regular operating systems, such as Windows or UNIX, and thus can be vulnerable to all the normal OS-level exploits. Even if the firewall operating system is proprietary, exploits have been found in them. Many firewalls use a Web server to interface with users, and that can be exploited via holes in the Web interface as well. Securing these frontline defenses is critical and should be one of your first priorities.
Also, firewalls tend to provide a security that is "crunchy on the outside, chewy inside" (analogy courtesy of Bill Cheswick). This means that they are hard to penetrate coming from the outside, but offer almost no protection if you are being attacked from within. You should make sure your systems internally are at least minimally secure and not depend on the firewall for all your network security.
Web Server Exploits
Almost every company has to run a Web server these days—not having a Web site is like not having a telephone or fax number. However, Web servers are notorious for having bugs and security holes in them. The very idea of a Web server—that a user can pull files from the server without any authentication at all—sets up the potential for security gaps. The large number of holes is due to the ever-expanding number and types of protocols and commands that Web servers have to deal with. When Web pages just consisted of HTML, it was much easier to control things. But now Web servers have to interpret ASP, PHP, and other types of traffic that contain executable code, and as Web applications get more complex, these issues will only increase.
Some Web servers are more secure than others, but they have all had their problems. And a hacked Web server can mean more than just embarrassment from a defaced Web page if that server also accesses a database and other internal systems, which is common these days.
Mail Server Exploits
E-mail has become vital for companies to communicate in the electronic age. However, mail servers have traditionally been a favorite target of attackers. The original mail transfer agent, Sendmail, was riddled with vulnerabilities and continues to cause security professionals fits. And Microsoft's flagship mail server, Exchange, is not much better. Web and mail servers usually represent a company's most exposed points.
The servers that control and maintain your company's domain names offer hackers an enticing target. Berkley Internet Naming Domain (BIND), which is the primary DNS server, has consistently been in the list of top ten exploited services. DNS is an older program and its structure lends itself to potential holes (one monolithic binary rather than a more modular architecture). DNS often is run as root, which makes it all the more dangerous if it is co-opted. Also, because DNS is hard to set up and little understood, it often is misconfigured and ill secured. The firewall settings for DNS are often not properly configured, with most system administrators allowing unfiltered access in and out.
While Web, mail, and other services have more visibility and get more attention from the IT staff, DNS holes offer the quickest and easiest way to take your company off the Internet map. Even if you have IP connectivity to the world, without valid DNS service for your domains no one will be able to reach your Web servers and no mail will go through. In fact, DNS has been cited as the weakest point in the whole Internet infrastructure and a potential target for cyberterrorism attacks. Rather than crack into your servers or break through your firewalls, an attacker can simply launch a denial of service against your DNS service, effectively taking your firm off the air. Or worse, using a type of attack called DNS cache poisoning, Web surfers bound for your site will be redirected to a site the hacker chooses.
More company Web sites are offering external access into their databases. For example, you might allow customers to place and check the status of orders online, allow employees to get information on benefits programs via the Web, or let vendors access your system to automatically update ship times. All of these functions usually access an internal company database. This takes Web sites beyond the one-dimensional, online brochures they were in the early days of the Internet and makes them an extension of your systems to external users. However, doing this opens up a big potential source of vulnerabilities. These are often systems that have not been hardened for external use. In other words, they assume that the users will be benign and not do overtly hostile things. Web front-end software such as ColdFusion and PHP have been found to be lacking in proper authentication controls and contain bugs such as buffer overflows. Specially crafted URLs can send SQL or other database commands straight into the heart of your system. The SQL Slammer worm that spread quickly worldwide in early 2003 using weaknesses in Microsoft's SQL Server showed how this can happen.
User and File Management
This area is one of the stickiest in info-security. You have to provide your users with the access to the systems and programs that they need to do their work. However, a key principle of good security is that of least privilege, the concept of giving users the minimum access that they need to do their job—and no more. Finding that level is the tricky part. Give them too little access and you will be barraged by help desk calls and complaints; give them too much access and you weaken the security of your system. Most administrators will err on the side of more relaxed access rules because it means less work for them.
Unfortunately, user-friendly systems like Windows also lean in this direction by setting up many permissions at their weakest level: poor security by default. Windows has some built-in accounts and shares that it uses for system-level operations that have more access than they really need. One example is the IPC (Inter-Process Communication) share, a default share on Windows that can be used by any user to gain information about that machine or domain. The default guest account can be used in a similar way. You can disable or limit these accounts, but you have to do it manually after installation. To Microsoft's credit, these types of default accounts have been limited in Windows XP, but the accounts still exist (they are necessary for the simple peer-to-peer networking that Windows allows). And UNIX systems aren't much better. The lack of granularity in account management, that is, there is only root and non-root, makes it hard to keep from handing out root-level access to many people.
And of course, keeping your user account list current can be a daily task with larger networks. Idle or unused accounts are considered valuable targets for hackers because they can use them without worry of the real owner suspecting foul play.
Manufacturer Default Accounts
In trying to make life easier for you, vendors often make your security job much harder. Many hardware manufacturers ship their hardware with standard default logins and user accounts to enable easier set up. Some of them also put in accounts for technicians and service representatives. You are supposed to immediately change these passwords when you install the equipment or software, but many people don't. The result is that many machines can be accessed simply by someone trying any number of default user account and password combinations. Routers, switches, phone systems, and other types of hardware are more likely to have these kinds of vulnerabilities than UNIX or Windows systems. However, there are exceptions. There is a whole protocol that is based on the idea of default passwords. SNMP (Simple Network Management Protocol) was designed to enable software to automatically poll devices and determine basic information about them (for example, the up/down status). In some cases, SNMP lets you even perform simple configuration operations. It was a good idea in concept, and many companies have designed network management systems around this protocol. However, in implementation, manufacturers defaulted to using two main accounts, "public" and "private," as their community strings or passwords. Using these passwords, anyone on the network can poll your devices to find out the status.
SNMP also allows basic commands to be sent to the devices, such as resetting a router or dropping an interface. Very few users of SNMP bother to change their default community strings because it would be a hassle to do that on every machine. The result is that a hacker with a simple tool such as snmpwalk, which is available on the Internet for free, can gather information on your network, map it out, and possibly even take it down if you are running SNMP with these default community strings. To add fuel to this fire, recent exploits of the SNMP protocol using a buffer overflow allows hackers to take over the remote machine entirely. Many people who don't even use SNMP are running it on their machines because manufacturers often turn it on by default to allow for easy network identification.
Another software-based example is the default sa account built into Microsoft's SQL server. This account is used by inter-system processes, but it can also be accessed by a script or worm, as demonstrated with the disruption caused by the SQL Slammer worm. There are sites on the Internet that list all the major hardware manufacturers and software vendors and any default passwords that may exist. And of course, there are automated programs that can try them all very quickly without a lot of effort.
Blank or Weak Passwords
While it may seem insane to have accounts with blank passwords, many networks do just that. And believe it or not, some even do this with the administrator account. It is also unexpectedly common to see login/password combinations of administrator/administrator, which is the default installation of Windows. It is not uncommon for worms and hacking programs to automatically check for this condition. If they find it, they have hit the gold mine: full administrator access to the system. Also, when users are setting passwords, they can simply leave their passwords blank. This allows anyone who has a user list to walk through the list, trying for blank password accounts. You can set your password policies to not allow this condition as well as to strengthen the length and complexity of the passwords. Requiring passwords to be changed on a regular basis and getting rid of accounts that have never logged in is also a good idea. Vulnerability scanning will check for these conditions.
Like a vestigial tail, there are often applications running on our machines that no longer serve any useful purpose. These services may be part of an earlier set of libraries that the programmers built on and never bothered to take out. This is one of the downsides of ever-increasing processing power and memory capacity. Programmers used to carefully ration every byte they used and would never allow unnecessary lines in their code. However, in this age of bloat-ware and gigabyte-sized operating systems, it is often easier to leave legacy services in rather than risk breaking some other program that depends on them. The incredible thing is that these services are often turned on by default. Table 5.1 lists services that no longer have a use and can generally be safely turned off.
When hackers or crackers are looking to get into a system, they start by doing some basic reconnaissance. They try to find out as much about your system and network before trying break in. Just like burglars casing a neighborhood, they look for the electronic equivalent of lights off, newspapers stacking up, loose windows, and so on. They do this with a number of tools, like port scanners and other hacking tools available on the Internet. Unfortunately, many operating systems are all too eager to help out these illicit information gatherers. Like chatty doormen, they give out vital system information without so much as an ID card.
Windows is particularly guilty of these transgressions. Because it was designed to be a plug-and-play network system, it offers all kinds of information to any system that polls it with the right commands. As mentioned earlier, incorrectly configured DNS servers can also expose a lot of information about your network configuration. Finally, an amazing amount of information can be gleaned from using public search engines such as Google. People often leave things in public directories of Web servers, thinking that just because they aren't linked from a Web page they won't show up in search engines. This is not true and you should definitely make a practice of regularly "Googling" your company's name and URLs to see if anything interesting comes up.
With this data, an outside user can generate user lists, shared drives and directories, system names, employee names, and other information. They can then leverage this data to perform brute force hacking by trying different password combinations using automated programs. Or they can use it in a social engineering attack (see the sidebar on system cracking).
Denial of Service
If they can't gain access to your system, many computer criminals are just as happy to take down your system so that nobody else can use it. This is especially true of high-profile sites or political targets. In the case of large e-commerce operations, this can cost millions of dollars per hour of downtime. Denial of Service (DoS) can come in many forms, from simply swamping the main routers with traffic to actually taking advantage of a weakness in a program to crash that service and therefore the server. The former is hard to protect against, but the latter are very preventable by identifying and then fixing or eliminating the condition that allows the DoS attack.
|< Day Day Up >|