Published: 01 Feb 2002
Scripts can augment security, but their use also entails a certain degree of risk. Many scripts require administrative access. If an attacker can gain write access to such a script, he'll be able to add anything he wants to it, which means he can run arbitrary programs in whatever security context the script runs.
For instance, what if an attacker accesses the FindPics.cmd script running on a server that's both an NT 4.0 PDC and a general file server (a bad idea to begin with, but let's overlook that for the moment)? The server is locked down pretty tight -- except that the directory in which FindPics.cmd resides has the default NTFS Everybody, which has Full Control permissions. A clever attacker could add a couple of lines, such as:
Copy %SYSTEMROOT%\Repair\sam._ g:\Users\EvilUser\Data
The following day, he could remove those lines, bring home sam._, expand it and spend the next week getting every single user ID and password in the domain.
This is a simplistic and somewhat silly attack, to be sure, and even basic NTFS permissions would prevent it. Nevertheless, it demonstrates a potential risk in using security scripts. More subtle attacks may introduce Trojans if relative paths or unsecured binaries are used. Or, an attacker may manipulate the data the script works with to compromise the system.
One example of this kind of data manipulation is race conditions and integrity issues with temporary files. Technically, a race condition is caused by unsynchronized access to shared data. In this context, the problem occurs if a temp file from a script running with administrative privileges can be modified. An attacker might be able to get that script to perform some arbitrary action. Needless to say, this is more of a problem with unattended and scheduled scripts. For example, if a script gathers a list of files to delete, and an attacker can add arbitrary files to that list, he can disable the system by deleting critical files, or cause other trouble by deleting data files to which he might otherwise not have access.
So how do you prevent attackers from misusing scripts? By exercising good coding practices and following common sense security principles -- most notably the principle of least privilege. Don't run the scripts in the administrator or system contexts unless absolutely necessary. Set very strict file system permissions. Hard-code absolute pathnames and binaries.
If your script requires temporary files, set up a separate directory with stringent file system permissions just for those files. If you must transfer data to or from other computers, consider using SSH (which is available for Windows free and commercially, but the free versions aren't necessarily as easy to install) and certificate-based authentication rather than hard-coding passwords into scripts.
About the author:
JP Vossen, CISSP, is a technical editor for Information Security and an infosec consultant.