May 7, 2001
(Computerworld)
I'd just sat down with a fresh cup of coffee when an e-mail popped up on my screen with a subject line that read: "Engineering Oracle database has been hacked." A staffer had sent the message to all of our operations management personnel, plus about seven other system and database administrators. My first thought was, "Oh, great - we've been hacked, and now the whole company knows."
This Week's Glossary
Trojan horse: A program hidden in a seemingly innocent executable file that, when launched, may destroy data, steal account information and allow a hacker to remotely control a system to launch attacks on other systems - all without the user's knowledge.
Back Orifice: Advertised as a remote administration tool, this client/server utility functions as a Trojan horse. The hacker e-mails the server portion as a file attachment and renames it to something innocuous, such as orgchart.ppt. exe. When the recipient executes it, the server installs itself and automatically notifies the hacker, who can gain access to the remote computer.
Links:
For more information on Back Orifice and other Trojan horse viruses, see this link at Symantec Corp.'s Web site.
How do you detect a Trojan horse program? The "Windows NT Intruder Detection Checklist" at the Web site of the CERT Coordination Center at Carnegie Mellon University is a good start.
Been hacked? CERT's "Steps for Recovering from a Unix or NT System Compromise" is a well-written checklist that shows how to recover.
I made a mental note to tell the staff that in the future, if they suspect that a hacker has visited them, they shouldn't announce it to the entire company. Because of the way our environment is configured, there's a high likelihood that if there's a hack, an internal employee is responsible, rather than an inquisitive college kid.
So then I was concerned that the perpetrator might know that we were on to him and try to cover his tracks. The e-mail disclosed that the Oracle system passwords had been changed without authorization. I wouldn't immediately attribute such action to a hacker, but nevertheless, someone had started the ball rolling, and as the security manager, I had to run with it.
Mysterious Moving Cursor
In addition to news of the password situation, I had received information from an application engineer about a month earlier who reported some weird behavior: His cursor started "moving by itself, opening the Start menu" and browsing around the computer without any interaction. That bit of information concerned me then.
Now everyone thought that someone had gained remote control of one of our engineers' computers and had hacked into an Oracle database from the engineer's desktop.
Was it possible? Absolutely. However, it was highly unlikely that any person who might have gained remote control was from the outside. We use network address translation (NAT), which means that the IP addresses of our desktop computers are translated to another IP address before leaving our network. It's a common practice that we use to conserve IP address space internally. And it also provides some additional security, if configured properly.
As for that Oracle database, I immediately took an image of the system, using the Unix data dump utility to copy the entire file system to an external drive. I next had the administrator change all of the passwords on the system.
Then I received a telephone call from the manager of engineering. He told me that the password change was a legitimate one made by one of the Oracle administrators, who had forgotten to communicate it properly.
Cool - that issue seemed to be resolved. Next, I wanted to address the issue of the floating Windows NT mouse cursor. My fear was that a Trojan horse program was in the system and was allowing a third party to gain control. Although we use NAT for our internal desktops, there's always a way to bypass security. So I was still worried.
A Trojan horse is a bit different from a virus, in that it can be disguised as something legitimate and attached to, say, an e-mail message. A virus normally affects one file but can have a devastating effect on the file system or operating system.
A Trojan horse is really a backdoor program that can let a hacker gain administrative access to an infected computer at a later date. If the hacker named the Trojan horse something clever like orgchart.ppt.exe, attached it to an e-mail and then spoofed the e-mail to make it appear to originate from, say, the CEO, most employees would be inclined to accept the attachment and execute it.
Notice the .exe extension. That's a bad thing. Executable programs, when launched, are under the control of whoever programmed the executable. The problem is that unless you train your employees properly, most won't know the difference between a legitimate attachment (such as PowerPoint slides) and an executable attachment (with extensions like .exe, .vbs and .com).
The one rule I continue to communicate to the entire company is to not run any executable program unless it's from a trusted source and the program can be verified as legitimate. We have a filtering program that's supposed to do this automatically, but unfortunately, it wasn't configured properly and .exe attachments are being allowed through the e-mail gateway.
Security Checklist
Getting back to the work at hand, I needed to determine whether the engineer's desktop was infected with a Trojan horse program. Such programs are often configured to be virtually undetectable; even the best antivirus programs can't find them all.
In dealing with this security hazard, I could have simply had this engineer's desktop hard drive completely wiped clean and the system rebuilt. That's probably the most effective way to eradicate a Trojan horse, but it's also very disruptive to the end user. I decided to first have the engineer go through a checklist to determine if the computer had been infected.
We use a checklist I downloaded from the CERT Coordination Center's Web site, along with my own checklist compiled from many different sources. It's important to have multiple mechanisms for intrusion detection, and it's my job to ensure that effective tools are in place and ready to go so the staff won't have to scramble at the last minute. It took about 45 minutes for the engineer to go through the checklists before reporting that there were no indications that his system had been compromised.
I now had a dilemma. Should I trust that the checklist was comprehensive and that the engineer didn't take shortcuts? If I just let it pass as some weird phenomenon and later found that someone had gained unauthorized access, I would have some serious explaining to do. I could have run through the checklist myself, but the computer in question was located in a remote office.
Well, I can't be everyone's friend, and I'd rather be safe than sorry. So I had the IT person at the remote office wipe the system clean and rebuild it. The engineer was quite mad at me, complaining to his manager about how this was going to affect his productivity, that he had wasted his time going through the checklist, that it was just some weird computer glitch and that he hadn't downloaded an executable file or e-mail attachment.
I guess you can't be an effective security professional without gaining some resentment or being called a barrier to productivity (and other names I'm not and probably never will be privy to). But in this job, I suppose it's all in a day's work.