IE Scripting Flaw Still a Threat to Unpatched Systems: Analyzing CVE-2018-8653

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.

Ryuk Ransomware Attack: Rush to Attribution Misses the Point

Senior analyst Ryan Sherstobitoff contributed to this report. During the past week, an outbreak of Ryuk ransomware that impeded newspaper printing services in the United States has garnered a lot of attention. To determine who was behind the attack many have cited past research that compares code from Ryuk with the older ransomware Hermes to […]

The post Ryuk Ransomware Attack: Rush to Attribution Misses the Point appeared first on McAfee Blogs.

Senior analyst Ryan Sherstobitoff contributed to this report.

During the past week, an outbreak of Ryuk ransomware that impeded newspaper printing services in the United States has garnered a lot of attention. To determine who was behind the attack many have cited past research that compares code from Ryuk with the older ransomware Hermes to link the attack to North Korea. Determining attribution was largely based on the fact that the Hermes ransomware has been used in the past by North Korean actors, and code blocks in Ryuk are similar to those in Hermes.

The McAfee Advanced Threat Research team has investigated this incident and determined how the malware works, how the attackers operate, and how to detect it. Based on the technical indicators, known cybercriminal characteristics, and evidence discovered on the dark web, our hypothesis is that the Ryuk attacks may not necessarily be backed by a nation-state, but rather share the hallmarks of a cybercrime operation.

How McAfee approaches attribution

Attribution is a critical part of any cybercrime investigation. However, technical evidence is often not enough to positively identify who is behind an attack because it does not provide all the pieces of the puzzle. Artifacts do not all appear at once; a new piece of evidence unearthed years after an attack can shine a different light on an investigation and introduce new challenges to current assumptions.

Ryuk attack: putting the pieces together

In October 2017, we investigated an attack on a Taiwanese bank. We discovered the actors used a clever tactic to distract the IT staff: a ransomware outbreak timed for the same moment that the thieves were stealing money. We used the term pseudo-ransomware to describe this attack. The malware was Hermes version 2.1.

One of the functions we often see in ransomware samples is that they will not execute if the victim’s system language is one of the following:

  • 419 (Russian)
  • 422 (Ukrainian)
  • 423 (Belarusian)

That was October 2017. Searching earlier events, we noticed a posting from August 2017 in an underground forum in which a Russian-speaking actor offered the malware kit Hermes 2.1 ransomware:

What if the actor who attacked the Taiwanese bank simply bought a copy of Hermes and added it to the campaign to cause the distraction? Why go to the trouble to build something, when the actor can just buy the perfect distraction in an underground forum?

In the same underground forum thread we found a post from October 22, 2018, mentioning Ryuk.

This post contains a link to an article in the Russian security magazine Xakep.ru (“Hacker”) discussing the emergence of Ryuk and how it was first discovered by MalwareHunterTeam in August 2018. This first appearance came well before last week’s attack on newspaper printing services.

Manga connection

Ryuk, according to Wikipedia, refers to a Japanese manga character from the series “Death Note.” Ryuk apparently drops a death note, a fitting name for ransomware that drops ransom notes.

Ransomware is typically named by its cybercriminal developer, as opposed to the naming of state-sponsored malware, which is mostly is done by the security industry. It seems the criminals behind Ryuk are into manga.

The use of manga character names and references is common in the cybercriminal scene. We often come across manga-inspired nicknames and avatars in underground forums.

Technical indicators

Looking at research from our industry peers comparing Ryuk and Hermes, we notice that the functionalities are generally equal. We agree that the actors behind Ryuk have access to the Hermes source code.

Let’s dive a bit deeper into Ryuk and compare samples over the last couple of months regarding compilation times and the presence of program database (PDB) paths:

We can see the PDB paths are almost identical. When we compare samples from August and December 2018 and focus on the checksum values of the executables’ rich headers, they are also identical.

From a call-flow perspective, we notice the similarities and evolution of the code:

The Hermes 2.1 ransomware kit, renamed and redistributed as Ryuk.

The author and seller of Hermes 2.1 emphasizes that he is selling is a kit and not a service. This suggests that a buyer of the kit must do some fine tuning by setting up a distribution method (spam, exploit kit, or RDP, for example) and infrastructure to make Hermes work effectively. If changing a name and ransom note are part of these tuning options, then it is likely that Ryuk is an altered version Hermes 2.1.

Attribution: analyzing competing hypotheses

In the race to determine who is behind an attack, research facts (the What and How questions) are often put aside to focus on attribution (the Who question). Who did it? This pursuit is understandable yet fundamentally flawed. Attribution is crucial, but there will always be unanswered questions. Our approach focuses on answering the What and How questions by analyzing the malware, the infrastructure involved, and the incident response performed at the victim’s site.

Our approach is always to analyze competing hypotheses. When investigating an incident, we form several views and compare all the artifacts to support these hypotheses. We try not only to seek verifying evidence but also actively try to find evidence that falsifies a hypothesis. Keeping our eyes open for falsifying facts and constantly questioning our results are essential steps to avoid conformation bias. By following this method, we find the strongest hypothesis is not the one with the most verifying evidence, but the one with the least falsifying evidence.

Examining competing hypotheses is a scientific approach to investigating cyber incidents. It may not help with the race to attribution, but it ensures the output is based on available evidence.

The most likely hypothesis in the Ryuk case is that of a cybercrime operation developed from a tool kit offered by a Russian-speaking actor. From the evidence, we see sample similarities over the past several months that indicate a tool kit is being used. The actors have targeted several sectors and have asked a high ransom, 500 Bitcoin. Who is responsible? We do not know. But we do know how the malware works, how the attackers operate, and how to detect the threat. That analysis is essential because it allows us to serve our customers.

The post Ryuk Ransomware Attack: Rush to Attribution Misses the Point appeared first on McAfee Blogs.

McAfee Labs Threats Report Examines Cybercriminal Underground, IoT Malware, Other Threats

The McAfee Advanced Threat Research team today published the McAfee® Labs Threats Report, December 2018. In this edition, we highlight the notable investigative research and trends in threats statistics and observations gathered by the McAfee Advanced Threat Research and McAfee Labs teams in Q3 of 2018. We are very excited to present to you new […]

The post McAfee Labs Threats Report Examines Cybercriminal Underground, IoT Malware, Other Threats appeared first on McAfee Blogs.

The McAfee Advanced Threat Research team today published the McAfee® Labs Threats Report, December 2018. In this edition, we highlight the notable investigative research and trends in threats statistics and observations gathered by the McAfee Advanced Threat Research and McAfee Labs teams in Q3 of 2018.

We are very excited to present to you new insights and a new format in this report. We are dedicated to listening to our customers to determine what you find important and how we can add value. In recent months we have gathered more threat intelligence, correlating and analyzing data to provide more useful insights into what is happening in the evolving threat landscape. McAfee is collaborating closely with MITRE Corporation in extending the techniques of its MITRE ATT&CK™ knowledge base, and we now include the model in our report. We are always working to refine our process and reports. You can expect more from us, and we welcome your feedback.

As we dissect the threat landscape for Q3, some noticeable statistics jump out of the report.  In particular, the continued rise in cryptojacking, which has made an unexpected emergence over the course of a year. In Q3 the growth of coin miner malware returned to unprecedented levels after a temporary slowdown in Q2.

Our analysis of recent threats included one notable introduction in a disturbing category. In Q3 we saw two new exploit kits: Fallout and Underminer. Fallout almost certainly had a bearing on the spread of GandCrab, the leading ransomware. Five years ago we published the report “Cybercrime Exposed,” which detailed the rise of cybercrime as a service. Exploit kits are the epitome of this economy, affording anyone the opportunity to easily and cheaply enter the digital crime business.

New malware samples jumped up again in Q3 after a decline during the last two quarters. Although the upward trend applies to almost every category, we did measure a decline in new mobile malware samples following three quarters of continual growth.

This post is only a small snapshot of the comprehensive analysis provided in the December Threats Report. We hope you enjoy the new format, and we welcome your feedback.

The post McAfee Labs Threats Report Examines Cybercriminal Underground, IoT Malware, Other Threats appeared first on McAfee Blogs.

‘Operation Sharpshooter’ Targets Global Defense, Critical Infrastructure

This post was written with contributions from the McAfee Advanced Threat Research team.   The McAfee Advanced Threat Research team and McAfee Labs Malware Operations Group have discovered a new global campaign targeting nuclear, defense, energy, and financial companies, based on McAfee® Global Threat Intelligence. This campaign, Operation Sharpshooter, leverages an in-memory implant to download […]

The post ‘Operation Sharpshooter’ Targets Global Defense, Critical Infrastructure appeared first on McAfee Blogs.

This post was written with contributions from the McAfee Advanced Threat Research team.  

The McAfee Advanced Threat Research team and McAfee Labs Malware Operations Group have discovered a new global campaign targeting nuclear, defense, energy, and financial companies, based on McAfee® Global Threat Intelligence. This campaign, Operation Sharpshooter, leverages an in-memory implant to download and retrieve a second-stage implant—which we call Rising Sun—for further exploitation. According to our analysis, the Rising Sun implant uses source code from the Lazarus Group’s 2015 backdoor Trojan Duuzer in a new framework to infiltrate these key industries.

Operation Sharpshooter’s numerous technical links to the Lazarus Group seem too obvious to immediately draw the conclusion that they are responsible for the attacks, and instead indicate a potential for false flags. Our research focuses on how this actor operates, the global impact, and how to detect the attack. We shall leave attribution to the broader security community.

Read our full analysis of Operation Sharpshooter.

Have we seen this before?

This campaign, while masquerading as legitimate industry job recruitment activity, gathers information to monitor for potential exploitation. Our analysis also indicates similar techniques associated with other job recruitment campaigns.

Global impact

In October and November 2018, the Rising Sun implant has appeared in 87 organizations across the globe, predominantly in the United States, based on McAfee telemetry and our analysis. Based on other campaigns with similar behavior, most of the targeted organizations are English speaking or have an English-speaking regional office. This actor has used recruiting as a lure to collect information about targeted individuals of interest or organizations that manage data related to the industries of interest. The McAfee Advanced Threat Research team has observed that the majority of targets were defense and government-related organizations.

Targeted organizations by sector in October 2018. Colors indicate the most prominently affected sector in each country. Source: McAfee® Global Threat Intelligence.

Infection flow of the Rising Sun implant, which eventually sends data to the attacker’s control servers.

 

Conclusion

Our discovery of this new, high-function implant is another example of how targeted attacks attempt to gain intelligence. The malware moves in several steps. The initial attack vector is a document that contains a weaponized macro to download the next stage, which runs in memory and gathers intelligence. The victim’s data is sent to a control server for monitoring by the actors, who then determine the next steps.

We have not previously observed this implant. Based on our telemetry, we discovered that multiple victims from different industry sectors around the world have reported these indicators.

Was this attack just a first-stage reconnaissance operation, or will there be more? We will continue to monitor this campaign and will report further when we or others in the security industry receive more information. The McAfee Advanced Threat Research team encourages our peers to share their insights and attribution of who is responsible for Operation Sharpshooter.

 

Indicators of compromise

MITRE ATT&CK™ techniques

  • Account discovery
  • File and directory discovery
  • Process discovery
  • System network configuration discovery
  • System information discovery
  • System network connections discovery
  • System time discovery
  • Automated exfiltration
  • Data encrypted
  • Exfiltration over command and control channel
  • Commonly used port
  • Process injection

Hashes

  • 8106a30bd35526bded384627d8eebce15da35d17
  • 66776c50bcc79bbcecdbe99960e6ee39c8a31181
  • 668b0df94c6d12ae86711ce24ce79dbe0ee2d463
  • 9b0f22e129c73ce4c21be4122182f6dcbc351c95
  • 31e79093d452426247a56ca0eff860b0ecc86009

Control servers

  • 214.99.20/view_style.php
  • 74.41.56/board.php
  • com.sg/board.php

Document URLs

  • hxxp://208.117.44.112/document/Strategic Planning Manager.doc
  • hxxp://208.117.44.112/document/Business Intelligence Administrator.doc
  • hxxp://www.dropbox.com/s/2shp23ogs113hnd/Customer Service Representative.doc?dl=1

McAfee detection

  • RDN/Generic Downloader.x
  • Rising-Sun
  • Rising-Sun-DOC

 

The post ‘Operation Sharpshooter’ Targets Global Defense, Critical Infrastructure appeared first on McAfee Blogs.