The McAfee Advanced Threat Research team today published the McAfee® Labs COVID-19 Threats Report, July 2020.

In this “Special Edition” threat report, we delve deep into the COVID-19 related attacks observed by our McAfee Advanced Threats Research and McAfee Labs teams in the first quarter of 2020 and the early months of the pandemic.

What started as a trickle of phishing campaigns and the occasional malicious app quickly turned to thousands of malicious URLs and more-than-capable threat actors leveraging our thirst for more information as an entry mechanism into systems across the world.

Thus far, the dominant themes of the 2020 threat landscape have been cybercriminal’s quick adaptation to exploit the pandemic and the considerable impact cyberattacks have had. For example, many ransomware attacks have escalated into data breaches as cybercriminals up the ante by leaking sensitive, often regulated, data, regardless of whether victims have paid the ransom.

Some of the other significant threat findings in our COVID-19 report include:

• Average of 375 threats per minute in Q1 2020
• Nearly 47% of all publicly disclosed security incidents took place in the United States
• New PowerShell Malware increased drastically
• Disclosed incidents largely targeted Public, Individual, and Education sectors

In a first, we also have made available a COVID-19 dashboard to complement this threat report and extend its impact beyond the publication date. Timeliness is a challenge for publishing any threat report, but through the development of MVISION Insights our threat reports will include a link to another live dashboard tracking the world’s top threats. We will also make available the IOCs, Yara rules, and mapping to the MITRE ATT&CK framework as part of our continuing commitment to sharing our actionable intelligence. I hope these McAfee resources will be useful to you, the reader.

As we head into the second half of the year, we must consider how the threat landscape has changed when we address and define each attack. Simply assigning a technical descriptor or reverting to the same attack classifications fail to communicate the impact such campaigns have on the broader society.

All too often, we are called into investigations where businesses have been halted, or victims have lost considerable sums of money. While we all have had to contend with pandemic lockdown, criminals of all manner of capability have had a field day.

We hope you enjoy these new threat report approaches, and moreover we would appreciate you sharing these findings far and wide. These tools and insights could be the difference between a business remaining operational or having to shut its doors at a time when we have enough challenges to contend with.

The post McAfee COVID-19 Report Reveals Pandemic Threat Evolution appeared first on McAfee Blog.

Windows Subsystem for Linux Plan 9 Protocol Research Overview

This is the final blog in the McAfee research series trilogy on the Windows Subsystem for Linux (WSL) implementation – see The Twin Journey (part 1) and Knock, Knock–Who’s There (part 2). The previous research discussed file evasion attacks when the Microsoft P9 server can be hijacked with a malicious P9 (Plan 9 File System Protocol) server. Since Windows 10 version 1903, it is possible to access Linux files from Windows by using the P9 protocol. The Windows 10 operating system comes with the P9 server as part of the WSL install so that it can communicate with a Linux filesystem. In this research we explore the P9 protocol implementation within the Windows kernel and whether we could execute code in it from a malicious P9 server. We created a malicious P9 server by hijacking the Microsoft P9 server and replacing it with code we can control.

In a typical attack scenario, we discovered that if WSL is enabled on Windows 10, then a non-privileged local attacker can hijack the WSL P9 communication channel to cause a local Denial of Service (DoS) or Blue Screen of Death (BSOD) in the Windows kernel. It is not possible to achieve escalation of privilege (EoP) within the Windows kernel due to this vulnerability; the BSOD appears to be as designed by Microsoft within their legitimate fail flow, if malformed P9 server communication packets are received by the Windows kernel. A non-privileged user should not be able to BSOD the Windows kernel, from a local or remote perspective. If WSL is not enabled (disabled by default on Windows 10), the attack can still be executed but requires the attacker to be a privileged user to enable WSL as a pre-requisite.

There have recently been some critical, wormable protocol vulnerabilities within the RDP and SMB protocols in the form of Bluekeep and SMBGhost. Remotely exploitable vulnerabilities are very high risk if they are wormable as they can spread across systems without any user interaction. Local vulnerabilities are lower risk since an attacker must first have a presence on the system; in this case they must have a malicious P9 server executing. The P9 protocol implementation runs locally within the Windows kernel so the objective, as with most local vulnerability hunting, is to find a vulnerability that allows an escalation of privilege (EoP).

In this blog we do a deep dive into the protocol implementation and vulnerability hunting process. There is no risk to WSL users from this research, which has been shared with and validated by Microsoft. We hope this research will help improve understanding of the WSL P9 communications stack and that additional research would be more fruitful further up the stack.

There have been some exploits on WSL such as here and here but there appears to be no documented research of the P9 protocol implementation other than this.

P9 Protocol Overview

The Plan 9 File System Protocol server allows a client to navigate its file system to create, remove, read and write files. The client sends requests (T-messages) to the server and the server responds with R-messages. The P9 protocol has a header consisting of size, type and tag fields which is followed by a message type field depending on the request from the client. The R-message type sent by the server must match the T-message type initiated from the client. The maximum connection size for the data transfer is decided by the client during connection setup; in our analysis below, it is 0x10000 bytes.

P9 protocol header followed by message type union (we have only included the subset of P9 message types which are of interest for vulnerability research):

The P9 T-message and corresponding R-message numbers for the types we are interested in (the R-message is always T-message+1):

At the message type layer, which follows the P9 protocol header, you can see the fields, which are of variable size, highlighted below:

Based on the packet structure of the P9 protocol we need to hunt for message type confusion and memory corruption vulnerabilities such as out of bounds read/write.

So, what will a packet structure look like in memory? Figure 1 shows the protocol header and message type memory layout from WinDbg. The message size (msize) is negotiated to 0x10000 and the version string is “9P2000.W”.

Figure 1. P9 packet for rversion message type

Windows WSL P9 Communication Stack and Data Structures

Figure 2. Windows Plan 9 File System Protocol Implementation within WSL

The p9rdr.sys network mini-redirector driver registers the “\\Device\\P9Rdr” device with the Redirected Drive Buffering Subsystem (RDBSS) using the RxRegisterMinirdr API as part of the p9rdr DriverEntry routine. During this registration, the following P9 APIs or driver routines are exposed to the RDBSS:

The p9rdr driver is not directly accessible from user mode using the DeviceIoControl API and all calls must go through the RDBSS.

As seen in Figure 2, when a user navigates to the WSL share at “\\wsl$” from Explorer, the RDBSS driver calls into the P9 driver through the previously registered APIs.

DIOD is a file server implementation, that we modified to be a “malicious” P9 server, where we claim the “fsserver” socket name prior to the Windows OS in a form of squatting attack. Once we replaced the Microsoft P9 server with the DIOD server, we modified the “np_req_respond” function (explained in the fuzzing constraints section) so that we could control P9 packets to send malicious responses to the Windows kernel. Our malicious P9 server and socket hijacking have been explained in detail here.

So now we know how data travels from Explorer to the P9 driver but how does the P9 driver communicate with the malicious P9 server? They communicate over AF_UNIX sockets.

There are two important data structures used for controlling data flow within the P9 driver called P9Client and P9Exchange.

The P9Client and P9Exchange data structures, when reverse engineered to the fields relevant to this research, look like the following (fields not relevant to this analysis have been labelled as UINT64 for alignment):

P9Client data structure memory layout in WinDbg:

The P9Exchange data structure layout in WinDbg:

To communicate with the P9 server, the P9 driver creates an I/O request packet (IRP) to receive data from the Winsock Kernel (WSK). An important point to note is that the Memory Descriptor List (MDL) used to hold the data passed between the P9 server and Windows kernel P9 client is 0x10000 bytes (the max connection size mentioned earlier).

The MDL is mapped to the P9PacketStart field address within the P9Client data structure.

On IRP completion, the WskTransport::SendReceiveComplete completion routine is called to retrieve the P9Client structure from the IRP to process the P9 packet response from the server:

The P9Client data structure is used within an IRP to receive the R-message data but what is the purpose of the P9Exchange data structure?

1. When the P9 driver sends a T-message to the server, it must create an exchange so that it can track the state between the message type sent (T-message) and that returned by the server (R-Message).
2. It contains lambda functions to execute on the specific message type. The Tmessage_type field within the P9Exchange data structure ensures that the server can only send R-messages to the same T-message type it received from the P9 driver.
3. PRX_CONTEXT * RxContext structure is used to transfer data between Explorer and the p9rdr driver via the RDBSS driver.

The flow of a WALK T-message can be seen below:

Within the P9Client::CreateExchange function, the MidExchangeManager::RegisterExchange is responsible for registering the P9Exchange data structure with the RDBSS using a multiplex ID (MID) to distinguish between concurrent server and client requests.

The important fields within the P9Client and P9Exchange data structures which we will discuss further during the analysis:

1. PClient->MaxConnectionSize – set at the start of the connection and cannot be controlled by an attacker
2. P9Client->P9PacketStart – points to P9 packet received and can be fully controlled by an attacker
3. P9Client->Rmessage_size –can be fully controlled by an attacker
4. P9Exchange->Tmessage_type – set during T-message creation and cannot be controlled by an attacker
5. P9Exchange->RxContext – used to pass data from P9 driver through the RDBSS to Explorer

Now that we know how the protocol works within the Windows kernel, the next stage is vulnerability hunting.

Windows Kernel P9 Server Vulnerability Hunting

P9 Packet Processing Logic

From a vulnerability perspective we want to audit the Windows kernel logic within p9rdr.sys, responsible for parsing traffic from the malicious P9 server. Figure 3 shows the source of the P9 packet and the sink, or where the packet processing completes within the p9rdr driver.

Figure 3. Windows Kernel Processing layers for the P9 protocol malicious server response parsing

Now that we have identified the code for parsing the P9 protocol message types of interest we need to audit the code for message type confusion and memory corruption vulnerabilities such as out of bounds read/write and overflows.

Fuzzing constraints

There were a number of constraints which made deploying automated fuzzing logic difficult:

1. The R-message type sent from the malicious P9 server must match the T-message type sent by the Windows kernel
2. Timeouts in higher layers of the WSL stack

The above challenges could, however, be overcome but since the protocol is relatively simple we decided to focus on reversing the processing logic validation. To verify the processing logic validation, we created some manual fuzzing capability within the malicious P9 server to test the variable length packet field boundaries identified from the protocol overview.

Below is an example RREAD R-message type which sends a malicious P9 packet in response to an RREAD T-message where we control the count and data variable length fields.

Validation Checks

The data passed to the P9 driver is contained within a connection memory allocation of 0x10000 bytes (P9Client->P9PacketStart) and most of the processing is done within this memory allocation, with two exceptions where memmove is called within the P9Client::FillData and P9Client::Lambda_2275 functions (discussed below).

A message-type confusion attack is not possible since the P9Exchange data structure tracks the R-message to its corresponding T-message type.

In addition, the P9 driver uses a span reader to process message type fields of static length. The P9Exchange structure stores the message type which is used to determine the number of fields within a message during processing.

While we can control the P9 packet size we cannot control the P9Client->MaxConnectionSize which means messages greater than or equal to 0x10000 will be dropped.

All variable size field checks within the message type layer of the protocol are checked against the P9Packet size field ensuring that a malicious field will not result in out of bounds read or write access outside of the 0x10000 connection memory allocation.

The processing logic functions identified previously were reverse engineered to understand the validation on the protocol’s fields, with specific focus on the variable length fields within message types rversion, rwalk and rread.

By importing the P9Client and P9Exchange data structures into IDA Pro, the reverse engineering process relatively straight forward to understand the packet validation logic. The functions below have been reversed to the level required for understanding the validation and are not representative of the entire function code base.

P9Client::ReceiveCallback validates that the Rmessage_size does not exceed the max connection size of 0x10000

P9Client::HandleReply – there are multiple local DoS here which result in a Blue Screen Of Death (BSOD) depending on the size of P9Client->Rmessage_size and P9Client->P9PacketEnd->size, e.g. when P9Client->P9PacketEnd->size is zero terminate() is called which is BSOD.

P9Client::FillData – we cannot reach this function with a large Rmessage_size to force an out of bounds write.

ProcessReply checks the R-message type with that from the T-message within the P9Exchange data structure.

During the P9Client::ProcessReply function it calls MidExchangeManager::FindAndRemove to fetch the P9Exchange data structure associated with the R-messages corresponding T-message.

ProcessVersionReply checks the version sent by Client “P92000.L” which is 8 characters and checks the same length on return so the rversionlen does not affect the tryString function.

ProcessWalkReply checks that the total number of rwalk structures does not exceed the P9message_size

ProcessReadReply checks the size of the count field does not exceed 0x8000 and writes it into an MDL within P9Exchange-> RxContext to pass back up the RDBSS stack to view file contents within Explorer.

Conclusion

Through this research, we discovered a local Denial of Service (DoS) within the Windows kernel implementation of the P9 protocol. As explained, the vulnerability cannot be exploited to gain code execution within the Windows kernel so there is no risk to users from this specific vulnerability. As a pre-requisite to malicious P9 server attacks, an attacker must hijack the P9 server socket “fsserver”. Therefore, we can mitigate this attack by detecting and preventing hijacking of the socket “fsserver”. McAfee MVISION Endpoint and EDR can detect and prevent coverage against P9 server socket “fsserver” hijacking which you can read more about here.

We hope this research provides insights into the following:

1. The vulnerability hunting process for new features such as the WSL P9 protocol on the Windows 10 OS
2. Provide support for future research higher up the WSL communications stack which increases in complexity due to the implementation of a virtual Linux file system on Windows
3. The value of McAfee Advanced Threat Research (ATR) working closely with our product and innovation teams to provide protection for our customers

Finally, a special thanks to Leandro Costantino and Cedric Cochin for their initial Windows 10 WSL P9 server research.

The post Hunting for Blues – the WSL Plan 9 Protocol BSOD appeared first on McAfee Blog.

Happy Birthday! Today we mark the fourth anniversary of the NoMoreRansom initiative with over 4.2 million visitors, from 188 countries, stopping an estimated $632 million in ransom demands from ending up in criminals’ pockets. It would be fair to say that the initiative, which started in a small meeting room in the Hague, has been integral for so many in the perpetual fight against cybercriminals.

Powered by the contributions of its 163 partners the portal, which is available in 36 languages, has added 28 tools in the past year and can now decrypt 140 different types of ransomware infection. To think, just four years ago we started with only a handful of decryptors and partners. That speaks volumes to the commitment by all members to collaborate and work together to give victims a third option; #DontPay.

All this hard work took place in an ever-changing cybercriminal landscape; during those four years ransomware criminals shifted their tactics from “spray and pay”, mostly aimed at consumers, to highly organized crime groups actively seeking to paralyze complete organizations and extort them for astronomical amounts of money.

These challenges have not discouraged NoMoreRansom and its partners; on the contrary, having a strong public private partnership between Law Enforcement and the Private sector has proven essential in several (ongoing) investigations. Without a doubt, we will be the first to admit that fighting ransomware has not been easy but that should not stop us from doing things that are hard.

We are delighted to continue supporting this initiative and play our part in fighting this global problem. However, we have to stress that the fight against ransomware is far from over, in fact we need more collaborative initiatives to combat the rise in malicious activity.  Also, there are still many individuals and organizations that do not even know about NoMoreRansom. Even within the information security industry there are those who have not heard about the availability of free decryption tools.

Please share the message: #DontPay #NoMoreRansom

The post Six Hundred Million Reasons to Celebrate: No More Ransom Turns FOUR!! appeared first on McAfee Blog.

Building Adaptable Security Architecture Against the Operation North Star Campaign

Operation North Star Overview

Over the last few months, we have seen attackers take advantage of the pandemic as a cover to launch cyberattacks. One such example is a campaign that McAfee Advanced Threat Research (ATR) observed as an increase in malicious cyber activity targeting the Aerospace & Defense industry. In this campaign McAfee ATR discovered a series of malicious documents containing job postings taken from leading defense contractors to be used as lures, in a very targeted fashion. This type of campaign has appeared before, in 2017 and 2019 using similar techniques, but the 2020 campaign has some distinct differences in implants, infrastructure and spear phishing lures. For a more detailed analysis of this campaign please see the McAfee ATR blog.

This blog is focused on how to build an adaptable security architecture to increase your resilience against these types of attacks and specifically, how McAfee’s portfolio delivers the capability to prevent, detect and respond against the tactics and techniques used in the Operation North Star campaign.

Gathering Intelligence on Operation North Star

As always, building adaptable defensive architecture starts with intelligence. In most organizations, the Security Operations team is responsible for threat intelligence analysis, as well as threat and incident response. McAfee Insights is a great tool for the threat intel analyst and threat responder. The Insights Dashboard identifies prevalence and severity of emerging threats across the globe which enables the Security Operations Center (SOC) to prioritize threat response actions and gather relevant cyber threat intelligence (CTI) associated with the threat, in this case the Operation North Star campaign. The CTI is provided in the form of technical Indicators of Compromise (IOCs) as well as MITRE ATT&CK framework tactics and techniques. As a threat intel analyst or responder, you can drill down to gather more specific information on Operation North Star, such as prevalence and links to other sources of information. You can further drill down to gather more specific actionable intelligence such as indicators of compromise and tactics/techniques aligned to the MITRE ATT&CK framework.

From the McAfee ATR blog, you can see that Operation North Star leverages tactics and techniques common to other APT campaigns, such as spear phishing for Initial Access, exploited system tools and signed binaries, modification of Registry Keys/Startup folder for persistence and encoded traffic for command and control.

Defensive Architecture Overview

Today’s digital enterprise is a hybrid environment of on-premise systems and cloud services with multiple entry points for attacks like Operation North Star. The work from home operating model forced by COVID-19 has only expanded the attack surface and increased risk for successful spear phishing attacks if organizations did not adapt their security posture and increase training for remote workers. Mitigating the risk of attacks like Operation North Star requires a security architecture with the right controls at the device, on the network and in security operations (sec ops). The Center for Internet Security (CIS) Top 20 Cyber Security Controls provides a good guide to build that architecture. The following outlines the key security controls needed at each layer of the architecture to protect your enterprise against Operation North Star tactics and techniques.

Initial Access Stage Defensive Overview

According to Threat Intelligence and Research, the initial access is performed either through vulnerability exploitation or spear phishing attachments. As attackers can quickly change spear phishing attachments or link locations, it is important to have layered defenses that include user awareness training and response procedures, intelligence and behavior-based malware defenses on email systems, web proxy and endpoint systems, and finally sec ops playbooks for early detection and response against suspicious email attachments or other phishing techniques The following chart summarizes the controls expected to have the most effect against initial stage techniques and the McAfee solutions to implement those controls where possible.

For additional information on how McAfee can protect against suspicious email attachments, review this additional blog post.

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/mcafee-protects-against-suspicious-email-attachments/

Exploitation Stage Defensive Overview

The exploitation stage is where the attacker gains access to the target system. Protection against Operation North Star at this stage is heavily dependent on adaptable anti-malware on both end user devices and servers, restriction of application execution, and security operations tools like endpoint detection and response sensors.

McAfee Endpoint Security 10.7 provides a defense in depth capability including signatures and threat intelligence to cover known bad indicators or programs, as well as machine-learning and behavior-based protection to reduce the attack surface against Operation North Star and detect new exploitation attack techniques. This attack leverages weaponized documents with links to external template files on a remote server. McAfee Threat Prevention and Adaptive Threat Protection modules protect against these techniques.

Additionally, MVISION EDR provides proactive detection capability on Execution and Defensive Evasion techniques identified in the exploit stage analysis. Please read further to see MVISION EDR in action against Operation North Star.

The following chart summarizes the critical security controls expected to have the most effect against exploitation stage techniques and the McAfee solutions to implement those controls where possible.

For more information on how McAfee Endpoint Security 10.7 can prevent some of the techniques used in the Operation North Star exploit stage, review this additional blog post.

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/mcafee-amsi-integration-protects-against-malicious-scripts/

Impact Stage Defensive Overview

The impact stage is where the attacker encrypts the target system, data and perhaps moves laterally to other systems on the network. Protection at this stage is heavily dependent on adaptable anti-malware on both end user devices and servers, network controls and security operation’s capability to monitor logs for anomalies in privileged access or network traffic. The following chart summarizes the controls expected to have the most effect against impact stage techniques and the McAfee solutions to implement those controls where possible.

Hunting for Operation North Star Indicators

As a threat intel analyst or hunter, you might want to quickly scan your systems for any indicators you received on Operation North Star. Of course, you can do that manually by downloading a list of indicators and searching with available tools. However, if you have MVISION EDR and Insights, you can do that right from the console, saving precious time. Hunting the attacker can be a game of inches so every second counts. Of course, if you found infected systems or systems with indicators, you can take action to contain and start an investigation for incident response immediately from the MVISION EDR console.

Proactively Detecting Operation North Star Techniques

Many of the exploit stage techniques in this attack use legitimate Windows processes and applications to either exploit or avoid detection. We demonstrated above how the Endpoint Protection Platform can disrupt the weaponized documents but, by using MVISION EDR, you can get more visibility. As security analysts, we want to focus on suspicious techniques used by winword.exe as this attack leverages weaponized documents. On MVISION EDR we got the first threat detection on the monitoring dashboard for WINWORD.EXE at a Medium Risk.

The dashboard also provides a detailed look at the process activity which, in this case, is the attempt to perform the template injection.

We also received 2 alerts due to the rundll32 usage:

1)            Loaded non-common file with specified parameters via rundll32 utility

2)            Suspicious process would have been cleaned by Endpoint Protection (in observe mode)

Monitoring or Reporting on Operation North Star Events

Events from McAfee Endpoint Protection and Web Gateway play a key role in Lazarus incident and threat response. McAfee ePO centralizes event collection from all managed endpoint systems. As a threat responder, you may want to create a dashboard for Lazarus-related threat events to understand current exposure. Here is a list (not exhaustive) of Lazarus-related threat events as reported by McAfee Endpoint Protection Platform (Threat Prevention module), with On-Access Scan and Global Threat Intelligence enabled, and McAfee Web Gateway with Global Threat Intelligence enabled as well.

Summary

To defeat targeted threat campaigns, defenders must collaborate internally and externally to build an adaptive security architecture which will make it harder for threat actors to succeed and build resilience in the business. This blog highlights how to use McAfee’s security solutions to prevent, detect and respond to Operation North Star and attackers using similar techniques.

McAfee ATR is actively monitoring this campaign and will continue to update McAfee Insights and its social networking channels with new and current information. Want to stay ahead of the adversaries? Check out McAfee Insights for more information.

The post McAfee Defender’s Blog: Operation North Star Campaign appeared first on McAfee Blog.

Executive Summary

We are in the midst of an economic slump [1], with more candidates than there are jobs, something that has been leveraged by malicious actors to lure unwitting victims into opening documents laden with malware. While the prevalence of attacks during this unprecedented time has been largely carried out by low-level fraudsters, the more capable threat actors have also used this crisis as an opportunity to hide in plain sight.

One such example is a campaign that McAfee Advanced Threat Research (ATR) observed as an increase in malicious cyber activity targeting the Aerospace & Defense industry. In this 2020 campaign McAfee ATR discovered a series of malicious documents containing job postings taken from leading defense contractors to be used as lures, in a very targeted fashion. These malicious documents were intended to be sent to victims in order to install a data gathering implant. The victimology of these campaigns is not clear at this time, however based on the job descriptions, they appear to be targeting people with skills and experience relating to the content in the lure documents. The campaign appears to be similar to activity reported elsewhere by the industry, however upon further analysis the implants and lure documents in this campaign are distinctly different [2], thus we can conclude this research is part of a different activity set. This campaign is utilizing compromised infrastructure from multiple European countries to host its command and control infrastructure and distribute implants to the victims it targets.

This type of campaign has appeared before in 2017 and 2019 using similar methods with the goal of gathering intelligence surrounding key military and defense technologies [3]. The 2017 campaign also used lure documents with job postings from leading defense contractors; this operation was targeting individuals employed by defense contractors used in the lures. Based on some of the insight gained from spear phishing emails, the mission of that campaign was to gather data around certain projects being developed by their employers.

The Techniques, Tactics and Procedures (TTPs) of the 2020 activity are very similar to those previous campaigns operating under the same modus operandi that we observed in 2017 and 2019. From our analysis, this appears a continuation of the 2019 campaign, given numerous similarities observed. These similarities are present in both the Visual Basic code used to execute the implant and some of the core functionality that exists between the 2019 and 2020 implants.

Thus, the indicators from the 2020 campaign point to previous activity from 2017 and 2019 that was previously attributed to the threat actor group known as Hidden Cobra [4]. Hidden Cobra is an umbrella term used to refer to threat groups attributed to North Korea by the U.S Government [1]. Hidden Cobra consists of threat activity from groups the industry labels as Lazarus, Kimsuky, KONNI and APT37. The cyber offensive programs attributed to these groups, targeting organizations around the world, have been documented for years. Their goals have ranged from gathering data around military technologies to crypto currency theft from leading exchanges.

Our analysis indicates that one of the purposes of the activity in 2020 was to install data gathering implants on victims’ machines. These DLL implants were intended to gather basic information from the victims’ machines with the purpose of victim identification. The data collected from the target machine could be useful in classifying the value of the target. McAfee ATR noticed several different types of implants were used by the adversary in the 2020 campaigns.

These campaigns impact the security of South Korea and foreign nations with malicious cyber campaigns. In this blog McAfee ATR analyzes multiple campaigns conducted in the first part of 2020.

Finally, we see the adversary expanding the false job recruitment campaign to other sectors outside of defense and aerospace, such as a document masquerading as a finance position for a leading animation studio.

In this blog we will cover:

• Target of Interest – Defense & Aerospace Campaign
• Technical Analysis
  • Phase One: Malicious Documents
    • Document Templates
    • Visual Basic Macro Code
  • Phase Two: Malicious DLLs
    • DLL Workflow
    • Implant Analysis
  • Phase Three: Network Evasion Techniques
  • Phase Four: Persistence
• Additional Lures: Relationship to 2020 Diplomatic & Political Campaign
  • Relationship to Falsified Job Recruitment Campaign
• Victimology
• Infrastructure Insights
• Techniques, Tactics & Procedures (TTPs)
• Defensive Architecture Recommendations
• IOCs
• Conclusion

Target of Interest – Defense & Aerospace Campaign

This is not the first time that we have observed threat actors using the defense and aerospace industry as lures in malicious documents. In 2017 and 2019, there were efforts to send malicious documents to targets that contained job postings for positions at leading defense contractors³

The objective of these campaigns was to gather information on specific programs and technologies. Like the 2017 campaign, the 2020 campaign also utilized legitimate job postings from several leading defense and aerospace organizations. In the 2020 campaign that McAfee ATR observed, some of the same defense contractors from the 2017 operation were again used as lures in malicious documents.

This new activity noted in 2020 uses similar Techniques, Tactics and Procedures (TTPs) to those seen in a 2017 campaign that targeted individuals in the Defense Industrial Base (DIB). The 2017 activity was included in an indictment by the US government and attributed to the Hidden Cobra threat group⁴

Attack Overview

Phase One: Initial Contact

This recent campaign used malicious documents to install malware on the targeted system using a template injection attack. This technique allows a weaponized document to download an external Word template containing macros that will be executed. This is a known trick used to bypass static malicious document analysis, as well as detection, as the macros are embedded in the downloaded template.

Further, these malicious Word documents contained content related to legitimate jobs at these leading defense contractors. All three organizations have active defense contracts of varying size and scope with the US government.

The timeline for these documents, that were sent to an unknown number of targets, ran between 31 March and 18 May 2020.

Document creation timeline

Malign documents were the main entry point for introducing malicious code into the victim’s environment. These documents contained job descriptions from defense, aerospace and other sectors as a lure. The objective would be to send these documents to a victim’s email with the intention they open, view and ultimately execute the payload.

As we mentioned, the adversary used a technique called template injection. When a document contains the .docx extension, in our case, it means that we are dealing with the Open Office XML standard. A .docx file is a zip file containing multiple parts. Using the template injection technique, the adversary puts a link towards the template file in one of the .XML files, for example the link is in settings.xml.rels while the external oleobject load is in document.xml.rels. The link will load a template file (DOTM) from a remote server. This is a clever technique we observe being used by multiple adversaries [5] and is intended to make a document appear to be clean initially, only to subsequently load malware. Some of these template files are renamed as JPEG files when hosted on a remote server to avoid any suspicion and bypass detection. These template files contain Visual Basic macro code, that will load a DLL implant onto the victim’s system. Current McAfee technologies currently protect against this threat.

We mentioned earlier that docx files (like xlsx and pptx) are part of the OOXML standard. The document defining this standard[6], describes the syntax and values that can be used as an  example. An interesting file to look at is the ‘settings.xml’ file that can be discovered in the ‘Word’ container of the docx zip file. This file contains settings with regards to language, markup and more. First, we extracted all the data from the settings.xml files and started to compare. All the documents below contained the same language values:

The XML file ends with a GUID value that starts with the value “w15”.

According to the Microsoft documentation, w15 defines the PersistentDocumentId Class. When the object is serialized out as xml, its qualified name is w15:docId. The 128-bit GUID is set as an ST_Guid attribute which, according to the Microsoft documentation, refers to a unique token. The used class generates a GUID for use as the DocID and generates the associated key. The client stores the GUID in that structure and persists in the doc file. If, for example, we would create a document and would “Save As”, the w15:docId GUID would persist across to the newly created document. What would that mean for our list above? Documents with the same GUID value need to be placed in chronological order and then we can state the earliest document is the root for the rest, for example:

What we can say from above table is that ‘_IFG_536R.docx” was the first document we observed and that later documents with the same docID value were created from the same base document.

To add to this assertion; in the settings.xml file the value “rsid” (Revision Identifier for Style Definition) can be found. According to Microsoft’s documentation: “This element specifies a unique four-digit number which shall be used to determine the editing session in which this style definition was last modified. This value shall follow this following constraint: All document elements which specify the same rsid* values shall correspond to changes made during the same editing session. An editing session is defined as the period of editing which takes place between any two subsequent save actions.”

Let’s start with the rsid element values from “*_IFG_536R.docx”:

And compare with the rsid element values from “*_PMS.docx”:

The rsid elements are identical for the first four editing sessions for both documents. This indicates that these documents, although they are now separate, originated from the same document.

Digging into more values and metadata (we are aware they can be manipulated), we created the following overview in chronological order based on the creation date:

When we zoom in on the DocID “932E534d(..) we read the value of a template file in the XML code: “Single spaced (blank).dotx” – this template name seems to be used by multiple “Author” names. The revision number indicates the possible changes in the document.

Note: the documents in the table with “No DocID” were the “dotm” files containing the macros/payload.

All files were created with Word 2016 and had both the English and Korean languages installed. This analysis into the metadata indicates that there is a high confidence that the malicious documents were created from a common root document.

Document Templates

There were several documents flagged as non-malicious discovered during our investigation. At first glance they did not seem important or related at all, but deeper investigation revealed how they were connected. These documents played a role in building the final malicious documents that ultimately got sent to the victims. Further analysis of these documents, based on metadata information, indicated that they contained relationships to the primary documents created by the adversary.

Two PDF files (***_SPE_LEOS and ***_HPC_SE) with aerospace & defense industry themed images, created via the Microsoft Print to PDF service, were submitted along with ***_ECS_EPM.docx. The naming convention of these PDF files was very similar to the malicious documents used. The name includes abbreviations for positions at the defense contractor much like the malicious documents. The Microsoft Print to PDF service enables content from a Microsoft Word document be printed to PDF directly. In this case these two PDF files were generated from an original Microsoft Word document with the author ‘HOME’. The author ‘HOME’ appeared in multiple malicious documents containing job descriptions related to aerospace, defense and the entertainment industry. The PDFs were discovered in an archive file indicating that LinkedIn may have been a possible vector utilized by the adversaries to target victims. This is a similar vector as to what has been observed in a campaign reported by industry[7], however as mentioned earlier the research covered in this blog is part of a different activity set.

Metadata from PDF file submitted with ***_ECS_EPM.docx in archive with context fake LinkedIn

Visual Basic Macro Code

Digging into the remote template files reveals some additional insight concerning the structure of the macro code. The second stage remote document template files contain Visual Basic macro code designed to extract a double base64 encoded DLL implant. The content is all encoded in UserForm1 in the remote DOTM file that is extracted by the macro code.

Macro code (17.dotm) for extracting embedded DLL

Further, the code will also extract the embedded decoy document (a clean document containing the job description) to display to the victim.

Code (17.dotm) to extract clean decoy document

Macro code (******_dds_log.jpg) executed upon auto execution

Phase Two: Dropping Malicious DLLs

The adversary used malicious DLL files, delivered through stage 2 malicious documents, to spy on targets. Those malicious documents were designed to drop DLL implants on the victim’s machine to collect initial intelligence. In this campaign the adversary was utilizing patched SQL Lite DLLs to gather basic information from its targets. These DLLs were modified to include malicious code to be executed on the victim’s machine when they’re invoked under certain circumstances. The purpose of these DLLs is/was to gather machine information from infected victims that could be used to further identify more interesting targets.

The first stage document sent to targeted victims contained an embedded link that downloaded the remote document template.

Embedded link contained within Word/_rels/settings.xml.rels

The DOTM (Office template filetype) files are responsible for loading the patched DLLs onto the victim’s machine to collect and gather data. These DOTM files are created with DLL files  encoded directly into the structure of the file. These DOTM files exist on remote servers compromised by the adversary; the first stage document contains an embedded link that refers to the location of this file. When the victim opens the document, the remote DOTM file that contains a Visual Basic macro code to load malicious DLLs, is loaded. Based on our analysis, these DLLs were first seen on 20 April 2020 and, to our knowledge based on age and prevalence data, these implants have been customized for this attack.

The workflow of the attack can be represented by the following image:

To identify the malicious DLLs that will load or download the final implant, we extracted from the Office files found in the triage phase, the following DLL files:

These DLL files are patched versions from goodware libraries, like the SQLITE library found in our analysis, and are loaded via a VBScript contained within the DOTM files that loads a double Base64 encoded DLL as described in this analysis. The DLL is encoded in UserForm1 (contained within the Microsoft Word macro) and the primary macro code is responsible for extracting and decoded the DLL implant.

DOTM Document Structure

Implant DLLs encoded in UserForm1

From our analysis, we could verify how the DLLs used in the third stage were legitimate software with a malicious implant inside that would be enabled every time a specific function was called with a set of parameters.

Analyzing the sample statically, it was possible to extract the legitimate software used to store the implant, for example, one of the DLL files extracted from the DOTM files was a patched SQLITE library. If we compare the original library within the extracted DLL, we can spot lot of similarities across the two samples:

Legitimate library to the left, malicious library to the right

As mentioned, the patched DLL and the original SQLITE library share a lot of code:

Both DLLs share a lot of code internally

The first DLL stage needs certain parameters in order to be enabled and launched in the system. The macro code of the Office files we analyzed, contained part of these parameters:

Information found in the pcode of the document

The data found in the VBA macro had the following details:

• 32-bit keys that mimic a Windows SID
  • The first parameter belongs to the decryption key used to start the malicious activity.
  • This could be chosen by the author to make the value more realistic
• Campaign ID

DLL Workflow

The analysis of the DLL extracted from the ‘docm’ files (the 2nd stage of the infection) revealed  the existence of two types of operation for these DLLs:

DLL direct execution:

• The DLL unpacks a new payload in the system.

Drive-by DLLs:

• The DLL downloads a new DLL implant from a remote server delivering an additional DLL payload into the system.

For both methods, the implant starts collecting the target information and then contacts the command and control (C2) server

We focused our analysis into the DLLs files that are unpacked into the system.

Implant Analysis

The DLL implant will be executed after the user interacts by opening the Office file. As we explained, the p-code of the VBA macro contains parts of the parameters needed to execute the implant into the system.

The new DLL implant file will be unpacked (depending of the campaign ID) inside a folder inside the AppData folder of the user in execution:

The DLL file, must be launched with 5 different parameters if we want to observe the malicious connection within the C2 domain; in our analysis we observed how the DLL was launched with the following command line:

The required parameters to launch the malicious implant are:

As we explained, the implants are patched SQLITE files and that is why we could find additional functions that are used to launch the malicious implant, executing the binary with certain parameters. It is necessary to use a specific export ‘sqlite3_steps’ plus the parameters mentioned before.

Analyzing the code statically we could observe that the payload only checks 2 of these 5 parameters but all of them must be present in order to execute the implant:

sqlite malicious function

Phase Three: Network Evasion Techniques

Attackers are always trying to remain undetected in their intrusions which is why it is common to observe techniques such as mimicking the same User-Agent that is present in the system, in order to remain under the radar. Using the same User-Agent string from the victim’s web browser configurations, for example, will help avoid network-based detection systems from flagging outgoing traffic as suspicious. In this case, we observed how, through the use of the Windows API ObtainUserAgentString, the attacker obtained the User-Agent and used the value to connect to the command and control server:

If the implant cannot detect the User-Agent in the system, it will use the default Mozilla User-Agent instead:

Running the sample dynamically and intercepting the TLS traffic, we could see the connection to the command and control server:

Unfortunately, during our analysis, the C2 was not active which limited our ability for further analysis.

The data sent to the C2 channel contains the following information:

We could find at least 5 different campaign IDs in our analysis, which suggests that the analysis in this document is merely the tip of the iceberg:

Phase Four: Persistence

In our analysis we could observe how the adversary ensures persistence by delivering an LNK file into the startup folder

The value of this persistent LNK file is hardcoded inside every sample:

Dynamically, and through the Windows APIs NtCreateFile and NtWriteFile, the LNK is written in the startup folder. The LNK file contains the path to execute the DLL file with the required parameters.

Additional Lures: Relationship to 2020 Diplomatic and Political Campaign

Further investigation into the 2020 campaign activity revealed additional links indicating the adversary was using domestic South Korean politics as lures. The adversary created several documents in the Korean language using the same techniques as the ones seen in the defense industry lures. One notable document, with the title US-ROK Relations and Diplomatic Security in both Korean and English, appeared on 6 April 2020 with the document author JangSY.

US-ROK Relation and Diplomatic Security

The document was hosted on the file sharing site hxxps://web.opendrive.com/api/v1/download/file.json/MzBfMjA1Njc0ODhf?inline=0 and contained an embedded link referring to a remote DOTM file hosted on another file sharing site (od.lk). The BASE64 coded value MzBfMjA1Njc0ODhf is a unique identifier for the user associated with the file sharing platform od.lk.

A related document discovered with the title test.docx indicated that the adversary began testing these documents in early April 2020. This document contained the same content as the above but was designed to test the downloading of the remote template file by hosting it on a private IP address. The document that utilized pubmaterial.dotm for its remote template also made requests to the URL hxxp://saemaeul.mireene.com/skin/visit/basic/.

This domain (saemaeul.mireene.com) is connected to numerous other Korean language malicious documents that also appeared in 2020 including documents related to political or diplomatic relations. One such document (81249fe1b8869241374966335fd912c3e0e64827) was using the 21^st National Assembly Election as part of the title, potentially indicating those interested in politics in South Korea were a target. For example, another document (16d421807502a0b2429160e0bd960fa57f37efc4) used the name of an individual, director Jae-chun Lee. It also shared the same metadata.

The original author of these documents was listed as Seong Jin Lee according to the embedded metadata information. However, the last modification author (Robot Karll) used by the adversary during document template creation is unique to this set of malicious documents. Further, these documents contain political lures pertaining to South Korean domestic policy that suggests that the targets of these documents also spoke Korean.

Relationship to 2019 Falsified Job Recruitment Campaign

A short-lived campaign from 2019 using India’s aerospace industry as a lure used what appears to be very similar methods to this latest campaign using the defense industry in 2020. Some of the TTPs from the 2020 campaign match that of the operation in late 2019. The activity from 2019 has also been attributed to Hidden Cobra by industry reporting.

The campaign from October 2019 also used aerospace and defense as a lure, using copies of legitimate jobs just like we observed with the 2020 campaign. However, this campaign was isolated to the Indian defense sector and from our knowledge did not expand beyond this. This document also contained a job posting for a leading aeronautics company in India; this company is focused on aerospace and defense systems. This targeting aligns with the 2020 operation and our analysis reveals that the DLLs used in this campaign were also modified SQL Lite DLLs.

Based on our analysis, several variants of the implant were created in the October 2019 timeframe, indicating the possibility of additional malicious documents.

One notable difference with the 2019 campaign is the main malicious document contained the implant payload, unlike the 2020 campaign that relied on the Microsoft Office remote template injection technique. Even though the technique is different, we did observe likenesses as we began to dissect the remote template document. There are some key similarities within the VBA code embedded in the documents. Below we see the 2019 (left) and 2020 (right) side-by-side comparison of two essential functions, that closely match each other, within the VBA code that extracts/drops/executes the payload.

VBA code of 13c47e19182454efa60890656244ee11c76b4904 (left) and acefc63a2ddbbf24157fc102c6a11d6f27cc777d (right)

The VBA macro drops the first payload of thumbnail.db at the filepath, which resembles the filepath used in 2020.

The VB code also passes the decryption key over to the DLL payload, thumbnail.db. Below you can see the code within thumbnail.db accepting those parameters.

Unpacked thumbnail.db bff1d06b9ef381166de55959d73ff93b

What is interesting is the structure in which this information is being passed over. This 2019 sample is identical to what we documented within the 2020 campaign.

Another resemblance discovered was the position of the .dll implant existing in the exact same location for both 2019 and 2020 samples; “o” field under “UserForms1”.

“o” field of 13c47e19182454efa60890656244ee11c76b4904

All 2020 .dotm IoCs contain the same .dll implant within the “o” field under “UserForms1”, however, to not overwhelm this write-up with separate screenshots, only one sample is depicted below. Here you can see the parallel between both 2019 and 2020 “o” sections.

“o” field of acefc63a2ddbbf24157fc102c6a11d6f27cc777d

Another similarity is the encoding of double base64, though in the spirit of competing hypothesis, we did want to note that other adversaries may also use this type of encoding. However, when you couple these similarities with the same lure of an Indian defense contractor, the pendulum starts to lean more to one side of a possible common author between both campaigns. This may indicate another technique being added to the adversary’s arsenal of attack vectors.

One method to keep the campaign dynamic and more difficult to detect is hosting implant code remotely. There is one disadvantage of embedding an implant within a document sent to a victim; the implant code could be detected before the document even reaches the victim’s inbox. Hosting it remotely enables the implant to be easily switched out with new capabilities without running the risk of the document being classified as malicious.

**-HAL-MANAGER.doc UserForm1 with double base64 encoded DLL

17.DOTM UserForm1 with double base64 encoded DLL from ******_DSS_SE.docx

According to a code similarity analysis, the implant embedded in **-HAL-Manager.doc contains some similarities to the implants from the 2020 campaign. However, we believe that the implant utilized in the 2019 campaign associated with **-Hal-Manager.doc may be another component. First, besides the evident similarities in the Visual Basic macro code and the method for encoding (double base64) there are some functional level similarities. The DLL file is run in a way with similar parameters.

DLL execution code **-Hal-Manager.doc implant

DLL execution code 2020 implant

Campaign Context: Victimology

The victimology is not exactly known due to the lack of spear phishing emails uncovered; however, we can obtain some insight from the analysis of telemetry information and lure document context. The lure documents contained job descriptions for engineering and project management positions in relationship to active defense contracts. The individuals receiving these documents in a targeted spear phishing campaign were likely to have an interest in the content within these lure documents, as we have observed in previous campaigns, as well as some knowledge or relationship to the defense industry.

Infrastructure Insights

Our analysis of the 2019 and 2020 campaigns reveals some interesting insight into the command and control infrastructure behind them, including domains hosted in Italy and the United States. During our investigation we observed a pattern of using legitimate domains to host command and control code. This is beneficial to the adversary as most organizations do not block trusted websites, which allows for the potential bypass of security controls. The adversary took the effort to compromise the domains prior to launching the actual campaign. Further, both 2019 and 2020 job recruitment campaigns shared the same command and control server hosted at elite4print.com.

The domain mireene.com with its various sub-domains have been used by Hidden Cobra in 2020. The domains identified to be used in various operations in 2020 falling under the domain mireene.com are:

• saemaeul.mireene.com
• orblog.mireene.com
• sgmedia.mireene.com
• vnext.mireene.com
• nhpurumy.mireene.com
• jmable.mireene.com
• jmdesign.mireene.com
• all200.mireene.com

Some of these campaigns use similar methods as the 2020 defense industry campaign:

• Malicious document with the title European External Action Service [8]
• Document with Korean language title 비건 미국무부 부장관 서신doc (U.S. Department of State Secretary of State Correspondence 20200302.doc).

Techniques, Tactics and Procedures (TTPS)

The TTPs of this campaign align with those of previous Hidden Cobra operations from 2017 using the same defense contractors as lures. The 2017 campaign also utilized malicious Microsoft Word documents containing job postings relating to certain technologies such as job descriptions for engineering and project management positions involving aerospace and military surveillance programs. These job descriptions are legitimate and taken directly from the defense contractor’s website. The exploitation method used in this campaign relies upon a remote Office template injection method, a technique that we have seen state actors use recently.

However, it is not uncommon to use tools such as EvilClippy to manipulate the behavior of Microsoft Office documents. For example, threat actors can use pre-built kits to manipulate clean documents and embed malicious elements; this saves time and effort. This method will generate a consistent format that can be used throughout campaigns. As a result, we have observed a consistency with how some of the malicious elements are embedded into the documents (i.e. double base64 encoded payload). Further mapping these techniques across the MITRE ATT&CK framework enables us to visualize different techniques the adversary used to exploit their victims.

MITRE ATT&CK mapping for malicious documents

These Microsoft Office templates are hosted on a command and control server and the downloaded link is embedded in the first stage malicious document.

The job postings from these lure documents are positions for work with specific US defense programs and groups:

• F-22 Fighter Jet Program
• Defense, Space and Security (DSS)
• Photovoltaics for space solar cells
• Aeronautics Integrated Fighter Group
• Military aircraft modernization programs

Like previous operations, the adversary is using these lures to target individuals, likely posing as a recruiter or someone involved in recruitment. Some of the job postings we have observed:

• Senior Design Engineer
• System Engineer

Professional networks such as LinkedIn could be a place used to deliver these types of job descriptions.

Defensive Architecture Recommendations

Defeating the tactics, techniques and procedures utilized in this campaign requires a defense in depth security architecture that can prevent or detect the attack in the early stages. The key controls in this case would include the following:

1. Threat Intelligence Research and Response Program. Its critical to keep up with the latest Adversary Campaigns targeting your specific vertical. A robust threat response process can then ensure that controls are adaptable to the TTPs and, in this case, create heightened awareness
2. Security Awareness and Readiness Program. The attackers leveraged spear-phishing with well-crafted lures that would be very difficult to detect initially by protective technology. Well-trained and ready users, informed with the latest threat intelligence on adversary activity, are the first line of defense.
3. End User Device Security. Adaptable endpoint security is critical to stopping this type of attack early, especially for users working from home and not behind the enterprise web proxy or other layered defensive capability. Stopping or detecting the first two stages of infection requires an endpoint security capability of identifying file-less malware, particularly malicious Office documents and persistence techniques that leverage start-up folder modification.
4. Web Proxy. A secure web gateway is an essential part of enterprise security architecture and, in this scenario, can restrict access to malicious web sites and block access to the command and control sites.
5. Sec Ops – Endpoint Detection and Response (EDR) can be used to detect techniques most likely in stages 1, 2 or 4. Additionally, EDR can be used to search for the initial documents and other indicators provided through threat analysis.

For further information on how McAfee Endpoint Protection and EDR can prevent or detect some of the techniques used in this campaign, especially use of malicious Office documents, please refer to these previous blogs and webinar:

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/ens-10-7-rolls-back-the-curtain-on-ransomware/
https://www.mcafee.com/blogs/other-blogs/mcafee-labs/how-to-use-mcafee-atp-to-protect-against-emotet-lemonduck-and-powerminer/
https://www.mcafee.com/enterprise/en-us/forms/gated-form.html?docID=video-6157567326001

Indicators of Compromise

Conclusion

In summary, ATR has been tracking a targeted campaign focusing on the aerospace and defense industries using false job descriptions. This campaign looks very similar, based on shared TTPs, with a campaign that occurred in 2017 that also targeted some of the same industry. This campaign began early April 2020 with the latest activity in mid-June. The campaign’s objective is to collect information from individuals connected to the industries in the job descriptions.

Additionally, our forensic research into the malicious documents show they were created by the same adversary, using Korean and English language systems. Further, discovery of legitimate template files used to build these documents also sheds light on some of the initial research put into the development of this campaign. While McAfee ATR has observed these techniques before, in previous campaigns in 2017 and 2019 using the same TTPs, we can conclude there has been an increase in activity in 2020.

McAfee detects these threats as

• Trojan-FRVP!2373982CDABA
• Generic Dropper.aou
• Trojan-FSGY!3C6009D4D7B2
• Trojan-FRVP!CEE70135CBB1
• W97M/Downloader.cxu
• Trojan-FRVP!63178C414AF9
• Exploit-cve2017-0199.ch
• Trojan-FRVP!AF83AD63D2E3
• RDN/Generic Downloader.x
• W97M/Downloader.bjp
• W97M/MacroLess.y

NSP customers will have new signatures added to the “HTTP: Microsoft Office OLE Arbitrary Code Execution Vulnerability (CVE-2017-0199)” attack name. The updated attack is part of our latest NSP sigset release: sigset 10.8.11.9 released on 28^th July 2020.The KB details can be found here: KB55446

[1] https://www.bbc.co.uk/news/business-53026175

[2] https://www.welivesecurity.com/2020/06/17/operation-interception-aerospace-military-companies-cyberspies/

[3] https://www.justice.gov/opa/pr/north-korean-regime-backed-programmer-charged-conspiracy-conduct-multiple-cyber-attacks-and

[4] https://www.justice.gov/opa/pr/north-korean-regime-backed-programmer-charged-conspiracy-conduct-multiple-cyber-attacks-and

5 https://www.us-cert.gov/northkorea

[5] https://www.virustotal.com/gui/file/4a08c391f91cc72de7a78b5fd5e7f74adfecd77075e191685311fa598e07d806/detection – Gamaredon Group

[6] https://docs.microsoft.com/en-us/openspecs/office_standards/ms-docx/550efe71-4f40-4438-ac89-23ec1c1d2182

[7] https://www.welivesecurity.com/2020/06/17/operation-interception-aerospace-military-companies-cyberspies/

[8] https://otx.alienvault.com/pulse/5e8619b52e480b485e58259a

The post Operation (노스 스타) North Star A Job Offer That’s Too Good to be True? appeared first on McAfee Blog.

Building Adaptable Security Architecture Against NetWalker

NetWalker Overview

The NetWalker ransomware, initially known as Mailto, was first detected in August 2019. Since then, new variants were discovered throughout 2019 and the beginning of 2020, with a strong uptick noticed in March of this year. NetWalker has noticeably evolved to a more stable and robust ransomware-as-a-service (RaaS) model, and McAfee research suggests that the malware operators are targeting and attracting a broader range of technically advanced and enterprising criminal affiliates. McAfee Advanced Threat Research (ATR) discovered a large sum of bitcoins linked to NetWalker which suggest its extortion efforts are effective and that many victims have had no option other than to succumb to its criminal demands. For more details on NetWalker, see the McAfee ATR blog here.

We do not want you to be one of those victims, so this blog is focused on how to build an adaptable security architecture to defeat this threat and, specifically, how McAfee’s portfolio delivers the capability to prevent, detect and respond to NetWalker ransomware.

Gathering Intelligence on NetWalker

As always, building adaptable defensive architecture starts with intelligence. In most organizations, the Security Operations team is responsible for threat intelligence analysis, as well as threat and incident response. The Preview of McAfee MVISION Insights is a sneak peek of some of MVISION Insights capabilities for the threat intel analyst and threat responder. The preview identifies the prevalence and severity of select top emerging threats across the globe which enables the Security Operations Center (SOC) to prioritize threat response actions and gather relevant cyber threat intelligence (CTI) associated with the threat, in this case NetWalker ransomware. The CTI is provided in the form of technical Indicators of Compromise (IOCs) as well as MITRE ATT&CK framework tactics and techniques.

As a threat intel analyst or responder, you can drill down to gather more specific information on NetWalker, such as prevalence and links to other sources of information.

As a threat intel analyst or responder, you can further drill down to gather more specific actionable intelligence on NetWalker, such as indicators of compromise and tactics/techniques aligned to the MITRE ATT&CK framework.

From MVISION Insights preview, you can see that NetWalker leverages tactics and techniques common to other ransomware attacks, such as spear phishing attachments for Initial Access, use of PowerShell for deployment, modification of Registry Keys/Startup folder for persistence and encryption of files for impact of course.

Defensive Architecture Overview

Today’s digital enterprise is a hybrid environment of on-premise systems and cloud services with multiple entry points for attacks like NetWalker. The work from home operating model forced by COVID-19 has only expanded the attack surface and increased the risk for successful ransomware attack if organizations did not adapt their security posture. Mitigating the risk of attacks like NetWalker requires a security architecture with the right controls at the device, on the network and in security operations (sec ops). The Center for Internet Security (CIS) Top 20 Cyber Security Controls provides a good guide to build that architecture. For ransomware, and NetWalker in particular, the controls must be layered throughout the enterprise. The following outlines the key security controls needed at each layer of the architecture to protect your enterprise against ransomware.

To assess your capability against NetWalker, you must match your existing controls against the attack stages we learned from the Preview of MVISION Insights. For detailed analysis on the NetWalker ransomware attack, see McAfee ATR’s blog but, for simplicity, we matched the attack stages to the MITRE ATT&CK Framework below.

Initial Access Stage Defensive Overview

According to Threat Intelligence and Research, the initial access is performed either through vulnerability exploitation or spear phishing attachments. The following chart summarizes the controls expected to have the most effect against initial stage techniques and the McAfee solutions to implement those controls where possible.

As attackers can quickly change spear phishing attachments, it is important to have adaptable defenses that include user awareness training and response procedures, behavior-based malware defenses on email systems, web access and endpoint systems, and finally sec ops playbooks for early detection and response against suspicious email attachments or other phishing techniques. For more information on how McAfee can protect against suspicious email attachments, review this additional blog post.

Using valid accounts and protocols, such as for Remote Desktop Protocol, is an attack technique we have seen rise during the initial COVID-19 period. To further understand how McAfee defends against RDP as an initial access vector, as well as how the attackers are using it to deploy ransomware, please see our previous posts.

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/rdp-security-explained/

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/cybercriminals-actively-exploiting-rdp-to-target-remote-organizations/

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/ens-10-7-rolls-back-the-curtain-on-ransomware/

Exploitation Stage Defensive Overview

The exploitation stage is where the attacker gains access to the target system. Protection at this stage is heavily dependent on system vulnerability management, adaptable anti-malware on both end user devices and servers and security operations tools like endpoint detection and response sensors.

McAfee Endpoint Security 10.7 provides a defense in depth capability including signatures and threat intelligence to cover known bad indicators or programs.

Additionally, machine-learning and behavior-based protection reduces the attack surface against NetWalker and detects new exploitation attack techniques.

For more information on how McAfee Endpoint Security 10.7 can prevent or identify the techniques used in NetWalker, review these additional blog posts.

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/ens-10-7-rolls-back-the-curtain-on-ransomware/

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/mcafee-amsi-integration-protects-against-malicious-scripts/

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/how-to-use-mcafee-atp-to-protect-against-emotet-lemonduck-and-powerminer/

The following chart summarizes the critical security controls expected to have the most effect against exploitation stage techniques and the McAfee solutions to implement those controls where possible.

Impact Stage Defensive Overview

The impact stage is where the attacker encrypts the target system, data and perhaps moves laterally to other systems on the network. Protection at this stage is heavily dependent on adaptable anti-malware on both end user devices and servers, network controls and security operation’s capability to monitor logs for anomalies in privileged access or network traffic. The following chart summarizes the controls expected to have the most effect against impact stage techniques and the McAfee solutions to implement those controls where possible.

Hunting for NetWalker Indicators

As a threat intel analyst or hunter, you might want to quickly scan your systems for any of NetWalker indicators. Of course, you can do that manually by downloading a list of indicators and searching with available tools. However, if you have MVISION EDR, you will be able to that search right from Insights, saving precious time. Hunting the attacker can be a game of inches so every second counts. Of course, if you found infected systems or systems with indicators, you can take action to contain and start an investigation for incident response immediately from the MVISION EDR console.

Proactively Detecting NetWalker Techniques

Many of the exploit stage techniques in this attack use legitimate Windows tools or valid accounts to either exploit, avoid detection or move laterally. These techniques are not easily prevented but can be detected using MVISION EDR. As security analysts, we want to focus on suspicious techniques, such as PowerShell, used to download files…

or execute scripts…

or evade defenses…

Monitoring or Reporting on NetWalker Events

Events from McAfee Endpoint Protection and Web Gateway play a key role in NetWalker incident and threat response. McAfee ePO centralizes event collection from all managed endpoint systems. As a threat responder, you may want to create a dashboard for NetWalker-related threat events to understand current exposure. Here is a list (not exhaustive) of NetWalker-related threat events as reported by Endpoint Protection Platform Threat Prevention Module and McAfee Web Gateway.

Summary

Ransomware has evolved into a lucrative business for threat actors, from underground forums selling ransomware, to offering services such as support portals to guide victims through acquiring crypto currency for payment, to the negotiation of the ransom. However, just as attackers work together, defenders must collaborate internally and externally to build an adaptive security architecture which will make it harder for threat actors to succeed and build resilience in the business. This blog highlights how to use McAfee’s security solutions to prevent, detect and respond to NetWalker and attackers using similar techniques.

McAfee ATR is actively monitoring ransomware threats and will continue to update McAfee MVISION Insights and its social networking channels with new and current information. Want to stay ahead of the adversaries? Check out McAfee MVISION Insights for more information.

The post McAfee Defender’s Blog: NetWalker appeared first on McAfee Blog.

Executive Summary

The NetWalker ransomware, initially known as Mailto, was first detected in August 2019. Since then, new variants were discovered throughout 2019 and the beginning of 2020, with a strong uptick noticed in March of this year.

NetWalker has noticeably evolved to a more stable and robust ransomware-as-a-service (RaaS) model, and our research suggests that the malware operators are targeting and attracting a broader range of technically advanced and enterprising criminal affiliates.

McAfee Advanced Threat Research (ATR) discovered a large sum of bitcoins linked to NetWalker which suggest its extortion efforts are effective and that many victims have had no option other than to succumb to its criminal demands.

We approached our investigation of NetWalker with some possible ideas about the threat actor behind it, only to later disprove our own hypothesis. We believe the inclusion of our thinking, and the means with which we debunked our own theory, highlight the importance of thorough research and we welcome further discussion on this topic. We believe it starts valuable discussions and helps avoid duplicate research efforts by others. We also encourage our peers in the industry to share information with us in case you have more evidence.

McAfee protects its customers against the malware covered in this blog in all its products, including personal antivirus, endpoint and gateway. To learn more about how McAfee products can defend against these types of attacks, visit our blog on Building Adaptable Security Architecture Against NetWalker.

Check out McAfee Insights to stay on top of NetWalker’s latest developments and intelligence on other cyber threats, all curated by the McAfee ATR team. Not only that, Insights will also help you prioritize threats, predict if your countermeasures will work and prescribe corrective actions.

Introduction

Since 2019, NetWalker ransomware has reached a vast number of different targets, mostly based in western European countries and the US. Since the end of 2019, the NetWalker gang has indicated a preference for larger organisations rather than individuals. During the COVID-19 pandemic, the adversaries behind NetWalker clearly stated that hospitals will not be targeted; whether they keep to their word remains to be seen.

The ransomware appends a random extension to infected files and uses Salsa20 encryption. It uses some tricks to avoid detection, such as a new defence evasion technique, known as reflective DLL loading, to inject a DLL from memory.

The NetWalker collective, much like those behind Maze, REvil and other ransomware, threatens to publish victims’ data if ransoms are not paid.

As mentioned earlier, NetWalker RaaS prioritizes quality over quantity and is looking for people who are Russian-speaking and have experience with large networks. People who already have a foothold in a potential victim’s network and can exfiltrate data with ease are especially sought after. This is not surprising, considering that publishing a victims’ data is part of NetWalker’s model.

The following sections are dedicated to introducing the NetWalker malware and displaying the telemetry status before moving on to the technical malware analysis of the ransomware’s behaviour. We will explain how the decryptor works and show some interactions between NetWalker’s operators and their victims. After this, we discuss the changes in modus operandi since September 2019, especially regarding payment behaviour. Then we show our attempts, unfruitful as they were, at discovering a link between NetWalker and previous, seemingly unrelated ransomware variants. Finally, we deliver an overview of IOCs related to NetWalker and its MITRE ATT&CK techniques.

Telemetry

Using McAfee’s billion Insights sensors, we can show the global prevalence of the NetWalker ransomware.

Figure 1. McAfee MVISION Insights shows global prevalence of the NetWalker ransomware

Technical Analysis

Ransom note (pre-March 2020)

Before March 2020, the NetWalker ransom note indicated how to contact the adversary directly using anonymous email account services with random names (such as [email protected] and [email protected]):

Figure 2. Example of ransom note prior to March 2020

Ransom Note (Post-March 2020)

On 12 March 2020, a researcher shared a screenshot of a new NetWalker ransom note in a tweet and we can see that the attackers have changed the contact method significantly. Email communication has been dropped completely with victims now required to make contact through the NetWalker Tor interface where, after submitting their user key, they will then be redirected to a chat with NetWalker technical support. This change in contact method coincides with underground forum postings where NetWalker revealed it was opening its RaaS up for new affiliates. The Tor page was not the only noticeable change we will highlight in this blog.

Figure 3. Example of ransom note after March 2020

NetWalker Analysis

Figure 4. NetWalker behavior

NetWalker Resource Analysis (Pre-March 2020)

The NetWalker malware uses a custom resource type (1337 or 31337) containing its entire configuration. This file is extracted to memory and decrypted using the RC4 algorithm with a hard-coded key in the resource.

Before 12 March 2020, NetWalker used the email contact process between its support operation and the victims to proceed with payment and send the decryption program. To do this, NetWalker used its configuration file in the resource to set its encryption mode, the name of the ransom note, etc., and email contacts.

Figure 5. NetWalker resource from wwllww.exe

Once decrypted, the configuration file reveals several parameters, allowing us to understand how it works (how it constitutes the ransom note, the number of threads allocated for encryption, etc.):

NetWalker Resource Analysis (Post-March 2020)

When Netwalker changed its contact mode and switched from email to the submission of the user key directly on the web portal of the group’s blog, the configuration file in the resource also changed.  We found changes in the configuration file, such as the disappearance of the contact “mail” and “crmask” fields (previously set as [email protected],[email protected], etc., and .mailto[email].{ID}). This field was replaced by “onion1” and “onion2”, and these fields are set with the NetWalker blog URL/payment page (hxxp://rnfdsgm<snip>drqqd.onion/). We also noticed that the NetWalker developers complemented their “unlocker” field with some specific values (e.g. “psexec.exe, system, forti*.exe, fmon.exe*, etc”).

Figure 6. NetWalker resource from cnt.ex

Usually, attackers use RC_DATA or a malicious BITMAP. The latter can, for example, be a regular Bitmap (open matrix image format used by Windows) that can be used by malware to execute code or as a payload dropper. The image’s pixels are an actual binary representation of the payload. This process can be summarized as Exe -> Resources -> BMP with embedded data in pixels fetched and decrypted by, e.g. a DLL -> Payload), etc. However, in this case, they use this special custom type to increase obfuscation. The NetWalker developers chose custom types by using 1337 or 31337 structs, so the resource format does not change. However, as we said, several values have changed or been replaced:

NetWalker Executable Analysis (Post-March 2020)

The malware sample used for this blog post has the same information:

The unpacked malware is a binary file of 32 bits that can be found as an EXE file.

Figure 7. Information sample of the malware

The malware’s first action is to combine all the required functions it needs into one large function, combining the modules already loaded in Windows with additional DLLs as described below.

Instead of searching for the function in the usual way, the malware makes a CRC32 hash of the name of each function and compares with hardcoded values. Additionally, instead of using the function “GetProcAddress”, the malware uses the Process Environment Block (PEB) to make analysis harder.

Figure 8. Get the module accessing the PEB and using a CRC32

If the module cannot be discovered, it will load with “LdrLoadDll”, a native function of Windows, to try avoiding hooks in the usual functions, e.g. “LoadLibraryW”:

Figure 9. Load library using LdrLoadDll

Figure 10. Get functions from module, e.g. using a CRC32 hash

If the malware fails to get a function, it will go to a “sleep” call and terminate itself.

Later, the malware extracts the configuration file from a resource with a custom type and a custom name using the functions “FindResourceA”, “LockResource”, “LoadResource” and “SizeOfResource”. The file extracted in memory is decrypted using the RC4 algorithm with a hardcoded key in the resource.

The struct of the resource is:

• 4 bytes -> The size of the hardcoded key to decrypt the configuration file.
• Variable size -> the hardcoded key to decrypt the configuration file.
• Variable size -> the configuration file encrypted.

The malware reads the first 4 bytes and reserves memory with the size of the password and reserves memory of the resource minus 4 bytes and the size of the password. Finally, it decrypts the configuration file:

Figure 11. Get configuration file and decrypt it

If the malware fails to get the configuration file, it will terminate itself.

After getting the configuration file, the malware will parse it and save the fields in memory and write in the registry information to encrypt the files in the machine. The malware will try first to write in the registry-hive “HKEY_LOCAL_MACHINE” but if it cannot create it, it will use the registry-hive “HKEY_CURRENT_USER”:

Figure 12. Write in the registry

After the writing in the registry has been completed, it will get some privileges using a token as SE_DEBUG_PRIVILEGE and SE_IMPERSONATE_PRIVILEGE:

Figure 13. Get some special privileges in the token

Later, the malware creates three threads, one to get information about the machine, such as the operating system version, one to get processes and the last one to get services in the system.

After this step, it will get the system directory and use “VSSadmin” to delete the Volume Shadow copies of the system. Volume Shadow copies can contain copies of the encrypted files and would be an option to restore from if no backup exists.

Figure 14. Delete the shadow volumes

Later, the malware will enumerate the logical units, prepare the new extension for the future encrypted files, based on the size that is defined in the ransomware config with a random extension, and encrypt all files in the fixed type units and remote units with the new extension.

Figure 15. Crypt the files

After all these steps have been completed, it will create the ransom note on the desktop using the functions “SHGetFolderPathlW” and “CreateFileW”. Subsequently, it will write the ransom note from the memory into a new file with the function “WriteFile”. The malware will create the ransom note in the root folder (for example “c:\”) of each logical unit. Next, it will launch “notepad.exe” with an argument to the ransom note file to show the user what happened on the system:

Figure 16. Creation of the ransom note in the desktop and root units

Finally, after the encryption of the files and creation of the ransom note, the malware creates a bat file in the %temp% folder of the machine with a temporary name and writes the content to destroy itself using the program “taskkill”. The batch script will delete the malware sample with its path using the command “del” and finally delete the bat file with the command “del %0%”. Of course, as the malware uses the “del” command without destroying itself before the deletion, it can be recovered with some forensic tools with luck (the same can also be said for the bat file).

This way the malware tries to remove itself from the machine to avoid being detected and analyzed by security researchers:

Figure 17. Get Temp path and make a temporary file as a bat and launch it

Finally, the malware will finish with “ExitProcess”.

Decryptor

When a NetWalker victim goes through technical support (see an example of this below) and pays the ransom demanded by the group they will be able to download the decryptor to clean up their environment.

Figure 18. Conversation with NetWalker operators

The download is done directly from the NetWalker Tor site, where the payment page switches to a download page certifying that the payment was made and received:

Figure 19. Decryptor download

The decryptor is delivered in a zip archive containing the decryptor executable and a note explaining how to run the program correctly:

Figure 20. Decryptor delivery

The program launches a graphical interface allowing the user to decipher their workstation automatically or manually:

Figure 21. Decryptor execution

At the end of the decryption process, the program indicates the number of decrypted files, deletes the ransom note if the user has checked that option, and terminates, leaving the user to resume their work peacefully:

Figure 22. Decryptor has finished the decryption process

The decryptor program appears unique and is linked to one victim specifically. In our example, it only decrypts the files belonging to the victim who made the payment from the user key specified in the ransom note.

Underground Advertising

In March 2020, the moniker Bugatti began actively advertising the NetWalker Ransomware-as-a-Service on two popular underground fora. Bugatti seems to have joined the underground scene in February 2020 but claims to have been active with NetWalker ransomware since September 2019. We have seen NetWalker activity before March but there has been a noticeable uptick in larger victims since their advertisement. For a relatively new ransomware it has been well received and respected among other cybercriminals as compared to, for instance, Nemty ransomware. The strength of NetWalker’s reputation is such that our current hypothesis is that the individual behind Bugatti is most likely a well-respected and experienced cybercriminal, even though it is a new moniker.

Figure 23. Bugatti advertising NetWalker on an underground forum

Bugatti provides regular updates on the improvements in the ransomware, such as the popular Invoke-ReflectivePEInjection method, also commonly used by Sodinokibi. In addition to the improvements in the ransomware, open slots for new affiliates are advertised. Bugatti strongly emphasized that they are primarily looking for experienced affiliates that focus on compromising the complete networks of organizations as opposed to end users. NetWalker is clearly following in the footsteps of its illustrious targeted ransomware peers like Sodinokibi, Maze and Ryuk.

One forum message in particular caught our attention as it included screenshots of several partial bitcoin addresses and USD amounts. This was most likely done to showcase the financial success of the ransomware. We have seen a similar posting in the past with the influential Sodinokibi affiliate Lalartu, so we decided to follow the money once more.

Figure 24. Bugatti is looking for advanced affiliates and shows samples of BTC payments

With the help of CipherTrace software we were able to find the complete BTC addresses from the screenshot and investigate the ledger further:

Screenshot 1

3JHTYZhRmMcq7WCKRzFN98vWvAZk792w9J

Screenshot 2

39aovzbz5rGoQdKjDm6JiybkSu1uGdVJ2V

Screenshot 3

39NRnZtgACDVhhmc7RwmvH9ZDUKTNwwaeB

Screenshot 4

3L4AW5kHnUCZBBjg2j1LBFCUN1RsHPLxCs

Following the Money

In the transactions mentioned in the underground forum post, the ransom amount payed by the victims is presumably shown. Since the bitcoin blockchain is a publicly accessible ledger, we can follow the money and see where the ransomware actors are transferring it to. In the case of the four posted transactions above, the full amount payed by the victim was transferred to two addresses (these addresses begin with bc1q98 and 1DgLhG respectively). It is safe to say that these two bitcoin addresses are under control of the NetWalker actors. We then proceeded on to analyze all incoming transactions to these two addresses and we were able to make the following observations:

• The first incoming transaction occurs on 1 March 2020.
• On 30 March 2020 the first incoming transaction appears where the amount is split between 4 different bitcoin addresses. A split like this is typically seen in Ransomware-as-a-Service, where the ransom payment is split between the RaaS operators and the affiliate who caused the infection. In this first transaction, the split is 80%, 10% and two 5% portions. This split matches the advertisement on the underground forum (80% – 20%).
• The two 5% portions of the ransom payments that are split, seem to be consistently transferred to the two bitcoin addresses we revealed earlier (bc1q98 and 1DgLhG).
• While the beneficiaries of the 5% cuts remain the same, the beneficiary of the 10% cut seems to change over time. Based on the forum post we assume these addresses also belong to the NetWalker actors.
• Payments to the bc1q98 and 1DgLhG addresses that are not being split continue up until the end of May. Possibly the initial NetWalker operators added a RaaS operation, while continuing to cause NetWalker infections themselves.
• While analyzing the bitcoin addresses that received 80% or more of the transaction amount, we noticed that there are some addresses that receive payments multiple times. A possible explanation could be that the address is configured as payout addresses for a certain campaign or affiliate. We identified 30 unique bitcoin addresses that seem to be the beneficiary of this larger portion of the ransom transaction. Some of these only received one payment but there are several that received multiple payments.
• In the two addresses uncovered by tracing the transactions a total of 641 bitcoin is held on 27 July 2020. Which at the current market value of bitcoin is worth well over 7 million USD.

Amounts Extorted

Working under the hypothesis that all the incoming transactions are ransomware payments; we can make the following observations:

• We found 23 transactions where the ransom payments were not split up and the beneficiaries are the two bitcoin addresses found by following the transactions mentioned in the underground forum post. The total amount of bitcoin extorted this way between 1 March 2020 and 27 July 2020 is 677 BTC. Additionally, the amount received from remaining transactions following the Ransomware-as-a-Service scheme by these addresses between 1 March 2020 and 27 July 2020 is 188 BTC.
• In the transactions that are split, the largest amount (usually 80% to 90% of the total transaction value) is presumably transferred to the affiliate that caused the infection. When we summed up these largest portions, we saw a total of 1723 BTC being transferred to affiliates.
• The total amount of extorted bitcoin that has been uncovered by tracing transactions to these NetWalker related addresses is 2795 BTC between 1 March 2020 and 27 July 2020. By using historic bitcoin to USD exchange rates, we estimate a total of 25 million USD was extorted with these NetWalker related transactions.

Even though we do not have complete visibility into the BTC flow before NetWalker started ramping up, one thing is certain, this quarter alone it has been highly successful at extorting organisations for large amounts of money. All this at a time when many sectors are struggling because people are sheltering in place and governments are trying to keep businesses from going bankrupt. NetWalker is making millions off the backs of legitimate companies.

Figure 25. Overview of uncovered bitcoin transactions, highlighting the two identified actor addresses.

Observed Changes

While talking about the impact of NetWalker with our partners, we learned that the change in modus operandi not only affected the way the actors communicate with their victims. When there was a change from email communication to a dedicated Tor hidden service, the actors also moved away from using legacy bitcoin addresses to SegWit addresses. The benefits of using the newer SegWit addresses include faster transaction time and lower transaction cost. The NetWalker advertisement on the underground forum mentions instant and fully automatic payments around the time of this observed change. This makes us believe the ransomware actors were professionalizing their operation just before expanding to the Ransomware-as-a-Service model.

Comparison with Previous Ransomware

Given the sudden appearance of NetWalker ransomware and the associated threat actor, it suggests that some prior knowledge on ransomware development or underground presence had to be in place. Armed with this hypothesis, we searched for possible links to underground actors and other ransomware strains that might fit the bill. We came across one threat actor offering ransomware that caught our attention. It was the use of the name NetWalker, in combination with a strong ransomware connection, that sparked our interest.

Some years ago, a threat actor using the moniker Eriknetwalker was advertising ransomware on several underground forums. We found posts from 2016 and the latest public activity was around June 2019, several months before NetWalker ransomware made its appearance.

Figure 26. Eriknetwalker began advertising their ransomware in 2016 (Google-translated from Russian)

Based on our underground research, we linked the moniker Eriknetwalker to the development and/or distribution of Amnesia, Bomber and Scarab ransomware. Eriknetwalker stopped advertising ransomware around June 2019. Therefore, we decided to perform a comparative analysis between the different ransomware strains linked to Eriknetwalker and some of the earliest versions of NetWalker we could find.

The goal of this comparative analysis was to identify whether there was an overlap between source codes. Such overlap could suggest a stronger link between the current NetWalker version and the other ransomware versions from Eriknetwalker, possibly even explaining the name overlap.

To execute the analysis, we used several tools one of which was the binary visualization tool Veles, which dynamically translates binary information into an abstract visualization that allows us to identify and compare patterns.

The different types of ransomware we began analyzing were the variants of Amnesia, Scarab, and NetWalker.

Figure 27. Flat visualization of binary data of the different ransomware variants

Figure 28. 3D visualization of binary data of the different ransomware variants

Visualizing data in such a manner is a way to use the human brain to quickly identify patterns and be able to draw comparisons between objects. In our case, we see that, based on the binary data visualized in Figures 27 and 28, the ransomware binaries do yield differences that we cannot ignore.

Figure 29. Comparison of source code results

Figure 29 shows the results of a source code similarity analysis led on the different variants of ransomware named in the figure itself. Interesting enough, Scarab and Amnesia show a higher overlap with Buran and Zeppelin than the early NetWalker samples. The percentages shown are the amount of code that is similar between two variants.

As illustrated in the overview, the September 2019 NetWalker version has a different codebase from the ErikNetWalker-linked ransomware variants. This finding disproves our earlier hypothesis that NetWalker is linked to the older Amnesia variants based on code overlap.

Often, research teams do not publish their results when it disproves their own hypothesis. However, for the sake of transparency, we decided to include our research efforts.

YARA Rules

We uploaded a YARA rule to detect almost all the samples observed in the wild to date.

Indicators of Compromise

During our investigation we have observed numerous IoCs linked to NetWalker ransomware. To obtain them please visit our McAfee ATR GitHub site, or get the latest NetWalker IoCs and intelligence on many other threats with McAfee Insights.

MITRE ATT&CK Techniques

The below techniques were based on our research and complemented with research from industry peers.

• Initial Access
  • Exploit Public-Facing Application (T1190) : Exploit Tomcat, Exploit WebLogic
  • Spear phishing Attachment (T1566.001): Phishing email
  • Valid Accounts (T1078): RDP compromised
• Execution
  • PowerShell (T1059.001): PowerShell Script
  • Command and Scripting Interpreter: Windows Command Shell (003)
  • Service Execution (T1569.002): PsExec
  • Native API (T1106): Use Windows API functions to inject DLL
  • Windows Management Instrumentation (T1047)
• Persistence
  • Registry Run Key (T1547.001): Place a value on RunOnce key
  • Modify Registry key (T1112): Create its own registry key in \SOFTWARE\<uniquename>
• Privilege Escalation
  • Exploitation for Privilege Escalation (T1068): CVE-2020-0796, CVE-2019-1458, CVE-2017-0213, CVE-2015-1701
  • Process Injection (T1055.001): Reflective DLL Injection
• Defense Evasion
  • Disabling Security Tools (T1562.001): ESET AV Remover, Trend Micro’s Security Agent Uninstall Tool, Microsoft Security Client Uninstall
  • Process Injection (T1055.001): Reflective DLL Injection
  • Deobfuscate/Decode Files or Information (T1140)
  • Obfuscated Files or Information (T1027): PowerShell Script uses Base64 and hexadecimal encoding and XOR-encryption
• Credential Access
  • Credential Dumping (T1003): Mimikatz, Mimidogz, Mimikittenz, Windows Credentials Editor, Pwdump, LaZagne
  • Brute Force (T1110.001): NLBrute
• Discovery
  • Network Service Scanning (T1046): SoftPerfect Network Scanner
  • Security Software Discovery (T1518.001)
  • System Information Discovery (T1082)
• Lateral Movement
  • Third-Party Software (T1072): TeamViewer, Anydesk
  • Service Execution (T 1569.002): PsExec
  • Lateral Tool Transfer (T1570)
• Collection
  • Data from information repositories (T1213)
  • Data from local system (T1005)
  • Data from network shared drive (T1039)
• Command and Control
  • Ingress Tool Transfer (T1105)
• Impact
  • Data Encrypted (T1486): NetWalker Ransomware
  • Inhibit System Recovery (T1490): Shadow Copies Deleted
  • Service Stop (T1489)

Conclusion

Ransomware has evolved into a lucrative business for threat actors, from underground forums selling ransomware, to offering services such as support portals to guide victims through acquiring crypto currency for payment, to the negotiation of the ransom. McAfee’s Advanced Threat Research team has analysed the NetWalker ransomware and have been following its evolution from the initial sighting of the Mailto ransomware to its redevelopment into the NetWalker ransomware. The recent shift to a business-centric model of Ransomware-as-a-Service is a clear sign that it is stepping up, so it seems that the NetWalker group is following in the footsteps of REvil and other successful RaaS groups. The ransomware developers have proven the ability to refocus and capitalize on current world events and develop lures to help ensure the effectiveness of the ransomware, which has allowed them to become selective of their affiliates by limiting access to the ransomware to only those with vetted access to large organizations. As development of the ransomware continues, we have witnessed recent shifts in activity that closely follow in the footsteps of other ransomware developments, including threatening victims with the release of confidential information if the ransom is not met.

McAfee ATR is actively monitoring ransomware threats and will continue to update McAfee MVISION Insights and its social networking channels with new and current information. MVISION Insights is the only proactive endpoint security solution that simultaneously prioritizes and predicts threats that matter to our customers while offering prescriptive guidance on what to do in their local environment. Want to stay ahead of the adversaries? Check out McAfee MVISION Insights for more information. If you want to experience some of the MVISION Insights capabilities, go the Preview of MVISION Insights where you can select the top threat information that is available.

Authored by: Thibault Seret, Valentine Mairet, Jeffrey Sman, Alfred Alvarado, Tim Hux, Alexandre Mundo, John Fokker, Marc Rivero Lopez and Thomas Roccia.

The post Take a “NetWalk” on the Wild Side appeared first on McAfee Blog.

This document has been prepared by McAfee Advanced Threat Research in collaboration with JSOF who discovered and responsibly disclosed the vulnerabilities. It is intended to serve as a joint research effort to produce valuable insights for network administrators and security personnel, looking to further understand these vulnerabilities to defend against exploitation. The signatures produced here should be thoroughly considered and vetted in staging environments prior to being used in production and may benefit from specific tuning to the target deployment. There are technical limitations to this work, including the fact that more complex methods of detection might be required to detect these vulnerabilities. For example, multiple layers of encapsulation may obfuscate the exploitation of the flaws and increase the difficulty of detection.

We have also provided packet captures taken from the vulnerability Proof-of-Concepts as artifacts for testing and deployment of either the signatures below or customized signatures based on the detection logic. Signatures and Lua Scripts are located on ATR’s Github page, as well as inline and in the appendix of this document respectively.

As of this morning (August 5^th), JSOF has presented additional technical detail and exploitation analysis at BlackHat 2020, on the two most critical vulnerabilities in DNS.

The information provided herein is subject to change without notice, and is provided “AS IS”, with all faults, without guarantee or warranty as to the accuracy or applicability of the information to any specific situation or circumstance and for use at your own risk. Additionally, we cannot guarantee any performance or efficacy benchmarks for any of the signatures.

Integer Overflow in tfDnsExpLabelLength Leading to Heap Overflow and RCE

CVE: CVE-2020-11901 (Variant 1)
CVSS: 9
Protocol(s): DNS over UDP (and likely DNS over TCP)
Port(s): 53

Vulnerability description:
In the Treck stack, DNS names are calculated via the function tfDnsExpLabelLength. A bug exists in this function where the computation is performed using an unsigned short, making it possible to overflow the computed value with a specially constructed DNS response packet. Since tfDnsExpLabelLength computes the full length of a DNS name after it is decompressed, it is possible to induce an overflow using a DNS packet far smaller than 2¹⁶ bytes. In some code paths, tfGetRawBuffer is called shortly after tfDnsExpLabelLength, allocating a buffer on the heap where the DNS name will be stored using the size computed by tfDnsExpLabelLength, thus leading to a heap overflow and potential RCE.

While newer versions of the Treck stack will stop copying the DNS name into the buffer as soon as a character that isn’t alphanumeric or a hyphen is reached, older versions do not have this restriction and further use predictable transaction IDs for DNS queries, making this vulnerability easier to exploit.

Limitations or special considerations for detection:
Ideally, detection logic for this vulnerability would involve independently computing the uncompressed length of all DNS names contained within incoming DNS responses. Unfortunately, this may be computationally expensive for a device to perform for every incoming DNS response, especially since each one may contain many DNS names. Instead, we must rely on a combination of heuristics.

Furthermore, it is currently unclear whether exercising this vulnerability is possible when using EDNS(0) or DNS over TCP. We recommend assuming it is possible for the purposes of implementing detection logic.  During our testing, an inconsistency in how Suricata handled DNS over TCP was discovered – in some cases it was correctly identified as DNS traffic and in other cases, it was not. Consequently, two rules have been created to determine the size of DNS over TCP traffic. The second rule uses the TCP primitive instead of the DNS primitive; however, the second rule will only be evaluated if not flagged by the first rule.

Because the Suricata rule in dns_invalid_size.rules uses the DNS responses’ EDNS UDP length, which may be controlled by the attacker, a second upper limit of 4096 bytes is enforced.

Recommended detection criteria:

• The device must be capable of processing DNS traffic and matching responses to their corresponding requests.
• The device must be capable of identifying individual DNS names within individual DNS packets.
• The device should flag any DNS responses whose size exceeds what is “expected”. The expected size depends on the type of DNS packet sent:
  • • For DNS over TCP, the size should not exceed the value specified in the first two bytes of the TCP payload.
    • For DNS over UDP with EDNS(0), the size should not exceed the value negotiated in the request, which is specified in the CLASS field of the OPT RR, if present.
    • For DNS over UDP without EDNS(0), the size should not exceed 512 bytes.
    • These are all checked in dns_invalid_size.rules, which invokes either dns_size.lua or dns_tcp_size.lua for the logic.
• The device should flag DNS responses containing DNS names exceeding 255 bytes (prior to decompression).
  • • This is checked in dns_invalid_name.rules, which invokes dns_invalid_name.lua for the logic.
• The device should flag DNS responses containing DNS names comprised of characters besides a-z, A-Z, 0-9, “-”, “_”, and “*”.
  • • This is also checked in dns_invalid_name.rules, which invokes dns_invalid_name.lua for the logic.
• The device should flag DNS responses containing a large number of DNS compression pointers, particularly pointers one after the other. The specific tolerance will depend on the network.
  • • The device should count all labels starting with the bits 0b10, 0b01, or 0b11 against this pointer total, as vulnerable versions of the Treck stack (incorrectly) classify all labels where the first two bits aren’t 0b00 as compression pointers. In the Lua script, we treat any value above 63 (0x3F) as a pointer for this reason, as any value in that range will have at least one of these bits set.
    • The specific thresholds were set to 40 total pointers in a single DNS packet or 4 consecutive pointers for our implementation of this rule. These values were chosen since they did not seem to trigger any false positives in a very large test PCAP but should be altered as needed to suit typical traffic for the network the rule will be deployed on. The test for consecutive pointers is especially useful since each domain name should only ever have one pointer (at the very end), meaning we should never be seeing many pointers in a row in normal traffic.
    • This is implemented in dns_heap_overflow_variant_1.lua, which is invoked by dns_heap_overflow.rules.
• Implementation of the detection logic above has been split up amongst several Suricata rule files since only the pointer counting logic is specific to this vulnerability. Detection of exploits leveraging this vulnerability are enhanced with the addition of the DNS layer size check, domain name compressed length check, and domain name character check implemented in the other rules, but these are considered to be “helper” signatures and flagging one of these does not necessarily indicate an exploitation attempt for this specific vulnerability.

False positive conditions (signatures detecting non-malicious traffic):
Networks expecting non-malicious traffic containing DNS names using non-alphanumeric characters or an abnormally large number of DNS compression pointers may generate false positives. Unfortunately, checking for pointers in only the domain name fields is insufficient, as a malicious packet could use a compression pointer that points to an arbitrary offset within said packet, so our rule instead checks every byte of the DNS layer. Consequently, Treck’s overly liberal classification of DNS compression pointers means that our rule will often misclassify unrelated bytes in the DNS payload as pointers.

In our testing, we ran into false positives with domain names containing spaces or things like “https://”. Per the RFCs, characters such as “:” and “/” should not be present in domain names but may show up from time to time in real, non-malicious traffic. The list of acceptable characters should be expanded as needed for the targeted network to avoid excessive false positives. That being said, keeping the list of acceptable characters as small as possible will make it more difficult to sneak in shellcode to leverage one of the Ripple20 DNS vulnerabilities.

False positives on the DNS size rules may occur when DNS over TCP is used if Suricata does not properly classify the packet as a DNS packet – something that has occurred multiple times during our testing. This would cause the second size check to occur, which assumes that all traffic over port 53 is DNS traffic and processes the payload accordingly. As a result, any non-DNS traffic on TCP port 53 may cause false positives in this specific case. It is recommended the port number in the rule be adjusted for any network where a different protocol is expected over port 53.

Fragmentation of DNS traffic over TCP may also introduce false positives. If the streams are not properly reconstructed at the time the rules execute on the DNS payload, byte offsets utilized in the attached Lua scripts could analyze incorrect data. Fragmentation in DNS response packets is not common on a standard network unless MTU values have been set particularly low. Each rule should be evaluated independently prior to use in production based on specific network requirements and conditions.

False negative conditions (signatures failing to detect vulnerability/exploitation):
False negatives are more likely as this detection logic relies on heuristics due to computation of the uncompressed DNS name length being too computationally expensive. Carefully constructed malicious packets may be able to circumvent the suggested pointer limitations and still trigger the vulnerability.

Signature(s):
dns_invalid_size.rules:

alert dns any any ‑> any any (msg:"DNS packet too large"; flow:to_client; flowbits:set,flagged; lua:dns_size.lua; sid:2020119014; rev:1;)
Lua script (dns_size.lua) can be found in Appendix A

alert tcp any 53 -> any any (msg:"DNS over TCP packet too large"; flow:to_client,no_frag; flowbits:isnotset,flagged; lua:dns_tcp_size.lua; sid:2020119015; rev:1;)
Lua script (dns_tcp_size.lua) can be found in Appendix A

dns_invalid_name.rules:

alert dns any any -> any any (flow:to_client; msg:"DNS response contains invalid domain name"; lua:dns_invalid_name.lua; sid:2020119013; rev:1;)
Lua script (dns_invalid_name.lua) can be found in Appendix A

dns_heap_overflow.rules:

# Variant 1
alert dns any any -> any any (flow:to_client; msg:"Potential DNS heap overflow exploit (CVE-2020-11901)"; lua:dns_heap_overflow_variant_1.lua; sid:2020119011; rev:1;)
Lua script (dns_heap_overflow_variant_1.lua) can be found in Appendix A

RDATA Length Mismatch in DNS CNAME Records Causes Heap Overflow

CVE: CVE-2020-11901 (Variant 2)
CVSS: 9
Protocol(s): DNS/UDP (and likely DNS/TCP)
Port(s): 53

Vulnerability description:
In some versions of the Treck stack, a vulnerability exists in the way the stack processes DNS responses containing CNAME records. In such records, the length of the buffer allocated to store the DNS name is taken from the RDLENGTH field, while the data written is the full, decompressed domain name, terminating only at a null byte. As a result, if the size of the decompressed domain name specified in RDATA exceeds the provided RDLENGTH in a CNAME record, the excess is written past the end of the allocated buffer, resulting in a heap overflow and potential RCE.

Limitations or special considerations for detection:
Although exploitation of this vulnerability has been confirmed using malicious DNS over UDP packets, it has not been tested using DNS over TCP and it is unclear if such packets would exercise the same vulnerable code path. Until this can be confirmed, detection logic should assume both vectors are vulnerable.

Recommended detection criteria:

• The device must be capable of processing incoming DNS responses.
• The device must be capable of identifying CNAME records within DNS responses
• The device should flag all DNS responses where the actual size of the RDATA field for a CNAME record exceeds the value specified in the same record’s RDLENGTH field.
  • • In this case, the “actual size” corresponds to how vulnerable versions of the Treck stack compute the RDATA length, which involves adding up the size of every label until either null byte, a DNS compression pointer, or the end of the payload is encountered. The Treck stack will follow and decompress the pointer that terminates the domain name, if present, but the script does not as this computation is simply too expensive, as mentioned previously.

False positive conditions (signatures detecting non-malicious traffic):
False positives should be unlikely, but possible in scenarios where network devices send non-malicious traffic where RDLENGTH is not equal to the size of RDATA, thereby breaking RFC 1035.

False negative conditions (signatures failing to detect vulnerability/exploitation):
Since the detection logic does not perform decompression when computing the “actual size” of RDATA, it will fail to detect malicious packets that contain domain names whose length only exceeds RDLENGTH after decompression. Unfortunately, coverage for this case is non-trivial as such packets are actually RFC-compliant. According to RFC 1035, section 4.1.4:

If a domain name is contained in a part of the message subject to a length field (such as the RDATA section of an RR), and compression is used, the length of the compressed name is used in the length calculation, rather than the length of the expanded name.

Besides the computational overhead, enforcing such a check would likely result in very high false positive rates.

Signature(s):
dns_heap_overflow.rules:

# Variant 2
alert dns any any -> any any (flow:to_client; msg:"Potential DNS heap overflow exploit (CVE-2020-11901)"; lua:dns_heap_overflow_variant_2.lua; sid:2020119012; rev:1;)
Lua script (dns_heap_overflow_variant_2.lua) can be found in Appendix A

Write Out-of-Bounds Using Routing Header Type 0

CVE: CVE-2020-11897
CVSS: 10
Protocol(s): IPv6
Port(s): N/A

Vulnerability description:
When processing IPv6 incoming packets, an inconsistency parsing the IPv6 routing header can be triggered where the header length is checked against the total packet and not against the fragment length. This means that if we send fragmented packets with the overall size greater than or equal to the specified routing header length, then we process the routing header under the assumption that we have enough bytes in our current fragment (where we have enough bytes in the overall reassembled packet only). Thus, using routing header type 0 (RH0) we can force read and write into out-of-bounds memory location.

There is also a secondary side effect where we can get an info leak in a source IPv6 address in an ICMP parameter returned from the device.

Limitations or special considerations for detection:
The RFC for RH0 defines the length field as equal to “two times the number of addresses in the header.”  For example, if the routing header length is six, then there are three IPv6 addresses expected in the header. Upon reconstruction of the fragmented packets, the reported number of addresses is filled with data from the fragments that follow. This creates “invalid” IPv6 addresses in the header and potentially malforms the next layer of the packet. During exploitation, it would also be likely for the next layer of the packet to be malformed. Although ICMP can be used to perform an information leak, it is possible for the next layer to be any type and therefore vary in length. Verification of the length of this layer could therefore be very expensive and non-deterministic.

Recommended detection criteria:

• The device must be capable of processing fragmented IPv6 traffic
• The device should inspect fragmented packets containing Routing Header type 0 (RH0). If a RH0 IPv6 packet is fragmented, then the vulnerability is likely being exploited
• If the length of the IPv6 layer of a packet fragment containing the RH0 header is less than the length reported in the routing header, then the vulnerability is likely being exploited
• Upon reconstruction of the fragmented packets, if the header of the layer following IPv6 is malformed, the vulnerability may be being exploited

Notes:
The routing header type 0 was deprecated in IPv6 traffic in RFC 5095 as of December 2007. As a result, it may be feasible simply to detect packets using this criterion. False positives may be possible in this scenario for legacy devices or platforms. Suricata already provides a default rule for this scenario which has been added below. According to the RFC, routers are not supposed to fragment IPv6 packets and must support an MTU of 1280, which would always contain all of the RH0 header, unless an unusual amount of header extensions or an unusually large header is used. If this is followed, then a packet using the RH0 header should never be fragmented across the RH0 extension header bounds and any RH0 packet fragmented in this manner should be treated as potentially malicious. Treating any fragmented RH0 packet as potentially malicious may be sufficient. Furthermore, treating any fragmented RH0 packet with fragments size below a threshold as well as IPv6 packets with multiple extension headers or an unusually large header above a threshold may provide high accuracy detection.

False positive conditions (signatures detecting non-malicious traffic):
If all detection criteria outlined above are used, false positives should be minimal since the reported length of a packet should match its actual length and the next header should never contain malformed data.  If only routing header type 0 is checked, false positives are more likely to occur.  In the additional provided rule, false positives should be minimal since RH0 is deprecated and the ICMP header should never have invalid checksums or unknown codes.

False negative conditions (signatures failing to detect vulnerability/exploitation):
False negatives may occur if the signature is developed overly specific to the layer following IPv6, for example, ICMP.  An attacker could potentially leverage another layer and still exploit the vulnerability without the information leak; however, this would still trigger the default RH0 rule. In the second rule below, false negatives are likely to occur if:

• An attacker uses a non-ICMP layer following the IPv6 layer
• A valid ICMP code is used
• The checksum is valid, and the payload is less than or equal to 5 bytes (this value can be tuned in the signature)

Signature(s):
Ipv6_rh0.rules:

alert ipv6 any any -> any any (msg:"SURICATA RH Type 0"; decode-event:ipv6.rh_type_0; classtype:protocol-command-decode; sid:2200093; rev:2;)

alert ipv6 any any -> any any (msg:"IPv6 RH0 Treck CVE-2020-11897"; decode-event:ipv6.rh_type_0; decode-event:icmpv6.unknown_code; icmpv6-csum:invalid; dsize:>5; sid:2020118971; rev:1;)

IPv4/UDP Tunneling Remote Code Execution

CVE: CVE-2020-11896
CVSS: 10.0
Protocol(s): IPv4/UDP
Port(s): Any

Vulnerability description:
The Treck TCP/IP stack does not properly handle incoming IPv4-in-IPv4 packets with fragmented payload data. This could lead to remote code execution when sending multiple specially crafted tunneled UDP packets to a vulnerable host.

The vulnerability is a result of an incorrect trimming operation when the advertised total IP length (in the packet header) is strictly less than the data available. When sending tunneled IPv4 packets using multiple fragments with a small total IP length value, the TCP/IP stack would execute the trimming operation. This leads to a heap overflow situation when the packet is copied to a destination packet allocated based on the smaller length. When the tunneled IPv4 packets are UDP packets sent to a listening port, there’s a possibility to trigger this exploit if the UDP receive queue is non-empty. This can result in an exploitable heap overflow situation, leading to remote code execution in the context in which the Treck TCP/IP stack runs.

Recommended detection criteria:
In order to detect an ongoing attack, the following conditions should be met if encapsulation can be unpacked:

• The UDP receive queue must be non-empty
• Incoming UDP packets must be fragmented
  • • Flag MF = 1 with any offset, or
    • Flag MF = 0 with non-zero offset
• Fragmented packets must have encapsulated IPv4 packet (upon assembly)
  protocol = 0x4 (IPIP)
• Encapsulated IPv4 packet must be split across 2 packet fragments.
• Reassembled (inner-most) IPv4 packet has incorrect data length stored in IP header.

The fourth condition above is required to activate the code-path which is vulnerable, as it spreads the data to be copied across multiple in-memory buffers. The final detection step is the source of the buffer overflow, as such, triggering on this may be sufficient.

Depending on the limitations of the network inspection device in question, a looser condition could be used, though it may be more prone to false positives.

In order to detect an ongoing attack if encapsulation cannot be unpacked:

• The UDP receive queue must be non-empty
• Incoming UDP packets must be fragmented
  • • Flag MF = 1 with any value in offset field, or
    • Flag MF = 0 with any non-zero value in offset field
• Final fragment has total fragment length longer than offset field.

The final condition shown above is not something that should be seen in a normal network.

Fragmentation, when it occurs, is the result of data overflowing the MTU of a given packet type. This indicates the final fragment should be no larger than any other fragment – and in practice would likely be smaller. The inverse, where the final fragment is somehow larger than previous fragments, indicates that the fragmentation is not the result of MTU overflow, but instead something else. In this case, malicious intent.

As network monitors in common usage are likely to have the ability to unpack encapsulation, only that ruleset is provided.

Limitations or special considerations for detection:
The Treck stack supports (at least) two levels of tunneling. Each tunnel level can be IPv4-in-IPv4, IPv6-in-IPv4, or IPv4-in-IPv6. The above logic is specific to the IPv4-in-IPv4, single level of tunneling case. In cases of deeper nesting, either a recursive check or a full unwrapping of all tunneling layers will be necessary.

False positive conditions (signatures detecting non-malicious traffic):
False positives should be minimal if all detection criteria outlined above are used in the case where the tunneling can be unpacked. In the case where tunneling cannot be unpacked, this is unlikely to trigger many false positives in the presence of standards compliant applications. Fragmentation as seen here is simply not common.

False negative conditions (signatures failing to detect vulnerability/exploitation):
False negatives could occur with deeper levels of nesting, or nesting of IPv6.

Signature(s):
ipv4_tunneling.rules:

alert ip any any -> any any (msg:"IPv4 TUNNELING EXPLOIT (CVE‑2020‑11896)"; ip_proto:4; lua:tunnel_length_check.lua; sid:2020118961; rev:1;)
Lua script (tunnel_length_check.Lua) can be found in Appendix A

Appendix A

Appendix A contains Lua scripts that are required for usage with corresponding Suricata signatures. These scripts are also located on McAfee ATR’s GitHub.

dns_tcp_size.lua: 

dns_size.lua: 

dns_invalid_name.lua:

dns_heap_overflow_variant_1.lua:

dns_heap_overflow_variant_2.lua:

tunnel_length_check.lua:

The post Ripple20 Critical Vulnerabilities – Detection Logic and Signatures appeared first on McAfee Blog.

Co-authored with Jesse Chick, OSU Senior and Former McAfee Intern, Primary Researcher.

Special thanks to Dr. Catherine Huang, McAfee Advanced Analytics Team
Special thanks to Kyle Baldes, Former McAfee Intern

“Face” the Facts

There are 7.6 Billion people in the world. That’s a huge number! In fact, if we all stood shoulder to shoulder on the equator, the number of people in the world would wrap around the earth over 86 times! That’s just the number of living people today; even adding in the history of all people for all time, you will never find two identical human faces. In fact, in even some of the most similar faces recorded (not including twins) it is quite easy to discern multiple differences. This seems almost impossible; it’s just a face, right? Two eyes, a nose, a mouth, ears, eyebrows and potentially other facial hair. Surely, we would have run into identical unrelated humans by this point. Turns out, there’s SO much more to the human face than this which can be more subtle than we often consider; forehead size, shape of the jaw, position of the ears, structure of the nose, and thousands more extremely minute details.

You may be questioning the significance of this detail as it relates to McAfee, or vulnerability research. Today, we’ll explore some work undertaken by McAfee Advanced Threat Research (ATR) in the context of data science and security; specifically, we looked at facial recognition systems and whether they were more, or less susceptible to error than we as human beings.

Look carefully at the four images below; can you spot which of these is fake and which are real?

StyleGAN images

The answer may surprise you; all four images are completely fake – they are 100% computer-generated, and not just parts of different people creativally superimposed. An expert system known as StyleGAN generated each of these, and millions more, with varying degrees of photorealism, from scratch.

This impressive technology is equal parts revolutions in data science and emerging technology that can compute faster and cheaper at a scale we’ve never seen before. It is enabling impressive innovations in data science and image generation or recognition, and can be done in real time or near real time. Some of the most practical applications for this are in the field of facial recognition; simply put, the ability for a computer system to determine whether two images or other media represent the same person or not. The earliest computer facial recognition technology dates back to the 1960s, but until recently, has either been cost-ineffective, false positive or false negative prone, or too slow and inefficient for the intended purpose.

The advancements in technology and breakthroughs in Artificial Intelligence and Machine Learning have enabled several novel applications for facial recognition. First and foremost, it can be used as a highly reliable authentication mechanism; an outstanding example of this is the iPhone. Beginning with the iPhone X in 2017, facial recognition was the new de facto standard for authenticating a user to their mobile device. While Apple uses advanced features such as depth to map the target face, many other mobile devices have implemented more standard methods based on the features of the target face itself; things we as humans see as well, including placement of eyes, width of the nose, and other features that in combination can accurately identify a single user. More simplistic and standard methods such as these may inherently suffer from security limitations relative to more advanced capabilities, such as the 3D camera capture. In a way, this is the whole point; the added complexity of depth information is what makes pixel-manipulation attacks impossible.

Another emerging use case for facial recognition systems is for law enforcement. In 2019, the Metropolitan Police in London announced the rollout of a network of cameras designed to aid police in automating the identification of criminals or missing persons. While widely controversial, the UK is not alone in this initiative; other major cities have piloted or implemented variants of facial recognition with or without the general population’s consent. In China, many of the trains and bus systems leverage facial recognition to identify and authenticate passengers as they board or unboard. Shopping centers and schools across the country are increasingly deploying similar technology.

More recently, in light of racial profiling and racial bias demonstrated repeatedly in facial recognition AI, IBM announced that it would eliminate its facial recognition programs given the way it could be used in law enforcement. Since then, many other major players in the facial recognition business have suspended or eliminated their facial recognition programs. This may be at least partially based on a high profile “false positive” case in which authorities errantly based an arrest of an individual on an incorrect facial recognition match of a black man named Robert Williams. The case is known as the country’s first wrongful arrest directly resulting from facial recognition technology.

Facial recognition has some obvious benefits of course, and this recent article details the use of facial recognition technology in China to track down and reunite a family many years after an abduction. Despite this, it remains a highly polarizing issue with significant privacy concerns, and may require significant further development to reduce some of the inherent flaws.

Live Facial Recognition for Passport Validation

Our next use case for facial recognition may hit closer to home than you realize. Multiple airports, including many in the United States, have deployed facial recognition systems to aid or replace human interaction for passport and identity verification. In fact, I was able to experience one of these myself in the Atlanta airport in 2019. It was far from ready, but travellers can expect to see continued rollouts of this across the country. In fact, based on the global impact COVID-19 has had on travel and sanitization, we are observing an unprecedented rush to implement touchless solutions such as biometrics. This is of course being done from a responsibility standpoint, but also from an airlines and airport profitability perspective. If these two entities can’t convince travelers that their travel experience is low-risk, many voluntary travelers will opt to wait until this assurance is more solid. This article expands on the impact Coronavirus is having on the fledgling market use of passport facial recognition, providing specific insight into Delta and United Airlines’ rapid expansion of the tech into new airports immediately, and further testing and integration in many countries around the world. While this push may result in less physical contact and fewer infections, it may also have the side-effect of exponentially increasing the attack surface of a new target.

The concept of passport control via facial recognition is quite simple. A camera takes a live video and/or photos of your face, and a verification service compares it to an already-existing photo of you, collected earlier. This could be from a passport or a number of other sources such as the Department of Homeland Security database. The “live” photo is most likely processed into a similar format (image size, type of image) as the target photo, and compared. If it matches, the passport holder is authenticated. If not, an alternate source will be checked by a human operator, including boarding passes and forms of ID.

As vulnerability researchers, we need to be able to look at how things work; both the intended method of operation as well as any oversights. As we reflected on this growing technology and the extremely critical decisions it enabled, we considered whether flaws in the underlying system could be leveraged to bypass the target facial recognition systems. More specifically, we wanted to know if we could create “adversarial images” in a passport-style format, that would be incorrectly classified as a targeted individual. (As an aside, we performed related attacks in both digital and physical mediums against image recognition systems, including research we released on the MobilEye camera deployed in certain Tesla vehicles.)

The conceptual attack scenario here is simple. We’ll refer to our attacker as Subject A, and he is on the “no-fly” list – if a live photo or video of him matches a stored passport image, he’ll immediately be refused boarding and flagged, likely for arrest. We’ll assume he’s never submitted a passport photo. Subject A (AKA Jesse), is working together with Subject B (AKA Steve), the accomplice, who is helping him to bypass this system. Jesse is an expert in model hacking and generates a fake image of Steve through a system he builds (much more on this to come). The image has to look like Steve when it’s submitted to the government, but needs to verify Jesse as the same person as the adversarial fake “Steve” in the passport photo. As long as a passport photo system classifies a live photo of Jesse as the target fake image, he’ll be able to bypass the facial recognition.

If this sounds far-fetched to you, it doesn’t to the German government. Recent policy in Germany included verbiage to explicitly disallow morphed or computer-generated combined photos. While the techniques discussed in this link are closely related to this, the approach, techniques and artifacts created in our work vary widely. For example, the concepts of face morphing in general are not novel ideas anymore; yet in our research, we use a more advanced, deep learning-based morphing approach, which is categorically different from the more primitive “weighted averaging” face morphing approach.

Over the course of 6 months, McAfee ATR researcher and intern Jesse Chick studied state-of-the-art machine learning algorithms, read and adopted industry papers, and worked closely with McAfee’s Advanced Analytics team to develop a novel approach to defeating facial recognition systems. To date, the research has progressed through white box and gray box attacks with high levels of success – we hope to inspire or collaborate with other researchers on black box attacks and demonstrate these findings against real world targets such as passport verification systems with the hopes of improving them.

The Method to the Madness

The term GAN is an increasingly-recognized acronym in the data science field. It stands for Generative Adversarial Network and represents a novel concept using one or more “generators” working in tandem with one or more “discriminators.” While this isn’t a data science paper and I won’t go into great detail on GAN, it will be beneficial to understand the concept at a high level. You can think of GAN as a combination of an art critic and an art forger. An art critic must be capable of determining whether a piece of art is real or forged, and of what quality the art is. The forger of course, is simply trying to create fake art that looks as much like the original as possible, to fool the critic. Over time, the forger may outwit the critic, and at other times the opposite may hold true, yet ultimately, over the long run, they will force each other to improve and adapt their methods. In this scenario, the forger is the “generator” and the art critic is the “discriminator.” This concept is analogous to GAN in that the generator and discriminator are both working together and also opposing each other – as the generator creates an image of a face, for example, the discriminator determines whether the image generated actually looks like a face, or if it looks like something else. It rejects the output if it is not satisfied, and the process starts over. This is repeated in the training phase for as long of a time as it takes for the discriminator to be convinced that the generator’s product is high enough quality to “meet the bar.”

One such implementation we saw earlier, StyleGAN, uses these exact properties to generate the photorealistic faces shown above. In fact, the research team tested StyleGAN, but determined it was not aligned with the task we set out to achieve: generating photorealistic faces, but also being able to easily implement an additional step in face verification. More specifically, its sophisticated and niche architecture would have been highly difficult to harness successfully for our purpose of clever face-morphing. For this reason, we opted to go with a relatively new but powerful GAN framework known as CycleGAN.

CycleGAN

CycleGAN is a GAN framework that was released in a paper in 2017. It represents a GAN methodology that uses two generators and two discriminators, and in its most basic sense, is responsible for translating one image to another through the use of GAN.

Image of zebras translated to horses via CycleGAN

There are some subtle but powerful details related to the CycleGAN infrastructure. We won’t go into depth on these, but one important concept is that CycleGAN uses higher level features to translate between images. Instead of taking random “noise” or “pixels” in the way StyleGAN translates into images, this model uses more significant features of the image for translation (shape of head, eye placement, body size, etc…). This works very well for human faces, despite the paper not specifically calling out human facial translation as a strength.

Face Net and InceptionResnetV1

While CycleGAN is an novel use of the GAN model, in and of itself it has been used for image to image translation numerous times. Our facial recognition application facilitated the need for an extension of this single model, with an image verification system. This is where FaceNet came into play. The team realized that not only would our model need to accurately create adversarial images that were photorealistic, it would also need to be verified as the original subject. More on this shortly. FaceNet is a face recognition architecture that was developed by Google in 2015, and was and perhaps still is considered state of the art in its ability to accurately classify faces. It uses a concept called facial embeddings to determine mathematical distances between two faces in a dimension. For the programmers or math experts, 512 dimensional space is used, to be precise, and each embedding is a 512 dimensional list or vector. To the lay person, the less similar the high level facial features are, the further apart the facial embeddings are. Conversely, the more similar the facial features, the closer together these faces are plotted. This concept is ideal for our use of facial recognition, given FaceNet operates against high level features of the face versus individual pixels, for example. This is a central concept and a key differentiator between our research and “shallow”adversarial image creation a la more traditionally used FGSM, JSMA, etc. Creating an attack that operates at the level of human-understandable features is where this research breaks new ground.

One of the top reasons for FaceNet’s popularity is that is uses a pre-trained model with a data set trained on hundreds of millions of facial images. This training was performed using a well-known academic/industry-standard dataset, and these results are readily available  for comparison. Furthermore, it achieved very high published accuracy (99.63%) when used on a set of 13,000 random face images from a benchmark set of data known as LFW (Labeled Faces in the Wild). In our own in-house evaluation testing, our accuracy results were closer to 95%.

Ultimately, given our need to start with a white box to understand the architecture, the solution we chose was a combination of CycleGAN and an open source FaceNet variant architecture known as InceptionResnet version 1. The ResNet family of deep neural networks uses learned filters, known as convolutions, to extract high-level information from visual data. In other words, the role of deep learning in face recognition is to transform an abstract feature from the image domain, i.e. a subject’s identity, into a domain of vectors (AKA embeddings) such that they can be reasoned about mathematically. The “distance” between the outputs of two images depicting the same subject should be mapped to a similar region in the output space, and two very different regions for input depicting different subjects. It should be noted that the success or failure of our attack is contingent on its ability to manipulate the distance between these face embeddings. To be clear, FaceNet is the pipeline consisting of data pre-processing, Inception ResNet V1, and data separation via a learned distance threshold.

Training

Whoever has the most data wins. This truism is especially relevant in the context of machine learning. We knew we would need a large enough data set to accurately train the attack generation model, but we guessed that it would be smaller than many other use cases. This is because given our goal was simply to take two people, subject A (Jesse) and subject B (Steve) below and minimize the “distance” between the two face embeddings produced when inputted into FaceNet, while preserving a misclassification in either direction. In other words, Jesse needed to look like Jesse in his passport photo, and yet be classified as Steve, and vice versa. We’ll describe facial embeddings and visualizations in detail shortly.

The training was done on a set of 1500 images of each of us, captured from live video as stills. We provided multiple expressions and facial gestures that would enrich the training data and accurately represent someone attempting to take a valid passport photo.

The research team then integrated the CycleGAN + FaceNet architecture and began to train the model.

As you can see from the images below, the initial output from the generator is very rough – these certainly look like human beings (sort of), but they’re not easily identifiable and of course have extremely obvious perturbations, otherwise known as “artifacts.”

However, as we progress through training over dozens of cycles, or epochs, a few things are becoming more visually apparent. The faces begin to clean up some of the abnormalities while simultaneously blending features of both subject A and subject B. The (somewhat frightening) results look something like this:

Progressing even further in the training epochs, and the discriminator is starting to become more satisfied with the generator’s output. Yes, we’ve got some detail to clean up, but the image is starting to look much more like subject B.

A couple hundred training epochs in, and we are producing candidates that would meet the bar for this application; they would pass as valid passport photos.

Fake image of Subject B

Remember, that with each iteration through this training process, the results are systematically fed into the facial recognition neural network and classified as Subject A or Subject B. This is essential as any photo that doesn’t “properly misclassify” as the other, doesn’t meet one of the primary objectives and must be rejected. It is also a novel approach as there are very few research projects which combine a GAN and an additional neural network in a cohesive and iterative approach like this.

We can see visually above that the faces being generated at this point are becoming real enough to convince human beings that they are not computer-generated. At the same time, let’s look behind the curtain and see some facial embedding visualizations which may help clarify how this is actually working.

To further understand facial embeddings, we can use the following images to visualize the concept. First, we have the images used for both training and generation of images. In other words, it contains real images from our data set and fake (adversarial) generated images as shown below:

Model Images (Training – Real_A & Real_B) – Generated (Fake_B & Fake_A)

This set of images is just one epoch of the model in action – given the highly realistic fake images generated here, it is not surprisingly a later epoch in the model evaluation.

To view these images as mathematical embeddings, we can use a visualization representing them on a multidimensional plane, which can be rotated to show the distance between them. It’s much easier to see that this model represents a cluster of “Real A” and “Fake B” on one side, and a separate cluster of “Real B” and “Fake A” on the other. This is the ideal attack scenario as it clearly shows how the model will confuse the fake image of the accomplice with the real image of the attacker, our ultimate test.

White Box and Gray Box Application

With much of machine learning, the model must be both effectively trained as well as able to reproduce and replicate results in future applications. For example, consider a food image classifier; its job being to correctly identify and label the type of food it sees in an image. It must have a massive training set so that it recognizes that a French Fry is different than a crab leg, but it also must be able to reproduce that classification on images of food it’s never seen before with a very high accuracy. Our model is somewhat different in that it is trained specifically on two people only (the adversary and the accomplice), and its job is done ahead of time during training. In other words, once we’ve generated a photorealistic image of the attacker that is classified as the accomplice, the model’s job is done. One important caveat is that it must work reliably to both correctly identify people and differentiate people, much like facial recognition would operate in the real world.

The theory behind this is based on the concept of transferability; if the models and features chosen in the development phase (called white box, with full access to the code and knowledge of the internal state of the model and pre-trained parameters) are similar enough to the real-world model and features (black box, no access to code or classifier) an attack will reliably transfer – even if the underlying model architecture is vastly different. This is truly an incredible concept for many people, as it seems like an attacker would need to understand every feature, every line of code, every input and output, to predict how a model will classify “adversarial input.” After all, that’s how classical software security works for the most part. By either directly reading or reverse engineering a piece of code, an attacker can figure out the precise input to trigger a bug. With model hacking (often called adversarial machine learning), we can develop attacks in a lab and transfer them to black box systems. This work, however, will take us through white box and gray box attacks, with possible future work focusing on black box attacks against facial recognition.

As mentioned earlier, a white box attack is one that is developed with full access to the underlying model – either because the researcher developed the model, or they are using an open source architecture. In our case, we did both to identify the ideal combination discussed above, integrating CycleGAN with various open source facial recognition models. The real Google FaceNet is proprietary, but it has been effectively reproduced by researchers as open source frameworks that achieve very similar results, hence our use of Inception Resnet v1. We call these versions of the model “gray box” because they are somewhere in the middle of white box and black box.

To take the concepts above from theory to the real world, we need to implement a physical system that emulates a passport scanner. Without access to the actual target system, we’ll simply use an RGB camera, such as the external one you might see on desktops in a home or office. The underlying camera is likely quite similar to the technology used by a passport photo camera. There’s some guesswork needed to determine what the passport camera is doing, so we take some educated liberties. The first thing to do is programmatically capture every individual frame from the live video and save them in memory for the duration of their use. After that, we apply some image transformations, scaling them to a smaller size and appropriate resolution of a passport-style photo. Finally, we pass each frame to the underlying pretrained model we built and ask it to determine whether the face it is analyzing is Subject A (the attacker), or Subject B (the accomplice). The model has been trained on enough images and variations of both that even changes in posture, position, hair style and more will still cause a misclassification. It’s worth noting that in this attack method, the attacker and accomplice are working together and would likely attempt to look as similar as possible to the original images in the data set the model is trained, as it would increase the overall misclassification confidence.

The Demos

The following demo videos demonstrate this attack using our gray box model. Let’s introduce the 3 players in these videos. In all three, Steve is the attacker now, Sam is our random test person, and Jesse is our accomplice. The first will show the positive test.

Positive Test:

This uses a real, non-generated image on the right side of the screen of Steve (now acting as our attacker). Our random test person (Sam), first stands in front of the live “passport verification camera” and is compared against the real image of Steve. They should of course be classified as different. Now Steve stands in front of the camera and the model correctly identifies him against his picture, taken from the original and unaltered data set. This proves the system can correctly identify Steve as himself.

Negative Test:

Next is the negative test, where the system tests Sam against a real photo of Jesse. He is correctly classified as different, as expected. Then Steve stands in front of the system and confirms the negative test as well, showing that the model correctly differentiates people in non-adversarial conditions.

Adversarial Test:

Finally, in the third video, Sam is evaluated against an adversarial, or fake image of Jesse, generated by our model. Since Sam was not part of the CycleGAN training set designed to cause misclassification, he is correctly shown as different again. Lastly, our attacker Steve stands in front of the live camera and is correctly misclassified as Jesse (now the accomplice). Because the model was trained for either Jesse or Steve to be the adversarial image, in this case we chose Jesse as the fake/adversarial image.

If a passport-scanner were to replace a human being completely in this scenario, it would believe it had just correctly validated that the attacker was the same person stored in the passport database as the accomplice. Given the accomplice is not on a no-fly list and does not have any other restrictions, the attacker can bypass this essential verification step and board the plane. It’s worth noting that a human being would likely spot the difference between the accomplice and attacker, but this research is based off of the inherent risks associated with reliance on AI and ML alone, without providing defense-in-depth or external validation, such as a human being to validate.

Positive Test Video – Confirming Ability to Recognize a Person as Himself

Negative Test Video – Confirming Ability to Tell People Apart

Adversarial Test Video – Confirming Ability to Misclassify with Adversarial Image

What Have we Learned?

Biometrics are an increasingly relied-upon technology to authenticate or verify individuals and are effectively replacing password and other potentially unreliable authentication methods in many cases. However, the reliance on automated systems and machine learning without considering the inherent security flaws present in the mysterious internal mechanics of face-recognition models could provide cyber criminals unique capabilities to bypass critical systems such as automated passport enforcement. To our knowledge, our approach to this research represents the first-of-its-kind application of model hacking and facial recognition. By leveraging the power of data science and security research, we look to work closely with vendors and implementors of these critical systems to design security from the ground up, closing the gaps that weaken these systems. As a call to action, we look to the community for a standard by which can reason formally about the reliability of machine learning systems in the presence of adversarial samples. Such standards exist in many verticals of computer security, including cryptography, protocols, wireless radio frequency and many more. If we are going to continue to hand off critical tasks like authentication to a black box, we had better have a framework for determining acceptable bounds for its resiliency and performance under adverse conditions.

For more information on research efforts by McAfee Advanced Threat Research, please follow our blog or visit our website.

The post Dopple-ganging up on Facial Recognition Systems appeared first on McAfee Blog.

Overview

As part of our continued goal of helping developers provide safer products for businesses and consumers, we here at McAfee Advanced Threat Research (ATR) recently investigated temi, a teleconference robot produced by Robotemi Global Ltd. Our research led us to discover four separate vulnerabilities in the temi robot, which this paper will describe in great detail. These include:

1. CVE-2020-16170 – Use of Hard-Coded Credentials
2. CVE-2020-16168 – Origin Validation Error
3. CVE-2020-16167 – Missing Authentication for Critical Function
4. CVE-2020-16169 – Authentication Bypass Using an Alternate Path of Channel

Together, these vulnerabilities could be used by a malicious actor to spy on temi’s video calls, intercept calls intended for another user, and even remotely operate temi – all with zero authentication.

Per McAfee’s vulnerability disclosure policy, we reported our findings to Robotemi Global Ltd. on March 5, 2020. Shortly thereafter, they responded and began an ongoing dialogue with ATR while they worked to adopt the mitigations we outlined in our disclosure report. As of July 15, 2020, these vulnerabilities have been successfully patched – mitigated in version 120 of the temi’s Robox OS and all versions after 1.3.7931 of the temi Android app. We commend Robotemi for their prompt response and willingness to collaborate throughout this process. We’d go so far as to say this has been one of the most responsive, proactive, and efficient vendors McAfee has had the pleasure of working with.

This paper is intended as a long-form technical analysis of the vulnerability discovery process, the exploits made possible by the vulns, and the potential impact such exploits may have. Those interested in a higher-level, less technical overview of these findings should refer to our summary blog post here.

Contents

Overview
Contents
What is temi
Normal Operation of temi
Initial Recon
Port Scanning
Capturing Traffic
Getting a Shell
Finding temi’s Code
Reversing the Code for Video Calls
Brute-Forcing the Channel Name as an Attack Vector
Exploring MQTT Attack Vectors
Overview
Modifying the temi Phone App
The Relationship Between Robot IDs and MQTT Topics
How are MQTT Call Invite Messages Published?
Intercepting Calls
Problem: temi Won’t Answer My Calls
Solution: Become an OWNER
Adding an OWNER: Phone App’s Perspective
Adding an OWNER: temi’s Perspective
Detour: Sneaking Onto temi’s Contact List
Gaining OWNER Privileges
Refining the Exploits
Impact
Conclusion

What is temi?

Robots.

The final frontier.

For an Android tablet ‘brain’ sitting atop a 4-foot-tall robot, temi packs a lot of sensors into a small form factor. These include 360° LIDAR, three different cameras, five proximity sensors, and even an Inertial Measurement Unit  (IMU) sensor, which is a sort of accelerometer + gyroscope + magnetometer all-in-one. All these work together to give temi something close to the ability to move autonomously through a space while avoiding any obstacles. If it weren’t for the nefarious forces of stairs and curbs, temi would be unstoppable.

Robotemi markets its robot as being used primarily for teleconferencing. Articles linked from the temi website describe the robot’s applications in various industries: Connected Living recently partnered with temi for use in elder care, the Kellog’s café in NYC adopted temi to “enhance the retail experience”, and corporate staffing company Collabera uses temi to “improve cross-office communication.” Despite its slogan of “personal robot”, it appears that temi is designed for both consumer and enterprise applications, and it’s the latter that really got us at McAfee Advanced Threat Research interested in it as a research target. Its growing presence in the medical space, which temi’s creators have accommodated by stepping up production to 1,000 units a month, is especially interesting given the greatly increased demand for remote doctor’s visits. What would a compromised temi mean for its users, whether it be the mother out on business, or the patient being diagnosed via robotic proxy? We placed our preorder and set out to find out.

Normal Operation of temi

Once it finally arrived, we got to setting it up the way any user might: we unboxed it, plugged in its charging dock, and connected it to WiFi. Normal operation of the temi robot is done through the use of its smart phone app, and at first startup temi prompted us to scan a QR code with the app. The phone used to scan the QR code becomes temi’s “admin”, allowing you to control the robot remotely by simply calling it. Temi can have many contacts outside of its singular admin, and becoming a contact is fairly straightforward. Whenever you launch the temi phone app, it scans your phone’s contacts and automatically adds any numbers that have been registered with the temi app to the app’s contact list. If any of those contacts happens to be a temi admin, you can call their temi simply by clicking that contact, as shown in Figure 1.

Figure 1: Selecting a contact from the temi phone app

In this way, users of the phone app besides temi’s admin can still call a temi robot using this method. Since initiating a call with a temi allows you to remotely operate it in addition to seeing through its camera and hearing through its microphone, giving anyone the ability to call your temi could prove… problematic. Temi’s creators address this exact issue on their FAQ page, as shown in Figure 2.

Figure 2: “Can anyone connect to my temi?”, from the temi’s FAQ page

The first line here is a bit misleading, since adding a temi’s admin as a phone contact seems to be sufficient to call that temi – the admin does not need to also have you added as a phone contact for this to work. That being said, this doesn’t mean that just anyone can start controlling your temi; “physical permission on the robot side” is required for calls made by users that aren’t temi’s admin or explicitly authorized by said admin. In practice, this corresponds to a call notification on the temi’s screen that the user can either answer or decline. In other words, it’s no more or less “secure” than receiving cold calls on your cell phone.

As for the last line, which refers to an admin’s ability to grant certain users the option to “hop in” to the robot, this is also done through the phone app by simply selecting the “Invite New Member” option from the temi’s contact entry in the app, and then selecting one or more users from the app’s contact list to “invite”, as shown in Figure 3.

Figure 3: How to grant users special permissions from the phone app

Once a call has been established between the robot and a phone user, which either party may initiate, the phone user can do things like manually drive the robot around, add, remove, and navigate to saved locations, patrol between saved locations, control its volume, and more.

Figure 4: Driving the temi using the phone app

Due to the level of control afforded to temi’s callers, the calling functionality quickly became a priority during our investigation of the temi robot.

Initial Recon

Port Scanning

While a robot was certainly a bit different from our typical targets, we began our reconnaissance with methods that have stood the test of time: port scans, packet captures, and a local shell.

Figure 5: Running Nmap on the temi

An Nmap scan revealed only one open port: TCP port 4443. Immediately we knew that Nmap’s classification of this port being used for Pharos, a “secure office printing solution for your business”, was almost certainly wrong. Instead, it was likely that this port was being used for TLS communication as an alternative to the standard 443. While good to know, this didn’t tell us much about the type of traffic temi expected on this port, or even what service(s) was handling that traffic, so we moved on.

Capturing Traffic

Next on our checklist was to obtain some captures of the robot’s network traffic, focusing on traffic generated during boot, during an update, and during a video call.

Traffic captured when temi was booting up but otherwise idling showed three unique external IP addresses being accessed: 98.137.246.7, 54.85.186.18, and 34.206.180.208.

Running nslookup on these IPs revealed that the first pointed to some Yahoo! media server, likely used for its news app, while the other two appeared to be AWS instances.

Figure 6: Running nslookup on IPs accessed by temi

As for the data being sent/received, there wasn’t much to look at. The Yahoo! address was being accessed via HTTP (port 80), but the TCP packets had no payload. As for the AWS addresses, these were being accessed via TLS (port 443) and the data was encrypted.

For updates, temi accessed “temi-ota-updates.s3-accelerate.amazonaws.com”, which was almost certainly a custom AWS instance set up by the folks at Robotemi. As with the other traffic to AWS, the updates were being encrypted.

Getting a Shell

In order to prod deeper, we needed a local shell on our temi. Fortunately, wireless connections via Android Debug Bridge, or ADB, could be enabled through temi’s settings from its touchscreen. Better still, the shell provided through ADB had root privileges, although the device itself was not “rooted”. This was likely done to help facilitate “temi Developers”, since the temi website has an entire portal dedicated to helping users develop custom apps for their robot.

Unfortunately, the default shell granted via ADB was fairly stripped down, and each reboot would mean having to manually reopen temi’s ADB port from its touchscreen before being able to connect to it again. Furthermore, this method required the temi software to be running in order to access our shell, which would leave us without recourse if our prodding somehow bricked that software. This was far from ideal.

While commands like adb push made moving custom ARM binaries for bash, busybox, and ssh onto temi fairly trivial, getting anything to run on boot proved more challenging. For starters, temi did not have the standard /etc/init.d/ directory. Additionally, the primary scripts that would run on boot, like /init.rc, would be loaded directly from the boot image, meaning any edits made to them would not persist across reboots. This was likely by design as part of Android’s SELinux security model – we would have to be a little more creative if we wanted to convince temi to start an SSH server on boot.

Digging through the contents of /init.rc, however, gave us a clue:

Figure 7: Interesting entry in /init.rc

For those unfamiliar with Android’s Init language,

“The init language is used in plain text files that take the .rc file extension. There are typically multiple of these in multiple locations on the system, described below.
/init.rc is the primary .rc file and is loaded by the init executable at the beginning of its execution. It is responsible for the initial set up of the system.” – Android docs.

The entry shown in Figure 7, one of the hundreds contained in temi’s init.rc, tells the system to launch the service “flash_recovery” during boot with the argument “/system/bin/install-recovery.sh”. The “class main” is just a label used to group entries together, and “oneshot” just means “do not restart the service when it exits.” This entry stood out to us because it was invoking a script located in /system/bin/, which was not loaded from the boot image, meaning any changes should stick. While the /system partition is read-only by default, our root privileges made it trivial to temporarily remount /system as read-write in order to add the following line to the end: “/system/bin/sshd”. With that, we had a reliable means of getting a root shell on our temi to explore further.

Finding temi’s Code

The first thing we did with our newfound freedom was run netstat:

Figure 8: Running netstat

It appeared that most networking, including the open port 4443 we found using Nmap earlier, was being handled by “com.roboteam.teamy.usa”. Based on the name alone, this was likely the main temi software running on the robot. Additionally, the name looked more like the name of an Android package than a native binary. We confirmed this by running:

Figure 9: Trying to find the binary for com.roboteam.teamy.usa in /proc

app_process32 (or app_process64, depending on architecture), is the binary used by Android for running Android apps, meaning we were looking for an APK, not an ELF. Under this assumption, we instead tried to find the code for this process using Android’s pm command:

Figure 10: Looking for the APK for “com.roboteam.teamy.usa”

Sure enough, we had our APK.

Typically, every installed app on Android has a corresponding data directory, and we were able to find the one for this package under /data/data/com.roboteam.teamy.usa:

Figure 11: data directory for “com.roboteam.teamy.usa”

The lib/ directory contained native code used by the package:

Figure 12: native code used by “com.roboteam.teamy.usa”

After looking into several of these libraries, libagora-rtc-sdk-jni.so in particular stood out to us since it was part of Agora, a platform that provides SDKs for voice, video, and Real-Time-Messaging (RTM) services. It was likely that temi was using Agora to implement its video calling functionality – the functionality we were most interested in.

By looking at this binary’s strings, we were also able to determine that temi was using version 2.3.1 of the Agora Video SDK:

Figure 13: Finding the Agora SDK version using strings

Of course, we were equally interested in the code for the temi phone app, which we obtained through the use of APK Extractor and ADB. We were also curious to see if the Android phone app used the same version of the Agora SDK, which we checked by comparing their MD5 hashes:

Figure 14: Comparing MD5 hashes for libagora between temi robot and temi phone app

Sure enough, they were the identical.

Reversing the Code for Video Calls

The next step was to begin reversing these apps in order to better understand how they worked. We decided to start by looking at the phone app’s code, since it was easier to test the behavior of the phone app compared to the robot.

In order to decompile and analyze the APK, we used JADX. Although there are many Java decompilers out there that work on Android code, JADX stood out to us due to its various features:

• It can open APK files directly (will convert .dex to .jar and merge multiple .dex files automatically)
• It handles modern Java features like nested classes and inline lambda functions better than most other decompilers
• For any class being viewed, you can click on the “smali” tab to see the smali code
• It displays line numbers synchronized with the corresponding .line directives in the bytecode, making it easier to map decompiled Java code back to the original bytecode
• You can right-click on any method, member, or class to see its usage or declaration

The temi Android phone app, like most non-trivial Android apps, was massive. Instead of groping in the dark and hoping to stumble upon some interesting code, we decided to take a more targeted approach. From the outset, we knew that our focus was on temi’s calling functionality since this would provide the greatest impact for any attacker. We also now knew that temi was using the Agora SDK to implement this calling functionality. After looking through Agora’s Java API Reference for Android (v2.3.1), we decided that the function joinChannel() would be a good place to start our investigation:

Figure 15: Agora’s documentation for joinChannel()

By opening libagora-rtc-sdk-jni.so in IDA and looking at its exports, we were able to find a function called nativeJoinChannel() at the offset 0xD4484:

Figure 16: Some of libagora’s exports

Using JADX’s search feature, we found a function with the same name in the decompiled code, located on line 960 in the class RtcEngineImpl:

Figure 17: Native Agora methods in RtcEngineImpl

From here, we began the tedious process of working backwards to trace the call chain for video calls all the way to their entry points. We did this by looking for the method that invoked nativeJoinChannel(), then looking for the method that invoked that method, and so on. The return on investment for our tireless efforts was the following:

Figure 18: Code flow diagram for the various ways of making video calls using the temi phone app

At a high level, the code for outgoing calls has four entry-points, and these map 1-to-1 with the four ways of initiating a call from the temi phone app:

1. Select a contact and hit “Call”. This will call that contact’s phone directly, not their temi. This corresponds to the “Contact Details → Contact Call” code path outlined in the graph (green region).
2. Select a contact and, if they have a temi robot, hit “Connect”. This will call their temi and corresponds to the “Contact Details → Robot Call” code path outlined in the graph (orange region).
3. Go to the app’s “Recents” tab and select one of the contacts/robots you have recently called or have called you. This will call that contact or robot and corresponds to the “Recent Calls → Call” code path outlined in the graph (blue region).
4. If you are an admin, select your temi from beneath the “My temi” heading on the “Contacts” tab and hit the “Connect” button from the following screen, also known as the Robot Details screen. This will call your temi and corresponds to the “Robot Details → Call” code path outlined in the graph (red region).

The classes and methods contained within the colored regions handle rendering the screens from which calls can be initiated and the binding of these buttons to the code that actually handles calling. No matter the entry point, all outgoing calls converge at TelepresenceService.initiateCall(), so it’s worth taking a closer look at this method:

Figure 19: TelepresenceService.initiateCall()

And here are the four ways it is invoked:

Contact Details → Contact Call

Figure 20: Invoking initiateCall() from Contact Details → Contact Call

Contact Details → Robot Call

Figure 21: Invoking initiateCall() from Contact Details → Robot Call

Recent Calls → Call

Figure 22: Invoking initiateCall() from Recent Calls → Call

Robot Details → Call

Figure 23: Invoking initiateCall() from Robot Details → Call

The first parameter is an ID used to identify the callee. For temi robots, this appears to be something called a “robot ID”, whereas for contacts it is obtained via a call to getContactId(). Interestingly, for recent calls, which can be either a contact or a robot, the ID is obtained via a call to getMd5PhoneNumber(), which is a bit strange since temi does not (as far as we can tell) have a phone number. We will expand on this later.

The second parameter is a string denoting the caller’s type. Since we were looking at exclusively phone app code here, we assumed that “typeUser” denotes a caller using the phone app.

The third parameter is the callee’s display name – straightforward enough.

The fourth and final parameter is of a custom enum type that denotes the callee’s type. If calling a temi, its type is CallContactType.TEMI_CALL; otherwise, it’s CallContactType.CONTACT_CALL. Note that for the Recent Calls entry point, this value is obtained dynamically, which makes sense since this path handles calls to both contacts and temis.

It’s also worth noting that initiateCall() invokes InvitationManager.createInvitation() in order to create an Invitation object which represents the “call invitation” to be sent to the callee:

Figure 24: InvitationManager.createInvitation()

From there, as seen on line 223 of Figure 19, initiateCall() passes the result of Utils.getRandomSessionId() as the first parameter to createInvitation(), which becomes the sessionId:

Figure 25: Utils.getRandomSessionId()

All this is doing is randomly generating an integer between 100,000 and 999,999, inclusive. In other words, the sessionId is always a positive, six-digit decimal number.

By tracing this value all the way down the call chain to Agora’s nativeJoinChannel(), we discovered that this sessionId becomes the “channelName” parameter described in Figure 15 – the unique identifier for the chatroom for that particular call.  The propagation of this channel name can be seen in Figure 18; the bolded parameter in each method call contains the channel name.

Brute-Forcing the Channel Name as an Attack Vector

So why were we so interested in the Agora channel name? Well, if we look back at Figure 15, we can see that it is one of only two fields needed to join a channel since the third and fourth fields are labeled optional. The only other required field is the “token”, but looking closer at the documentation reveals that “in most circumstances, the static App ID suffices”, and in those cases the token “is optional and can be set as null”:

Figure 26: Agora documentation for joinChannel’s “token” parameter

Our next question was, does temi use a token or does it use a static App ID? We quickly answered that question by looking at how the temi phone app was calling joinChannel():

Figure 27: Agora’s joinChannel() API function being called from AgoraEngine.joinChannel()

Sure enough, the token parameter is being set to null.

This was starting to look promising – if the static App ID and channel name are all that’s needed to join an Agora video call and we already knew that temi’s channel names are restricted to six-digit values, then it might be plausible to join existing temi calls through brute force means. All we would need is this “App ID”.

Looking back at the Agora docs, we looked for which API functions actually use this App Id. As it turned out, there was only one: RtcEngine.create().

Figure 28: Agora documentation for RtcEngine.create()

Put briefly, the App ID is a static value issued to developers that is unique to each project and is used as a sort of namespace, segregating different users of Agora’s servers. This ensures that temi users can only use Agora to call other temi users. Since any temi phone app user should be able to call any temi (or other user), there should be a single App ID shared by all temi robots. We decided to take a look at how temi’s code was invoking RtcEngine.create() to see if we could track down the App ID:

Figure 29: AgoraEngine.ensureRtcEngineReadyLock()

Well, that’s not good.

In our view, this was already a vulnerability, denoted by CVE-2020-16170 and having a CVSS score of 8.2. A dedicated attacker would have no problem iterating over all 900,000 possible channel names. Worse yet, doing so would let the attacker “spray and pray”, allowing them to connect to any ongoing temi call without needing to know anything about their victims.

While we certainly couldn’t test such an exploit against a production server, we did decide to test whether an attacker could join an existing temi call knowing only the App ID and channel name in advance. To facilitate this, we used an Android phone to call our temi, making sure to run logcat on the phone before the call started. Doing so, we were able to capture the invitation message containing the channel name (labeled “sessionId”) as it was being sent to the OkHttp client, which then logged it:

Figure 30: Finding the channel name for the call using logcat

Using the hardcoded App ID and the channel name obtained from the logs we were able to successfully join an ongoing call and get both audio and video from at least one of the other callers, proving that this is a viable attack vector.

Although exploitation of this vulnerability utilizes Agora’s video calling API, its existence is a result of temi’s specific implementation of the SDK. While the decision to hardcode temi’s Agora App ID into the phone app is the root cause of this vulnerability, its impact could also have been substantially mitigated by utilizing a token or by allowing a broader range of channel names. Either of these would have rendered the brute-force attack vector incredibly difficult, if not impossible.

Exploring MQTT Attack Vectors

Overview

Outside of a brute-force method involving joining existing temi calls by trying every possible channel ID, it would be useful to have a more targeted attack vector. Moreover, while joining a call using the brute-force method would let an attacker spy on users, it would not grant them control of the robot itself – we wanted a method that would let us do both. Fortunately, this level of control is already available during normal operation of the temi robot + phone app.

Although temi uses Agora to facilitate video calls, notifying users of incoming calls, through ringing or otherwise, is not a feature implemented by Agora. In the case of temi, this functionality is implemented using MQTT. MQTT is a publish/subscribe (pub/sub) connectivity protocol designed for “machine-to-machine (M2M)/Internet of Things” communication. In it, communications are categorized into “topics” and clients can either “subscribe” to these topics to receive all their related messages, “publish” their own messages to these topics, or both. These topics are structured into a hierarchy delineated in a manner very similar to UNIX-style filesystem naming schemes, with a forward slash (“/”) separating different topic “levels”. Communication between clients is facilitated via a system known as a “broker“, usually implemented as a remote server, which handles establishing and closing connections, message delivery, and client authentication.

Unfortunately, there were several hurdles we would need to overcome in order to leverage temi’s calling functionality as an unauthorized “attacker”.

Firstly, a targeted attack method requires, at a minimum, a reliable way of uniquely identifying the target. In other words, if you are interested in hacking Bob’s temi, you need a way to pick out Bob’s temi from every other temi. A softer but equally important requirement is that this identifier must be one that an attacker could plausibly obtain. The more difficult the identifier is to obtain, the more contrived and unrealistic any attack vectors that rely on this identifier become. As an example, a name or phone number might be a plausible identifier; a social security number, less so.

Reversing temi’s MQTT implementation in its phone app code had revealed a promising potential identifier. We discovered that each robot has its own MQTT topics that it listens on, which are identified using its MQTT client ID, otherwise known as its robot ID. The robot ID for a temi can be easily obtained through normal operation of the phone app by simply adding one of its users as a phone contact, a method we had described previously. This is because the temi phone app allows the user to call any temi registered to a phone number in the user’s contacts list, which requires that temi’s robot ID. If the phone app already has access to this information locally, then it should be hypothetically possible to pull this information from the app.

Second, we needed a way to communicate with temi. If calling is facilitated through the publishing of MQTT messages to certain topics, we needed to find a way to publish our own messages to these same topics. On that note, if all MQTT messages must first pass through the broker, we needed a way to trick the broker into thinking we were a trusted MQTT client and bypass any authentication that might be in place.

One way to overcome this hurdle would be to alter the existing temi phone app. Modifying third party Android apps is a well-known process and would let us leverage the code already present for sending MQTT messages instead of writing this code from scratch. Furthermore, since the phone app requires nothing more than the phone number of one of temi’s users in order to call it (and thus, publish MQTT messages on its topics), this means that the phone app must have a way of authenticating with the broker. If we could send custom MQTT messages to arbitrary topics from the context of a “trusted” phone app, then we likely wouldn’t need to worry about authentication.

This left us with our third and final hurdle: privilege escalation. Although cold calling a temi robot is not difficult to achieve, it does not grant us the ability to remotely operate the robot on its own. This is because calling temi in this way causes it to ring and requires the call to be accepted on temi’s end via its touchscreen. Only temi’s admin, the user who registered it via QR code scan, and privileged users manually selected by this admin may directly control temi without any user interaction on the other end. Thus, we needed to find a way to escalate our privilege so that temi would pick up our calls automatically.

If MQTT is the primary means of communication between temi and its phone app users, and admins can manage the privilege levels of users directly from the phone app, it stands to reason that privilege management is likely performed through MQTT. Thus, if we could alter the phone app to spoof a privilege escalation MQTT message, we could overcome this hurdle, as well.

Modifying the temi Phone App

Since our entire plan hinged on us being able to alter the bytecode of the phone app without either breaking the app or preventing it from authenticating with the various remote servers it communicates with, we decided to first confirm that this was even possible. To accomplish this, we used a combination of ADB, Apktool, Keytool, and Jarsigner.

We began by unpacking the APK file for the temi phone app using Apktool:

Figure 31: Unpacking the temi phone app

Next, we searched the unpacked APK for the file or code we wanted to modify. For our proof-of-concept, we decided to simply change the label for the “Call” button, since it would be immediately obvious whether or not it worked. In many Android apps, the strings used for buttons are typically not hardcoded and are instead loaded from a resource file. In this case, they were loaded from the file res/values/strings.xml:

Figure 32: Searching for the call button label in strings.xml

It looked like line 108 contained the label we wanted to change. We simply replaced “Call” with “PWN” and saved our changes.

Note: For less trivial modifications, like the ones we would need to make later, this process would naturally be more involved. Since even the most sophisticated Java decompilers are unable to produce code that will actually compile for non-trivial apps, meaningful modifications usually mean having to read and modify smali, the assembler for Android’s Dalvik bytecode. That being said, we found that the best approach to making meaningful changes to a complex app like temi’s is to read Java, write smali. By this, we mean that it’s better to do your reversing on decompiled Java code and only look at the nigh-hieroglyphic smali code once you know exactly what changes you want to make and what class to make it in.

Once our modification had been made, we used Apktool again to repack the APK:

Figure 33: Repacking our modified app

Our next step was to sign the modified APK. This is because Android refuses to install any unsigned APKs, even through ADB. First, we generated a key using Keytool:

Figure 34: Generating the key we will use to sign the modified app

and then we used our key to sign the APK using Jarsigner:

Figure 35: Signing the modified app

Finally, we installed the modified APK onto an Android phone using ADB:

Figure 36: Installing the modified app

After launching the app and selecting one of our contacts, we were greeted with a pleasant sight:

Figure 37: Testing the modified app

Furthermore, the change we made did not seem to impact the app’s functionality; we could still make and receive calls, add contacts, etc.

In our view, this was a vulnerability, later denoted by CVE-2020-16168 and having a CVSS score of 6.5. An altered and potentially malicious app could still access the various cloud resources and user information made available to the temi app because no integrity checks were performed by either the app or the remote servers to ensure that the app had not been modified. As we’ll demonstrate later, the presence of this vulnerability made various other attack vectors possible.

The Relationship Between Robot IDs and MQTT Topics

In the overview section, we made the claim that “each robot has its own MQTT topics that it listens on, which are identified using temi’s MQTT client ID, otherwise known as its robot ID.” Here we will outline how we came to this conclusion and the specific format of a few of the topics that temi and its phone app subscribe/publish to.

Since we knew that temi uses MQTT to handle calling notifications, a natural place to start our investigation was the code used by the phone app to initiate calls. Moving down the call chain, we saw that the robot ID was being passed to the sendInitInvitation() method of the TelepresenceService class:

Figure 38: InvitationManagerImpl.sendInitInvitation()

Here, the robot ID is used in two different places. On line 82, an MqttDelegateApi.Topic object is created with the name “users/<ROBOT_ID>/status”, implying that each robot has its own MQTT topic category for its status and the robot ID itself is used to uniquely identify these topics. Next, on line 87, we see one of many RxJava functions (the others have been omitted) with the robot ID passed as a parameter to it. This function’s only purpose is to call InvitationManagerImpl.sendInviteMsg(), passing along the Invitation and the robot ID as its arguments:

Figure 39: InvitationManagerImpl.sendInviteMsg()

This function is of particular interest because we see the construction of another MQTT topic name on line 332, this time taking the form “client/<ROBOT_ID>/invite”. Presumably, this is the topic format used when publishing call invitations to specific temi robots (and, likely, phone contacts).

Additionally, the anonymous function executed via doOnSuccess() uses MqttManager.publish() (line 359) to actually publish the call invitation on the callee’s call invite topic. This information would become useful when we later tried to send custom MQTT messages to our temi in order to facilitate privilege escalation.

How are MQTT Call Invite Messages Published?

If we were to publish our own MQTT messages, we would need a robust understanding of the code used by the temi phone app to publish arbitrary MQTT messages, which appears to be this MqttManagerImpl.publish() method.

To determine what was actually being passed to publish(), we needed to go through what each of the RxJava functions in InvitationManagerImpl.sendInviteMsg() was doing. Referring back to Figure 39:

• On lines 331-339, Single.zip() is called, which simply creates a Pair from the MQTT topic string (“client/<ROBOT_ID>/invite”) and the Invitation object.
• On lines 340-355, Single.flatMap() is called, which adds a timestamp to the Invitation object inside the Pair.
• Presuming successful execution of the previous flatMap() call, Single.doOnSuccess() is called on lines 356-372. As mentioned previously, this is where the call to MqttManagerImpl.publish() occurs. Since this doOnSuccess() operates on the value returned by the previous call to flatMap(), the arguments being passed to publish() are:

While it was obvious that the first argument is the MQTT topic the message is being published on and the second argument is the message itself, it was not immediately obvious what the third and fourth arguments were for. Digging down into the source code of the MQTT package being used (org.eclipse.paho.client.mqttv3) revealed their purpose:

Figure 40: MqttAsyncClient.publish()

After passing through a couple MqttManagerImpl methods, the four arguments listed above become the first four arguments passed to this internal publish() method. The JSON string (second argument), is converted from a string to a byte array in the interim; the rest of the arguments are unchanged.

Knowing this, it was clear that the second argument is indeed the MQTT message, the third argument is the QoS, and the fourth argument is a flag that specifies whether or not the message should be retained. A QoS value of “0” means that the message will be delivered to clients subscribed to the topic at most once. A retained flag of “false” means that new subscribers to the topic will not receive the most recent published message upon subscription.

Intercepting Calls

As we’ve already established, every temi robot has a unique MQTT client ID and many of the topics it subscribes to contain this ID to indicate that they are intended for that specific robot. If users of the temi phone app can receive calls in addition to making them, it stands to reason that they must also have a unique MQTT client ID – a robot ID equivalent. If there was an easy way to discover the client ID of another phone app user, it might be possible to subscribe to their topics and thus receive calls intended for them, making it worthy of investigation.

If we refer back to Figure 22, we saw that if a call is initiated from the Recent Calls screen, a method called getMd5PhoneNumber() is used to obtain the client ID of the callee. While a temi doesn’t have a phone number to speak of, we began to suspect that the client ID for users of the temi phone app might just be an MD5 hash of their phone number.

Although we could have followed the code in order to track down exactly where this value comes from, we thought it might be easier to simply verify our suspicions. To do this, we first took the MD5 hash of the temi admin’s phone number and then performed a string search for this hash in every temi-related file we had access to.

Figure 41: The Google Voice number used to register with temi

Figure 42: Taking the MD5 hash of the phone number

Sure enough, this hash appeared in two places. First, it appeared in the primary SQLite 3 database file for the temi app running on the robot itself. More specifically, it appears in the “RecentCallModel” table under the “userId” column for the table’s only entry. Based on the table’s name and sole entry, this is almost certainly used to store temi’s recent calls, as its admin was the only user it had called at this point.

Figure 43: The matching string in temi’s RecentCallModel table, part of its SQLite 3 Database

The second match was in the log output we saved after running logcat on our temi earlier, the same log output seen in Figure 30:

Figure 44: Matching strings in the logcat output recorded earlier

This log output appears to conclusively confirm our suspicions. With what we knew now, these log messages appeared to be JSON data being sent to/received from the MQTT broker. Moreover, the “topic” string in the first result exactly matched the MQTT topic format string found on line 82 of Figure 38. The only difference is that in that case, the string between “users/” and “/status” was the robot ID; here, it was an MD5 hash of the user’s phone number.

Since we now knew that

1. temi robots and phone app users received calls on the topic “client/<CLIENT_ID>/invite”, where “<CLIENT_ID>” is the MQTT client ID of the callee,
2. the MQTT client ID for phone app users was simply an MD5 hash of the phone number used to register with the app, and
3. we could alter the existing phone app,

it stood to reason that we could modify the app to subscribe to another user’s call invite topic in order to intercept calls intended for that user as long as we knew the user’s phone number. In theory, this would allow an attacker to effectively impersonate another user and spy on them by intercepting their calls. The question then became: What code needs to be modified in order to get this to happen? Well, we’re looking at a situation where temi initiates a call with its admin and an attacker attempts to intercept that call. In the case of calls initiated by the phone app, we discovered that call invitations are sent via InvitationManagerImpl.sendInviteMsg(), which publishes the call invite message on the topic “client/<ROBOT ID>/invite”. We suspected a similar approach was being used when a call is initiated from a temi to a phone user and decided to investigate to confirm.

Luckily for us, the exact same InvitationManagerImpl.sendInviteMsg() method could be found in the temi robot’s code, and it even seemed to function identically. Thus, it was probably safe to assume that the robot initiates calls with phone users in the same way: by publishing a call invitation to the topic “client/<CLIENT ID>/invite”, CLIENT_ID being the MQTT client ID of the callee.

If the caller publishes their call invites to a certain MQTT topic, it follows that the callee must subscribe to that same topic to receive the invite. Now that we knew the format of the call invite topic, the next step was to track down the code used by the Android app to subscribe to this topic so we could alter it to subscribe to the temi admin’s topic instead.

Performing a string search for this pattern in the decompiled phone app’s code produced three unique results:

Figure 45: Searching for “client/.+/invite”

The second result we recognized as being part of the code used to generate an outgoing call invitation. Thus, we were only interested in the first and third results.

We began by looking at the first result, found on line 170 of InvitationManagerImpl.java:

Figure 46: InvitationManagerImpl.sendInviteAbortMsg()

This reference is part of the method InvitationManagerImpl.sendInvitationAbortMsg(). Since we were interested in the code that subscribes to the call invite topic and not the code that publishes messages to it, we moved on.

The third result was found on line 523 of MqttManagerImpl.java:

Figure 47: MqttManagerImpl.buildInviteTopic()

This didn’t tell us anything about how the generated topic is used, so we took a step back and looked at what code invokes this method:

Figure 48: MqttManagerImpl.lambda$initMqttClient$13()

The call to buildInviteTopic() can be seen on line 408. There’s a lot going on in this method, but at a high level it appears that it is responsible for setting the callback functions for the MqttManager, which are being defined inline. More specifically, the invite topic string generated by buildInviteTopic() is used in the connectComplete() callback function, where it is passed as the first parameter to MqttManagerImpl.subscribe().

As expected, MqttManager’s subscribe() method is used to a subscribe to a particular MQTT topic, with the first parameter being the topic string:

Figure 49: MqttMangerImpl.subscribe()

Thus, it appeared that we had found the code being used to subscribe to the call invite MQTT topic. Based on these findings, we decided the simplest approach would be to change the call to MqttManagerImpl.subscribe() on line 408 of Figure 48 – instead of passing it the topic string returned by MqttManagerImpl.buildInviteTopic(), we would instead hard-code it to pass the temi admin’s call invite MQTT topic string.

Using this approach, we were able to construct a modified temi phone app that would receive all calls intended for another user, as shown in the following video:

Here, the vulnerability was the lack of any authentication when publishing or subscribing to arbitrary topics, denoted by CVE-2020-16167 and having a CVSS score of 8.6. At a minimum, a check should have been made to ensure that clients cannot subscribe to another client’s topics.

Problem: temi Won’t Answer My Calls

Our next goal was to gain the ability initiate a call with a temi and have it automatically answer. As mentioned previously, this capability is typically reserved for the temi’s admin and users explicitly authorized by the admin. Thus, if an attacker wishes to spy on a temi user, they would need to trick temi into thinking the call is originating from one of these authorized users.

With no other leads, we began searching through the robot’s codebase for keywords related to user permissions, ownership, admin, etc. until we found a very promising enum class:

Figure 50: Class used for delineating the various roles held by temi’s users

This enum is used in com.roboteam.teamy.users.User, the class used to store information about individual temi users, with User.role being an object of the Role enum class:

Figure 51: Class used to describe individual temi users/contacts

Going back to Figure 50, if we assume that Role.ADMIN refers to the user that originally registered temi and that Role.CONTACT refers to a normal user, then Role.OWNER likely refers to a user that has been authorized to “hop in” to the robot by the admin. To verify this, we looked for places in the code where this enum is used. There are 59 unique references to the Role class, but we’ll only be looking at the pertinent ones here.

The first reference we’ll be looking at appears on lines 351 and 357 of ConferencePresenter.handleViewForCallTypes():

Figure 52: ConferencePresenter.handleViewForCallTypes()

On line 351, a string comparison is performed between this.resourcesLoader.getString(R.string.privacy_support_support_caller_name) and this.callerDisplayName; if the two match, a new User is created with a role of CONTACT. So just what is this string that the ‘if’ statement is checking against? We decided to take a look at where this constant is defined:

Figure 53: Searching for “privacy_support_support_caller_name”

Taken together, this means that if the caller’s display name is exactly “Support”, a new User is created with CONTACT privileges. This check likely exists in the event that a member of temi’s support staff calls a user. While this was certainly interesting, it is a niche scenario.

What happens if the caller’s name is not “Support”? In that case, the else statement on line 352 is hit, which simply sets user to the result of getUserbyPeerId():

Figure 54: ConferencePresenter.getUserByPeerId()

This method tries to obtain the User associated with the current caller by performing a lookup in temi’s UsersRepository using the caller’s MQTT client ID. If the lookup succeeds, the found User is returned; if it fails, a new User is created with Role.CONTACT privileges.

As mentioned previously, Figure 52 contains two references to the Role class. Let’s now look at the second reference, found on line 357. Here, the role of the user is checked. If they are either an ADMIN or an OWNER, temi:

• waits 1.5 seconds (line 362)
• checks if the call hasn’t already ended (line 365)
• if it hasn’t, answers the incoming call (line 370)

Otherwise, the function returns after setting the app’s view for an incoming call.

Solution: Become an OWNER

To recap what we’ve learned thus far:

• The role of ADMIN appears to be reserved for the user that originally registers temi via QR code scan.
• If the user calling temi is not recognized, a new User object is created for them with CONTACT privileges.
• If the user calling temi is recognized, their role is checked:
  • If they are a CONTACT, temi waits for the call to be answered via touchscreen.
  • If they are either an ADMIN or an OWNER, temi answers the call automatically. This is the behavior we want.

Scanning the temi’s QR code for the purposes of registration is only possible when temi is first powered on or after performing a factory reset. Thus, the attacker cannot realistically make themselves an ADMIN. And since CONTACT privileges are insufficient to get temi to pick up automatically, our best bet was to figure out how to obtain the role of OWNER.

Adding an OWNER: Phone App’s Perspective

Although we knew that it was possible to promote a user to an OWNER using the phone app and we suspected that was achieved via MQTT, we still weren’t sure of what goes on “under the hood” to make that happen.

After some searching, we found that AddOwnersPresenter.addOwners() is called whenever an admin selects one or more users to be granted OWNER privileges:

Figure 55: AddOwnersPresenter.addOwners(), trimmed

Here, selectedIds refers to the MQTT client IDs of the users selected to be promoted and robotId refers to the MQTT client ID of the temi robot this method is granting permissions for.

The majority of this method’s body has been trimmed because we’re really only concerned with what’s happening on lines 104-106, which seems to handle sending the request to add an OWNER – the rest of the method is dedicated to logging and updating local databases to reflect the new OWNERs.

This request is sent by first fetching the unique private key used to identify this app’s instance (line 101), and then creating a new AddRemoveOwnersRequest using the selectedIds, robotId, and this private key:

Figure 56: AddRemoveOwnersRequest

The constructor for AddRemoveOwnersRequest creates a timestamp for the request, then creates a new AddOwnersRequestRequest, which contains the body of the request, and finally uses the passed in privateKey in order generate a signature for the AddOwnersRequestRequest. In other words, AddRemoveOwnersRequest is nothing more than a wrapper for the real request and is used to store its signature.

We decided to look at this AddOwnersRequestRequest object next. While the ownerIds, robotId, and timestamp members were mostly self-explanatory, source and type were less so. Looking back at line 8, we saw that source was being set to a hardcoded value of “ADMIN”, which seemed to imply that this was the origin of the request. Looking back at line 6, we saw that type is simply the passed in OwnersRequestType enum (in our case, OWNERS_ADD_TYPE) converted to a string. This enum, defined near the bottom of the class, can take on two values: OWNERS_ADD_TYPE and OWNERS_REMOVE_TYPE. This implied that this same structure was recycled for requests meant to demote OWNERs back to CONTACTs.

Thus, we determined that AddRemoveOwnersRequests had the following structure:

Figure 57: Anatomy of an AddRemoveOwnersRequest

Now that we knew the structure of these requests, we next wanted to know how they were being sent and where. To this end, we decided to look at OwnersApi.addOwners(), which, according to Figure 55, is actually sending the AddRemoveOwnersRequest.

Figure 58: OwnersApi.addOwners()

The body of this method didn’t tell us much, but the imports for the OwnersApi class gave us a clue: this was using the Retrofit 2 HTTP Client for Android, which is typically used to send HTTP requests to a REST API. According to this Retrofit tutorial, the @POST annotation “indicates that we want to execute a POST request when this method is called” and “the argument value for the @POST annotation is the endpoint.” The @Body annotation, on the other hand, indicates that we want the AddRemoveOwnersRequest to serve as the body of the POST request.

Okay, so this method is simply sending the request to add an OWNER via POST to some REST server at the endpoint “ownership/admin/add/owners”. Our next question became: Where is this REST server located?

Part 5 of that same Retrofit tutorial told us that the getClient() method is typically used to obtain/create a Retrofit instance, and the only argument it takes is a string containing the URL for the REST server. Searching for “getClient()” in the phone app’s code led us to ApiClient.getClient():

Figure 59: ApiClient.getClient()

Working backwards from this method, we were able to track down the server’s URL:

Figure 60: URLs for the MQTT broker and REST server

This URL confirmed that the recipient of this request was not the temi robot and it was not being sent via MQTT, contrary to our initial assumptions. This begged the question: If the phone app wasn’t sending these requests to temi, how was temi being notified of any updates to the privileges of its users? We hypothesized that this REST server was simply a middleman whose job was to authenticate all requests to add/remove OWNERs by checking the request’s signature against the admin’s public key that was saved during temi’s initial registration process. This extra level of authentication made sense since privilege management was a particularly sensitive functionality. Presumably, this same REST server would then forward the request to the robot if it determined that the request’s signature was valid.

We took some time trying to send these requests from a user that wasn’t temi’s admin, but they failed, lending some credence to our theory. This was looking like a dead end.

Adding an OWNER: temi’s Perspective

Well, if we couldn’t successfully spoof the request the phone app sends to the REST server, perhaps we could instead spoof the request the server sends to temi, bypassing the authentication mechanism altogether. We started looking for the code temi used to handle these requests.

Searching specifically for “Role.OWNER” in the temi’s decompiled code led us to OwnersController$getUsersRepository$2.apply():

Figure 61: OwnersController$getUsersRepository$2.apply()

Starting with OwnersController$getUsersRepository$2, we moved up the call chain in an attempt to discover how temi processes requests to add OWNERs. More concretely, this was accomplished through a liberal use of the “Find Usage” feature in JADX, which can be done by simply right-clicking virtually any symbol. Although convenient, “Find Usage” would often fail when the method in question was not invoked directly, such as when an implementation of an abstract class/interface served as the middleman. In such cases, we would perform a string search for instances where the method was invoked in the smali code. To help separate invocations from declarations, we took advantage of the smali syntax for method calls, which consisted of the name of the class the method belonged to, followed by a right arrow (->), followed by the method’s signature.

As an example, “Find Usage” failed for the accept() method of the class UsersAdminTopicListener$listenToUserAdminTopic$1, so to find where it’s invoked, we ran:

Figure 62: Searching for UsersAdminTopicListener$listenToUserAdminTopic$1.accept() in the smali code

For especially indirect invocations, like dependency injection, more creative means had to be used, but a combination of “Find Usage” and string searches such as these got us 99% of the way there.

Using this approach, we found that the mechanism begins with the UsersAdminTopicListener class, which, as the name suggests, handles listening on temi’s “users admin” topic. Moving down the call chain from here, we found out how messages received on this topic are processed by temi and ultimately used to alter the Role, or privilege level, of certain contacts. Based on our earlier analysis, it was likely that the REST server would forward the request sent by the phone app to this MQTT topic.

We found that the bulk of the work is performed by a method called listenToUserAdminTopic():

Figure 63: UsersAdminTopicListener.listenToUserAdminTopic()

This function does several things. First, on line 50, it creates a Flowable object by calling UsersAdminTopicListener.getOwnerRequestFlowable(). Next, on lines 51-56, it subscribes to this Flowable and for each emitted OwnersRequest, it calls OwnersController.handle$app_usaDemoRelease() upon success or simply logs upon failure.

We decided to first look at the code for getOwnerRequestFlowable():

Figure 64: UsersAdminTopicListener.getOwnerRequestFlowable()

• It begins by first converting an Observable obtained via mqttPipeline.observe() into a Flowable.
• Next, it throws out all emitted MqttMessages whose topic doesn’t match the regex “users/.+/admin” via RxJava’s filter() method.
• RxJava’s map() method is then used convert the body of the MqttMessage from JSON to an object of the OwnersMessage
• Finally, map() is used a second time to extract and return the OwnersRequest from each OwnersMessage.

At this point, we decided it would be useful to understand the structure of OwnersRequests and OwnersMessages, since these seem to be key to temi’s privilege management mechanisms:

Figure 65: Anatomy of an OwnersMessage

Put briefly, each OwnersMessage is nothing more than a wrapper for an OwnersRequest, which consists of ownerIds, a list of the MQTT client IDs of the users whose privileges are being modified, and type, which indicates whether the request is trying to promote a CONTACT to an OWNER (OWNERS_ADD) or demote an OWNER back to a CONTACT (OWNERS_REMOVE).

Comparing this to Figure 57, an OwnersMessage appears to be an AddRemoveOwnersRequest without the signature. Similarly, an OwnersRequest appears to be a stripped-down AddOwnersRequestRequest, with the robotId, source, and timestamp omitted. This meshes well with our earlier hypothesis that the REST server’s job is to authenticate and forward AddRemoveOwnersRequests to the temi robot. The signature, timestamp, and source would be omitted since they’ve already been verified by the server; the robotId, while needed by the server to know where to forward the request, becomes redundant once the request reaches temi.

Our next step was to figure out what handle$app_usaDemoRelease() does. Since it’s quite the rabbit hole, however, we will summarize its effects in lieu of venturing down it:

1. It queries the Users table in temi’s local database for all users with IDs matching any of the ones in the OwnersRequest’s ownerIds
2. It replaces the Role for each of these users with one corresponding to the OwnersRequest’s type: OWNERS_ADD→ OWNER, OWNERS_REMOVE → CONTACT.
3. It updates temi’s Users table with the updated user information.

This was promising, since it meant that we could potentially trick temi into promoting an arbitrary user/contact to an OWNER simply by crafting a custom OwnersRequest and publishing it on temi’s “users/<ROBOT_ID>/admin” topic, thereby bypassing the authentication server entirely.

Unfortunately, part 1 above reveals a potential obstacle for this plan: since temi will only process OwnersRequests for users already present in its local Users table, we must first add ourselves to this table for this strategy to succeed. Recalling our earlier analysis of how temi handles unrecognized callers, one way of accomplishing this was to simply cold call temi, which would cause it to automatically add the caller to its contacts list. This was far from ideal, however, since cold calling  temi without already having the role of OWNER or ADMIN would cause it to ring and display the caller’s username on its screen, potentially alerting temi’s users that something weird is going on.

Detour: Sneaking Onto temi’s Contact List

Before continuing on, we decided to take a brief detour to find a better way for an attacker to add themselves to temi’s contact list.

From our prior investigation into how temi implements its various privilege levels through the use of Roles, we discovered that temi uses the User class to define its various users. Thus, it follows that any code used to add a new user to temi’s local contact list would first create a new User object, so that’s exactly what we searched for.

Figure 66: Searching temi’s code for “new User(“, trimmed

Figure 66 shows the result that we followed up on, the others have been omitted. The name of the containing class, SyncContactsController, sounded promising on its own since syncing contacts from temi’s ADMIN would likely involve adding new contacts without needing to start a call, which was exactly what we were trying to do.

Using largely the same strategy we employed for tracing the code flow for adding OWNERs (JADX’s “Find Usage” feature + grepping the smali code), we were able to trace the code flow all the way back to the app’s entry point. With a more holistic understanding of the mechanism used to sync contacts, we realized that the process is ultimately kicked off by SyncContactsTopicListener.subscribeMqttPipeline():

Figure 67: SyncContactsTopicListener.subscribeMqttPipeline()

The first thing this method does is take this.mqttPipeline and turns it first into an Observable (using MqttPipeline.observe()) and then into a Flowable (using RxJavaInterop.toV2Flowable()), as seen on lines 29 and 30.

Essentially, this.mqttPipeline acts as a relay. Incoming MQTT messages are pushed to the relay using its push() method, which it then relays to all its observers.

The output of this relay is then filtered on lines 31-38 to only return MQTT messages received on topics matching the regex “synccontacts/.+”. Based on the other MQTT topic strings we’ve seen up to this point –

• “users/<CLIENT_ID>/status”
• “users/<CLIENT_ID>/admin”
• “client/<CLIENT_ID>/invite”

– we were fairly certain temi’s client ID goes after the forward slash. Thus, temi appeared to be listening on the MQTT topic “synccontacts/<CLIENT_ID>” for messages regarding contact synchronization.

On lines 39-43, the now-filtered MQTT messages emitted by the relay are passed to a call to RxJava’s map() function, which converts each incoming MQTT message from JSON to an object of the SyncContactsMessage class. We quickly determined that SyncContactsMessages had the following structure:

Figure 68: Anatomy of a SyncContactsMessage

Put briefly, each SyncContactsMessage consisted of a senderClientId, a string holding the MQTT client ID of the request’s sender, and contacts, a list of ContactEntry objects. Each ContactEntry object in the list corresponded to a contact to be synced to temi’s contact list, containing both their clientId and their name.

Finally, on lines 45-49, SyncContactsController.save() would be called on each SyncContactsMessage spit out by the prior call to map():

Figure 69: SyncContactsController.save()

This method is doing a lot, but we’ll focus on only the most pertinent side-effects:

• On lines 53-62, all messages where the senderClientId does not match the temi admin’s client ID are discarded. This will become important later.
• On lines 63-75, the list of contacts is extracted from the SyncContactsMessage and is used to build a list of User objects – one per contact. The Users produced by this method are initialized in the following manner:

• On lines 81-85, our newly-minted list of User objects is passed to insertOrUpdateContact(). This method writes the list of Users to the Users table in temi’s SQLite 3 database, completely overwriting temi’s old contacts list in the process.

So now that we knew how an ADMIN’s contacts are synced to their temi, how could we leverage that knowledge to add ourselves to temi’s contact list in a discrete fashion? Well, if we could publish a message to temi’s synccontacts MQTT topic, we could add ourselves as a contact. Although temi does perform a check to make sure that the sender of the message is its ADMIN, it makes the mistake of trusting that the contents of the message accurately reflect the actual sender. In theory, there’s nothing stopping us from publishing a SyncContactsMessage from one client ID and setting the senderClientId field in the message to a completely different ID – the ADMIN’s client ID, for example.

Based on our understanding of how the temi robot parses MQTT requests to sync contacts, we crafted a JSON message that should decode into a valid SyncContactsMessage object and would add our “attack” phone to temi’s contacts:

Figure 70: Our custom SyncContactsMessage in JSON format

This message was crafted using the following rationale:

1. Objects in JSON are indicated via curly braces ({}). Since the entire message contents are being converted into a single SyncContactsMessageobject, it follows that the contents should be contained within a pair of curly braces, representing the SyncContactsMessage object itself.
2. A SyncContactsMessagecontains a senderClientId, a string indicating the client ID of the “sender” of the message. Thus, we added an element to our object with the key “senderClientId” and the string “060f62296e1ab8d0272b623f2f08f915” – the client ID of the temi’s admin – as its value.
3. A SyncContactsMessagealso contains contacts, a list of ContactEntry Thus, we added an element with the key “contacts” and a new list as its value. In JSON, lists are indicated via square brackets ([]).
4. In our case, the contacts list contains only a single ContactEntry – one corresponding to the “attack” phone, so we added a single pair of curly braces to the list to indicate the contents of this single ContactEntry.
5. Each ContactEntry contains a clientId. Thus, we added an element to the object with the key “clientId” and the string “fe5d7af42433f0b6fb6875b6d640931b” – the client ID of the “attack” phone – as its value.
6. Each ContactEntry also contains a name. Thus, we added a second element to the object with the key “name” and the string “Test” as its value. This simply represents the display name for the contact, so we could set it to basically whatever we liked.
7. As for spacing and newlines, we referred to the Gson User Guide, since that’s the library temi was using to perform JSON serialization/deserialization. The guide states:

“The default JSON output that is provided by Gson is a compact JSON format. This means that there will not be any whitespace in the output JSON structure. Therefore, there will be no whitespace between field names and its value, object fields, and objects within arrays in the JSON output.”

As a result, whitespace and newlines have been omitted.

Now that we understood where to publish the request and what the request should look like, the next step was figuring out how to alter the temi phone app to send this request. Since we were aiming for a simple proof-of-concept, we prioritized ease and speed of implementation over robustness or elegance when considering which code to change. To this end, it made sense to leverage the code already present in the app that was dedicated to publishing MQTT messages since it would minimize the amount of code we needed to change and thus reduce the risk of introducing unintended bugs into our altered app – an ever-present risk when directly modifying an app’s bytecode. While the phone app publishes many MQTT messages to various topics during its runtime, we decided to try using the phone app’s video calling functionality. This had the obvious advantage of giving us clear control over when and how often the MQTT message is published, since calls are always initiated by hitting the “Connect” or “Call” buttons. Ultimately, we decided to leverage InvitationManagerImpl.sendInviteMsg() for this purpose. If we refer back to Figure 39 and our section “How are MQTT Call Invite Messages Published?”, the reason for this becomes apparent: sendInviteMsg() has a direct interface to MqttManagerImpl.publish(), the underlying method temi uses to publish arbitrary MQTT messages, while still being specific to the call chain for outgoing video calls. This meant that it would only get executed unless when we manually initiated a call from the app.

Running our altered app resulted in our attack phone being added to temi’s contact list, as shown in the following video:

Gaining OWNER Privileges

All that was left was for us to craft and publish a custom OwnersMessage in order to gain OWNER privileges on our temi. As before, we began by crafting the JSON for the message itself:

Figure 71: Our custom OwnersMessage in JSON format

This message was crafted using the following rationale:

1. Since the entire message contents are being converted into a single OwnersMessage object, it follows that the contents should be contained within a pair of curly braces, representing the OwnersMessage object itself.
2. An OwnersMessage contains a request, an object of the OwnersRequest class, and nothing else. Thus, we added an element with the key “request” and a new object as its value. The contents of this inner object will become our OwnersRequest.
3. An OwnersRequest contains a type, an enum specifying the type of request. In our case we want to add an OWNER, so we added an element with the key “type” and the string “OWNERS_ADD” as its value. As for why we’re expressing this enum value as a string, it’s because this article shows that Gson’s default behavior is to express enum values as strings corresponding to the name of the enum value.
4. An OwnersRequest also contains ownerIds, a list of strings enumerating the temi contacts the request should apply to. In our case, the list contains only a single ID – the ID of the “attack” phone, which is just the MD5 hash of its phone number.
5. As before, spaces and newlines have been omitted, per the Gson User Guide.

Fortunately, we were able to leverage the code modifications we used to publish our SyncContactsMessage, since the only things changing were the MQTT topic we’re publishing to and the contents of the message.

Our full test consisted of running our first modified app in order to add ourselves to temi’s contact list, followed by our second modified app in order to perform privilege escalation, as shown in the following video:

The call appeared to be fully functional, and we were able to drive temi around, navigate to its saved locations, and receive its audio/video feeds. All an attacker needed to make this possible was the phone number of one of temi’s contacts.

This authentication bypass was the final and most impactful vulnerability we discovered in the temi robot, denoted by CVE-2020-16169 and having a CVSS score of 9.4. To better understand how this an auth bypass, let’s compare temi’s privilege management during normal operation:

Figure 72: temi’s privilege management during normal operation

to how it looks using our modified app:

Figure 73: temi’s privilege management with auth bypass

As you can see, although authentication is in place for adding OWNERs, it can be circumvented entirely by simply spoofing the MQTT message temi expects to receive from the REST server post-authentication.

Refining the Exploits

Once our exploits had the capabilities we initially set out to obtain, we got to work refining them. We created a single modified app that combined all of the MQTT attack vectors we previously outlined: it could intercept calls and send both MQTT messages necessary to obtain OWNER privileges, all with a single button press. Furthermore, we added some additional logic to automatically extract the client IDs required by our custom MQTT messages from the app’s contact list, meaning our app would work on any temi robot. To see all these features in action, please refer to the video below:

Impact

At this point it would be prudent to take a step back, review the combined capabilities of the exploits we’ve outlined, and consider what impact these might have in a real-world setting.

At the time of discovery, the vulnerabilities in the temi robot meant that an attacker could join any ongoing temi call simply by using a custom Agora app initialized with temi’s hardcoded App ID and iterating over all 900,000 possible channel names – certainly feasible with modern computing power. This becomes more plausible if one considers that our testing revealed that joining a temi call this way does not notify either of the existing call participants that another user is present, since the apps were only designed with 1-on-1 calling in mind. The fact that the attacker needs no information on the victims makes this attack vector worrisome, but it also means that the attacker has no control over who he or she spies on using this method. Realistically, a malicious actor might use this exploit as a means of reconnaissance – by collecting data on arbitrary temi users, they could follow up on the more “promising” ones later with one of the targeted attack vectors. Given temi’s limited adoption by consumers but ramping adoption in industries such as healthcare, the odds are in the attacker’s favor that they stumble upon sensitive information.

Furthermore, if an attacker has a specific victim in mind, they could leverage the lack of per-topic authentication in temi’s MQTT implementation in order to intercept calls between a user and their temi. The plausibility of this particular attack vector is difficult to evaluate. On the one hand, the only information the attacker needs is the victim’s phone number, and telemarketers consistently remind us that this is a very low bar. On the other hand, this exploit’s behavior during our testing proved somewhat inconsistent. At times, the user running the exploit could listen in on the call as a third party with the call participants being none the wiser. At other times, the user running the exploit would disconnect the original caller and take their place. It is easy to imagine scenarios where both of these outcomes are desirable to a malicious actor, and neither bodes well for the privacy of the user being targeted. It is also important to note that although we focused on using this vulnerability to intercept calls, it can also be used to intercept all sorts of notifications intended for another user: contacts being added, when temi goes online/offline, its current location, etc. While less flashy than intercepting a call, this approach is more discreet and might allow a dedicated attacker to learn a user’s routine, only showing their hand to listen in when it would be most impactful.

Of the possible attack vectors, we believe that the ability to call and control a temi remotely, leveraging the authentication bypass present in temi’s privilege management mechanism, is the most impactful. The bar for this attack vector is arguably even lower than the previous, as the attacker would only need the phone number of any of temi’s contacts – it need not be its admin. In our testing, none of the steps involved in leveraging this exploit notify temi’s admin in any way that something is amiss; they are not notified that the attacker has added themselves to the robot’s contact list nor that they have gained raised privileges. Since this method does not cause temi to ring, an observer would have to see the attacker move temi or have a good look at its touchscreen during the attack to know something nefarious was going on. This level of control and subtlety becomes especially problematic when we consider some of temi’s applications in industry. In April of this year, Robotemi Global Ltd. stepped up production to 1,000 units per month in response to Israel’s Ministries of Defense and Health choosing temi to assist with patients in their COVID-19 wards. In South Korea, temi sees use in both public places and nursing homes, helping to facilitate social distancing. Besides the obvious impact of compromising patients’ sensitive medical information during remote doctor’s visits, the ability to have eyes and ears into a hospital is worrying in its own right. It isn’t difficult to imagine what a malicious agent might do with an overheard network password, access code to a sensitive area, or the location and condition of a person of interest.

Conclusion

The findings outlined in this paper highlight the importance of secure coding practices and security auditing for cutting edge technologies, particularly in the IoT space. When an IoT camera evolves into one that can also drive around your home or business and even assist medical patients, the need to properly secure who can access it only becomes more important. While history has demonstrated that any sufficiently complex software is bound to have vulnerabilities, there are many steps we can take to substantially raise the bar for bad actors. In our view, these responsibilities are shared between vendors, consumers, and the security industry as a whole.

First and foremost, vendors can ensure they are employing proper security hygiene when designing products. Often, best practices consist not of novel, out-of-the-box thinking, but rather adopting time-tested guidelines like the principle of least privilege. In the case of temi, application of this principle likely would have addressed CVE-2020-16167, which allows clients to subscribe/publish to topics they have no business accessing. Considerations for security should also extend beyond the development phase, with third-party security auditing being a powerful tool that allows vendors to discover and patch vulnerabilities before the bad guys get ahold of them. Taking vulnerability disclosure seriously and cooperating with the bodies that report them can often net similar benefits, and this is an area Robotemi excelled in.

Consumers of these technologies, at either the individual or enterprise level, also share some of the responsibility. Companies should ideally vet all technologies before widespread adoption, particularly if these technologies have access to customer information. It goes without saying that greater risk warrants greater scrutiny. Individuals, while typically having fewer resources, can also take certain precautions. Placing IoT devices on a VLAN, a virtually segregated subnetwork, reduces the risk that a vulnerability in one device will compromise your entire network. Staying up to date on important vulnerabilities can also help inform consumers’ purchasing decisions, although the presence of vulnerabilities is often less illuminating than if/how a company chooses to address them.

Finally, we in the security industry also have an obligation towards moving the needle in the realm of security, one that we hope research such as this embodies. One of our goals here at McAfee ATR is to identify and illuminate a broad spectrum of threats in today’s complex and constantly evolving landscape. While we take seriously our obligation to inform vendors of our findings in a timely and responsible fashion, it is only through cooperation that the best results are possible. Our partnership with Robotemi on addressing these vulnerabilities was a perfect example of this. They responded quickly to our private disclosure report, outlined to us their plans for mitigations and an associated timeline, and maintained a dialogue with us throughout the whole process. We even received feedback that they have further emphasized security in their products by approaching all development discussions with a security-first mindset as a result of this disclosure. The ultimate result is a product that is more secure for all who use it.

The post Call an Exorcist! My Robot’s Possessed! appeared first on McAfee Blog.

Retired Marine fighter pilot and Top Gun instructor Dave Berke said “Every single thing you do in your life, every decision you make, is an OODA Loop.” OODA Loop? Observe–Orient–Decide–Act, the “OODA Loop” was originally developed by United States Air Force Colonel John Boyd and outlines that fundamentally all actions are first based on observations.  If you can’t first observe you are at a serious disadvantage. This can be applied at every scale from planning a large-scale military invasion, to changing lanes on a highway or even down to the split-second decision of picking up a glass of water off a table. But it all starts with observation.

If observation or information about what’s around us is so important, then it’s no surprise that tools and devices that can provide us information not only increase our success but also make us feel more comfortable. The personal robot called temi, is such a device. With 1,000 new devices being created a month, temi can help us see a loved one in the hospital through teleconferencing, escort us to the ballroom in the hotel we are staying at or help a doctor virtually visit with a patient. In fact, across Israel, temi was recently selected as the de facto robotics platform for hospital telepresence. Temi can allow us to observe and interact remotely; all while influencing what we decide to do next with the information we have learned.

But what are the risks associated with tools that help provide greater information into our OODA Loop? How could someone with malicious intent use tools like temi to improve their OODA Loop, furthering their ability to cause harm? Could someone control temi without the owner’s permission? What if someone could turn on the camera and microphone and see the robot’s surroundings while listening to your medical diagnosis or treatment plan? What if someone could “check in on your kids” and map out your house without your permission? These are the type of questions that McAfee Advanced Threat Research (ATR) aims to answer when we see a product like temi. We look at technologies and the wealth of information they provide through the lens of an attacker; with the goal of making your experience a safer one. So, it is no surprise that our team decided to take a deeper look into temi when it was first released.

On day one, like a kid during Christmas, we unboxed our shiny new temi with a sense of joy and excitement. Like your average user, we set it up following the included directions, had it follow us around dressed up as a ghost for Halloween, marked key locations, made video calls and were amazed at just how cool this robot was! Maybe a little less like your average user, we also captured all the network traffic while temi showed off and did a firmware update. We also looked at what open network ports temi exposed, decompiled the Android application, activated android debugger (adb) and installed a ssh server, just to be safe.  Basically, we treated temi like your child’s first date in high school – we did a background check and used proper intimidation techniques before we allowed temi to go on a date.

Over the next several months, we really dug into what we learned from our “first date” with temi. What we discovered, not unlike some of my first high school dates, is temi had some trust issues. This is not a good report card considering some of temi’s primary functions. For the ability to make video calls and to remotely control temi securely, it’s important to keep information used to connect to a call secret and secured. Since temi had some flaws doing so, the team turned its attention to the question of whether these “character flaws” could be exploited.

It turned out with only a few modifications to the original temi Android application, we could intercept phone calls intended for another user. With a few more modifications, temi began to trust us (the attacker) to navigate it around and activate the camera and microphone. Additionally, we discovered the only knowledge an attacker would need to know about the victim is their phone number. Yes, the same number you can’t figure out how tele-markers got ahold of was the information a malicious actor would need to access your temi completely remotely without your knowledge or consent.

For an attacker, temi’s security flaws allows them to feed vital information into their OODA Loop. Consider a hospital that keeps a very tight and well-run information security program. From the outside they are almost impossible to steal information from. The vulnerabilities discovered in temi now provide them a way to gather information about the internal operations of the business without needing to crack the well implemented business network or physical security. With the phone number of anyone who has called a temi recently, an attacker could observe what room number and condition a hospitalized member of congress is in. Temi could watch the security guard type in the building alarm code. Temi could observe the dog pictures on the nurse’s desk labeled with its cute name and birthday, that just happens to also be part of their password. This information can be invaluable to an attacker’s OODA loop and the potentially malicious decisions they make. Temi was a challenging target to compromise, but the nature of the flaws discovered highlight the importance of this research and the value of vendors to provide fast and effective mitigations, as was the case here.

For those who enjoy punishing themselves with an excessive amount of technical detail of these vulnerabilities, we have a special treat for you in our highly technical paper on this research here. This dives into the vulnerability discovery and exploitation process from start to finish in intricate detail.

In keeping with our responsible disclosure program, we reached out to temi as soon as we confirmed that the vulnerabilities we discovered were exploitable. Temi was very receptive, grateful, and had a strong desire to improve the security of temi. Over the next several weeks, we worked closely with their team to develop a more robust solution for temi. For each vulnerability, we provided temi with two mitigations strategies; a band aid and a cure. It is common for vendors to only implement the band aid or quick fix solution. To their credit, temi took on the challenge of implementing the more effective solution or the cure for all findings. Once in place, we were able to test and confirm that all the vulnerabilities reported were effectively mitigated. It is always exciting to see the positive impact security research can have when responsible disclosure is valued by vendor and researchers alike. The following demo video is a light-hearted way to show the true possible impact of the remote accessibility component of this research, had these been found by adversaries instead of responsibly disclosed by McAfee ATR and fixed by temi.

So, what is the larger lesson here? I would venture to guess that I wouldn’t be the first to conclude that Colonel John Boyd was a smart man and his theory of the OODA Loop is not only effective but also strengthens a process – in this case, vulnerability mitigation. For our research, this applies directly to a personal robot assistant which is currently being used worldwide, across a wide range of industries, and currently producing nearly 1,000 new units a month. McAfee’s ATR team observed a new impactful technology emerging into the market. Due to our previous experiences and technical expertise we were well oriented in a position where we decided to take further action and investigate. Temi observed the value in collaboration, oriented themselves in a position where they could decide to take action in making a tool used for observation a more secure product.

The post Robot Character Analysis Reveals Trust Issues appeared first on McAfee Blog.

Executive Summary

Open source has become the foundation for modern software development. Vendors use open source software to stay competitive and improve the speed, quality, and cost of the development process. At the same time, it is critical to maintain and audit open source libraries used in products as they can expose a significant volume of risk.

The responsibility of auditing code for potential security risks lies with the organization using it. We have seen one of the highest impact vulnerabilities originate with open source software in the past. The famous Equifax data breach was due to a vulnerability in open source component Apache Struts, widely used in mainstream web frameworks. Furthermore, the 2020 Open Source Security Risk and Analysis report states that out of the applications audited in 2019, 99% of codebases contained open source components and 75% of codebases contained vulnerabilities, with 49% of codebases containing high risk vulnerabilities.

Graphics libraries have a rich history of vulnerabilities and the volume of exploitable issues are especially magnified when the code base is relatively older and has not been recompiled recently. It turns out that graphics libraries on Linux are widely used in many applications but are not sufficiently audited and tested for security issues. This eventually became a driving force for us to test multiple vector graphics and GDI libraries on Linux, one of which was libEMF, a Linux C++ library written for a similar purpose and used in multiple graphics tools that support graphics conversion into other vector formats. We tested this library for several days and found multiple vulnerabilities, ranging from multiple denial-of-service issues, integer overflow, out-of-bounds memory access, use-after-free conditions, and uninitialized memory use.

All the vulnerabilities were locally exploitable. We reported them to the code’s maintainer, leading to two new versions of the library being released in a matter of weeks. This reflects McAfee’s commitment to protecting its customers from upcoming security threats, including defending them against those found in open source software. Through collaboration with McAfee researchers, all issues in this library were fixed in a timely manner.

In this blog we will emphasize why it is critical to audit the third-party code we often use in our products and outline general practices for security researchers to test it for security issues.

Introduction

Fuzzing is an extremely popular technique used by security researchers to discover potential zero-day vulnerabilities in open, as well as closed source software. Accepted as a fundamental process in product testing, it is employed by many organizations to discover vulnerabilities earlier in the product development lifecycle. At the same time, it is substantially overlooked. A well designed fuzzer typically comprises of a set of tools to make the fuzzing process relatively more efficient and fast enough to discover exploitable bugs in a short period, helping developers patch them early.

Several of the fuzzers available today help researchers guide the fuzzing process by measuring code coverage, by using static or dynamic code instrumentation techniques. This eventually results in more efficient and relevant inputs to the target software, exercising more code paths, leading to more vulnerabilities discovered in the target. Modern fuzzing frameworks also come with feedback-driven channels for maximizing the code coverage of the target software, by learning the input format along the way and comparing the code coverage of the input via feedback mechanisms, resulting in more efficient mutated inputs. Some of the state-of-the-art fuzzing frameworks available are American Fuzzy Lop (AFL), LibFuzzer and HongFuzz.

Fuzzers like AFL on Linux come with compiler wrappers (afl-gcc, afl-clang, etc.). With the assembly parsing module afl-as, AFL parses the generated assembly code to add compile-time instrumentation, helping in visualizing the code coverage. Additionally, modern compilers come with sanitizer modules like Address Sanitizers (ASAN), Memory Sanitizers (MSAN), Leak Sanitizers (LSAN), Thread Sanitizers (TSAN), etc., which can further increase the fuzzer’s bug finding abilities. Below highlights the variety of memory corruption bugs that can be discovered by sanitizers when used with fuzzers.

One of the McAfee Vulnerability Research Team goals is to fuzz multiple open and closed source libraries and report vulnerabilities to the vendors before they are exploited. Over the next few sections of this blog, we aim to highlight the vulnerabilities we discovered and reported while researching one open source library, LibEMF (ECMA-234 Metafile Library).

Using American Fuzzy Lop (AFL)

Much of the technical detail and working of this state-of-the-art feedback-driven fuzzer is available in its documentation. While AFL has many use cases, its most common is to fuzz programs written in C / C++ since they are susceptible to widely exploited memory corruption bugs, and that is where AFL and its mutation strategies are extremely useful. AFL gave rise to several forks like AFLSmart , AFLFast and Python AFL, differing in their mutation strategies and extensions to increase performance. Eventually, AFL was also imported to the Windows platform, WinAFL, using a dynamic instrumentation approach predominantly for closed source binary fuzzing.

The fuzzing process primarily comprises the following tasks:

Fuzzing libEMF (ECMA-234 Metafile Library) with AFL

LibEMF (Enhanced Metafile Library) is an EMF parsing library written in C/C++ and provides a drawing toolkit based on ECMA-234. The purpose of this library is to create vector graphic files. Documentation of this library is available here and is maintained by the developer.

We chose to fuzz this LibEMF with AFL fuzzer because of its compile time instrumentation capabilities and good mutation strategies as mentioned earlier. We have the source code compiled in hardened mode, which will add code hardening options while invoking the downstream compiler, which helps with discovering memory corruption bugs.

Compiling the Source

To use the code instrumentation capabilities of AFL, we must compile the source code with the AFL compiler wrapper afl-gcc/afl-g++ and, with an additional address sanitizer flag enabled, use the following command:

./configure CXX=afl-g++ CFLAGS=”-fsanitize=address -ggdb” CXXFLAGS=”-fsanitize=address -ggdb” LDFLAGS=”-fsanitize=address”

Below is a snapshot of the compilation process showing how the instrumentation is added to the code:

Pwntools python package comes with a good utility script, checksec, that can examine the binary security properties. Executing checksec over the library confirms the code is now ASAN instrumented. This will allow us to discover non-crashing memory access bugs as well:

Test harness is a program that will use the APIs from the library to parse the file given to the program as the command line argument. AFL will use this harness to pass its mutated files as an argument to this program, resulting in several executions per second. While writing the harness, it is extremely important to release the resources before returning to avoid excessive usage which can eventually crash the system. Our harness for parsing EMF files using APIs from the libEMF library is shown here:

AFL will also track the code coverage with every input that it passes to the program and, if the mutations result in new program states, it will add the test case to the queue. We compiled our test harness using the following command:

afl-g++ -o playemffile playemffile.c -g -O2 -D_FORTIFY_SOURCE=0 -fsanitize=address -I /usr/local/include/libEMF/ -L/usr/local/lib/libEMF -lEMF

Collecting Test Cases

While a fuzzer can learn and generate the input format even from an empty seed file, gathering the intial corpus of input files is a significant step in an effective fuzzing process and can save huge amounts of CPU cycles. Depending upon the popularity of the file format, crawling the web and downloading the initial set of input files is one of the most intuitive approaches. In this case, it is not a bad idea to manually construct the input files with a variety of EMF record structures, using vector graphic file generation libraries or Windows GDI APIs. Pyemf is one such available library with Python bindings which can be used to generate EMF files. Below shows example code of generating an EMF file with an EMR_EXTEXTOUTW record using Windows APIs. Constructing these files with the different EMR records will ensure functionally different input files, exercising different record handlers in the code.

Running the Fuzzer

Running the fuzzer is just running the afl-fuzz command with the parameters as shown below. We would need to provide the input corpus of EMF files ( -i EMFs/ ) , output directory ( -o output/ ) and the path to the harness binary with @@, meaning the fuzzer will pass the file as an argument to the binary. We also need to use -m none since the ASAN instrumented binary needs a huge amount of memory.

afl-fuzz -m none -i EMFs/ -o output/ — /home/targets/libemf-1.0.11/tests/playemffile @@

However, we can make multiple tweaks to the running AFL instance to increase the number of executions per second. AFL provides a persistent mode which is in-memory fuzzing. This avoids forking a new process on every run, resulting in increased speed. We can also run multiple AFL instances, one on every core, to increase the speed. Beyond this, AFL also provides a file size minimization tool that can be used to minimize the test case size. We applied some of these optimization tricks and, as we can see below, there is a dramatic increase in the execution speed reaching ~500 executions per second.

After about 3 days of fuzzing this library, we had more than 200 unique crashes, and when we triaged them we noticed 5 unique crashes. We reported these crashes to the developer of the library along with MITRE, and after being acknowledged, CVE-2020-11863, CVE-2020-11864, CVE-2020-11865, CVE-2020-11866 and CVE-2020-13999 were assigned to these vulnerabilities. Below we discuss our findings for some of these vulnerabilities.

CVE-2020-11865 – Out of Bounds Memory Access While Enumerating the EMF Stock Objects

While triaging one of the crashes produced by the fuzzer, we saw SIGSEGV (memory access violation) for one of the EMF files given as an input. When the binary is compiled with the debugging symbols enabled, ASAN uses LLVM Symbolizer to produce the symbolized stack traces. As shown below, ASAN outputs the stack trace which helps in digging into this crash further.

Looking at the crash point in the disassembly clearly indicates the out of bounds memory access in GLOBALOBJECTS::find function.

Further analyzing this crash, it turned out that the vulnerability was in accessing of the global object vector which had pointers to stock objects. Stock objects are primarily logical graphics objects that can be used in graphics operations. Each of the stock objects used to perform graphical operations have their higher order bit set, as shown below from the MS documentation. During the metafile processing, the index of the relevant stock object can be determined by masking the higher order bit and then using that index to access the pointer to the stock object. Metafile processing code tries to retrieve the pointer from the global object vector by attempting to access the index after masking the higher order bit, as seen just above the crash point instruction, but does not check the size of the global object vector before accessing the index, leading to out of bounds vector access while processing a crafted EMF file.

Shown below is the vulnerable and fixed code where the vector size check was added:

CVE-2020-13999 – Signed Integer Overflow While Processing EMR_SCALEVIEWPORTEX Record

Another crash in the code that we triaged turned out to be a signed integer overflow condition while processing an EMR_SCALEVIEWPORTEXT record in the metafile. This record specifies the viewport in the current device context and is calculated by computing ratios. An EMR_SCALEVIEWPORTEXTEX record looks like this, as per the record specification. A new viewport is calculated as shown below:

As part of AFL’s binary mutation strategy, it applies a deterministic approach where certain hardcoded sets of integers replace the existing data. Some of these are MAX_INT, MAX_INT-1, MIN_INT, etc., which increases the likelihood of triggering edge conditions while the application processes binary data. One such mutation done by AFL in the EMF record structure is shown below:

This resulted in the following crash while performing the division operation.

Below we see how this condition, eventually leading to a denial-of-service, was fixed by adding division overflow checks in the code:

CVE-2020-11864 – Memory Leaks While Processing Multiple Metafile Records

Leak Sanitizer (LSAN) is yet another important tool which is integrated with the ASAN and can be used to detect runtime memory leaks. LSAN can also be used in standalone mode without ASAN. While triaging generated crashes, we noticed several memory leaks while processing multiple EMF record structures. One of them is as shown below while processing the EXTTEXTOUTA metafile record, which was later fixed in the code by releasing the memory buffer when there are exceptions reading the corrupted metafiles.

Apparently, memory leaks can lead to excessive resource usage in the system when the memory is not freed after it is no longer needed. This eventually leads to the denial-of-service. We found memory leak issues while libEMF processed several such metafile records. The same nature of fix, releasing the memory buffer, was applied to all the vulnerable processing code:

Additionally, we also reported multiple use-after-free conditions and denial-of-service issues which were eventually fixed in the newer version of the library released here.

Conclusion

Fuzzing is an important process and fundamental to testing the quality of a software product. The process becomes critical, especially when using third-party libraries in a product which may come with exploitable vulnerabilities. Auditing them for security issues is crucial. We believe the vulnerabilities that we reported are just the tip of the iceberg. There are several legacy libraries which likely require a thorough audit. Our research continues with several other similar Windows and Linux libraries and we will continue to report vulnerabilities through our coordinated disclosure process. We believe this also highlights that it is critical to maintain a good level of collaboration between vulnerability researchers and the open source community to have these issues reported and fixed in a timely fashion. Additionally, modern compilers come with multiple code instrumentation tools which can help detect a variety of memory corruption bugs when used early in the development cycle. Using these tools is recommended when auditing code for security vulnerabilities.

The post Vulnerability Discovery in Open Source Libraries Part 1: Tools of the Trade appeared first on McAfee Blog.

Intro

In a U.S. government cyber security advisory released today, the National Security Agency and Federal Bureau of Investigation warn of a previously undisclosed piece of Linux rootkit malware called Drovorub and attribute the threat to malicious actor APT28. The report is incredibly detailed and proposes several complementary detection techniques to effectively identify Drovorub malware activity. A multitude of investigative methods are suggested given that the common issue with rootkits is that large scale detection on a host can be a real challenge. The NSA and FBI have been explicit in their report that systems with a kernel version of 3.7 or lower are most susceptible to Drovorub malware due to the absence of adequate kernel signing enforcement.

Keeping a system updated and fully protected isn’t specific to Windows-based environments. Linux based systems are widespread within many enterprise organizations, requiring the same maintenance as any modern operating system. Linux offers a robust, secure computing platform which can meet many needs. As in most cases, proper configuration is key to the security of the platform.

For specific McAfee technology protections against Drovorub please visit the dedicated Drovorub KB article here.

In addition to the guidance provided in the  U.S. government report and our product specific knowledge base article, McAfee encourages organizations to take note of and apply the following best practices (where possible) for rootkit detection and kernel security.

Scanning for Rootkits

Just like a malware scanner, a rootkit scanner can scan low level processes to determine if any malicious code is loaded at bootup. For example, below are examples of software that can be used for general rootkit detection:

• Chrootkit – A rootkit scanner for Linux to discover hard to find rootkits
• Rkhunter – A rootkit scanner for Linux to discover backdoors and possible local exploits.

In this specific Drovorub case the advice is given to forensically analyze a machine’s memory with tools like Volatility. Using the Volatility plugin “Linux_Psxview” presence of the Drovorub client can be detected even though it doesn’t show up in the normal PSlist.

Linux Kernel hardening

Today’s advisory suggests that organizations enable UEFI Secure Boot in “full” or “thorough” mode on x86-64 systems. UEFI Secure Boot requires cryptographically signed firmware and kernels. Because no unsigned drivers can be loaded for hardware, this action will decrease the attack surface by making it more difficult for an attacker to insert a malicious kernel module into the system and for unsigned rootkits to remain persistent after reboot.

Organizations should take note, however, that Secure Boot is not integrated in all Linux distros. There are also some challenges with enabling Secure Boot. Often it requires manual intervention any time a kernel or module is upgraded or may prevent some products from loading. This knowledge base article from VMWare discusses ways to address these Secure Boot issues

Securing the kernel

There are several steps organizations can take to secure the Linux kernel and take advantage of the features that are provided. We will highlight some of the best-practices that can be used and applied. Please apply these within a test-environment before applying them in production.

Kernel module signing

Since Linux 3.7, the kernel has supported digital signatures on loadable kernel modules. This facility can be enabled in the kernel with settings in CONFIG_MODULE_SIG. These options can require valid signatures; enable automatic module signing during the kernel build phase; and specify which hash algorithm to use. Additionally, local or remote keys can be used. By requiring valid digital signatures, only known valid modules can be loaded, decreasing your system’s attack surface.

Module loading rules

Only known modules should be loadable. Limited module support can be enabled by default, disallowing kernel module loading and specifying which modules are exempt from the ban. The following command can be used to disable the loading:

sysctl kernel.modules_disabled=1

Some modules required for system operation may normally be loaded during system operation and not at boot.  To ensure these modules are available, they must be loaded at startup prior to when loading is disabled. To load these modules, list them in a file located in /etc/modules-load.d.

Disabling modules completely

Depending on the system in question, disabling all non-necessary hardware in the kernel configuration and building all required driver code directly into the kernel rather than using modules could allow for completely disabling loadable kernel module support. For special use systems, this may be a viable option. By disallowing modules entirely, your system’s attack surface can be drastically reduced.

Fully disabling kernel module support might only be possible for special purpose systems with a known usage pattern. General purpose, user-facing machines will likely need module support to support user access patterns.

Using Linux kernel Lockdown

The lockdown patches have been merged into the kernel since version 5.4. Even if Secure Boot is enabled, if not prevented, the root could still modify the kernel and, for example, apply a hot-patch and create a persistent process.  Lockdown was developed to provide a policy to prevent the root from modifying the kernel code. Lockdown has two modes: “integrity” and “confidentiality”. The community generally advises organizations to consider the “integrity” mode and use “confidentiality” mode for special systems.

Harden sysctl.conf

The sysctl.conf file is the main kernel parameter configuration point for a Linux system. By using secure defaults, the whole system will benefit from a more secure foundation. Example options include disabling IPv6 if not in use, ignoring network broadcast packets, enabling ASLR, and activating DEP/NX. (https://www.cyberciti.biz/faq/linux-kernel-etcsysctl-conf-security-hardening/)

Enable SELinux or AppArmor

Modern Linux systems include the security enhancement systems of AppArmor or SELinux depending on the distribution. These allow for granular access control with security policies. SElinux is installed and enabled by default on CentOS and RedHat Enterprise Linux operating systems, while AppArmor is installed and enabled by default on Ubuntu and SuSE Linux Enterprise systems.

• https://wiki.ubuntu.com/AppArmor
• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/index

What we often observe is that people will decide to disable these security enhancement systems as soon as they run into an issue since they is easy to disable with root privileges. But taking the time to learn how to allow services and fix issues is very important to provide an additional layer of security on a Linux system.

AppArmor is a Linux kernel security module that provides capabilities similar to SELinux. While SELinux operates on files (specifically inodes) and requires filesystem support, AppArmor works on paths, while being file system agnostic. Considered by many to be easier to use, it is mostly transparent to regular users. While SELinux can be (potentially) more secure, the complexity of the system has many users preferring AppArmor.

Among the mainline Enterprise-level Linux distributions, RedHat embraces SELinux, while SuSE Enterprise embraces (and owns the trademark to) AppArmor. Canonical is a significant contributor to AppArmor as well, and supports it by default in Ubuntu.

Additional Linux System hardening

In light of today’s advisory, we have focused mostly on securing the Linux Kernel in this article. However, there are many best practices to secure Linux (or nearly any modern operating system), including:

• Removal of unused software
• Disabling unused services
• Enabling auditing
• Controlling API access
• Limiting root account usage
• Incorporating a least-privilege policy as much as possible
• Backing up your system
• Increasing ASLR entropy via sysctl to make reliable exploitation more difficult, by increasing the number of locations libraries that could be stored in memory.

Detailed hardening and securing guides for Linux distributions can be downloaded from:

https://www.cisecurity.org/cybersecurity-best-practices/

Conclusion

Linux Kernel and System hardening may prove to hold a learning curve for organizations and administrators more familiar with the configuration and use of Windows operating systems. However, given the information provided in the NSA-FBI publication and the adaptation of Linux-based malware by threat actors overall, we advise organizations remain vigilant, harden Linux systems as much as possible, and deploy adequate security products.

For specific McAfee technology protections against Drovorub please visit the dedicated Drovorub KB article here.

The post On Drovorub: Linux Kernel Security Best Practices appeared first on McAfee Blog.

Open Source projects are the building blocks of any software development process. As we indicated in our previous blog, as more and more products use open source code, the increase in the overall attack surface is inevitable, especially when open source code is not audited before use. Hence it is recommended to thoroughly test it for potential vulnerabilities and collaborate with developers to fix them, eventually mitigating the attacks. We also indicated that we were researching graphics libraries in Windows and Linux, reporting multiple vulnerabilities in Windows GDI as well as Linux vector graphics library libEMF. We are still auditing many other Linux graphics libraries since these are legacy code and have not been strictly tested before.

In part 1 of this blog series, we described in detail the significance of open source research, by outlining the vulnerabilities we reported in the libEMF library. We also highlighted the importance of compiling the code with memory sanitizers and how it can help detect a variety of memory corruption bugs. In summary, the Address Sanitizer (ASAN) intercepts the memory allocation / deallocation functions like malloc () / free() and fills out the memory with the respective fill bytes (malloc_fill_byte / free_fill_byte). It also monitors the read and write to these memory locations, helping detect erroneous access during run time.

In this blog, we provide a more detailed analysis for one of the reported vulnerabilities, CVE-2020-11863, which was due to the use of uninitialized memory. This vulnerability is related to CVE-2020-11865, a global object vector out of bounds memory access in the GlobalObject::Find() function in libEMF. However, the crash call stack turned out to be different, which is why we decided to examine this further and produce this deep dive blog.

The information provided by the ASAN was sufficient to reproduce the vulnerability crash outside of the fuzzer. From the ASAN information, the vulnerability appeared to be a null pointer dereference, but this was not the actual root cause, as we will discuss below.

Looking at the call stack, it appears that the application crashed while dynamically casting the object, for which there could be multiple reasons. Out of those possible reasons that seem likely, either the application attempted to access the non-existent virtual table pointer, or the object address returned from the function was a wild address accessed when the application crashed. Getting more context about this crash, we came across an interesting register value while debugging. Below shows the crash point in the disassembly indicating the non-existent memory access.

If we look at the state of the registers at the crash point, it is particularly interesting to note that the register rdi has an unusual value of 0xbebebebebebebebe. We wanted to dig a little deeper to check out how this value got into the register, resulting in the wild memory access. Since we had the source of the library, we could check right away what this register meant in terms of accessing the objects in memory.

Referring to the Address Sanitizer documentation, it turns out that the ASAN writes 0xbe to the newly allocated memory by default, essentially meaning this 64-bit value was written but the memory was not initialized. The ASAN calls this as the malloc_fill_byte. It also does the same by filling the memory with the free_fill_byte when it is freed. This eventually helps identify memory access errors.

This nature of the ASAN can also be verified in the libsanitizer source here. Below is an excerpt from the source file.

Looking at the stack trace at the crash point as shown below, the crash occurred in the SelectObject() function. This part of the code is responsible for processing the EMR_SELECTOBJECT record structure of the Enhanced Meta File (EMF) file and the graphics object handle passed to the function is 0x80000018. We want to investigate the flow of the code to check if this is something which comes directly from the input EMF file and can be controlled by an attacker.

In the SelectObject() function, while processing the EMR_SELECTOBJECT record structure, the handle to the GDI object is passed to GlobalObjects.find() as shown in the above code snippet, which in turn accesses the global stock object vector by masking the higher order bit from the GDI object handle and converting it into the index, eventually returning the stock object reference from the object vector using the converted index number. Stock object enumeration specifies the indexes of predefined logical graphics objects that can be used in graphics operations documented in the MS documentation. For instance, if the object handle is 0x8000018, this will be ANDed with 0x7FFFFFFF, resulting in 0x18, which will be used as the index to the global stock object vector. This stock object reference is then dynamically cast into the graphics object, following which EMF::GRAPHICSOBJECT member function getType ( ) is called to determine the type of the graphics object and then, later in this function, it is again cast into an appropriate graphics object (BRUSH, PEN, FONT, PALETTE, EXTPEN), as shown in the below code snippet.

EMF::GRAPHICSOBJECT is the class derived from EMF::OBJECT and the inheritance diagram of the EMF::OBJECT class is as shown below.

However, as mentioned earlier, we were interested in knowing if the object handle, passed as an argument to the SelectObject function, can controlled by an attacker. To be able to get context on this, let us look at the format of the EMR_SELECTOBJECT record as shown below.

As we notice here, ihObject is the 4-byte unsigned integer specifying the index to the stock object enumeration. In this case the stock object references are maintained in the global objects vector. Here, the object handle of 0x80000018 implies that index 0x18 will be used to access the global stock object vector. If, during this time, the length of the object vector is less then 0x18 and the length check is not done prior to accessing the object vector, it will result in out of bounds memory access.

Below is the visual representation of processing the EMR_SELECTOBJECT metafile record.

While debugging this issue, we enable a break point at GlobalObjects.find () and continue until we have object handle 0x80000018; essentially, we reach the point where the above highlighted EMR_SELECTOBJECT record is being processed. As shown below, the object handle is converted into the index (0x18 = 24) to access the object vector of size (0x16 = 22), resulting into out of bounds access, which we reported as CVE-2020-11865.

Further stepping into the code, it enters the STL vector library stl_vector.h which implements the dynamic expansion of the std::vectors. Since the objects vector at this point of time has only 22 elements, the STL vector will expand the vector to the size indicated by the parameter highlighted, accessing the vector by passed index, and will return the value at that object reference, as shown in the below code snippet, which comes out to be 0xbebebebebebebebe as filled by the ASAN.

The code uses the std:allocator to manage the vector memory primarily used for memory allocation and deallocation. On further analysis, it turns out that the value returned, 0xbebebebebebebebe in this case, is the virtual pointer of the non-existent stock object, which is dereferenced during dynamic casting, resulting in a crash.

As mentioned in our earlier blog, the fixes to the library have been released in a subsequent version, available here.

Conclusion

While using third party code in products certainly saves time and increases development speed, it potentially comes with an increase in the volume of vulnerabilities, especially when the code remains unaudited and integrated into products without any testing. It is extremely critical to perform fuzz testing of the open source libraries used, which can help in discovering vulnerabilities earlier in the development cycle and provides an opportunity to fix them before the product is shipped, consequently mitigating attacks. However, as we emphasized in our previous blog, it is critical to strengthen the collaboration between vulnerability researchers and the open source community to continue responsible disclosures, allowing the maintainers of the code to address them in a timely fashion.

The post Vulnerability Discovery in Open Source Libraries: Analyzing CVE-2020-11863 appeared first on McAfee Blog.

McAfee Advanced Threat Research (ATR) is collaborating with Cork Institute of Technology (CIT) and its Blackrock Castle Observatory (BCO) and the National Space Center (NSC) in Cork, Ireland

The essence of Space 4.0 is the introduction of smaller, cheaper, faster-to-the-market satellites in low-earth-orbit into the value chain and the exploitation of the data they provide. Space research and communication prior to Space 4.0 was primarily focused on astronomy and limited to that of governments and large space agencies. As technology and society evolves to consume the “New Big Data” from space, Space 4.0 looks set to become the next battleground in the defense against cybercriminals. Space 4.0 data can range from earth observation sensing to location tracking information and applied across many vertical uses cases discussed later in this blog. In the era of Space 4.0 the evolution of the space sector is rapidly changing with a lower cost of launching, combined with public and private partnerships that open a whole new dimension of connectivity. We are already struggling to secure our data on earth, we must now understand and secure how our data will travel through space constellations and be stored in cloud data centers on earth and in space.

Low Earth Orbit (LEO) satellites are popular for scientific usage but how secure are they? The Internet of Things (IoT) introduced a myriad of insecure devices onto the Internet due to the low cost of processors and high-speed connectivity, but the speed in its adoption resulted in a large fragmentation of insecure hardware and software across business verticals.

Space 4.0 is now on course for a similar rapid adoption with nanosats as we prepare to see a mass deployment of cheap satellites into LEO. These small satellites are being used across government, academic and commercial sectors for different use cases that require complex payloads and processing. Many nanosats can coexist on a single satellite. This means that the same satellite backbone circuit infrastructure can be shared, reducing build and launch costs and making space data more accessible.

To date, satellites have typically been relay type devices repeating signals to and from different locations on earth in regions with poor internet connectivity, but that is all set to change with a mass deployment of smarter satellite devices using inter-satellite links (ISL) in  constellations like Starlink which aim to provide full high speed broadband global coverage. As the Space 4.0 sector is moving from private and government sectors to general availability, this makes satellites more accessible from a cost perspective, which will attract threat actors other than nation states, such as cyber criminals. Space 4.0 also brings with it new service delivery models such as Ground Station as a Service (GSaaS) with AWS and Azure Orbital and Satellite as a Service (SataaS). With the introduction of these, the satellite will become another device connecting to the cloud.

In our research we analyze the ecosystem to understand the latest developments and threats in relation to cybersecurity in space and whether we are ready to embrace Space 4.0 securely.

Space 4.0 Evolution

What is the Industrial 4^th Revolution? The original industrial revolution started with the invention of steam engines then electricity, computers and communication technology. Industry 4.0 is about creating a diverse, safe, healthy, just world with clean air, water, soil and energy, as well as finding a way to pave the path for the innovations of tomorrow.

The first space era, or Space 1.0, was the study of astronomy, followed by the Apollo moon landings and then the inception of the International Space Station (ISS). Space 4.0  is analogous to Industry 4.0, which is considered as the unfolding fourth industrial revolution of manufacturing and services. Traditionally, access to space has been the domain of governments and large space agencies (such as NASA or the European Space Agency) due to the large costs involved in the development, deployment and operation of satellites. In recent years, a new approach to using space for commercial, economic and societal good has been driven by private enterprises in what is termed New Space. When combined with the more traditional approach to space activity, the term “Space 4.0” is used. Space 4.0 is applicable across a wide range of vertical domains, including but not limited to:

• Ubiquitous broadband
• Autonomous vehicles
• Earth observation
• Disaster mitigation/relief
• Human spaceflight
• Exploration

Cyber Threat Landscape Review

The Cyber Threat Landscape has evolved greatly over the past 20 years with the convergence of Information Technology (IT), Operational Technology (OT) and IoT. Protecting consumers, enterprises and critical infrastructure with the rapid parallel innovation of technology and cybercriminals is a constant challenge. While technology and attacks evolve rapidly the cybercriminal motive remains a constant; make money and maximize profit by exploiting a combination of users and technology.

Cybercriminals have much more capabilities now than they did 10 years ago due to the rise of Cybercrime as a Service (CaaS). Once an exploit for a vulnerability has been developed, it can then be weaponized into an exploit kit or ransomware worm, such as WannaCry. Cybercriminals will follow the path of least resistance to achieve their goal of making money.

Nearly every device class across the business verticals, ranging from medical devices to space Very-small-aperture terminals (VSAT), have been hacked by security researchers, as evident from Blackhat and Defcon trends.

From a technology stack perspective (hardware and software) there have been vulnerabilities discovered and exploits developed across all layers where we seek to establish some form of trustworthiness when connected to the internet; browsers, operating systems, protocols, hypervisors, enclaves, cryptographic implementations, system on chips (SoC) and processors.

Not all these vulnerabilities and exploits become weaponized by cybercriminals, but it does highlight the fact that the potential exists. Some notable weaponized exploits are:

1. Stuxnet worm
2. WannaCry ransomware worm
3. Triton malware
4. Mirai Botnet

Some recent major industry vulnerabilities were: BlueKeep (Windows RDP Protocol), SMBGhost (Windows SMB Protocol), Ripple20 (Treck embedded TCP/IP library), Urgent 11 (VxWorks TCP/IP library), Heartbleed (OpenSSL library), Cloudbleed (Cloudflare), Curveball (Microsoft Crypto API), Meltdown and Spectre (Processor side channels).

Cybercriminals will adapt quickly to maximize their profit as we saw with the COVID-19 pandemic and the mass remote workforce. They will quickly understand the operating environment changes and how they can reach their goals by exploiting users and technology, whichever is the weakest link. The easiest entry point into an organization will be through identity theft or weak passwords being used in remote access protocols such as RDP.

Cybercriminals moved to the Dark Web to hide identity and physical location of servers or using bullet-proof providers to host their infrastructure. What if these services are hosted in space? Who is the legal entity and who is responsible?

McAfee Enterprise Supernova Cloud analysis reports that:

• Nearly one in 10 files shared in the cloud with sensitive data have public access, an increase of 111% year over year
• One in four companies have had their sensitive data downloaded from the cloud to an unmanaged personal device, where they cannot see or control what happens to the data
• 91% of cloud services do not encrypt data at rest
• Less than 1% of cloud services allow encryption with customer-managed keys

The transition to the cloud, when done securely, is the right business decision. However, when not done securely it can leave your services and data/data lakes accessible to the public through misconfigurations (shared responsibility model), insecure APIs, and identity and access management issues. Attackers will always go for the low hanging fruit such as open AWS buckets and credentials through vendors in the supply chain.

One of the key initiatives, and now industry benchmark, is the MITRE ATT&CK framework which enumerates the TTPs from real word incidents across Enterprise (Endpoint and Cloud), Mobile and ICS. This framework has proved to be very valuable in enabling organizations to understand adversary TTPs and the corresponding protect, detect and response controls required in their overall defense security architecture. We may well see a version of MITRE ATT&CK evolve for Space 4.0.

Space Cyber Threat Landscape Review

Threat actors know no boundaries as we have seen criminals move from traditional crime to cybercrime using whatever means necessary to make money. Likewise, technology communication traverses many boundaries across land, air, sea and space. With the reduced costs to entry and the commercial opportunities with Space 4.0 big data, we expect to see cybercriminals innovating within this huge growth area. The Cyber Threat Landscape can be divided into vulnerabilities discovered by security researchers and actual attacks reported in the wild. This allows us to understand the technologies within the space ecosystem that are known to contain vulnerabilities and what capabilities threat actors have and are using in the wild.

Vulnerabilities discovered to date have been within VSAT terminal systems and intercepting communications. There have been no vulnerabilities disclosed on actual satellites from figure 1 below.

Figure 1 – Security Researcher space vulnerability disclosures

To date, satellites have mostly been controlled by governments and the military so little information is available as to whether an actual satellite has been hacked. We do expect to see that change with Space 4.0 as these satellites will be more accessible from a hardware and software perspective to do security analysis. Figure 2 below highlights reported attacks in the wild

Figure 2 – Reported Attacks in the Wild

In McAfee’s recent threat research, “Operation North Star”, we observed an increase in malicious cyber activity targeting the Aerospace and Defense industry. The objective of these campaigns was to gather information on specific programs and technologies.

Since the introduction of the cloud, it appears everything has become a device that interacts with a service. Even cybercriminals have been adapting to the service model. Space 4.0 is no different as we start to see the adoption of the Ground Station as a Service (GSaaS) and Satellite as a Service (SataaS) models per figure 3 below. These services are opening in the space sector due to the acceleration of vendors into Space 4.0 to help keep their costs down. Like any new ecosystem this will bring new attack surfaces and challenges which we will discuss in the Threat Modelling section.

Figure 3 – New Devices and Services for Space 4.0

So, with the introduction of cheap satellites using commercial off-the-shelf (COTS) components and new cloud services is it just a matter of time before we see mass satellite attacks and compromise?

Space 4.0 Data Value

The global space industry grew at an average rate of 6.7% per year between 2005 and 2017 and is projected to rise from its current value of $350 billion to $1.3 trillion per annum by 2030. This rise is driven by new technologies and business models which have increased the number of stakeholders and the application domains which they service in a cost-effective way. The associated increase in data volume and complexity has, among other developments, resulted in increasing concerns over the security and integrity of data transfer and storage between satellites, and between ground stations and satellites.

The McAfee Supernova report shows that data is exploding out of enterprises and into the cloud. We are now going to see the same explosion from Space 4.0 to the cloud as vendors race to innovate and monetize data from low cost satellites in LEO.

According to Microsoft the processing of data collected from space at cloud-scale to observe the Earth will be “instrumental in helping address global challenges such as climate change and furthering of scientific discovery and innovation”. The value of data from space must be viewed from the perspective of the public and private vendors who produce and consume such data. Now that satellite launch costs have reduced, producing this data becomes more accessible to commercial markets, so we are going to see much innovation in data analytics to improve our lives, safety and preservation of the earth. This data can be used to improve emergency response times to save lives, monitoring illegal trafficking, aviation tracking blind spots, government scientific research, academic research, improving supply chains and monitoring the earth’s evolution, such as climate change effects. Depending on the use case, this data may need to be confidential, may have privacy implications when tracking and may have substantial value in the context of new markets, innovation and state level research. It is very clear that data from space will have much value as new markets evolve, and cybercriminals will most certainly target that data with the intent to hold organizations to ransom or sell data/analytics innovation to competitors to avoid launch costs. Whatever the use case and value of the data traveling through space may be, we need to ensure that it moves securely by providing a trustworthy end to end ecosystem.

As we progress towards the sixth digital era, our society, lives and connectivity will become very dependent on off-planet data and technology in space, starting with SataaS.

In Part 2 we will discuss remote computers in Space, the Space 4.0 threat model and what we must do to secure Space 4.0 moving forward.

McAfee would like to thank Cork Institute of Technology (CIT) and their Blackrock Castle Observatory (BCO) and the National Space Center (NSC) in Cork, Ireland for their collaboration in our mission to securing Space 4.0.

The post Securing Space 4.0 – One Small Step or a Giant Leap? Part 1 appeared first on McAfee Blog.

McAfee Advanced Threat Research (ATR) is collaborating with Cork Institute of Technology (CIT) and its Blackrock Castle Observatory (BCO) and the National Space Center in Cork, Ireland

In the first of this two-part blog series we introduced Space 4.0, its data value and how it looks set to become the next battleground in the defense against cybercriminals. In part two we discuss the architectural components of Space 4.0 to threat model the ecosystem from a cybersecurity perspective and understand what we must do to secure Space 4.0 moving forward.

Nanosats: Remote Computers in Space

A satellite is composed of a payload and a bus. The payload is the hardware and software required for the mission or satellite’s specific function, such as imaging equipment for surveillance. The bus consists of the infrastructure or platform that houses the payload, such as thermal regulation and command and control. Small satellites are space craft typically weighing less than 180 kilograms and, within that class of satellites, is what we call nanosatellites or nanosats which typically weigh between 1-10 kilograms. Cubesats are a class of nanosat so you will often hear the term used interchangeably, and for the context of Space 4.0 security, we can assume they are the same device. Nanosats significantly reduce launch costs due to their small size and the fact that many of these devices can be mounted on board a larger single satellite for launch.

Commercial off-the-shelf (COTS) Cubesats typically use free open source software such as FreeRTOS or KubOS for the on-board operating system. However, other systems are possible, with drivers available for most of the hardware on Linux and Windows OS. KubOS is an open source flight software framework for satellites and has cloud-based mission control software, Major Tom, to operate nanosats or a constellation. We mention KubOS here as it is a good example of what the current Space 4.0 operating model looks like today. While we have not reviewed KubOS from a security perspective, developing a secure framework for satellites is the right path forward, allowing mission developers to focus on the payload.

Some of the use cases available with Cubesats are:

1. File transfers
2. Remote communication via uplink/downlink
3. Intra-satellite and inter-satellite communications
4. Payload services such as camera and sensors telemetry
5. Software Updates

KubOS is “creating a world where you can operate your small satellite from your web browser or iPhone”. KubOS’ objective is to allow customers to send bits and not rockets to space and it is defining a new era of software-designed satellites. The satellite model is changing from relay type devices to remote computers in space using COTS components and leveraging TCP/IP routing capabilities. This model shift also means that there is more software executing on these satellites and more complex payload processing or interaction with the software stack and hence more attack surface.

To date, attacks on satellite systems from a cybersecurity perspective have typically been in the context of VSAT terminals, eavesdropping and hijacking. While there have been vulnerabilities found in the VSAT terminal software and its higher-level custom protocols, there seems to have been no focus and vulnerabilities discovered within the network software stack of the satellite itself. This may be since satellites are very expensive, as well as closed source, so not accessible to security researchers or cybercriminals, but this security by obscurity will not provide protection with the new era of nanosats. Nanosats use COTS components which will be accessible to cybercriminals.

Due to the closed nature of satellites there has not been much published on their system hardware and software stack. However, the Consultative Committee for Space Data Systems (CCSDS), which develops standards and specifications including protocols for satellite communications, does give some insight. The CCSDS technical domains are:

1. Space Internetworking Services
2. Mission Ops. And Information Management Services
3. Spacecraft Onboard Interface Services
4. System Engineering
5. Cross Support Services
6. Space Link Services

The CCSDS standards are divided into color codes to represent recommended standards and practices versus informational and experimental. This is a very large source of data communications for satellite designers to aid them in a reference for implementation. However, as we have observed over the cyber threat landscape of the past few decades, secure standards and specifications for hardware, software and protocols do not always translate to secure implementation. The CCSDS defines a TCP/IP stack suitable for transmission over space datalinks as per figure 1 below. Satellites that become more connected, just like any other device on the internet, their network and protocol software stack will become more accessible and targeted. As we discussed in part 1 <insert link> of our Space 4.0 blog series, there have been many TCP/IP and remote protocol related vulnerabilities in both embedded devices and even state of the art operating systems such as Windows 10. The TCP/IP stack and remote protocol implementations are a common source of vulnerabilities due to the complexities of parsing in unsafe memory languages such as C and C++. There does not appear to be any open source implementations of the CCSDS TCP/IP protocol stack.

Figure 1 – CCSDS Space communications protocols reference model

The CubeSat Protocol (CSP) is a free open source TCP/IP stack implementation for communication over space datalinks, similar to the CCSDS TCP/IP stack. The CSP protocol library is implemented in C, open source and implemented in many Cubesats that have been deployed to space. The protocol can be used for communication from ground station to satellite, inter-satellite and the intra-satellite communication bus. There have been 3 vulnerabilities to date reported in this protocol.

Figure 2 below shows what a Cubesat architecture looks like from a trust boundary perspective relative to the satellite and other satellites within the constellation and the earth.

Figure 2 – Space LEO Cubesat architecture trust boundaries

No hardware, software, operating system or protocol is completely free of vulnerabilities. What is important from a security perspective is:

1. The accessibility of the attack surface
2. The motives and capabilities of the adversary to exploit an exposed vulnerability if present in the attack surface

As these low-cost satellites get launched in our LEO and become more connected, any exposed technology stack will become increasingly targeted by cybercriminals.

Space 4.0 Threat Modeling

This Space 4.0 threat model focuses on the cybercriminal and how they can exploit Space 4.0 data for monetization. The following Space 4.0 factors will make it more accessible to cybercriminals:

1. Mass deployment of small satellites to LEO
2. Cheaper satellites with COTS components and increased satellite on board software processing (no longer relay devices)
3. Satellite service models, Ground Station-as-a-Service (GSaaS) and Satellite-as-a-Service (SataaS) and shared infrastructure across government, commercial and academic
4. Satellite connectivity and networks in space (ISL – inter-satellite links)
5. Space 4.0 data value

Space security has typically been analyzed from the perspective of ground segment, communications or datalink and space segment. Additionally, the attack classes have been categorized as electronic (jamming), eavesdropping, hijacking and control. Per figure 3 below, we need to think about Space 4.0 with a cybersecurity approach due to the increased connectivity and data, as opposed to the traditional approach of ground, communication and space segments. Cybercriminals will target the data and systems as opposed to the RF transmission layer.

Figure 3 – Space 4.0 threat modeling architecture

It is important to consider the whole interconnectivity of the Space 4.0 ecosystem as cybercriminals will exploit any means possible, whether that be direct or indirect access (another trusted component). Open source networked ground stations such as SatNOGs and the emerging NyanSat are great initiatives for space research but we should consider these in our overall threat model as they provide mass connectivity to the internet and space.

The traditional space security model has been built on a foundation of cost as a barrier to entry and perimeter-based security due to lack of physical access and limited remote access to satellites. However, once a device is connected to the internet the threat model changes and we need to think about a satellite as any other device which can be accessed either directly or indirectly over the internet.

In addition, if a device can be compromised in space remotely or through the supply chain, then that opens a new attack class of space to cloud/ground attacks.

Users and trusted insiders will always remain a big threat from a ground station perspective, just like enterprise security today, as they can potentially get direct access to the satellite control.

The movement of ground services to the cloud is a good business model if designed and implemented securely, however a compromise would impact many devices in space being controlled from the GSaaS. It is not quite clear where the shared responsibility starts and ends for the new SataaS and GSaaS Space 4.0 service models but the satellite key management system (KMS), data, GSaaS credentials and analytics intellectual property (this may reside in the user’s environment, the cloud or potentially the satellite but for the purposes of this threat model we assume the cloud) will be much valued assets and targeted.

From the Cyber and Space Threat Landscape review in part 1 <insert link>, combined with our understanding of the Space 4.0 architecture and attack surfaces, we can start to model the threats in Table 1 below.

Table 1 – Space 4.0 threats, attack classes and layers, and attack vectors

Based on the above threat model, let’s discuss a real credible threat and attack scenario. From our Space cyber threat landscape review in part 1 of this blog series, there were attacks on ground stations in 2008 at the Johnson Space Center and for a Nasa research satellite. In a Space 4.0 scenario, the cybercriminal attacks the ground station through phishing to get access to satellite communications (could also be a supply chain attack to get a known vulnerable satellite system into space). The cybercriminal uses an exploit being sold on the underground to exploit a remote wormable vulnerability within the space TCP/IP stack or operating system of the satellite in space, just like we saw EternalBlue being weaponized by WannaCry. Once the satellite has been compromised the malware can spread between satellite vendors using their ISL communication protocol to propagate throughout the constellation. Once the constellation has been compromised the satellite vendor can be held to ransom, causing major disruption to Space 4.0 data and/or critical infrastructure.

Moving Forward Securely for a Trustworthy Space 4.0 Ecosystem

Establishing a trustworthy Space 4.0 ecosystem is going to require strong collaboration between cyber threat research teams, government, commercial and academia in the following areas:

1. Governance and regulation of security standards implementation and certification/validation of satellite device security capabilities prior to launch
2. Modeling the evolving threat landscape against the Space 4.0 technology advancements
3. Secure reference architectures for end to end Space 4.0 ecosystem and data protection
4. Security analysis of the CCSDS protocols
5. Design of trustworthy platform primitives to thwart current and future threats must start with a security capable bill of materials (BOM) for both hardware and software starting with the processor then the operating system, frameworks, libraries and languages. Hardware enabled security to achieve confidentiality, integrity, availability and identity so that satellite devices may be resilient when under attack
6. Visibility, detection and response capabilities within each layer defined in our Space 4.0 architecture threat model above
7. Development of a MITRE ATT&CK specifically for Space 4.0 as we observe real world incidents so that it can be used to strengthen the overall defensive security architecture using TTPs and threat emulation

Space 4.0 is moving very fast with GSaaS, SataaS and talk of space data centers and high-speed laser ISL; security should not be an inhibitor for time to market but a contributor to ensure that we have a strong security foundation to innovate and build future technology on with respect to the evolving threat landscape. Space communication predates the Internet so we must make sure any legacy limitations which would restrict this secure foundation are addressed. As software complexity for on board processing and connectivity/routing capability increases by moving to the edge (space device) we will see vulnerabilities within the Space 4.0 TCP/IP stack implementation.

This is a pivotal time for the secure advancement of Space 4.0 and we must learn from the mistakes of the past with IoT where the rush to adopt new and faster technology resulted in large scale deployment of insecure hardware and software. It has taken much effort and collaboration between Microsoft and the security research community since Bill Gates announced the Trustworthy Computing initiative in 2002 to arrive at the state-of-the-art Windows 10 OS with hardware enabled security. Likewise, we have seen great advancements on the IoT side with ARM Platform Security Architecture and Azure Sphere. Many security working groups and bodies have evolved since 2002, such as the Trust Computing Group, Confidential Computing Consortium, Trusted Connectivity Alliance and Zero Trust concept to name a few. There are many trustworthy building block primitives today to help secure Space 4.0, but we must leverage at the concept phase of innovation and not once a device has been launched into space; the time is now to secure our next generation infrastructure and data source. Space security has not been a priority for governments to date but that seems all set to change with the “Memorandum on Space Policy Directive-5—Cybersecurity Principles for Space Systems”.

We should pause here for a moment and recognize the recent efforts from the cybersecurity community to secure space, such as the Orbital Security Alliance, S-ISAC, Mantech and Defcon Hack-a-Sat.

KubOS is being branded as the Android of space systems and we are likely to see a myriad of new software and hardware emerge for Space 4.0. We must work together to ensure Space 4.0 connectivity does not open our global connectivity and infrastructure dependency to the next Mirai botnet or WannaCry worm on LEO.

McAfee would like to thank Cork Institute of Technology (CIT) and its Blackrock Castle Observatory (BCO) and the National Space Center (NSC) in Cork, Ireland for their collaboration in our mission to secure Space 4.0.

The post Securing Space 4.0 – One Small Step or a Giant Leap? Part 2 appeared first on McAfee Blog.

From June to August, part of the McAfee Advanced Threat Research (ATR) team participated in Microsoft’s Azure Sphere Research Challenge.  Our research resulted in reporting multiple vulnerabilities classified by Microsoft as “important” or “critical” in the platform that, to date, have qualified for over $160,000 USD in bounty awards scheduled to be contributed to the ACLU ($100,000), St. Jude’s Children’s Research Hospital ($50,000) and PDX Hackerspace (approximately $20,000). With these contributions, we hope to support and give back both to our local hacker community that has really stepped up to help during the COVID crisis, and also recognize, at a larger scale, the importance to protect and further civil liberties and the wellbeing of those most in need.  

This blog post is a high–level overview of the program, why we choose to take part in it, and a brief description of our findings. A detailed technical walkthrough of our findings can be found here.  

Additionally, Microsoft has released two summary blogs detailing the Azure Sphere Bounty Program as a whole, including McAfee’s efforts and findings. They can be found here:

MSRC Blog

Azure Sphere Core Team Blog

What is Azure Sphere and the Azure Sphere Research Challenge? 

In late May Microsoft started a new bug bounty program for its Azure Sphere platform. Azure Sphere is a hardened IoT device with a secure communication link to the cloud that has been in development for the last few years and reached general availability in early 2020. Microsoft designed and built it from scratch to ensure every aspect of it is as secure as possible, per their security model. To put the theory to test, Microsoft invited a few select partners and hackers to try their best to defeat its security measures.  

The Azure sphere team came up with multiple scenarios that would test the security model of the device and qualify for an increased payout from the regular Azure Bug Bounty program. These scenarios range from the ability to bypass certain security measures, to executing code in the hardware enabled secure core of the device.  

Research scenarios specific to the Azure Sphere Research Challenge 

Why did ATR get involved with the program? 

There are multiple reasons why we were keen to participate in this program. First, as security researchers, the Azure Sphere platform is an exciting new research target that has been built from the ground up with security in mind. It showcases what might become of the IoT space in the next few years as legacy platforms are slowly phased out. Being at the forefront of what is being done in the IoT space ensures our research remains current and we are ready to tackle future new challenges. Second, by finding critical bugs in this new platform we help make it more secure and offer our support to make the IoT space increasingly resistant to cyber threats. Finally, as this is a bug bounty program, we decided from the start that we would donate any award we received to charity, thus using our skills to contribute to the social good of our local communities and support causes that transcend the technology sector.   

Findings 

We’ve reported multiple bugs to Microsoft as a result of our research that were rated Important or Critical: 

• Important – Security Feature bypass ($3,300): The inclusion of symlink in application package allows for referencing files outside of the application package mount point. 
• Critical – RCE ($48,000): The inclusion of a “character device” in an application package allows for direct interaction with a part of the flash memory, eventually leading to the modification of critical system files and further exploitation. 
• Important – EoP ($11,000): Multiple bugs in how uid_map files are processed, allowing for elevation of privilege to the sys user.  
• Important – Eop ($11,000): A user with sys privileges can trick Application Manager into unmounting “azcore” and mount a rogue binary in its stead. Triggering a core dump of a running process will then execute the rogue binary with full capabilities & root privileges due to improper handling of permissions in the LSM. 
• Critical – EoP ($48,000): Further problems in the privilege dropping of “azcore” leads to the complete bypass of Azure Sphere capability restrictions 
• Critical – EoP ($48,000): Due to improper certificate management, it is possible to re-claim a device on the Azure Sphere pre-prod server and obtain a valid capability file that works in the prod environment. This capability file can be used to re-enable application development mode on a finalized device (claimed by a third party). The deployment of the capability file requires physical access to a device.  

Conclusion 

This research was an exciting opportunity to look at a new platform with very little prior research, while still being in the familiar territory of an ARM device running a hardened Linux operating-system.  

Through the bugs we found we were able to get a full chain exploit from a locked device to having root access. However, the Azure Sphere platform has many more security features such as remote attestation, and a hardware enabled secure core that is still holding strong.  

Finally, we want to thank Microsoft for the opportunity of participating in this exciting program, and the bounty awards.  

The post Our Experiences Participating in Microsoft’s Azure Sphere Bounty Program appeared first on McAfee Blog.

CVE-2020-16898: “Bad Neighbor”

CVSS Score: 8.8

Overview
Today, Microsoft announced a critical vulnerability in the Windows IPv6 stack, which allows an attacker to send maliciously crafted packets to potentially execute arbitrary code on a remote system. The proof-of-concept shared with MAPP (Microsoft Active Protection Program) members is both extremely simple and perfectly reliable. It results in an immediate BSOD (Blue Screen of Death), but more so, indicates the likelihood of exploitation for those who can manage to bypass Windows 10 and Windows Server 2019 mitigations. The effects of an exploit that would grant remote code execution would be widespread and highly impactful, as this type of bug could be made wormable. For ease of reference, we nicknamed the vulnerability “Bad Neighbor” because it is located within an ICMPv6 Neighbor Discovery “Protocol”, using the Router Advertisement type.

Vulnerability Details
A remote code execution vulnerability exists when the Windows TCP/IP stack improperly handles ICMPv6 Router Advertisement packets that use Option Type 25 (Recursive DNS Server Option) and a length field value that is even. In this Option, the length is counted in increments of 8 bytes, so an RDNSS option with a length of 3 should have a total length of 24 bytes. The option itself consists of five fields: Type, Length, Reserved, Lifetime, and Addresses of IPv6 Recursive DNS Servers. The first four fields always total 8 bytes, but the last field can contain a variable number of IPv6 addresses, which are 16 bytes each. As a result, the length field should always be an odd value of at least 3, per RFC 8106:

When an IPv6 host receives DNS options (i.e., RDNSS and DNSSL
options) through RA messages, it processes the options as follows:

   o  The validity of DNS options is checked with the Length field;
      that is, the value of the Length field in the RDNSS option is
      greater than or equal to the minimum value (3) and satisfies the
      requirement that (Length - 1) % 2 == 0.

When an even length value is provided, the Windows TCP/IP stack incorrectly advances the network buffer by an amount that is 8 bytes too few. This is because the stack internally counts in 16-byte increments, failing to account for the case where a non-RFC compliant length value is used. This mismatch results in the stack interpreting the last 8 bytes of the current option as the start of a second option, ultimately leading to a buffer overflow and potential RCE.

It is likely that a memory leak or information disclosure bug in the Windows kernel would be required in order to build a full exploit chain for this vulnerability. Despite this, we expect to see working exploits in the very near future.

Threat Surface
The largest impact here will be to consumers on Windows 10 machines, though with Windows Updates the threat surface is likely to be quickly minimized. While Shodan.io shouldn’t be counted on as a definitive source, our best queries put the number of Windows Server 2019 machines with IPv6 addresses is in the hundreds, not exceeding approximately 1000. This is likely because most servers are behind firewalls or hosted by Cloud Service Providers (CSPs) and not reachable directly via Shodan scans.

Detection
We believe this vulnerability can be detected with a simple heuristic that parses all incoming ICMPv6 traffic, looking for packets with an ICMPv6 Type field of 134 – indicating Router Advertisement – and an ICMPv6 Option field of 25 – indicating Recursive DNS Server (RDNSS). If this RDNSS option also has a length field value that is even, the heuristic would drop or flag the associated packet, as it is likely part of a “Bad Neighbor” exploit attempt.

Mitigation
Patching is always the first and most effective course of action. If this is not possible, the best mitigation is disabling IPv6, either on the NIC or at the perimeter of the network by dropping ICMPv6 traffic if it is non-essential. Additionally, ICMPv6 Router Advertisements can be blocked or dropped at the network perimeter. Windows Defender and Windows Firewall fail to block the proof-of-concept when enabled. It is unknown yet if this attack can succeed by tunneling the ICMPv6 traffic over IPv4 using technologies like 6to4 or Teredo. Our efforts to repeat the attack in this manner have not been successful to date.

For those McAfee customers who are unable to deploy the Windows patch, the following Network Security Platform (NSP) signatures will provide a virtual patch against attempted exploitation of this vulnerability, as well as a similar vulnerability (CVE-2020-16899). Unlike “Bad Neighbor”, the impact of CVE-2020-16899 is limited to denial-of-service in the form of BSoD.

NSP Attack ID: 0x40103a00 – ICMP: Windows IPv6 Stack Elevation of Privilege Vulnerability (CVE-2020-16898)
NSP Attack ID: 0x40103b00 – ICMP: Windows Function Discovery SSDP Provider Elevation of Privilege Vulnerability (CVE-2020-16899)

Additionally, we are releasing Suricata rules to detect potential exploitation of these vulnerabilities. Due to limitations in open source tools such as Snort and Suricata, we found that implementing the minimal detection logic described earlier required combining Suricata with its built-in Lua script parser. We have hosted the rules and Lua scripts at our public GitHub under CVE-2020-16898 and CVE-2020-16899 respectively. Although we have confirmed that the rules correctly detect use of the proof-of-concepts, they should be thoroughly vetted in your environment prior to deployment to avoid risk of any false positives.

The post CVE-2020-16898: “Bad Neighbor” appeared first on McAfee Blog.

McAfee’s Advanced Threat Research (ATR) today released research that uncovers previously undiscovered information on how Operation North Star evaluated its prospective victims and launched attacks on organizations in Australia, India, Israel and Russia, including defense contractors based in India and Russia.

McAfee’s initial research into Operation North Star revealed a campaign that used social media sites, spearphishing and weaponized documents to target employees working for organizations in the defense sector. This early analysis focused on the adversary’s initial intrusion vectors, the first stages of how an implant was installed, and how it interacted with the Command and Control (C2) server.

By deepening its investigation into the inner workings of North Star’s C2, McAfee ATR can now provide a unique view into not only the technology and tactics the adversary used to stealthily execute his attacks but also the kinds of victims he targeted.

The latest research probed into the campaign’s backend infrastructure to establish greater perspective into how the adversary targeted and assessed his victims for continued exploitation, and how he used a previously unknown implant called Torisma to execute this exploitation.

McAfee’s findings ultimately provide a unique view into a persistent cyber espionage campaign targeting high value individuals in possession of high value defense sector intellectual property and other confidential information.

VECTORS & INFRASTRUCTURE

Most analysis of cyber campaigns is typically reliant upon the dissection of malware and the telemetry of cyber defenses that have come into contact with those campaigns. McAfee’s analysis of Operation North Star complemented these elements by dissecting the C2 infrastructure that operated the campaign. In doing so, we gained a holistic view of its operations that is rarely available to threat researchers.

Attackers often send out many spearphishing emails to many potential targets rather than precisely targeting the highest value individuals. Once the victim opens a message and infects himself, the malware will try to fully exploit his system. But this broad, less precise approach of infecting many is “noisy” in that it is likely to be identified if these infections are happening at scale across an organization (let alone around the world).  Cyber defenses will eventually be able to recognize and stop it.

In the case of Operation North Star, the attackers researched their specific target victims, developed customized content to lure them, engaged them directly via LinkedIn mail conversations, and sent them sophisticated attachments that infected them in a novel way using a template injection tactic.

The campaign used legitimate job recruitment content from popular U.S. defense contractor websites to lure specific victims into opening malicious spear phishing email attachments. Notably, the attackers compromised and used legitimate web domains hosted in the U.S. and Italy to host their command and control capabilities. These otherwise benign domains belonged to organizations in a wide variety of fields, from an apparel manufacturer, to an auction house, to a printing company, to an IT training firm.

Using these domains to conduct C2 operations likely allowed them to bypass some organizations’ security measures because most organizations do not block trusted websites.

The first stage implant was delivered by DOTM files which, once established on a victim’s system, gathered information on that system such as disk information, free disk space information, computer name and logged in username and process information. It would then use a set of logic to evaluate the victim system data sent back by this initial implant to determine whether to install a second-stage implant called Torisma. All the while, it operated to achieve its objectives while minimizing the risk of detection and discovery.

General process flow and component relationship

Torisma is a previously undiscovered, custom-developed, second-stage implant focused on specialized monitoring of high value victims’ systems. Once installed, it would execute custom shellcode and run a custom set of actions depending on the victim systems’ profiles. The actions included active monitoring of the systems and execution of payloads based on observed events. For instance, it would monitor for an increase in the number of logical drives and Remote Desktop Sessions (RDS).

What is clear is that the campaign’s objective was to establish a long-term, persistent espionage campaign focused on specific individuals in possession of strategically valuable technology from key countries around the world.

VICTIMS & IMPACT

McAfee’s early analysis of Operation North Star’s spearphishing messages were written in Korean and exhibited mentions of topics specific to South Korean politics and diplomacy. But our latest analysis of North Star’s C2 log files enabled us to identify targets beyond South Korea:

• Two IP addresses in two Israeli ISP address spaces
• IP addresses in Australian ISP space
• IP address in Russian ISP address space
• India-based defense contractor
• Russian defense contractor

The campaign’s technologies and tactics—the installation of data gathering and system monitoring implants—suggests that the adversary is in a position to remain persistent, conduct surveillance on and exfiltrate sensitive data from its defense sector victims.

The detailed job descriptions used to lure victims and the selective use of the Torisma implant suggest that the attackers were pursuing very specific intellectual property and other confidential information from very specific defense technology providers. Less valuable victims were sidelined to be monitored silently over an extended period of time until they become more valuable.

VILLAINS & IMPLICATIONS

McAfee cannot independently attribute Operation North Star to a particular hacking group. McAfee has established that the code used in the spearphishing attachments is almost identical to that used by a 2019 Hidden Cobra campaign targeting Indian defense and aerospace companies. This could indicate that either Hidden Cobra is behind Operation North Star or another group is copying the group’s known and established technology and tactics. But sound, accurate attribution requires that technical analysis of such attacks be complemented by information from traditional intelligence sources available only to government agencies.

McAfee’s findings do suggest that the actors behind the campaign were more sophisticated than they initially appeared in our early analysis. They were focused and deliberate in what they meant to achieve and more disciplined and patient in their execution to avoid detection.

Please see our full report entitled “Operation North Star: Behind the Scenes” for a detailed review of ATR’s analysis of the campaign.

Also, please read our McAfee Defender’s blog to learn more about how you can build an adaptable security architecture against the Operation North Star campaign and others like it.

The post Operation North Star: Summary Of Our Latest Analysis appeared first on McAfee Blog.

Executive Summary

It is rare to be provided an inside view on how major cyber espionage campaigns are conducted within the digital realm. The only transparency afforded is a limited view of victims, a malware sample, and perhaps the IP addresses of historical command and control (C2) infrastructure.

The Operation North Star campaign we detailed earlier this year provided just this. This campaign used social media sites, spearphishing and weaponized documents to target employees working for organizations in the defense sector. This early analysis focused on the adversary’s initial intrusion vectors, described the first stages of how an implant was installed, and how it interacted with the Command and Control (C2) server.

However, that initial disclosure left gaps such as the existence of secondary payload, and additional insights into how the threat actors carried out their operations and who they targeted. The updated report takes a unique deep dive following our identification of previously undiscovered information into the backend infrastructure run by the adversaries.

These findings reveal a previously undiscovered secondary implant known as Torisma. However, more telling are the operational security measures that were undertaken to remain hidden on compromised systems. In particular, we saw the application of an Allow and Block list of victims to ensure the attacker’s secondary payload did not make its way to organizations that were not targeted. This tells us that certainly there has been a degree of technical innovation exhibited not only with the use of a template injection but also in the operations run by the adversary.

Finally, while we cannot confirm the extent of the success of the adversary’s attacks, our analysis of their C2 log files indicate that they launched attacks on IP-addresses belonging to internet service providers (ISPs) in Australia, Israel and Russia, and defense contractors based in Russia and India.

The findings within this report are intended to provide you, the reader, unique insights into the technology and tactics the adversary used to target and compromise systems across the globe.

Compromised Site

Operation North Star C2 infrastructure consisted of compromised domains in Italy and other countries. Compromised domains belonged, for example, to an apparel company, an auction house and printing company. These URLs hosted malicious DOTM files, including a malicious ASP page.

• hxxp://fabianiarte.com:443/uploads/docs/bae_defqa_logo.jpg
• hxxps://fabianiarte.com/uploads/imgproject/912EC803B2CE49E4A541068D495AB570.jpg
• https://www.fabianiarte.com/include/action/inc-controller-news.asp

The domain fabianiarte.com (fabianiarte.it) was compromised to host backend server code and malicious DOTM files. This domain hosted DOTM files that were used to mimic defense contractors’ job profiles as observed in Operation North Star, but the domain also included some rudimentary backend server code that we suspect was used by the implant. Log files and copies appeared in the wild pertaining to the intrusion of this domain and provided further insight. According to our analysis of this cache of data this site was compromised to host code on 7/9/2020.

Two DOTM files were discovered in this cache of logs and other intrusion data. These DOTM files belong to campaigns 510 and 511 based on the hard-coded value in the malicious VB scripts.

• 22it-34165.jpg
• 21it-23792.jpg

Developments in Anti-Analysis Techniques

During our analysis we uncovered two DOTM files as part of the cache of data pertaining to the backend. In analyzing first stage implants associated with the C2 server over a period of seven months, we found that there were further attempts by the adversary to obfuscate and confuse analysts.

Having appeared in July, these DOTM files contained first stage implants embedded in the same location as we documented in our initial research.  However, previous implants from other malicious DOTM files were double base64 encoded and the implants themselves were not further obfuscated. However, there were some notable changes in the method that differed from those detailed in our initial research:

• The first stage implant that is nested in the DOTM file, is using triple base64 encoding in the Visual Basic Macro
• The extracted DLL (desktop.dat) is packed with the Themida packer attempting to make analysis more difficult.

The first stage implant extracted from the DOTM files contains an encrypted configuration file and an intermediate dropper DLL. The configuration file, once decrypted, contains information for the first stage implant. The information includes the URL for the C2 and the decryption keys for the second stage payload called “Torisma”.

Contents of decrypted configuration

Because the configuration file contains information on how to communicate with the C2, it also stores the parameter options (ned, gl, hl). In this case, we see an unknown fourth parameter known as nl, however it does not appear to be implemented in the server-side ASP code. It is possible that the adversary may have intended to implement it in the future.

Appearance of nl parameter

In addition, analysis of the backend components for this compromised server enables us to draw a timeline of activity on how long the attacker had access. For example, the DOTM files mentioned above were placed on the compromised C2 server in July 2020. Some of the main malicious components involved in the backend operation were installed on this server in January 2020, indicating that this C2 server had been running for seven months.

Digging into the Heart of Operation North Star – Backend

Inc-Controller-News.ASP

As we covered in our initial Operation North Star research, the overall attack contained a first stage implant delivered by the DOTM files. That research found specific parameters used by the implant and that were sent to the C2 server.

Further analysis of the implant “wsdts.db” in our case, revealed that it gathers information of the victim’s system. For example:

• Get system disks information
• Get Free disk space information
• Get Computer name and (logged in) Username
• Process information

When this information is gathered, they will be communicated towards the C2 server using the parameters (ned, gl, hl).

These parameters are interpreted by an obfuscated server-side ASP page, based on the values sent will depend on the actions taken upon the victim. The server-side ASP page was placed on the compromised server January 2020.

Additionally, based on this information the adversary is targeting Windows servers running IIS to install C2 components.

The server-side ASP page contains a highly obfuscated VBScript embedded that, once decoded, reveals code designed to interact with the first stage implant. The ASP page is encoded with the VBScript.Encode method resulting in obfuscated VBScript code. The first stage implant interacts with the server-side ASP page through the usage of these finite parameters.

Encoded VBScript

Once the VBScript has been decoded it reveals a rather complex set of functions. These functions lead to installing additional stage implants on the victim’s system. These implants are known as Torisma and Doris, both of which are base64 encoded. They are loaded directly into memory via a binary stream once conditions have been satisfied based on the logic contained within the script.

Decoded VBScript

The ASP server-side script contains code to create a binary stream to where we suspect the Torisma implant is written. We also discovered that the Torisma implant is embedded in the ASP page and decoding the base64 blob reveals an AES encrypted payload. This ASP page contains evidence that indicates the existence of logic that decodes this implant and deliver it to the victim.

Depending on the values sent, additional actions are performed on the targeted victim. Further analysis of the server-side script indicates that there is logic that depends on some mechanism for the actor to place a victim’s IP address in an allowed-list file. The second stage implant is not delivered to a victim unless this condition is met first. This alludes to the possibility that the actor is reviewing data on the backend and selecting victims, this is likely performed through another ASP page discovered (template-letter.asp).

The server-side ASP page contains code to interpret the data sent via the following parameters to execute additional code. The values to these parameters are sent by the first stage implant initially delivered by the DOTM files. These parameters were covered in our initial research, however having access to the C2 backend code reveals additional information about their true purpose.

The URL query string is sent to the C2 server in the following format.

Further, code exists to get the infected victim’s IP address; this information is used to check if the IP address is allowed (get the second stage) or if the IP address has been blocked (prevent second stage). As mentioned previously, the addition of the victim’s IP address into the fake MP3 files is likely performed manually through identification of incoming connections through the stage 1 implant.

The full code of the logic gets the IP address for the connecting client machine and writing victim entries to a log file. In breaking down this code we can see different functionality is used that is most interesting. These log files are also stored within the WWW root of the compromised server based on the variable strlogpath.

From the below code-snippet of the vbscript, we can see that the “gl” and “hl” parameters are used to query the system information from the victim (gl) and the OS architecture (32 or 64 bits):

Victim Logging

The adversary keeps track of victims through logging functionality that is implemented into the server-side ASP code. Furthermore, as described above, the backend server code has the ability to perform victim logging based on first stage implant connections. This log file is stored in the WWW root directory on the compromised C2 server. The following code snippet will write data to a log file in the format [date, IP Address, User Agent, Campaign Code (NED), System Info (GL), OS Architecture (HL)].

The server-side ASP code will check whether the IP address is part of an allow-list or block-list by checking for the presence of the IP in two server-side files masquerading as MP3 files. The IP address is stored in the format of an MD5 hash, contained within the server-side code as a function to create a MD5 hash. The code is looking for these files in the WWW root of the compromised server based on the variable strWorkDir.

Using an ‘allow-list’ is a possible indication that it contained the list of their pre-determined targets.

IP allow-list / blocklist checking

For MD5 hash generation, the system appears to be using a non-standard form of hashing for the IP addresses. In most cases, the built in Microsoft cryptographic service provider would be used to generate an MD5. In this case, however, the actor chose to use a custom method instead.

The IP address is retrieved and hashed using this method.

The following function (ipopk) is set to read from a file that stores hashed IPs and will be used later in a conditional block statement. The code below will open and read a file, if there is no data the flag for ipok will result in 0, if there is data then the resulting value will be 1.

The following code is the logic to determine if an infected victim should receive the Torisma implant. A series of cases are used to make the decision depending on specific conditions as depicted in the code. Below the cases are explained:

• If the victim’s IP-address is on the allow-list, and the OS architecture bit value is “1” (resembling 64 bits), the Torisma 64 bits version implant will be sent to the victim and in the log file the term “case_1_64” is written behind the victim, meaning 64 bit version of the Torisma implant sent.
• Same for the second case but now for a 32-bit version OS (value 0) and the term “case_1_86” is written, meaning 32-bit implant version of torisma sent.
• If the ip-address of the victim is on the block list with either 32/64 bit OS architecture, a non-sense payload called “doris_x86” “doris_x64” will be sent to the victim. For example, in our case this was the value for “doris_x86”: DoriS_x86=”ddddddd”
• If condition “24” is returned from the victim, a log entry is written with value “case_3” and no implant sent and an http response status of 405 is sent
• If neither of the above conditions are met, “case_4” is written in the log-file, no implant sent and again an http response status of 405 is sent.

An http 405 response code indicates that the request method is known by the server but is not supported by the target resource.

Logic to deliver 2^nd stage implant to victim

Inside the Torisma Implant

One of the primary objectives of Operation North Star from what we can tell is to install the Torisma implant on the targeted victim’s system based on a set of logic. Further, the end goal is executing custom shellcode post Torisma infection, thus running custom actions depending on the specific victim profiles. As described earlier, Torisma is delivered based on data sent from the victim to the command and control server. This process relies on the first stage implant extracted from VB macro embedded in the DOTM file.

General process flow and component relationship

Further, Torisma is a previously unknown 2^nd stage implant embedded in the server-side ASP page as a base64 encoded blob. Embedded is a 64 and 32-bit version and depending on the OS architecture flag value sent by the victim and will determine what version is sent. Further this implant is loaded directly into memory as a result of interaction between the victim and the command and control server. The adversary went to great lengths to obfuscate, encrypt and pack the 1^st and 2^nd stage implants involved in this specific case.

Once Torisma is decoded from Base64 the implant is further encrypted using an AES key and compressed. The server-side ASP page does not contain any logic to decrypt the Torisma implant itself, rather it relies on decryption logic contained within the first stage implant. The decryption key exists in an encrypted configuration file, along with the URL for the command and control server.

This makes recovery of the implant more difficult if the compromised server code were to be recovered by incident responders.

The decryption method is performed by the first stage implant using the decryption key stored in the configuration file, this key is a static32-bit AES key. Torisma can be decoded with a decryption key 78b81b8215f40706527ca830c34b23f7.

Further, after decrypting the Torisma binary, it is found to also be packed with lz4 compression giving it another layer of protection. Once decompressing the code, we are now able to analyze Torisma and its capabilities giving further insight into Operation North Star and the 2^nd stage implant.

The variant of the implant we analyzed was created 7/2/2020; however, given that inc-controller-news.asp was placed on the C2 in early 2020, it indicates the possibility of multiple updates.

Based on the analysis, Torisma is sending and receiving information with the following URLs.

• hxxps://www.fabianiarte.com/newsletter/arte/view.asp
• hxxps://www.commodore.com.tr/mobiquo/appExtt/notdefteri/writenote.php
• hxxp://scimpex.com:443/admin/assets/backup/requisition/requisition.php

Encrypted Configuration File

Torisma also uses encrypted configuration files just as with the 1^st stage implant to indicate what URLs it communicates with as a command and control, etc.

Decrypted configuration file

The configuration file for Torisma is encrypted using the algorithm VEST[1] in addition to the communication sent over the C2 channel. From our research this encryption method is not commonly used anywhere, in fact it was a proposed cipher that did not become a standard to be implemented in general technologies[2].

Further, the FOUND002.CHK file recovered from the backend is used to update the configuration and contains just URLs with .php extension. These URLs have pages with a .php extension, indicating that some of the backend may have been written in PHP. It’s unclear what the role of the servers with .PHP pages have in the overall attack. Though we can confirm based on strings and functions in Torisma that there is code designed to send and receive files with the page view.asp. This view.asp page is the Torisma implant backend from what our analysis shows here. Later in this analysis we cover more on view.asp, however that page contained basic functionality to handle requests, send and receive data with an infected victim that has the Torisma implant.

Main Functionality

According to our analysis, the Torisma code is a custom developed implant focused on specialized monitoring.

The role of Torisma is to monitor for new drives added to the system as well as remote desktop connections. This appears to be a more specialized implant focused on active monitoring on a victim’s system and triggering the execution of payloads based on monitored events. The end objective of Torisma is executing shellcode on the victim’s system and sending the results back to the C2.

The Torisma code begins by running a monitoring loop for information gathering.

Information gathering loop

General Process

It runs the monitoring routine but will first check if monitoring is enabled based on the configuration (disabled by default). The general logic of this process is as follows:

1. If monitoring is disabled, just return
2. Else call the code that does the monitoring and upon completion temporarily disable monitoring
3. When run, the monitoring will be executed for a specified amount of time based on a configuration value
4. Upon return of the monitoring function, the code will proceed to command and control communication
5. If there is repeated failure in communication, the implant will force monitoring for 1hr and then retry the communication
6. Repeat forever

Triggering monitoring based on configuration

Monitoring

The monitoring loop will retrieve the address of WTSEnumerateSessionsW and the local mac address using GetAdaptersInfo.

1. The code will execute on a loop, until either enough time has elapsed (end time passed a parameter) or an event of interest occurred

Monitoring loop

2. It will monitor for an increase in the number of logical drives and Remote Desktop Sessions (RDS). If either occur, a status code will be set (5. New drive, 6. New RDS session) and the monitoring loop stops.

Drive tracking

a. It uses GetlogicalDrives to get a bitmask of all the drives available on the system, then iterates over each possible drive letter

b. It will also use GetDriveType to make sure the new drive is not a CD-ROM drive

Check drive type

3. It keeps track of the number of drives previously seen and will return 1 if the number has increased

RDP Session Tracking

The RDP session tracking function operates the same as the drive tracking. If the number increases by one it then returns 1. It uses WTSEnumerateSessionsW to get a list of sessions, iterates through them to count active ones.

Get active RDP sessions

Get active RDP sessions, continued

Command and Control Communication

The C2 code is interesting and is a custom implementation. The general process for this protocol is as follows.

1. Generates a connection ID that will be kept throughout this step as a hex string of five random bytes for each module (0x63) and random seeded with the output of GetTickCount64

Generate connection ID

2. Next it loads a destination URL
   a. There are three available servers hardcoded in the implant as an encrypted blob
   2. b. The decryption is done using a VEST-32 encryption algorithm with the hardcoded key ff7172d9c888b7a88a7d77372112d772

Configuration Decryption

c. A random configuration number is picked (mod 6) to select this configuration

d. There are only 3 configurations available, if the configuration number picked is above 3, it will keep incrementing (mod 6) until one is picked. Configuration 0 is more likely to be chosen because of this process.

Code to pick configurations

3. It will send a POST request to the URL it retrieved from the configuration with a “VIEW” action. It builds a request using the following hardcoded format string.

a. The process will be looking for the return of the string Your request has been accepted. ClientID: {f9102bc8a7d81ef01ba} to indicate success

4. If successful, it will retrieve data from the C2 via a POST request, this time it will use the PREVPAGE action

a. It uses the following format string for the POST request

b. The reply received from the server is encrypted it. To decrypt it the following process is needed

i. Replace space with +

ii. Base64 decode the result

iii. Decrypt the data with key “ff7172d9c888b7a88a7d77372112d772”

Server decryption using key

iv. Perform a XOR on the data

Perform XOR on the data

7. 7. The decrypted data is going to be used to execute a shellcode from the server and send data back

a. Data from the server will be split into a payload to execute and the data passed as an argument that is being passed to it
b. Part of the data blob sent from the server is used to update the local configuration used for monitoring

i. The first 8 bytes are fed to a add+xor loop to generate a transformed version that s compared to hardcoded values

Configuration check

Configuration check continued

ii. If the transformed data matched either of the two hardcoded values, the local configuration is updated

iii. In addition, the duration of the observation (for the Drive/RDS) loop can be updated by the server

iv. If the duration is above 0x7620 (21 days) it will then re-enable the monitoring even if the configuration detailed above had disabled it

v. If the transformed data doesn’t match any of the two hardcoded values, then monitoring will be disabled by the configuration

c. The implant will create a new communication thread and will wait until its notified to continue. It will then proceed to execute the shellcode and then wait for the other thread to terminate.

d. Depending on what occurred (an error occurred, or monitoring is enabled/disabled) the code will return a magic value that will decide if the code needs to run again or return to the monitoring process.

Return to communications loop

8. 8. The communications thread will create a new named pipe (intended to communicate with the shellcode). It the notifies the other thread once the pipe is ready and then proceed to send data read from the pipe to the server.

a. The pipe name is \\.\pipe\fb4d1181bb09b484d058768598b

Code for named pipe

b. It will read data from the pipe (and flag the processing as completed if it finds “- – – – – – – – -“

c. It will then send the data read back to the C2 by sending a POST in the following format

d. Data is encrypted following the same pattern as before, data is first XORED and then encrypted using VEST-32 with the same key as before

e. This will be repeated until the payload thread sends the “- – – – – – – – -“message or that the post failed

Campaign Identification

One way the adversary keeps track of what victims are infected by what version of the first stage implant is by using campaign IDs. These IDs are hard coded into the VB macro of the template document files that are retrieved by the first stage maldoc.

They are sent to the backend server through the NED parameter as covered earlier, further they are read and interpreted by the ASP code.

Victimology

According to the raw access logs for Inc-Controller-News.asp it is possible to understand what countries were impacted and it matches with the logs we discovered along another .asp page (view.asp), which we will explain later in the document.

Based on one of C2 log files we could identify the following about the victims:

• Russian defense contractor
• Two IP addresses in two Israeli ISP address spaces
• IP addresses in Australian ISP space
• IP address in Russian ISP address space
• India-based defense contractor

Template-letter.asp

During our investigation we uncovered additional information that led to the discovery of additional ASP pages. One ASP page discovered on the same compromised command and control server contained interesting code. First this ASP page is encoded in the same method using VB.Encode as we observed with the code that delivers the Torisma implant. Second it appears that the code is part of the core backend managed by the attacker and had the original file name of board_list.asp. Based on in the wild submission data the file board_list.asp first appeared in Korea October 2017, this suggests that this code for this webshell has been in use since 2017.

Further, this ASP page is a custom webshell that according to our knowledge and sources is not an off-the-shelf common webshell, rather something specifically used in these attacks. Some of the actions include browsing files, executing commands, connecting to a database, etc. The attacker is presented with the login page and a default base64 encoded password of ‘venus’ can be used to login (this value is hardcoded in the source of this page).

Template-Letter.ASP main page

Functionality to execute commands

 VIEW.ASP -Torisma Backend

The View.ASP file is equally important as the inc-controller-news.asp file and contains interesting functionality. This ASP page is the backend code for the Torisma implant, and the functions are intended to interact with the infected victim.

The view.asp file contains the following references in the code:

The file “FOUND001.CHK” contains a “logfile” as the CONST value name possibly refers to “logvault”.

Analyzing the possible victims revealed an interesting list:

• Russia-based defense contractor
• Two IP addresses in two Israeli ISP address spaces
• IP address in Russian ISP address space
• India-based defense contractor

The file “FOUND002.CHK” contains a Base64 string that decodes to:

hxxps://www.krnetworkcloud.org/blog/js/view.php|www.krnetworkcloud.org|2|/blog/js/view.php|NT

The above domain was likely compromised to host malicious code, given it belongs to an Indian IT training company.

The Const value name for “FOUND002.CHK” is “cfgvault”, the first three letters might refer to “configuration”. This ASP code contains additional functions that may indicate what role this page has in the overall scheme of things. View.asp is the Torisma implant backend code with numerous functions implemented to handle requests from the implant as described earlier in this analysis. Based on our analysis of both the Torisma implant and this backend code, some interesting insight has been discovered.  First implemented in the ASP code are the general actions that can be taken by this backend depending on the interaction with Torisma.

Some of these actions are triggered by the implant connecting and the others may be invoked by another process. The main ASP page is implemented to handle incoming requests based on a request ACTION with several possible options to call. Given that the implant is driven by the “ACTION” method when it comes to the C2 communication, a number of these cases could be selected. However, we only see code implemented in Torisma to call and handle the request/response mechanism for NEXTPAGE and PREVPAGE, thus these other actions are likely performed by the adversary through some other process.

General actions by View.ASP

ViewPrevPage

As described in the analysis, the ViewPrevPage action is a function designed to handle incoming requests from Torisma to get data. The data sent to Torisma appears to be in the form of ~dmf files. This content for the ViewPrevPage action comes in the form of shellcode intended to be executed on the victim side according to the analysis of the implant itself.

ViewPrevPage function

ViewNextPage

Torisma uses this method to send data back to the C2 server read from the named pipe. This is the results of the execution of the shellcode on the victim’s system through the ViewPrevPage action and the results of this execution are sent and processed using this function.

Implant sends data to C2

ViewGallery

There is no function in Torisma implemented to call this function directly, this is likely called from another administration tool, probably implemented in the upstream server. A static analysis of this method reveals that it is likely intended to retrieve log files in a base64 encoded format and write the response. Like the Torisma implant, there is a response string that is received by the calling component that indicates the log file had been retrieved successfully and that it should then delete the log file.

Retrieve and write log file content in base64 format (ViewGallery)

ViewMons

Another function also not used by Torisma is intended to set the local configuration file. It appears to use a different request method than ACTION; in this case it uses MAILTO. Based on insight gathered from Torisma, we can speculate this is related to configuration files that are used by the implant.

ViewMons function

SendData

This function is used in the RedirectToAdmin method exclusively and is the mechanism for sending data to the upstream C2. It depends on the GetConfig function that is based on the stored value in the cfgvault variable.

Send Data

RedirectToAdmin

This function is used to redirect information from an infected victim to the master server upstream. This is an interesting function indicating additional infrastructure beyond the immediate C2 with which we observed Torisma communicating.

RedirectToAdmin

WriteAgentLog

As part of the process of tracking victim’s with Torisma, the ASP code has a function to write log files. These resulting log files indicate success for the execution of shellcode on victims running Torisma. This logging method captures the user agent and IP address associated with the victim being monitored. This function is called when the information is sent to the master server via the RedirectToAdmin method.

Analysis of the server logs indicates the following countries made connections to the View.ASP page in July 2020.

• India
• Australia
• Israel
• Finland

Webshells

During our analysis we were able to determine that in some instances the attacker used webshells to maintain access. Discovered on another compromised server by the same actor with the same type of code was a PHP Webshell known as Viper 1337 Uploader. Based on our analysis this is a modified variant of Viper 1337 Uploader.

Some additional log file analysis reveals that a dotm file hosted with a. jpg extension was accessed by an Israeli IP address. This IP address likely belongs to a victim in Israel that executed the main DOCX. Based on the analysis of the user-agent string belonging to the Israel IP address Microsoft+Office+Existence+Discovery indicates that the dotm file in question was downloaded from within Microsoft Office (template injection).

Attacker Source

According to our analysis the attacker accessed and posted a malicious ASP script “template-letter.asp” from the IP address 104.194.220.87 on 7/9/2020.  Further research indicates that the attacker is originating from a service known as VPN Consumer in New York, NY.

Snipped from log file showing attacker IP 104.194.220.87

From the same logfiles, we observed the following User Agent String:

“Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+Win64;+x64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+ms-office;+MSOffice+16)”

Decoding the User Agent string we can make the following statement

The attacker is using a 64bit Windows 10 platform and Office 2016.

The Office version is the same as we observed in the creation of the Word-documents as described in our document analysis part of Operation NorthStar.

Conclusion

It is not very often that we have a chance of getting the C2 server code pages and associated logging in our possession for analysis. Where we started with our initial analysis of the first stage payloads, layer after layer we were able to decode and reveal, resulting in unique insights into this campaign.

Analysis of logfiles uncovered potential targets of which we were unaware following our first analysis of Operation North Star, including internet service providers and defense contractors based in Russia and India.

Our analysis reveals a previously unknown second stage implant known as Torisma which executes a custom shellcode, depending on specific victim profiles, to run custom actions. It also illustrates how the adversary used compromised domains in Italy and elsewhere, belonging to random organizations such as an auction house and printing company, to collect data on victim organizations in multiple countries during an operation that lasted nearly a year.

This campaign was interesting in that there was a particular list of targets of interest, and that list was verified before the decision was made to send a second implant, either 32 or 64 bits, for further and in-depth monitoring. Progress of the implants sent by the C2 was monitored and written in a log file that gave the adversary an overview of which victims were successfully infiltrated and could be monitored further.

Our findings ultimately provide a unique view into not only how the adversary executes his attacks but also how he evaluates and chooses to further exploit his victims.

Read our McAfee Defender’s blog to learn more about how you can build an adaptable security architecture against the Operation North Star campaign.

Special thanks to Philippe Laulheret for his assistance in analysis

[1] https://www.ecrypt.eu.org/stream/p2ciphers/vest/vest_p2.pdf

[2] https://www.ecrypt.eu.org/stream/vestp2.html

The post Operation North Star: Behind The Scenes appeared first on McAfee Blog.

CVSS Score: 9.8 

Vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C 

Overview 

Microsoft released a patch today for a critical vulnerability (CVE-2020-17051) in the Windows NFSv3 (Network File System) server. NFS is typically used in heterogenous environments of Windows and Unix/Linux for file sharing. The vulnerability can be reproduced to cause an immediate BSOD (Blue Screen of Death) within the nfssvr.sys driver. Interestingly, the November patches from Microsoft also include a remote kernel data read vulnerability in the same nfssvr.sys driver (CVE-2020-17056), which leads to a potential ASLR (address space layout randomization) bypass. The combination of these two vulnerabilities dramatically increases the likelihood of a remote exploit when used on Windows Server to bypass exploit mitigations.  CVE-2020-17051 is the first known vulnerability which has been disclosed within the Windows implementation of the NFSv3 protocol to the best of our knowledge.  

Threat Surface 

The vulnerability is believed to impact all versions of Windows Server when: 

1. An authenticated user has write access to any NFS share. 
2. An NFS share has been configured with anonymous write access (no authentication required) 

A Shodan query reported 38,893 servers with port 2049 exposed to the internet; however, it is unknown what percentage of these servers are actually NFS shares and actually configured with anonymous write access. The network share discovery technique is typically used by an adversary within the discovery phase of the MITRE ATT&CK framework with the objective to gain further privileges. CVE-2020-17051 would give adversaries the ability to spread worm–like within heterogenous Windows and Unix/Linux environments using anonymous write access file shares over NFSv3. 

Mitigation 

Patching is always the first and most effective course of action. If it’s not possible to patch, the best mitigation is to limit Windows NFSv3 server share write access internally and block any external access to vulnerable servers. For those McAfee customers who are unable to deploy the Windows patch, the following Network Security Platform (NSP) signatures will provide a virtual patch against attempted exploitation of this vulnerability. 

NSP Attack ID: 0x40c01200 – NFS Microsoft Windows Network File System Remote Code Execution Vulnerability (CVE-2020-17051) 

The post CVE-2020-17051: Remote kernel heap overflow in NFSv3 Windows Server appeared first on McAfee Blog.

Threat Intel Analyst: Antonis Terefos (@Tera0017)
Data Scientist: Anne Postma (@A_Postma)

1. Introduction

TA505 is a sophisticated and innovative threat actor, with plenty of cybercrime experience, that engages in targeted attacks across multiple sectors and geographies for financial gain. Over time, TA505 evolved from a lesser partner to a mature, self-subsisting and versatile crime operation with a broad spectrum of targets. Throughout the years the group heavily relied on third party services and tooling to support its fraudulent activities, however, the group now mostly operates independently from initial infection until monetization.

Throughout 2019, TA505 changed tactics and adopted a proven simple, although effective, attack strategy: encrypt a corporate network with ransomware, more specifically the Clop ransomware strain, and demand a ransom in Bitcoin to obtain the decryption key. Targets are selected in an opportunistic fashion and TA505 currently operates a broad attack arsenal of both in-house developed and publicly available tooling to exploit its victims. In the Netherlands, TA505 is notorious for their involvement on the Maastricht University incident in December 2019. 

To obtain a foothold within targeted networks, TA505 heavily relies on two pieces of malware: Get2/GetandGo and SDBbot. Get2/GetandGo functions as a simple loader responsible for gathering system information, C&C beaconing and command execution. SDBbot is the main remote access tool, written in C++ and downloaded by Get2/GetandGo, composed of three components: an installer, a loader and the RAT.

During the period March to June 2020, Fox-IT didn’t spot as many campaigns in which TA505 distributed their proven first stage malware. In early June 2020 however, TA505 continued to push their flavored GetandGo-SDBbot campaigns thereby slightly adjusting their chain of infection, now leveraging HTML redirects. In the meantime – and in line with other targeted ransomware gangs – TA505 started to operate a data leak platform dubbed “CL0P^_- LEAKS” on which stolen corporate data of non-paying victims is publicly disclosed.

The research outlined in this blog is focused around obtained Get2/GetandGo and SDBbot samples. We unpacked the captured samples and organized them within their related campaign. This resulted in providing us an accurate view on the working schedule of the TA505 group during the past year.

2. Infection Chain and Tooling

As mentioned above, the Threat Actor uses private as well as public tooling to get access, infect the network and drop Clop ransomware.

2.1. Email – XLS – GetandGo

1. The victim receives an HTML attachment. This file contains a link to a malicious website. Once the file is opened in a browser, it redirects to this compromised URL.

2. This compromised URL redirects again to the XLS file download page, which is operated by the actor.

3. From this URL the victim downloads the XLS file, frequently the language of the website can indicate the country targeted.

4. Once the XLS is downloaded and triggered, GetandGo is executed, communicates with the C&C and downloads SDBbot.

2.2. SDBbot Infection Process

1. GetandGo executes the “ReflectiveLoader” export of SDBbot.

2. SDBbot contains of three modules. The Installer, Loader, RAT module.

3.Initially the Installer module is executed, creates a Registry BLOB containing the Loader code and the RAT module.

4. The Loader module is dropped into disk and persistence is maintained via this module.

5. The Loader module, reads the Registry Blob and loads the Loader code. This loader code is executed and Loads the RAT module which is again executed in memory.

6. The RAT module communicates with the C&C and awaits commands from the administrator.

2.3. TA505 Infection Chain

Once SDBbot has obtained persistence, the actor uses this RAT in order to grab information from the machine, prepare the environment and download the next payloads. At this stage, also the operator might kill the bot if it is determined that the victim is not interesting to them.

For further infection of victims and access of administrator accounts, FOX-IT has also observed Tinymet and Cobalt Strike frequently being used.

3. TA505 Packer

To evade antivirus security products and frustrate malware reverse engineering, malware operators leverage encryption and compression via executable packing to protect their malicious code. Malware packers are essentially software programs that either encrypt or compress the original malware binary, thus making it unreadable until it’s placed in memory.

In general, malware packers consist of two components:
• A packed buffer, the actual malicious code
• An “unpacking stub” responsible for unpacking and executing the packed buffer

TA505 also works with a custom packer, however their packer contains two buffers. The initial stub decrypts the first buffer which acts as another unpacking stub. The second unpacking stub subsequently unpacks the second buffer that contains the malicious executable. In addition to their custom packer, TA505 often packs their malware with a second or even a third layer of UPX (a publicly available open-source executable packer).

Below we represent an overview of the TA505 packing routines seen by Fox-IT. In total we can differentiate four different packing routines based on the packing layers and the number of observed samples.

To aid our research, a Fox-IT analyst wrote a program dubbed “TAFOF Unpacker” to statically unpack samples packed with the custom TA505 packer.

We observed that the TA505 packed samples had a different Compilation Timestamp than the unpacked samples, and they were correlating correctly with the Campaign Timestamp. Furthermore, samples belonging to the same campaign used the same XOR-Key to unpack the actual malware.

4. Data Research

Over the course of approximately a year, Fox-IT was able to collect TA505 initial XLS samples. Each XLS file contained two embedded DLLs: a x64 and a x86 version of the Get2/GetandGo loader.

Both DLLs are packed with the same packer. However, the XOR-key to decrypt the buffer is different. We have “named” the campaigns we identified based on the combination of those XOR-Keys: x86-XOR-Key:x64-XOR-Key (e.g. campaign 0X50F1:0X1218). All of the timestamps related to the captured samples were converted to UTC. For hashes that existed on VirusTotal we used those timestamps as first seen; for the remainder, the Fox-IT Malware Lab was used.

Find below an overview on the descriptive statistics of both datasets:

4.1. Dataset 1, Working Hours and Workflow routine

During this period, we collected all the XLS files matching our TA505-GetandGo Yara rule and we unpacked them with TAFOF Unpacker. We observed that the compilation timestamps of the packed samples were different from the unpacked ones. Furthermore, the unpacked one was clearly indicating the malspam campaign date.

For the Dataset 1, we used the VirusTotal first seen timestamp as an estimation of when the campaign took place.

In the following graph we plotted all 81 campaigns (XOR-key combinations), and ordered them chronologically based on the C&C domain registration time.

What we noticed was, that we see relatively short orange/yellow/light green patches: meaning that the domain was registered shortly before they compiled the malware, and a few hours/days the first sample of this campaign was found on VirusTotal.

As seen by the graph, it seems clear the workflow followed most of the times by the group: Registering the C&C, compiling the malware and shortly after, releasing the malspam campaign.

As seen on the 37% of the campaigns, the first seen sample and compilation timestamp are observed within 12 hours, while 79% of the campaigns are discovered after 1 day of the compilation timestamp and 91.3% within 2 days.

We can also observe the long vacations taken during the Christmas/New Year period (20th December 2019 until 13th of January 2020), another indication of Russian Cybercrime groups.

The group mostly works on Mondays, Wednesdays and Thursdays, less frequently Tuesdays, Fridays and Sundays (mostly preparing for Monday campaign). As for the time, earliest is usually 6 AM UTC and latest 10 PM UTC. Those time schedules give us once again a small indication about the time zone where the actor is operating from.

4.2. Dataset 2, Working Hours and Workflow routine

For the Dataset 2, we used as a source the first seen date of the InTELL Malware Lab. This dataset contains samples obtained after their time off. In this research we combined SDBbot data as well, which is the next stage payload of Get2. Furthermore, for this second dataset we managed to collect TA505 malspam emails from actual targets/victims indicating the country targeted from the email’s language.

From the above graph we can clearly behold, that multiple GetandGo campaigns were downloading the “same SDBbot” (same C&C). This information makes even more clear the actual use of the short lifespan of a GetandGo C&C, which is to miss the link with the SDBbot C&C (as happened for this research on the 24^th of June). This allows the group for a longer lifespan of the SDBbot C&C, avoiding being easily detected.

The working days are the same since they restarted after their long time off, although now we see a small difference on the working hours, starting as early as 5 AM UTC until 11 PM UTC. This small 1 hour difference from the earliest working time might indicate that the group started “working from home” like the rest of the world during these pandemic times. However as both periods are in respectively winter and summer time, it could also be related to daylight savings time. This combined with the prior knowledge that the group is communicating in Russian language this points specifically to Ukraine being the only majority Russian speaking country with DST, but this would be speculation by itself.

The time information does point however to a likely Eastern European presence of the group, and not all members have to be necessarily in one country.

When we plotted also the SDBbot compilation timestamps we observed that GetandGo is more of a morning/day work for the group as they need to target victims during their working schedule, but SDBbot is performed mostly during the evening, as they don’t need to hurry as much in this case.

5. Dransom Time

“Dransom time, is the period from when a malicious attack enters the network until the ransomware is released.”

Once the initial access is achieved, the group is getting its hands on SDBbot and starts moving laterally in order to obtain root/admin access to the victim company/organization. This process can vary from target to target as well as the duration from initial access (GetandGo) to ransomware (Clop).

The differences on the Dransom time manifests that the group is capable of staying undetected for long periods of time (more than 2 months), as well as getting root access as fast as their time allows (3 days).

* There are definitely more extreme Dransom times accomplished by this group, but the above are some of the ones we encountered and managed to obtain.

6. Working Schedule

With the above data at hand, we were able to accurately estimate the work focus of the group at specific days and times during the past year.

The below week dates are some examples of this data, plotted in a weekly schedule (time in UTC).

* Each color represents a different campaign.

6.1. Week 42, 14-20 of October 2019

During this week, the group released six different campaigns targeting various geographical regions. We observe the group preparing two Monday campaigns on Sunday. And as for Tuesday, they managed to achieve the initial infection at Maastricht University.

On Wednesday, the group performed two campaigns targeting different regions, although this time they used the same C&C domain and the only difference was the URL path (f1610/f1611).

6.2. Week 43, 21-27 of October 2019

Throughout week 43, the group performed three campaigns. First campaign was released on Monday and was partially prepared on Sunday.

As for Wednesday, the group prepared and released a campaign on the same day, which resulted on the initial infection of Antwerp University. For the next three to four days, the group managed to get administrator access, and released Clop ransomware on Saturday of the same week.

6.3. Week 51, 16-22 of December 2019

Week 51 was the last week before their ~20 days “vacation” period where Fox-IT didn’t observe any new campaigns. Last campaign of this week was observed on Thursday.

During those days of “vacations”, the group was mainly off, although they were spotted activating Clop ransomware at Maastricht University and encrypting their network after more than two months since the initial access (week 42).

6.4. Week 2, 6-12 of January 2020

While on week 2 the group didn’t release any campaigns, they were observed preparing the first campaign since their “vacations” on late Sunday, to be later released on Monday of the 3^rd week.

7. Conclusion

The extreme Dransom times demonstrate a highly sophisticated and capable threat actor, able to stay under the radar for long periods of time, as well as quickly achieving administrator access when possible. Their working schedule manifests a well-organized and well-structured group with high motivation, working in a criminal enterprise full days starting early and finishing late at night when needed. The hourly timing information does suggest that the actors are in Eastern Europe and mostly working along a fairly set schedule, with a reasonable possibility that the group resides in Ukraine as the only majority Russian speaking country observing daylight savings time. Since their MO switched after the introduction of Clop ransomware in early 2019, TA505 has been an important threat to all kind of organizations in various sectors across the world.

TL; DR: this blog post serves as an advisory for both: CVE-2020-28054: An Authorization Bypass vulnerability affecting JamoDat – TSMManager Collector v. <= 6.5.0.21 A Stack Based Buffer Overflow affecting IBM Tivoli Storage Manager – ITSM Administrator Client Command Line Administrative Interface (dsmadmc.exe) Version 5, Release 2, Level 0.1. Unfortunately, after I had one of […]

The post Tivoli Madness appeared first on VoidSec.

Abstract.  Due to its popularity, iOS has attracted the attention of a large number of security researchers.  Apple is constantly improving iOS security, develops and adapts new mitigations at a rapid pace. In terms of the effectiveness of mitigation measures, Apple increases the complexity of hacking iOS devices making it one of the hardest platforms to hack, however, it is not yet sufficient to block skilled individuals and well-funded groups from achieving remote code execution with elevated permissions, and persistence on the device.

This blog post is the first of multiple in a series of achieving elevated privileges on iOS. 

This series of posts will go all the way until privileged access is obtained, the userspace exploit, as well as persistence on the device following a reboot. The full reports are currently available to iOS Threat Intelligence subscribers of ZecOps Mobile Threat Intelligence.

We will cover in detail how chaining a few bugs leads us to run code in the context of iOS kernel. Chaining such bugs with other exploits (e.g. the iOS MailDemon vulnerability, or other webkit based bugs) allow to gain full remote control over iOS devices.

This exploit was obtained as part of ZecOps Reverse Bounty, and donated to FreeTheSandbox initiative.

Freethesandbox.org – Free The Sandbox restrictions from iOS & Android devices

We would like to thank @08Tc3wBB for participating in ZecOps Reverse Bounty, and everyone else that helped in this project. We would also like to thank the Apple Security team for fixing these bugs and preventing further abuse of these bugs in up to date versions of iOS.

As we’re planning to release the additional blogs, we are already releasing a full Local Privilege Escalation chain that works on iOS 13.7 and earlier versions on both PAC and non-PAC devices.

We are making this release fully open-source for transparency. We believe that it is the best outcome to improve iOS research and platform security.

The Vulnerabilities – Part I

AppleAVE2 is a graphics IOKit driver that runs in kernel space and exists only on iOS and just like many other iOS-exclusive drivers, it’s not open-source and most of the symbols have been removed. 

The driver cant be accessed from the default app sandbox environment, which reduces the chances of thorough analysis by Apple engineers or other researchers. The old implementation of this driver seems like a good attack surface and the following events demonstrate this well. 

Back in 2017,  7 vulnerabilities were exposed in the same driver, by Adam Donenfeld of the Zimperium zLabs Team,

From the description of these vulnerabilities, some remain attractive even today, while powerful mitigations like PAC (for iPhones/iPads with A12 and above) and zone_require (iOS 13 and above) are present, arbitrary memory manipulation vulnerabilities such as CVE-2017-6997, CVE-2017-6999 play a far greater role than execution hijacking type, have great potential when used in chain with various information leakage vulnerabilities.

Despite the fact that these vulnerabilities have CVEs, which generally indicating that they have been fixed, Apple previously failed to fix bugs in one go and even bug regressions. With that in-mind, let’s commence our journey to hunt the next AVE vulnerability! 

We will start off from the user-kernel data interaction interface:

AppleAVE2 exposes 9 (index 0-8) methods via rewriting IOUserClient::externalMethod:

Two exposed methods (index 0 and 1) allow to add or remove clientbuf(s), by the FIFO order.

The rest of the methods (index 3-8) are all eventually calling AppleAVE2Driver::SetSessionSettings through IOCommandGate to ensure thread-safe and avoid racing.

 *1 Overlapping Segment Attack against dyld to achieve untethered jailbreak, first appearance in iOS 6 jailbreak tool — evasi0n, then similar approach shown on every public jailbreak, until after Pangu9, Apple seems finally eradicated the issue.
*2  Apple accidentally re-introduces previously fixed security flaw in a newer version.

We mainly use method at index 7 to encode a clientbuf, which basically means to load many IOSurfaces via IDs provided from userland, and use method at index 6 to trigger trigger the multiple security flaws located inside AppleAVE2Driver::SetSessionSettings.

The following chart entails a relationship map between salient objects:

clientbuf is memory buffer allocated via IOMalloc, with quite significant size (0x29B98 in iOS 13.2).

Every clientbuf objext thats is being added contains pointers to the front and back, forming a double-linked list, so that the AppleAVE2Driver’s instance stores only the first clientbuf pointer.

The clientbuf contains multiple MEMORY_INFO structures. When user-space provides IOSurface, an iosurfaceinfo_buf will be allocated and then used to fill these structures.

iosurfaceinfo_buf contains a pointer to AppleAVE, as well as variables related to mapping from user-space to kernel-space.

As part of the clientbuf structure, the content of these InitInfo_block(s) is copied from user-controlled memory through IOSurface, this happens when the user first time calls another exposed method(At index 7) after adding a new clientbuf.

m_DPB is related to arbitrary memory reading primitive which will be explained later in this post.

Brief Introduction to IOSurface

In case if you are not familiar with IOSurface, read the below:

According to Apple’s description IOSurface is used for sharing hardware-accelerated buffer data ( for framebuffers and textures) more efficiently across multiple processes.

Unlike AppleAVE, an IOSurface object can be easily created by any userland process (using IOSurfaceRootUserClient). When creating an IOSurface object you will get a 32 bit long Surface ID number for indexing purposes in the kernel so that the kernel will be able to map the userspace memory associated with the object into kernel space.  

Now with these concepts in mind let’s talk about the AppleAVE vulnerabilities. 

The First Vulnerability (iOS 12.0 – iOS 13.1.3)

The first AppleAVE vulnerability has given CVE-2019-8795 and together with other two vulnerabilities — A Kernel Info-Leak(CVE-2019-8794) that simply defeats KASLR, and a Sandbox-Escape(CVE-2019-8797) that’s necessary to access AppleAVE, created an exploit chain on iOS 12 that was able to jailbreak the device. That’s until the final release of iOS 13, which  destroyed the Sandbox-Escape by applying sandbox rules to the vulnerable process and preventing it from accessing AppleAVE, So the sandbox escape was replaced with another sandbox escape vulnerability that was discussed before. 

The first AppleAVE vulnerability was eventually fixed after the update of iOS 13.2.

Here is a quick description about it and for more detailed-write up you can look at a previous writeup.

When a user releases a clientbuf, it will go through every MEMORY_INFO that the clientbuf contains and will attempt to unmap and release related memory resources.

The security flaw is quite obvious if you compare to how Apple fixed it:

The unfixed version has defect code due to an  out-of-bounds access that allows an attacker to hijack kernel code execution in regular and PAC-enabled devices. This flaw can also become an arbitrary memory release primitive via the operator delete. and back then, before Apple fixed zone_require flaw on iOS 13.6, that was enough to achieve jailbreak on the latest iOS device.

The POC released today is just an initial version that will allow others to take it further. The POC shares basic analytics data with ZecOps to find additional vulnerabilities and help further secure iOS – this option can be disabled in the source.

In the next posts we’ll cover:

• Additional vulnerabilities in the kernel
• Exploiting these vulnerabilities
• User-space vulnerabilities
• The ultimate persistence mechanism that is likely to never be patched

Hear the news first

• Only essential content
• New vulnerabilities & announcements
• News from ZecOps Research Team

Keep Me Updated

Your subscription request to ZecOps Blog has been successfully sent.

We won’t spam, pinky swear

Follow @ZecOps

This is a story about a Microsoft Teams crash that we investigated recently. At first glance, it looked like a possible arbitrary code execution vulnerability, but after diving deeper we realized that there’s another explanation for the crash.

TLDR;

• ZecOps ingested and analyzed an event that seems exploitable on a Windows machine from Microsoft Teams
• This machine has a lot of other anomalies
• ZecOps verifies anomalies such as: blue screens, sudden crashes, mobile restarts without clicking on the power button; and determines if they are related to cyber attacks, software/hardware issues, or configuration problems. 
• Spoiler alert (text beneath the black highlight):

After further analyzing the crash, we realized that the faulty hardware was causing this exploitable event to appear, and not related to an intentional attack. We suspect that a bit flip was caused due to a bad hardware component.

• Business impact: Hardware problems are more common than we think. Repeating faulty hardware-issues lead to continuous loss of productivity, context-switches, and IT/Cyber disruptions. Identifying faulty hardware can save a lot of time. We recommend using the freely available and agent-less tool ZOTOMATE to identify what is SW/HW problems. ZecOps is leveraging machine-learning and its mobile threat intelligence, mobile DFIR, as well as endpoints and servers crash analysis solution, and mobile apps crash-analysis to perform such analysis at scale. 

The crash

Looking at the call stack, we saw that the process crashed due to a stack overflow:

 # Child-SP          RetAddr               Call Site
00 000000e5`84600f20 00007ffd`9048ebbc     ntdll!RtlDispatchException+0x3c
01 000000e5`84601150 00007ffd`9049a49a     ntdll!RtlRaiseStatus+0x5c
02 000000e5`846016f0 00007ffd`9048ebbc     ntdll!RtlDispatchException+0xa5cba
03 000000e5`84601e20 00007ffd`9049a49a     ntdll!RtlRaiseStatus+0x5c
04 000000e5`846023c0 00007ffd`9048ebbc     ntdll!RtlDispatchException+0xa5cba
05 000000e5`84602af0 00007ffd`9049a49a     ntdll!RtlRaiseStatus+0x5c
06 000000e5`84603090 00007ffd`9049350e     ntdll!RtlDispatchException+0xa5cba
07 000000e5`846037c0 00007ffd`9048eb73     ntdll!KiUserExceptionDispatch+0x2e
08 000000e5`84603f60 00007ffd`9049a49a     ntdll!RtlRaiseStatus+0x13
09 000000e5`84604500 00007ffd`9048ebbc     ntdll!RtlDispatchException+0xa5cba
0a 000000e5`84604c30 00007ffd`9049a49a     ntdll!RtlRaiseStatus+0x5c
0b 000000e5`846051d0 00007ffd`9048ebbc     ntdll!RtlDispatchException+0xa5cba
[307 more pairs of RtlRaiseStatus and RtlDispatchException]
272 000000e5`846fb670 00007ffd`9049a49a     ntdll!RtlRaiseStatus+0x5c
273 000000e5`846fbc10 00007ffd`9049350e     ntdll!RtlDispatchException+0xa5cba
274 000000e5`846fc340 00007ff7`8b93338a     ntdll!KiUserExceptionDispatch+0x2e
275 000000e5`846fcad0 00007ff7`8b922e4d     Teams!v8_inspector::V8StackTraceId::ToString+0x39152a
[More Teams frames...]
2c1 000000e5`846ffa40 00007ffd`9045a271     kernel32!BaseThreadInitThunk+0x14
2c2 000000e5`846ffa70 00000000`00000000     ntdll!RtlUserThreadStart+0x21

It can be seen from the call stack that the original exception occurred earlier, at address 00007ff7`8b93338a. Due to an incorrect exception handling, the RtlDispatchException function raised the STATUS_INVALID_DISPOSITION exception again and again in a loop, until no space was left in the stack and the process crashed. That’s an actual bug in Teams that Microsoft might want to fix, but it manifests itself only when the process is about to crash anyway, so that might not be a top priority.

The original exception

To extract the original exception that occurred on address 00007ff7`8b93338a, we did what Raymond Chen suggested in his blog post, Sucking the exception pointers out of a stack trace. Using the .cxr command with the context record structure passed to the KiUserExceptionDispatcher function, we got the following output:

0:000> .cxr 000000e5846fc340
rax=00005f5c70818010 rbx=00005f5c70808010 rcx=000074e525bf0e08
rdx=0000006225f01970 rsi=000016b544b495b0 rdi=0001000000000000
rip=00007ff78b93338a rsp=000000e5846fcad0 rbp=0000000000000009
 r8=000000e5846fcb68  r9=00000000ff000000 r10=0000000000ff0000
r11=000000cea999e331 r12=00005f5c70808010 r13=0000000000001776
r14=0000006225f01970 r15=000000e5846fcaf8
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
Teams!v8_inspector::V8StackTraceId::ToString+0x39152a:
00007ff7`8b93338a 488b07          mov     rax,qword ptr [rdi] ds:00010000`00000000=????????????????

The original exception was triggered by accessing an invalid pointer of the value 00010000`00000000. Not only does the pointer look invalid, It’s actually a non-canonical address in today’s hardware implementations of x86-64, which means that it can’t ever be allocated or become valid. Next, we looked at the assembly commands below the crash:

0:000> u
Teams!v8_inspector::V8StackTraceId::ToString+0x39152a:
00007ff7`8b93338a 488b07          mov     rax,qword ptr [rdi]
00007ff7`8b93338d 4889f9          mov     rcx,rdi
00007ff7`8b933390 ff5008          call    qword ptr [rax+8]
[...]

Very interesting! If we can control the rdi register at this point of the execution, that’s a great start for arbitrary code execution. All we need to control the instruction pointer is to be able to build a fake virtual table, or to use an existing one, and the lack of support for Control Flow Guard (CFG) makes things even easier. As a side note, there’s an issue about adding CFG support which is being actively worked on.

At this point, we wanted to find answers to the following questions:

• How can this bug be reproduced?
• What source of input can trigger the bug? Specifically, can it be triggered remotely?
• To what extent can the pointer be controlled?

The original exception stack trace

In order to try and reproduce the crash, we needed to gather more information about what was going on when the exception occurred. We checked the original exception stack trace and got the following:

0:000> k
 # Child-SP          RetAddr               Call Site
00 000000e5`846fcad0 00007ff7`8b922e4d     Teams!v8_inspector::V8StackTraceId::ToString+0x39152a
01 000000e5`846fcb40 00007ff7`8b92f29b     Teams!v8_inspector::V8StackTraceId::ToString+0x380fed
02 000000e5`846fcbc0 00007ff7`8b92f21f     Teams!v8_inspector::V8StackTraceId::ToString+0x38d43b
03 000000e5`846fcc00 00007ff7`8b9308c0     Teams!v8_inspector::V8StackTraceId::ToString+0x38d3bf
04 000000e5`846fcc80 00007ff7`8b064123     Teams!v8_inspector::V8StackTraceId::ToString+0x38ea60
05 000000e5`846fce10 00007ff7`8b08b411     Teams!v8::Unlocker::~Unlocker+0xf453
06 000000e5`846fce60 00007ff7`8b088f16     Teams!v8::Unlocker::~Unlocker+0x36741
07 000000e5`846fd030 00007ff7`8b087eff     Teams!v8::Unlocker::~Unlocker+0x34246
08 000000e5`846fd190 00007ff7`8b053b79     Teams!v8::Unlocker::~Unlocker+0x3322f
09 000000e5`846fd1c0 00007ff7`8b364e51     Teams!v8::Unwinder::PCIsInV8+0x22059
0a 000000e5`846fd2e0 00007ff7`8b871abd     Teams!v8::internal::TickSample::print+0x54071
0b 000000e5`846fd3d0 00007ff7`8b84e3b8     Teams!v8_inspector::V8StackTraceId::ToString+0x2cfc5d
0c 000000e5`846fd420 00005ebc`b2fdc6a9     Teams!v8_inspector::V8StackTraceId::ToString+0x2ac558
0d 000000e5`846fd468 00007ff7`8b800cb8     0x00005ebc`b2fdc6a9
[More Teams frames...]
4c 000000e5`846ffa40 00007ffd`9045a271     kernel32!BaseThreadInitThunk+0x14
4d 000000e5`846ffa70 00000000`00000000     ntdll!RtlUserThreadStart+0x21

It can be deduced from the large offsets that something is wrong with the symbols, as Raymond Chen also explains in his blog post, Signs that the symbols in your stack trace are wrong. In fact, Teams comes with no symbols, and there’s no public symbol server for it, so the symbols we see in the stack trace are some of the few functions exported by name. Fortunately, Teams is based on Electron which is open source, so we were able to match the Teams functions on the stack to the same functions in Electron. At first, we tried to do that with a binary diffing tool, but it didn’t work so well due to the executable/symbol files being so large (exe – 120 MB, pdb – 2 GB), so we ended up matching the functions manually.

Here’s what we got after matching the symbols:

 # Call Site
00 WTF::WeakProcessingHashTableHelper<...>::Process
01 blink::ThreadHeap::WeakProcessing
02 blink::ThreadState::MarkPhaseEpilogue
03 blink::ThreadState::AtomicPauseMarkEpilogue
04 blink::UnifiedHeapController::TraceEpilogue
05 v8::internal::GlobalHandles::InvokeFirstPassWeakCallbacks
06 v8::internal::Heap::CollectGarbage
07 v8::internal::Heap::CollectGarbage
08 v8::internal::Heap::HandleGCRequest
09 v8::internal::StackGuard::HandleInterrupts
0a v8::internal::Runtime_StackGuard
0b v8::internal::compiler::JSCallReducer::ReduceArrayIteratorPrototypeNext
0c Builtins_ObjectPrototypeHasOwnProperty
[...]

WTF was indeed our reaction when we saw where the exception occurred (which, of course, means Web Template Framework).

From what we can see, the hasOwnProperty object method was called, at which point the garbage collection was triggered, and the invalid pointer was accessed while processing one of its internal hash tables. Could it be that we found a memory bug in the V8 garbage collection? We believed it to be quite unlikely. And if so, how do we reproduce it?

Switching context

At this point we put the Teams crash on hold and went on to look at the other crashes which occurred on the same computer. Once we did that, it all became clear: it had several BSODs, all of the type MEMORY_CORRUPTION_ONE_BIT, indicating a faulty memory/storage hardware. And looks like that’s exactly what happened in the Teams crash: the faulty address was originally a NULL pointer, but because of a corrupted bit it became 00010000`00000000, causing the exception and the crash.

Conclusion

The conclusion is that the relevant computer needs to have its faulty hardware replaced, and of course there’s nothing wrong with V8’s garbage collection that has anything to do with the crash. That’s yet another reminder that hardware problems can cause various anomalies that are hard to explain, such as this Teams crash or crashing at the xor eax, eax instruction.

Hear the news first

• Only essential content
• New vulnerabilities & announcements
• News from ZecOps Research Team

Keep Me Updated

Your subscription request to ZecOps Blog has been successfully sent.

We won’t spam, pinky swear

Follow @ZecOps

Summary

We’re going to work on an operating system which is designed specifically for fuzzing! This is going to be a streaming series for most of December which will cover making a new operating system with a strong focus on fuzzing. This means that things like the memory manager, determinism, and scalability will be the most important parts of the OS, and a lot of effort will go into making them super fast!

When

Streaming will start sometime on Thursday, December 10th, probably around 18:00 UTC, but the streams will be at relatively random times on relatively random days. I can’t really commit to specific times!

Streams will likely be 4-5 days a week (probably M-F), and probably 8-12 hours in length. We’ll see, who knows, depends how much fun we have!

Where

You’ll be able to find the streams live on my Twitch Channel, and if you’re unlucky and miss the streams, you’ll be able to find the recordings on my YouTube Channel! Don’t forget to like, comment, and subscribe, of course.

What

So… ultimately, I don’t really know what all will happen. But, I can predict a handful of things that we’ll do. First of all, it’s important to note that these streams are not training material. There is no prepared script, materials, flow, etc. If we end up building something totally different, that’s fine and we’re just going with the flow. There is no requirement of completing this project, or committing to certain ways the project will be done. So… with that aside.

We’ll be working on making an operating system, specifically for x86-64 (Intel flavor processors at the start, but AMD should work in non-hypervisor mode). This operating system will be designed for fuzzing, which means we’ll want to focus on making virtual memory management extremely fast. This is the backbone of most performant fuzzing, and we’ll need to be able to map in, unmap, and restore pages as they are modified by a fuzz case.

To keep you on the edge of your toes, I’ll first start with the boring things that we have to do.

OS

We have to make an operating system which boots. We’re gonna make a UEFI kernel, and we might dabble in running it on ARM64 as most of our code will be platform agnostic. But, who knows. It’ll be a pretty generic kernel, I’m mainly going to develop it on bare metal, but of course, we’ll make sure it runs on KVM/Xen/Hyper-V such that it can be used in a cloud environment.

ACPI

We’re gonna need to write ACPI table parsers such that we can find the NUMA locality of memory and CPUs on the system. This will be critical to getting a high performance memory manager that scales with cores.

Multi-processing

Of course, the kernel will support multiple cores, as otherwise it’s kinda useless for compute.

10gbit networking + TCP stack

Since I never work with disks, I’m going to follow my standard model of just using the network as general purpose whatever. To do this, we’ll need 10gbit network drivers and a TCP stack such that we can communicate with the rest of a network. Nothing too crazy here, we’ll probably borrow some code from Chocolate Milk

Interesting stuff

Okay, that stuff was boring, lets talk about the fun parts!

Exotic memory model

Since we’ll be “snapshotting” memory itself, we need to make sure things like pointers aren’t a problem. The fastest, easiest, and best solution to this, is simply to make sure the memory always gets loaded at the same address. This is no problem for a single core, but it’s difficult for multiple cores, as they need to have copies of the same data mapped at the same location.

What’s the solution? Well of course, we’ll have every single core on the system running it’s own address space. This means there is no shared memory between cores (with some very, very minor execeptions). Not only does this lead to execeptionally high memory access performance (due to caches only being in the exclusive or shared states), but it also means that shared (mutable) memory will not be a thing! This means that we’ll do all of our core synchronization through message passing, which is higher latency in the best case than shared memory models, but with an advantage of scaling much better. As long as our messages can be serialized to TCP streams, that means we can scale across the network without any effort.

This has some awesome properties since we no longer need any locks to our page tables to add and remove entries, nor do we need to perform any TLB shootdowns, which can cost tens thousands of cycles.

I used this model in Sushi Roll, and I really miss it. It had incredibly good performance properties and forced a bit more thought about sharing information between cores.

Scaling

As with most things I write, linear scaling will be required, and scaling across the network is just implied, as it’s required for really any realistic application of fuzzing.

Fast and differential memory snapshotting

So far, none of these things are super interesting. I’ve had many OSes that do these things well, for fuzzing, for quite a long time. However, I’ve never made these memory management techniques into a true data structure, rather I use them as needed manually. I plan to make the core of this operating system, a combination of Rust procedural macros and virtual memory management tricks to allow for arbitrary data structure to be stored in a tree-shaped checkpointed structure.

This will allow for fast transitions between different state of the structure as they were snapshotted. This will be done by leveraging the dirty bits in the page tables, and creating an allocator that will allocate in a pool of memory which will be saved and restored on snapshots. This memory will be treated as an opaque blob internally, and thus it can hold any information you want, device state, guest memory state, register state, something completely unrelated to fuzzing, won’t matter. To handle nested structures (or more specifically, pointers in structures which are to be tracked), we’ll use a Rust procedural macro to disallow untracked pointers within tracked structures.

Effectively, we’re going to heavily leverage the hardware’s MMU to differentally snapshot, teleport between, and restore blobs of memory. For fuzzing, this is necessary as a way to hold guest memory state and register state. By treating this opaquely, we can focus on doing the MMU aspects really well, and stop worrying about special casing all these variables that need to be restored upon resets.

Linux emulator

Okay, so all of that is kinda to make room for developing high performance fuzzers. In my case, I want this mainly for a new rewrite of vectorized emulation, but to make it interesting for others, we’re going to implement a Linux emulator capable of running QEMU.

This means that we’ll be able to (probably staticially only) compile QEMU. Then we can take this binary, and load it into our OS and run QEMU in our OS. This means we can control the syscall responses to the requests QEMU makes. If we do this deterministically (we will), this means QEMU will be deterministic. Which thus means, the guest inside of QEMU will also be deterministic. You see? This is a technique I’ve used in the past, and works exceptionally well. We’ll definitely outperform Linux’s handling of syscalls, and we’ll scale better, and we’ll blow Linux away when it comes to memory management.

KVM emulator + hypervisor

So, I have no idea how hard this would be, but from about 5 minutes of skimming the interwebs, it seems that I could pretty easily write a hypervisor in my OS that emulates KVM ioctls. Meaning QEMU would just think KVM is there, and use it!

This will give us full control of QEMU’s determinism, syscalls, performance, and reset speeds… without actually having to modify QEMU code.

That’s it

So that’s the plan. An OS + fast MMU code + hypervisor + Linux emulator, to allow us to deterministically run anything QEMU can run, which is effectively everything. We’ll do this with performance likely into the millions of VM resets per second per core, scaling linearly with cores, including over the network, to allow some of the fastest general purpose fuzzing the world has ever seen :D

FAQ

Some people have asked questions on the internet, and I’ll post them here:

Hackernews Q1

Q:

Huh. So my initial response was, "why on earth would you need a whole OS for that", but memory snapshotting and improved virtual memory performance might actually be a good justification. Linux does have CRIU which might be made to work for such a purpose, but I could see a reasonable person preferring to do it from a clean slate. On the other hand, if you need qemu to run applications (which I'm really unclear about; I can't tell if the plan is to run stuff natively on this OS or just to provide enough system to run qemu and then run apps on linux on qemu) then I'm surprised that it's not easier to just make qemu do what you want (again, I'm pretty sure qemu already has its own memory snapshotting features to build on).

Of course, writing an OS can be its own reward, too:) 

A:

Oooh, wasn't really expecting this to make it to HN cause it was meant to be more of an announcement than a description.

But yes, I've done about 7 or 8 operating systems for fuzzing in the past and it's a massive performance (and cleanliness) cleanup. This one is going to be like an operating system I wrote 2-3 years ago for my vectorized emulation work.

To answer your QEMU questions, the goal is to effectively build QEMU with MUSL (just to make it static so I don't need a dynamic loader), and modify MUSL to turn all syscalls to `call` instructions. This means a "syscall" is just a call to another area, which will by my Rust Linux emulator. I'll implement the bare minimum syscalls (and enum variants to those syscalls) to get QEMU to work, nothing more. The goal is not to run Linux applications, but run a QEMU+MUSL combination which may be modified lightly if it means a lower emulation burden (eg. getting rid of threading in QEMU [if possible] so we can avoid fork())

The main point of this isn't performance, it's determinism, but that is a side effect. A normal syscall instruction involves a context switch to the kernel, potentially cr3 swaps depending on CPU mitigation configuration, and the same to return back. This can easily be hundreds of cycles. A `call` instruction to something that handles the syscall is on the order of 1-4 cycles.

While for syscalls this isn't a huge deal, it's even more emphasized when it comes to KVM hypercalls. Transitions to a hypervisor are very expensive, and in this case, the kernel, the hypervisor, and QEMU (eg. device emulation) will all be running at the same privilege level and there won't be a weird QEMU -> OS -> KVM -> other guest OS device -> KVM -> OS -> QEMU transition every device interaction.

But then again, it's mainly for determinism. By emulating Linux deterministically (eg. not providing entropy through times or other syscall returns), we can ensure that QEMU has no source of external entropy, and thus, will always do the same thing. Even if it uses a random-seeded hash table, the seed would be derived from syscalls, and thus, will be the same every time. This determinism means the guest always will do the same thing, to the instruction. Interrupts happen on the same instructions, context switches do, etc. This means any bug, regardless of how complex, will reproduce every time.

All of this syscall emulation + determinism I have also done before, in a tool called tkofuzz that I wrote for Microsoft. That used Linux emulation + Bochs, and it was written in userspace. This has proven incredibly successful and it's what most researchers are using at Microsoft now. That being said, Bochs is about 100x slower than native execution, and now that people have gotten a good hold of snapshot fuzzing (there's a steep learning curve), it's time to get a more performant implementation. With QEMU with get this with a JIT, which at least gets us a 2-5x improvement over Bochs while still "emulating", but even more value could be found if we get the KVM emulation working and can use a hypervisior. That being said, I do plan to support a "mode" where guests which do not touch devices (or more specifically, snapshots which are taken after device I/O has occurred) will be able to run without QEMU at all. We're really only using QEMU for device emulation + interrupt control, thus, if you take a snapshot to a function that just parses everything in one thread, without process IPC or device access (it's rare, when you "read" from a disk, you're likely just hitting OS RAM caches, and thus not devices), we can cut out all the "bloat" of QEMU and run in a very very thin hypervisor instead.

In fuzzing it's critical to have ways to quickly map and unmap memory as most fuzz cases last for hundreds of microseconds. This means after a few hundred microseconds, I want to restore all memory back to the state "before I handled user input" and continue again. This is extremely slow in every conventional operating system, and there's really no way around it. It's of course possible to make a driver or use CRIU, but these are still not exactly the solution that is needed here. I'd rather just make an OS that trivially runs in KVM/Hyper-V/Xen, and thus can run in a VM to get the cross-platform support, rather than writing a driver for every OS I plan to use this on.

Stay cute, ~gamozo 

Social

I’ve been streaming a lot more regularly on my Twitch! I’ve developed hypervisors for fuzzing, mutators, emulators, and just done a lot of fun fuzzing work on stream. Come on by!

Follow me at @gamozolabs on Twitter if you want notifications when new blogs come up. I often will post data and graphs from data as it comes in and I learn!

Part I of II

Situation

In a blog post released 13 Dec 2020, FireEye disclosed that threat actors compromised SolarWinds’s Orion IT monitoring and management software with a trojanized version of SolarWinds.Orion.Core.BusinessLayer.dll. The trojanized file delivers the SUNBURST malware through a backdoor as part of a digitally-signed Windows Installer Patch. Use of a Compromised Software Supply Chain (T1195.002) as an Initial Access technique is particularly critical as it can go undetected for a long period. FireEye released countermeasures that can identify the SUNBURST malware.

If you are using SolarWinds software, please refer to the company’s guidance here to check for vulnerable versions and patch information. McAfee has evaluated the published countermeasures and will continue to analyze further attack indicators. It’s important to note that this was a very sophisticated attack and customers are advised to assess their overall security architecture capability to either prevent, detect or respond to an APT threat. This attack reminds us that in today’s digital enterprise the supply chain includes many diverse elements including but not limited to critical equipment and hardware, cloud software and infrastructure as a service provider and critical IT software. Customers are advised to assess both intellectual property protection and supply chain integrity strategies. Part one of this blog series details initial McAfee defensive guidance and response actions. Part two will describe additional mitigation and solution recommendations.

Protection Summary

For the latest information on McAfee see KB93861and subscribe to receive updates. Below is protection summary to date for the known backdoor indicators

• GTI Cloud and latest DAT has coverage for known indicators and C2 domains for the backdoor
• McAfee Web Gateway can block known C2 domains
• McAfee is continuing to review other detection approaches, including Real Protect and Endpoint Detection and Response
• McAfee Advanced Threat Researchers continue to hunt for new indicators. Intelligence updates will be made available in MVISION Insights
• Signatures are available for Network Security Platform to detect network indicators of compromise

McAfee Labs will continue analysis for any known indicators associated with this attack and update product protection accordingly.  Furthermore, analysis is underway to analyse the behavioural components of the campaign and ensure product efficacy considers protection beyond static measures such as signatures. 

Threat Intelligence Summary

MVISION Insights is tracking the campaign as SolarWinds Supply Chain Attack Affecting Multiple Global Victims with SUNBURST Backdoor.  Customers can view the public version of MVISION Insights for the latest attack details, prevalence, techniques used and indicators of compromise.

Insights provides the indicators used by SUNBURST. The indicators will continue to update based on automated collection and human analysis. You can use the indicators to hunt on your network.  Note: This will be updated as new indicators are verified.

Insights outlines the MITRE Att&ck techniques used by SUNBURST. You can use MITRE Att&ck framework to asses defensive capability across your security architecture.

HUNTING FOR THE BACKDOOR INDICATORS

One of the first initial response actions should be to hunt for known indicators of the attack. You can use MVISION EDR or MAR to search endpoints for SUNBURST backdoor indicators as provided by Microsoft and FireEye. See the search syntax below. If you are licensed for MVISION Insights this query will take place automatically. Additional defensive guidance will be published in an upcoming blog.

Begin MVEDR Query Syntax…

Files name, full_name, md5, sha256, created_at, create_user_name, create_user_domain and HostInfo hostname, ip_address, os and LoggedInUsers username, userdomain where Files sha256 equals “ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c” or Files sha256 equals “c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77” or Files sha256 equals “eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed” or Files sha256 equals “dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b” or Files sha256 equals “32519685c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77” or Files sha256 equals “d0d626deb3f9484e649294a8dfa814c5568f846d5aa02d4cdad5d041a29d5600” or Files sha256 equals “53f8dfc65169ccda021b72a62e0c22a4db7c4077f002fa742717d41b3c40f2c7” or Files sha256 equals “019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134” or Files sha256 equals “ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6” or Files sha256 equals “32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77” or Files sha256 equals “292327e5c94afa352cc5a02ca273df543f2020d0e76368ff96c84f4e90778712” or Files sha256 equals “c15abaf51e78ca56c0376522d699c978217bf041a3bd3c71d09193efa5717c71”

…End MVEDR Query Syntax

You should also search McAfee Web Gateway logs (or other network and SIEM logs) for communication to command and control domains or IP addresses, particularly those categorized as “Malicious Sites” below. Continue to check MVISION Insights for new domains and URLs.

What’s Next

It’s important to note that ongoing analysis will be critical to understand how the attackers will adapt and what additional mitigation is required. This will be a continuous process and we expect to add multiple updates to KB93861. Additionally, customers should follow McAfee Labs posts, check Insights Public Dashboard for latest threat intelligence, and continually check the Knowledge Center for latest product guidance. Part two of this blog will cover defensive capabilities and controls in more depth.

Additional McAfee Threat Intel Resources

Insights Trending Campaigns

Every week Insights Preview highlights the top emerging threats and campaigns based on ATR Operational Intelligence collection and analysis.

Atlas Dashboard

Follow the latest COVID Threat statistics on the public Atlas Dashboard.  For more information about how a customer can utilize Atlas and Intelligence as a Service from APG, speak to your McAfee Account Manager for a Threat Intel Briefing and Workshop.

Threat Research

McAfee Labs and Advanced Threat Research teams produce regular research reports with the latest threat intelligence statistics and trends. Please share the reports with customers.

McAfee Threat Intelligence Blogs

Review and Share our external blogs that feature deeper malware analysis and explanations on emerging threats and attack campaigns.

The post SUNBURST Malware and SolarWinds Supply Chain Compromise appeared first on McAfee Blog.

Executive Summary

There has been considerable focus on the recent disclosures associated with SolarWinds, and while existing analysis on the broader campaign has resulted in detection against specific IoCs associated with the Sunburst trojan, the focus within the Advanced Threat Research (ATR) team has been to determine the possibility of additional persistence measures. Our analysis into the backdoor reveals that the level of access lends itself to the assumption that additional persistence mechanisms could have been established and some inferences regarding the intent from adversaries;

• An interesting observation was the check for the presence of SolarWinds’ Improvement Client executable and it’s version “3.0.0.382”. The ImprovementClient is a program that can collect considerable information such as count of Orion user accounts by authentication method and data about devices and applications monitored.
• Observation of the http routine was the search for certain keywords in the http-traffic that might indicate the adversary was looking into details/access of Cloud and/or wireless networks of their victims.
• Even if a victim is using a Proxy-server with username and password, the backdoor is capable of retrieving that information and using it to build up the connection towards the C2.

Available Resources

Although this analysis will focus on the premise that the backdoor supports the feasibility of establishing additional persistence methods we recognize the importance of providing assurance regarding coverage against available indicators. To that end the following resources are available:

• KB93861: McAfee coverage for SolarWinds Sunburst Backdoor:
  https://kc.mcafee.com/corporate/index?page=content&id=KB93861 
• SUNBURST Malware and SolarWinds Supply Chain Compromise : Detailing the protection summary, but also how to use MVISION EDR or MAR to search for SUNBURST: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/sunburst-malware-and-solarwinds-supply-chain-compromise/  
• MVISION Insights Campaign: SolarWinds Supply Chain Attack Affecting Multiple Global Victims With SUNBURST Backdoor. This resource provides up to date tracking on the prevalence of available indicators based on geography and sector of potential targets: https://www.mcafee.com/enterprise/en-us/lp/insights-preview.html# 

Additional resources will become available as analysis both conducted by McAfee researchers, and the wider community becomes available.

Backdoor Analysis

There exists excellent analysis from many of our industry peers into the SUNBURST trojan, and the intention here is not to duplicate findings but to provide analysis we have not seen previously covered. The purpose is to enable potential victims to better understand the capabilities of the campaign in an effort to consider the possibility that there are additional persistence mechanisms.

For the purposes of this analysis our focus centered upon the file “SolarWinds.Orion.Core.BusinessLayer.dll“, this particular file, as the name suggests, is associated with the SolarWinds ORION software suite and was modified with a class added containing the backdoor “SunBurst”.

A deeper dive into the backdoor reveals that the initial call is to the added class “OrionImprovementBusinessLayer” which has the following functions:

The class starts with a check to see if the module is running and, if not, it will start the service and thereafter initiate a period of dormancy.

As was detailed by FireEye, this period of sleep can range from minutes up to two weeks. The actual time period of dormancy is dependent on the checks that must be passed from the code, like hash of the Orion process, write-times of files, process running etc. A sleep period of this length of time is unusual and speaks to a very patient adversary.

The most important strings inside the backdoors are encoded with the DeflateStream Class of the .NET’s Compression library together with the base64 encoder. By examining the block-list, we discover findings that warrant further inspection. First entries are the local-IP address ranges and netmasks:

• 10.0.0.0 255.0.0.0
• 172.16.0.0 255.240.0.0
• 192.168.0.0 255.255.0.0

Followed by the IPv6 local addresses equivalents:
fc00::,fe00::, fec0::,ffc0::,ff00::,ff00::

Next, there is a list of IP-addresses and their associated subnetmasks. We executed a whois on those IP-addressees to get an idea of whom they might belong to. There is no indication as to the reason that the following IPs have been inserted into the blocklist, although the netmasks implemented in certain entries are ‘quite’ specific, therefore we have to assume the attackers were intentional in their desire to avoid certain targets.

Assuming that the victim is not within the block list, the sample will then proceed to create the named pipe 583da945-62af-10e8-4902-a8f205c72b2e. This is done to ensure that only one instance of the backdoor is running. We were able to verify this through replication we carried out within our own environment.

When we ran the backdoor, we were able to confirm that this value is hardcoded in the code, and once the dormancy period passed the service is started and named pipe is created. At this point, the backdoor will also create a unique UserID MD5 value for the system it is installed on as depicted within figure 5.

This particular routine will initially read the Device-info of the system but ignore the loopback interfaces (part of the code of the ReadDeviceInfo routine that mentions “Select * From Win32_NetworkAdapterConfiguration where IPEnabled=true” ). The Device-info will then be combined with the domain name, followed by a value from the registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography). This information is then used to create an MD5 value of that string.

The module will start the ‘update’ routine. This routine is a continuous loop designed for verification against, for example, unwanted services that could potentially be used against detection of the backdoor as depicted in figure 6.

Information Gathering

The backdoor gathers information from the system. The following information is gathered by a routine called “CollectSystemDescription”, some examples include;

• OS version, major /minor – is it 32 or 64 bits
• Network configs, info on IP, NetBIOS, IPV6 etc.
• Host, SID & Username & System directory. In particular the SID for the Administrator account is searched for.

There exists other subroutines to collect additional data, for example enumerating the information from the network-adaptors, the backdoor uses the GetNetworkAdapterConfiguration routine. The routine is gathering the following information:

In order to check if certain ‘unwanted’ services are running, the backdoor enumerates the services, creates a hashlist and compares them with a hard-coded set of these values. The ‘update’ routine will exit once a ‘block-listed’ process id discovered. The backdoor will attempt to stop these services by entering a value in the registry for that service that will disable that service. The update routine will check again and continue this process until all unwanted processes are disabled.
Another capability of the backdoor is to start/stop tasks:

Other functionalities we observed in the code are:

• SetTime
• CollectSystemDescription
• UploadSystemDescription
• GetProcessByDescription
• GetFileSystemEntries
• WriteFile
• FileExists
• DeleteFile
• GetFileHash
• ReadRegistryValue
• SetRegistryValue
• DeleteRegistryValue
• GetRegistrySubKeyAndValueNames
• Reboot

An interesting observation was the check for the presence of SolarWinds’ Improvement Client executable and it’s version “3.0.0.382”.

The ImprovementClient is a program that can collect the following information (source SolarWinds) :

• The SWID (SolarWinds ID) associated with any SolarWinds commercial licenses installed
• The email address provided to the installer during installation
• Unique identifier of the downloaded installer
• Versions of all Orion products installed
• Operating system version
• CPU description and count
• Physical memory installed and percent used
• Time zone
• Dates when you logged in to the Orion website
• Licensing information of other SolarWinds Orion products locally installed
• Row counts for database tables
• Count of monitored nodes by polling protocol
• Count of Orion user accounts by authentication method
• Network discovery scheduling information (not results)
• Data about devices and applications monitored:
  • Vendor
  • Model
  • OS/Firmware version
  • Count
  • Abstract configuration information, such as number of websites hosted
• Data about the SolarWinds product:
  • Feature usage statistics
  • Performance statistics
  • Hardware and OS platform description

Another observation of the http routine was the search for certain keywords in the http-traffic that might indicate the adversary was looking into details/access of cloud and/or wireless networks of their victims by using the SolarWinds’ modules that are installed to monitor/administer these kinds of instances. Managing the network using SolarWinds’ Orion is executed by using a browser and localhost that is hosting the webserver. Reading out the certificate values and search for these keywords in the http-traffic would have gained this information.

Network / DGA

After all checks and routines have passed, the backdoor will use a domain generating algorithm (hereafter DGA) to generate a domain. Example of the part of the DGA code:

When the domain is successfully reached, the routine called ‘Update’ contains a part that will act on this and start a new thread firing off the routine “HttpHelper.Initialize”. In the below screenshot we can observe that flow:

The code shows that when the dnsrecord equals the domain and can be reached, the new thread will start in the background.

The ‘HttpHelper’ class/routine is responsible for all the C2 communications:

Even if a victim is using a Proxy-server with username and password, the backdoor is capable of retrieving that information and using it to build up the connection towards the C2. It then uses a routine called “IWebProxy GetWebProxy” for that:

The DGA-generated C2s are subdomains of: avsvmcloud[.]com.
An example of how these domains would look:

• 02m6hcopd17p6h450gt3.appsync-api.us-west-2.avsvmcloud.com
• 039n5tnndkhrfn5cun0y0sz02hij0b12.appsync-api.us-west-2.avsvmcloud.com
• 043o9vacvthf0v95t81l.appsync-api.us-east-2.avsvmcloud.com
• 04jrge684mgk4eq8m8adfg7.appsync-api.us-east-2.avsvmcloud.com
• 04r0rndp6aom5fq5g6p1.appsync-api.us-west-2.avsvmcloud.com
• 04spiistorug1jq5o6o0.appsync-api.us-west-2.avsvmcloud.com

Inspecting the CNAME’s from the DGA-generated C2’s we observed the following domain-names:

• freescanonline[.]com
• deftsecurity[.]com
• thedoccloud[.]com
• websitetheme[.]com
• highdatabase[.]com
• incomeupdate[.]com
• databasegalore[.]com
• panhardware[.]com
• Zupertech[.]com
• Virtualdataserver[.]com
• digitalcollege[.]org

In the forementioned HTTP handler code, we discovered paths that might be installed on the C2’s for different functions:

• swip/upd/
• swip/Events
• swip/Upload.ashx

Once the backdoor is connected, depending on the objectives from the adversaries, multiple actions can be executed including the usage of multiple payloads that can be injected into memory. At the time of writing, details regarding the ‘killswitch’ against the above domain will prevent this particular backdoor from being operational, however for the purpose of this analysis it demonstrates the level of access afforded to attackers. While the efforts to sinkhole the domain are to be applauded, organisations that have been able to identify indicators of SUNBURST within their environment are strongly encouraged to carry out additional measures to provide themselves assurances that further persistent mechanisms have not been deployed.

The post Additional Analysis into the SUNBURST Backdoor appeared first on McAfee Blog.

ZecOps is proud to share that we detected multiple exploits by the threat actors that recently targeted Aljazeera’s journalists before it was made public. The attack detection was automatically detected using ZecOps Mobile DFIR.

In this blog post, we’ll share our analysis of the post-exploitation kernel panics observed on one of the targeted devices.

Key details on the attacks targeting journalists in Middle East:

• First known attack: earliest signs of compromise on January 17th, 2020.
• Was the attack successful: Yes – the device shows signs for successfully planted malware / rootkit.
• Persistence: The device shows signs for a persistent malware that is capable of surviving reboots. It is unclear if the device was re-infected following an OS update, or that the malware also persisted between OS updates.
• Attack Impact: The threat-operators were able to continuously access the device microphone, camera, and data including texts, and emails for the entire period.
• Attribution: We named this threat actor Desert Cobra. We do not rule out that NSO (aka “NSO Group”) was involved in the other reporters’ cases that was published today by Citizen Labs. We refrain from naming the particular threat actor that targeted one of the victims in Citizen-Labs report, NSO, due to some activities that do not add-up with our Mobile Threat Intelligence on NSO. We also do not rule out that this device was potentially compromised by more than one threat actor simultaneously.
• OS Update? We do recommend updating to the latest iOS version, however we have no evidence that this actually fixes any of the vulnerabilities that were exploited by this threat operator(s).

Post-exploitation Panic Analysis

A tale of two panics: MobileMail and mediaanalysisd: kauth_cred_t corruption

The following stack backtrace of the MobileMail panic indicates that the panic happened on function kauth_cred_unref:

panic(cpu 2 caller 0xfffffff02a2f47f0): "kfree: size 8589934796 > kalloc_largest_allocated 21938176"
_func_fffffff007b747f0 + 0 ~ (kfree + 340)
sfree() + 28
_func_fffffff008debd5c + 68 ~ (_mpo_cred_check_label_update + 2904)
_func_fffffff008df5f48 + 92 ~ (_sandbox_hook_policy_syscall + 6488)
_func_fffffff008df5d8c + 300 ~ (_sandbox_hook_policy_syscall + 6252)
_func_fffffff008de309c + 64 ~ (_check_boolean_entitlement + 1716)
_func_fffffff0081538e8 + 76 ~ (audit_session_unref)
_func_fffffff007f3f790 + 200 ~ (kauth_cred_unref)
...
 _vn_open_auth + 1612
 _open1 + 256
 _open + 528

kauth_cred_unref frees credential structures from the kernel. The following is the stack backtrace of the mediaanalysisd panic, it also panicked on function “kauth_cred_unref”:

_func_fffffff008db5d4c + 260 ~ (_sandbox_hook_policy_syscall + 6212)         
       0xfffffff010795e50  ldr x8, [x21]                  
       0xfffffff010795e54  str x8, [x19, x22, lsl #3]     
       0xfffffff010795e58  b 0x01db5e78    // 0xfffffff01254bcd0 
       0xfffffff010795e5c  ldr x9, [x8] 
 _func_fffffff008da305c + 64 ~ (_check_boolean_entitlement + 1716)
 _func_fffffff00814783c + 76 ~ (audit_session_unref)
 _func_fffffff007f336f4 + 200 ~ (kauth_cred_unref)
...
_func_fffffff007cebec8 + 444 ~ (_copyin + 4560)
_copyin + 2224

Function “kauth_cred_free” calls by “kauth_cred_unref”, code as follows:

static void kauth_cred_free(kauth_cred_t cred)
{
assert(os_atomic_load(&cred->cr_ref, relaxed) == 0);
#if CONFIG_MACF
mac_cred_label_destroy(cred);
#endif
AUDIT_SESSION_UNREF(cred); // ← call kfree, panic inside
FREE_ZONE(cred, sizeof(*cred), M_CRED);
}

Both of the panics happened inside “AUDIT_SESSION_UNREF”, which means the credential structure of the processes was corrupted.

A classic way to gain root access for a kernel exploit is to replace the credential structure of an attacker controlled process with the kernel credentials. Please note that it doesn’t necessarily mean MobileMail or mediaanalysisd was controlled, the corruption of the credential structures could have also happened due to wrong offsets during exploitation.

ZecOps customers: no further action is required. The deployed systems detect these activities. The complete report and full IOC list is available in ZecOps Threat Intelligence feed.

Hear the news first

• Only essential content
• New vulnerabilities & announcements
• News from ZecOps Research Team

Keep Me Updated

Your subscription request to ZecOps Blog has been successfully sent.

We won’t spam, pinky swear

Follow @ZecOps