Headline
Running in the wild, not for so long
Over the weekend we received a report from our partners about a possible unpatched Internet Explorer vulnerability being exploited in the wild. The exploit code uses a memory corruption bug triggered from a webpage but it deeply leverages a Flash SWF file in order to achieve reliable exploitation and code execution.
Over the weekend we received a report from our partners about a possible unpatched Internet Explorer vulnerability being exploited in the wild. The exploit code uses a memory corruption bug triggered from a webpage but it deeply leverages a Flash SWF file in order to achieve reliable exploitation and code execution. The Flash file is made of a sophisticated ActionScript code that allocates certain objects in memory in such a way that they can be corrupted later by the Internet Explorer bug in order to give unsafe access to memory regions to the Flash ActionScript code that will carry on the entire exploitation.
In summary, our analysis of this exploit sample revealed the following:
- ASLR is bypassed by the attacker through a use-after-free IE vulnerability that corrupts the size of a Flash Vector<> object and generates the possibility for Flash ActionScript to access memory unsafely and disclose module addresses, including NTDLL base;
- DEP is bypassed with a ROP gadget which calls into ntdll!NtProtectVirtualMemory in order to change protection of non-executable memory pages to executable;
The good news is that the memory corruption vulnerability used in this attack - CVE-2013-3163 - has been already addressed by yesterday’s Microsoft Security Bulletin MS13-055. If you have not yet updated, please do so at the earliest possible. EMET 4.0 was able to stop this exploit variant before the patch with the following mitigations:
- HeapSpray (also effective for EMET 3.0)
- Multiple ROP mitigations: StackPivot, CallerCheck, MemProt when “DeepHooks” is enabled
Advice for detection and indicators
The common pattern for this limited targeted attack is a drive-by webpage “vid.aspx” or “list.aspx” used as starting point to trigger the bug and run the secondary Flash payload; below we are providing some URL patterns that can be useful for log and network traffic analysis:
h **p://profiles.johnhoward.org/archives/vid.aspx?id=[ALPHANUMERIC CHARS]
h** p://johnhoward.org/archives/vid.aspx?id=[ALPHANUMERIC CHARS]
h ** p://visit.ccgeo.org/act/list.aspx?id=[ALPHANUMERIC CHARS]
As of July 7th, some of the specific Flash samples were still undetected by most of the AV community according to VirusTotal; hashes and filenames of these samples are listed also below to facilitate detection for AV vendors:
MD5
SHA1
FILENAME
d055742371ca82c996dce3672818c28f
2a698512d9b75565be747ba6914fe795bfa98e27
ad.swf
e2fe34c58765b4f6e41e4b096203d04a
81fe2ae7a685014cafc12c3abbcc5ffc9ab27b7e
movie.swf
507d8f868c27feb88b18e6f8426adf1c
2c03a983e147631639b9bbfb697fa35ba10be632
AD1.swf
The shellcode used by the sample received attempts to download a graphic file (pageerror.gif) which contains appended an encrypted and compressed malicious executable, possibly launched from %TEMP% folder using “javae.exe” filename.
Stay safe,
Cristian Craioveanu, Elia Florio
MSRC Engineering
Related news
Today, we are thrilled to announce a preview release of the next version of the Enhanced Mitigation Experience Toolkit, better known as EMET. You can download EMET 5.0 Technical Preview here. This Technical Preview introduces new features and enhancements that we expect to be key components of the final EMET 5.