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
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.
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.
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.”