REMOTE-ACCESS SERVICES

Perhaps one of the most popular side-entry doors available to attackers, remote-access utilities (such as Symantec's PCAnywhere, Windows's RAS, or UNIX's SSL/RSH) provide legitimate users with easy access to corporate resources from geographically remote locations. (The system administrator no longer has to make 3 A.M. trips into the office to reboot a server.)

Unfortunately, these convenient applications have two fundamental vulnerabilities. The first risk is that the client machine (for instance, a traveling salesperson's laptop) could be stolen, depending upon how the client is authenticated. The theft could potentially use this stolen machine to gain direct access to the corporate network by simply turning the machine on and double-clicking an icon on the desktop. The second risk is that the server- side component of the service running on the corporate network does a poor job of authenticating the client. Here the requester of the service is wrongly identified as a legitimate user and not an intruder trying to gain unauthorized access, especially when access is via an unsanctioned modem installed on a machine behind the corporate firewall.

Directories and Files

Each individual directory (or folder in Windows terminology) and file on a machine can have different access privileges assigned to different user accounts. In theory, this means each user can be assigned the minimum access privileges they need in order to perform their legitimate tasks. Unfortunately, because maintaining Draconian directory and file privileges is often labor intensive, many machines typically enable users (and the services that they have spawned) more generous access than they actually need.

To reduce the likelihood of human error when assigning directory and file access privileges, some LAN administrators will group files together based on their access privilege needs. For example, programs or scripts that only need to be granted execute access could be placed in a directory that restricts write access, thereby inhibiting an intruder's ability to upload a file into a directory with execute privileges.

Many products will by default install files that are not absolutely necessary; vendor demos and training examples are typical. Since some of these unneeded files may contain

capabilities or security holes that could be exploited by an intruder, the safest approach is to either not install them or promptly remove them after the installation is complete.

Intruders are particularly interested in directories that can be written to. Gaining write and/or execute access to a directory on a target machine, even a temp directory that does not contain any sensitive data, can be extremely useful. An intruder looking to escalate his or her limited privileges will often need such a resource to upload hacking tools (rootkits, Trojan horses, or backdoors) on to the target machine and then execute them.

For an intruder to gain access to a directory, two things must happen. First, the intruder must determine the name and directory path of a legitimate directory, and second, the intruder must determine the password used to protect the directory (the topic of the next section of this chapter). In order to reference the target directory, the intruder must figure out or guess the name and directory path of a candidate directory. This is an easy step if default directory names and structures are used, or the intruder is able to run a find utility against the target machine.

In an effort to supplement the built-in file security offered by an operating system, several products now provide an additional level of authorization security. Typically, these products provide directory and file access using their own proprietary access mechanisms, thereby potentially mitigating any security hole or omission that could be exploited in the underlying operating system. Table 4.13 lists some of these products.

Table 4.13: Sample List of Directory and File Access Control Tools

NAME ASSOCIATED WEB SITE

ArmoredServer www.armoredserver.com AppLock www.watchguard.com AppShield www.sanctuminc.com Authoriszor 2000 www.authoriszor.com Entercept www.entercept.com InterDo www.kavado.com PitBull LX www.argus-systems.com SecureEXE/SecureStack www.securewave.com StormWatch www.okena.com Virtualvault www.hp.com FILE-SEARCHING TECHNIQUE EXAMPLE

A complete listing of all the files present in a Web server's directory can be easily obtained if the webmaster has not disabled a Web server's automatic directory service or redirected

The following is a simple exploit intended to show how easy it could be for an Intruder to map out a directory structure. A feature with early versions of Microsoft IIS can display the directory structure of a Web site as part of an error message. Entering www.wiley.com/index.idc from a browser's URL entry line would result in a response such as this one:

Error Performing Query

The query file F:\wwwroot\primary\wiley\index.idc could not be opened.

The file may not exist or you may have insufficient permission to open

the file.

Regardless of any third-party access control products that an organization may have deployed, the directory and file permissions for critical machines should still be checked to ensure that the permissions are no more liberal than they have to be. Fortunately, this potentially tedious manual task can to a large degree be automated using either commercial tools designed to find permission omissions or tools originally designed for attackers with other intentions. Table 4.14 lists some sample file-share-checking tools and Table 4.15 offers a checklist for checking the security of directories and files.

Table 4.14: Sample List of File-Share-Scanning Tools

NAME ASSOCIATED WEB SITE

Legion www.hackersclub.com Nbtdump www.atstake.com

NetBIOS Auditing Tool (NAT) www.nmrc.org IP Network Browser www.solarwinds.net

Winfo www.ntsecurity.nu Table 4.15: System Software Directories and Files Checklist