Methods to Prevent Unauthorized Execution

Several techniques can be used to prevent unauthorized execution.

Don't Let End Users Be Logged In As Admin

One of the single best things you can do to prevent unauthorized software installation is to prevent non-admin users from being logged in as administrators. Non-admin users cannot install most software, modify the HKLM registry key, or add programs to most Windows auto-start areas. Non-admin users normally cannot install programs from the Internet or modify existing program configuration information.

Unfortunately, this recommendation doesn't prevent normal users from running already installed software. Unless the user is restricted from running a program using permissions or some other method, Windows allows users to run most programs without administrative access.

Remove or Delete Software

If existing software isn't needed by any user, uninstall it, delete it, or rename it. As discussed earlier in this book, even when software isn't used, it can make a computer vulnerable. If possible, uninstall or delete the software or service. Using the program's official uninstall program is preferred, as it should remove associated files, folders, and registry entries. Unfortunately, many uninstall routines still leave unneeded files and registry entries even when they claim to be removing them. If the software being removed is high-risk, be sure to manually inspect the related files, folders, and registry keys, and delete if needed. Renaming the software executable or folder to something Windows or the end user doesn't expect can be useful when the software is difficult to remove. It's security-by-obscurity, but it can work in preventing easy execution.

Be aware that Windows will sometimes track name changes and update the pointers, icons, and shortcuts to the new name. Unfortunately, this method doesn't prevent re-installation. For example, if a network administrator removes America Online's Instant Messaging (AIM) client, there is little to prevent an end user from re-installing it if they have the appropriate admin permissions. Also, you cannot remove, delete, or rename Windows File Protection (WFP)—protected files. If you do any of the preceding, Windows just replaces them in a few seconds. Still, if you can successfully remove unneeded software, it is one of the best ways to strengthen the security of any computer system.

Use NTFS Permissions

You can use NTFS permissions to prevent the execution of existing installed software, and in some limited cases, prevent the installation of new software. NTFS permissions are the number one most secure way to prevent the unauthorized execution of existing software. If appropriately used, NTFS is hard to get around or trick.

Determine what software most normal users should be able to execute, and if the software cannot be removed completely (e.g., needed for admin purposes or other users on a shared computer), then use appropriately set NTFS permissions to secure it. In most cases, an administrator wants to take away a normal user's Read & Execute permission. As Figure 9-1 shows, a common decision would be to set permissions at the application's folder level and let the resulting permissions be inherited downward. In this case, Figure 9-1 shows the Everyone group's permissions being set to none (as if it had previously had permissions set). Administrators, System, and Service have the expected default Read & Execute permissions.

Figure 9-1

Remove any other groups that should not have permissions. There is no need to add the Everyone group (or any other group) and then remove the permissions if the group does not already have permissions. When Windows realizes that a listed security principal has no permissions set on a protected resource, it will remove it from the access control list completely.

Be careful. Do not set Read & Execute-Deny permissions for the Everyone or Authenticated Users group unless that is your true intent. Administrators and other privileged accounts belong to the larger groups as well and any permissions you set will also apply to the more privileged user accounts. Doing so could result in Read & Execute permissions unintentionally being taken away for the more specific groups. The key here is to remove Read & Execute permissions from groups that do not need access.

Preventing New Installs Using NTFS Permissions

The easiest way to prevent new installs using NTFS permissions is to not allow non-admin users to be logged in with admin credentials. Outside of that effort, another way to prevent new installs using NTFS permissions is to remove all permissions on the folders where the software is likely to be installed. Essentially, you want to take away the Read permissions from even the Administrators group, if end users are normally logged on with admin credentials. The true administrator can always take ownership and add back permissions if they are really needed.

For example, if you are tired of a particular software being installed (e.g., FreeRebates, a popular adware program), you can create its default directory ahead of time and remove all permissions. In this example, you could create a folder under C:\Program Files called FreeRebates, where the FreeRebates program would normally install itself. By creating the folder and removing all permissions, the FreeRebates install program will attempt to install itself but fail. This is because when it begins to create what it thinks is a new directory, the unseen directory will already exist and can't be created, and the install routine will fail. Simple error-checking code in the program's installation routine would prevent the failed installation, but most install routines do not contain the necessary programming. The same obscurity technique can be used to trick viruses and trojans. If a malware outbreak (that uses a particular file name) occurs and other defensive measures are not available, you can consider using this trick. For example, suppose a worm always creates a program called Mywife.gif in the C:\Windows\System32 directory. You can create a small text file with the same name and then assign it no or Full Control-Deny permissions. If the worm tries to exploit the modified system, it will not be able to create the expected file and will hopefully fail.

You can also try creating a directory with the same name as the file you wish to block. This often blocks malware that's smart enough to clear adverse attributes from a proactive blocking file but doesn't have the coding to deal with a directory with the same name. These methods are very crude and don't work all the time. The installing program or user might be able to install the software or malware using another folder or file name. But many malware programs install to a particular directory with predictable names, and end users almost always take the default install directory path when given a choice. It's a crude method, but it works in a pinch.

Preventing New Installs Using NTFS Registry Permissions

If an installed program relies on the registry to run, you can use registry permissions to prevent unwanted execution. As covered in Chapter 6, find the program's registry keys and remove Read permissions from the appropriate groups.

Use Service Permissions

If the program installs itself as a Windows server, you can use service permissions to prevent execution. As covered in Chapter 7, service permissions are most easily set using Group Policy Objects (GPOs) and the System Services leaf object. Alternately, you can set service permissions using the Sc.exe utility and its Sdshow (see Figure 9-2) and Sdset parameters along with the appropriate SDDL settings. With either method, you can control which security principals have the ability to stop, start, and read various system services. You can also disable services using the Windows hardware profiles feature (also covered in Chapter 7).

Figure 9-2

Don't Forget to Use Good NTFS Permission Setting Practices

Whenever using NTFS to set permissions, don't forget to follow best practices, including the following:

• Use the AGULP method to assign security permissions.

• Always assign permissions to groups but never to individual users.

• Use the Advanced Security Settings dialog box when setting NTFS permissions.

• Set Share and NTFS permissions as tightly as you can to meet the least-privilege principle.

• Using NTFS permissions is one of the best ways to prevent unauthorized execution of installed programs.

Unregister DLLs

There are times when it is important to temporarily disable COM objects or particular DLLs. Several Microsoft vulnerability warnings in 2005 (e.g., www.microsoft.com/technet/security/advisory/906267.mspx) recommended that specific files be "unregistered" as a workaround until patches could be developed, tested, and released.

By default, many programs, COM objects, and DLLs register themselves with Windows. They do this so they can easily be found and executed when appropriate in Windows. You can use the Regsvr32.exe or /Unregister command to unregister files.

For example, before the appropriate patch was released, Microsoft Bulletin 903144 (www.microsoft.com/technet/security/advisory/903144.mspx) advised concerned administrators to unregister the Javaprxy.dll COM object. It can be done using the following syntax:

 Regsvr32.exe /u Javaprxy.dll 

You must execute the command at the command prompt and in the current directory where the object is located (or otherwise provide the correct path). If done correctly, a message dialog box will pop up stating the success (see Figure 9-3).

Figure 9-3

Any object unregistered using the Regsvr32.exe program can be registered by typing in the same syntax, but without the /u unregister parameter:

 Regsvr32.exe Javaprxy.dll 

Again, a successful message dialog box should appear. You can use the /S parameter (i.e., Silent mode) to prevent the popup dialog box from appearing. Most Dll and ActiveX controls (OCXs) files can be registered and unregistered using Regsvr32.exe. You must close and re-open any dependent applications if they are open when the Regsver32.exe command is executed in order for the new setting to be effective.

Larger applications often carry their own unregister commands. For example, the Windows scripting host HTML application host program, Mshta.exe, can be registered and unregistered using the /register and /unregister parameters:

 Mshta.exe /register or Mshta.exe /unregister 

Unregistering a program removes its file association in the registry. Figure 9-4 shows the .HTA file extension normally associated with Mshta.exe. Figure 9-5 shows the same screen after the /unregister switch has been executed. The HTA file extension is no longer listed.

Figure 9-4

Figure 9-5

Microsoft Visual Basic ActiveX controls can often be registered using the /regserver and /unregserver parameters (see http://support.microsoft.com/default.aspx?scid=kb;en-us;297279). Check each program's documentation for more information on the registration process.

Unregistering a program or Dll file is useful in instances when other alternative defenses are not available, but should not be used as a long-term defense. It's too easy for the unregistered program to be re-registered by a new software update or newly installed program. For long-term solutions, use NTFS or Software Restriction Policies (covered below).

Use the Kill Bit

Another technique similar to the registration solution is setting the kill bit. Administrators and users can set a kill bit flag in the registry to instruct Internet Explorer, Outlook, and other Windows programs to not load specific ActiveX controls. In order to set a control's kill bit, the control's CLSID must be known. To find an object's CLSID, you can:

• View the control's CLSID in Internet Explorer (not always accurate or possible).

• Contact the control's manufacturer.

• Use the Microsoft Resource Kit utility, Oleview.

• Query a database that lists various ActiveX controls and their CLSIDs.

• Search for it in the registry.

The Microsoft Resource Kit utility, Oleview (www.microsoft.com/windows2000/techinfo/reskit/tools/existing/oleview-o.asp), is an excellent tool for hunting down unknown CSLIDs. You can see an example of it revealing Adobe Acrobat Reader's CLSID in Figure 9-6.

Figure 9-6

CastleCop's (http://castlecops.com/ActiveX.html) listing of ActiveX controls is one of the best on the Internet. Not only does it list control CLSIDs; it makes a determination about whether the control is legitimate or more likely to be considered unwanted by most users (i.e., spyware, adware, etc.).

Searching for a control's CLSID in the registry can be monotonous. Search for the Default string value for the ProgID key for each of the CLSID keys in HKCR\CLSID. Figure 9-7 shows an example searching for the Quick Time ActiveX control CLSID. In Regedit.exe, click on HKCR\CLSID. Choose the F3 key to search, type in ProgID, and then press Enter. Press F3 to repeat the search until you find the product name you are looking for. In this case, the QuickTime control's CLSID is .

Figure 9-7

Note 

Nirsoft's RegScanner (www.nirsoft.net/utils/regscanner.html) is a good tool for registry scanning. It lists all matches of a single registry query in one list from which you can jump into edit. This is a lot better than finding and changing things one at a time via Regedit, when you realize you've done 37 such changes and the scrollbar suggests you have 75% of the registry still to go. It can also do queries based on modification date and time.

After the control's CLSID is located, the following registry key must be located or created: HKLM\Software\Microsoft\Internet Explorer\ActiveX Compatability\{CLSID}. Locate the Compatibility Flag key. By default, it can be several values. Setting it to 400 will instruct Internet Explorer not to load the control. This is a good way for administrators to prevent known controls from running if they've had a problem with them previously. You can even proactively set the kill bit for ActiveX controls yet to be installed. The kill bit works only within Internet Explorer and other applications that rely on Internet Explorer to render graphics (e.g., Outlook), and thus some controls can bypass the settings. For example, I set the kill bit on Adobe's Acrobat ActiveX control. When I clicked on a PDF document in Internet Explorer, the control was not launched. However, I downloaded the same PDF document to my hard drive and clicked on it in Internet Explorer. Explorer automatically loaded Windows Explorer to handle the local file, which then loaded Acrobat and displayed the PDF document. This just re-enforces one of ActiveX's criticisms about security being handled by the browser. We will cover other methods to secure ActiveX controls in Chapter 10.

Software Restriction Policies

Starting with Windows XP Pro, Microsoft introduced the concept of software restriction policies (SRPs). SRP enables an administrator to specify what software is allowed to run on any managed computer. Software restriction policies (known as SAFER within Microsoft) require Windows XP Pro or later computers. Windows 2000 has a smaller subset of features similar to SRP but isn't nearly as versatile.

The SRP management console is accessed using group policy or Local Security Policy. Chose Computer Configuration\Windows Settings\Security Settings\Software Restriction Policies to access SRP settings (see Figure 9-8). Group policy, but not Local Computer Policy, allows administrators to configure SRP in the User Configuration area as well.

Figure 9-8

Overall SRP Decisions

First, before administrators even begin configuring SRP, a major decision needs to be made. Is SRP going to deny all software by default except that which is allowed, or allow all software to run by default, except that which is denied (the default when SRP is turned on)? Once the overall rule is set, exceptions to the major rule are defined. Hence, if you decide to implement the deny-by-default rule as the major rule, every program you want to run is then defined as an exception to the default rule.

The deny-by-default rule is called Disallowed in SRP. The other option, to allow all software to run except that which is explicitly denied, is called Unrestricted. This major SRP setting, called Security Levels, is made under the Security Settings leaf object (see Figure 9-9).

Figure 9-9

If you choose Disallowed, Microsoft has already created four exception rules (see Figure 9-10) that prevent first-time users from locking themselves out of their systems. The exceptions allow all executes in the root directory, the Windows directory, the System32 directory, and the Program Files folder to run, by default. These rules can be removed when you are familiar with SRP, but do so with caution.

Figure 9-10

You can also decide whether SRP applies to all Windows files or all Windows files except Dll files (see Figure 9-11). The default is all files except Dll files. This is because Dll files are often shared between multiple programs and throughout Windows. Most of the time, administrators mean to block normal executables. If an administrator chooses the Disallow default rule and also blocks Dll files, they could possibly cause problems with desired Windows programs. The All software files setting should be chosen with caution. You can also decide to whom SRP applies — all users or all users except local administrators. This allows a local Administrator to log in and run any executable they want for emergencies and troubleshooting but will prove useless if all users are logged in as local administrators.

Figure 9-11

SRP can initially control only 31 different file types, including many of the highest-risk files. Default file extensions include ADE, ADP, BAS, BAT, CHM, CMD, COM, CPL, CRT, EXE, HLP, HTA, INF, INS, ISP, LNK, MDB, MDE, MSC, MSI, MSP, MST, OCX, PCD, PIF, REG, SCR, SHS, URL, VB, and WSC. You can easily add more file extensions (see Figure 9-12), but they will be far fewer than the hundreds of file extensions allowed to run in Windows by default. Use the file extension list presented in Table 5-1 as your guide.

Figure 9-12

SRP allows an administrator to determine what level user (see Figure 9-13) can install a software vendor's publisher certificate as trusted (i.e., a Trusted Publisher). A trusted publisher can potentially install any application they like remotely without ever warning the user or asking for permission. Trusted publishers should be set with caution. In most cases, only local or Enterprise administrators should be installing trusted publishers, although this is not the default. You can also choose whether to require revocation checking on certificates using the publisher's name or the certificate's timestamp. In practice, revocation checking doesn't work as well as it should. You can enable it unless you have problems, but don't trust it to be accurate.

Figure 9-13

Exception Rules

After that major decision is made, the administrator goes about setting exceptions. Exceptions are policy rules that either allow specific software (when using the Disallowed main setting), or deny specific software (when using the Unrestricted setting). There are four different types of exception rules:

• Certificate rules

• Hash rules

• Internet Zone rules

• Path rules

Certificate exception rules allow you to deny or allow software digitally signed by a specific digital certificate (see Figure 9-14). For example, you can deny all VBScript files except those signed by an internal private company development digital certificate. It will stop VBS viruses and worms from running, but allow your own internal management scripts to run. Certificate rules require a code signing digital certificate to be trusted, and you must configure separately who can decide whether to trust a particular code signing certificate (see Figure 9-13 above). Certificate rules apply no matter where the file is or what it is named, as long as the file's integrity has been maintained and the certificate remains valid.

Figure 9-14

Hash rules allow you to input a valid MD5 or SHA1 file hash value (also known as a digital fingerprint). Like Certificate rules, it allows you to deny or allow a particular file or program no matter where the target resides or what the file is named. All that matters is that the related file meets its previously stored hash value (see Figure 9-15).

Figure 9-15

Most administrators implementing SRP use a lot of hash rules. The only problem is that software updates and patches frequently update the related executable referred to by the hash. This means the administrator is constantly adding and modifying hash rules every time a new file version comes out. With that said, the hash rule method is extremely accurate.

The Internet Zone rule (see Figure 9-16) is probably the least useful of the SRP rules. It will allow or deny all software installed and executed in a particular Internet Explorer Zone (more on zones in Chapter 10), but only if the file was installed with a Windows installer file (.MSI). Since most Internet-installed software programs do not install with an .MSI file, it practically makes the rule class almost useless. The Internet rule being established in Figure 9-16 would prevent any MSI programs from being installed from web sites lying within the Restricted sites zone.

Figure 9-16

Lastly, Path rules allow you to define exceptions using directory (see Figure 9-17) or registry paths. Path rules will accept the standard wildcard naming conventions (i.e., ? and *) in the path statements. SRP is fairly accurate at preventing the exact executable from executing, but it can easily be bypassed by a semi-knowledgeable end user — for instance, by right-clicking the protected executable and creating a shortcut. That shortcut will run the executable without problem. If you rename the executable, it will run without problem. If you copy the executable elsewhere, it will run without problem.

Figure 9-17

Setting up a deny-by-default SRP takes some planning and work. None of the rule exceptions by themselves work perfectly, but all four types used together can roughly enforce which software is and isn't allowed to run on a Windows XP and later computer. Figure 9-18 shows the type of message a user will get if the program is restricted by SRP.

Figure 9-18

There are some issues with SRP beyond figuring out what is and isn't allowed. It isn't perfect. For one, it works only with Windows XP Pro and later. Two, it cannot manage 16-bit executables (such as Command.com and Edit.com). If you wish to prevent 16-bit executables, use NFTS permissions on Ntdvm.exe. Three, it does not apply to all file types by default. Lastly, there appears to be many ways to bypass each particular exception rule. Most users won't be able to guess how to hack around SRP, but it can be done. It is not a panacea. If you need absolute security, use NTFS permissions instead.

In at least one instance, SRPs are better than NTFS permissions. It is the case of how to secure applications prior to them being installed. NTFS permissions cannot be set until the file or folder is already installed. SRP can be used with wildcards to allow or deny programs from the moment they were attempted to be first installed. You should use a combination of all the SRP and NTFS permissions to get the desired outcome.

Although SRP doesn't work on Windows 2000, group policy had SRP-like policies. In Group Policy, choose User Configuration\Administrative Templates\System. There are two similar settings called Run only allowed Windows applications and Don't run specific Windows applications. A few other options above and below will allow you to have some limited control over software execution.

More Security Levels

SRP comes with two exposed security levels: Disallowed and Unrestricted. While these two levels may be all that many companies need, there are in fact three more security levels that can be implemented in SRP:

• Basic User (also known as Normal User)

• Constrained (also known as Restricted)

• Untrusted

Constrained and Untrusted users are locked down further than normal users. For one, they cannot read the HKCU registry key or their own user profiles. Normally, all users have Full Control permissions to both these places. In Chapters 5 and 6, I recommended setting their permissions to Read-only to prevent malicious misuse. However, the Constrained and Untrusted security levels go even further, preventing even the reading of those keys. Unfortunately, the side effects of this treatment are unpredictable, varied, and hard to troubleshoot. I recommend that the Constrained and Untrusted levels be ignored until better utilized by Windows (as I'm sure it will).

The Basic User security level is a lot more useful than the other two and really should be a default setting in SRP. To expose the Basic User security level, you have to add a registry entry. Create a new Dword value called Levels under HKLM\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers. Set the value of Levels to hexadecimal 0x00020000 (see Figure 9-19).

Figure 9-19

This will reveal the Basic User security level when you go back into SRP (see Figure 9-20).

Figure 9-20

Now you can set the default SRP rule to be Basic User. Basic users run programs with permissions of non-admin Authenticated Users. An even better strategy is to set the overall SRP rule to Disallowed or Unrestricted as suggested before. But now use exception rules to force particular applications (e.g., Internet Explorer, Outlook, etc.) to run in the Basic User security context. Just define exception rules as you normally would, but instead choose Basic User instead of one of the other two options (see Figure 9-21).

Figure 9-21

This is much like Windows Vista's new feature of running non-admin programs as lower-privileged users even when the current user is logged in as an administrator. You can use SRP to bring this feature to your Windows XP Pro and later computers. Microsoft security architect and book author Michael Howard has an excellent series of articles on the three additional security levels and SAFER programming at http://blogs.msdn.com/michael_howard/archive/2005/01/17/354708.aspx.

Third-Party Apps

Many third-party tools do the same thing as SRP, such as Novell's ZENworks (www.novell.com/products/zenworks), Desktop Standard's PolicyMaker (www.desktopstandard.com/PolicyMakerStandard.aspx), and NetIQ's Group Policy Administrator (www.netiq.com/products/gpa/default.asp). Go to www.microsoft.com/windowsserver2003/technologies/management/grouppolicy/gptools.mspx for more Group Policy extension tools that can accomplish the same thing as SRP.