Why Do I Have to Tighten Security on My System? (Why Can't I Just Patch?)

Even if you patch your system regularly and follow all security updates, you can still be vulnerable. This article delves into the levels of hackers and why extra security is a must.

 By Jay Beale
Page 1 of 2
Print Article

Again and again, when considering system security, people tell me, "I already patch my system." I try to explain to them, as I will here, why they're still vulnerable, even if they patch and read BugTraq regularly. To this end, I'll visit the following topics:

  • Levels of Cracker-dom
  • The Way of the Script Kiddie (Methods)
  • Common (Failed) Attempts to Halt the Kiddie
  • The Lifecycle of the Modern Security Vulnerability
  • Really Stopping the Kiddie!

Levels of Cracker-dom

We can think of system crackers ("hackers") of falling into three tiers of ability - I'll use a strange, but hopefully effective, analogy with photographers:

Tier I - The Professional

This person really knows what he's doing. He finds vulnerabilities in existing programs and writes his own exploit code from scratch. He's very knowledgeable and often rather experienced and may even be doing this for a living. This guy is like the photographer who builds his camera from scratch, or at least makes his own repairs. While this type of cracker is very rare, consider him very dangerous. He'll be very stealthy when he cracks your system - if you even notice him, you probably spent a lot of time on your Intrusion Detection Systems.

Tier II - Mid-level, Knowledgeable Types

This person probably works as a UNIX programmer or system administrator by day. He often uses pre-written, higher-level tools, like nmap and netcat. In some cases, he'll use others' exploit code, but he's not reliant on others to provide one-shot easy- to-use scripted cracks. He'll often code his own vulnerability scanners, by combining tools with his own C, Perl or shell code. When he does get root on a new system, he knows what he's doing and covers his tracks fairly well. He's like the photographer who knows enough to carefully select his own filters and lenses, take a well- constructed shot and then develop his own film when he gets home. This cracker is somewhat more common than the Pro, but usually picks his targets selectively and isn't interested in your system.

Tier III - L33t Script Kiddie d00d3z

This is your average system cracker. He's not especially knowledgeable. He downloads his exploit scripts from Web sites and often barely understands what he's doing. Once he does root your system, he may not even know basic UNIX commands - some will even try DOS commands at the root prompt! This guy is the weekend photographer who uses the disposable one-button auto-everything camera and tends to remove film before he's rewound it. These crackers are dangerous, if only because there are so many of them - if one of them has a 1/10% chance of successfully compromising your system, but 100 of them are trying, there's a 1 in 10 shot you're getting cracked. This type of cracker is incredibly common on the Internet and, as I hope to show you below, is the bulk of the problem.

Hardening your system is effective against all three classes of cracker, but we're going to discuss the Kiddie here, as he represents the simplest, yet most common, case that can be easily stopped.

The Way of the Script Kiddie

The script kiddie uses two basic types of exploit: remote exploits and local exploits. He can run a remote exploit against your system from some other host on the Internet, while he can only run a local exploit from an account on your system itself. Remote exploits are far, far less common, but rather dangerous. We'll consider this type first.

Our script kiddie scans cracker/security web sites, ftp sites and irc channels regularly for new remote exploits. Few exist and even fewer actually work, but he'll tend to find one or two that do work. Next, he'll download and run a scanner that can look for vulnerable boxes that he can attack with these scripts/programs.

This is key: the script kiddie is indiscriminate. His exploit only works against a small percentage of machines on the Internet, so he's got to scan a large portion of it to find vulnerable hosts. The last time that I cleaned up a hacked machine, I found that the cracker had been scanning the IP range - for Solaris hosts with a vulnerable sadmind available - this range includes the entirety of a major home user ISP! I learned about my cracked machine not from IDS, but from cable modem users who he had scanned!

The kiddie can scan a large IP range in hours. He'll usually log off and let his scanner run, coming back for the listing of vulnerable machines later. When he comes back, he'll methodically break into each one with his exploit, set up shop, and decide what to do with his new box. Before we talk about what he does next, let's consider the class of local exploits.

Our kiddie also uses local exploits which require1 a shell account on a vulnerable system. To get accounts that he can use for this, our kiddie will generally set up a sniffer on a system that he's already compromised. The sniffer, or "protocol analyzer," will grab thousands of name/password pairs from each telnet/ftp/pop/imap session to or from the compromised system. Each of these pairs represents an account he can now steal - these accounts will be not only on the compromised system, but also on lots of remote systems!

Using one of these stolen name/password pairs, the kiddie will now log in to one of our systems. At this point, he'll try to figure out what version of the O/S (Linux, FreeBSD, Solaris...) that we're running, so he can download local exploits. He'll usually download these by running an ftp client on our system to grab exploits from his favorite site. He'll even use our system to compile any C exploits that he downloads.

Each exploit is against a particular vulnerable local program that runs with root privilege. This program might be a Set-UID root program like dump or at, or a local system daemon, like gpm. On Red Hat 6.0, he might use userrooter.sh to exploit the Set-UID root program userhelper. Once he's found an exploit for such a program, he'll run his exploit to turn his ordinary user privilege into root privilege. This method, where he gets an unprivileged account and then leverages this to get root, is called "escalation of privilege."

What does our script kiddie do once he does get root, through either method? He sets up shop! He'll create additional accounts, plant back doors so he can get back in and Trojan existing programs. He'll often install a rootkit, replacing common programs, like ps, ls, and top, with versions that will hide his activities. He may even patch your system, to stop other crackers from using the same hole he used! In any case, he might inhabit your system quietly, running a sniffer or an IRC bot from your box, or he may make a total nuisance of himself, using your system as a launchpad to scan or attack other systems. In either case, you'd probably prefer if he never got root in the first place!

Common (Failed) Attempts to Halt the Kiddie

How do we halt the script kiddie? One common approach is to simply "not have any vulnerabilities!" Strike 1! This fails, because every publicly available operating system, even the venerable OpenBSD, seems to have bugs that lead to security vulnerabilities. Well then, you say, what if we turn off every vital service? Strike 2! In this case, our machine becomes quite useless and the kernel may still be vulnerable! OK, OK, you say, I'm a good admin! I patch! Most (good) sysadmins take this approach, whereby they patch the hell out of their machines, as rapidly as the patches come out. But this too fails. Strike 3! Patching, unfortunately, fails to protect you in many cases because it doesn't account for both undiscovered bugs and discovered, but unfixed, bugs. Actually, even if you read BugTraq and fix bugs before official patches are released, you still have non- trivially long windows of vulnerability. We'll consider this last bit in greater depth now, as we discuss the lifecycle of the modern security vulnerability.

This article was originally published on Oct 16, 2000
Get the Latest Scoop with Networking Update Newsletter