I was battling yet another worm infestation this week when it came to my attention that our FTP server might be allowing visitors to download illegal copies of Windows.
As for the worms, we've had one after another, and all of them so far have taken advantage of a well-known Windows vulnerability for which Microsoft has already issued a patch. Unfortunately, until we deploy an effective patch management infrastructure to the entire organization and partition off network segments that can't be patched in a timely manner (specifically our engineering labs), we'll continue to have to attend to these outbreaks.
Eventually, I hope to convince upper management to support my proposed patch management and network segmentation deployment. But we're so busy fighting the worms that we've had little time to document their negative effects. And until we gather some meaningful historical data, it's difficult to build a decent business case.
Piracy Suspected
This week, an alarming e-mail from one of our product marketing managers also took up quite a bit of my time. He had noticed a file named en-win2k-pro.iso in the public, outgoing directory on one of our file transfer protocol servers. The file name appeared to be an installation image of the Windows 2000 Professional operating system.
The .iso extension indicates a file that contains the complete image of a CD-ROM. We often use image files when transferring CD images over the Internet, and they can be used to make software distributions available for download.
Once you have the .iso image, it's easy to restore the image to a CD-ROM. Doing that with the en-win2k-pro.iso file would essentially create a pirated Windows distribution CD-ROM. All you need then is a license key to turn it on. Not good.
I walked over to the offices of our Unix FTP server systems administrators and asked one of them to log on for me. Sure enough, the file was residing in the outgoing directory. Its size, at about 420MB, matched the size of a Windows 2000 Professional distribution copy. The presence of such an image could get my company into hot water for illegally distributing licensed software.
The public could freely download the image, but the FTP server was configured in such a way that external users, who access the server as anonymous users, couldn't have uploaded the file. Uploads from the public can be directed only to the incoming directory. The only people who can upload to the outgoing directory are users with valid administrative accounts on the server. That meant that an employee or hacker had uploaded the image.
Following our protocol for such incidents, I asked the administrator to create an image of the entire file system in order to preserve the state of the server before we started changing things. I didn't expect that this was the work of an outside hacker, since our FTP server configuration and the firewall rules protecting it are pretty strong. Most likely, this was an internal job.
Tracing the User
With the image complete, I asked the administrator to move the .iso image to a nonpublic directory. Then I asked for the FTP transfer logs and read this: 20040601/ftp.mycompany.com/xfer.20040601.20:31:11 | S,//pub//outgoing/en-win2k-pro.iso, support, 192.168.5.121,, OK,.
On June 1, an internal user originating from IP address 192.168.5.121 uploaded the en-win2k-pro.iso image to the outgoing directory using a common internal "support" account. This account is shared by many administrators and technical support people, who use it to upload product updates and customer data. To find the user, we had to trace the IP address.
With that information in hand, I went to the Windows help desk manager and had him pull up the server logs to see which user was assigned the 192.168.5.121 address on that day.
Unfortunately, he had to pull the logs from backup archives because we use dynamic addressing, and the addresses had been renewed since June 1. In many cases, users retain the same IP addresses after they expire. But we had to be sure of who held the address in question. It took a few hours to properly restore the log file for the previous month, but we were able to obtain it.
User "jkeaton" (not his real name) had been issued that address on May 10. Since addresses don?t expire for 30 days, I could safely assume that jkeaton was the user
I was looking for. I then searched our employee database and came up with only one person with the last name Keaton. He works as a help desk technician on the swing shift. That made sense, since the file had originally been uploaded at 8:30 p.m.
I was almost ready to call human resources. But before doing so, I wanted to be absolutely sure that jkeaton had been assigned the IP address on June 1, so I had our Snort intrusion-detection systems administrator pull the IDS logs for June 1 and search for the suspect IP address.
I didn't need to be a Snort guru to see the date of the incident and the username and IP address within the long string of output text. But there was still one last detail. Was the file in question truly a Windows distribution image?
I restored the .iso image to a CD-ROM to be sure. It was indeed an illicit copy of Windows 2000 Professional, but fortunately, it wasn't bound to our license key.
Nonetheless, it's still illegal to distribute this software. Now I've given all this information to HR. It's up to them to talk to the employee to see what his intentions were. Maybe he'll get his hand slapped, or maybe they'll let him go. Either way, I'm sure he won't do it again. And I'm relieved to know that it wasn't the work of a hacker.
What Do You Think?
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com, or join the discussion in our forum: QuickLink a1590.