Thursday, August 4, 2011

Bypassing AES Zone Checks In A .VBS Logon Script

Attachment Execution Services (AES)

Beginning with Windows XP SP2, Microsoft included a security feature known as Attachment Execution Services (AES) in its operating systems. For any executable file invoked via the ShellExecute() API, AES attempts to determine what zone the attachment originated from (Internet, Local Intranet, Trusted Sites, or Restricted Sites), and then applies security restrictions accordingly. The behavior of this feature can be adjusted via Internet Explorer's Internet Options. To change it, open Internet Explorer and go to Tools > Internet Options, and then select the "Security" tab. From there, select the zone you wish to modify the behavior for, and click the "Custom Level" button. Scroll down to the "Miscellaneous" section, and locate the "Launching applications and unsafe files" option. You may then choose either "Disable", "Enable", or "Prompt".

The Open File - Security Warning

You can observe the effects of AES by attempting to launch an executable attachment from an internet resource, or by navigating to the UNC path of an executable file on your network by using the FQDN of the server it resides on, and launching the file. In the case of the latter, you receive an "Open File - Security Warning" prompt. Why do you receive this warning despite having enabled the "Launching applications and unsafe files" option for the Local Intranet zone? This occurs because the FQDN is assumed to be a reference to an internet resource, hence the settings for the Internet zone are applied instead. You will notice that navigating to the same executable by using only the server's hostname in its UNC path (without the domain suffix), you can then launch the file, and bypass the security warning. This allows the program to execute uninterrupted.

Logon Script Considerations

Most administrators prefer to keep all of their logon scripts in a central location, and typically store this repository in the NETLOGON folder, so that it is replicated across their domain controllers. Another common practice is to create a single VBScript file, which in turn launches any other executables required during logon, and subsequently assign this master logon script to all users. It seems logical then to launch those executables from the master script (usually invoking either the Run() or Exec() method of a WScipt.Shell object) by referencing the UNC paths of the executables using the domain root FQDN (i.e. \\mydomain.com\NETLOGON\Script.vbs). This ensures that any future decom of a DC will not affect the execution of an end-user's logon script. However, this also opens up the possibility for AES to interfere with the proper execution of your script. Since AES will perceive the UNC path as an internet resource due to the presence of your domain's FQDN, it may prevent all or part of it from running.

Temporarily Bypassing AES Zone Checks

You can get around this AES interruption issue by temporarily disabling zone checks at the beginning of your script, and then re-enabling them prior to its termination. This is done by manipulating the SEE_MASK_NOZONECHECKS process environment variable. Setting SEE_MASK_NOZONECHECKS to 1 disables zone checking. Conversely, removing the variable re-enables this behavior. For an example of disabling and re-enabling zone checks, please see the VBScript code snippet below:

Please note that it is very important not to leave zone checking disabled, as this presents a HUGE security risk. For more information regarding AES and the SEE_MASK_NOZONECHECKS environment variable, please refer to KB article 889815.

No comments:

Post a Comment