File Defenses


Now that we've discussed common high-risk files and programs, it's time to discuss how to minimize risk.

Uninstall, Remove, Delete, and Rename

The best way to minimize the threat of malicious exploit from high-risk files and programs is not to have them installed in the first place. Do a software inventory audit of all the software running on the systems under your control. Document software that is approved for use within the organization and remove everything else you can. Run uninstall programs, remove the programs manually if you have to, delete files and registry keys, or, as a last-ditch effort, rename the main executables.

Note 

If you rename a program file to stop it from being used, there is a risk of Windows tracking it. Once, when I renamed WScript.exe to WScript.ex! to disable stand-alone WSH script files, I found that related script files still ran. When I looked in the relevant parts of HKCR, I found that the "open" action command line was changed to WScript.ex!. I've also had hotfixes and service packs undo my renamed and deleted security protections.

Unfortunately, that works only for non-WFP protected files.

Microsoft protects most of the executables in the %Windir% and %Windir%\System32 directories. Out of the more than 8,000 files installed with Windows, over one fourth is protected by WFP (called System File Protection in Windows ME). When a protected file is deleted, renamed, or moved, Windows will replace it with a legitimate copy (from the install media or %Windir%\System32\Dllcache). Although WFP can be disabled, it isn't easy or recommended. WFP provides nice (although not solid) protection against many file virus attacks.

Use NTFS Permissions

The single best way to prevent unauthorized program and file execution is to use NTFS permissions. For every high-risk file and unused application, prevent non-Admin users from being able to execute the file. By default, most Authenticated Users have Read & Execute access to all Windows system files. Make sure that administrators have Full Control to those files, but remove the Authenticated Users group from having Read & Execute permissions. Note that I didn't say deny permissions. Some readers may accidentally enable Read & Execute-Deny permissions to the Authorized Users or Everyone groups as a result of the recommendation. Unfortunately, administrators are also part of those groups so you don't want to be denying access. Instead, add Administrators and uncheck the Authenticated Users permissions. You may have to remove inheritance on some files and folders to change default permissions.

If you have ever wondered how to disable Outlook Express without disabling Outlook (Outlook requires Outlook Express files), use NTFS permissions. Find the Outlook Express executable (i.e., F:\ProgramFiles\Outlook Express\Msimn.exe) and remove non-Administrators from being able to run it.

Remove Everyone Full Control Permissions

Consider replacing any permissions handed to the Everyone group with a more select group. At the very least you can usually replace the Everyone group with the Authenticated Users group and guarantee that anyone using a related protected resource at least had to provide valid authentication credentials.

One of the most fundamental computer security tenets is to assign security principals only the bare minimum permissions necessary to perform their duties — the principle of least privilege. For any protected resource to which non-Admin users have Full Control, consider changing to Modify permissions instead. Full Control is a lot of authority to give any non-Admin user. It gives them the capability to change permissions and to take ownership. Modify permissions is all most non-Admin users needed. Also remember that by default all Authenticated members of any trusted domain in the forest have the same permissions that your Authenticated Users and Everyone groups have. However, you can limit foreign domain users' access further by using NTFS permissions.

Create a Least Privilege Users Group

As administrators, we are continually asked to add new users who only need basic security permissions to a very limited subset of files and folders. Maybe it is an external consultant who needs access to the internal SQL database running on one server, or an external business partner who needs to log into your IIS server and pick up one file, or an onsite security consultant performing an audit. In any case, all administrators need to create user accounts that should only have access to exactly what they need and no more. Here's a solution.

Create a custom security group called LeastPrivilegedUsersGrp. Create a LeastPrivilegedUsersOU organization unit and place the LeastPrivilegedUsersGrp inside. Add any security principal that should have very limited access to both the OU and the group. Better yet, add membership to the LeastPrivilegedUsersGrp group using the Restricted Groups group policy feature (see Figure 5-6). You can find more about the Restricted Groups feature in Chapter 14, "Group Policy Explained."

Using a group policy object, severely restrict the User Rights and privileges of the members of the LeastPrivilegedUsersGrp to a common bare minimum. Create a LeastPrivilegedUsersGPO and attach it to the LeastPrivilegedUsersOU, and set it to be enforced (this will be explained in Chapter 14). Then, using the File Security feature of group policy, ensure that the members of the group have Full Control-Deny to all files and folders on every drive, starting with the root directory of each volume and working on down. Inheritance should do most of the work.

image from book
Figure 5-6

Then, wherever the members need access, go to those specific file and folder locations and grant specific access permissions. The specific permissions should override the inherited permissions set by the group policy. Using this method, you can create a group whose members have no rights to any file and folder in your network, except exactly where you want them to have access. No more having to wonder what files and folders these supposedly restricted users had before. Just drop the user into the OU, set their specific permissions needed, and let Active Directory do the rest. This is a great strategy for temporary workers, consultants, web site users, and web site pool identities.

Use GPO Where Possible

Group Policy objects are a wonderful way to automatic almost any computer security setting, but they are especially helpful when setting file permissions. By default, when you delete or overwrite a file, it loses its set NTFS permissions. For example, if you delete a file protected by WFP, the permissions assigned to the replacement copy are inherited from the parent folder and do not necessarily match the permissions of the file deleted. The same thing can happen when Microsoft updates a file. The update overwrites the original and file permissions can sometimes be lost. Normally NTFS permissions are tied to the exact object they were set on. A new object, even if it has the same name, is a different object, so the original NTFS permissions are lost. Luckily this is not true when using a GPO.

By using group policy to set permissions, the NTFS permissions will be set on the file every time the GPO applies as long as the file's name and location do not change. The object the permission is being set on in the GPO must already exist on the machine where the GPO is being configured. However, you can make up any "fake" object as a placeholder, if you need to, to help with creating the policy. For high-risk files, use a GPO to ensure that the permissions are being applied and pushed out to all managed computers without having to worry about the files being updated or re-created and losing their permissions.

There are two security considerations. First, setting an object's permission via a GPO does not mean the logged in user cannot change the permission. When permissions are set via a GPO, the object's permissions are set, or reset, whenever the GPO re-applies. During the time interval between GPO applications, the file's permissions can be modified if the manipulator has the appropriate security permissions (i.e., Change Permissions). A GPO, by itself, only sets permissions. It does not prevent permissions from being changed otherwise if the manipulator has the necessary permissions.

Second, when a GPO is applied, it is not re-applied again for 16 hours by default (called the maximum GPO refresh interval) unless the GPO itself is new or changed. If the object being protected by the GPO is deleted or re-created (of course, the user or process doing this would have to have the appropriate permissions to do so), the predefined GPO permissions could take up to 16 hours to re-apply. You can manually force a GPO to re-apply immediately by typing in Gpupdate.exe /force at the affected workstation, or, more quickly, by telling the GPO to always re-apply during its periodic refresh interval (which by default is every 90 minutes with a random offset of 30 minutes). To turn on the latter feature, enable Computer Configuration\Administrative Template\System\Group Policy\Security policy processing and its child option of Process even if Group Policy objects have not been changed. You can download a security template with the default settings listed in this chapter from the Wrox web site.

Software Restriction Policies

Starting with Windows XP Pro, Microsoft introduced the concept of Software Restriction Policies (SRP). SRP allows an administrator to specify what software is allowed to run on any managed computer. Software Restriction Policies 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 Computer Policy. Choose Computer Configuration\Windows Settings\Security Settings\Software Restriction Policies to access SRP settings (see Figure 5-7). Group Policy, but not Local Computer Policy, allows administrators to configure SRP in the User Configuration area as well.

image from book
Figure 5-7

First, before administrators even begin configuring SRP, they need to establish what software should and shouldn't be allowed to run on a managed computer. This includes all user applications, utilities, Windows program files, etc. If the admin is going to restrict what files and programs are allowed to run, he or she must first get a list of what is to be allowed. Next, 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)?

A good security policy is to deny by default all software except that which is explicitly allowed, much like a firewall should be configured. This method takes much longer to get working initially but pays back the biggest security dividend. If an administrator could stop unauthorized programs from running, it would stop nearly every computer security problem in the enterprise. Most of the recommendations in this book are because administrators are not willing to go this far in preventing unauthorized applications from running. This choice is called Disallowed in SRP. The other choice — that is, to allow all software to run except that which is explicitly denied — is called Unrestricted. Unrestricted is good at stopping specific nuisances, such as spyware, but it doesn't provide nearly as much security for the effort. You can also decide who SRP applies to — all users or all users except local Administrators.

Rule Exceptions

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. For example, you can deny all VBScript files except those signed by an internal private 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 (any user or just Administrators). 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. Administrators can define whether certificate revocation checking is enabled on Certificate rules and how revocation is checked (Publisher, Timestamp, or both).

Hash rules allow you to input a valid MD5 or SHA1 file hash value (also known as a digital fingerprint). Like Certificate rules, they allow 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 5-8).

image from book
Figure 5-8

Most administrators using 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 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 useless.

Lastly, Path rules allow you to define exceptions using directory or registry paths. When SRP is enabled, Microsoft inserts four default Path rules ensuring that users don't lock themselves out of Windows the first time they enable the Disallow option. 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 can easily be bypassed by a semi-knowledgeable end user — for instance, if you right-click the protected executable and create 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.

There are some issues with SRP beyond figuring out what is and isn't allowed. It isn't perfect. For one, it only works 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. The initial configuration (by file extension) is only 31 file types (see Figure 5-9). You can easily add more file extensions to SRP's file blocking mechanism, but it far less than the hundreds of file extensions defined in Windows 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.

image from book
Figure 5-9

In at least one instance, SRP permissions are better than NTFS permissions. It is the problem of how to secure applications with NTFS permissions 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 has SRP-like policies. Choose UserConfiguration\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.

There are many third-party tools that do the same thing as SRP, such as 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.

Enable Auditing

On high-risk files, consider enabling Object Access auditing. Turn on the audit categories you wish to monitor, and review event logs manually or with a tool looking for signs of intrusion. For example, enable auditing on the Hosts file. Set the default permissions on the Hosts file to be Read-only for non-admin users (or administrators, if you like). Enable Object Access auditing on the file and tell it to report any successes or failures for access requests beyond reading. If spyware tries to modify it, Windows will generate an event log entry. Consider doing this for any high-risk files that are especially critical.

Keep Patches Updated

Many file and program vulnerabilities are patched by the vendor. Keep your operating system and applications patched and updated.

Other Defenses

There are other defenses that can be taken to minimize the threat of unauthorized file and program execution, including the following:

  • Blocking malicious files at the e-mail server and gateway devices. Any file-blocking device should allow file blocking by file extension or MIME types. Better devices actually inspect a file's header to determine its legitimacy (more on this in Chapter 11).

  • Using NTFS permissions on high-risk registry keys and values can provide as much security as NTFS permission for files and folders. This will be covered in the next chapter, "Protecting High-Risk Registry Entries."



Professional Windows Desktop and Server Hardening
Professional Windows Desktop and Server Hardening (Programmer to Programmer)
ISBN: 0764599909
EAN: 2147483647
Year: 2004
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net