ICS-CERT Releases WannaCry Fact Sheet

Original release date: May 17, 2017 | Last revised: May 19, 2017

The Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) has released a short overview of the WannaCry ransomware infections. This fact sheet provides information on how the WannaCry program spreads, what users should do if they have been infected, and how to protect against similar attacks in the future.

US-CERT encourages users and administrators to review the ICS-CERT Fact Sheet on WannaCry and the US-CERT Current Activity on the topic. For more technical details, please consult TA17-132A, Indicators Associated With WannaCry Ransomware.


This product is provided subject to this Notification and this Privacy & Use policy.


How to Protect Against WannaCry Ransomware in a McAfee Environment

WannaCry is a ransomware family targeting Microsoft Windows. On Friday May 12, a large cyberattack based on this threat was launched. At this time, it is estimated that more than 250,000 computers in 150 countries have been infected, each demanding a ransom payment.

The initial attack vector is unclear, but an aggressive worm helps spread the ransomware. A critical patch was released by Microsoft on March 14 to remove the underlying vulnerability in supported versions of Windows, but many organizations have not yet applied this patch.

Computers running unsupported versions of Windows (Windows XP, Windows Server 2003) did not have an available patch, but Microsoft released a security patch for Windows XP and Windows Serve 2003 over the weekend.

Detailed technical analyses of the WannaCry ransomware can be found here (posted May 12) and here (May 14).

 

How McAfee products can protect against WannaCry ransomware

McAfee is leading the way enterprises protect against emerging threats such as WannaCry ransomware, remediate complex security issues, and combat attacks with an intelligent end-to-end security platform that provides adaptable and continuous protection as a part of the threat defense lifecycle.

McAfee had zero-day protection for components of the initial WannaCry attack in the form of behavioral, heuristic, application control, and sandbox analyses. This post provides an overview of those protections with the following products:

  • McAfee Network Security Platform (NSP)
  • McAfee Host Intrusion Prevention (HIPS)
  • McAfee Endpoint Protection (ENS)
  • McAfee VirusScan Enterprise (VSE)
  • McAfee Advanced Threat Defense (ATD)
  • McAfee Web Gateway (MWG)
  • McAfee Threat Intelligence Exchange (TIE)

Frequently updated technical details can be found in the McAfee Knowledge Center article KB89335.

 

McAfee Network Security Platform (NSP)

McAfee NSP is one product that quickly responds to prevent exploits and protect assets within networks. The McAfee NSP team works diligently to develop and deploy user-defined signatures (UDS) for critical matters. Within a 24-hour period, several UDS were created and uploaded for customers to deploy on their network sensors. In this case, the UDS explicitly targeted the exploit tools EternalBlue, Eternal Romance SMB Remote Code Execution, and DoublePulsar. There were also related indicators of compromise that were released which could be added to a blacklist to block potential threats associated with the original Trojan.

NSP signatures:

  • 0x43c0b800—NETBIOS-SS: Windows SMBv1 identical MID and FID type confusion vulnerability (CVE-2017-0143)
  • 0x43c0b400—NETBIOS-SS: Windows SMB Remote Code Execution Vulnerability (CVE-2017-0144)
  • 0x43c0b500—NETBIOS-SS: Windows SMB Remote Code Execution Vulnerability (CVE-2017-0145)
  • 0x43c0b300—NETBIOS-SS: Microsoft Windows SMB Out of Bounds Write Vulnerability (CVE-2017-0146)
  • 0x43c0b900—NETBIOS-SS: Windows SMBv1 Information Disclosure Vulnerability (CVE-2017-0147)

The NSP Research Team has reviewed the information for CVE-2017-0148 and has created the following UDS:

  • NETBIOS-SS: MS17-010 EternalBlue SMB Remote Code Execution
  • NETBIOS-SS: SMB DoublePulsar Unimplemented Trans2 Session Setup Subcommand Request
  • HTTP: Windows Kernel Information Disclosure Vulnerability (CVE-2017-0175)
  • HTTP: Microsoft Windows Edge IE Mixed Content Warnings Bypass Vulnerability (CVE-2017-0064)
  • HTTP: Microsoft Scripting Engine Memory Corruption Vulnerability (CVE-2017-0234)
  • HTTP: Microsoft Scripting Engine Memory Corruption Vulnerability (CVE-2017-0236)

The UDS is available from KB55447 only for registered users. Log in to https://support.mcafee.com to access the article.

 

McAfee Host Intrusion Prevention (HIPS)

McAfee HIPS 8.0 with NIPS Signature 6095 (which will be released on May 16), provides protection against all four of the preceding known variants of WannaCry.

For the interim period, HIPS custom signatures can be created to protect against the encryption of files. Refer to KB89335 for the latest information on these configurations.

Custom Sig #1: WannaCry Registry Blocking Rule

Use Standard Subrule

Rule Type = Registry

Operations = Create, Modify, Change Permissions

Parameters, include Registry Key

Registry Key =  \REGISTRY\MACHINE\SOFTWARE\WanaCrypt0r

Executable = *

Custom Sig #2: WannaCry File/Folder Blocking Rule

Use Standard Subrule

Rule Type = Files

Operations = Create, Write, Rename, Change read-only/hidden attributes,

Parameters, include Files

Files = *.wnry

Executable = *

 

McAfee Endpoint Protection (ENS) and McAfee VirusScan Enterprise (VSE)

McAfee recommends the following Adaptive Threat Protection configurations to protect against the WannaCry exploit and unknown variants.

 

McAfee Endpoint Security 10.5—Adaptive Threat Protection

McAfee Endpoint Security 10.5 with Adaptive Threat Protection Real Protect & Dynamic Application Containment (DAC) provides protection against known or unknown exploits for WannaCry.

  1. Configure the following setting in the Adaptive Threat Protection—Options Policy:

Rule Assignment = Security (default setting is balanced)

  1. Configure the following rules in the Adaptive Threat Protection—Dynamic Application Containment policy:

Dynamic Application Containment—Containment Rules

(Refer to KB87843–Best Practices for ENS Dynamic Application Containment Rules and set the recommended DAC rules to “Block” as prescribed.)

 

Content Dependent Security Products

McAfee Endpoint Security 10.1, 10.2, and 10.5—Threat Prevention

McAfee Endpoint Security 10.x Threat Prevention with AMCore content Version 2978 or later provides protection against all four of the preceding currently known variants of WannaCry.

 

McAfee VirusScan Enterprise 8.8

McAfee VirusScan Enterprise 8.8 with DAT content 8527 or later provides protection against all four of the preceding currently known variants of WannaCry.

 

McAfee Endpoint Protection (ENS) and McAfee VirusScan Enterprise (VSE) Access Protection proactive measures

The McAfee ENS and McAfee VSE Access Protection rules will prevent the creation of the .wnry file. This rule prevents the encryption routine, which creates encrypted files that contain a .wncryt, .wncry, or .wcry extension. By implementing the block against .wnry files, other blocks are not necessary for the encrypted file types.

Use McAfee VSE Access Protection rules:

Rule1:

Rule Type: Registry Blocking Rule
Process to include: *
Registry key or value to protect: HKLM—/Software/WanaCrypt0r
Registry key or value p protect: Key
File actions to prevent: Create key or value.

Rule2:

Rule Type: File/Folder Blocking Rule
Process to include: *
File or folder name to block: *.wnry
File actions to prevent: New files being created

Use McAfee ENS Access Protection rules:

Rule1:

Executable1:

Inclusion: Include
File Name or Path: *

SubRule1:

SubRule Type: Registry key
Operations: Create
Target1:

Inclusion: Include
File, folder name, or file path: *\Software\WanaCrypt0r

SubRule2:

SubRule Type: Files
Operations: Create
Target1:

Inclusion: Include
File, folder name, or file path: *.wnry

McAfee ENS Dynamic Application Containment rules triggered by Ransom-WannaCry variants:

Rule1:

Rule Name: Executing any child process

Rule2:

Rule Name: Accessing user cookie locations

Rule3:

Rule Name: Creating files with the .html, .jpg, or .bmp extension

Rule4:

Rule Name: Creating files with the .exe extension

Rule5:

Rule Name: Modifying users’ data folders

Rule6:

Rule Name: Modifying startup registry locations

Rule7:

Rule Name: Modifying critical Windows files and registry locations

Rule8:

Rule Name: Reading or modifying files on any network location

Rule9:

Rule Name: Modifying files with the .bat extension

Rule10:

Rule Name: Modifying files with the .vbs extension

Rule11:

Rule Name: Creating files with the .bat extension

Rule12:

Rule Name: Reading files commonly targeted by ransomware-class malware

Rule13:

Rule Name: Creating files on any network location

Rule14:

Rule Name: Writing to files commonly targeted by ransomware-class malware

Rule15:

Rule Name: Modifying the hidden attribute bit

 

Configure your endpoint security system to protect against file encryption from WannaCry (and future unknown variants)

Customers not using McAfee ENS Adaptive Threat Protection security may not have McAfee-defined content protection against not yet released variants. We recommend configuring repository update tasks with a minimal refresh interval to ensure new content is applied when it is released by McAfee.

Additional protections against the encryption routine can be configured using McAfee VSE/ENS Access Protection rules, or McAfee HIPS custom rules. Refer to KB89335 for the latest information on these configurations.

McAfee VSE and McAfee ENS Access Protection rules, and McAfee HIPS customer signature will prevent the creation of the .wnry file.

The rules prevent the encryption routine, which creates encrypted files that contain a .wncryt, .wncry, or .wcry extension.

By implementing the block against .wnry, other blocks are not necessary for the encrypted file types.

Refer to KB89335 (accessible to McAfee registered customers) for the latest information on these configurations.

 

McAfee Advanced Threat Defense (ATD)

McAfee ATD machine learning can convict a sample on a “medium severity” analysis.

McAfee ATD has observed the following:

Behavior classification:

  • Obfuscated file
  • Spreading
  • Exploitation through shellcode
  • Network propagation

Dynamic analysis:

  • Elicited ransomware behavior
  • Encryption of files
  • Created and executed suspicious scripting content
  • Behaved like a Trojan macro dropper

McAfee ATD observed 22 process operations, including five runtime DLLs, 58 file operations, registry modifications, file modifications, file creations (dll.exe), DLL injections, and 34 network operations.

Further analysis continues on other variants. McAfee is identifying what other behaviors can be extracted to detect future attacks.

 

McAfee Web Gateway (MWG)

McAfee Web Gateway (MWG) is a product family (appliance, cloud, and hybrid) of web proxies that provides immediate protection against WannaCry variants delivered through the web (HTTP/HTTPS) using multiple real-time scanning engines.

Known variants will be blocked by McAfee Global Threat Intelligence (GTI) reputation and antimalware scanning as web traffic is processed through the proxy.

The Gateway Anti-Malware (GAM) engine within MWG provides effective prevention of variants that have not yet been identified with a signature (“zero-day” threats) through its process of behavior emulation, conducted on files, HTML, and JavaScript. Emulators are regularly fed intelligence by machine learning models. GAM runs alongside GTI reputation and antimalware scanning as traffic is processed.

Coupling MWG with ATD allows for further inspection and an effective prevention and detection approach.

 

McAfee Threat Intelligence Exchange (TIE)

McAfee Threat Intelligence Exchange (TIE) further enhances a customer’s security posture. With the ability to aggregate reputation verdicts from ENS, VSE, MWG, and NSP, TIE can quickly share reputation information related to WannaCry with any integrated vector. By providing the ability to use GTI for a global reputation query, TIE also enables integrated products to make an immediate decision prior to execution of the ransomware payload, leveraging the reputation cached in the TIE database.

As one endpoint protects, detects from any related variants, and updates the reputation score to TIE, this fully encompassing approach extends protection to endpoints by disseminating this information to all endpoints integrated with TIE. This bidirectional sharing of threat intelligence is duplicated in capability with MWG and NSP. Thus, as the potential threat attempts to infiltrate through the network or web, MWG and NSP will provide protection and detection and share this intelligence with TIE to inoculate endpoints—immediately protecting the enterprise with no further execution of the convicted variant on a potential “patient zero” in the environment.

 

 

 

The post How to Protect Against WannaCry Ransomware in a McAfee Environment appeared first on McAfee Blogs.

Further hardening glibc malloc() against single byte overflows

Introduction

Back in 2014, while at Project Zero, I exploited a buffer overflow of a single NUL byte in glibc. Tavis Ormandy had found the interesting glibc vulnerability but there was skepticism in the Linux community that this was exploitable. The only thing to do was to write an exploit. (Was this really 3 years ago? How time flies!)

As part of warming up to write the exploit, I created a few sample test C files which explored different interesting glibc malloc() side effects after an off-by-one NUL byte write. You can find them here. The exploit abused a situation similar to consolidate_forward.c, but did not thoroughly need to defeat ASLR because the target platform was 32-bit.

I also noted a curiosity for future research in shrink_free_hole_alloc_overlap_consolidate_backward.c: there's a possible sequence triggered by a NUL byte overwrite whereby ASLR can be cleanly defeated to leave aliased heap chunks. The C file is commented if you want to see how the sequence works.

Interestingly enough, this technique turned up in a December 2016 Project Zero guest post describing a Chrome OS exploit chain. In a fantastic piece of work, attributed anonymously, a single byte overflow of the value x01 is used to fully defeat ASLR and eventually achieve code execution in a 64-bit x86_64 process.

I've been thinking about ways to kill this technique for a while now: it's far too powerful if it can reliably defeat ASLR in a 64-bit process. I also worry that many of the super serious Linux daemon bugs remaining are likely to be of the subtle type, i.e. one byte overflows.

Inline vs. out-of-line metadata

It's time for a brief foray into memory allocator design.

  • glibc malloc. glibc malloc is based on dlmalloc, which has an inline metadata design. Specifically, every buffer handed out to the program is preceded by a little piece of metadata indicating the size of the chunk and whether the previous chunk is free or not.
  • tcmalloc. tcmalloc is an allocator that has a largely out-of-line metadata design, on account of being a bucketing allocator for smaller sizes and a page based allocator for larger sizes. However, the internal metadata for this allocator is mixed in with pages handed out as buffers to the calling program. This was hardened a while ago by Justin Schuh for the Google Chrome web browser; not sure it made it upstream.
  • PartitionAlloc. PartitionAlloc, part of the Google Chrome web browser. It has an out-of-line metadata design such that heap metadata is partitioned or guard paged off from the calling program's buffers. The notable exception, shared with tcmalloc, is freelist pointers, which occupy the freed slots. In PartitionAlloc, freelist pointers are transformed so that dereferencing them faults, and partial pointer overwrites are thwarted.

While writing PartitionAlloc, strictly protected heap metadata was a goal. After all, if the metadata is naturally guarded with guard pages then there's less need for code defenses which are trying to detect and stop bad side effects from metadata corruption. Simplicity wins.

However, there's an interesting interaction with single byte overflows that provides pause for thought and philosophizing.

With an out-of-line metadata design, a single byte overflow off the end of a chunk will hit the first byte of some other chunk. Depending on the different object types that could be in the adjacent chunk, that's potentially a lot of possibilities for the attacker to explore.

With an inline metadata design, a single byte overflow off the end of a chunk will hit some metadata. Depending on the level of metadata corruption checks present, the single byte overflow could be dead in the water as an attacker primitive. However, on the flipside, there's also the possibility for more generic attacks against the metadata, such as the one we are patching up here.

Hardening against the glibc malloc() ASLR defeat

This is one of those cases where a relatively simple patch pops out, but only after some careful thought and analysis.

In this case, the key observation is that there are two linkages between heap chunks in glibc malloc():

  • Freelist pointers. These are doubly linked and the double linkage is already validated. Since pointer values are a "secret" before ASLR is defeated, the attacker cannot fake pointer values before they have defeated ASLR.
  • Lengths. There is also length linkage. For a free chunk, the length is present at both the beginning and the end of the chunk, to enable chunk traversal. Unfortunately, an attacker can craft a fake length easily and problems arise specifically when these lengths are modified to point to valid metadata structures, but not the "correct" metadata structure. Previously there was no length linkage validation.
The solution used was to also validate length linkage when unlinking chunks. It was checked in a while ago, here: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=17f487b7afa7cd6c316040f3e6c86dc96b2eec30

Now, if the attacker has an off-by-one corruption with a small value (NUL or x01 - x07) that hits the lowest significant byte of a length (malloc_chunk->size), the attacker can only use that to cause the length to effectively shrink. This is because all heap chunks are at least 8 bytes under the covers. Shrinking a chunk's length means it will never match the prev_size stored at the end of that chunk. Even if the attacker deploys their one byte overflow multiple times, this new check should always catch them.

If an attacker has an arbitrary linear overwrite, they could corrupt both size and prev_size to match, but with that powerful primitive, there would likely be other more fruitful ways forward.

Conclusion

Did we finally nail off-by-one NUL byte overwrites in the glibc heap? Only time will tell!

Further hardening glibc malloc() against single byte overflows

Introduction

Back in 2014, while at Project Zero, I exploited a buffer overflow of a single NUL byte in glibc. Tavis Ormandy had found the interesting glibc vulnerability but there was skepticism in the Linux community that this was exploitable. The only thing to do was to write an exploit. (Was this really 3 years ago? How time flies!)

As part of warming up to write the exploit, I created a few sample test C files which explored different interesting glibc malloc() side effects after an off-by-one NUL byte write. You can find them here. The exploit abused a situation similar to consolidate_forward.c, but did not thoroughly need to defeat ASLR because the target platform was 32-bit.

I also noted a curiosity for future research in shrink_free_hole_alloc_overlap_consolidate_backward.c: there's a possible sequence triggered by a NUL byte overwrite whereby ASLR can be cleanly defeated to leave aliased heap chunks. The C file is commented if you want to see how the sequence works.

Interestingly enough, this technique turned up in a December 2016 Project Zero guest post describing a Chrome OS exploit chain. In a fantastic piece of work, attributed anonymously, a single byte overflow of the value \x01 is used to fully defeat ASLR and eventually achieve code execution in a 64-bit x86_64 process.

I've been thinking about ways to kill this technique for a while now: it's far too powerful if it can reliably defeat ASLR in a 64-bit process. I also worry that many of the super serious Linux daemon bugs remaining are likely to be of the subtle type, i.e. one byte overflows.

Inline vs. out-of-line metadata

It's time for a brief foray into memory allocator design.

  • glibc malloc. glibc malloc is based on dlmalloc, which has an inline metadata design. Specifically, every buffer handed out to the program is preceded by a little piece of metadata indicating the size of the chunk and whether the previous chunk is free or not.
  • tcmalloc. tcmalloc is an allocator that has a largely out-of-line metadata design, on account of being a bucketing allocator for smaller sizes and a page based allocator for larger sizes. However, the internal metadata for this allocator is mixed in with pages handed out as buffers to the calling program. This was hardened a while ago by Justin Schuh for the Google Chrome web browser; not sure it made it upstream.
  • PartitionAlloc. PartitionAlloc, part of the Google Chrome web browser. It has an out-of-line metadata design such that heap metadata is partitioned or guard paged off from the calling program's buffers. The notable exception, shared with tcmalloc, is freelist pointers, which occupy the freed slots. In PartitionAlloc, freelist pointers are transformed so that dereferencing them faults, and partial pointer overwrites are thwarted.

While writing PartitionAlloc, strictly protected heap metadata was a goal. After all, if the metadata is naturally guarded with guard pages then there's less need for code defenses which are trying to detect and stop bad side effects from metadata corruption. Simplicity wins.

However, there's an interesting interaction with single byte overflows that provides pause for thought and philosophizing.

With an out-of-line metadata design, a single byte overflow off the end of a chunk will hit the first byte of some other chunk. Depending on the different object types that could be in the adjacent chunk, that's potentially a lot of possibilities for the attacker to explore.

With an inline metadata design, a single byte overflow off the end of a chunk will hit some metadata. Depending on the level of metadata corruption checks present, the single byte overflow could be dead in the water as an attacker primitive. However, on the flipside, there's also the possibility for more generic attacks against the metadata, such as the one we are patching up here.

Hardening against the glibc malloc() ASLR defeat

This is one of those cases where a relatively simple patch pops out, but only after some careful thought and analysis.

In this case, the key observation is that there are two linkages between heap chunks in glibc malloc():

  • Freelist pointers. These are doubly linked and the double linkage is already validated. Since pointer values are a "secret" before ASLR is defeated, the attacker cannot fake pointer values before they have defeated ASLR.
  • Lengths. There is also length linkage. For a free chunk, the length is present at both the beginning and the end of the chunk, to enable chunk traversal. Unfortunately, an attacker can craft a fake length easily and problems arise specifically when these lengths are modified to point to valid metadata structures, but not the "correct" metadata structure. Previously there was no length linkage validation.
The solution used was to also validate length linkage when unlinking chunks. It was checked in a while ago, here: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=17f487b7afa7cd6c316040f3e6c86dc96b2eec30

Now, if the attacker has an off-by-one corruption with a small value (NUL or \x01 - \x07) that hits the lowest significant byte of a length (malloc_chunk->size), the attacker can only use that to cause the length to effectively shrink. This is because all heap chunks are at least 8 bytes under the covers. Shrinking a chunk's length means it will never match the prev_size stored at the end of that chunk. Even if the attacker deploys their one byte overflow multiple times, this new check should always catch them.

If an attacker has an arbitrary linear overwrite, they could corrupt both size and prev_size to match, but with that powerful primitive, there would likely be other more fruitful ways forward.

Conclusion

Did we finally nail off-by-one NUL byte overwrites in the glibc heap? Only time will tell!