Debasish Mandal – McAfee Blogs https://securingtomorrow.mcafee.com Securing Tomorrow. Today. Mon, 28 Oct 2019 09:17:07 +0000 en-US hourly 1 https://securingtomorrow.mcafee.com/wp-content/uploads/2018/11/cropped-favicon-32x32.png Debasish Mandal – McAfee Blogs https://securingtomorrow.mcafee.com 32 32 Using Expert Rules in ENS to Prevent Malicious Exploits https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/using-expert-rules-in-ens-10-5-3-to-prevent-malicious-exploits/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/using-expert-rules-in-ens-10-5-3-to-prevent-malicious-exploits/#respond Fri, 25 Oct 2019 15:41:38 +0000 https://securingtomorrow.mcafee.com/?p=97184

Expert Rules are text-based custom rules that can be created in the Exploit Prevention policy in ENS Threat Prevention 10.5.3+. Expert Rules provide additional parameters and allow much more flexibility than the custom rules that can be created in the Access Protection policy. It also allows system administration to control / monitor an endpoint system […]

The post Using Expert Rules in ENS to Prevent Malicious Exploits appeared first on McAfee Blogs.

]]>

Expert Rules are text-based custom rules that can be created in the Exploit Prevention policy in ENS Threat Prevention 10.5.3+. Expert Rules provide additional parameters and allow much more flexibility than the custom rules that can be created in the Access Protection policy. It also allows system administration to control / monitor an endpoint system at a very granular level. Expert rules do not rely on User-Mode hooking; hence they have very minimal impact on a system’s performance. This blog is created as a basic guide to show our customers how to create them and which threats they can help block. Further detailed information can be found in the conclusion.

How Expert Rules work

The following sections show how to add Expert rules via EPO and ENS.

Adding an Expert Rule from EPO

1. Select System Tree | Subgroup (e.g.: ens_10.6.0) | Assigned Policies | Product (Endpoint Security Threat Prevention) | Exploit Prevention (My Default)

2. Navigate to Signatures and click on Add Expert Rule.

3. In the Rules section, complete the fields.

a. Select the severity and action for the rule. The severity provides information only; it has no select on the rule action.

b. Select the type of rule to create. The Rule content field is populated with the template for the selected type.

c. Change the template code to specify the behavior of the rule.

When you select a new class type, the code in the Rule content field is replaced with the corresponding template code. Endpoint Security assigns the ID number automatically, starting with 20000. Endpoint Security does not limit the number of Expert Rules you can create.

4. Save the rule, then save the settings.

5. Enforce the policy to a client system.

6. Validate the new Expert Rule on the client system.

Adding an Expert Rule directly at the Endpoint:

If we need to add an expert rule from EPO it will be pushed to all endpoints of an entire EPO “WORKGROUP”. There could be situations where expert rules are required to be applied in one/two systems or ENS systems which are not managed by EPO (non-corporate environment where ENS is installed from a standalone setup); in those cases, the expert rule must be added directly at the endpoint. Expert rules can be written and applied directly at the Endpoint system using McAfee Endpoint Security UI. Steps are below:

1. Open McAfee Endpoint Security. Go to Settings.

2. Go to Threat Prevention | Show Advanced.

3. Scroll Down to Expert Rule Section and then click on Add Expert Rule.

4. The expert rule compiler should pop up where an end user can directly write and compile expert rules and, upon compilation, enforce the rules to the system.

If there is no syntax error in the expert rule it can be applied in the system by clicking on the Enforce button. In case there is a syntax error, the details can be found in log file  %ProgramData%\McAfee\Endpoint Security\Logs\ExploitPrevention_Debug.log

Testing the Rules

When new rules are created, they should first be tested in ‘Report’ mode so that the detections can be observed. When enough confidence in the rule has been gained, it can be turned to ‘Block’ mode.

Expert Rule Examples:

 

Basic Rule:

The following rule will detect an instance of cmd.exe creating any file at c:\temp. Please note that cmd.exe might be run by any user and from any part of the system.

Rule {

Process {

Include OBJECT_NAME { -v “cmd.exe” }

}

Target {

Match FILE {

Include OBJECT_NAME { -v “c:\\temp\\**” }

Include -access “CREATE”

}

}

}

 

Rules which target specific malicious behavior:

The following rules can be created to help block specific malicious activity which is performed by various malware families and attack techniques.

 

Expert Rule to Block Remote Process Injection [MITRE Technique Process Injection T1055]:

Rule {

Process {

Include OBJECT_NAME { -v “**” }

Exclude OBJECT_NAME { -v “SYSTEM” }

Exclude OBJECT_NAME { -v “%windir%\\System32\\WBEM\\WMIPRVSE.EXE” }

Exclude OBJECT_NAME { -v “%windir%\\System32\\CSRSS.EXE” }

Exclude OBJECT_NAME { -v “%windir%\\System32\\WERFAULT.EXE” }

Exclude OBJECT_NAME { -v “%windir%\\System32\\SERVICES.EXE” }

Exclude OBJECT_NAME { -v “*\\GOOGLE\\CHROME\\APPLICATION\\CHROME.EXE” }

}

Target {

Match THREAD {

Include OBJECT_NAME { -v “**” }

Exclude OBJECT_NAME { -v “**\\MEMCOMPRESSION” }

Exclude OBJECT_NAME { -v “%windir%\\System32\\WERFAULT.EXE” }

Include -access “WRITE”

}

}

}

 

Expert Rule which prevents powershell.exe and powershell_ise.exe process from dumping credentials by accessing lsass.exe memory [ MITRE Technique Credential Dumping T1003 ]:

Rule {

Process {

Include OBJECT_NAME {  -v “powershell.exe”  }

Include OBJECT_NAME {  -v “powershell_ise.exe”  }

Exclude VTP_PRIVILEGES -type BITMASK { -v 0x8 }

}

Target {

Match PROCESS {

Include OBJECT_NAME {   -v  “lsass.exe”  }

Include -nt_access “!0x10”

Exclude -nt_access “!0x400”

}

}

}

 

Expert Rule which prevents creation of a suspicious task (PowerShell script or batch file) using “SchTasks.exe” utility [MITRE Technique Scheduled Task T1053]:

Rule {

Process {

Include OBJECT_NAME { -v  “SchTasks.exe” }

Include PROCESS_CMD_LINE { -v “*/Create*” }

}

Target {

Match PROCESS {

Include PROCESS_CMD_LINE { -v “**.bat**” }

}

Match PROCESS {

Include PROCESS_CMD_LINE { -v “**.ps1**” }

}

}

}

 

Expert Rule to prevent Start Up Entry Creation [ MITRE Technique Persistence T1060]:

Adversaries can use several techniques to maintain persistence through system reboots. One of the most popular techniques is creating entries in the Start Up folder. The following expert rule will prevent any process from creating files in the Start Up folder. Recently, the internet has witnessed a full-fledged exploit of a decade old WinRAR vulnerability (CVE-2018-20251) which can be exploited by dropping files in the Start Up directory. The following expert rule will also block such an attempt.

Rule {

Process {

Include OBJECT_NAME { -v ** }

}

Target {

Match FILE {

Include OBJECT_NAME { -v “**\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\**” }

Include -access “CREATE WRITE”

}

}

}

 

Expert Rule which blocks JavaScript Execution within Adobe Reader:

Exploiting a client-side software vulnerability to gain an initial foothold in a network is not new [MITRE Technique T1203]. Adobe Reader is a very popular target because, like any other browser, it supports JavaScript which makes exploitation much easier. The following expert rule can be deployed in any network to prevent Adobe Reader from executing any kind of JavaScript.

Rule {

Process {

Include OBJECT_NAME { -v “AcroRd32.exe”}

}

Target {

Match SECTION {

Include OBJECT_NAME { -v “EScript.api” }

}

}

}

The table below shows how the above four Expert Rules line up in the Mitre Att&ck matrix.

Conclusion

There are many more rules which can be created within Exploit Prevention (part of McAfee’s ENS Threat Prevention) and they can be customized depending on the customer’s environment and requirements. For example, the Expert Rule which blocks JavaScript Execution within Adobe Reader will be of no use if an organization does not use “Adobe Reader” software. To fully utilize this feature, we recommend our customers read the following guides:

https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/27000/PD27227/en_US/ens_1053_rg_ExpertRules_0-00_en-us.pdf

https://kc.mcafee.com/corporate/index?page=content&id=KB89677

 

Disclaimer: The expert rules used here as examples can cause a significant number of False Positives in some environments, hence we recommend those rules to be explicitly applied only in an environment where better visibility of above (or similar) events at granular level is required.

Acknowledgement:

The author would like to thank following colleagues for their help and inputs authoring this blog.

  • Oliver Devane
  • Abhishek Karnik
  • Cedric Cochin

The post Using Expert Rules in ENS to Prevent Malicious Exploits appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/using-expert-rules-in-ens-10-5-3-to-prevent-malicious-exploits/feed/ 0
IE Scripting Flaw Still a Threat to Unpatched Systems: Analyzing CVE-2018-8653 https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ie-scripting-flaw-still-a-threat-to-unpatched-systems-analyzing-cve-2018-8653/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ie-scripting-flaw-still-a-threat-to-unpatched-systems-analyzing-cve-2018-8653/#respond Thu, 10 Jan 2019 23:27:28 +0000 https://securingtomorrow.mcafee.com/?p=93699

Microsoft recently patched a critical flaw in Internet Explorer’s scripting engine that could lead to remote code execution. The vulnerability is being exploited in the wild and was originally reported by a researcher from Google’s Threat Analysis Group. Microsoft released an out-of-band patch to fix the vulnerability before the normal patch cycle. McAfee products received […]

The post IE Scripting Flaw Still a Threat to Unpatched Systems: Analyzing CVE-2018-8653 appeared first on McAfee Blogs.

]]>

Microsoft recently patched a critical flaw in Internet Explorer’s scripting engine that could lead to remote code execution. The vulnerability is being exploited in the wild and was originally reported by a researcher from Google’s Threat Analysis Group. Microsoft released an out-of-band patch to fix the vulnerability before the normal patch cycle. McAfee products received an update to detect the threat shortly after the patch was released.

A remote attacker can target Internet Explorer Versions 9 through 11 via a specially crafted website, while a local attacker on a rogue network could also target the Web Proxy Auto-Discovery service, which uses the same vulnerable scripting engine (jscript.dll). Microsoft Edge is not affected; however, other Windows applications that include the scripting engine might be vulnerable until the security patch from Microsoft is applied.

Context

Vulnerabilities targeting Internet Explorer that can be triggered either remotely or locally are prime tools for cybercriminals to compromise many unpatched computers. That is why criminals usually integrate those vulnerabilities into exploit kits, which propagate malware or conduct other nefarious activities against compromised hosts. The threat of exploit kits is one reason to track this type of vulnerability and to ensure all security patches are deployed in a timely manner. In 2018, more than 100 memory corruption vulnerabilities were found in a Microsoft scripting engine (either for Internet Explorer or Edge). See the MITRE website for more details. (For defense-in-depth, products such as McAfee Endpoint Security or McAfee Host Intrusion Prevention can detect and eradicate such threats until patches can be applied.)

Once a CVE ID is released, cybercriminals can take as little as a few weeks (or in some cases days) to integrate it into their exploit kit. For example, CVE-2018-8174 was initially reported to Microsoft in late April by two teams of threat researchers who had observed its exploitation in the wild. Microsoft published an advisory within a week, in early May. Meanwhile, the researchers published their security analysis of the exploit. Only two weeks later a proof-of-concept exploit was publicly released. In the next couple of weeks exploit kits RIG and Magnitude integrated their weaponized versions of the exploit. (A more detailed timeline can be found here.)

It took less than a month for cybercriminals to weaponize the vulnerability initially disclosed by Microsoft; therefore, it is critical to understand the threat posed by these attack vectors, and to ensure counter measures are in place to stop the threat before it can do any damage.

Technical details

The IE scripting engine jscript.dll is a code base that has been heavily audited:

It is no surprise that exploitable bugs are becoming more exotic. This is the case for CVE 2018-8653, which takes three seemingly innocent behaviors and turns them into a use-after-free flaw. A Microsoft-specific extension triggers a rarely explored code path that eventually misbehaves and invokes a frequently used function with unusual arguments. This leads to the use-after-free condition that was exploited in the wild.

The enumerator object: The entry point for this vulnerability is a Microsoft-specific extension, the enumerator object. It offers an API to enumerate opaque objects that belong to the Windows world (mostly ActiveX components, such as a file system descriptor used to list drives on a system). However, it can also be called on a JavaScript array. In this situation, one can access the array member as usual, but objects created this way are stored slightly differently in memory. This is the cause of interesting side effects.

The objects created by calling the Enumerator.prototype.item() function are recognized as an ActiveXObject and, as seen in the creation of eObj, we can under certain circumstances overwrite the “prototype” member that should have been a read-only property.

Unexpected side effect: The ability to overwrite the prototype member of an ActiveXObject can seem innocuous at first, but it can be leveraged to explore a code path that should not be reachable.

When using the “instanceof” keyword, we can see that the right side of the keyword expects a function. However, with a specially crafted object, the instanceof call succeeds and, worse, we can control the code being executed.

The edge case of invoking instanceof on a specially crafted ActiveXObject gives us the opportunity to run custom JavaScript code from a callback we control, which is typically an error-prone situation.

Attackers successfully turned this bug into a use-after-free condition, as we shall see next.

Exploiting the bug: Without getting into too much detail (see the proof of concept later in this document for more info), this bug can be turned into a “delete this” type of primitive, which resembles previously reported bugs.
When the callback function (“f” in our previous example) is invoked, the keyword “this” points to eObj.prototype. If we set it to null and then trigger a garbage collection, the memory backing the object can be freed and later reclaimed. However, as mentioned in the Project Zero bug report, to be successful an entire block of variables needs to be cleared before the memory is freed.

The out-of-band patch: Microsoft released an unscheduled patch to fix this vulnerability. It is common practice for us to look at what changed before and after the patch. Interestingly, this patch changes the strict minimum number of bytes, while the version number of the DLL remains unchanged.

Using the popular diffing tool Diaphora, we compared the version of jscript.dll for Windows 10, x64-bit edition (feature version 1809).

We can see that only a few functions were modified. All but one point to array-related functions. Those were probably patches addressing CVE 2018-8631 (jscript!JsArrayFunctionHeapSort out-of-bounds write). The only one remaining that was substantially modified is NameTbl::InvokeInternal.

Diaphora provides us with a diff of the assembly code of the two versions of the function. In this instance, it is easier to compare the functions side by side in Ida Pro to see what has changed. A quick glance toward the end of the function shows the introduction of two calls to GCRoot::~GCRoot (the destructor of the object GCRoot).

Looking at the implementation of ~GCRoot, we see it is the same code as that inlined in that function created by the compiler in the older version of the DLL.

In the newer version of the DLL, this function is called twice; while in the unpatched version, the code was called only once (inlined by the compiler, hence the absence of a function call). In C++ parlance, ~GCRoot is the destructor of GCRoot, so we may want to find the constructor of GCRoot. An easy trick is to notice the magic offset 0x3D0 to see if this value is used anywhere else. We find it near the top of the same function (the unpatched version is on the left):

Diving into the nitty gritty of garbage collection for jscript.dll is beyond the scope of this post, so let’s make some assumptions. In C++/C#, GCRoot would usually design a template to keep track of references pointing to the object being used, so those do not have garbage collection. Here it looks as though we are saving stack addresses (aka local variables) into a list of GCRoot objects to tell the garbage collector not to collect the objects whose pointers are on those specific locations on the stack. In hindsight this makes sense; we were able to “delete this” because “this” was not tracked by the garbage collector, so now Microsoft makes sure to specifically add that stack variable to the tracked elements.

We can verify this hypothesis by tracing the code around an invocation of instanceof. It turns out that just before invoking our custom “isPrototypeOf” callback function, a call to NameTbl::GetVarThis stores a pointer in the newly “protected” stack variable and then invokes ScrFncObj::Call to execute our callback.

Looking at unexpected behavior in `instanceof`: Curious readers might wonder why it is possible to invoke instanceof on a custom object rather than on a function (as described previously). When instanceof is invoked in JavaScript, the CScriptRuntime::InstOf function is called behind the scene. Early on, the function distinguishes two cases. If the variable type is 0x81 (which seems to be a broad type for a JavaScript object on the heap), then it invokes a virtual function that returns true/false if the object can be called. On the other hand, if the type is not 0x81, a different path is followed; it tries to automatically resolve the prototype object and invoke isPrototypeOf.

The 0x81 path:

The not 0x81 path:

 

 

Proof of concept

Now that we have seen the ins and outs of the bug, let’s look at a simple proof of concept that exhibits the use-after-free behavior.

First, we set up a couple of arrays, so that everything that can be preallocated is allocated, and the heap is in a somewhat ready state for the use after free.

Then, we declare our custom callback and trigger the vulnerability:

For some reason, the objects array needs to be freed and garbage collected before the next step of the exploit. This could be due to some side effect of freeing the ActiveXObject. The memory is reclaimed when we assign “1” to the property reallocPropertyName. That variable is a magic string that will be copied over the recently freed memory to mimic legitimate variables. It is created as shown:

The 0x0003 is a variable type that tells us the following value is an integer and that 1337 is its value. The string needs to be long enough to trigger an allocation of the same or similar size as the memory block that was recently freed.

To summarize, JavaScript variables (here, the RegExp objects) are stored in a block; when all the variables from the block are freed, the block itself is freed. In the right circumstances, the newly allocated string can take the place of the recently freed block, and because “this” is still dangling in our callback, it can be used for some type confusion. (This is the method used by the attackers, but beyond the scope of this post.) In this example, the code will print 1337 instead of an empty RegExp.

McAfee coverage

Please refer to the McAfee product bulletin for full coverage updates. Here is a short summary of current product coverage as of this writing.

Endpoint products: Endpoint Security (ENS), ENS Adaptive Threat Protection (ENS-ATP), Host Intrusion Prevention (HIPS), VirusScan Enterprise (VSE), WSS.

  • ENS (10.2.0+) with Exploit Prevention
    • Proactively covered by McAfee Generic Buffer Overflow Protection Signature ID 428
  • HIPS (8.0.0+)
    • Proactively covered by McAfee Generic Buffer Overflow Protection Signature ID 428
  • ENS (all versions) and WSS (all versions). Coverage based on samples observed so far. This protection is expected to be expanded over the next few days as viable exploitation attempts are seen.
    • Minimum DAT: V3 DAT (3564)
    • Detection names: Exploit-CVE2018-8653 and Exploit-CVE2018-8653.a
  • VSE (8.8+). Coverage based on samples observed so far. This protection is expected to be expanded over the next few days as viable exploitation attempts are seen.
    • Minimum DAT: V2 DAT (9113)
    • Detection names: Exploit-CVE2018-8653 and Exploit-CVE2018-8653.a

Content summary

  • DATs: V2 DAT (9113), V3 DAT (3564)
  • Generic Buffer Overflow Protection Signature ID 428

MITRE score

The base score (CVSS v3.0) for this vulnerability is 7.5 (High) with an impact score of 5.9 and an exploitability score of 1.6.

Conclusion

CVE-2018-8653 targets multiple versions of Internet Explorer and other applications that rely on the same scripting engine. Attackers can execute arbitrary code on unpatched hosts from specifically crafted web pages or JavaScript files. Even though the bug was recently fixed by Microsoft, we can expect exploit kits to soon deploy a weaponized version of this critical vulnerability, leveraging it to target remaining unpatched systems. The technical analysis in this post should provide enough information for defenders to ensure their systems will withstand the threat and to know which primitives to look for as an entry point for the attack. McAfee security products can be leveraged to provide specific “virtual patching” for this threat until full software patches can be deployed, while current generic buffer overflow protection rules can be used to fingerprint exploit attempts against this and similar vulnerabilities.

The post IE Scripting Flaw Still a Threat to Unpatched Systems: Analyzing CVE-2018-8653 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ie-scripting-flaw-still-a-threat-to-unpatched-systems-analyzing-cve-2018-8653/feed/ 0
CactusTorch Fileless Threat Abuses .NET to Infect Victims https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cactustorch-fileless-threat-abuses-net-to-infect-victims/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cactustorch-fileless-threat-abuses-net-to-infect-victims/#respond Thu, 26 Jul 2018 13:00:32 +0000 https://securingtomorrow.mcafee.com/?p=90489 McAfee Labs has noticed a significant shift by some actors toward using trusted Windows executables, rather than external malware, to attack systems. One of the most popular techniques is a “fileless” attack. Because these attacks are launched through reputable executables, they are hard to detect. Both consumers and corporate users can fall victim to this […]

The post CactusTorch Fileless Threat Abuses .NET to Infect Victims appeared first on McAfee Blogs.

]]>
McAfee Labs has noticed a significant shift by some actors toward using trusted Windows executables, rather than external malware, to attack systems. One of the most popular techniques is a “fileless” attack. Because these attacks are launched through reputable executables, they are hard to detect. Both consumers and corporate users can fall victim to this threat. In corporate environments, attackers use this vector to move laterally through the network.

One fileless threat, CactusTorch, uses the DotNetToJScript technique, which loads and executes malicious .NET assemblies straight from memory. These assemblies are the smallest unit of deployment of an application, such as a .dll or .exe. As with other fileless attack techniques, DotNetToJScript does not write any part of the malicious .NET assembly on a computer’s hard drive; hence traditional file scanners fail to detect these attacks.

In 2018 we have seen rapid growth in the use of CactusTorch, which can execute custom shellcode on Windows systems. The following chart shows the rise of CactusTorch variants in the wild.

Source: McAfee Labs.

The DotNetToJScript tool kit

Compiling the DotNetToJScript tool gives us the .NET executable DotNetToJScript.exe, which accepts the path of a .NET assembly and outputs a JavaScript file.

 

Figure 1: Using DotNetToJScript.exe to create a malicious JavaScript file.

The DotNetToJScript tool kit is never shipped with malware. The only component created is the output JavaScript file, which is executed on the target system by the script host (wscript.exe). For our analysis, we ran some basic deobfuscation and found CactusTorch, which had been hidden by some online tools:

Figure 2: CactusTorch code.

Before we dive into this code, we need to understand .NET and its COM exposure. When we install the .NET framework on any system, several .NET libraries are exposed via Microsoft’s Component Object Model (COM).

Figure 3: COM exposing the .NET library System.Security.Cryptography.FromBase64Transform.

If we look at the exposed interfaces, we can see IDispatch, which allows the COM object to be accessed from the script host or a browser.

Figure 4: Exposed interfaces in a .NET library.

To execute malicious code using the DotNetToJScript vector, an attack uses the following COM objects:

  • Text.ASCIIEncoding
  • Security.Cryptography.FromBase64Transform
  • IO.MemoryStream
  • Runtime.Serialization.Formatters.Binary.BinaryFormatter
  • Collections.ArrayList

Now, let’s return to the JavaScript code we saw in Figure 2. The function base64ToStream()converts the Base64-encoded serialized object to a stream. Before we can fully understand the logic behind the JavaScript code, we need to examine the functionality of the Base64-encoded serialized object. Thus our next step is to reverse engineer the embedded serialized object and recreate the class definition. Once that was done, the class definition looks like the following code, which is responsible for executing the malicious shellcode. (Special thanks to Casey Smith, @subTee, for important pointers regarding this step).

Figure 5: The class definition of the embedded serialized object.

Now we have the open-source component of CactusTorch, and the JavaScript code in Figure 2 makes sense. We can see how the malicious shellcode is executed on the targeted system. In Figure 2, line 29 the code invokes the flame(x,x) function with two arguments: the executable to launch and the shellcode.

The .NET assembly embedded in the CactusTorch script runs the following steps to execute the malicious shellcode:

  • Launches a new suspended process using CreateProcessA (to host the shellcode)
  • Allocates some memory with VirtualAllocEx() with an EXECUTE_READWRITE privilege
  • Writes the shellcode in the target’s process memory with WriteProcessMemory()
  • Creates a new thread to execute the shellcode using CreateRemoteThread()

Conclusion

Fileless malware takes advantage of the trust factor between security software and genuine, signed Windows applications. Because this type of attack is launched through reputable, trusted executables, these attacks are hard to detect. McAfee Endpoint Security (ENS) and Host Intrusion Prevention System (HIPS) customers are protected from this class of fileless attack through Signature ID 6118.

 

Acknowledgements

The author thanks the following colleagues for their help with this analysis:

  • Abhishek Karnik
  • Deepak Setty
  • Oliver Devane
  • Shruti Suman

References

MITRE ATT&CK techniques

  • Drive-by compromise
  • Scripting using Windows Script Host
  • Decode information
  • Command-line interface
  • Process injection

Hashes

  • 4CF9863C8D60F7A977E9DBE4DB270819
  • 5EEFBB10D0169D586640DA8C42DD54BE
  • 69A2B582ED453A90CC06345886F03833
  • 74172E8B1F9B7F9DB600C57E07368B8F
  • 86C47B9E0F43150FEFF5968CF4882EBB
  • 89F87F60137E9081F40E7D9AD5FA8DEF
  • 8A33BF71E8740BDDE23425BBC6259D8F
  • 8DCCC9539A499D375A069131F3E06610
  • 924B7FB00E930082CE5B96835FDE69A1
  • B60E085150D53FCE271CD481435C6E1E
  • BC7923B43D4C83D077153202D84EA603
  • C1A7315FB68043277EE57BDBD2950503
  • D2095F2C1D8C25AF2C2C7AF7F4DD4908
  • D5A07C27A8BBCCD0234C81D7B1843FD4
  • E0573E624953A403A2335EEC7FFB1D83
  • E1677A25A047097E679676A459C63A42
  • F0BC5DFD755B7765537B6A934CA6DBDC
  • F6526E6B943A6C17A2CC96DD122B211E
  • CDB73CC7D00A2ABB42A76F7DFABA94E1
  • D4EB24F9EB1244A5BEAA19CF69434127

 

The post CactusTorch Fileless Threat Abuses .NET to Infect Victims appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cactustorch-fileless-threat-abuses-net-to-infect-victims/feed/ 0
Microsoft Kills Potential Remote Code Execution Vulnerability in Office (CVE-2017-8630) https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/microsoft-kills-potential-remote-code-execution-vulnerability-in-office-cve-2017-8630/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/microsoft-kills-potential-remote-code-execution-vulnerability-in-office-cve-2017-8630/#respond Thu, 21 Sep 2017 13:00:37 +0000 https://securingtomorrow.mcafee.com/?p=78653 Recently the McAfee IPS Research Team informed Microsoft about a potential remote code execution vulnerability in Office 2016 that McAfee discovered in March. Microsoft released a patch for this vulnerability this week with CVE-2017-8630. In this post, we will briefly discuss the vulnerability and its exploitability. The Problem While auditing PowerPoint, we came across an […]

The post Microsoft Kills Potential Remote Code Execution Vulnerability in Office (CVE-2017-8630) appeared first on McAfee Blogs.

]]>
Recently the McAfee IPS Research Team informed Microsoft about a potential remote code execution vulnerability in Office 2016 that McAfee discovered in March. Microsoft released a patch for this vulnerability this week with CVE-2017-8630. In this post, we will briefly discuss the vulnerability and its exploitability.

The Problem

While auditing PowerPoint, we came across an interesting application crash. The stack trace looked like this:

When we disassembled the crash point we noticed something interesting.

We saw the access violation occurred at address 0x6631508d. And at address 0x66315090 we noticed a call instruction. From these instructions it appeared the code was trying to call a virtual function from the vtable of an object. To make sure, we quickly enabled a page heap for PowerPoint and tried to reproduce the issue.

The page heap made it clear that the issue was a dangling pointer, a “use after free” case. The preceding screenshot shows that the object being accessed was already free. Although we identified the issue while examining PowerPoint, digging further reveals the issue lies in some Office 2016 shared functionality. The problem affects not only PowerPoint, but other applications as well. On September 12 Microsoft published a patch confirming that Office 2016 (32-bit and 64-bit editions) is affected by this problem.

Triggering the Condition

This use-after-free condition is not easy to trigger. When we open the proof-of-concept file in PowerPoint, several pop-up windows appear. We need to choose a specific set of options to exploit the vulnerability. The time gap between choosing the options also matters.

After several trials, we noticed the object is freed when we suppress the first pop-up and select OK. The object reuse happens when selecting the Repair option in the second window. This sequence is very helpful when we move to exploit this vulnerability.

Exploitation

Our exploitation strategy was the same as for any other use-after-free vulnerability. However, due to the absence of an interactive engine in Office, preparing the memory layout for the exploitation was challenging. In this case we used an ActiveX object to spray office memory and set up the desired memory layout. Two excellent papers explain how to prepare a desired memory layout to exploit Office.

These papers discuss the technique mostly with Word. However, we ported the same technique to PowerPoint. The following diagram shows the exploitation strategy at a glance:

Preparing the Memory Layout

Our first step in preparing the memory layout is to make sure that controlled data is present at known addresses, such as 0x0a0a0a0a and 0x0c0c0c0c.

The preceding screen shows how to use heap spray to place our controlled data at a predictable address. Address 0x0a0a0a0a has the data 0xdebadeba and some no-operation slides. To be more specific, for exploitation we need an address that we control at 0x0a0a0a0a + 0x8.

The next challenge is to create a fake object in a PowerPoint process of the same size as our object. To make sure we can claim the same freed heap block for our fake object, we must spray the memory several times so that the heap manager forcefully places the fake object where the real object was situated. We must spray the memory with same size multiple times using the pattern 0x0a0a0a0a. Thus when the virtual function is called using the object under our control, it will dereference the value from our heap spray (as we performed in last section) at the address 0x0a0a0a0a + 0x8.

So far, we have not done anything to the PowerPoint file that triggers the use-after-free vulnerability. We have just set the stage on which we will perform the exploitation. Once we have everything in place, we carefully port the heap-spraying code to the open XML file, which triggers the use after free.

The preceding screen shows, once everything is in right place, the register ecx pointing to the fake object. When it is dereferenced, we get a pointer to the fake vtable in eax.

McAfee highly recommends that Office 2016 users apply the patch shipped by Microsoft this month. This vulnerability resides in some shared features and can be exploited through different Office 2016 products. McAfee Network Security Platform IPS can catch some exploits with the help of Signature 0x45217b00.

The author thanks Bing Sun for his help with this post.

The post Microsoft Kills Potential Remote Code Execution Vulnerability in Office (CVE-2017-8630) appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/microsoft-kills-potential-remote-code-execution-vulnerability-in-office-cve-2017-8630/feed/ 0
Analyzing a Patch of a Virtual Machine Escape on VMware https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-patch-of-a-virtual-machine-escape-on-vmware/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-patch-of-a-virtual-machine-escape-on-vmware/#respond Mon, 17 Jul 2017 18:53:39 +0000 https://securingtomorrow.mcafee.com/?p=75709 This blog was written by Yakun Zhang. A virtual machine is a completely isolated guest operating system installation within a normal host operating system. Virtual machine escape is the process of breaking out of a virtual machine and interacting with the host operating system, which can lead to infections and malware execution. VMware escapes demonstrated […]

The post Analyzing a Patch of a Virtual Machine Escape on VMware appeared first on McAfee Blogs.

]]>
This blog was written by Yakun Zhang.

A virtual machine is a completely isolated guest operating system installation within a normal host operating system. Virtual machine escape is the process of breaking out of a virtual machine and interacting with the host operating system, which can lead to infections and malware execution. VMware escapes demonstrated at the most recent PwnFest, organized by Power of Community in Seoul, South Korea, grabbed our attention as VMware was publicly pwned for the first time. The McAfee IPS Vulnerability Research Team decided to look deeper into the issue to better understand the vulnerability.

VMware responded well by very quickly pushing a fix for these exploits and releasing a security advisory. As we often do for security issues in closed-source software, we looked into the advisory. It includes this:

“The drag-and-drop (DnD) function in VMware Workstation and Fusion has an out-of-bounds memory access vulnerability. This may allow a guest to execute code on the operating system that runs Workstation or Fusion. On Workstation Pro and Fusion, the issue cannot be exploited if both the drag-and-drop function and the copy-and-paste (C&P) function are disabled.”

The vulnerability resides in the drag-and-drop and copy-and-paste functions. Both use the VMware remote procedure call (RPC) mechanism. VMware’s RPC has been a very popular attack surface for guest-to-host escapes.

Before we go deeper into the patch for VMSA-2016-0019 (CVE-2016-7461) we must have a basic idea of how VMware Workstation handles guest-to-host or host-to-guest copy-and-paste operations.

The following diagram shows the VMware drag-and-drop copy-and-paste (DnDCP) model by class hierarchy. (Source: Open VM Tools source code.)

 

To seamlessly perform a guest-to-host or host-to-guest copy-and-paste operation, VMware tools need to be installed on the guest operating system. VMware tools handle the guest-to-host or host-to-guest communication. In our investigation, we used Windows guest and Windows host. In Windows guest, the main tools process is vmtoolsd.exe.

One way guest and host communicate with each other is by RPC. VMware has an RPC interface called Backdoor.

Guest RPC mechanism

Let’s take a close look at how a guest and host OS communicate with each other over RPC. To understand the guest RPC mechanism, we referred to the open-source component of VMware tools, open-vm-tools, which primarily use the following functions for guest RPC calls:

Theoretically, anything using RpcChannel_Send() or RpcOut_send() can be sent with the command-line tool rpctools.exe, which ships with VMWare Workstation.

RpcOut_Send() invokes Message_Send(), which calls the function Backdoor().

The Backdoor function is responsible for sending the message through the VMware special I/O port.

 

Usually we see the following set of instructions while invoking Backdoor from guest to host.

 

In the VMware tools installation, the function resides in vmtools.dll. Here we see Backdoor() calling the function sub_10050190.

Digging into this, we find this function executes the privilege instruction “in.”

Let’s return to the vulnerability. We are mainly interested in DnDCP RPC message(s) because the vulnerability lies in DnDCP RPC, per the advisory. The VM Tools source code reveals the DnDCP RPC message structure for us.

 

From the source code, we see the first member of the structure is the RPC command. When we break into vmtools!RpcOut_send(x,x,x,) of the vmtoolsd.exe process in guest, we see the same thing.

Bool RpcOut_send(RpcOut *out, char const *request, size_t reqLen,char const **reply, size_t *repLen);

In RpcOut_Send(), the second argument is the request-RPC packet. If we dump the packet from the guest OS vm-tools process, in the data packet we first see the RPC command (as in the DnDCPMsgHrV4 structure) and we also see a copy-and-paste request packet for our test file debasish.txt on the guest desktop.

RPC packet handling in guest

Let’s look at how the host operating system handles the RPC request. On the host, each running virtual machine has a separate process, vmware-vmx.exe.

When a guest RPC is issued by the guest, code inside vmware-vmx.exe searches the guest RPC handler table for a handler corresponding the request.

If we search the raw string in vmware-vmx.exe disassembled in IDA Pro, we find almost all the handlers.

 

From this, we know vmware-vmx.exe is the main component in the host, responsible for handling the vulnerable component, the copy-and-paste RPC. We next performed a binary “diffing” of the patched and unpatched binaries. The patch was shipped through VMware Workstation Version 12.5.2, so we ran the binary diffing between the vmware-vmx.exe of Version 12.5.2 and 12.5.1.

We can see a few functions in vmware-vmx.exe that were modified by the patch.

One interesting modified function is vmware_vmx!sub_140621520.

 

This function grabbed our attention because it has a call to memcpy(), which is a perfect situation for triggering an out-of-bounds condition.

After running some debugging and reverse engineering, we confirmed the function vmware_vmx!sub_140621520 handles RPC packets, and we were able to control one argument of the modified function from the guest operating system. The argument is a pointer to a structure, giving us control of the content of the passed structure.

The following screenshot demonstrates the statement. The window at left is the guest virtual machine and the window at right is windbg attached with the vmware_vmx.exe process.

In this screen, we have modified an RPC packet in the main vm-tools process vmtoolsd.exe (RpcOut_send) at runtime, and the modified packet is received by the function vmware_vmx!sub_140621520 in the vmware-vmx.exe process.

Now, let’s look at the decompiled source code of our patched function to identify which fixes were added to kill the bug.

To send a valid RPC packet we referred to the source code of VM Tools, which defines the RPC packet structure. The following screen shows the definition of an RPC packet header; we can see the size is exactly 0x38.

 

The fields binarySize and payloadSize are actually the variables v6 and v5 in our decompiled code. We can control the values of these two fields to cause an out-of-bounds access. To send an arbitrary RPC packet from guest to host, we developed a standalone tool that can send an RPC from guest to host via the function Backdoor. After thorough reverse engineering, we found that using the vulnerable function we can achieve an out-of-bounds read/write in the vmware-vmx.exe process.

Out-of-bounds read

As we know, the payloadSize is in our control. If we send a packet with a large payloadSize without a payload buffer, when the program reaches memcpy() it will read some memory out of bounds.

The preceding screen shows the code will copy 0x500-length contents from 0x36E4D96 to 0x378A0D0. However, our data ends only with 0x4C in 0x36E4DB7. The data after 0x36E4DB7 will cause an out-of-bounds read.

Out-of-bounds write

If the RPC message contains multiple packets, we will get into the function sub_1406215F0.

 

To create an out-of-bounds write in the preceding function we have to send more than one RPC packet in one session; then vmware-vmx will create a new buffer to combine the payloads of all packets. After some thorough reverse engineering trials, we conclude that RPC packets with the following characteristics can be sent from guest to host to achieve an out-of-bounds write.

First, we send a drag-and-drop RPC packet with these characteristics:

  • packet->binarySize is 0x10000.
  • packet->payloadOffset is 0x0.
  • packet->payloadSize is 0x500.

With these options, all preceding check conditions are satisfied.

  • packetSize is certainly larger than DND_CP_MSG_HEADERSIZE_V4.
  • packet->payloadSize is less than 0xFF64.
  • packet->binarySize is less than 0x400000.
  • packet->payloadOffset + packet->payloadSize < packet->binarySize.

The procedure will create a new buffer and copy all our packet payloads to it.

Then, we send another packet with the same session ID, in which

  • packet->binarySize is 0x10100.
  • packet->payloadOffset is 0x500.
  • packet->payloadSize is 0xFC00.

These options also satisfy the sanity checks.

  • packetSize is certainly larger than DND_CP_MSG_HEADERSIZE_V4.
  • packet->payloadSize is less than 0xFF64.
  • packet->binarySize is less than 0x400000.
  • packet->payloadOffset + packet->payloadSize < packet->binarySize.

Because this packet has the same session ID as the first packet, and the new buffer is already allocated, the code continues to copy payloads to the current buffer—because 0x500 + 0xFC00 = 0x10100, not 0x10000. This leads to an out-of-bounds write to memory of 0x100 bytes.

The preceding screenshot shows the memory state of the vmware-vmx.exe process before the out-of-bounds write happens.

The preceding screenshot shows the memory state of the vmware-vmx.exe process after the out-of-bounds write, where 0x40E3070 is the memory after the new buffer ends (0x10000). After we sent the second packet, we successfully overwrote 0x100 bytes of memory at 0x40E3070.

 

This post gives a brief overview of the RPC mechanism in VMware Workstation and how the RPC attack surface can be exploited to escape from the guest to the host operating system. In a series of posts, we will discuss each step of this exploitation in detail and demonstrate how these exploits can be chained together to achieve a complete VMware guest-to-host escape.

RPC is not the only vector to attack VMware. In future posts, we will discuss other virtual machine attack surfaces, techniques, and exploits.

 

The authors would like to thank Bing Sun for his valuable assistance throughout this analysis.

The post Analyzing a Patch of a Virtual Machine Escape on VMware appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-patch-of-a-virtual-machine-escape-on-vmware/feed/ 0
‘SSL Death Alert’ (CVE-2016-8610) Can Cause Denial of Service to OpenSSL Servers https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ssl-death-alert-cve-2016-8610-can-cause-denial-of-service-to-openssl-servers/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ssl-death-alert-cve-2016-8610-can-cause-denial-of-service-to-openssl-servers/#respond Wed, 14 Dec 2016 01:13:40 +0000 https://securingtomorrow.mcafee.com/?p=66242 Recently we noticed a security patch has been published for the OpenSSL vulnerability called SSL Death Alert. As with other serious security vulnerabilities, this one grabbed our attention because the discoverer of the vulnerability says that it may cause a denial of service to an OpenSSL web server. To better protect our customers from this […]

The post ‘SSL Death Alert’ (CVE-2016-8610) Can Cause Denial of Service to OpenSSL Servers appeared first on McAfee Blogs.

]]>
Recently we noticed a security patch has been published for the OpenSSL vulnerability called SSL Death Alert. As with other serious security vulnerabilities, this one grabbed our attention because the discoverer of the vulnerability says that it may cause a denial of service to an OpenSSL web server. To better protect our customers from this attack and provide detection and prevention for this vulnerability, the McAfee Labs IPS Vulnerability Research team looked into this issue.

Our analysis started with the patch differences report of the newly pushed code.

2016-12-13-openssl-death-alert-1

As we can see in the diffing results, a couple of files have been modified to fix this problem.

The patch diff of include/openssl/ssl.h reveals the new error code SSL_R_TOO_MANY_WARN_ALERTS (409) has been introduced.

2016-12-13-openssl-death-alert-2

In ssl/record/record_locl.h, we can see the directive MAX_WARN_ALERT_COUNT has been introduced and is set to 5.

2016-12-13-openssl-death-alert-3

Now let’s look into the actual patch, which sits in the files ssl/record/rec_layer_d1.c and ssl/record/rec_layer_s3.c.

The following screen shots show the patch changes in the two files.

ssl/record/rec_layer_d1.c

2016-12-13-openssl-death-alert-4

ssl/record/rec_layer_s3.c

2016-12-13-openssl-death-alert-5

As we can see, the patch is pretty simple and straightforward. It simply counts the layers of consecutive SSL3_AL_WARNING alert packets and checks if the count exceeds five. If the count is greater than five, it raises an error.

Exploiting this issue

To provide detection and prevention for this DoS attack, we created a minimal proof of concept. Although there is no public exploit, the advisory provides a lot of technical details. To exploit this bug, we must initiate the SSL handshake. As a part of the handshake the attacker has to send a genuine Client Hello packet to the server. The following screen shot shows a packet capture of the first stage of the exploit, a normal Client Hello packet.

2016-12-13-openssl-death-alert-6

As described in the security advisory, to exhaust the CPU, we need to send a large number of crafted cleartext SSL3_AL_WARNING alert packets to the server. To do this, we must understand the structure of an alert packet. The message looks like the following, from this TLS protocol memo.

2016-12-13-openssl-death-alert-7

An alert message can be encrypted, but in this case we have to send a cleartext alert to the vulnerable server.

The following screen shot shows captured SSL3_AL_WARNING packets in our test environment.

2016-12-13-openssl-death-alert-8

Next we see multiple alerts packed inside a single record.

2016-12-13-openssl-death-alert-9

The alert packet structure looks like this:

2016-12-13-openssl-death-alert-10

To test the developed exploit, we configured a test server with OpenSSL and self-signed certificate and private key. The following screen shot shows the server listening to port 4433 and communicating with an SSL client.

2016-12-13-openssl-death-alert-11

During normal SSL communications between server and client, we see nothing abnormal with CPU consumption of server processes.

2016-12-13-openssl-death-alert-12

As soon as we run the exploit against the server, however, we immediately see the server process stops responding as CPU usage reaches 99% and then 100% after a few seconds.

2016-12-13-openssl-death-alert-13

The CPU spike causes a denial of service by the OpenSSL Server as it becomes inaccessible. In our test environment, we noticed the SSL service resumes as soon as we stop the exploit from sending malicious packets.

Server administrators should apply the patch to OpenSSL servers as soon as possible. McAfee Network Security Platform (IPS) signature 0x45c09000 provides detection and prevention for this attack.

The post ‘SSL Death Alert’ (CVE-2016-8610) Can Cause Denial of Service to OpenSSL Servers appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/ssl-death-alert-cve-2016-8610-can-cause-denial-of-service-to-openssl-servers/feed/ 0
CVE-2016-0018: DLL Planting Leads to a Remote Code Execution Vulnerability https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cve-2016-0018-dll-planting-leads-to-a-remote-code-execution-vulnerability/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cve-2016-0018-dll-planting-leads-to-a-remote-code-execution-vulnerability/#respond Wed, 27 Apr 2016 18:39:46 +0000 https://blogs.mcafee.com/?p=49116 DLL planting, also known as DLL side loading, is a popular attack technique today. If we take a look at the list of advisories Microsoft has recently published, it is clear that a large number of vulnerabilities encompass DLL planting. We have seen many targeted attacks that abuse Windows OLE in many ways. At BlackHat USA 2015, an […]

The post CVE-2016-0018: DLL Planting Leads to a Remote Code Execution Vulnerability appeared first on McAfee Blogs.

]]>
DLL planting, also known as DLL side loading, is a popular attack technique today. If we take a look at the list of advisories Microsoft has recently published, it is clear that a large number of vulnerabilities encompass DLL planting. We have seen many targeted attacks that abuse Windows OLE in many ways. At BlackHat USA 2015, an McAfee team presented the paper “Attacking Interoperability: an OLE Edition,” which covered various attack techniques and attack surfaces of OLE. In this paper, my colleagues Bing Sun and Haifei Li showcased many interesting vulnerabilities in OLE.

Recently we informed Microsoft of a vulnerability that can be exploited by attackers to perform a DLL side-loading attack. In this case, the vulnerable COM class object ID (CLSID) is {f4ba59cc-2506-45ae-84c8-78ea8d7f9b3e}. This CLSID can be found in the registry at HKEY_CLASSES_ROOT\CLSID\{f4ba59cc-2506-45ae-84c8-78ea8d7f9b3e}. This CLSID’s InprocServer32 key points to the file invagent.dll. A quick Google search reveals this DLL is a part of Windows and is covered by the update KB2976978.

CVE_02016_0018_A_Tale_of_a_windows_library_loading

During our research we found that it is possible to load and initialize this COM object with specially crafted Office document. As proof of concept, we created a Word document with an embedded external OLE object. Opening our Word doc in Office, we see this:

CVE_02016_0018_A_Tale_of_a_windows_library_loading_2

Later we simply patched and changed the CLSID to {f4ba59cc-2506-45ae-84c8-78ea8d7f9b3e}.

CVE_02016_0018_A_Tale_of_a_windows_library_loading_3

Now if we double-click the embedded icon, Office tries to load the OLE object and associated DLLs into the process. One of the DLLs Office tries to load is api-ms-win-core-winrt-l1-1-0.dll. We noticed that if we placed a DLL named api-ms-win-core-winrt-l1-1-0.dll in the same location as the crafted doc, Office simply loads the DLL from the current working directory, allowing us to execute arbitrary code through a planted fake DLL. In Process Monitor, below, we can see that the DLL is loaded from the current working directory.

CVE_02016_0018_A_Tale_of_a_windows_library_loading_4

To prove our point, we compiled a fake api-ms-win-core-winrt-l1-1-0.dll in which DLLMain() executes calc.exe and was placed that DLL in the same folder with the crafted Word doc. As we see in the following screen, as soon as we click on the embedded doc icon, calc.exe pops up.

CVE_02016_0018_A_Tale_of_a_windows_library_loading_5

This same attack can also be performed with a specially crafted rich text format (RTF) document. What’s interesting about an RTF attack is that no user interaction (such as a mouse click) is required to achieve code execution.

CVE_02016_0018_A_Tale_of_a_windows_library_loading_6

The next screen shows the stack trace of the vulnerable LoadLibraryEx() call. As we can see the OLE initialization process started from a call to ole32!OleLoad() -> ole32!CoCreateInstance() and goes on from there.

CVE_02016_0018_A_Tale_of_a_windows_library_loading_7

The next screen shows the disassembly of the vulnerable function invagent!AeInvProvider::AeInvProvider(), in which the insecure library load happens.

CVE_02016_0018_A_Tale_of_a_windows_library_loading_8

Microsoft pushed out a fix for this bug in January, as part of MS16-007 (https://support.microsoft.com/en-us/kb/2952664). As a fix, the dwFlags parameter of the LoadLibraryEx() function was set to 0x800. With this value, only the %windows%\system32 path is searched for the DLLs. The following screen shows the patched function after installing this fix.

CVE_02016_0018_A_Tale_of_a_windows_library_loading_9

For a video demonstration of this attack, click here.

Disclosure time line:
January 8: McAfee reports the issue to Microsoft.
January 9: Automated response from Microsoft.
February 27: Microsoft confirms the issue and informs us a fix was part of Security Bulletin MS16-007 (January’s Patch Tuesday update).
April 21: Microsoft publicly acknowledges our report.

The post CVE-2016-0018: DLL Planting Leads to a Remote Code Execution Vulnerability appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cve-2016-0018-dll-planting-leads-to-a-remote-code-execution-vulnerability/feed/ 0
CVE-2016-0153: Microsoft Patches Possible OLE Typo https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cve-2016-0153-microsoft-patches-possible-ole-typo/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cve-2016-0153-microsoft-patches-possible-ole-typo/#respond Thu, 14 Apr 2016 21:45:11 +0000 https://blogs.mcafee.com/?p=48979 Recently McAfee Labs discovered an interesting bug in Windows’ OLE implementation, which Microsoft patched this week. Now that the patch is available, we can discuss this vulnerability, which resides in the OleRegEnumVerbs() function of ole32.dll. During our research we found that a stack corruption vulnerability in ole32!OleRegEnumVerbs can be triggered if we embed any OLE1 […]

The post CVE-2016-0153: Microsoft Patches Possible OLE Typo appeared first on McAfee Blogs.

]]>
Recently McAfee Labs discovered an interesting bug in Windows’ OLE implementation, which Microsoft patched this week. Now that the patch is available, we can discuss this vulnerability, which resides in the OleRegEnumVerbs() function of ole32.dll.

During our research we found that a stack corruption vulnerability in ole32!OleRegEnumVerbs can be triggered if we embed any OLE1 object into an Office document and try to load it. Whether a class identifier (CLSID) represents an OLE1 class can be determined from the registry.

20160414 OLE typo 1

As we see in the registry editor, HKEY_CLASSES_ROOT\CLSID\{00030000-0000-0000-C000-000000000046} represents an OLE1 object. Hence this CLSID can be used to trigger the bug.

This CLSID was embedded in a Word document. We observed the app crash when an attempt was made to load that OLE object. The stack trace on Windows 8.1 appeared like this:

20160414 OLE typo 2

Using windbg we can see the crash occurred inside the OleRegEnumVerbs() function with the exception code STATUS_STACK_BUFFER_OVERRUN. From this exception code, we can tell this is a stack corruption.

To find the root cause, we took a look at the disassembly of OleRegEnumVerb(). The first thing we see is a call to the CoIsOle1Class() function and the CLSID being passed to it.

20160414 OLE typo 3

According to the Microsoft Developer Network, the CoIsOle1Class() function verifies whether the CLSID passed to it represents an OLE1 object. In this case the CSID we feed into this function does represent an OLE1 object, so the program reaches the following code:

20160414 OLE typo 4

Here we see two calls: ProgIDFromCLSID() and StringCchCopyExW(). In this scenario we are interested in the StringCchCopyExW() call. The developer network tell us the StringCchCopyExW() function basically copies one string to another.

Ret_value = StringCchCopyExW(szKey, 0x100u, psz, &pwszBase, &cchRemain, 0);

In the preceding call:

szKey is the destination buffer

0x100 is the size of the destination buffer

psz is the source string (RegionUsageHeap)

pwszBase is the address of a pointer to the end of szKey

cchRemain is the number of unused characters in szKey

After this call succeeds, the program reaches following code, which is where the bug lies:

20160414 OLE typo 5

As we see, the code subtracts psz from pwszBase. Here pwszBase belongs to the stack, and psz belongs to the heap. Thus the value of pwszBase will less than psz, and the subtraction result (saved into ebx) becomes negative. At runtime, we can see value of ebx becomes 0xf9d93e2c, which points to kernel land.

0:000>? 0x002d9844 – 0x06545a18

Evaluate expression: -103203284 = 0xf9d93e2c

This bug occurs most likely because the developer made a typo. The developer’s intention probably was ebx = pwszBase – szKey, instead of ebx = pwszBase – psz.

Later we see another call to OpenClassesRootKeyExW().If the call is successful, the program tries dereference the corrupted pointer in the stack and write 0x00 there. Thus we see the host application crash.

20160414 OLE typo 6

Under certain circumstance, when the exploit attempt is combined with other vulnerabilities, this flaw can lead to remote code execution.

Vulnerability disclosure timeline

  • January 16: McAfee labs reports issue to Microsoft Security Response Center
  • February 1: MSRC confirms issue.
  • April 12: Microsoft releases patch as part of MS16-044.

 

The post CVE-2016-0153: Microsoft Patches Possible OLE Typo appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cve-2016-0153-microsoft-patches-possible-ole-typo/feed/ 0