It often seems to me that network administrators are obsessed with security and are among the most paranoid people on earth. They have to be. After all, if an administrator goes easy on the security, there are countless hooligans just waiting to break into the network to steal or vandalize data—or simply to shut the network down. I once heard someone say that being a network administrator was one of the world’s toughest jobs because you have to be smarter than every hacker out there. I don’t know if that statement is completely true, but there’s definitely something to be said for outsmarting hackers. One of the best ways that you can do just that is to be aware of some of the ways in which hackers attack networks. In this two-part series, I’ll review some of the more common hacking techniques.
In this Daily Drill Down, I’ll discuss some ways in which hackers can attack your servers by exploiting the clients connected to them. Because the most vulnerable client is Windows 9x, I’ll focus on that. Although it may seem off the topic to discuss client-side security when discussing server security, you should remember that it’s often easiest for a hacker to attack a server by first exploiting the clients to which it’s attached. In part two, I’ll continue the discussion by explaining some server-side hacking techniques in a Windows NT environment.
When many people think of hacking, they think of stealing passwords. Although there are many different ways of hacking the Windows 9x operating system, stealing passwords is one of the more common and dangerous methods. As you may know, the initial password prompt that users see when logging on to Windows 9x can be easily bypassed by simply pressing [Esc]. The only real benefit to entering a Windows password is that doing so allows you to access a Windows NT or Windows 2000 domain and allows you to cache passwords.
In case you’re unfamiliar with caching passwords, I’ll take a second to explain. You’ve probably seen Web sites or applications that require passwords. In many cases, when you enter a password, Windows will ask if you’d like to have this password saved so that when you visit the site again, Windows will automatically fill it in for you. This is called caching a password. If you choose to allow Windows to save the password for this Web site or application, then you need only remember the initial Windows password—the one required when you log on—to gain access to all such cached passwords.
Because Windows passwords can provide a hacker access to a domain or to other applications, there’s a temptation to steal the passwords. Unfortunately, Windows 9x wasn’t designed as a secure environment. The main reason that Windows even asks you to log on is simply so that the operating system will know which user’s preferences to load. This lack of security means that the passwords aren’t very well protected. In fact, the Windows password and all cached passwords are stored in a PWL file.
There are numerous utilities available on the Internet for cracking PWL files and extracting the Windows password. Best of all, a hacker doesn’t even have to be at the workstation to do it. By simply copying the PWL file to a disk, the hacker can toy around with cracking the password from any computer.
So what do you do about this problem? Unfortunately, there isn’t really a way to protect your PWL files from being copied. You can flag the files to be hidden, but this won’t stop a good hacker. Instead, I recommend adding a subkey to the registry and setting its value to one. The subkey is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
Windows\CurrentVersion\Policies\Network DisablePwdCaching. Creating this registry subkey and setting its value to one will make it impossible for Windows to remember passwords (other than the initial Windows password).
I can’t count the number of times that I’ve seen users remain logged on while away from their desks. Oftentimes, the users assume that their accounts are safe because the PCs are running screen-saver-protected passwords. It’s simple to get around a screen saver password, though.
In early versions of Windows 95, you could bypass a screen saver password by pressing [Ctrl][Alt][Del] or [Alt][Tab]. Microsoft quickly learned about that vulnerability and fixed the problem, but there’s still another easy way to get in. You can simply insert a CD into the CD-ROM drive. Windows is designed to constantly poll the CD-ROM drive for the presence of a new CD and to run the CD’s Autorun.inf file. If the screen saver happens to be active, the CD will run anyway.
To stop this behavior, open Control Panel and double-click the System icon. When you see the System properties sheet, select the Device Manager tab. Next, navigate through the Device Manager tree until you locate your CD-ROM drive. Select the CD-ROM drive and click the Properties button. When you do, you’ll see the CD-ROM drive’s properties sheet. Now, select the Settings tab and deselect the Auto Insert Notification check box. Click OK to close the properties sheet, and hackers will no longer be able to use the CD-ROM trick to get past a screen saver.
Before you start feeling too cocky about safeguarding the screen saver, though, remember that all a hacker has to do is cycle the power and then press [Esc] at the Windows login prompt to gain access to all of your local resources. The lesson here—save anything that’s important on a server where it can be better protected.
One big threat to your network is Windows 9x file sharing. The file-sharing process isn’t itself a problem. If users are sharing files, they probably intend for people to access them. Therefore, the unauthorized access to the shared data isn’t really the problem. The good stuff is usually stored on servers anyway.
The real problem is with the way that the shares are made available. It’s extremely easy to use a protocol analyzer to intercept a password as it’s entered to gain access to a share point. Sure, the password is encrypted, but once a hacker has an encrypted password, decrypting it is easy. There are a number of tools available on the Web for decrypting passwords.
Once the hackers have deciphered the share’s password, they will have full access to the share. They can now delete files, replace files with a few of their own, or go into the files and alter the data. I personally witnessed one situation in which a hacker erased all of the data from an Excel spreadsheet and replaced the data with a nude photo of Jennifer Aniston. Needless to say, there were quite a few surprised people when it came time to update the spreadsheet. Thank God for backups!
Remember, though, I said that the real problem wasn’t the shared directory. Sure, the hacker can do some damage in the shared directory, but the fact is that passwords are often used for more than one thing. There’s a very good chance that the hacker would be able to use the stolen password to break into other, more important shares. I’ve even seen users who don’t want to have to remember more than one password, so they set their own personal password to match the password required by a frequently used share.
So what do you do about this dilemma? My advice is that unless you have a very compelling business reason for using file shares, disallow file sharing on the workstations. If you have too many workstations to manually check each one, try using the System Policy Editor to disallow file sharing.
Other hacking techniques
Usually, when people think of hacking, they tend to think of remote hacking—that is, breaking into a system from a remote location. But because Windows 9x isn’t a true network operating system (no e-mail messages about that one, please!), it isn’t nearly as vulnerable to remote attacks as you might think. Consider the case of Windows NT. Windows NT offers true remote administration capabilities. Just about any of the Windows NT administrative tools can be used on either the local system or on a remote system. For example, you can easily edit the registry on a remote system.
Windows 9x, on the other hand, doesn’t offer many remote administration capabilities. Sure, you can still remotely edit the registry, but you have to have the Remote Registry Service installed first. This service isn’t installed by default, and most people don’t even know that it exists, let alone how to use it. Even with the Remote Registry Service installed, the system must be attached to a Windows NT or Windows 2000 domain and must be running in user-level security mode, which requires the owner of the system to specify which users may access the registry remotely. I’m not saying that remote access isn’t a way of hacking into Windows 9x. I’m just saying that there are much easier ways of getting in.
In spite of the fact that remote overrides through Windows 9x are difficult, I recommend being cautious about installing modems in workstations. If you put a modem into a workstation and the modem is set to allow incoming calls, you’ve created a back door to your network. Even if the remote callers can’t directly access your network through the modem, they can establish a session and use the session as a way to gather important information about your network for a future attack through a different portal.
I should also mention that programs like PC Anywhere and ProComm can pose a threat to network security, because if installed on a workstation with a modem, they can be exploited to provide a hacker with a remote control session. They can then use this session to wreak havoc upon your network.
By far the biggest threats to Windows 9x, and indirectly to your network, are application holes. The reason application holes are such big threats is that applications exploit the power of the Windows operating system. For example, if an application tells Windows to run a file, Windows will run that file. Likewise, if an application tells Windows to make a call to the network, Windows will make that call.
As you can imagine, the fact that applications can tell Windows to perform various tasks conforms to Windows’ intended design. After all, what good would an application be if Windows wouldn’t allow it to create new documents, access the network, open databases, etc.? The problem is that Windows can’t tell the difference between legitimate applications, malicious applications, and weak applications.
We all know what a legitimate application is, but what about malicious or weak applications? An example of a malicious application is a virus. Not all malicious applications are viruses, however. A malicious application is nothing more than code that’s designed to harm your system or data. Therefore, a malicious application could be a virus, but it could also be a script that a hacker has designed to break into your network.
It’s fairly easy to protect your system against some types of malicious applications. For example, your antivirus software is constantly protecting you from viruses. It’s much more difficult to guard against weak applications. A weak application is a legitimate application that has inherent weaknesses because of its complexity or functionality.
An example of a weak application is Microsoft Office. Few people would doubt that Microsoft Office is a perfectly legitimate application. Nevertheless, Microsoft Office allows you to imbed macros and other types of scripts into documents. It’s possible for a hacker to e-mail you a virus or a script that’s designed to compromise your network’s security and disguise it as a legitimate Microsoft Word or Excel document.
Another example of a weak application is Internet Explorer. As you’re no doubt aware, Internet Explorer is designed to run ActiveX (and other content that has been deemed safe). It’s a very common practice for hackers to trick Internet users into running an ActiveX control that’s designed to serve some evil purpose.
In this Daily Drill Down, I reviewed some of the more common techniques that hackers use to break into corporate networks through Windows 9x machines. By knowing something of the techniques that hackers use, you can prevent them from getting into your network. In part two of this series, I’ll review some more hacking techniques that focus on the server side.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.