Addressing CVE-2014
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2014-0322 | Use-After-Free Remote Code Execution in Microsoft Internet Explorer CVE-2014-0322 is a use-after-free memory corruption flaw (CWE-416) in Microsoft Internet Explorer that allows remote code execution. It is triggered when the browser processes crafted web content: an attacker-controlled object is freed and then reused, corrupting memory, and in the known campaign FireEye observed it being exploited as a 0-day via a watering hole attack on websites visited by targets. A successful exploit lets an attacker execute arbitrary code with the privileges of the logged-on user, typically through nothing more than a drive-by visit to a compromised web page. Everyone browsing with the affected Internet Explorer versions was exposed, which at the time of disclosure meant on the order of hundreds of millions of desktop users given IE's dominant market share. Exploitation is confirmed in the wild - the flaw was added to the CISA Known Exploited Vulnerabilities catalog on 2022-05-04 - though the source data notes no standalone public proof-of-concept code. Do: Apply Microsoft's March 2014 Internet Explorer security updates per vendor instructions, as required by the CISA KEV catalog. Inventory endpoints for legacy or unpatched IE usage, restrict browsing with IE on outdated hosts, migrate systems still using IE to a supported browser where possible, and monitor for watering-hole/drive-by compromise indicators. | — | 85% | KEV |
| masshundreds of millions of users at the time of disclosure (IE held the majority of desktop browser share in 2014); residual exposure now limited to legacy… | |
| CVE-2014-1776 | Use-After-Free Memory Corruption RCE in Microsoft Internet Explorer CVE-2014-1776 is a use-after-free memory corruption flaw in Microsoft Internet Explorer that can be triggered when the browser processes specially crafted web content, corrupting memory in a manner an attacker controls. A remote attacker can deliver the malicious content from a site they host or inject it into a compromised/legitimate website, causing Internet Explorer to access freed memory under attacker control. Successful exploitation allows arbitrary code execution in the context of the current user, giving the attacker that user's privileges on the client machine. Any organization or user running an affected version of Internet Explorer is exposed, and the flaw has been associated with highly targeted attack activity, including the FireEye-documented zero-day exploit in the wild and the targeted Pirpi-distributed 0-day. The vulnerability was exploited in the wild as a zero-day, was addressed by Microsoft updates, and was added to CISA's Known Exploited Vulnerabilities Catalog on 2022-01-28; no public proof-of-concept is known. Do: Apply Microsoft's Internet Explorer security updates per vendor instructions, prioritizing this as a KEV-required remediation, and verify all workstations still launching IE or legacy MSHTML-based content are patched. Reduce residual exposure by steering users away from Internet Explorer for untrusted sites and auditing intranet applications and tooling for lingering IE dependencies. Because the exact affected versions are not in the data, cross-check Microsoft's advisory to confirm your deployed IE versions are covered by the fix. | — | 88% | KEV |
| mass≈ hundreds of millions of users/endpoints (IE held roughly half of global browser market share when exploited in 2014) | |
| CVE-2014-6332 | Remote Code Execution via Array Bounds Flaw in Microsoft Windows OLE Automation CVE-2014-6332 is a memory-corruption flaw (CWE-119) in OleAut32.dll, the OLE Automation component shipped with Microsoft Windows, in which OLE automation arrays are mishandled, allowing out-of-bounds memory access. A remote attacker triggers it by luring a user to a crafted website whose script (typically executed through Internet Explorer) calls into the vulnerable OLE Automation code, corrupting memory on the victim machine. Successful exploitation yields remote code execution with the privileges of the logged-on user, generally giving the attacker full control of the workstation. Because OleAut32.dll is a core OS component, essentially every Windows client and server in circulation at the time was affected; Microsoft addressed it in the November 2014 security updates (MS14-064). The flaw is listed in CISA's Known Exploited Vulnerabilities catalog (added 2022-03-25), indicating known in-the-wild exploitation, and EPSS assigns a 95% probability of exploitation within 30 days (100th percentile); no public PoC is tracked in the source data. Do: Apply Microsoft's November 2014 Windows/OLE security updates (MS14-064) across all Windows clients and servers, prioritizing internet-facing systems and workstations used for web browsing, and confirm the patched OleAut32.dll is present via patch-management or vulnerability-scanner checks. Because the flaw is KEV-listed and exploitable in a drive-by web-attack scenario, treat any remaining unpatched Windows host as high risk and isolate legacy systems that cannot be updated. | — | 95% | KEV |
| mass≈1 billion+ Windows installations (OleAut32.dll ships with every Windows client and server) |
Full article839 words · extracted from unit42.paloaltonetworks.com · click to collapse
Continuing a recent trend in which Internet Explorer vulnerabilities are exploited using Flash, samples of an SWF purportedly used in conjunction with CVE-2014-6332 have appeared in several places. The most famous examples of this trend are the exploits for CVE-2014-0322 and CVE-2014-1776.
We have yet to encounter the SWF sample with its original exploit attached, but by looking at the SWF, it is clear that it is constructed to function with several forms of memory corruption, making the vulnerability itself less interesting. That is a great example of why our Advanced Endpoint Protection approach, which focuses on the core techniques used in attacks, works well. It will prevent uses of this SWF framework, regardless of the vulnerability it is used with.
The interesting part in this exploit is the Flash component. At first glance at the decompiled ActionScript shown here, it seems fairly straightforward, sharing much of its code with the previously seen exploits:
This post will not go into detail regarding the spray mechanisms since they are almost identical to the ones seen in previous exploits, but in short:
- A 0x18180 element vector is sprayed, each vector 0x3FE bytes in size.
- A timer routine is started, with the browser vulnerability is triggered via an ExternalInterface call to a JavaScript/VBScript function.
- Once the timed routine detects that the corruption has occurred by scanning the vector for a longer vector, it stops and continued to the next phase.
- The following vector is corrupted to span the entire memory and read/write abstracts are defined
- A pointer from Flash_*.ocx is leaked and its base is determined by scanning backwards.
After that, addresses of VirtualAlloc and GetProcAddress are resolved from the import table, for later use in assembling the ROP and shellcode.
The ROP chain is triggered by overriding the previously created Sound object's vtable and calling the toString method, leading to the first ROP gadget.
At this point it’s worth mentioning one particular behavior. Prior to the shellcode, after the stack pivot, the original stack address (now in eax) is preserved in esi, and then put back into esp as part of the shellcode's prologue, enabling the shellcode to run on the original stack.
The shellcode
The interesting part starts with the shellcode, which seems to be tailor made to bypass Microsoft EMET protections, and possibly other security products as well.
The first reference to EMET can be seen when the shellcode sets up its data section (containing mostly hashes of functions to later be resolved):
The shellcode then starts off by resolving the address of NtSetContextThread by calling GetProcAddress, the address of which was previously written into the heap spray (pointed to by ecx) by the ActionScript code.
The shellcode sets up a CONTEXT structure and calls NtSetContextThread, overriding the debug registers and eliminating EMET's EAF feature, as per the method demonstrated by Piotr Bania in 2012.
Once this is accomplished, the challenges faced by the shellcode are greatly reduced.
It then proceeds to resolve the previously entered hashes into functions:
It resolves the following functions from kernel32 and ntdll in two separate loops:
- LoadLibraryA
- GetProcAddress
- VirtualAlloc
- IsBadReadPtr
- WriteProcessMemory
- GetModuleHandleA
- Sleep
- VirtualProtect
- CreateThread
- GetProcessHeap
- CreateFileA
- WriteFileA
- CloseHandle
- WinExec
- GetTempPathA
- SetUnhandledExceptionFilter
- RtlAllocateHeap
- Memcpy
- ZwGetContextThread
- ZwSetContextThread
Once all functions are resolved, it proceeds to read a payload PE that was concatenated to the end of the shellcode by the Flash component. The payload PE itself arrives via a file named "shadow.jpg", and is marked by the magic value 0xDEADBEEF41414141 and another DWORD containing its overall size.
It is copied into memory and then written into a file called "windump.exe" in the Local\Temp directory (retrieved using GetTempPathA).
At this point another piece of evasive code is introduced:
The shellcode checks if EMET.dll is present in the process.
If so it simply calls WinExec normally, and the payload is run. Otherwise, it resets the UnhandledExceptionFilter, saves the current esp value, and calls a wrapper function which first takes control of the last SEH handler (pointed to by the TEB) and jumps into WinExec.
Upon returning it will reset esp to its preserved value and exit cleanly.
Either way, normal execution is restored after having returned from the corrupted sound object's toString method.
Conclusion
This exploit is interesting because it is the first display of an in-the-wild attack targeting machines protected by EMET (specifically, EMET 4.1).
Oddly enough, the bypass is unfinished – this exploit would be caught by EMET's stack pivot check on VirtualAlloc.
Disable or bypass this single test – and the exploit will succeed in bypassing EMET 4.1.
In fact, a fairly small set of customizations could be made to enable this exploit to bypass EMET 5.1 as well.
Albeit half-baked, this exploit shows a significant step toward in-the-wild exploits which bypass EMET, whereas in previous exploits of this nature, exploiters actively avoided machines running EMET by using a since patched information disclosure vulnerability in IE (CVE-2014-7331).
Worth noting: Palo Alto Networks Traps stopped this exploit with several layers of redundancy. We will continue to examine these exploits and update as appropriate.
Text extracted automatically; images, tables and formatting may be missing. Original: https://unit42.paloaltonetworks.com/addressing-cve-2014-6332-swf-exploit/