Foreground Security's Sr. Incident Handler and Malware Analyst, Curt Shaffer, co-presented this past weekend at the Shmoocon 2012 Security Conference with Chris Cuevas from Secure Ideas. The research came from two discussing how crazy the marketing was on this newer technology. They decided to test out three popular choices for application whitelisting and see if the hype was true. We do want to mention that Foreground and the researchers believe application whitelisting is a step in the right direction, the implementation has flaws and it should only be used as part of a strong defense in depth solution.

The results are in and they found that Application Whitelisting is nothing more than a small road block much like current Anti-Virus. They found that there are some very easy ways to get around this type of software due to lack of features, lack of understanding the current threat landscape and in some cases vulnerabilities in the software that allow complete bypass. They took the audience through their testing methodology and findings. They tested Bit9 Parity 6.0.x, Microsoft AppLocker and McAfee Application control on both Windows XP and Windows 7.

They outlined the methodology so other people could test their implementations. This one goes into a bit more detail because they wanted the readers to also know what failed. That way they get an idea of what was tried. They also plan on releasing Metasploit modules that will utilize the capabilities they found to be successful.

Methodology

•       Windows File Protection - Windows XP performs file protection checks by file name. Therefore, if you change calc.exe for example to winlogon.exe and run the calculator, you will be unable to kill the process because of Windows XP's over-protection of the name. Malware authors have known this for a white. Curt found this to work, but inconsistently with Bit9 on the Windows XP testing. Windows 7 now does file protection via hash and/or digital signature.

•       File Naming Fun - The two tried a number of file name tricks to see if they could bypass checks that the developers might not have taken into consideration. They attempted things like the Right to Left Override technique, Alternate Data Streams and chaining file type associations, making .txt files executable for example.

•       Iexpress packaging - This was an old technique that used to work against App Locker. Using the iexpress packaging utility built into Windows digitally signs the external package with a trusted certificate from Microsoft. Due to not properly checking the internal executable to the package, one was able to execute code not on the approved publisher list. This technique did not work on any of the versions tested this time.

•       Java Exploits/Malware - Java was very successful in all cases. It will be very difficult for companies and agencies to get a handle on Java applications. In some situations the development of these applets are not in the control of the company or agency that utilizes them. How can they keep up on ensuring they have the latest greatest version on their whitelist. Because of this the two were able to utilize exploits in Java to execute Meterpreter payloads and they were also able to create Java applets that did such things as direct shellcode execution in memory and write out localized Javascript files that were able to execute.

•       Flash Exploits/Malware - Flash exploits and malware were successful in many of the same reasons of the Java attempts. So much on the Internet relies on Flash, therefore how will you keep a handle on it to keep your list populated with trusted code only?

•       Adobe Exploits/Malware - Adobe, much like the others mentioned above was successful due to the inherent trust of the Adobe application.

•       JavaScript - JavaScript had some inconsistency in execution. It did appear that JavaScript was blocked, especially if trying to build out an executable file or local script. Chris discussed some capabilities of using this technique in things such as Chrome or Firefox extensions and addons. In that way, the script would be executed with local privileges, making it successful.

•       VBA - VBA was another case where there was inconsistent results. Curt was able to execute direct shellcode from VBA built into a Microsoft Office document. The examples he utilized were from work by Dider Stevens and @scriptjunkie1. Utilizing direct Shellcode execution, it was pretty easy to get shell.

•       Raw Shellcode - Raw shellcode was something that was able to be used not only in the VBA scenario, they were able to utilize shellcodeexec to allocate memory space to inject code into.

•       Powershell - Chris did a good bit of testing with Powershell. The interesting thing with it is that by default, this is blocked. However utilizing the Get-Content keyword, Chris was able to read in content from another file line by line and execute PowerShell code line by line.

•       LoadLibraryEx - Chris found that research done by Didier Stevens on two functions of this API allow someone to just tell App Locker "these are not the droids your looking for". LOAD_IGNORE_CODE_AUTHZ_LEVEL and SANDBOX_INERT allow for this functionality. This didn't work in all cases by it will work on default App Locker installations. Microsoft does have a hotfix, but this is not built into the utility yet.

They did some testing with HTML5, digitally signed malware and masquerading as a CD-ROM dive. The results of these were not included in full. The two plan on following up with an updated version of the presentation which will include these things as well as other vendors. There are some other things that you can test that are part of normal configurations. Try to locate and launch from %netlogon%. This directory should not be writable by general users. If you can pop an admins box, you might get lucky though. This is normally a trusted directory because of logon scripts and Group Policy scripts are kept here. Try to locate and launch from SMS/Bigfix/SCCM Directory. There are generally central locations for packages for network wide deployment. It may even be possible to execute files by injecting into those processes thus utilizing their trust and permission level. This was not tested, but is an open option. There are also local directories that you might be able to launch from SMS/BigFix/SCCM local cace (i.e. c:\windows\system32\ccm\cache). Sometimes there are rules to ignore these directories. You could also try crashing the process and see how it acts offline/in limbo. Finally you could also launch from a network share in general.

All three vendors failed pretty similarly in all of these techniques. They believe this is why there is a fundamental problem with the technology as it is today. There were two failures that were worth extra note. The Bit9 Parity application has a flaw where it does not do full self protection. Curt was just poking around the internet, Google hacking to see if he could find anyone that alluded to any weakness in any of the applications. He stumbled on a video on Youtube from November of 2012 (linked below). There the author was able to utilize DLL injection to get Parity to execute any code they wanted. Of course Curt tried this and it failed on the newer versions. However, Curt noticed that there is a child process of Pairty.exe called notifier.exe. This is the part of the application that controls the visual pop up message telling the user that something they attempted was denied. Curt attempted DLL injection on the notifier.exe process and Bob's your uncle it worked! How many times are application developers only going to fix the immediate issue with their code rather than asking themselves where else might this be possible? The scary thing here is that he was able to also execute files that were in a banned state globally. Not only did Parity trust notifier.exe, it appears that it inherently trusts anything that spawns from it.

Below are the steps you can do to tests this same functionality:

Prior access is needed to recreate this flaw in this example. However, code could be crafted and delivered remotely to the user by email or drive by download.This will also require that a DLL that will be used for infection is on the computer to be exploited.

On a machine with and up to date policy configuration in Secon 20 or "lock down" mode. This configuration is used to stop all executions of files that are not on the whitelist of permitted applications.

Execute an action to cause partiy.exe to spawn notifer.exe if it is not already running.This can be accomplished by running an executable file in a pending or banned state.

Once notifier.exe has launched the user can use the program called "Process Hacker" http://processhacker.sourceforge.net/. This application allows the capability to inject DLLs into a process. Note: on the proof of concept machine, the Process Hacker executable file will need to be permitted to run.

In Process Hacker right click the newly spawned notifier.exe process choose the Miscellaneous menu and Inject DLL...

If the exploit worked, the user will then see a new process forked under notifier.exe. The two were able to inject a Metasploit Meterpreter payload that would open a reverse shell to the attackers system.This was tested with both pending files which should not have been permitted to run as well as specifically banned files.

It should be noted that the information being released on the vulnerability is in proof of concept only at this time. While attempting to do this manually, rather than from code exploitation, the user may need to retry the whole process multiple times before having success. As time permits, the two are releasing a Metasploit post exploitation module that will be more precise with the injection, making the exploit more stable.

This technique was tested on Windows XP with the latest operating system patches and Windows 7 in a similar configuration.

There is a work around that they provided for those using a vulnerable version of Bit9 Parity. Below is the fix. Please note, the Bit9 employee in the audience did mention this may not be a supported configuration.

The work around for this is to enable Memory Protection on the notifier.exe process. *Note: depending what version you are running, this may not be a supported configuration.

6.0.0 does not have a direct link to the memory rules because of this:

Navigate to https://<Bit9ServerIP>/memory-rules.php

Click Add Memory Rule > Enter a name for the rule

Choose Enabled for the status

Check all Restrictions > For target process type *notifier.exe*

Any source process

Any user or group

Choose the policies it applies to

You may want to choose to report only until you are confident in the settings change.

Once you have modified this rule from alert only to block. This technique is no longer possible in the testing done thus far.

The second flaw found in Bit9 Parity was the fact that they do not perform SSL certificate validation by default for client/server communication. The researchers were able to man in the middle the communications with Burp Proxy. It was clear that these packets could be replayed or crafted to instruct the client to change it's security level, approve files, enter into local approval mode which will trust all new files until taken out of the mode, or disabling the client completely. It is possible that communication may be sent back to the server as well to make global configuration changes. These techniques were not fully tested yet. The two did want to ensure everyone knew of the potential though.

The two ended the presentation with a demonstration of injection of a Meterpreter.dll into the notifier.exe process and using Powershell to inject a binary into the system bypassing UAC via the Hak5 Rubber Ducky. The later part goes to show that physical access is game over in almost all cases. Another possibility with physical access is to just boot into Windows Safe Mode and disable the Parity.exe service. It is probably also possible to do this with the other vendors as well.

To reiterate, the presentation was not to say that any of these vendors or the idea itself is bad. They both agree that it is certainly a step in the right direction. They just want the vendors to let people know that its a good next step in a defense in depth model. It all boils down to if you can get cmd.exe on a box, it's game over because of the inherent trust that exists for tools and trusted functions of the operating systems.

Foreground Security plans on releasing a demonstration video where Curt will show an example of how he is able to gain access to a standard user computer via a Java exploit. Using a Metasploit module called incognito, he can masquerade as an admin that has logged on to manage the box. From there, he can utilize their token to log onto another domain admins' workstation. Armed with this access, he is able to pull the admin's password from either LSASS or the registry. With those credentials, he can pass the hash to gain access to a domain controller. Once on the domain controller, he changes the sethc.exe, sticky keys executable file, with cmd.exe. All that needs to be done at this point is initiate a remote desktop connection to the server. Not needing to enter credentials, he just presses the Shift key 5 times. This would normally open the sticky keys application, but since it was changed out with cmd.exe, also a trusted application, he gets shell with local system privileges.

Once on the shell on the domain controller with this access, he turns on volume shadow copies and uses a technique that he found from LaNMaSteR53 from the Paul Dot Com crew to take the ntds.dit, thus gaining access to all passwords in the domain.

They idea of this demonstration is to show that with a mix of memory only exploitation and built in tools, he is able to pwn the whole network. This example works with all three of the vendor's protection enabled.

Both Chris and Curt wanted to bring out that they didn't reveal any ground breaking research here. They just used techniques they found by people infinitely smarter than them and applied them to a newer technology. You will be able to find the video for the Shmoocon presentation once they put them online at www.shmoocon.org. You can download the slides now from here: presentation slides. There is a lot more research to be done here. They believe they only touched the tip of the iceberg. Keep your eyes open for further discussions on this topic to include new vendor implementations and techniques found. A Metasploit module, or a few, will be released in the coming weeks for everyone to use in their pentesting or assessments of their network. If you have any questions, please don't hesitate to contact Curt Shaffer at Foreground Security or Chris Cuevas at Secure Ideas. They will be happy to discuss this more.

Some links on the research topics (Special Thanks to everyone!)

Talk Abstract: http://www.shmoocon.org/speakers#raising

http://secureideas.net/

http://www.scriptjunkie.us/2012/01/direct-shellcode-execution-in-ms-office-macros/

http://blog.didierstevens.com/2011/01/24/circumventing-srp-and-applocker-by-design/

http://blog.didierstevens.com/2011/01/25/circumventing-srp-and-applocker-to-create-a-new-process-by-design/

http://blog.didierstevens.com/2008/10/23/excel-exercises-in-style/

http://www.offensive-security.com/metasploit-unleashed/VBScript_Infection_Methods

http://r362.squarespace.com/blog/2011/5/30/remote-dll-injection-with-meterpreter.html

http://pauldotcom.com/2011/11/safely-dumping-hashes-from-liv.html

http://www.youtube.com/watch?v=665d-jrcgzc

Hotfix for vulnerability in AppLocker: