Robert has a standard strategy when he’s trying to break into a corporate network that’s of significant size. He “goes after how they take care of the need for people to be able to get into their network. A large company has a much greater challenge in this than a small one. If you have five employees, you can send them an email, right? Or, you can see them all and say, ‘This is how you connect to your server from home, this is how you get your email from home.’”
But a large company will usually have a help desk or some external resource that people can go to when they’re having a computer problem.
Robert figures that a company with a significant number of employees will have a set of instructions somewhere — most likely from its help desk — explaining how to access files and email remotely. If he could find those instructions, he could probably learn the steps for getting onto the network from outside, such as what software is needed to connect to the internal network over the corporate VPN. In particular, he was hoping to
find out what access points the developers used to access the develop-ment system from outside, because they would have access to the much-coveted source code.
So his challenge at this stage was to find his way to the help desk.
I started using a little utility called the Network Mapper, some-thing I wrote myself. It basically goes sequentially through a list of typical host names. I use it as my sequential DNS resolver.
The Network Mapper identifies hosts and provides the IP address for each. Robert’s short Perl script simply went down a list of commonly used hostnames and checked to see if it existed with the target company’s domain. So, for an attack on a company called “digitaltoes,” the script might look for web.digitaltoes.com, mail.digitaltoes.com, and so on.
This exercise had the potential of uncovering hidden IP addresses or net-work blocks that were not easily identified. On running the script, he might get back results looking like the following:
beta.digitaltoes.com
IP Address #1:63.149.163.41...
ftp.digitaltoes.com
IP Address #1:63.149.163.36...
intranet.digitaltoes.com
IP Address #1:65.115.201.138...
mail.digitaltoes.com
IP Address #1:63.149.163.42...
www.digitaltoes.com
IP Address #1:63.149.163.36...
This would reveal that our fictitious company “digitaltoes” has some servers in the 63.149 net block, but I’d put my money on the server in the 65.115 net block with the name “intranet” as being their internal network.
A Little Help from helpdesk.exe
Among the servers Robert discovered with his Network Mapper was the one he had hoped for: helpdesk.companyX.com. When he tried to go to the site, though, a login dialog box appeared demanding a username and password, restricting access to authorized users.
The helpdesk application was on a server running IIS4, an ancient ver-sion of Microsoft’s Internet Information Server (IIS) software, which Robert knew had a number of vulnerabilities. With a little luck, he might find a useful one that had not been patched.
Meanwhile he also discovered a gaping hole. Some company administra-tor had enabled MS FrontPage in such a way that anyone could upload or download files from the root directory where the Web server files are stored.
(I’m familiar with the problem. One of the Web servers at my security startup company was hacked using a similar vulnerability because the vol-unteer system administrator who was giving me a hand did not properly configure the system. Fortunately, the server was a standalone system, on its own network segment.)
Recognizing that this mistake gave him the ability to download and upload files to the server, he began looking at how the server was set up.
The most common thread with some dumb IIS servers is that [whoever set it up] enabled FrontPage authoring.
And, in fact, this site had a weakness. Deploying Microsoft FrontPage (an application program used to easily create and edit HTML documents) without setting the proper file permissions is sometimes an oversight by a system administrator, sometimes intentionally configured this way for convenience. In this case, it meant anyone could not only read files but could also upload files to any unprotected directory. Robert was stoked.
I was looking at it and going, “Holy shit, I can read or edit any pages on the server without needing a username or password.”
So I was able to log in and look at the root of the Web server.
Robert thinks that most hackers miss an opportunity here.
The thing is that when people set up a scanner network for a server, they often don’t look for common misconfigurations with server extensions like FrontPage. They look [to see what kind of server it is] and say, “Well, it’s just Apache” or “It’s just IIS.”
And they miss making their work much easier if FrontPage has been misconfigured.
It wasn’t as much of a blessing as he had expected, since “there wasn’t really a whole lot on that server.” Still, he noticed that an application called helpdesk.exe would come up when he accessed the site through his browser.
That could prove highly useful, but required a login with password.
So, I’m looking at it thinking how the f___k can I attack this?
One thing I don’t like doing is uploading some other file to a Web server, because if the administrators look through their Web
logs and see a thousand people going to helpdesk.exe and all of a sudden one guy in the South Pacific is going to two.exe or some other thing, that would make them think twice, right? So I try to stay out of the logs.
The helpdesk application consisted of a single executable and a dynamic-link library (DLL) file (files with the .DLL extension contain a collection of Windows functions the application can call on).
With the ability to upload files to the Web root, an attacker could eas-ily upload a simple script allowing him or her to execute commands through his or her browser. But Robert isn’t just any attacker. He prides himself on being stealthy, leaving few if any traces in the Web server logs.
Instead of just uploading a customized script, he downloaded the helpdesk.exe and helpdesk.dll files to his computer to analyze how the application worked, relying on some of his background experience. “I’ve done a lot of reverse engineering applications and looking at things in assembler,” so he knew how to go about working with the compiled C code and reversing most of it back to assembler.
The program he turned to was called IDA Pro, the Interactive Disassembler (sold by www.ccso.com), used, as he describes it, “by a lot of, like, virus companies and worm hunters, looking to decompile some-thing to an assembler level and read it and figure out what it’s doing.”
He decompiled helpdesk.exe and, approving of work performed by pro-fessional programmers, decided that it was “written quite well.”