The Art of Intrusion: The Real Stories Behind the Exploits of Hackers, Intruders and Deceivers (24 page)

tend to think of hacker break-ins as something more like an "Oceans Eleven" strategic attack, the sad truth is that most of these attacks aren't ingenious or clever. They are, instead, successful because a large portion of enterprise networks are not adequately protected.

Also, the people responsible for developing and placing these systems into production are making simple configuration errors or programming oversights that create an opportunity for the thousands of hackers bang- ing on the front door every day.

If the two financial institutions described in this chapter give any indi- cation of how most of the world's banks are currently protecting client information and funds, then we may all decide to go back to hiding our cash in a shoebox under the bed.

NOTES 1. Though he didn't specify the site, this information is available at www.flumps.org/ip/.

Your Intellectual

Property Isn't Safe If one thing didn't work, I'd just try something else because I knew there was something that would work. There is always something that works. It's just a matter of finding out what.

-- Erik

W

hat's the most valuable asset in any organization? It's not the

computer hardware, it's not the offices or factory, it's not

even what was claimed in the once-popular corporate clich� that said, "Our most valuable asset is our people."

The plain fact is that any of these can be replaced. Okay, not so easily, not without a struggle, but plenty of companies have survived after their plant burned down or a bunch of key employees walked out the door. Surviving the loss of intellectual property, however, is another story alto- gether. If someone steals your product designs, your customer list, your new-product plans, your R&D data -- that would be a blow that could send your company reeling.

What's more, if someone steals a thousand products from your ware- house, or a ton of titanium from your manufacturing plant, or a hundred computers from your offices, you'll know it immediately. If someone electronically steals your intellectual property, what they're stealing is a copy and you'll never know it's gone until long afterward (if ever), when the damage is done and you're suffering the consequences.

So, it may come as distressing news that people with hacking skills are stealing intellectual property every day -- and often from companies that

153 154 The Art of Intrusion

are probably no less security-conscious than your own, as suggested by the two examples in this chapter.

The two guys in the following pair of stories belong to a special breed referred to as crackers, a term for hackers who "crack" software by reverse-engineering commercial applications or stealing the source code to these application programs, or licensing code, so they can use the soft- ware for free and eventually distribute through a labyrinth of under- ground cracking sites. (This use is not to be confused with "cracker" as a program for cracking passwords.)

Typically, there are three motivations for a cracker to go after a partic- ular product:

To obtain software that he or she has a special interest in and

wants to examine closely.

To tackle a challenge and see whether he or she can outwit a

worthy opponent (usually the developer), just the way some-

one else tries to outwit opponents at chess, bridge, or poker.

To post the software so it's available to others in a secret

online world that deals in making valuable software available

free. The crackers are not just after the software itself but also

the code used to generate the licensing key.

Both characters in these stories are compromising target software man- ufacturers to steal source code so they can release a patch or key genera- tor ("keygen"), the very proprietary code used for generating customer license keys, to cracking groups so that they can essentially use the soft- ware for free. There are many people with hacking skills that are doing the same thing, and these software businesses have no idea how hard they are getting hit.

Crackers dwell in a dark, well-hidden world where the coin of the realm is stolen software -- intellectual property theft on a scale you will likely find stunning and frightening. The fascinating last act of the story is detailed near the end of the chapter, in the section "Sharing: A Cracker's World."

THE TWO-YEAR HACK Erik is a 30-something security consultant who complains that "When I report a vulnerability, I often hear, `It's nothing. What's the big deal? What's that gonna do?'" His story demonstrates a much-ignored truism: It's not just the big mistakes that will kill you. Chapter 8 Your Intellectual Property Isn't Safe 155

Some of the following may seem, for those with limited technical knowledge of the approaches used by hackers, like rather heavy slogging. What's fascinating about the chronicle, though, is the way it reveals the persistence of many hackers. The events related here, which took place quite recently, reveal Erik to be, like so many others in these pages, dur- ing the day an ethical hacker was helping businesses protect their infor- mation assets but was lured into the thrill of hacking into unsuspecting targets at night.

Erik belongs to that special breed of hackers who set their sights on breaking into a place and stick to the task until they succeed ... even if it takes months or years.

A Quest Starts A few years ago, Erik and some long-distance hacker buddies had been collecting different types of server software and had reached the point where they "owned the source code" of all the major products in the category . . . with only a single exception. "This was the last one I didn't have," he explains, "and I don't know why, it was just interesting to me to break into that one." I understand the attitude perfectly. Erik was into trophy hunting, and the more valuable the asset, the bigger the trophy.

This last one to make Erik feel complete turned out to be more of a challenge than he had anticipated. "There are some sites that I want to break into, but they are truly difficult for some reason," he explains sim- ply. I can relate to that attitude, as well.

He began in a familiar way, with "a port scan of the Web server that is probably the first place I look when I'm trying to break into Web servers. There's usually more exposure there. But I couldn't find anything right off." It's common to probe a target lightly when getting started with an attack to avoid generating alerts or being noticed by an administrator because of entries in the logs -- especially these days, since many compa- nies are running intrusion-detection systems to detect port scans and other types of probes commonly used by attackers.

For Erik, "there's a few ports I'll look for that I know are going to be interesting targets." He rattles off a list of numbers for the ports used for the Web server, terminal services, Microsoft SQL server, Microsoft Virtual Private Network (VPN), NetBIOS, mail server (SMTP), and others.

On a Windows server, port 1723 (as mentioned in Chapter 7, "Of Course Your Bank Is Secure -- Right?") is ordinarily used for a protocol known as point-to-point tunnel, which is Microsoft's implementation of VPN communications and uses Windows-based authentication. Erik 156 The Art of Intrusion

has found that probing port 1723 "gives me an idea of what kind of role the server plays" and, as well, "sometimes you can guess or brute-force passwords."

He doesn't even bother trying to hide his identity at this stage because "there's so many port scans [a company] will get every day that no one even cares. One port scan out of a hundred thousand in a day, it doesn't mean anything."

(Erik's assessment of the low risk of being detected and possibly iden- tified is based on his risky assumption that his port scans will be buried in the "noise" of the Internet. True, the target company's network admin- istrators may be too overworked or lazy to examine the logs, but there's always a chance he'll run into a zealous type and get busted. It's a chance more cautious hackers are not willing to take.)

Despite the risk, in this case the port scans didn't turn up anything use- ful. Then, using a custom-built piece of software that worked much like a common gateway interface (CGI) scanner, he found a log file generated by the "WS_FTP server," which contains, among other things, a listing of the filenames that were uploaded to the server. It's similar to any other FTP (File Transfer Protocol) log, Erik says, "except that the log was stored in each directory that files were uploaded to," so when you see a file listed in the log that looks interesting, it's right there -- you don't have to go hunting for it.

Erik analyzed the FTP log and found the names of files that had been recently uploaded to the "/include" directory, a directory ordinarily used to store ".inc" file types -- common programming functions that are from other main source code modules. Under Windows 2000, these files are by default not protected. After reviewing the list of filenames in the log, Erik used his Internet browser to view the source code of particular filenames he thought might contain valuable information. Specifically, he looked at files that might have included the passwords for a back-end database server. And he eventually hit pay dirt.

"At that point," Erik said, "I probably made ten hits to the Web server -- you know, still nothing major in the logs." Although his dis- covery of the database passwords was exciting, he quickly found that there was no database server on that box.

But from there, things turned "interesting."

I couldn't find anything on that Web server, but I had a [software]

tool I made that guesses host names based on a list of common host

names -- like gateway, backup, test, and so on, plus the domain

name. It goes through a list of common host names to identify any

host names that may exist in the domain. Chapter 8 Your Intellectual Property Isn't Safe 157

People are pretty predictable in [choosing hostnames], so it's pretty

simple to find the servers.

Finding the servers was easy enough, but it still didn't lead him any- where. Then it struck him: This company wasn't in the United States. So "I used that country's extension, and tried it with a whole bunch of the hosts I had found with my host name scanning tool." For example, for a Japanese company it would be

hostname.companyname.com.jp

That led him to discover a backup Web and mail server. He accessed it with the passwords he had found in the "include" (.inc) source files. He was able to execute commands through a standard system procedure (xp_cmdshell) that permitted him to run shell commands under whatever user the SQL server was running -- usually under a privileged account. Triumph! This gave him full system access to the Web/mail server.

Erik immediately proceeded to dig into the directories looking for backups of source code and other goodies. His main objective was to obtain the keygen -- as mentioned, the very proprietary code used for generating customer license keys. The first order of business was gather- ing as much information about the system and its users as possible. In fact, Erik used an Excel spreadsheet to record all interesting information he found, such as passwords, IP addresses, hostnames, and what services were accessible through open ports, and so forth.

He also probed hidden parts of the operating system that the amateur attacker generally overlooks, such as Local Security Authority (LSA) secrets, which stores service passwords, cached password hashes of the last users to log in to the machine, Remote Access Services (RAS) dial- up account names and passwords, workstation passwords used for domain access, and more. He also viewed the Protected Storage area where Internet Explorer and Outlook Express store passwords.1

His next step was to extract the password hashes and crack them to recover the passwords. Because the server was a backup domain con- troller, mail server, and secondary Domain Name Service (DNS) server, he was able to access all the DNS resource records (including, among other things, hostnames and corresponding IP addresses) by opening the DNS management panel, which contained the entire list of domain and hostnames used by the company.

Now I had a list of all their hosts and I just gathered passwords

here and there, hopping from system to system. 158 The Art of Intrusion

This "puddle jumping" was possible because of his earlier success in cracking the passwords on the backup Web server, after exploiting the Microsoft SQL password he had obtained.

He still didn't know which servers were the application development machines, storing the source code of the product and the licensing man- agement code. Looking for clues, he carefully scrutinized the mail and Web logs to identify any patterns of activity that would point to these boxes. Once he gathered a list of other IP addresses from the logs that looked interesting, he would target these machines. The Holy Grail at this stage was a developer's workstation, since any developer would likely have access to the entire source code collection of files.

From there, he laid low for several weeks. Beyond collecting passwords, he wasn't able to get much for a couple of months, "just kind of down- loading a little piece of information now and then that I thought useful."

The CEO's Computer This went on for about eight months, as he patiently "hopped around from server to server" without finding either the source code or the license key generator. But then, he got a breakthrough. He started look- ing more closely at the backup Web server he had first compromised and discovered that it stored the logs of anyone retrieving email, listing the username and IP address of all these employees. From an examination of the logs, he was able to recover the CEO's IP address. He had finally identified a valuable target.

I finally found the CEO's computer and that was kind of inter-

esting. I port-scanned it for a couple of days and there would just

be no response, but I knew his computer was there. I could see in

the email headers that he would use a fixed IP address, but he was

never there.

So I finally tried port-scanning his box, checking a few common

ports every two hours to stay under the radar in case he was run-

ning any kind of intrusion-detection software. I would try at dif-

ferent times of day, but would limit the number of ports to no

more than 5 in any 24-hour period.

It took me a few days to actually find a port open at the time he

was there. I finally found one port open on his machine -- 1433,

running an instance of MS SQL server. It turns out it was his

laptop and he was only on for like two hours every morning. So,

he'd come in his office, check his emails, and then leave or turn his

laptop off. Chapter 8 Your Intellectual Property Isn't Safe 159

Getting into the CEO's Computer By then Erik had gathered something like 20 to 30 passwords from the company. "They had good, strong passwords, but they followed patterns. And once I figured out their patterns, I could easily guess the passwords."