Hacking 101

A few times a year, security firm Foundstone sends a handful of its best experts out to the field to teach others how to hack computers.

It's not that they want to encourage such behavior; the company makes its money fending off exactly the sorts of things it teaches. Rather, the point of the class is to show cybercops just what they are up against, and how they can stop culprits in their tracks.

We spent four days watching the watchmen. Small wonder the good guys feel so outnumbered.

Day 1

I meet my classmates. They are no dummies. Most are systems administrators or engineers who specialize in locking up networks so the bad guys won't get in. They come from places like the Federal Aviation Administration, the U.S. Air Force, Genuity and Fidelity Brokerage Services. A small minority, like me, are generalists who have dabbled in Unix but have no particular expertise in networking.

Kevin Mandia, a one-time Air Force investigator, is today's instructor.

A good hacker covers his tracks, of course. But from whom? The system administrators? Maybe. And it's then that Mandia says one of the more disturbing things of the day.

"Is a CEO going to know if you've been hacked? No way." Almost always, he says, it comes down to the technical staff giving the rest of the company the heads up.

Then it hits me the systems administrators aren't just minding the store - these guys are the store.

And their record isn't always good. Mandia summons up the CD Universe case from late 1999. Hackers managed to compromise tens of thousands of credit card numbers by hacking into the company's servers. Everyone knew about it. But when the company tech staff went in to fight off the hack, they didn't bother to make a copy of the hard disks that got compromised. After they were done fighting off the intruders, there wasn't enough evidence left on the disk to take the case to trial.

The lesson, he says, is to pull the plug on the connection so you can copy all the data that was changed.

Throughout the four days, instructors will keep coming back to the importance of response plans and how victims have to have them in place before they are hit. Still, detecting and even performing the hacks themselves is what takes up most classroom time.

We all pore over Unix logs, the text records of what goes on inside a computer when it does its thing. System operators who care about security are supposed to make sure they are turned on. That does not always happen in practice.

I take a look. My thin bit of experience suggests this fellow has managed to take over the machine by impersonating its chief administrator. The problem is, there's no specific message that will tell me that, since the logs' main purpose is to show technicians how their systems are performing. I'm stumped, but it's clear enough our visitor, logged on under a strange user name, is downloading software from elsewhere. Could they be hacker tools? I look to my classmates surely they will know.

Many don't. A half hour of decoding and guessing leads us to the conclusion our culprit broke in with a stolen or guessed password, then flooded the server with more data than it could handle, triggering a response that let him run any program he wanted on the machine. In a few short minutes, he became a "Superuser" authorized to do whatever he wanted.

He set up a log of his own, designed to track what others on the system are doing. He was smart enough to wipe the software he used for the job from the disk.

Day 2

Yesterday, we used ordinary Unix commands to see who was invading our systems. Today, we use the same commands to break in ourselves.

We connect to a computer on the network that, like many, leaves itself open to outside users who know the right passwords, and others who don't.

We use some standard commands that come with every Unix and Linux system out there. First, class members do a quick scan of the target machine, which quickly reveals which Internet services it can supply - Web access, e-mail, whatever. In fact, there's a Web server on board, so we throw a few prepackaged, commonly available programming scripts at the servers.

Dozens of such instructions are floating around the Web, and many of them will take down almost any Web host that hasn't been patched carefully.

Previous observation of the line going into the target gives us the name of a user who frequents the system. Our instructor tells us the password is a Star Wars character. Someone guesses which one in 30 seconds - no need to run an automated password guesser against the target.

Class members have lots of basic Linux knowledge at their disposal and know how to use it. It's a good thing the target server in the room is easy to restore to its original condition: it's pretty well trashed within minutes of entry.

So far, the logs have told us a fair amount about what's going on. Other Linux commands tell us which processes are running on the server, including some hacker's tools. But they can't tell us everything if Knark is running. Get the password of a computer's system administrator - it's not always that hard - and you can install this malicious bit of code. It hides what's going on very thoroughly. So thoroughly, in fact, you will likely have to take the server offline and poke through its innermost guts to detect. We don't run it.

Day 3

We continue talking about response strategies today - what to preserve when you get hit, how to preserve it - the basic things computer jocks need to do to fight the crackers in court.

We learn more about how hackers can hide their tracks, too, down to directory names that may not even show up when administrators ask for a listing of files on a system.

But this time around it's not just paper, but our own laptops that have been hacked. Instructor Will Chan swaps out half of the class' hard disks for ones that have been compromised and tells us to figure out what happened.

My partner has forgotten more about Linux than I know, so I mostly take notes while he does the typing. It seems one Hansolo has penetrated our defenses by feeding the PC too much information when it asked for his name and password. In effect, he has flooded the system with nonsense, then fed it more information that it blindly executes.

The vulnerability is known as a buffer overflow, and it works like a charm. Programmers fixed this particular vulnerability a while ago, but the operating systems we are using are in many ways typical: they haven't been updated.

Hansolo stole in, grabbed some passwords going across the system, then broke into another user's account. Then, he downloaded some program called "deathstar." It looks like he ran this tool against the our computer, transferred some files, and got out, all in the course of a few minutes.

What did he get? What did the program do to us? We can't tell. Like any good burglar, he bound and gagged the machine: Any error messages it might have generated during the break-in were immediately destroyed. We don't find much in the way of fingerprints or muddy footsteps, either; He has wiped the logs of the machine clean. There's no way we can tell what he did while he was inside. And that, we learn, isn't so unusual in this business.

The afternoon and the next morning are more of the same, but this time we follow similar attacks on Windows NT machines, instead of Linux boxes.

We see how Web hosting companies open themselves up to hackers by letting customers use Microsoft scripting languages on their home pages. Likewise, we learn about the dozens of non-Windows scripts hackers can use to attack servers. The names of Windows tools are different, the logs we look at have other names, the overall security of Windows isn't as good as some other operating systems, but it all gets down to the same thing: our infrastructure is riddled with holes, and people with a modicum of skills will always get in somewhere. How much damage they do largely depends on the time and resources people devote to keeping intruders at bay.

The irony of throwing so much labor at processes that are supposed to be automatic is not lost on our presenters.

Instructor Keith Jones, helpful yet demanding throughout the four days, stands talking quietly with his other black-clad Foundstone lecturers. He's happy to talk to me, but subdued. There's something more than a bit creepy about this business, he says. To teach people to do good, you must first teach them how to do evil. No wonder these guys like Star Wars so much.