Eoin Carroll – McAfee Blogs https://www.mcafee.com/blogs Securing Tomorrow. Today. Tue, 07 Apr 2020 02:55:00 +0000 en-US hourly 1 https://wordpress.org/?v=5.4.1 https://www.mcafee.com/wp-content/uploads/2018/11/cropped-favicon-32x32.png Eoin Carroll – McAfee Blogs https://www.mcafee.com/blogs 32 32 Transitioning to a Mass Remote Workforce – We Must Verify Before Trusting https://www.mcafee.com/blogs/other-blogs/mcafee-labs/transitioning-to-a-mass-remote-workforce-we-must-verify-before-trusting/ https://www.mcafee.com/blogs/other-blogs/mcafee-labs/transitioning-to-a-mass-remote-workforce-we-must-verify-before-trusting/#respond Tue, 07 Apr 2020 13:01:47 +0000 /blogs/?p=99569

While not a new practice, the sheer volume of people required to adhere to social distancing best practices means we now have a mass workforce working remotely. Most enterprises and SMBs can support working remotely today but many IT departments are not equipped to scale to the numbers currently required. In this blog we discuss […]

The post Transitioning to a Mass Remote Workforce – We Must Verify Before Trusting appeared first on McAfee Blogs.

]]>

While not a new practice, the sheer volume of people required to adhere to social distancing best practices means we now have a mass workforce working remotely. Most enterprises and SMBs can support working remotely today but many IT departments are not equipped to scale to the numbers currently required. In this blog we discuss the threats to enterprises and SMBs through this increased remote workforce and how to mitigate the risk.

Cybercriminals seek opportunities to achieve their goals and will follow the path of least resistance. The initial access vectors enumerated in MITRE ATT&CK typically used by cyber criminals are phishing or exploitation of vulnerabilities to gain access to an organization, and are used to act on their malicious objectives. Now that employees have migrated to their homes to work remotely, cybercriminals will target the insecurities of consumer systems and networks to gain access to corporations. As Raj Samani highlighted in a previous post, targeted ransomware attacks are fueling the increased demand in the underground for compromised corporate networks. If employees access corporate networks from pre-infected unmanaged machines without adequate security measures, it creates a much larger attack surface for cybercriminals. This increases the risk of an organization falling victim to a potential breach and ransomware lockdown.

COVID-19 social distancing restrictions came into effect very rapidly, giving organizations little time to prepare for securely managing their workforce remotely. It is important that organizations continue to do business during this tough time, but they must also do it securely to prevent an attack such as ransomware. To protect organizations in this current climate we must approach this from two perspectives:

  1. Know your environment and users
  2. Know your business and real threats

To understand the threats of telecommuting at scale, we must understand the technologies typically used by remote workers to execute their work and access the organization.

Know Your Environment and Users

Per figure 1 below, it is important to understand the architecture and technologies being used by your employees within your business environment. This gives you visibility into your potential exposure based on vulnerabilities being actively exploited by threat actors so that you can protect your remote workers and business infrastructure/assets.

 

Trust boundaries, common technologies and use cases in telecommuter deployments

Know Your Business and Real Threats

Adversary Opportunities

Adversaries need an initial access vector to gain a foothold within an organization. They will typically seek out corporate usernames and passwords using techniques enumerated in MITRE ATT&CK, such as phishing or remote exploitation of software vulnerabilities. The telecommuter technology increases the attack surface significantly and is being exploited/researched as evident below:

Controls

Minimum technical controls for remote worker machines:

  • Secure configuration and strong passwords to prevent router compromise
  • Keep all software layers patched, VPNs and telecommuter applications
  • Do not reuse passwords across personal and work systems
  • Robust endpoint security software

Minimum technical controls for enterprise/SMBs:

  • Security hygiene best practices
  • MFA/2FA and logging for VPN accounts
  • VPN patching
  • Secure RDP access
  • Segmentation of critical business assets
  • Data backups
  • User and device identity for employees and 3rd parties/suppliers

Policies:

  • Data loss prevention
  • Strong passwords
  • SaaS security
  • Managed vs unmanaged device access

Training:

  • Phishing and social engineering training based on the current climate context – “verify before trusting”
  • Keep employees informed of phishing campaigns relative to your environment and business

Conclusion

Strong technical controls are a must to protect telecommuters in the current climate and there is also no substitute for employee phishing and social engineering training as a successful phish can negate technical controls. Even MFA/2FA can be bypassed in some cases, using advanced phishing techniques, so we must all stay vigilant, starting with ourselves to protect our organizations by adopting a “verify before trusting” approach.

The post Transitioning to a Mass Remote Workforce – We Must Verify Before Trusting appeared first on McAfee Blogs.

]]>
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/transitioning-to-a-mass-remote-workforce-we-must-verify-before-trusting/feed/ 0
SMBGhost – Analysis of CVE-2020-0796 https://www.mcafee.com/blogs/other-blogs/mcafee-labs/smbghost-analysis-of-cve-2020-0796/ https://www.mcafee.com/blogs/other-blogs/mcafee-labs/smbghost-analysis-of-cve-2020-0796/#comments Fri, 13 Mar 2020 02:44:01 +0000 /blogs/?p=99084

The Vulnerability The latest vulnerability in SMBv3 is a “wormable” vulnerability given its potential ability to replicate or spread over network shares using the latest version of the protocol (SMB 3.1.1). As of this writing, Microsoft have just released a patch for CVE-2020-0796 on the morning of March 12th. The bug was introduced very recently, […]

The post SMBGhost – Analysis of CVE-2020-0796 appeared first on McAfee Blogs.

]]>

The Vulnerability

The latest vulnerability in SMBv3 is a “wormable” vulnerability given its potential ability to replicate or spread over network shares using the latest version of the protocol (SMB 3.1.1). As of this writing, Microsoft have just released a patch for CVE-2020-0796 on the morning of March 12th. The bug was introduced very recently, in the decompression routines for SMBv3 data payloads. The code implementing this was deployed in April 2019 for Version 1903 and November 2019 for version 1909.

The vulnerability occurs during the processing of a malformed compressed message. The header of the message follows this format: (from [MS-SMB2])

  • There are two parameters in the header that are of interest: OriginalCompressedSegmentSize and Offset/Length
  • The Srv2DecompressData (srv2.sys) function allocates a buffer of size OriginalCompressedSegmentSize + Offset/Length
  • This is not checking the signedness of these values, and as the addition is signed an attacker can allocate a buffer smaller than intended
  • Data is being decompressed at buffer + offset, using data from packet+0x10+offset
  • OriginalCompressedSegmentSize is used as the UncompressedBufferSize parameter passed to SmbCompressionDecompression which is a wrapper for RtlDecompressBufferEx2
  • This routine assumes the uncompressed buffer size to be an unsigned long so a negative value gets cast into a large unsigned number
  • Because of this, the decompression routine decompresses the buffer and can go well beyond the original size, as it is assuming it has a very large buffer to work with

Here’s an annotated disassembly of the relevant function on the server side:

This flaw can affect both client and server in SMB negotiations in a compressed message sent after the Negotiate Protocol Responses. The server vulnerability is within srv2.sys and the client vulnerability is within mrxsmb.sys which both end up calling the same code in SmbCompressDecompress.

Here’s an annotated disassembly of the relevant function on the client side – unlike the server side the OriginalCompressedSegmentSize is bounds checked but there is no check on offset/length before they are combined and passed to ExAllocatePoolWithtag. We have confirmed the BSOD crash from both client->server AND server-client using this vulnerability.

If a computer allows inbound SMB3 traffic over port 445, by default compression is supported and the client and server will negotiate the “terms” of this compression and then the client will proceed to transfer a compressed payload.

The flaw is present in the SMB Compression Transform Header, prior to any kind of authentication.

We can see the very large OriginalSize used for attacker-controlled data (4294967295 is 0xFFFFFFFF in hex which is also -1 if viewed as a signed long). This is copied into a smaller fixed buffer and results in a classic buffer overflow. Of note is the ProtocolID of \xfcSMB, which must be present and represents the magic bytes used to indicate the message must be decompressed per the spec.

However, it is not just the server-side which is vulnerable to this attack. If a client connects to a malicious SMB server, both sides run the same vulnerable code and a malicious server can respond to client requests in the same way to trigger the overflow on the initiator/client side. In this scenario, the Windows Powershell command referenced here will not be effective in stopping this attack against the SMB client. It will only be useful when implemented on the SMB server/recipient side pre-authentication.

Exposure

As always, this kind of patch should be applied as soon as possible, subject to organizational policy. While there are currently no known exploits in the wild, as you will see, causing a BSOD (blue screen of death), is quite trivial, and remains a highly effective attack method for disruption if an attacker can gain access to an internal network.

More dangerous yet are any systems exposing port 445 to the Internet, as we have seen the damage possible through similar bugs such as WannaCry. As of the time of this writing and just prior to Microsoft releasing its patch, Shodan.io appears to have just over 35,000 Windows computers reporting the vulnerable versions of software as searched by: port:445 os: “Windows” + os: “18362” for example. Many of these will likely be patched quickly now that a fix is out.

Patch Analysis

Looking at the patched version, we can see the code is now using RtlULongAdd to add  OriginalCompressedSegmentSize and the Offset/Length value. There also seem to be an extra test to make sure the size is not bigger than the whole packet plus 0x134.

Looking a little further, we can also see the usage of RtULongSub for computing the size of the compressed buffer while accounting for the offset field.

Finally, we can also notice the usage of WPP tracing code in case an error occurs (tracing was already occurring throughout the driver, but this specific function was not previously instrumented in such a way).

Impact – BSOD vs. RCE

Getting a Blue Screen of Death or BSOD is a straightforward exercise. Pivoting from that to full remote code execution will likely be more challenging, as additional bugs will likely be required to bypass Windows’ latest mitigation techniques, such as Kernel ASLR or KASLR. For this bug, the attacker will have easy primitives for the allocation of data and can control the size of the data used to trigger the overflow. On the flip side, the objects allocated in memory to store the attacker input are freed relatively quickly, making exploitation more difficult.

Product Detection/Mitigation

McAfee has released NSP ID 0x43c0e600 – NETBIOS-SS: Samba Remote Code Execution Vulnerability (CVE-2020-0796) to address exploitation of the vulnerability. We are working on developing additional signatures to complement or replace this coverage.

 

The post SMBGhost – Analysis of CVE-2020-0796 appeared first on McAfee Blogs.

]]>
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/smbghost-analysis-of-cve-2020-0796/feed/ 1
The Cloning of The Ring – Who Can Unlock Your Door? https://www.mcafee.com/blogs/other-blogs/mcafee-labs/the-cloning-of-the-ring-who-can-unlock-your-door/ https://www.mcafee.com/blogs/other-blogs/mcafee-labs/the-cloning-of-the-ring-who-can-unlock-your-door/#respond Tue, 07 Jan 2020 05:01:14 +0000 /blogs/?p=97916

Steve Povolny contributed to this report. McAfee’s Advanced Threat Research team performs security analysis of products and technologies across nearly every industry vertical. Special interest in the consumer space and Internet of Things (IoT) led to the discovery of an insecure design with the McLear NFC Ring a household access control device. The NFC Ring […]

The post The Cloning of The Ring – Who Can Unlock Your Door? appeared first on McAfee Blogs.

]]>

Steve Povolny contributed to this report.

McAfee’s Advanced Threat Research team performs security analysis of products and technologies across nearly every industry vertical. Special interest in the consumer space and Internet of Things (IoT) led to the discovery of an insecure design with the McLear NFC Ring a household access control device. The NFC Ring can be used to interact with NFC-enabled door locks which conform to the ISO/IEC 14443A NFC card type. Once the NFC Ring has been paired with the NFC enabled door lock, the user can access their house by simply placing the NFC Ring within NFC range of the door lock.

McLear originally invented the NFC Ring to replace traditional keys with functional jewelry. The NFC Ring uses near field communication (NFC) for access control, to unlock and control mobile devices, share and transfer information, link people and much more. McLear NFC Ring aims to redefine and modernize access control to bring physical household security through convenience. Their latest ring also supports payment capability with McLear Smart Payment Rings, which were not in scope for this research.

Identity is something which uniquely identifies a person or object; an NFC tag is a perfect example of this. Authentication can be generally classified into three types; something you know, something you have and something you are. A NFC Ring is different from the general NFC access tag devices (something you have) as the Ring sits on your finger, so it is a hybrid authentication type of something you have and something you are. This unique combination, as well as the accessibility of a wearable Ring with NFC capabilities sparked our interest in researching this product as an NFC-enabled access control device. Therefore, the focus of our research was on NFC Ring protection against cloning as opposed to the door lock, since NFC access control tags and door locks have been well-researched.

The research and findings for this flaw were reported to McLear on September 25, 2019. To date, McAfee Advanced Threat Research has not received a response from the vendor.

Duplicating Keys Beyond the Hardware Store

In the era of Internet of Things (IoT), the balance between security and convenience is an important factor to get right during the concept phase of a new product and the bill of materials (BOM) selection. The hardware selection is critical as it often determines the security objectives and requirements that can be fulfilled during design and implementation of the product lifecycle. The NFC Ring uses an NFC capable Integrate Circuit (IC) which can be easily cloned and provides no security other than NFC proximity. The NFC protocol does not provide authentication and relies on its operational proximity as a form of protection. The problem with NFC Tags is that they automatically transmit their UID when in range of NFC device reader without any authentication.

Most consumers today use physical keys to secure access to their household door. The physical key security model requires an attacker to get physical access to the key or break the door or door lock. The NFC Ring, if designed securely, would provide equal or greater security than the physical key security model. However, since the NFC Ring can be easily cloned without having to attain physical access to the Ring, it makes the product’s security model less secure than a consumer having a physical key.

In this blog we discuss cloning of the NFC Ring and secure design recommendations to improve its security to a level equal to or greater than existing physical keys.

NFC Ring Security Model and Identity Theft

All McLear non-payment NFC Rings using NTAG216 ICs are impacted by this design flaw. Testing was performed specifically on the OPN which has an NTAG216 IC. The NFC Ring uses the NTAG 216 NFC enabled Integrated Circuit (IC) to provide secure access control by means of NFC communication.

The NFC protocol provides no security as it’s just a transmission mechanism.  The onus is on product owners to responsibly design and implement a security layer to meet the security objectives, capable of thwarting threats identified during the threat modeling phase at concept commit.

The main threats against an NFC access control tag are physical theft and tag cloning by NFC. At a minimum, a tag should be protected against cloning by NFC; with this research, it would ensure the NFC Ring provides the same level of security as a physical key. Ideal security would also protect against cloning even when the NFC Ring has been physically stolen which would provide greater security than that of a physical key.

The NTAG216 IC provide the following security per the NFC Ring spec:

  1. Manufacturer programmed 7-byte UID for each device
  2. Pre-programmed capability container with one-time programmable bits
  3. Field programmable read-only locking function
  4. ECC based originality signature
  5. 32-bit password protection to prevent unauthorized memory operations

The NFC Ring security model is built on the “Manufacturer programmed 7-byte UID for each device” as the Identity and Authentication with the access control principle or door lock. This 7-byte UID (unique identifier) can be read by any NFC enabled device reader such as a proxmark3 or mobile phone when within NFC communication range.

The NFC Ring security model can be broken by any NFC device reader when they come within NFC communication range since the static 7-byte UID is automatically transmitted without any authentication. Once the 7-byte UID has been successfully read, a magic NTAG card can be programmed with the UID, which forms a clone of the NFC Ring and allows an attacker to bypass the secure access control without attaining physical access to the NFC Ring.

The NFC Ring is insecure by design as it relies on the static 7-byte UID programmed at manufacture within the NTAG216 for device identity and authentication purposes. The NFC Ring security model relies on NFC proximity and a static identifier which can be cloned.

In addition, we discovered that the UIDs across NFC Rings maybe predictable (this was a very small sample size of three NFC Rings):

  • NFC Ring#1 UID 04d0e722993c80
  • NFC Ring#2 UID 04d24722993c80
  • NFC Ring#3 UID 04991c4a113c80

There is only a 22-byte difference between the UID of NFC Ring#1 and NFC Ring#2 (0x24-0x0e). By social engineering when a victim purchased their NFC Ring, an attacker could purchase a significant sample size of NFC Rings around the same time and possibly brute force their NFC Ring UID.

Social Engineering

Social Engineering consists of a range of techniques which can be used through human interaction for many malicious purposes such as identity theft. In the case of the NFC Ring the goal is to steal the user’s identity and gain access to their home. Reconnaissance can be performed online to gain background information such as what type of technology is being used by the victim for their home access.

One of the most common exchanges of technology today has become the passing of a phone between two untrusted parties to take a picture. The NFC Ring social engineering attack could be as simple as requesting the victim to take a picture with the attacker-supplied phone. The victim-as-helpful-photographer holds the attacker’s phone, which can read NFC tags and could be equipped with a custom Android app to read the NFC Ring UID, all transparent to the victim while they are snapping away. There is no sign to the victim that their NFC Ring is being read by the phone. It is recorded in the system log and cannot be viewed until a USB cable is attached with required software. Once the Ring is compromised, it can be reprogrammed on a standard writable card, which can be used to unlock smart home locks that partner with this product. The victim’s home is breached.

How It’s Done: NFC Ring Cloning

To successfully clone an NFC Tag, one must first identify the Tag type. This can be done by looking up the product specifications in some cases, or verifying by means of an NFC device reader such as a proxmark3.

From the NFC Ring specs we can determine most of the required tag characteristics:

  1. IC Model: NTAG216
  2. Operating Frequency: 13.56Mhz
  3. ISO/IEC: 14443A
  4. User writable space: 888 bytes
  5. Full specifications

In addition, by communicating with a proxmark3 attackers can physically verify the NFC Tag characteristics and obtain the UID which is required for cloning.

The most straightforward method to stealing the unique identifier of the Ring would be through a mobile phone. The following steps were taken in the below demo:

  1. Reading of NFC Ring with proxmark3 and cloning NTAG21x emulator card
  2. Setting attacker’s phone to silent to prevent NFC Tag detection sound
  3. Running our customized Android app to prevent Android activity popup when NFC Tag detected and read.

Mitigation Secure Design Recommendations

Lock the door. The existing insecure design can be mitigated by using NFC Doorlock password protection in combination with the NFC Ring for two factor authentication.

Authenticate. NFC Ring designers must mandate a secure PKI design with an NFC Tag which contains a crypto module that provides TAG authentication. The NFC Ring secure design must mandate a security layer on top of NFC to access control device manufacturers to ensure secure and trustworthy operation.

Randomize UIDs. In addition, the NFC designers must ensure they are not manufacturing NFC Rings with sequential UIDs which may be predictable with purchase date.

Consumer Awareness

To make customers aware of the security risks associated with products available on the market, product manufacturers should clearly state the level of security which their product provides in comparison with the technology or component they claim to be advancing. Are customers holding the master key to unlock their door, and are there duplicates?

In the case of the NFC Ring, while convenient, it clearly does not provide the same level of security to consumers as a physical key. This decrease in security model from a physical key to a NFC Ring is not due to technology limitations but due to an insecure design.

 

The post The Cloning of The Ring – Who Can Unlock Your Door? appeared first on McAfee Blogs.

]]>
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/the-cloning-of-the-ring-who-can-unlock-your-door/feed/ 0
In NTDLL I Trust – Process Reimaging and Endpoint Security Solution Bypass https://www.mcafee.com/blogs/other-blogs/mcafee-labs/in-ntdll-i-trust-process-reimaging-and-endpoint-security-solution-bypass/ https://www.mcafee.com/blogs/other-blogs/mcafee-labs/in-ntdll-i-trust-process-reimaging-and-endpoint-security-solution-bypass/#respond Thu, 20 Jun 2019 16:00:14 +0000 https://securingtomorrow.mcafee.com/?p=95608

Process Reimaging Overview The Windows Operating System has inconsistencies in how it determines process image FILE_OBJECT locations, which impacts non-EDR (Endpoint Detection and Response) Endpoint Security Solution’s (such as Microsoft Defender Realtime Protection), ability to detect the correct binaries loaded in malicious processes. This inconsistency has led McAfee’s Advanced Threat Research to develop a new […]

The post In NTDLL I Trust – Process Reimaging and Endpoint Security Solution Bypass appeared first on McAfee Blogs.

]]>

Process Reimaging Overview

The Windows Operating System has inconsistencies in how it determines process image FILE_OBJECT locations, which impacts non-EDR (Endpoint Detection and Response) Endpoint Security Solution’s (such as Microsoft Defender Realtime Protection), ability to detect the correct binaries loaded in malicious processes. This inconsistency has led McAfee’s Advanced Threat Research to develop a new post-exploitation evasion technique we call “Process Reimaging”. This technique is equivalent in impact to Process Hollowing or Process Doppelganging within the Mitre Attack Defense Evasion Category; however, it is , much easier to execute as it requires no code injection. While this bypass has been successfully tested against current versions of Microsoft Windows and Defender, it is highly likely that the bypass will work on any endpoint security vendor or product implementing the APIs discussed below.

The Windows Kernel, ntoskrnl.exe, exposes functionality through NTDLL.dll APIs to support User-mode components such as Endpoint Security Solution (ESS) services and processes. One such API is K32GetProcessImageFileName, which allows ESSs to verify a process attribute to determine whether it contains malicious binaries and whether it can be trusted to call into its infrastructure. The Windows Kernel APIs return stale and inconsistent FILE_OBJECT paths, which enable an adversary to bypass Windows operating system process attribute verification. We have developed a proof-of-concept which exploits this FILE_OBJECT location inconsistency by hiding the physical location of a process EXE.

The PoC allowed us to persist a malicious process (post exploitation) which does not get detected by Windows Defender.

The Process Reimaging technique cannot be detected by Windows Defender until it has a signature for the malicious file and blocks it on disk before process creation or performs a full scan on suspect machine post compromise to detect file on disk. In addition to Process Reimaging Weaponization and Protection recommendations, this blog includes a technical deep dive on reversing the Windows Kernel APIs for process attribute verification and Process Reimaging attack vectors. We use the SynAck Ransomware as a case study to illustrate Process Reimaging impact relative to Process Hollowing and Doppelganging; this illustration does not relate to Windows Defender ability to detect Process Hollowing or Doppelganging but the subverting of trust for process attribute verification.

Antivirus Scanner Detection Points

When an Antivirus scanner is active on a system, it will protect against infection by detecting running code which contains malicious content, and by detecting a malicious file at write time or load time.

The actual sequence for loading an image is as follows:

  • FileCreate – the file is opened to be able to be mapped into memory.
  • Section Create – the file is mapped into memory.
  • Cleanup – the file handle is closed, leaving a kernel object which is used for PAGING_IO.
  • ImageLoad – the file is loaded.
  • CloseFile – the file is closed.

If the Antivirus scanner is active at the point of load, it can use any one of the above steps (1,2 and 4) to protect the operating system against malicious code. If the virus scanner is not active when the image is loaded, or it does not contain definitions for the loaded file, it can query the operating system for information about which files make up the process and scan those files. Process Reimaging is a mechanism which circumvents virus scanning at step 4, or when the virus scanner either misses the launch of a process or has inadequate virus definitions at the point of loading.

There is currently no documented method to securely identify the underlying file associated with a running process on windows.

This is due to Windows’ inability to retrieve the correct image filepath from the NTDLL APIs.  This can be shown to evade Defender (MpMsEng.exe/MpEngine.dll) where the file being executed is a “Potentially Unwanted Program” such as mimikatz.exe. If Defender is enabled during the launch of mimikatz, it detects at phase 1 or 2 correctly.  If Defender is not enabled, or if the launched program is not recognized by its current signature files, then the file is allowed to launch. Once Defender is enabled, or the signatures are updated to include detection, then Defender uses K32GetProcessImageFileName to identify the underlying file. If the process has been created using our Process Reimaging technique, then the running malware is no longer detected. Therefore, any security service auditing running programs will fail to identify the files associated with the running process.

Subverting Trust

The Mitre ATT&CK model specifies post-exploitation tactics and techniques used by adversaries, based on real-world observations for Windows, Linux and macOS Endpoints per figure 1 below.

Figure 1 – Mitre Enterprise ATT&CK

Once an adversary gains code execution on an endpoint, before lateral movement, they will seek to gain persistence, privilege escalation and defense evasion capabilities. They can achieve defense evasion using process manipulation techniques to get code executing in a trusted process. Process manipulation techniques have existed for a long time and evolved from Process Injection to Hollowing and Doppelganging with the objective of impersonating trusted processes. There are other Process manipulation techniques as documented by Mitre ATT&CK and Unprotect Project,  but we will focus on Process Hollowing and Process Doppelganging. Process manipulation techniques exploit legitimate features of the Windows Operating System to impersonate trusted process executable binaries and generally require code injection.

ESSs place inherent trust in the Windows Operating System for capabilities such as digital signature validation and process attribute verification. As demonstrated by Specter Ops, ESSs’ trust in the Windows Operating system could be subverted for digital signature validation.

Similarly, Process Reimaging subverts an ESSs’ trust in the Windows Operating System for process attribute verification.

When a process is trusted by an ESS, it is perceived to contain no malicious code and may also be trusted to call into the ESS trusted infrastructure.

McAfee ATR uses the Mitre ATT&CK framework to map adversarial techniques, such as defense evasion, with associated campaigns. This insight helps organizations understand adversaries’ behavior and evolution so that they can assess their security posture and respond appropriately to contain and eradicate attacks. McAfee ATR creates and shares Yara rules based on threat analysis to be consumed for protect and detect capabilities.

Process Manipulation Techniques (SynAck Ransomware)

McAfee Advanced Threat Research analyzed SynAck ransomware in 2018 and discovered it used Process Doppelganging with Process Hollowing as its fallback defense evasion technique. We use this malware to explain the Process Hollowing and Process Doppelganging techniques, so that they can be compared to Process Reimaging based on a real-world observation.

Process Manipulation defense evasion techniques continue to evolve. Process Doppelganging was publicly announced in 2017, requiring advancements in ESSs for protection and detection capabilities. Because process manipulation techniques generally exploit legitimate features of the Windows Operating system they can be difficult to defend against if the Antivirus scanner does not block prior to process launch.

Process Hollowing

Process hollowing occurs when a process is created in a suspended state then its memory is unmapped and replaced with malicious code. Execution of the malicious code is masked under a legitimate process and may evade defenses and detection analysis” (see figure 2 below)

Figure 2 – SynAck Ransomware Defense Evasion with Process Hollowing

Process Doppelganging

Process Doppelgänging involves replacing the memory of a legitimate process, enabling the veiled execution of malicious code that may evade defenses and detection. Process Doppelgänging’s use of Windows Transactional NTFS (TxF) also avoids the use of highly-monitored API functions such as NtUnmapViewOfSection, VirtualProtectEx, and SetThreadContext” (see figure 3 below)

Figure 3 – SynAck Ransomware Defense Evasion with Doppleganging

Process Reimaging Weaponization

The Windows Kernel APIs return stale and inconsistent FILE_OBJECT paths which enable an adversary to bypass windows operating system process attribute verification. This allows an adversary to persist a malicious process (post exploitation) by hiding the physical location of a process EXE (see figure 4 below).

Figure 4 – SynAck Ransomware Defense Evasion with Process Reimaging

Process Reimaging Technical Deep Dive

NtQueryInformationProcess retrieves all process information from EPROCESS structure fields in the kernel and NtQueryVirtualMemory retrieves information from the Virtual Address Descriptors (VADs) field in EPROCESS structure.

The EPROCESS structure contains filename and path information at the following fields/offsets (see figure 5 below):

  • +0x3b8 SectionObject (filename and path)
  • +0x448 ImageFilePointer* (filename and path)
  • +0x450 ImageFileName (filename)
  • +0x468 SeAuditProcessCreationInfo (filename and path)

* this field is only present in Windows 10

Figure 5 – Code Complexity IDA Graph Displaying NtQueryInformationProcess Filename APIs within NTDLL

Kernel API NtQueryInformationProcess is consumed by following the kernelbase/NTDLL APIs:

  • K32GetModuleFileNameEx
  • K32GetProcessImageFileName
  • QueryFullProcessImageImageFileName

The VADs hold a pointer to FILE_OBJECT for all mapped images in the process, which contains the filename and filepath (see figure 6 below).

Kernel API NtQueryVirtualMemory is consumed by following the kernelbase/NTDLL API:

  • GetMappedFileName

Figure 6 – Code Complexity IDA Graph Displaying NtQueryVirtualMemory Filename API within NTDLL

Windows fails to update any of the above kernel structure fields when a FILE_OBJECT filepath is modified post-process creation. Windows does update FILE_OBJECT filename changes, for some of the above fields.

The VADs reflect any filename change for a loaded image after process creation, but they don’t reflect any rename of the filepath.

The EPROCESS fields also fail to reflect any renaming of the process filepath and only the ImageFilePointer field reflects a filename change.

As a result, the APIs exported by NtQueryInformationProcess and NtQueryVirtualMemory return incorrect process image file information when called by ESSs or other Applications (see Table 1 below).

Table 1 OS/Kernel version and API Matrix

Prerequisites for all Attack Vectors

Process Reimaging targets the post-exploitation phase, whereby a threat actor has already gained access to the target system. This is the same prerequisite of Process Hollowing or Doppelganging techniques within the Defense Evasion category of the Mitre ATT&CK framework.

Process Reimaging Attack Vectors
FILE_OBJECT Filepath Changes

Simply renaming the filepath of an executing process results in Windows OS returning the incorrect image location information for all APIs (See figure 7 below).  This impacts all Windows OS versions at the time of testing.

Figure 7 FILE_OBJECT Filepath Changes – Filepath Changes Impact all Windows OS versions

FILE_OBJECT Filename Changes

Filename Change >= Windows 10

Simply renaming the filename of an executing process results in Windows OS returning the incorrect image information for K32GetProcessImageFileName API (See figure 8.1.1 below). This has been confirmed to impact Windows 10 only.

Figure 8.1.1 FILE_OBJECT Filename Changes – Filename Changes impact Windows >= Windows 10

Per figure 8.1.2 below, GetModuleFileNameEx and QueryFullProcessImageImageFileName will get the correct filename changes due to a new EPROCESS field ImageFilePointer at offset 448.  The instruction there (mov r12, [rbx+448h]) references the ImageFilePointer from offset 448 into the EPROCESS structure.

Figure 8.1.2 NtQueryInformationProcess (Windows 10) – Windows 10 RS1 x64 ntoskrnl version 10.0.14393.0

Filename Change < Windows 10

Simply renaming the filename of an executing process results in Windows OS returning the incorrect image information for K32GetProcessImageFileName, GetModuleFileNameEx and QueryFullProcessImageImageFileName APIs (See figure 8.2.1 below). This has been confirmed to impact Windows 7 and Windows 8.

Figure 8.2.1 FILE_OBJECT Filename Changes – Filename Changes Impact Windows < Windows 10

Per Figure8.2.2 below, GetModuleFileNameEx and QueryFullProcessImageImageFileName will get the incorrect filename (PsReferenceProcessFilePointer references EPROCESS offset 0x3b8 SectionObject).

Figure 8.2.2 NtQueryInformationProcess (Windows 7 and 8) – Windows 7 SP1 x64 ntoskrnl version 6.1.7601.17514

LoadLibrary FILE_OBJECT reuse

LoadLibrary FILE_OBJECT reuse leverages the fact that when a LoadLibrary or CreateProcess is called after a LoadLibrary and FreeLibrary on an EXE or DLL, the process reuses the existing image FILE_OBJECT in memory from the prior LoadLibrary.

Exact Sequence is:

  1. LoadLibrary (path\filename)
  2. FreeLibrary (path\filename)
  3. LoadLibrary (renamed path\filename) or CreateProcess (renamed path\filename)

This results in Windows creating a VAD entry in the process at step 3 above, which reuses the same FILE_OBJECT still in process memory, created from step 1 above. The VAD now has incorrect filepath information for the file on disk and therefore the GetMappedFileName API will return the incorrect location on disk for the image in question.

The following prerequisites are required to evade detection successfully:

  • The LoadLibrary or CreateProcess must use the exact same file on disk as the initial LoadLibrary
  • Filepath must be renamed (dropping the same file into a newly created path will not work)

The Process Reimaging technique can be used in two ways with LoadLibrary FILE_OBJECT reuse attack vector:

  1. LoadLibrary (see figure 9 below)
    1. When an ESS or Application calls the GetMappedFileName API to retrieve a memory-mapped image file, Process Reimaging will cause Windows OS to return the incorrect path. This impacts all Windows OS versions at the time of testing.

Figure 9 LoadLibrary FILE_OBJECT Reuse (LoadLibrary) – Process Reimaging Technique Using LoadLibrary Impacts all Windows OS Versions

2. CreateProcess (See figure 10 below)

    1. When an ESS or Application calls the GetMappedFileName API to retrieve the process image file, Process Reimaging will cause Windows OS to return the incorrect path. This impacts all Windows OS versions at the time of testing.

Figure 10 LoadLibrary FILE_OBJECT Reuse (CreateProcess) – Process Reimaging Technique using CreateProcess Impacts all Windows OS Versions

Process Manipulation Techniques Comparison

Windows Defender Process Reimaging Filepath Bypass Demo

This video simulates a zero-day malware being dropped (Mimikatz PUP sample) to disk and executed as the malicious process “phase1.exe”. Using the Process Reimaging Filepath attack vector we demonstrate that even if Defender is updated with a signature for the malware on disk it will not detect the running malicious process. Therefore, for non-EDR ESSs such as Defender Real-time Protection (used by Consumers and also Enterprises) the malicious process can dwell on a windows machine until a reboot or the machine receives a full scan post signature update.

CVSS and Protection Recommendations

CVSS

If a product uses any of the APIs listed in table 1 for the following use cases, then it is likely vulnerable:

  1. Process reputation of a remote process – any product using the APIs to determine if executing code is from a malicious file on disk

CVSS score 5.0 (Medium)  https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N (same score as Doppelganging)

  1. Trust verification of a remote process – any product using the APIs to verify trust of a calling process

CVSS score will be higher than 5.0; scoring specific to Endpoint Security Solution architecture

Protection Recommendations

McAfee Advanced Threat Research submitted Process Reimaging technique to Microsoft on June 5th, 2018. Microsoft released a partial mitigation to Defender in the June 2019 Cumulative update for the Process Reimaging FILE_OBJECT filename changes attack vector only. This update was only for Windows 10 and does not address the vulnerable APIs in Table 1 at the OS level; therefore, ESSs are still vulnerable to Process Reimaging. Defender also remains vulnerable to the FILE_OBJECT filepath changes attack vector executed in the bypass demo video, and this attack vector affects all Windows OS versions.

New and existing Process Manipulation techniques which abuse legitimate Operating System features for defense evasion are difficult to prevent dynamically by monitoring specific API calls as it can lead to false positives such as preventing legitimate processes from executing.

A process which has been manipulated by Process Reimaging will be trusted by the ESS unless it has been traced by EDR or a memory scan which may provide deeper insight.

Mitigations recommended to Microsoft
  1. File System Synchronization (EPROCESS structures out of sync with the filesystem or File Control Block structure (FCB)
    1. Allow the EPROCESS structure fields to reflect filepath changes as is currently implemented for the filename in the VADs and EPROCESS ImageFilePointer fields.
    2. There are other EPROCESS fields which do not reflect changes to filenames and need to be updated, such as K32GetModuleFileNameEx on Windows 10 through the ImageFilePointer.
  2. API Usage (most returning file info for process creation time)
    1. Defender (MpEngine.dll) currently uses K32GetProcessImageFileName to get process image filename and path when it should be using K32GetModuleFileNameEx.
    2. Consolidate the duplicate APIs being exposed from NtQueryInformationProcess to provide easier management and guidance to consumers that require retrieving process filename information. For example, clearly state GetMappedFileName should only be used for DLLs and not EXE backing process).
    3. Differentiate in API description whether the API is only limited to retrieving the filename and path at process creation or real-time at time of request.
  3. Filepath Locking
    1. Lock filepath and name similar to lock file modification when a process is executing to prevent modification.
    2. Standard user at a minimum should not be able to rename binary paths for its associated executing process.
  4. Reuse of existing FILE_OBJECT with LoadLibrary API (Prevent Process Reimaging)
    1. LoadLibrary should verify any existing FILE_OBJECT it reuses, has the most up to date Filepath at load time.
  5. Short term mitigation is that Defender should at least flag that it found malicious process activity but couldn’t find associated malicious file on disk (right now it fails open, providing no notification as to any potential threats found in memory or disk).
Mitigation recommended to Endpoint Security Vendors

The FILE_OBJECT ID must be tracked from FileCreate as the process closes its handle for the filename by the time the image is loaded at ImageLoad.

This ID must be managed by the Endpoint Security Vendor so that it can be leveraged to determine if a process has been reimaged when performing process attribute verification.

The post In NTDLL I Trust – Process Reimaging and Endpoint Security Solution Bypass appeared first on McAfee Blogs.

]]>
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/in-ntdll-i-trust-process-reimaging-and-endpoint-security-solution-bypass/feed/ 0
RDP Stands for “Really DO Patch!” – Understanding the Wormable RDP Vulnerability CVE-2019-0708 https://www.mcafee.com/blogs/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/ https://www.mcafee.com/blogs/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/#respond Tue, 21 May 2019 21:09:35 +0000 https://securingtomorrow.mcafee.com/?p=95306

During Microsoft’s May Patch Tuesday cycle, a security advisory was released for a vulnerability in the Remote Desktop Protocol (RDP). What was unique in this particular patch cycle was that Microsoft produced a fix for Windows XP and several other operating systems, which have not been supported for security updates in years. So why the […]

The post RDP Stands for “Really DO Patch!” – Understanding the Wormable RDP Vulnerability CVE-2019-0708 appeared first on McAfee Blogs.

]]>

During Microsoft’s May Patch Tuesday cycle, a security advisory was released for a vulnerability in the Remote Desktop Protocol (RDP). What was unique in this particular patch cycle was that Microsoft produced a fix for Windows XP and several other operating systems, which have not been supported for security updates in years. So why the urgency and what made Microsoft decide that this was a high risk and critical patch?

According to the advisory, the issue discovered was serious enough that it led to Remote Code Execution and was wormable, meaning it could spread automatically on unprotected systems. The bulletin referenced well-known network worm “WannaCry” which was heavily exploited just a couple of months after Microsoft released MS17-010 as a patch for the related vulnerability in March 2017. McAfee Advanced Threat Research has been analyzing this latest bug to help prevent a similar scenario and we are urging those with unpatched and affected systems to apply the patch for CVE-2019-0708 as soon as possible. It is extremely likely malicious actors have weaponized this bug and exploitation attempts will likely be observed in the wild in the very near future.

Vulnerable Operating Systems:

  • Windows 2003
  • Windows XP
  • Windows 7
  • Windows Server 2008
  • Windows Server 2008 R2

Worms are viruses which primarily replicate on networks. A worm will typically execute itself automatically on a remote machine without any extra help from a user. If a virus’ primary attack vector is via the network, then it should be classified as a worm.

The Remote Desktop Protocol (RDP) enables connection between a client and endpoint, defining the data communicated between them in virtual channels. Virtual channels are bidirectional data pipes which enable the extension of RDP. Windows Server 2000 defined 32 Static Virtual Channels (SVCs) with RDP 5.1, but due to limitations on the number of channels further defined Dynamic Virtual Channels (DVCs), which are contained within a dedicated SVC. SVCs are created at the start of a session and remain until session termination, unlike DVCs which are created and torn down on demand.

It’s this 32 SVC binding which CVE-2019-0708 patch fixes within the _IcaBindVirtualChannels and _IcaRebindVirtualChannels functions in the RDP driver termdd.sys. As can been seen in figure 1, the RDP Connection Sequence connections are initiated and channels setup prior to Security Commencement, which enables CVE-2019-0708 to be wormable since it can self-propagate over the network once it discovers open port 3389.

 

Figure 1: RDP Protocol Sequence

The vulnerability is due to the “MS_T120” SVC name being bound as a reference channel to the number 31 during the GCC Conference Initialization sequence of the RDP protocol. This channel name is used internally by Microsoft and there are no apparent legitimate use cases for a client to request connection over an SVC named “MS_T120.”

Figure 2 shows legitimate channel requests during the GCC Conference Initialization sequence with no MS_T120 channel.

Figure 2: Standard GCC Conference Initialization Sequence

However, during GCC Conference Initialization, the Client supplies the channel name which is not whitelisted by the server, meaning an attacker can setup another SVC named “MS_T120” on a channel other than 31. It’s the use of MS_T120 in a channel other than 31 that leads to heap memory corruption and remote code execution (RCE).

Figure 3 shows an abnormal channel request during the GCC Conference Initialization sequence with “MS_T120” channel on channel number 4.

 

Figure 3: Abnormal/Suspicious GCC Conference Initialization Sequence – MS_T120 on nonstandard channel

The components involved in the MS_T120 channel management are highlighted in figure 4. The MS_T120 reference channel is created in the rdpwsx.dll and the heap pool allocated in rdpwp.sys. The heap corruption happens in termdd.sys when the MS_T120 reference channel is processed within the context of a channel index other than 31.

Figure 4: Windows Kernel and User Components

The Microsoft patch as shown in figure 5 now adds a check for a client connection request using channel name “MS_T120” and ensures it binds to channel 31 only (1Fh) in the _IcaBindVirtualChannels and _IcaRebindVirtualChannels functions within termdd.sys.

 

Figure 5: Microsoft Patch Adding Channel Binding Check

After we investigated the patch being applied for both Windows 2003 and XP and understood how the RDP protocol was parsed before and after patch, we decided to test and create a Proof-of-Concept (PoC) that would use the vulnerability and remotely execute code on a victim’s machine to launch the calculator application, a well-known litmus test for remote code execution.

Figure 6: Screenshot of our PoC executing

For our setup, RDP was running on the machine and we confirmed we had the unpatched versions running on the test setup. The result of our exploit can be viewed in the following video:

There is a gray area to responsible disclosure. With our investigation we can confirm that the exploit is working and that it is possible to remotely execute code on a vulnerable system without authentication. Network Level Authentication should be effective to stop this exploit if enabled; however, if an attacker has credentials, they will bypass this step.

As a patch is available, we decided not to provide earlier in-depth detail about the exploit or publicly release a proof of concept. That would, in our opinion, not be responsible and may further the interests of malicious adversaries.

Recommendations:

  • We can confirm that a patched system will stop the exploit and highly recommend patching as soon as possible.
  • Disable RDP from outside of your network and limit it internally; disable entirely if not needed. The exploit is not successful when RDP is disabled.
  • Client requests with “MS_T120” on any channel other than 31 during GCC Conference Initialization sequence of the RDP protocol should be blocked unless there is evidence for legitimate use case.

 

It is important to note as well that the RDP default port can be changed in a registry field, and after a reboot will be tied the newly specified port. From a detection standpoint this is highly relevant.

Figure 7: RDP default port can be modified in the registry

Malware or administrators inside of a corporation can change this with admin rights (or with a program that bypasses UAC) and write this new port in the registry; if the system is not patched the vulnerability will still be exploitable over the unique port.

McAfee Customers:

McAfee NSP customers are protected via the following signature released on 5/21/2019:

0x47900c00 “RDP: Microsoft Remote Desktop MS_T120 Channel Bind Attempt”

If you have any questions, please contact McAfee Technical Support.

 

The post RDP Stands for “Really DO Patch!” – Understanding the Wormable RDP Vulnerability CVE-2019-0708 appeared first on McAfee Blogs.

]]>
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/feed/ 0
IE Scripting Flaw Still a Threat to Unpatched Systems: Analyzing CVE-2018-8653 https://www.mcafee.com/blogs/other-blogs/mcafee-labs/ie-scripting-flaw-still-a-threat-to-unpatched-systems-analyzing-cve-2018-8653/ https://www.mcafee.com/blogs/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://www.mcafee.com/blogs/other-blogs/mcafee-labs/ie-scripting-flaw-still-a-threat-to-unpatched-systems-analyzing-cve-2018-8653/feed/ 0