At the end of January, Remko Weijnen posted a
What this Exploit Does Do
Without showing the entire hand, the technique fools the system into launching one process, whilst believing it is another. So, using Excel.exe (which is owned by a Trusted Owner- but equally any of the applications in the office suite could potentially be used to launch this exploit), I can spawn a process (with a number of caveats) to access an otherwise “blocked” executable- whether this executable has been blocked by Group Policy or by using a product such as AppSense Application Manager. For example, you may have set the Prevent access to the command prompt Group Policy setting, or if using AppSense Application Manager may have explicitly denied access to CMD.EXE.
For all intents and purposes this process appears to be the Trojan I have specified, rather than the actual target. Remko specifically used Excel.exe as the target in his video- so although a CMD prompt is available the process appears as if it is Excel.exe in Task Manager, and even is grouped as such on the Start Menu.
What this Exploit Does Not Do
The Exploit, whilst being able to launch a process is still within a gilded cage. The process is in no way elevated- so in a default Windows environment- a Standard User still cannot perform destructive actions on system folders and files, nor read files they do not have permission to read. In the context of AppSense Application Manager, if you launch, for example, CMD Prompt and then try to launch BLOCKEDAPP1.EXE, BLOCKEDAPP1.EXE will still get blocked- you have not escaped the protection intrinsic to Application Manager- merely created another vector to attempt to launch processes from, which will be evaluated and allowed or denied based on the policy.
The video below shows the extent and effect of this exploit in a Windows Server 2003 x86 environment with AppSense Application Manager 8.4 installed:
How to Stop this Exploit
This exploit relies on the fact that the Microsoft Office Suite of applications all include a Compiler inside them (not a separate executable). This is done so Visual Basic for Applications can be used to created Macros, Methods and Functions for use with more demanding use cases of the Suite. The major security hole that including this compiler into the executable introduces is that VBA can talk directly to libraries that are core to the operating system- including the Kernel. To make matters worse, malicious code executed through here is not inspected by Anti-Virus or other software in the same way it would a standalone compiler meaning that the mere inclusion of this is something that Viruses can use to inject code into your environment.
With that said Microsoft dealt with it to an extent by introducing Signatures for Macros and defaulting the Security Policy to Very High- blocking any Macro that did not have a digital signature from a trusted source. This can also be mandated through Group Policy and remains the single most effective environment for prevention of this exploit.
Additionally, if the Prevent Access to the command prompt and Precent access to Registry editing tools Group Policy Objects are enabled launching CMD or Regedit will occur, but immediately be killed off by Windows.
Having said that, for environments where for whatever reason you cannot accept these basic levels of security, there is a workaround to preventing the specific code witnessed from operating using AppSense Application Manager- but it may impact custom plugins and other tools used within the environment. That workaround is:
- Include a Process Rule for any of the applications which can compile VBA (the majority of the Microsoft Office Suite- all versions) to block Kernel32.dll and scrrun.dll.
This workaround was discovered within hours of the initial post using Rules Analyzer in the AppSense Application Manager console to monitor an affected client, and required no knowledge of the techniques utilized within the code- merely a risk assessment of what preventing this applications from running could have.
The effects of this are seen in the following video:
And an example policy configuration for AppSense Application Manager 8.0 can be found here: Application_Manager_-_Desktop_Template_Configuration_with_VBA_Exploit_Lockdown.zip
I’ve been deeply impressed by Remko and the community’s methodical manner of finding and understanding this technique, and as a company it is certainly something AppSense will be looking to address given that there does not seem to be an existing solution of allowing full access to VBA on the one hand, and preventing access to disruptive techniques that are the domain of hackers, virus writers and Trojan horses on the other. User Virtualization is, and always will be, about the balancing of the needs and wants of Users on the one hand, with the requirements placed upon them by the environments they operate in in the other, and this truly illustrates that struggle in a vivid and engaging way.