Haifei Li – McAfee Blogs https://securingtomorrow.mcafee.com Securing Tomorrow. Today. Wed, 16 Jan 2019 01:22:34 +0000 en-US hourly 1 https://securingtomorrow.mcafee.com/wp-content/uploads/2018/11/cropped-favicon-32x32.png Haifei Li – McAfee Blogs https://securingtomorrow.mcafee.com 32 32 Analyzing Microsoft Office Zero-Day Exploit CVE-2017-11826: Memory Corruption Vulnerability https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-microsoft-office-zero-day-exploit-cve-2017-11826-memory-corruption-vulnerability/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-microsoft-office-zero-day-exploit-cve-2017-11826-memory-corruption-vulnerability/#respond Thu, 26 Oct 2017 13:00:21 +0000 https://securingtomorrow.mcafee.com/?p=80117 McAfee Labs has performed frequent analyses of Office-related threats over the years: In 2015, we presented research on the Office OLE mechanism; in 2016 at the BlueHat conference, we looked at the high-level attack surface of Office; and this year at the SYSCAN360 Seattle conference, we presented deep research on the critical Office “Moniker” zero-day vulnerabilities. […]

The post Analyzing Microsoft Office Zero-Day Exploit CVE-2017-11826: Memory Corruption Vulnerability appeared first on McAfee Blogs.

]]>
McAfee Labs has performed frequent analyses of Office-related threats over the years: In 2015, we presented research on the Office OLE mechanism; in 2016 at the BlueHat conference, we looked at the high-level attack surface of Office; and this year at the SYSCAN360 Seattle conference, we presented deep research on the critical Office “Moniker” zero-day vulnerabilities.

This month, Microsoft released an update for an Office zero-day attack. We examined an in-the-wild sample, and with this post we share our findings to help others understand the threat.

The sample arrives as an RTF file, and embeds at least three objects (through the control word “\object”). This is a memory corruption vulnerability, so it needs additional steps to archive the full exploitation.

1. The first object, in the following figure, shows that it loads a COM object whose CLASSID is D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731.

 

If we look into the Windows registry, we see that the COM DLL C:\Windows\system32\msvbvm60.dll will be loaded. The purpose of loading this DLL is that msvbvm60.dll is not compatible with address space layout randomization (ASLR), thus it can be used to bypass ASLR and data execution prevention (DEP) on older Office versions. (We will explain later.) This is not a new trick; researcher Parvez Anwar described this process in 2015.

2. The second object is a .docx file that employs the ActiveX.bin technique to spray the heap, also not a new trick. McAfee Labs first identified this exploitation technique in a zero-day attack discovery in 2013; our colleague Debasish Mandal discussed this technique in one of his recent posts.

3. The third object is the cause of this vulnerability. It is an embedded .docx file. When this .docx is rendered, a memory corruption vulnerability is triggered. Specifically, we have identified the problem is due to mishandling of nested tags in the Office Open XML format. The key tags follow:

With help from the first and the second steps, an attacker can hijack the program’s control flow to a predictable address in msvbvm60.dll’s code by exploiting the memory corruption vulnerability. This is the classic step of “stack pivot” for defeating ASLR and DEP. (See the next figure.) Following the return-oriented programming chain and shellcode comes the main payload, which we will not discuss in this post.

This exploitation technique works only on older Office versions. Since Office 2013, Microsoft has employed the security feature Forced-ASLR. As its name suggests, the feature forces the randomization of a module’s loading address even if the DLL is not ASLR compatible. Thus this in-the-wild attack can work only on Office 2010 and older versions. Nonetheless, because the underlying vulnerability does affect newer versions of Office, we recommend that all Office users install the official patch as soon as possible.

For McAfee NSP customers, we have released signature 0x45219c00 (UDS-HTTP: Microsoft Office Memory Corruption Vulnerability (CVE-2017-11826)) to prevent this attack.

Thanks to my colleague Bing Sun for his help with the analysis.

The post Analyzing Microsoft Office Zero-Day Exploit CVE-2017-11826: Memory Corruption Vulnerability appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-microsoft-office-zero-day-exploit-cve-2017-11826-memory-corruption-vulnerability/feed/ 0
Critical Office Zero-Day Attacks Detected in the Wild https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/critical-office-zero-day-attacks-detected-wild/ Fri, 07 Apr 2017 23:14:50 +0000 https://securingtomorrow.mcafee.com/?p=71267 At McAfee, we have put significant efforts in hunting attacks such as advanced persistent threats and “zero days.” Yesterday, we observed suspicious activities from some samples. After quick but in-depth research, this morning we have confirmed these samples are exploiting a vulnerability in Microsoft Windows and Office that is not yet patched. This blog post […]

The post Critical Office Zero-Day Attacks Detected in the Wild appeared first on McAfee Blogs.

]]>
At McAfee, we have put significant efforts in hunting attacks such as advanced persistent threats and “zero days.” Yesterday, we observed suspicious activities from some samples. After quick but in-depth research, this morning we have confirmed these samples are exploiting a vulnerability in Microsoft Windows and Office that is not yet patched.

This blog post serves as a heads-up for our customers and all Office users to protect against this zero-day attack.

The samples we have detected are organized as Word files (more specially, RTF files with “.doc” extension name). The exploit works on all Microsoft Office versions, including the latest Office 2016 running on Windows 10. The earliest attack we have seen dates to late January.

The exploit connects to a remote server (controlled by the attacker), downloads a file that contains HTML application content, and executes it as an .hta file. Because .hta is executable, the attacker gains full code execution on the victim’s machine. Thus, this is a logical bug, and gives the attackers the power to bypass any memory-based mitigations developed by Microsoft. The following is a part of the communications we captured:

The .hta content is disguised as a normal RTF file to evade security products, but we can find the malicious Visual Basic scripts in a later part of the file:

 

 

 

 

 

 

The successful exploit closes the bait Word document, and pops up a fake one to show the victim. In the background, the malware has already been stealthily installed on the victim’s system.

The root cause of the zero-day vulnerability is related to the Windows Object Linking and Embedding (OLE), an important feature of Office. (Check our Black Hat USA 2015 presentation, in which we examine the attack surface of this feature.)

We strongly suggest Office users take the following actions to protect or mitigate against this zero-day attack before Microsoft issues an official patch. We notified the Microsoft Security Response Center as soon as we found the suspicious samples, and we will continue to work with them to protect Office users.

  •  Do not open any Office files obtained from untrusted locations.
  •  According to our tests, this active attack cannot bypass the Office Protected View, so we suggest everyone ensure that Office Protected View is enabled.

We will continue to update our findings on this ongoing investigation.

 

Special thanks to Bing Sun, Chong Xu, Christiaan Beek, and Abhishek Karnik (and his team) for their help with this investigation.

The post Critical Office Zero-Day Attacks Detected in the Wild appeared first on McAfee Blogs.

]]>
Patch Now: Simple Office ‘Protected View’ Bypass Could Have Big Impact https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/patch-now-simple-office-protected-view-bypass-could-have-big-impact/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/patch-now-simple-office-protected-view-bypass-could-have-big-impact/#respond Tue, 12 Jul 2016 19:08:52 +0000 https://blogs.mcafee.com/?p=51163 Protected View is a security feature of Microsoft Office. According to research from MWR Labs, Protected View mode is a strong application-level sandbox. In a real-world attack scenario, Office documents from the Internet, such as downloaded documents from browsers (Chrome, Edge, Internet Explorer), or attachments received on emails clients (such as Outlook), are opened by default in […]

The post Patch Now: Simple Office ‘Protected View’ Bypass Could Have Big Impact appeared first on McAfee Blogs.

]]>
Protected View is a security feature of Microsoft Office. According to research from MWR Labs, Protected View mode is a strong application-level sandbox. In a real-world attack scenario, Office documents from the Internet, such as downloaded documents from browsers (Chrome, Edge, Internet Explorer), or attachments received on emails clients (such as Outlook), are opened by default in Protected View mode, which offers the first line of protection against various Office-based attacks.

Many exploits are delivered in Office file formats. For example, the Hacking Team was found to have embedded Flash zero-day exploits into Office documents for a long time. This trick was also used in the recent Flash zero-day attack (CVE-2016-4117). However, if we look closer at the attack scenario, this exploit-delivering method usually fails thanks to Protected View. When the “from the Internet” document is opened, Protected View blocks the running of the embedded exploit, and a warning tells the user telling it is safer to stay in Protected View. (We strongly recommend users not ignore the warning unless they really need to edit the file.) See the following screen:

 

We have been working with the Microsoft Security Response Center during the past several months to address an Office Protected View bypassing bug (CVE-2016-3279) we found. Today, now that Microsoft has finally released a patch, we will discuss the details to offer better detection and defense for the community.

The attack is quite simple and the exploit can be packed as a .xla file type, an Excel add-in. We found that when a .xla file from the Internet is opened, Protected View does not activate. In other words, Excel uses its normal mode to open the file (probably because Excel considers that .xla files cannot cause harm). Unfortunately, however, the .xla format can contain many types of potentially malicious contents, typically ActiveX or OLE objects, just as other well-known formats such as .docx or .xls.

The following screen shows what happens when the user opens a Flash-embedded .xla file downloaded from the Internet. The “Zone.Identifier” Alternate Data Stream is set (marking the file as from the Internet), but the Flash binary is still loaded into the Excel process, which suggests the Protected View sandbox is not activated. (This version of Excel is running at the Medium integrity level.)

20160712 Protected_View_Bypass

 

Thus an an attacker can bypass the first line of protection just by saving an Office exploit as an .xla file.

For your defense, we highly recommend that every Office user—whether at work or at home—install the official patch as soon as possible. Our NIPS signature, “0x451bce00—Microsoft Office XLA File Handling Remote Code Execution (CVE-2016-3279),” can detect such an attack. Users who download or receive an .xla file from untrusted sources should be extremely careful before opening the file.

Thanks to my colleague Bing Sun for his help with this post.

 

The post Patch Now: Simple Office ‘Protected View’ Bypass Could Have Big Impact appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/patch-now-simple-office-protected-view-bypass-could-have-big-impact/feed/ 0
Threat Actors Employ COM Technology in Shellcode to Evade Detection https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/threat-actors-employ-com-technology-shellcode-evade-detection/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/threat-actors-employ-com-technology-shellcode-evade-detection/#respond Mon, 06 Jun 2016 22:34:47 +0000 https://blogs.mcafee.com/?p=50230 COM (Component Object Model) is a technology in Microsoft Windows that enables software components to communicate with each other; it is one of the fundamental architectures in Windows. From the security point of view, several “features” built into COM have lead to many security vulnerabilities. These features include ActiveX (an Internet Explorer plug-in technology), the […]

The post Threat Actors Employ COM Technology in Shellcode to Evade Detection appeared first on McAfee Blogs.

]]>
COM (Component Object Model) is a technology in Microsoft Windows that enables software components to communicate with each other; it is one of the fundamental architectures in Windows. From the security point of view, several “features” built into COM have lead to many security vulnerabilities. These features include ActiveX (an Internet Explorer plug-in technology), the brokers on Internet Explorer Protected Mode and Enhanced Protected Mode, and OLE (Object Linking and Embedding), which we analyzed and presented at last year’s Black Hat USA conference.

For a local system, there are two types of COM objects. One we call in-process COM, for this type the server and the client run in the same process. The other is cross-process COM, for this type the server and the client run in different processes.

In this post we will focus on cross-process COM. The following is an illustration from the Microsoft Developer Network showing one process talking with another process via COM (called COM marshaling).

 

 

 

 

 

 

 

 

 

 

 

From the security defense perspective, we have seen COM-related tricks in malware samples that abuse COM technology to hide from detection and remain persistent. However, for exploits, as far as we know, there have been no reports.

At McAfee we have recently analyzed a number of interesting samples. The exploited vulnerabilities and the dropped malware are not new. However, from an exploit detection perspective, we now see shellcode employing COM technology to perform post-exploitation operations after successfully exploiting the vulnerability. Specifically, Windows Management Instrumentation (WMI) objects—which can be accessed through COM—are used to execute the dropped malware.

We have reverse-engineered the shellcode. The following pseudocode does the trick:

//Instantiate the COM object
CoCreateInstance(CLSID_WbemLocator,0, CLSCTX_INPROC_SERVER, IID_IWbemLocator, (LPVOID *) &pLoc);

//Connect the WMI namespace
pLoc->ConnectServer(_bstr_t(L”ROOT\\CIMV2″),NULL,NULL,0,NULL,0,0,&pSvc);

//Set the authentication information
CoSetProxyBlanket(
pSvc,
RPC_C_AUTHN_WINNT,
RPC_C_AUTHZ_NONE,
NULL,
RPC_C_AUTHN_LEVEL_CALL,
RPC_C_IMP_LEVEL_IMPERSONATE,
NULL,
EOAC_NONE
);

//Get the WMI class
pSvc->GetObject(L”Win32_Process”, 0, NULL, &pClass, NULL);

//Get the method on this classs
pClass->GetMethod(L”Create”, 0, &pInParamsDefinition, NULL);

//Create a new instance of the class
pInParamsDefinition->SpawnInstance(0, &pClassInstance);

//Put the parameter (the path of the dropped malware)
VARIANT varCommand;
varCommand.vt = VT_BSTR;
varCommand.bstrVal = _bstr_t(L”C:\\Users\\USER1\\AppData\\Local\\Temp\\..\\Mozilla\\ffupd.exe“);
pClassInstance->Put(L”CommandLine”, 0, &varCommand, 0);

//Finally, execute the dropped malware
hres = pSvc->ExecMethod(L”Win32_Process”, L”Create”, 0,NULL, pClassInstance, &pOutParams, NULL);

Why would the threat actors do this? We conclude the purpose is to evade behavior-based detection. Most behavior-based detection products today, regardless whether on a user’s system or in a sandbox, are able to catch a suspicious process launched directly by the “monitored” process (the monitored process is the vulnerable process such as a Word or Internet Explorer process). This can be done many ways, such as hooking some sensitive Windows APIs such as CreateProcess().

However, the preceding WMI (COM) object is not implemented in the same vulnerable process; instead, it is implemented in a separate process: C:\Windows\system32\wbem\wmiprvse.exe. When the attacker tries to instantiate the WMI object, a new process, wmiprvse.exe (called the COM server), will be launched from the system service process svchost.exe. Later, wmiprvse.exe will be used to execute the dropped malware (ffupd.exe).

The following illustrates the process.

 

 

 

 

 

 

 

 

 

The point is that the main process that runs the dropped malware is not the vulnerable process (winword.exe, in this example), but the new, legitimate process wmiprvse.exe, which does not have a direct relationship with the vulnerable process. You won’t find anything wrong if you just monitor the vulnerable process or look at the “parent-child process relationship” on the system.

Is this a new attacking technique? COM technology is not new; in fact, it is a “common technology” on Windows. One Black Hat paper (page 15) dates the specific attacking technique to 2011. However, the samples show us that the bad guys are now implementing this technique in real-world attacking operations. Their goal, of course, is to bypass various behavior-based detections on endpoints or in sandboxing systems.

Although the WMI object in this example is not new, we must point out that this WMI object is only one of many potential “cross-process” COM objects in Windows that can be abused. The exploited vulnerabilities in the samples we analyzed are not new, but it is easy for attackers to copy such techniques when exploiting other new or zero-day vulnerabilities. Overall, we need a specific detection to defend against this style of attack.

We hope this post will help our fellow security defenders to understand the attacking technique, recognize the challenge, and take action to prepare for it. The MD5 hash of the analyzed sample is 72A7B4369E820DEB9D526C1F0E6294FB.

Thanks to my colleagues Bing Sun and Stanley Zhu for their help with the research and the post.

The post Threat Actors Employ COM Technology in Shellcode to Evade Detection appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/threat-actors-employ-com-technology-shellcode-evade-detection/feed/ 0
Threat Actors Use Encrypted Office Binary Format to Evade Detection https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/threat-actors-use-encrypted-office-binary-format-evade-detection/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/threat-actors-use-encrypted-office-binary-format-evade-detection/#comments Tue, 07 Jul 2015 23:24:32 +0000 https://blogs.mcafee.com/?p=44251 This blog post was written in conjunction with Xiaoning Li. Microsoft Office documents play an important role in our work and personal lives. In the last couple years, unfortunately, we have seen a number of exploits, especially some critical zero-day attacks, delivered as Office documents. Here are a couple of standouts: CVE-2014-4114/6352, the “Sandworm” zero-day […]

The post Threat Actors Use Encrypted Office Binary Format to Evade Detection appeared first on McAfee Blogs.

]]>
This blog post was written in conjunction with Xiaoning Li.

Microsoft Office documents play an important role in our work and personal lives. In the last couple years, unfortunately, we have seen a number of exploits, especially some critical zero-day attacks, delivered as Office documents. Here are a couple of standouts:

  • CVE-2014-4114/6352, the “Sandworm” zero-day attack, reported in October 2014. McAfee Labs has provided in-depth root-cause analysis about this vulnerability as well as Microsoft’s initial failed patch.
  • CVE-2014-1761, a highly crafted zero-day attack spotted by Google in March 2014. Read here to understand why we conclude it’s highly crafted.
  • CVE-2013-3906, a zero-day vulnerability in Microsoft Graphics Component but delivered as an Office document. This zero-day attack was detected and reported by McAfee Labs in October 2013.
  • CVE-2012-0158/1856, two vulnerabilities in MSCOMCTL.OCX that are quite old, but they have been attackers’ favorites for years. Exploits are still spotted in the wild.

At McAfee Labs we are performing some leading research on Office security to drive innovations on exploit detection and protection. Recently, we have seen an increase in attacks leveraging the Sandworm vulnerability. Most important, the threat actors have introduced some interesting detection-evasion techniques, which we want to share with the security community.

PPSX vs. PPS

We have seen quite a number of Sandworm exploits (CVE-2014-4114) masquerading as .pps (PowerPoint Show) format rather than the current .ppsx format. The original Sandworm samples were packed as .ppsx, which uses the Office Open XML Format, a replacement of the older Office Binary Format. The binary format is still supported by Office for compatibility. Because the Open XML Format is transparent and open, it is easy to parse and understand for third-party applications including security products. Thus most security vendors have no problem detecting CVE-2014-4114 exploits that use the Open XML Format.

It’s a different story with .pps documents using the Office Binary Format. Even though Microsoft has released the specification, the format is not easy to understand. As a result, security products have difficulty detecting exploits that use this format. Of course, the bad guys have realized this, and they have started to deliver CVE-2014-4114 exploits in .pps rather than .ppsx format. One example is the spear phishing campaign reported few days ago by ThreatGeek. (We are tracking the campaign as well.) In this campaign, the exploits are repacked as .pps, which successfully avoids most AV detections.

Plain PPS vs. encrypted PPS

Fortunately, even though the binary format is hard to parse, it is still a “plain” format, meaning that if there is a good signature with generic patterns, the malicious bytes won’t be able to hide. But the exploit writers are not content with only moving to .pps. At McAfee Labs we see that they are now encrypting their exploits to make them even harder to detect.

Let’s take a look at what a normal .pps and an encrypted .pps look like by examining a sample we spotted in plain .pps. As we can see in the following image, the key bytes (the string “package”) can still be seen, which suggests the bytes are not encrypted.

 

And here is an encrypted .pps:

 

In the encrypted version we can’t find any malicious bytes at all.

Let’s try open and edit the sample with PowerPoint. To avoid playing it, we first rename it to .ppt from .pps.

The exploit authors have cleverly leveraged a feature in Office that allows an author to protect documents from viewing or editing. In this example, the author has encrypted the document with a password, allowing anyone to view but not edit. (When we open a .pps (PowerPoint Show) document, we are actually “viewing” it; that’s why the exploit works without a password prompt.) On the other hand, because the document can’t be edited, it prevents security products from analyzing the content, and also prevents researchers from statically analyzing the malicious sample.

We have tracked threat campaigns with encrypted Office exploits for some time. Here is one older than the spear phishing example. This campaign, with MD5: 2E63ED1CDCEBAC556F78F16E8E872786, arrived with the filename “Attachment Information(English Version).pps” and was first seen on VirusTotal on May 12. As of July 2, there was still no detection on VirusTotal due to the encryption.

Analyzing the malware in the encrypted exploit

In exploiting CVE-2014-4114, this malicious .pps sample dropped one malware into the temp directory and ran it as update.dat (9421D13AA5F3ECE0C790A7184B9B10B3).

The file’s main function:

The main function performed several tasks:

  • Decrypted the encrypted .exe file data into $AppData\Roaming\SearchCache.dll (97FE2A5733D33BDE1F93678B73B062AC)
  • Ran a new rundll32.exe process to call the exported API_flushfile@16 in SearchCache.dll (C:\Windows\system32\rundll32.exe $AppData\Roaming \SearchCache.dll”,_flushfile@16 $AppData\Local\Temp\update.dat)

In the exported API _flushfile@16, the code at first slept to avoid detection, and then deleted the original update.dat and created a new thread to perform other tasks.

The new thread connected to a control server, collected local system information, and sent the data to the control server. This thread also downloaded irmon32.dll and registered a service for it for future malicious actions. The detailed steps:

 

Threat intelligence

To help our fellow defenders with their analyses, here are some of the sample hashes (MD5) related to these campaigns:

0BC232549C86D9FA7E4500A801676F02
12F8354C83E9C9C7A785F53883C71CFC
142B50AEAEBE7ABEDA2EC3A05F6559B6
1E479D02DDE72B7BB9DD1335C587986B
209470139EE8760CA1921A234D967E40
2E63ED1CDCEBAC556F78F16E8E872786
3EA3435FC57CECB7AD53AEE0BBE3A31D
4AF0B2073B290E15961146E9714BD811
6360DDC19A858B0CE3DB7D1E07BC742F
710A39FA656981A81577D2EE31B46B18
719A7315449A3AE664291A7E0C124F0A
822F13D2A8AE52836BB94D537A1E3E3C
864EC7ED23523B0DC9C4B46DE3B852D1
8675174A45AABC8407C858D726ABB049
8A6A6ADCDE64420F0D53231AD7A6A927
96432AC95A743AC329DF0D51C724786F
AD2A5B0AF9B3188F42A5A29326CDDB0E
B4F788E76E60F91CF35880F5833C9D27
B86297F429FFBC8AFD67BDDD44CBB867
D57DF8C7BA9F2119660EA1BCE01D8F4A
E5BEF07992F88BCF91173B68AC3EA6BC
E7399EDE401DA1BACB3D2059A45F0763

Conclusion and response

These evasion tricks produce a real challenge for defenders. Although security is always a seesaw battle, we need to stay ahead of the bad guys. This case also highlights the fact that in today’s computing environment, no single security product (whether network-, endpoint-, or sandbox-based) can stop all threats. For this type of threat, our sandbox-based Advanced Threat Defense and Host Intrusion Prevention are ideal choices. (And if you haven’t patched the Sandworm vulnerability, you’d better get to it.) McAfee AntiVirus provides detections for the two campaigns we discussed, including both the “plain” and “encrypted” exploits.

Furthermore

Speaking of Office security, we will make a presentation at this year’s Black Hat USA 2015 security conference in Las Vegas in August. We will present some of our original, cutting-edge research on the important OLE feature in Office. We want to help the community understand the risk of Office OLE and better protect users from threat actors.

 

Special thanks to Bing Sun and Stanley Zhu of  McAfee for their valuable input.

The post Threat Actors Use Encrypted Office Binary Format to Evade Detection appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/threat-actors-use-encrypted-office-binary-format-evade-detection/feed/ 1
An Advance You Won’t Want to Miss: McAfee Adds Flash Exploit Detection to NSP 8.2 https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/advance-wont-want-miss-mcafee-adds-flash-exploit-detection-nsp-8-2/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/advance-wont-want-miss-mcafee-adds-flash-exploit-detection-nsp-8-2/#respond Sun, 21 Dec 2014 22:43:22 +0000 http://blogs.mcafee.com/?p=40235 Adobe Flash vulnerabilities and exploits have worried users and security professionals for many years. The situation today remains serious. A quick search of the National Vulnerability Database shows 277 vulnerabilities reported in Flash Player since 2011. For Flash zero-day attacks (which means that there was no patch from Adobe when the vulnerability was exploited), researcher […]

The post An Advance You Won’t Want to Miss: McAfee Adds Flash Exploit Detection to NSP 8.2 appeared first on McAfee Blogs.

]]>
Adobe Flash vulnerabilities and exploits have worried users and security professionals for many years. The situation today remains serious. A quick search of the National Vulnerability Database shows 277 vulnerabilities reported in Flash Player since 2011. For Flash zero-day attacks (which means that there was no patch from Adobe when the vulnerability was exploited), researcher Chris Evans provided a useful spreadsheet tracking all of them in recent years (except for the recent CVE-2014-9163). Since 2011, 21 Flash zero-day attacks have been disclosed, and that doesn’t count those exploited in the wild soon after Adobe’s patch. On average, there are about six Flash vulnerabilities per month, and every two to three months we have seen a Flash zero-day attack. Flash threats are not only Flash exploits; because Flash works as a plug-in to browsers, vulnerabilities in browsers can sometimes be exploited with the aid of Flash. This usually happens with Microsoft Internet Explorer. Previously, we have seen IE zero-day attacks involving Flash, such as the IE CVE-2014-1776 zero-day attack in April 2014, and the IE CVE-2013-3163 zero-day attack in July 2013.

At McAfee Labs we have performed leading research on Flash for quite a long time. During the last couple of years, we have analyzed every Flash-related threat. We were the first security vendor to successfully identify the modern exploitation technology on Flash Player, which we named Flash Vector Spraying, in February 2013. This advanced technology soon became the leading exploitation method used in many Flash and IE zero-day attacks to defeat address space layout randomization and data execution prevention on Windows 7 and later operation systems. You may have read about the technology talking about zero-day or watering-hole attacks.

Flash is a complex application. From a research point of view, the Flash Player binary Flash32_xx_xx_xx.ocx is about 16MB without any symbols, which makes it really hard for researchers to reverse-engineer the application. Thus it’s not easy to analyze and debug Flash exploits. The core script engine on Flash–the ActionScript language–is extremely flexible, but this flexibility makes it almost impossible to deliver meaningful signatures against malicious Flash contents.

What about sandbox-based detection, you ask? Yes, sandboxing is cool and has attracted a lot of attention in the industry. However, once you understand how the bad guys make Flash exploits, you won’t think sandboxing is such a good idea. First, a Flash exploit–especially for targeted or advanced attacks–may work on only one or some versions of Flash Player that are vulnerable. Flash Player has frequent updates; there are many Flash Player versions. Thus it would be really hard for a sandboxing solution to set up the vulnerable version for any potential Flash exploit. A sandboxing solution that can’t trigger the exploit code is ineffective. Second, due to their nature, sandboxing systems are offline solutions, and cannot prevent malicious Flash exploits by blocking these attacks inline, in real-time. Third, Flash content is so common on the Internet that running all the Flash content in a sandbox would likely introduce performance problems and thus harm the usability of a sandbox solution as well as the user experience.

Considering these challenges, we find the best way to fight Flash exploits is with the traditional “static” approach, aided by some innovative ideas based on our in-depth understanding of how Flash exploits work, as well as the nature of Flash compilers. From a product perspective, the static approach is useful because it’s the fastest solution and users expect the highest performance. In addition, it’s quite easy to integrate our detection engine with many of our security products. Our approach is to detect malicious exploitation operations not based on signatures or patterns, and our engine effectively detects and stops zero-day (or any unknown) attacks related to Flash content. We tested our in-the-Labs engine with all samples involved in all previous Flash and IE zero-day attacks when they came out, and none of them could evade our detection engine. Here is a short list of the zero-day attacks and their typical in-the-wild Flash samples, and we detected all of them at the time they appeared.

(The recent CVE-2014-9163 is not listed because there was no public sample as of this writing.)

Concerned about our customers’ experiences, we have performed quite a lot of large-scale tests against real-world Flash samples from both our internal and external VirusTotal sample databases. Based on the results, we are confident that our solution will balance the effectiveness, performance, and false-positive rate very well.

During the past 18 months, our research and engineering team has been busy implementing the engine and integrating it into our Network Security Platform (NSP). With the release of NSP Version 8.2, we are excited to announce the availability of this feature. Our NSP customers may refer to this page for information regarding this release.

We are excited about this advanced and innovative feature for combating Flash exploits, and we hope our customers will share that excitement, too. We strongly suggest our NSP customers try this feature and give us feedback regarding your experience. Because the feature can recognize zero-day attacks, we also encourage our customers to share the intelligence when they detect unknown samples.

 

Thanks to Chang Liu and Winny Thomas, who made special efforts for this product feature.

The post An Advance You Won’t Want to Miss: McAfee Adds Flash Exploit Detection to NSP 8.2 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/advance-wont-want-miss-mcafee-adds-flash-exploit-detection-nsp-8-2/feed/ 0
Bypassing Microsoft’s Patch for the Sandworm Zero Day: Even ‘Editing’ Can Cause Harm https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/bypassing-microsofts-patch-for-the-sandworm-zero-day-even-editing-can-cause-harm/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/bypassing-microsofts-patch-for-the-sandworm-zero-day-even-editing-can-cause-harm/#comments Thu, 13 Nov 2014 01:31:27 +0000 http://blogs.mcafee.com/?p=39189 This is the second part of our analysis of the Sandworm OLE zero-day vulnerability and the MS14-060 patch bypass. Check out the first part here. Microsoft’s Patch From our previous analysis we’ve learned that the core of this threat is its ability to effectively right-click a file. Now, let’s see what Microsoft did in its patch […]

The post Bypassing Microsoft’s Patch for the Sandworm Zero Day: Even ‘Editing’ Can Cause Harm appeared first on McAfee Blogs.

]]>
This is the second part of our analysis of the Sandworm OLE zero-day vulnerability and the MS14-060 patch bypass. Check out the first part here.

Microsoft’s Patch

From our previous analysis we’ve learned that the core of this threat is its ability to effectively right-click a file. Now, let’s see what Microsoft did in its patch MS14-060.

With a little bit of help from patch diffing, we can easily spot that the function MarkFileUnsafe() is called right after the malicious file is dropped into the temp folder. The following image shows the call:

MarkFileUnsafe() is called right after dropping the file into the temp folder.

There are two ways that an attacker can drop a file into the temp folder. Researchers have seen real in-the-wild samples of both. The first way is to copy from a UNC location, such as in this sample (SHA1: 22fbbcfa5646497e57ee238a180d1b367789984a). The second is to drop it directly from the embedded OLE stream, as in this sample (SHA1: cb2aadbfcfac3c5802ff23ae6971791549b120b8). Our research also shows that the two ways are represented by several code flows. Thus, there have to be (and we have seen them in the updated packager.dll) several places calling the MarkFileUnsafe() function.

Now, let’s take a look at what MarkFileUnsafe() does. The function calls the IZoneIdentifier APIs to mark the dropped file as coming from the Internet zone (“URLZONE_INTERNET”). At a low level, the function leverages a feature in NTFS. (If you’d like more details on how this works, refer to these links 1, 2.) We call this feature Internet marked.

After a file is Internet marked, users will receive a warning dialog whenever they try to “execute” the file. This blocks automatic code execution. For example, installing an Internet-marked .inf file will bring up the following dialog, which is exactly what we saw when testing the original zero-day sample with Microsoft’s patch MS14-060:

Warning dialog when a user tries to “execute” the Internet-marked .inf file.

Problem with the patch

An “execute” action will be blocked by the Internet-marked feature because the Windows Shell routines will check the Security Zone when performing an “execute” action. However, a “non-execute” action will go through directly. This is the same reason that we can’t directly run an executable downloaded through Internet Explorer, but we can open a downloaded Word document with Office.

Let’s consider the potential problems:

  • On Windows, there are many file types (filename extensions). They are registered by various applications on the system. Taking the same action with right-click pop-up menus basically allows you or a command to run various applications or perform various actions on the system.
  • The registered actions also vary. They can include opening the file, often with the keyword “edit,” as well as many other actions. For example, you can unzip a .zip file when WinRar is installed (see the following image), regardless whether the .zip is Internet marked. It all depends on which extension you choose and which applications you have installed.

The “right-click” menu for a .zip file.

You can see why we were already worried at this stage: Allowing unexpected applications to run is not acceptable from a security point of view because no one knows whether launching an “unknown” application will cause a problem.

Exploiting the problem: a real-world example

The proof of concept we sent to Microsoft leverages Python on Windows. When we right-click on a .py file, we get this menu:

The “right-click” menu for .py file

Thus we can call the Python development tool IDLE to open a .py file with the iVerb set to 3, as in the original sample. (See part one of this post for a discussion of iVerb and other details.) Because this is just an “edit” action, even with an Internet-marked file, the command will run without any warning. Now, let’s see what happens when IDLE runs. We use Process Monitor to record the following events:

It seems that IDLE tried to load a Python module named tabnanny in the same directory as the .py file. This interested us. So we created tabnanny.py and test.py in the same directory. When opening test.py with IDLE (through right-clicking), the code inside tabnanny.py was automatically executed!

As we have mentioned, the first security issue in packager.dll is allowing it to drop arbitrary files into the temp folder. By embedding more Packager objects on a PowerPoint slide, we can drop many files into the temp folder when a PowerPoint Show slide is viewed. Thus we can drop the first file with the special filename tabnanny.py. When the second .py file, with any filename, is opened by IDLE, the Python code in tabnanny.py will immediately be executed.

The environment is Windows 7 with Office 2010 and Python 2.7.8 installed, all are updated after the October patch (with MS14-060 installed) but before the November 11 patch.

Even though we ran the exploit in an environment with third-party software installed, considering the large number of file types on default Windows as well as various “non-execute” actions for these file types, there is a good chance that attackers can develop exploits for the default setup.

A look at the partial bypass

The preceding exploitation method was the one we showed to Microsoft. As we have mentioned at the beginning of this post, there is an in-the-wild sample that is claimed to also bypass the patch. We’ve obtained that sample (SHA1: cb2aadbfcfac3c5802ff23ae6971791549b120b8). Let’s see how it works.

This sample drops an .exe file into the temp folder, and also selects the second item on the right-click menu (via cmd=3). What’s the second item for an .exe on Windows?

The right-click menu for a Windows .exe file.

Now, we see that the exploit performs “Run as administrator.” This won’t trigger the Internet-mark warning dialog because it triggers another dialog: a user account control dialog will show up when the UAC is not disabled for a standard user account.

Concerns remain

Microsoft has finally resolved this serious vulnerability with MS14-064. Users should apply the patch as soon as possible. As we have pointed out in previous sections, the vulnerability actually consists of two security issues: the “dropping arbitrary file into temp folder” issue and the “code execution through DoVerb()” issue. However, according to our test against the new patch, only the latter was fixed; the “dropping arbitrary file into temp folder” issue remains. We recommend that Microsoft resolve this security issue as well.

Users who have concerns regarding the remaining issue may consider the workaround and mitigations provided in our July post.

Conclusion

In this post we provided in-depth research around the Sandworm vulnerability CVE-2014-4114, which includes a thorough understanding of the root cause, the exploitation, the patching methodology, as well as the patch bypassing that leads to CVE-2014-6352. We demonstrated a real-world bypass that leverages an issue in Python IDLE.

The key problem of the patch is that it blocks only a small number of actions of the right-click menu involved with direct execution. However, other actions, such as the most popular–“editing” with a registered application–are still allowed. This interoperability opens a door for attackers for future exploitation.

This interesting case study highlights that interoperability between applications raises complexity. Security is no longer about a single application. Understanding the behaviors of various applications and how they work together is vital for effective security.

Thanks to my colleagues Bing Sun, Chong Xu, Stanley Zhu (all of McAfee Labs), and Xiaoning Li (McAfee) for their help with this analysis.

The post Bypassing Microsoft’s Patch for the Sandworm Zero Day: Even ‘Editing’ Can Cause Harm appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/bypassing-microsofts-patch-for-the-sandworm-zero-day-even-editing-can-cause-harm/feed/ 7
Bypassing Microsoft’s Patch for the Sandworm Zero Day: a Detailed Look at the Root Cause https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/bypassing-microsofts-patch-sandworm-zero-day-root-cause/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/bypassing-microsofts-patch-sandworm-zero-day-root-cause/#respond Tue, 11 Nov 2014 20:48:13 +0000 http://blogs.mcafee.com/?p=39015 On October 21, we warned the public that a new exploitation method could bypass Microsoft’s official patch (MS14-060, KB3000869) for the infamous Sandworm zero-day vulnerability. As Microsoft has finally fixed the problem today via Security Bulletin MS14-064, it’s time to uncover our findings and address some confusion. This is the first of two posts on […]

The post Bypassing Microsoft’s Patch for the Sandworm Zero Day: a Detailed Look at the Root Cause appeared first on McAfee Blogs.

]]>
On October 21, we warned the public that a new exploitation method could bypass Microsoft’s official patch (MS14-060, KB3000869) for the infamous Sandworm zero-day vulnerability. As Microsoft has finally fixed the problem today via Security Bulletin MS14-064, it’s time to uncover our findings and address some confusion. This is the first of two posts on this issue. (Read part 2 here.) McAfee has already delivered various protections against this threat to our customers.

Sandworm background

This zero-day attack was disclosed at almost the same time that the patch was available on the last “Patch Tuesday” (October 14). We found that this is a very serious zero-day attack not only because the attack targeted many sensitive organizations (such as NATO), but also from the technical properties of the vulnerability and exploitation.

  • This vulnerability is a logic fault. It’s not related to memory corruption (such as a heap-based overflow or use-after-free) so proven-effective exploitation mitigations such as ASLR and DEP on Windows 7 or later will fail to block the exploit. Nor can Microsoft’s enhanced security tool Enhanced Mitigation Experience Toolkit (EMET) block the attack by default.
  • Though the in-the-wild samples are organized as PowerPoint Show (.ppsx) files, this is due to a vulnerability in the Windows Packager COM object (packager.dll). Considering that COM objects are OS-wide function providers, any applications installed on the system can invoke them, which means that other formats can be attacks paths as well. This indicates that all Windows users, not only Office users, are at risk.

The attack has been going on for quite a long time. For example, an exploit generator found on VirusTotal suggests that the vulnerability was discovered in June 2013.

Microsoft’s patch and two bypasses

On October 17, three days after its release, we found that Microsoft’s patch could be bypassed with some tricks. We reported our findings to Microsoft on the same day, which lead to an emergency Security Advisory 3010060, released October 21, with a temporary “Fix It.”

We created a proof of concept (PoC) demonstrating the bypass. We later learned that some other parties, including the Google Security Team, have detected in-the-wild samples that are said to bypass the patch. We analyzed some samples in the wild, and found that they will trigger a user account control (UAC) warning when one logs in with a standard nonadministrator account. However, users on an administrator account or who have disabled the UAC will not see the warning, and the malicious code will execute automatically.

Our PoC takes another path and does not trigger the UAC at all. Thus our PoC is a full bypass while the in-the-wild samples are a partial bypass.

At the root

The vulnerability exists in the Packager object. In fact, there are two issues rather than one.

The first issue allows an attacker to drop an arbitrary file into the temp folder. (We warned the public about this security issue in a July post. Anyone who followed our advice at that time, preventing Office from invoking the Packager object, is immune to the Sandworm attack.)

The second issue is the core of the matter. While the former allows only the writing of a file into the temp folder, the latter allows an attacker to “execute” the file from the temp folder. Let’s take a closer look at how it works.

Looking at the slide definition XML file inside the .ppsx sample, we find something interesting at the following lines:

The “verb” definition in slide1.xml.

The Packager is an OLE object that supports embedding one file into another container application. As described on this MSDN page, OLE objects that provide embedding functions must expose the interface IOleObject. For the preceding XML definition, this calls the DoVerb() method of this IOleObject. Another MSDN page provides the prototype of this method:

Prototype of the IOleObject::DoVerb() function.

And the following shows the location of the IOleObject and the DoVerb() function in the packager.dll:

The IOleObject interface and the DoVerb() function in packager.dll.

The string “cmd=3” in the slide1.xml suggests that the value of the first parameter (iVerb) is 3. Depending on different values of iVerb, we see a switch to different code in IOleObject::DoVerb(). Following we have the REed code (source code generated through reverse engineering) when iVerb equals 3.

The REed code for handling iVerb=3 in the IOleObject::DoVerb() function.

With further research and testing, we realized that this code performs the same action as clicking the second item on the following menu after right-clicking the filename, as shown here. (The print in red is our addition.)

The “right-click” menu for .inf file.

Reading the whole code of IOleObject::DoVerb(), we see that depending on different values of iVerb, the code will switch to different code paths. We split them into two situations.

  • For iVerb values greater than or equal to 3, the code will perform the same action as clicking on the pop-up menu. As we see in the REed code, it subtracts the fixed value 2 from the iVerb value 3, with the result 1, which represents the second item on the right-click menu. We can also invoke any command below “Install” on the menu by supplying a larger iVerb value. For example, if we want to click the third item on the preceding menu, we can set iVerb=4 (“cmd=4”) in the slide definition file.
  • For an iVerb value less than 3, the program will follow other code that we have not shown. These actions, such as performing the default action (iVerb=2) or renaming the display name of the Packager object (iVerb=1), are handled well from a security point of view.

We are focusing on the first situation: When the iVerb value is greater than or equal to 3, it will effectively click “Install” or a lower choice from the pop-up menu for the specific file.

For a .inf file, the right-click menu will appear exactly as in our image for a default Windows setup. Thus, in this example “InfDefaultInstall.exe” will execute and various bad thing will happen.

In this post, we have introduced the case and explained the essence of the vulnerability. In a second part, we discuss the MS14-060 patch, how to bypass it, and more.

The post Bypassing Microsoft’s Patch for the Sandworm Zero Day: a Detailed Look at the Root Cause appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/bypassing-microsofts-patch-sandworm-zero-day-root-cause/feed/ 0
New Exploit of Sandworm Zero-Day Could Bypass Official Patch https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/new-exploit-sandworm-zero-day-bypass-official-patch/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/new-exploit-sandworm-zero-day-bypass-official-patch/#comments Tue, 21 Oct 2014 22:06:30 +0000 http://blogs.mcafee.com/?p=38662 Update of October 25: Some comments posted after we published this report suggest that our proof-of-concept exploit will trigger the UAC (User Account Control) on Windows. We did not observe this during our analysis.   During the last few days researchers at McAfee Labs have been actively investigating Sandworm, the Windows packager zero-day attack (CVE-2014-4114). […]

The post New Exploit of Sandworm Zero-Day Could Bypass Official Patch appeared first on McAfee Blogs.

]]>
Update of October 25: Some comments posted after we published this report suggest that our proof-of-concept exploit will trigger the UAC (User Account Control) on Windows. We did not observe this during our analysis.

 

During the last few days researchers at McAfee Labs have been actively investigating Sandworm, the Windows packager zero-day attack (CVE-2014-4114). McAfee has already released various updates through our products to protect our customers, and we continue to analyze this attack.

During our investigation, we found that the Microsoft’s official patch (MS14-060, KB3000869) is not robust enough. In other words, attackers might still be able to exploit the vulnerability even after the patch is applied. Users who have installed the official patch are still at risk.

This finding has significant impact because attacks leveraging the vulnerability are still very active. We reported our findings to the Microsoft Security Response Center immediately after we successfully developed a proof of concept on October 17. Since then we have actively worked with Microsoft to resolve this issue.

Today, Microsoft has released Security Advisory 3010060 as well as the “Fix It” temporary patch. A new ID, CVE-2014-6352, has been assigned to track this issue. To protect hundreds of millions of Windows users, we are not sharing any of the details until a permanent patch from Microsoft is available to the public.

While we will continue to monitor potential new attacks in the wild, users who have concerns about their security may consider the following actions:

  • Apply the Microsoft “Fix It” or workarounds shared in Security Advisory 3010060.
  • Apply the first or the second workarounds shared in Security Bulletin MS14-060. These are “Disable the WebClient service” and “Block TCP ports 139 and 445.” We believe these two workarounds will be effective to block the new exploitation method, though the third in the bulletin (“Block the launching of executables via Setup information files”) may not be effective.

We thank James Forshaw of Google Project Zero, who helped us with this finding. Thanks as well to Bing Sun, Chong Xu, and Stanley Zhu of McAfee Labs for their help with this research and investigation.

The post New Exploit of Sandworm Zero-Day Could Bypass Official Patch appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/new-exploit-sandworm-zero-day-bypass-official-patch/feed/ 4
Dropping Files Into Temp Folder Raises Security Concerns https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/dropping-files-temp-folder-raises-security-concerns/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/dropping-files-temp-folder-raises-security-concerns/#respond Mon, 28 Jul 2014 21:56:13 +0000 http://blogs.mcafee.com/?p=36893 Recently, the McAfee Advanced Exploit Detection System (AEDS) has delivered some interesting RTF files to our table. These RTFs have executables “attached” to the documents. Usually, some words in the documents try to convince users to click and run the attachments. The following figure shows the point at which a user clicks on the attachment. […]

The post Dropping Files Into Temp Folder Raises Security Concerns appeared first on McAfee Blogs.

]]>
Recently, the McAfee Advanced Exploit Detection System (AEDS) has delivered some interesting RTF files to our table. These RTFs have executables “attached” to the documents. Usually, some words in the documents try to convince users to click and run the attachments. The following figure shows the point at which a user clicks on the attachment.
malicious_rtf_click_to_open

This warning appears when a user tries to execute the attached malware.

Because there are strong warnings, we don’t see these threats as a problem. However, we strongly suggest users not run any of the files attached to these documents. McAfee antivirus products already provide detection against this type of attack.

Our story doesn’t end here. Just as we used AEDS to discover a potential security issue in PDFs, we have identified a suspicious (or maybe “interesting”) behavior while opening such an RTF: The attached file was dropped into the temporary folder of the current user (typically, in C:\Users\<username>\AppData\Local\Temp). The following figure shows the file reader.exe after it is dropped in the temporary folder for the particular RTF sample.
showing_temp_file1

The file Reader.exe is dropped into the current user’s temporary folder when the RTF is opened.

We observed this behavior on Windows 7 and 8 with or without Office installed. (Using WordPad to open the RTF is enough to trigger the behavior.) We didn’t see the behavior on Windows XP.

The file is dropped through the “Package” ActiveX Control. The format looks like this:
rtf_key_structure

The “Package” ActiveX Control is invoked by the RTF.

The registry information for the “Package” ActiveX Control:

CLSID: {F20DA720-C02F-11CE-927B-0800095AE340}
ProgID: Package
InProcServer32: %SystemRoot%\system32\packager.dll

During our tests, we observed the following:

  • The filename as well as the content of the dropped file are controlled by the RTF
  • Opening the RTF document is enough to trigger this behavior; no additional user interaction is required
  • If the filename already exists in the temporary folder, the malware will drop as <filename> (2).<ext>. The current file will not be overwritten.
  • When the document is closed, the dropped file is removed

This behavior allows anyone to drop an arbitrary file with an arbitrary filename into the temporary folder when the RTF document is opened. This certainly raises security concerns. The best practice for temporary files is to create unique filenames, such as using random filenames or creating an application-specific directory under the temporary folder. For example, Adobe Reader 11 uses the directory acrord32_sbx (C:\Users\<username>\AppData\Local\Temp\acrord32_sbx) for its various temporary file operations.

How could an attacker abuse this behavior?
Because most applications and the operating system frequently use the temporary folder and we don’t know how each program uses each temporary file, answering the question is difficult. Here are some thoughts.

  • In some conditions, an application runs an executable from the temporary folder as long as the file exists. Certainly, opening the RTF could be dangerous in such conditions. This also applies to DLLs. In the real world, we expect that these conditions are infrequent. Instead, most applications will first create the executable or DLL (or overwrite it if the file is already there), and then run it.
  • DLL-preloading problems. Some applications may create an executable in the temporary folder and execute it. In this situation, when the .exe has DLL-preloading problems, it will search for that named DLL in the temporary folder. If a DLL with the same name is placed in the temporary folder, the DLL will be loaded right away.
  • Applications may rely on some specifically named nonexistent non-executable files for operations. When such a file is placed in the temporary folder, it may change the application’s behavior or program flow, bringing future security problems.

We call these situations vulnerable temp folder access. With the aid of the vulnerable temp folder access from other programs, an attacker could abuse this behavior to run arbitrary code on the victim’s system.

A typical attacking scenario would include the following steps:

  • The attacker sends an RTF file to the victim.
  • The victim opens it, and one or more specific files are dropped into the temp folder.
  • If another program is accessing the temp folder in one of the vulnerable ways we discussed, code execution may occur automatically at this point. The document could contain some social-engineering text to convince the victim to perform future apparently safe actions, such as running legal applications.
  • If the victim follows these instructions, successful exploitation may occur if the user action triggers one of the vulnerable accesses we discussed.

Therefore, to attack successfully, another program’s vulnerable access to the temp folder is a must. Sometimes the attack might require additional user interactions, sometimes not.

Are any attackers trying to exploit this behavior?
It’s hard to tell. A successful exploitation requires the attacker to learn, prior to the attack, whether the target has a vulnerable temp folder access as well as the details. Thus from an analyst’s point of view, examining the RTF samples is usually not enough to understand the attacker’s intention. For example, an RTF dropping Reader.exe into the temp folder could be just a “click to run” trick, or it could be an exploitation attempt of this behavior if the attacker knows that the target is running some programs accessing the Reader.exe in the temp folder in a vulnerable way.

We have seen some in-the-wild malicious RTFs drop files with “interesting” names:

CEH.exe
du.sfx.exe
FINCEN~2.EXE
inicio.bat
inv_875867001426_74653003.cpl
pastelyearendguidedm (3).exe
QUICKSHIPPINGDUEINVOICE.exe
Reader.exe
test.vir

Advanced persistent threats usually consist of learning the targets well before the attack occurs. We recommend to organizations with concerns about this issue to specially focus on sophisticated targeted attacks.

Keeping safe
If users always open RTFs with Microsoft Word, there is a workaround to disable the “Package” ActiveX Control through the Office kill bit. We have found that the problem is solved in Office by setting the following registry key/value.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Common\COM Compatibility\{F20DA720-C02F-11CE-927B-0800095AE340}]
"Compatibility Flags"=dword:00000400

However, the preceding workaround won’t work for users who employ WordPad to open RTF documents. As we have said many times for document-based exploits, the best practice is to not open documents from untrusted sources. Close the document as soon as possible when you find it’s suspicious, and don’t follow any actions suggested in the document. These steps can reduce the chance of success of a potential attack.

Our investigation of suspicious behavior when handling RTF documents in Windows and Office shows that exploitation is not only about memory corruption or a single application or system; it’s a far broader concept. The breadth of exploitation poses challenges to organizations and security companies. McAfee is committed to meeting those challenges.

Thanks to Bing Sun, Chong Xu, Jun Xie, and Xiaoning Li (of McAfee Labs) for their help with this research and investigation.

The post Dropping Files Into Temp Folder Raises Security Concerns appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/dropping-files-temp-folder-raises-security-concerns/feed/ 0
A Close Look at RTF Zero-Day Attack CVE-2014-1761 Shows Sophistication of Attackers https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/close-look-rtf-zero-day-attack-cve-2014-1761-shows-sophistication-attackers/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/close-look-rtf-zero-day-attack-cve-2014-1761-shows-sophistication-attackers/#respond Fri, 04 Apr 2014 06:32:43 +0000 http://blogs.mcafee.com/?p=34464 A serious RTF zero-day attack has struck recently. McAfee detection solutions were provided a couple of days ago that allowed us to spot in-the-wild attacks. We detected this exploit on Wednesday. McAfee Labs researchers have been actively working on this threat. In this post, we will share our perspective on how the exploit works–specifically how […]

The post A Close Look at RTF Zero-Day Attack CVE-2014-1761 Shows Sophistication of Attackers appeared first on McAfee Blogs.

]]>
A serious RTF zero-day attack has struck recently. McAfee detection solutions were provided a couple of days ago that allowed us to spot in-the-wild attacks. We detected this exploit on Wednesday. McAfee Labs researchers have been actively working on this threat. In this post, we will share our perspective on how the exploit works–specifically how an extended instruction pointer (EIP) is controlled at a deep technical level.

From our analysis, we believe the root cause of the vulnerability is related to the RTF “overridetable” control word (also called a structure) or the inside structures. An “overridetable” structure may include the “listoverride,” “listoverridecount,” and “lfolevel” fields. The “listoverridecount” basically tells how many instances of “lfolevel” the structure may contain. According to Microsoft’s official specification, the legal value should be 0, 1, or 9. However, in this exploit, the value is 25.

The in-the-wild exploit is a bit complex. However, we can simplify it into this one-line proof of concept:

During our tests, when the value of the “listoverridecount” is set to 25, starting from the 29th value the “lfolevel” structure is handled incorrectly by the Microsoft Word. Specifically, an object-confusion fault occurs, for example, class A is wrongly handled as class B. As every byte of the confusing object can be controlled by the attacker via various control words, the attacker can control the program flow (EIP) accurately.

The attacker controls the EIP to an address in MSCOMCTL.DLL. Because the DLL doesn’t have address space layout randomization (ASLR) enabled (for Office 2010 or earlier versions), the attacker can make the exploit work for Office on newer operating systems such as Windows 7. The first controlled EIP is a fixed address, 0x275A48E8. Let’s see what it looks like:

first_address1

The preceding first address is controlled from somewhere (shown in the following image) in wwlib.dll via a “call [ecx+4]”.

eip_control2

As we can see, at this point the object (pointed by ecx, at 0x07941060 for this test) is being used incorrectly. What we see is that the memory bytes are always the following (listed at 0x18 length):

07941060  7B 7B 00 00 E8 48 5A 27 89 64 59 27 EF B8 58 27
07941070  59 59 00 00 5A 5A 00 00

Note the second DWORD 0x275A48E8; this is the EIP that is controlled. The other bytes are also important for making sure all the following steps (after the first EIP control) work correctly, such as ROP and shellcode executions. So the question is, Where do the memory bytes for this incorrectly used object come from? Is this filled by some kind of heap spraying or something else? More deep research showed that all of the bytes actually came directly from the RTF file; in other words, all the bytes can be controlled.

The mystery lies in the fields (and their values) in the “listoverrideformat” structure inside the incorrectly handled “lfolevel” structure. The following image shows exactly how the fields’ values are transferred into the 0x18-length memory bytes:

bytes_relation1

Here are the highlights:

  1. Bytes 0-3 (first DWORD) are controlled via the “\levelstartat” control word
  2. Byte 4 is controlled via the “\levelnfcn” control word
  3. Controlling byte 5 is a little tricky, but it’s important because that’s where the first EIP control goes. This step is not easy due to the nature of the confusing object. The attacker is apparently smart enough to realize that he or she can control the fourth and seventh bits (from low to high) of the byte via the “\levelnorestart” and the “\levelold” control words, respectively. When these two bits are set, the byte comes to 0x48 (in bits, 0100 1000) which is a part of the DWORD 0x275A48E8. This is enough to transfer the program flow to a useful starting address in MSCOMCTL.DLL.
  4. Bytes 6-14 can be controlled via the “\levelnumbers” control word. In this example, the attacker uses a “\'” control word to input a hex byte 0x5A (\’5A). The program reads the other bytes (7-14) directly from the following bytes in the RTF file.
  5. Byte 15 is controlled via the “\levelfollow” control word
  6. The DWORDs at bytes 16-19 and at bytes 20-23 are controlled via the “\levelspace” and the “\levelindent” control words, respectively. (The linking relationship isn’t shown in the preceding figure.)

Because the object memory can be controlled accurately by the attacker via specific RTF control words, the attacker can make a highly reliable and accurate exploitation, even without a heap spray.

Overview of follow-up executions
(provided by McAfee Labs researcher Jun Xie)

The ROP chain (in MSCOMCTL.DLL) allocates a memory block marked as READ/WRITE/EXECUTE at address 0x40000000, and copies the first-stage shellcode to this address. After that, a specific ROP, usually known as stack pivot, runs and the program flow goes to 0x40000040.

In the first-stage shellcode, the exploit performs a brute-force search to find the file handle to map the RTF file into memory. Then it searches the second-stage shellcode and copies the second-stage shellcode to address 0x40002000. The second-stage shellcode reads the Microsoft patch-log file on the system. If it finds that the last patch time is after April 8, the execution is terminated. Otherwise, it will decrypt and drop malware named svchost.exe (to confuse the victim). The malware makes some other confusing moves, for example, at the end it decrypts and shows a harmless Word document (which includes some porn images) to the victim.

Conclusion
From what we’ve learned, we can see how sophisticated this exploit is and how deeply the attackers understand RTF. Apparently the bad guys understand the related control words and their memory representations at a really deep level.

Considering these elements, we see this zero day as a serious threat and suggest that everyone take the following action(s) as soon as possible:

  • For McAfee customers, apply our detection solutions, found here
  • Apply the “Fix It” tool or install EMET, as suggested by Microsoft
  • Wait to apply the patch that will be released next Tuesday, according to the Microsoft Security Response Center blog post

Thanks to Bing Sun, Xiaoning Li (McAfee Labs), and Chong Xu for their help with this analysis.

The post A Close Look at RTF Zero-Day Attack CVE-2014-1761 Shows Sophistication of Attackers appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/close-look-rtf-zero-day-attack-cve-2014-1761-shows-sophistication-attackers/feed/ 0
RTF Attack Takes Advantage of Multiple Exploits https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rtf-attack-takes-advantage-of-multiple-exploits/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rtf-attack-takes-advantage-of-multiple-exploits/#comments Thu, 03 Apr 2014 19:14:31 +0000 http://blogs.mcafee.com/?p=34366 This is a joint analysis by Haifei Li, Stanley Zhu, and Jun Xie of McAfee Labs Recently, the rich text format has provoked new interest in the security industry due to a critical RTF zero-day (CVE-2014-1761) exploit found in the wild. McAfee Labs has investigated this threat. As usual, we suggest our customers apply our […]

The post RTF Attack Takes Advantage of Multiple Exploits appeared first on McAfee Blogs.

]]>
This is a joint analysis by Haifei Li, Stanley Zhu, and Jun Xie of McAfee Labs

Recently, the rich text format has provoked new interest in the security industry due to a critical RTF zero-day (CVE-2014-1761) exploit found in the wild. McAfee Labs has investigated this threat. As usual, we suggest our customers apply our solutions right away if you haven’t already done so.

In this post, we want to share our analysis of another RTF exploit. This attack is particularly interesting because the single RTF sample tries to exploit two previous vulnerabilities. This multiexploitation technique is usually seen in HTML or JavaScript exploits but rarely for RTF or Office exploits.

Analyzing the exploit
As you can see in the following figure, the malicious RTF comes as an attachment to an email that appears to be a UPS delivery invoice.

attack_email2

We have analyzed the content of the RTF at a deep level. The content consists of several objects, which we will examine one by one.

The first object looks like the following:

object1

The first object loads both first- and second-stage shellcode in memory. After successful exploitation, the first-stage shellcode searches the memory for the second-stage shellcode and executes it. We’ll explain this later.

The second object in the RTF file is some OLE data read via the program ID “Word.Document.12,” which suggests that it contains a Word 2007 OpenXML document.

object2We can simply “unzip” the .docx file and find something like this.

heap_spray_activex1

As shown above, the attack uses the same nonscriptable heap-spraying trick that we first identified in the Office TIFF zero-day attack, which we discovered in the wild last November. Previously we had seen the trick used only with OpenXML formats (.docx); this time the trick is used with RTF.

The third object aims to exploit a years-old but still popular Office vulnerability. This vulnerability, CVE-2010-3333, is a stack-based overflow in MSCOMCTL.OCX. The vulnerability is easy to exploit, which makes popular in many exploit kits.

After successfully exploiting CVE-2010-3333, shellcode will execute; it’s a very smooth attack. However, CVE-2010-3333 is an old vulnerability that was patched more than three years ago. To maximize the chance of hacking into victims’ systems, the attacker has made some innovations.

The third object also tries to trigger the CVE-2013-3906 TIFF paring vulnerability through a “\pict” control word, with the object stream actually a crafted TIFF file.

object_last

CVE-2013-3906 is an integer overflow vulnerability in OGL.DLL. By exploiting the vulnerability, an attacker can control the program flow to heap memory around 0x0A0AXXXX. At this point, the heap memory has already been sprayed there via the second object, so the first-stage shellcode will be correctly executed in the heap. The shellcode uses 0x3F (AAS) as the NOP instruction.

EIP_control_point2

After that, the first-stage shellcode in the second object searches for and executes the second-stage shellcode.

 

Analyzing the dropped malware
After a successful start, the exploit downloads the malware from http://track.invoice-accounts.org/WebTracking/updateoffice.exe and executes it. See following piece of shellcode:

malware_download1

The dropped updateoffice.exe is a variant of the Win32/Trojan.zbot family. Now let’s look at a behavior analysis of the malware, consisting of three steps.

Step 1
The malware copies itself to the %temp% directory and renames itself laruo.exe (with perhaps some random characters), and executes. The full path may look like this:
C:\Documents and Settings\%user%\Local Settings\Temp\Owma\laruo.exe.

malware_figure1

Step 2
Laruo.exe releases its driver file (2ad5a3) to the %system32\drivers directory and loads it into the kernel (C:\WINDOWS\system32\drivers\2ad5a3.sys). The malicious driver replaces a kernel-mode driver, and also hooks NtOpenProcess and NtOpenThread in the SSDT kernel. The driver code is encrypted. The malicious driver is a variant of the W32.Rootkit.Necurs family.

Step 3
Laruo.exe is injected into the explorer.exe process, and adds itself to AutoRun by editing the following register key:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run Value: “C:\Documents and Settings\sh1t0u\Local Settings\Temp\Owma\laruo.exe.

Laruo.exe disables the Windows firewall by modifiying the value of the register key
HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile.

It also does some self-deleting using the following command line:
C:\WINDOWS\system32\cmd.exe” /c “C:\DOCUME~1\%user%\LOCALS~1\Temp\OLDFF57.bat.

With the malware injected into explorer.exe, the injection code connects to the malicious domain aulbbiwslxpvvphxnjij.biz (50.116.4.71) for DNS requests. The string is contained in the malware file itself, as shown next:

malware_figure2

The address 115.126.143.176 is the active control server as we write this:

malware_figure3

 

Conclusion
To simplify, the process of the RTF exploit takes four steps:

  1. Load the second-stage shellcode for future execution (preparing for Step 4)
  2. Spray the heap using the method we first saw in the CVE-2013-3906 .docx exploit (preparing for Step 4)
  3. Exploit CVE-2010-3333
    A. If successful, the malware executes (shutting down the Word process). => Game over
    B. If failing, nothing happen except go to Step 4.
  4. Exploit CVE-2013-3906 with the sprayed heap and second-stage shellcode prepared in Step 1 and 2. => Game over

In this post we have showcased a real-world multiexploitation RTF attack that we recently detected in the wild. Even though the RTF is not a scriptable file format, this RTF-specific trick is able to exploit multiple vulnerabilities in one single RTF attack. This trick helps bad guys maximize their chances of success.

From this analysis we now know how flexible the RTF file format can be: It could perhaps embed any Office exploit. From a defense point of view, the complexity of the RTF format poses a challenge for accurate detection via signature-based methods. We have seen quite a lot of RTF exploits that lack detections, but we are glad to see that our sandboxing solutions–such as McAfee Advanced Threat Defense and the Advanced Exploit Detection System project–are filling the gap.

We would like to thank Bing Sun, Xiaoning Li (McAfee Labs,) and Chong Xu for their help with this analysis.

The post RTF Attack Takes Advantage of Multiple Exploits appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rtf-attack-takes-advantage-of-multiple-exploits/feed/ 2
McAfee Labs Detects Zero-Day Exploit Targeting Microsoft Office https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-detects-zero-day-exploit-targeting-microsoft-office-2/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-detects-zero-day-exploit-targeting-microsoft-office-2/#respond Tue, 05 Nov 2013 18:00:02 +0000 http://blogs.mcafee.com/?p=30977 Last Thursday morning (October 31), our Advanced Exploit Detection System (AEDS), which we discussed in an earlier post, detected a suspicious sample targeting Microsoft Office. After some investigation, we confirmed this is a zero-day attack. Considering the importance of this incident, we shared our findings immediately with the Microsoft Security Response Center and worked closely […]

The post McAfee Labs Detects Zero-Day Exploit Targeting Microsoft Office appeared first on McAfee Blogs.

]]>
Last Thursday morning (October 31), our Advanced Exploit Detection System (AEDS), which we discussed in an earlier post, detected a suspicious sample targeting Microsoft Office. After some investigation, we confirmed this is a zero-day attack.

Considering the importance of this incident, we shared our findings immediately with the Microsoft Security Response Center and worked closely with them in the last couple days. Today, as Microsoft has publicly released the security advisory with mitigations and workarounds, we feel it is time to share some detail of this zero-day attack.

Here is the traffic captured by this attack on a fully updated version of Office 2007 running on Windows XP SP3.

traffic1

As we can see, after successful exploitation, the exploit downloads an executable (saved to C:\Documents and Settings\<username>\Local Settings\Temp\winword.exe) from the controlled web server.

The executable is actually a RAR SFX containing another executable and a fake Word document. The another executable (dropped to C:\Documents and Settings\<username>\Updates.exe) is a backdoor allowing attacker to take control of the victim’s computer. The fake document (dropped to C:\Documents and Settings\<username>\Shanti.doc) is popped to the victim right after the success of the exploitation, this is a common post-exploitation trick which tries to prevent victims from being aware of this attack.

The zero-day exploit sample is organized as the Word OpenXML format (.docx). We observed many ActiveX objects contained in the “activeX” directory after unzipping the .docx file. This suggests that the exploit uses ActiveX control to spray the heap memory.

activex_spray1

It is worth to note that this heap-spraying in Office via ActiveX objects is a new exploitation trick which we didn’t see before, previously attackers usually chose Flash Player to spray memory in Office. We would believe the new trick was developed under the background that Adobe introduced a click-to-play feature in Flash Player months ago, which basically killed the old one. This is another proof that attacking technique always tries to evolve when old ones don’t work anymore.

As it shows, the meta date of the files were set to October 17, 2013, which may suggest a creation time of this exploit (though, the meta time could be faked).

And this is the place that EIP is being controlled to a sprayed memory space 0x08080808.

eip_control_windbg_hidden21

Speaking on the vulnerability leveraged by this attack, while we spotted the attack performed via Office 2007 running on Windows XP, this is actually a fault existing in a TIFF-processing component shipped with Microsoft Office. Therefore, not only are Office 2007 with Windows XP vulnerable to this attack, but also more environments are affected by this vulnerability. In addition, our later research showed this exploit also works on Office 2007 running on Windows 7. We’d suggest that readers take a look at the SRD blog post where they shared the exact affected environments and views from the vendor’s perspective. The Labs has been actively working on getting every piece of details of this exploit, we may share our additional findings in the near future.

Our AEDS continues to monitor advanced threats such as zero-day exploits and APTs worldwide, as a part of our commitments to protect our customers from today’s fast-evolving attacks.

For McAfee customers, we have released NIPS signature “UDS-ShantiMalwareDetected” last Friday to deliver protection in advance, our HIPS product is able to detect this attack without any update.

Thanks Bing Sun, Chong Xu, Xiaoning Li (McAfee Labs)  and Lijun Cheng for their hard work on the exploit analysis as well as IPS detections. Guilherme Venere and Abhishek Karnik also contributed from the anti-virus side.

The post McAfee Labs Detects Zero-Day Exploit Targeting Microsoft Office appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-detects-zero-day-exploit-targeting-microsoft-office-2/feed/ 0
New Zero-Day Attack Copies Earlier Flash Exploitation https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/new-zero-day-attack-copies-earlier-flash-exploitation/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/new-zero-day-attack-copies-earlier-flash-exploitation/#respond Fri, 12 Jul 2013 18:51:58 +0000 http://blogs.mcafee.com/?p=27404 Late on July 10, Microsoft released a blog post disclosing that they were aware of a zero-day attack in the wild. This attack exploits a previously unpatched Internet Explorer vulnerability (CVE-2013-3163). It’s interesting that the vulnerability was just patched in this month’s Patch Tuesday (July 9), which is perhaps only a coincidence. Although we do […]

The post New Zero-Day Attack Copies Earlier Flash Exploitation appeared first on McAfee Blogs.

]]>
Late on July 10, Microsoft released a blog post disclosing that they were aware of a zero-day attack in the wild. This attack exploits a previously unpatched Internet Explorer vulnerability (CVE-2013-3163). It’s interesting that the vulnerability was just patched in this month’s Patch Tuesday (July 9), which is perhaps only a coincidence. Although we do not know how long ago the attack began, we do have the official solution right now. (Apply the Microsoft patch if you haven’t done so.)

McAfee Labs rapidly responded to the threat. While digging into the exploitation process, we realized that this attack leverages the same exploitation technology that we were first to identify in an Adobe Flash zero-day attack in February. We call the new exploitation technology the Flash Vector exploitation. As highlighted in our blog post from February, we made a fairly accurate prediction:

More important, the technique looks like a common exploitation approach to Flash Player. The vulnerability actually doesn’t help much–just overwriting few bytes that are considered as a field of “element number” for a specific ActionScript object. These traits show that the exploitation technique is not limited to this particular Flash vulnerability; it may apply to other Flash or non-Flash vulnerabilities.

Both of these attacks leverage a weakness inside Flash Player’s custom heap management, especially, for the heap management of ActionScript “Vector.<>” objects. During our analysis, we also found some minor differences between these two attacks:

  • Because the trigger of the previous attack is a Flash vulnerability, the exploitation contains a step that frees the heap block (“leaving the hole”). In the second case, this step is not necessary because the trigger is an IE vulnerability. IE and Flash use different heap managements; thus IE can overwrite the memory bytes managed by Flash.
  • In the earlier exploitation, the zero day leveraged the “Vector.<Number>()” object and corrupted its length field. In the current case, the exploit leverages the “Vector.<uint>()” object (corrupting its length field as well). For example, the following code sprays a lot of “Vector.<uint>()” objects in the memory:

vector_spraying1

McAfee Labs has released a couple of UDS signatures to protect customers of our Network Security Platform against the IE vulnerability as well as the exploitation. Signature “UDS-HTTP: Microsoft Internet Explorer CBlockElement bdo element tag Use After Free Vulnerability I” addresses the vulnerability, and “UDS-HTTP: Microsoft Internet Explorer CVE-2013-3163 Flash Exploitation” handles the exploitation. Also, the generic buffer overflow prevention feature on our HIPS products will stop the related attacks.

The author would like to thank Bing Sun, Chong Xu, and Xiaoning Li for their help with the analysis.

The post New Zero-Day Attack Copies Earlier Flash Exploitation appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/new-zero-day-attack-copies-earlier-flash-exploitation/feed/ 0
Tracking PDF Usage Poses a Security Problem https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/tracking-pdf-usage-poses-a-security-problem/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/tracking-pdf-usage-poses-a-security-problem/#respond Fri, 26 Apr 2013 23:18:19 +0000 http://blogs.mcafee.com/?p=24235 Update on May 2 Adobe has confirmed this vulnerability and has scheduled a patch release for May 14.   Looking back this year’s RSA Conference, you might have the feeling that the current threat landscape is primarily a series of advanced attacks. This concept includes well-known advanced persistent threats (APTs) and zero-day vulnerability exploits. To […]

The post Tracking PDF Usage Poses a Security Problem appeared first on McAfee Blogs.

]]>
Update on May 2

Adobe has confirmed this vulnerability and has scheduled a patch release for May 14.

 

Looking back this year’s RSA Conference, you might have the feeling that the current threat landscape is primarily a series of advanced attacks. This concept includes well-known advanced persistent threats (APTs) and zero-day vulnerability exploits. To respond to this trend in threats, McAfee Labs has launched several innovative projects, one of which we call the advanced exploit detection system (AEDS). The AEDS is based on our in-depth understanding of application security, which comes from our long-term cutting-edge research efforts. We have already seen some interesting results that reflect the effectiveness of the project.

Recently, we detected some unusual PDF samples. After some investigation, we successfully identified that the samples are exploiting an unpatched security issue in every version of Adobe Reader including the latest “sandboxed” Reader XI (11.0.2). Although the issue is not a serious problem (such as allowing code execution), it does let people track the usage of a PDF. Specifically, it allows the sender to see when and where the PDF is opened.

The vulnerability

When a specific PDF JavaScript API is called with the first parameter having a UNC-located resource, Adobe Reader will access that UNC resource. However, this action is normally blocked and creates a warning dialog asking for permission, such as we see below:

pdf_track_of_usage1

The danger is that if the second parameter is provided with a special value, it changes the API’s behavior. In this situation, if the UNC resource exists, we see the warning dialog. However, if the UNC resource does not exist, the warning dialog will not appear even though the TCP traffic has already gone.

The following screen capture shows the outgoing traffic:

pdf_track_of_usage2

How does this affect users?

Is this a serious problem? No, we don’t want to overvalue the issue. However, we do consider this issue a security vulnerability. Considering this, we have reported the issue to Adobe and we are waiting for their confirmation and a future patch. We are also hiding the key details of the vulnerability to protect Reader users. We may update this post at some point after we see a patch from Adobe.

Some people might leverage this issue just out of curiosity to know who has opened their PDF documents, but others won’t stop there. An APT attack usually consists of several sophisticated steps. The first step is often collecting information from the victim; this issue opens the door. Malicious senders could exploit this vulnerability to collect sensitive information such as IP address, Internet service provider, or even the victim’s computing routine. In addition, our analysis suggests that more information could be collected by calling various PDF JavaScript APIs. For example, the document’s location on the system could be obtained by calling the JavaScript “this.path” value.

Who is exploiting this issue?

We have detected some PDF samples in the wild that are exploiting this issue. Our investigation shows that the samples were made and delivered by an “email tracking service” provider. We don’t know whether the issue has been abused for illegal or APT attacks.

Conclusion and protection

This interesting case highlights the point that privacy protection is a part of security. It shows that we can form different opinions depending on our goals (such as security protection vs. email tracking service).

This case also demonstrates that we need to constantly explore methods of detection because these examples won’t trigger memory corruption or code execution. Some of the most advanced detection technologies in the industry failed to detect them. We are happy to see that our AEDS is filling the gap.

Until Adobe creates a patch, Reader users should consider disabling JavaScript in Reader.

 

Thanks to my colleagues Bing Sun, Xiaobo Chen, and Chong Xu for their help with this investigation.

The post Tracking PDF Usage Poses a Security Problem appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/tracking-pdf-usage-poses-a-security-problem/feed/ 0
A Quick Analysis of the Flash Player Opcode-Verifying Code Execution Vulnerability https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/a-quick-analysis-of-the-flash-player-opcode-verifying-code-execution-vulnerability/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/a-quick-analysis-of-the-flash-player-opcode-verifying-code-execution-vulnerability/#respond Tue, 16 Oct 2012 03:42:31 +0000 http://blogs.mcafee.com/?p=19428 On October 12, McAfee Labs learned of proof-of-concept code exploiting a newly patched Flash Player vulnerability. Adobe had patched this vulnerability in its latest security update on October 8. Our research team rapidly responded to this threat with an in-depth analysis of the root cause and the degree of exploitability. This specific vulnerability occurred due […]

The post A Quick Analysis of the Flash Player Opcode-Verifying Code Execution Vulnerability appeared first on McAfee Blogs.

]]>
On October 12, McAfee Labs learned of proof-of-concept code exploiting a newly patched Flash Player vulnerability. Adobe had patched this vulnerability in its latest security update on October 8. Our research team rapidly responded to this threat with an in-depth analysis of the root cause and the degree of exploitability.

This specific vulnerability occurred due to a coding fault in Adobe’s ActionScript virtual machine (a.k.a. The Tamarin Project). Specifically, it lies in the way that AVM2 verifies the opcode OP_inclocal or OP_declocal. A checking logic step was mistakenly disabled by a macro. As a result, a U30 parameter was used directly without a bounds check, which leads to various code execution situations.

We assess the threat, CVE-2012-5271, by the following:

  • The root cause is quite simple. It’s in the core of the AVM (verification), so every platform’s Flash Player (such as the built-in Flash Player on Chrome and Windows 8) is affected.
  • AVM is a scriptable virtual machine. Because the coding fault lies in its core verification process, attackers may have many opportunities to develop a working exploit.

We strongly suggest users update their Flash Players as soon as possible. For McAfee customers, a User Defined Signature was released late on Friday, Oct 12 to deliver our protections. The signature name is “UDS-HTTP: Adobe Flash Player ActionScript Opcode OP_inclocal and OP_declocal Verifying Code Execution Vulnerability.”

McAfee Labs will continue to monitor the threat of this vulnerability.

 

I’d like thank my colleagues Yichong Lin, Bing Sun, XiaoBo Chen, and Chong Xu for their collaboration on this analysis.

The post A Quick Analysis of the Flash Player Opcode-Verifying Code Execution Vulnerability appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/a-quick-analysis-of-the-flash-player-opcode-verifying-code-execution-vulnerability/feed/ 0