This weekend, the Guardian released a groundbreaking report that authoritarian governments have breached the mobile devices of human rights activists, journalists, and lawyers across the world, using a hacking software sold by NSO Group.

While the Guardian report contained new information regarding the targets of NSO customers and the Pegasus spyware, the specific mobile vulnerabilities that NSO leveraged were not identified and remain unpatched. This means that despite the public attribution, NSO tools remain just as powerful today as they were prior to the report.

Fight Back with ZecOps!

ZecOps suspects that NSO will quickly alter its methods so that the specific IOCs, or indicators of compromise, will be difficult to identify by mobile security researchers. However, with our Mobile EDR product, we can help your organization identify NSO attacks automatically by focusing on the behavior that remains present in the logs in addition to the publically known IOCs.

Note: ZecOps does not collect or access your personal information. ZecOps will only collect information required for mobile security investigations, leaving personal information out.

In 2021 ransomware attacks have been dominant among the bigger cyber security stories. Hence, I was not surprised to see that McAfee’s June 2021 Threat report is primarily focused on this topic.

This report provides a large range of statistics using the McAfee data lake behind MVISION Insights, including the Top MITRE ATT&CK Techniques. In this report I highlight the following MITRE techniques:

1. Spear phishing links (Initial Access)
2. Exploit public-facing applications (Initial Access)
3. Windows Command Shell (Execution)
4. User execution (Execution)
5. Process Injection (Privilege escalation)
6. Credentials from Web Browsers (Credential Access)
7. Exfiltration to Cloud Storage (Exfiltration)

I also want to highlight one obvious technique which remains common across all ransomware attacks at the end of the attack lifecycle:

8. Data encrypted for impact (Impact)

Traditional defences based on anti-malware signatures and web protection against known malicious domains and IP addresses can be insufficient to protect against these techniques. Therefore, for the rest of this article, I want to cover a few recent McAfee innovations which can make a big difference in the fight against ransomware.

Unified Cloud Edge with Remote Browser Isolation

The following three ransomware techniques are linked to web access:

• Spear phishing links
• User execution
• Exfiltration to Cloud Storage

Moreover, most ransomware attacks require some form of access to a command-and-control server to be fully operational.

McAfee Remote Browser Isolation (RBI) ensures no malicious web content ever even reaches enterprise endpoints’ web browsers by isolating all browsing activity to unknown and risky websites into a remote virtual environment. With spear phishing links, RBI works best when running the mail client in the web browser. The user systems cannot be compromised if web code or files cannot run on them, making RBI the most powerful form of web threat protection available. RBI is included in most McAfee United Cloud Edge (UCE) licenses at no additional cost.

Figure 1. Concept of Remote Browser Isolation

McAfee Client Proxy (MCP) controls all web traffic, including ransomware web traffic initiated without a web browser by tools like MEGAsync and Rclone. MCP is part of McAfee United Cloud Edge (UCE).

Protection Against Fileless Attacks

The following ransomware techniques are linked to fileless attacks:

• Windows Command Shell (Execution)
• Process Injection (Privilege escalation)
• User Execution (Execution)

Many ransomware attacks also use PowerShell.

Figure 2. Example of an attack kill chain with fileless

McAfee provides a large range of technologies which protect against fileless attack methods, including McAfee ENS (Endpoint Security) Exploit prevention and McAfee ENS 10.7 Adaptive Threat Protection (ATP). Here are few examples of Exploit Prevention and ATP rules:

• Exploit 6113-6114-6115-6121 Fileless threat: self-injection
• Exploit 6116-6117-6122: Mimikatz suspicious activity
• ATP 316: Prevent PDF readers from starting cmd.exe
• ATP 502: Prevent new services from being created via sc.exe or powershell.exe

Regarding the use on Mimikatz in the example above, the new McAfee ENS 10.7 ATP Credential Theft Protection is designed to cease attacks against Windows LSASS so that you do not need to rely on the detection of Mimikatz.

Figure 3. Example of Exploit Prevention rules related to Mimikatz

ENS 10.7 ATP is now included in most McAfee Endpoint Security licenses at no additional cost.

Proactive Monitoring and Hunting with MVISION EDR

To prevent initial access, you also need to reduce the risks linked to the following technique:

• Exploit public facing applications (Initial Access)

For example, RDP (Windows Remote Desktop Protocol) is a common initial access used by ransomware attacks. You may have a policy that already prohibits or restricts RDP but how do you know it is enforced on every endpoint?

With MVISION EDR (Endpoint Detection and Response) you can perform a real time search across all managed systems to see what is happening right now.

Figure 4. MVISION EDR Real-time Search to verify if RDP is enabled or disabled on a system

Figure 5. MVISION EDR Real-time Search to identify systems with active connections on RDP

MVISION EDR maintains a history of network connections inbound and outbound from the client. Performing an historical search for network traffic could identify systems that actively communicated on port 3389 to unauthorized addresses, potentially detecting attempts at exploitation.

MVISION EDR also enables proactive monitoring by a security analyst. The Monitoring Dashboard helps the analyst in the SOC quickly triage suspicious behavior.

For more EDR use cases related to ransomware see this blog article.

Actionable Threat Intelligence

With MVISION Insights you do not need to wait for the latest McAfee Threat Report to be informed on the latest ransomware campaigns and threat profiles. With MVISION Insights you can easily meet the following use cases:

• Proactively assess your organization’s exposure to ransomware and prescribe how to reduce the attack surface:
  • Detect whether you have been hit by a known ransomware campaign
  • Run a Cyber Threat Intelligence program despite a lack of time and expertise
  • Prioritize threat hunting using the most relevant indicators

These use cases are covered in the webinar How to fight Ransomware with the latest McAfee innovations.

Regarding the following technique from the McAfee June 2021 Threat Report:

Credentials from Web Browsers (Credential Access)

MVISION Insights can display the detections in your environment as well as prevalence statistics.

Figure 6. Prevalence statistics from MVISION Insights on the LAZAGNE tool

MVISION Insights is included in several Endpoint Security licenses.

Rollback of Ransomware Encryption

Now we are left with the last technique in the attack lifecycle:

• Data encrypted for impact (Impact)

McAfee ENS 10.7 Adaptive Threat Protection (ATP) provides dynamic application containment of suspicious processes and enhanced remediation with an automatic rollback of the ransomware encryption.

Figure 7. Configuration of Rollback remediation in ENS 10.7

You can see how files impacted by ransomware can be restored through Enhanced Remediation in this video. For more best practices on tuning Dynamic Application Containment rules, check the knowledge base article here.

Additional McAfee Protection Against Ransomware

Last year McAfee released this blog article covering additional capabilities from McAfee Endpoint Security (ENS), Endpoint Detection and Response (EDR) and the Management Console (ePO) against ransomware including:

• ENS Exploit prevention
• ENS Firewall
• ENS Web control
• ENS Self protection
• ENS Story Graph
• ePO Protection workspace
• Additional EDR use cases against ransomware

Summary

To increase your protection against ransomware you might already be entitled to:

• ENS 10.7 Adaptive Threat Protection
• Unified Cloud Edge with Remote Browser Isolation and McAfee Client Proxy
• MVISION Insights
• MVISION EDR

If you are, you should start using them as soon as possible, and if you are not, contact us.

The post Fighting new Ransomware Techniques with McAfee’s Latest Innovations appeared first on McAfee Blog.

The overarching threat facing cyber organizations today is a highly skilled asymmetric enemy, well-funded and resolute in his task and purpose.   You never can exactly tell how they will come at you, but come they will.  It’s no different than fighting a kinetic foe in that, before you fight, you must choose your ground and study your enemy’s tendencies.

A lot of focus has been placed on tools and updating technology, but often we are pushed back on our heels and find ourselves fighting a defensive action.

But what if we change?  How do we do that?

The first step is to study the battlefield, understand what you’re trying to protect and lay down your protection strategy.  Pretty basic right??

Your technology strategy is very important, but you must embrace and create a thorough Cyber Threat Intelligence (CTI) doctrine which must take on many forms.

First, there is data, and lots of it.  However, the data must take specific forms to research and detect nascent elements where the adversary is attempting to catch you napping or give you the perception that the activity you see is normal.

As you pool this data, it must be segmented into layers and literally mapped to geographic locations across the globe.  The data is classified distinctly as malicious and reputations are applied.  This is a vital step in that it enables analytical programs, along with human intelligence analysts to apply the data within intelligence reports which themselves can take on many forms.

Once the data takes an analytic form, then it allows organizations to forensically piece together a picture of an attack.  This process is painstakingly tedious but necessary to understand your enemy and his tendencies.  Tools are useful, but it’s always the human in the loop that will recognize the tactical and strategic implications of an adversary’s moves. Once you see the picture, it becomes real, and then you’re able to prepare your enterprise for the conflict that follows.

Your early warning and sensing strategy must incorporate this philosophy.  You must sense, collect, exploit, process, produce and utilize each intelligence product that renders useful information.  It’s this process that will enable any organization to move decisively to and stay “left of boom”.

The McAfee Advanced Programs Group (APG) was created eight years ago to support intelligence organizations that embrace and maintain a strong CTI stance.  Its philosophy is to blend people, processes, data and a strong intelligence heritage to enable our customers to understand the cyber battlefield to proactively protect, but “maneuver” when necessary to avoid an attack.

APG applies three key disciplines or mission areas to provide this support.

First, we developed an internal tool called the Advanced Threat Landscape Analysis System (ATLAS).  This enables our organization to apply our malicious threat detections to a geospatial map display to see where we’re seeing malicious data.  ATLAS draws from our global network of billions of threat sensors to see trillions of detections each day, but enables our analysts to concentrate on the most malicious activity.  Then we’re better able to research and report accurate threat landscape information.

The second leg in the stool is our analytical staff, the true cyber ninjas that apply decades of experience supporting HUMINT operations across the globe and a well-established intelligence-based targeting philosophy to the cyber environment.  The result is a true understanding of the cyber battlefield enabling the leadership to make solid “intelligence-based” decisions.

Finally, the third leg is our ability to develop custom solutions and interfaces to adapt in a very custom way our ability to see and study data.  We have the ability to leverage 2.8 billion malicious detections, along with 20 other distinct malicious feeds, to correlate many different views, just not the McAfee view.  We interpret agnostically.

These three legs provide APG a powerful CTI advantage allowing our customers to adapt and respond to events by producing threat intelligence dynamically. When using this service it allows the customer to be fully situationally aware in a moments notice (visual command and control). Access to the data alone is an immense asset to any organization.  This allows each customer not only to know what their telemetry is, but also provides real time insights into the entire world ecosystem. Finally, the human analysis alone is immensely valuable.  It allows for the organizations to read and see/understand what it all means (the who, what, where and why).   “The so what!!”

The post An Overall Philosophy on the Use of Critical Threat Intelligence appeared first on McAfee Blog.

We previously published that we suspected that there were more than one threat actor targeting the Al-Jazeera journalists.

Background

ZecOps discovered NSO attacks that targeted Al-Jazeera automatically using ZecOps Mobile EDR & DFIR solutions. Our initial analysis suggested that the footprint does not belong only to NSO.

ZecOps Mobile Threat Intelligence Brief

ZecOps can now confirm, with high-confidence, that the attacks targeting journalists in Middle East were caused by at least two commercial threat actors working together, and the attack launched by a nation-state that purchased NSO’s exploit-platform. 

This may sound like a minor detail, but every detail in attribution is crucial.

In the last transparency report by NSO, they published that they limit the usage.

This can be translated into “We have a license based attack-as-a-service model. We only sell a certain amount of attack licenses to a certain buyer.”. While this intelligence is not fully confirmed, and should be taken with a grain of salt, our intelligence also suggests that “Desert Cobra” (state actor) purchased an ‘unlimited number of licenses’ package to carry out attacks using NSO’s software.

NSO acquired exploits from another supplier and leveraged the borrowed exploit in the attack launched by the end-buyer (Desert Cobrat) against Al-Jazeera journalists. It is unclear if the  end-customer, a government, was aware that parts of the exploit chain were obtained from another threat-actor and sold as a package.

Bottom line

As threat actors working together, defenders should be working together too. We hope that the vendors reading this will enable SOCs around the world with better access in-order to find and capture payloads by threat actors like NSO, that will always find a way, or as we can see in this post “buy their way”, to bypass all the existing mitigations and security controls.

ZecOps Mobile EDR Customers: no further action is required. ZecOps discovered the Al-Jazeera attack, and other NSO related incidents automatically. The deployed systems detect these activities. The complete report and full IOC list is available in ZecOps Mobile Threat Intelligence feed.

Al Jazeera NSO Attack IOCs:

• /private/var/tmp/uevkjdwxijvah/c
• /private/var/db/com.apple.xpc.roleaccountd.staging/launchafd
• /private/var/db/com.apple.xpc.roleaccountd.staging/rs
• /private/var/db/com.apple.xpc.roleaccountd.staging/natgd

Unfortunately, due to iOS sandbox restrictions, it is not trivial to check for these IOCs. If you would like to check your phone for these IOCs, other attacks by NSO, or other threat actors, please feel free to contact us here.

Free Mobile Inspection

To help discover these attacks, for a limited time, ZecOps is offering free mobile inspections to businesses that were targeted in the NSO leak. For your instant inspection, fill out the form below.

The TL;DR Version:

ZecOps Mobile EDR Research team investigated if the recently announced WiFi format-string bug in wifid was exploited in the wild. 

This research led us to interesting discoveries:

• Recently a silently patched 0-click WiFi proximity vulnerability on iOS 14 – iOS 14.4 without any assigned CVE
• That the publicly announced WiFi Denial of Service (DoS) bug, which is currently a 0day, is more than just a DoS and actually a RCE!
• Analysis if any of the two bugs were exploited across our cloud user-base.

Introduction

There’s a new WiFi vulnerability in-town. You probably already saw it, but didn’t realize the implication. The recently disclosed ‘non-dangerous’ WiFi bug – is potent.

This vulnerability allows an attacker to infect a phone/tablet without *any* interaction with an attacker. This type of attack is known as “0-click” (or “zero-click”). The vulnerability was only partially patched.

1. Prerequisites to the WiFiDemon 0-Click Attack:

• Requires the WiFi to be open with Auto-Join (enabled by default)
• Vulnerable iOS Version for 0-click: Since iOS 14.0
• The 0-Click vulnerability was patched on iOS 14.4

Solutions:

• Update to the latest version, 14.6 at the time of writing to avoid risk of WiFiDemon in its 0-click form. 
• Consider disabling WiFi Auto-Join Feature via Settings->WiFi->Auto-Join Hotspot->Never.
• Perform risk and compromise assessment to your mobile/tablet security using ZecOps Mobile EDR in case you suspect that you were targeted.

2. Prerequisites to the WiFi 0Day Format Strings Attack:

Unlike initial research publications, at the time of writing, the WiFi Format Strings seem to be a Remote Code Execution (RCE) when joining a malicious SSID. 

Solutions:

• Do not join unknown WiFis.
• Consider disabling WiFi Auto-Join Feature via Settings->WiFi->Auto-Join Hotspot->Never.
• Perform risk and compromise assessment to your mobile/tablet security using ZecOps Mobile EDR in case you suspect that you were targeted.
• This vulnerability is still a 0day at the time of writing, July 4th. iOS 14.6 is VULNERABLE when connecting to a specially crafted SSID. 
• Wait for an official update by Apple and apply it as soon as possible.

Wi-Fi-Demon ?

wifid is a system daemon that handles protocol associated with WIFI connection. Wifid runs as root. Most of the handling functions are defined in the CoreWiFi framework, and these services are not accessible from within the sandbox. wifid is a sensitive daemon that may lead to whole system compromise.

Lately, researcher Carl Schou (@vm_call) discovered that wifid has a format string problem when handling SSID.

https://www.forbes.com/sites/kateoflahertyuk/2021/06/20/new-iphone-bug-breaks-your-wifi-heres-the-fix

The original tweet suggests that this wifid bug could permanently disable iPhone’s WiFi functionality, as well as the Hotspot feature. This “WiFi” Denial of Service (DoS) is happening since wifid writes known wifi SSID into the following three files on the disk:

• /var/preferences/com.apple.wifi.known-networks.plist
• /var/preferences/SystemConfiguration/com.apple.wifi-networks.plist.backup
• /var/preferences/SystemConfiguration/com.apple.wifi-private-mac-networks.plist

Every time that wifid respawns, it reads the bad SSID from a file and crashes again. Even a reboot cannot fix this issue.

However, this bug can be “fixed” by taking the following steps according to Forbes:

“The fix is simple: Simply reset your network settings by going to Settings > General > Reset > Reset Network Settings.”

This bug currently affects the latest iOS 14.6, and Apple has not yet released any fixes for this bug.

Further Analysis Claims: This is Only a Denial of Service

Followed by another researcher Zhi @CodeColorist published a quick analysis.

https://blog.chichou.me/2021/06/20/quick-analysis-wifid/

His conclusion was:

“For the exploitability, it doesn’t echo and the rest of the parameters don’t seem like to be controllable. Thus I don’t think this case is exploitable.

After all, to trigger this bug, you need to connect to that WiFi, where the SSID is visible to the victim. A phishing Wi-Fi portal page might as well be more effective.”

The Plot Thickens

We checked ZecOps Mobile Threat Intelligence to see if this bug was exploited in the past. We noticed that two of our EMEA users had an event related to this bug. Noteworthy, we only have access to our cloud data, and couldn’t check other on-premises clients – so we might be missing other events.

We asked ourselves: 

1. Why would a person aware of dangerous threats connect to a network with such an odd name “%s%s…”. – Unlikely.
2. Why would an attacker bring a tactical team to target a VIP, only to cause DoS – It still does not make sense.

Remotely exploitable, 0-click, under the hood!

Further analysis revealed that:

1. Attackers did not need to force the user to connect. This vulnerability could be launched as a 0click, without any user interaction. A victim only needed to have your WiFi turned on to trigger the vulnerable code.
2. This is not a DoS, but an actual RCE vulnerability for both the recently patched 0-click format-strings vulnerability, and the malicious SSID format-strings 0-day vulnerability.

This 0-click bug was patched on iOS 14.4 and credits “an anonymous researcher” for assisting. Although this is a potent 0-click bug, a CVE was not assigned.

Technical Details: Analysis of a Zero-Click WiFi Vulnerability – WiFiDemon

Let’s do a deeper dive into the technical details behind this vulnerability:

Considering the possible impact of triggering this vulnerability as a 0-click, as well as the potential RCE implications, we investigated the wifid vulnerability in depth.

When we tested this format-strings bug on an older version, similar to our clients, we noticed that wifid has intriguing logs when it is not connected to any wifi.

These logs contain SSID, which indicates that it may be affected by the same format string bug. 

We tested it and Voilà, it is affected by the same format string bug – meaning that this is a zero-click vulnerability and can be triggered without an end-user connecting to a strange named wifi.

This log is related to a common smart device behavior: Automatically scan and join known networks.

Zero-Click – Even When The Screen is Off

The iPhone scans WiFi to join every ~3 seconds while the user is actively using the phone. Furthermore, even if the user’s phone screen has been turned off, it still scans for WiFi but at a relatively lower frequency. The waiting time for the following scan will be longer and longer, from ~10 seconds to 1+ minute. 

As long as the WiFi is turned on this vulnerability can be triggered. If the user is connected to an existing WiFi network, an attacker can launch another attack to disconnect/de-associate the device and then launch this 0-click attack. Disconnecting a device from a WiFi is well-documented and we’ll not cover it as part of the scope for this blog.

This 0-click vulnerability is powerful: if the malicious access point has password protection and the user never joins the wifi, nothing will be saved to the disk. After turning off the malicious access point, the user’s WIFI function will be normal. A user could hardly notice if they have been attacked.

Exploiting this Vulnerability

We further analyzed whether this vulnerability can be exploited, and how:

This post assumes that the reader is aware of the concept of format-string bugs and how to exploit them. However, this bug is slightly different from the “traditional” printf format string bugs because it uses [NSString stringWithFormat:] which was implemented by Apple, and Apple removed the support for %n for security reasons. That’s how an attacker would have been able to write to the memory in an exploitation of a traditional format string bug.

Where You AT? – %@ Is Handy!

Since we cannot use %n, we looked for another way to exploit this 0-click N-Day, as well as the 1-click 0-day wifid bug. Another possible use is %@, which is uniquely used by Objective-C.

Since the SSID length is limited to 32 bytes, we can only put up to 16 Escape characters in a single SSID. Then the Escape characters we placed will process the corresponding data on the stack.

A potential exploit opportunity is if we can find an object that has been released on the stack, in that case, we can find a spray method to control the content of that memory and then use %@ to treat it as an Objective-C object, like a typical Use-After-Free that could lead to code execution.

Step 1: Find Possible Spraying Opportunities on the Stack

First, we need to design an automatic method to detect whether it is possible to tweak the data on the stack. lldb breakpoint handling script perfectly fits that purpose. Set a breakpoint right before the format string bug and link to a lldb script that will automatically scan and observe changes in the stack.

Step 2: Find an Efficient Spraying Method

Then we need a spray method that can interfere with wifid’s memory over the air. 

An interesting strategy is called Beacon Flooding Attack. It broadcasts countless Beacon frames and results in many access points appearing on the victim’s device.

To perform a beacon flooding attack, you need a wireless Dongle that costs around $10 and a Linux VM. Install the corresponding dongle firmware and a tool called mdk3. For details, please refer to this article.

As part of the beacon frame mandatory field, SSID can store a string of up to 32 bytes. wifid assigns a string object for each detected SSID. You can observe that from the log. This is the most obvious thing we can use for spray.

Now attach a debugger to wifid and start flooding the device with a list of SSIDs that can be easily recognized. Turn on the iOS wifi feature and wait until it begins automatically scanning for available WiFi. The breakpoint will get triggered and check through the stack to find traces of spray. Below is the output of the lldb script:

The thing that caught our eye is the pointer stored at stack + offset 0x18. Since the SSID can store up to 32 bytes, the shortest format string escape character such as %x will occupy two bytes, which means that we can reach the range of 16 pointers stored on the stack with a single SSID at most. So stack + offset 0x18 could be reached by the fourth escape character. And the test results tell us that data at this offset could be controlled by the content we spray.

Step 3 – Test the Ability to Remotely Control the Code Execution Flow

So in the next test, we kept the Beacon Flooding Attack running, meanwhile we built a hotspot named “DDDD%x%x%x%@”. Notice that %@ is the fourth escape character. Unsurprisingly, wifid crashes as soon as it reads the name, and it automatically respawns and crashes again as long as the hotspot is still on.

Checking the crash, it appears that the x15 register is easily affected.

Now analyze where it crashed. As the effect of %@ format specifier, it’s trying to print Objective-C Object.

The code block highlighted in yellow is the desired code execution flow. x0 is the pointer stored at stack + offset 0x18. We try to control its content through the spray and lead the situation to the typical Use-After-Free scenario. x9 is the data x0 points to. It represents isa pointer, which is the first member of the objc object data structure. As you can see in the figure, control x9 is critical to reaching that objc_msgSend call at the bottom. With more tests, we confirmed that stack + offset 0x18 indeed can be affected by the spray.

Now things have become more familiar. Pass a controlled/fake Objc object to objc_msgSend to achieve arbitrary code execution. The next challenge is finding a way to spray memory filled with ROP/JOP payload.

Step 4 – Achieving Remote Code Execution

wifid deals with a lot of wireless features. Spraying large memory wirelessly is left as an exercise for the reader. Locally, this bug can be used to build a partial sandbox escape to help achieve jailbreaking.

Attacks-In-The-Wild?

Ironically, the events that triggered our interest in this vulnerability were not related to an attack and the two devices were only subject to a denial of service issue that was fixed on iOS 14.6.

However, since this vulnerability was widely published, and relatively easy to notice, we are highly confident that various threat actors have discovered the same information we did, and we would like to encourage an issuance of a patch as soon as possible.

ZecOps Mobile EDR Customers will identify attacks leveraging these vulnerabilities with the tag “WiFiDemon”.

Generating an Alert Using ZecOps Mobile EDR

We have added generic rules for detection of successful exploitation to our customers.

We also provided instructions to customers on how to create a rule to see failed spraying / ASLR bypass attempts.

To summarize:

• A related vulnerability was exploitable as a 0-click until iOS 14.4. CVE was not assigned and the vulnerability was silently patched. The patch thanks an anonymous researcher.
• The publicly announced WiFi vulnerability is exploitable on 14.6 when connecting a maliciously crafted SSID.
• We highly recommend issuing a patch for this vulnerability.
• Older devices: e.g. iPhone 5s are still on iOS 12.X which is not vulnerable to the 0-click vulnerability.

If you’d like to check your phone and monitor it – feel free to reach out to us here to discuss how we can help you increase your mobile visibility using ZecOps Mobile EDR.

We would like to thank @08tc3wbb (follow), @ihackbanme (follow) and SYMaster for assisting with this blog.

iOS 14.7 fix

The fix on iOS 14.7 is as follows, it’s pretty straightforward, adding “%s” as format-string and the SSID included string as a parameter solves the issue.

This blog was written byVaradharajan Krishnasamy, Karthickkumar, Sakshi Jaiswal

Introduction

Ransomware attacks are one of the most common cyber-attacks among organizations; due to an increase in Ransomware-as-a-service (RaaS) on the black market. RaaS provides readily available ransomware to cyber criminals and is an effective way for attackers to deploy a variety of ransomware in a short period of time.

Usually, RaaS model developers sell or rent their sophisticated ransomware framework on the black market. After purchasing the license from the ransomware developer, attackers spread the ransomware to other users, infect them, encrypt files, and demand a huge ransom payment in Bitcoin.  Also, there are discounts available on the black market for ransomware frameworks in which the ransom money paid is shared between developers and the buyer for every successful extortion of ransom from the victims. These frameworks reduce the time and effort of creating a new ransomware from scratch using latest and advanced programming languages.

REvil is one of the most famous ransomware-as-a-service (RaaS) providers. The group released the Sodinokibi ransomware in 2019, and McAfee has since observed REvil using a DLL side loading technique to execute ransomware code. The actual ransomware is a dropper that contains two embedded PE files in the resource section.  After successful execution, it drops two additional files named MsMpEng.exe and MpSvc.dll in the temp folder. The file MsMpEng.exe is a Microsoft digitally signed file having a timestamp of March 2014 (Figure 1).

Figure-1: Image of Microsoft Digitally signed File

DLL SIDE LOADING

The malware uses DLL side loading to execute the ransomware code. This technique allows the attacker to execute malicious DLLs that spoof legitimate ones. This technique has been used in many APTs to avoid detection. In this attack, MsMpEng.exe loads the functions of MpSvc.dll during the time of execution. However, the attacker has replaced the clean MpSvc.dll with the ransomware binary of the same name. The malicious DLL file has an export function named ServiceCrtMain, which is further called and executed by the Microsoft Defender file. This is a clever technique used by the attacker to execute malicious file using the Microsoft digitally signed binary.

Figure-2: Calling Export function

PAYLOAD ANALYSIS

The ransomware uses the RC4 algorithm to decrypt the config file which has all the information that supports the encryption process.

Figure-3: REvil Config File

Then it performs a UI language check using GetSystemDefaultUILanguage/GetUserDefaultUILanguage functions and compares it with a hardcoded list which contains the language ID of several countries as shown in below image.

Figure-4: Language Check

Countries excluded from this ransomware attack are mentioned below:

Additionally, the ransomware checks the users keyboardlayout and it skips the ransomware infection in the machine’s which are present in the country list above.

Figure-5: Keyboardlayout check

Ransomware creates a Global mutex in the infected machine to mark its presence.

Figure-6: Global Mutex

After creating the mutex, the ransomware deletes the files in the recycle bin using the SHEmptyRecycleBinW function to make sure that no files are restored post encryption.

Figure-7: Empty Recycle Bin

Then it enumerates all the active services with the help of the EnumServicesStatusExW function and deletes services if the service name matches the list present in the config file. The image below shows the list of services checked by the ransomware.

Figure-8: Service List check

It calls the CreateToolhelp32Snapshot, Process32FirstW and Process32NextW functions to enumerate running processes and terminates those matching the list present in the config file.  The following processes will be terminated.

• allegro
• steam
• xtop
• ocssd
• xfssvccon
• onenote
• isqlplussvc
• msaccess
• powerpnt
• cad
• sqbcoreservic
• thunderbird
• oracle
• infopath
• dbeng50
• pro_comm_msg
• agntsvc
• thebat
• firefox
• ocautoupds
• winword
• synctime
• tbirdconfig
• mspub
• visio
• sql
• ocomm
• orcad
• mydesktopserv
• dbsnmp
• outlook
• cadence
• excel
• wordpad
• creoagent
• encsvc
• mydesktopqos

Then, it encrypts files using the Salsa20 algorithm and uses multithreading for fast encryption of the files. Later, background wallpaper will be set with a ransom message.

Figure-9: Desktop Wallpaper

Finally, the ransomware displays ransom notes in the victim’s machine. Below is an image of readme.txt which is dropped in the infected machine.

Figure-10: Ransom Note

IOCs and Coverage

Expert rules allow McAfee customers to extend their coverage. This rule covers this REvil ransomware behaviour.

MITRE

Conclusion

McAfee observed that the REvil group has utilized oracle web logic vulnerability (CVE-2019-2725) to spread the ransomware last year and used kaseya’s VSA application recently for their ransomware execution, with the help of DLL sideloading. REvil uses many vulnerability applications for ransomware infections, however the encryption technique remains the same. McAfee recommends making periodic backups of files and keeping them isolated off the network and having an always updated antivirus in place.

The post REvil Ransomware Uses DLL Sideloading appeared first on McAfee Blog.

This blog was written by Vallabh Chole & Oliver Devane

Over the years, the cybersecurity industry has seen many threats get taken down, such as the Emotet takedown in January 2021. It doesn’t usually take long for another threat to attempt to fill the gap left by the takedown. Hancitor is one such threat.

Like Emotet, Hancitor can send Malspams to spread itself and infect as many users as possible. Hancitor’s main purpose is to distribute other malware such as FickerStealer, Pony, CobaltStrike, Cuba Ransomware and Zeppelin Ransomware. The dropped Cobalt Strike beacons can then be used to move laterally around the infected environment and also execute other malware such as ransomware.

This blog will focus on a new technique used by Hancitor created to prevent crawlers from accessing malicious documents used to download and execute the Hancitor payload.

The infection flow of Hancitor is shown below:

A victim will receive an email with a fake DocuSign template to entice them to click a link. This link leads him to feedproxy.google.com, a service that works similar to an RSS Feed and enables site owners to publish site updates to its users.

When accessing the link, the victim is redirected to the malicious site. The site will check the User-Agent of the browser and if it is a non-Windows User-Agent the victim will be redirected to google.com.

If the victim is on a windows machine, the malicious site will create a cookie using JavaScript and then reload the site.

The code to create the cookie is shown below:

The above code will write the Timezone to value ‘n’ and the time offset to UTC in value ‘d’ and set it into cookie header for an HTTP GET Request.

For example, if this code is executed on a machine with timezone set as BST the values would be:

d = 60

n = “Europe/London”

These values may be used to prevent further malicious activity or deploy a different payload depending on geo location.

Upon reloading, the site will check if the cookie is present and if it is, it will present them with the malicious document.

A WireShark capture of the malicious document which includes the cookie values is shown below:

The document will prompt them to enable macros and, when enabled, it will download the Hancitor DLL and then load it with Rundll32.

Hancitor will then communicate with its C&C and deploy further payloads. If running on a Windows domain, it will download and deploy a Cobalt Strike beacon.

Hancitor will also deploy SendSafe which is a spam module, and this will be used to send out malicious spam emails to infect more victims.

Conclusion

With its ability to send malicious spam emails and deploy Cobalt Strike beacons, we believe that Hancitor will be a threat closely linked to future ransomware attacks much like Emotet was. This threat also highlights the importance of constantly monitoring the threat landscape so that we can react quickly to evolving threats and protect our customers from them.

IOCs, Coverage, and MITRE

IOCs

Mitre

The post Hancitor Making Use of Cookies to Prevent URL Scraping appeared first on McAfee Blog.

This blog was written by Kiran Raj & Kishan N.

Introduction

In the last few years, Microsoft Office macro malware using social engineering as a means for malware infection has been a dominant part of the threat landscape. Malware authors continue to evolve their techniques to evade detection. These techniques involve utilizing macro obfuscation, DDE, living off the land tools (LOLBAS), and even utilizing legacy supported XLS formats.

McAfee Labs has discovered a new technique that downloads and executes malicious DLLs (Zloader) without any malicious code present in the initial spammed attachment macro. The objective of this blog is to cover the technical aspect of the newly observed technique.

Infection map

Threat Summary

• The initial attack vector is a phishing email with a Microsoft Word document attachment.
• Upon opening the document, a password-protected Microsoft Excel file is downloaded from a remote server.
• The Word document Visual Basic for Applications (VBA) reads the cell contents of the downloaded XLS file and writes into the XLS VBA as macros.
• Once the macros are written to the downloaded XLS file, the Word document sets the policy in the registry to Disable Excel Macro Warning and calls the malicious macro function dynamically from the Excel file,
• This results in the downloading of the Zloader payload. The Zloader payload is then executed by rundll32.exe.

The section below contains the detailed technical analysis of this technique.

Detailed Technical Analysis

Infection Chain

The malware arrives through a phishing email containing a Microsoft Word document as an attachment. When the document is opened and macros are enabled, the Word document, in turn, downloads and opens another password-protected Microsoft Excel document.

After downloading the XLS file, the Word VBA reads the cell contents from XLS and creates a new macro for the same XLS file and writes the cell contents to XLS VBA macros as functions.

Once the macros are written and ready, the Word document sets the policy in the registry to Disable Excel Macro Warning and invokes the malicious macro function from the Excel file. The Excel file now downloads the Zloader payload. The Zloader payload is then executed using rundll32.exe.

Figure-1: flowchart of the Infection chain

Word Analysis

Here is how the face of the document looks when we open the document (figure 2). Normally, the macros are disabled to run by default by Microsoft Office. The malware authors are aware of this and hence present a lure image to trick the victims guiding them into enabling the macros.

Figure-2: Image of Word Document Face

The userform combo-box components present in the Word document stores all the content required to connect to the remote Excel document including the Excel object, URL, and the password required to open the Excel document. The URL is stored in the Combobox in the form of broken strings which will be later concatenated to form a complete clear string.

Figure-3: URL components (right side) and the password to open downloaded Excel document (“i5x0wbqe81s”) present in user-form components.

VBA Macro Analysis of Word Document

Figure-4: Image of the VBA editor

In the above image of macros (figure 4), the code is attempting to download and open the Excel file stored in the malicious domain. Firstly, it creates an Excel application object by using CreateObject() function and reading the string from Combobox-1 (ref figure-2) of Userform-1 which has the string “excel. Application” stored in it. After creating the object, it uses the same object to open the Excel file directly from the malicious URL along with the password without saving the file on the disk by using Workbooks.Open() function.

Figure-5: Word Macro code that reads strings present in random cells in Excel sheet.

The above snippet (figure 5) shows part of the macro code that is reading the strings from the Excel cells.

For Example:

Ixbq = ifk.sheets(3).Cells(44,42).Value

The code is storing the string present in sheet number 3 and the cell location (44,42) into the variable “ixbq”. The Excel.Application object that is assigned to variable “ifk” is used to access sheets and cells from the Excel file that is opened from the malicious domain.

In the below snippet (figure 6), we can observe the strings stored in the variables after being read from the cells. We can observe that it has string related to the registry entry “HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Security\AccessVBOM” that is used to disable trust access for VBA into Excel and the string “Auto_Open3” that is going to be the entry point of the Excel macro execution.

We can also see the strings “ThisWorkbook”, “REG_DWORD”, “Version”, “ActiveVBProject” and few random functions as well like “Function c4r40() c4r40=1 End Function”. These macro codes cannot be detected using static detection since the content is formed dynamically on run time.

Figure-6: Value of variables after reading Excel cells.

After extracting the contents from the Excel cells, the parent Word file creates a new VBA module in the downloaded Excel file by writing the retrieved contents. Basically, the parent Word document is retrieving the cell contents and writing them to XLS macros.

Once the macro is formed and ready, it modifies the below RegKey to disable trust access for VBA on the victim machine to execute the function seamlessly without any Microsoft Office Warnings.

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Security\AccessVBOM

After writing macro contents to Excel file and disabling the trust access, function ’Auto_Open3()’ from newly written excel VBA will be called which downloads zloader dll from the ‘hxxp://heavenlygem.com/22.php?5PH8Z’ with extension .cpl

Figure-7: Image of ’Auto_Open3()’ function

The downloaded dll is saved in %temp% folder and executed by invoking rundll32.exe.

Figure-8: Image of zloader dll invoked by rundll32.exe

Command-line parameter:

Rundll32.exe shell32.dll,Control_RunDLL “<path downloaded dll>”

Windows Rundll32 commands loads and runs 32-bit DLLs that can be used for directly invoking specified functions or used to create shortcuts. In the above command line, the malware uses “Rundll32.exe shell32.dll,Control_RunDLL” function to invoke control.exe (control panel) and passes the DLL path as a parameter, therefore the downloaded DLL is executed by control.exe.

Excel Document Analysis:

The below image (figure 9) is the face of the password-protected Excel file that is hosted on the server. We can observe random cells storing chunks of strings like “RegDelete”, “ThisWorkbook”, “DeleteLines”, etc.

These strings present in worksheet cells are formed as VBA macro in the later stage.

Figure-9: Image of Remote Excel file.

Coverage and prevention guidance:

McAfee’s Endpoint products detect this variant of malware and files dropped during the infection process.

The main malicious document with SHA256 (210f12d1282e90aadb532e7e891cbe4f089ef4f3ec0568dc459fb5d546c95eaf) is detected with V3 package version – 4328.0 as “W97M/Downloader.djx”.  The final Zloader payload with SHA-256 (c55a25514c0d860980e5f13b138ae846b36a783a0fdb52041e3a8c6a22c6f5e2)which is a DLL is detected by signature “Zloader-FCVP” with V3 package version – 4327.0

Additionally, with the help of McAfee’s Expert rule feature, customers can strengthen the security by adding custom Expert rules based on the behavior patterns of the malware. The below EP rule is specific to this infection pattern.

McAfee advises all users to avoid opening any email attachments or clicking any links present in the mail without verifying the identity of the sender. Always disable the macro execution for Office files. We advise everyone to read our blog on this new variant of Zloader and its infection cycle to understand more about the threat.

Different techniques & tactics are used by the malware to propagate and we mapped these with the MITRE ATT&CK platform.

• E-mail Spear Phishing (T1566.001): Phishing acts as the main entry point into the victim’s system where the document comes as an attachment and the user enables the document to execute the malicious macro and cause infection. This mechanism is seen in most of the malware like Emotet, Drixed, Trickbot, Agenttesla, etc.
• Execution (T1059.005): This is a very common behavior observed when a malicious document is opened. The document contains embedded malicious VBA macros which execute code when the document is opened/closed.
• Defense Evasion (T1218.011): Execution of signed binary to abuse Rundll32.exe and to proxy execute the malicious code is observed in this Zloader variant. This tactic is now also part of many others like Emotet, Hancitor, Icedid, etc.
• Defense Evasion (T1562.001): In this tactic, it Disables or Modifies security features in Microsoft Office document by changing the registry keys.

IOC

Conclusion

Malicious documents have been an entry point for most malware families and these attacks have been evolving their infection techniques and obfuscation, not just limiting to direct downloads of payload from VBA, but creating agents dynamically to download payload as we discussed in this blog. Usage of such agents in the infection chain is not only limited to Word or Excel, but further threats may use other living off the land tools to download its payloads.

Due to security concerns, macros are disabled by default in Microsoft Office applications. We suggest it is safe to enable them only when the document received is from a trusted source.

The post Zloader With a New Infection Technique appeared first on McAfee Blog.

Executive Summary

Ryuk is a ransomware that encrypts a victim’s files and requests payment in Bitcoin cryptocurrency to release the keys used for encryption. Ryuk is used exclusively in targeted ransomware attacks.

Ryuk was first observed in August 2018 during a campaign that targeted several enterprises. Analysis of the initial versions of the ransomware revealed similarities and shared source code with the Hermes ransomware. Hermes ransomware is a commodity malware for sale on underground forums and has been used by multiple threat actors.

To encrypt files Ryuk utilizes a combination of symmetric AES (256-bit) encryption and asymmetric RSA (2048-bit or 4096-bit) encryption. The symmetric key is used to encrypt the file contents, while the asymmetric public key is used to encrypt the symmetric key. Upon payment of the ransom the corresponding asymmetric private key is released, allowing the encrypted files to be decrypted.

Because of the targeted nature of Ryuk infections, the initial infection vectors are tailored to the victim. Often seen initial vectors are spear-phishing emails, exploitation of compromised credentials to remote access systems and the use of previous commodity malware infections. As an example of the latter, the combination of Emotet and TrickBot, have frequently been observed in Ryuk attacks.

Coverage and Protection Advice

Ryuk is detected as Ransom-Ryuk![partial-hash].

Defenders should be on the lookout for traces and behaviours that correlate to open source pen test tools such as winPEAS, Lazagne, Bloodhound and Sharp Hound, or hacking frameworks like Cobalt Strike, Metasploit, Empire or Covenant, as well as abnormal behavior of non-malicious tools that have a dual use. These seemingly legitimate tools (e.g., ADfind, PSExec, PowerShell, etc.) can be used for things like enumeration and execution. Subsequently, be on the lookout for abnormal usage of Windows Management Instrumentation WMIC (T1047). We advise everyone to check out the following blogs on evidence indicators for a targeted ransomware attack (Part1, Part2).

• Looking at other similar Ransomware-as-a-Service families we have seen that certain entry vectors are quite common among ransomware criminals:
• E-mail Spear phishing (T1566.001) often used to directly engage and/or gain an initial foothold. The initial phishing email can also be linked to a different malware strain, which acts as a loader and entry point for the attackers to continue completely compromising a victim’s network. We have observed this in the past with the likes of Trickbot & Ryuk or Qakbot & Prolock, etc.
• Exploit Public-Facing Application (T1190) is another common entry vector, given cyber criminals are often avid consumers of security news and are always on the lookout for a good exploit. We therefore encourage organizations to be fast and diligent when it comes to applying patches. There are numerous examples in the past where vulnerabilities concerning remote access software, webservers, network edge equipment and firewalls have been used as an entry point.
• Using valid accounts (T1078) is and has been a proven method for cybercriminals to gain a foothold. After all, why break the door down if you already have the keys? Weakly protected RDP access is a prime example of this entry method. For the best tips on RDP security, please see our blog explaining RDP security.
• Valid accounts can also be obtained via commodity malware such as infostealers that are designed to steal credentials from a victim’s computer. Infostealer logs containing thousands of credentials can be purchased by ransomware criminals to search for VPN and corporate logins. For organizations, having a robust credential management and MFA on user accounts is an absolute must have.

When it comes to the actual ransomware binary, we strongly advise updating and upgrading endpoint protection, as well as enabling options like tamper protection and Rollback. Please read our blog on how to best configure ENS 10.7 to protect against ransomware for more details.

Summary of the Threat

Ryuk ransomware is used exclusively in targeted attacks

Latest sample now targets webservers

New ransom note prompts victims to install Tor browser to facilitate contact with the actors

After file encryption, the ransomware will print 50 copies of the ransom note on the default printer

Learn more about Ryuk ransomware, including Indicators of Compromise, Mitre ATT&CK techniques and Yara Rule, by reading our detailed technical analysis.

The post New Ryuk Ransomware Sample Targets Webservers appeared first on McAfee Blog.

The relationship between processes and threads is fairly well known – a process contains one or more threads, running within the process, using process wide resources, like handles and address space.

Where do windows (those usually-rectangular elements, not the OS) come into the picture?

The relationship between a process, its threads, and windows, along with desktop and Window Stations, can be summarized in the following figure:

A window is created by a thread, and that thread is designated as the owner of the window. The creating thread becomes a UI thread (if it’s the first User/GDI call it makes), getting a message queue (provided internally by Win32k.sys in the kernel). Every occurrence in the created window causes a message to be placed in the message queue of the owner thread. This means that if a thread creates 100 windows, it’s responsible for all these windows.

“Responsible” here means that the thread must perform something known as “message pumping” – pulling messages from its message queue and processing them. Failure to do that processing would lead to the infamous “Not Responding” scenario, where all the windows created by that thread become non-responsive. Normally, a thread can read its own message queue only – other threads can’t do it for that thread – this is a single threaded UI scheme used by the Windows OS by default. The simplest message pump would look something like this:

MSG msg;
while(::GetMessage(&msg, nullptr, 0, 0)) {
    ::TranslateMessage(&msg);
    ::DispatchMessage(&msg);
}

The call to GetMessage does not return until there is a message in the queue (filling up the MSG structure), or the WM_QUIT message has been retrieved, causing GetMessage to return FALSE and the loop exited. WM_QUIT is the message typically used to signal an application to close. Here is the MSG structure definition:

typedef struct tagMSG {
  HWND   hwnd;
  UINT   message;
  WPARAM wParam;
  LPARAM lParam;
  DWORD  time;
  POINT  pt;
} MSG, *PMSG;

Once a message has been retrieved, the important call is to DispatchMessage, that looks at the window handle in the message (hwnd) and looks up the window class that this window instance is a member of, and there, finally, the window procedure – the callback to invoke for messages destined to these kinds of windows – is invoked, handling the message as appropriate or passing it along to default processing by calling DefWindowProc. (I may expand on that if there is interest in a separate post).

You can enumerate the windows owned by a thread by calling EnumThreadWindows. Let’s see an example that uses the Toolhelp API to enumerate all processes and threads in the system, and lists the windows created (owned) by each thread (if any).

We’ll start by creating a snapshot of all processes and threads (error handling mostly omitted for clarity):

#include <Windows.h>
#include <TlHelp32.h>
#include <unordered_map>
#include <string>

int main() {
	auto hSnapshot = ::CreateToolhelp32Snapshot(
        TH32CS_SNAPPROCESS | TH32CS_SNAPTHREAD, 0);

We’ll build a map of process IDs to names for easy lookup later on when we show details of a process:

PROCESSENTRY32 pe;
pe.dwSize = sizeof(pe);

// we can skip the idle process
::Process32First(hSnapshot, &pe);

std::unordered_map<DWORD, std::wstring> processes;
processes.reserve(500);

while (::Process32Next(hSnapshot, &pe)) {
	processes.insert({ pe.th32ProcessID, pe.szExeFile });
}

Now we loop through all the threads, calling EnumThreadWindows and showing the results:

THREADENTRY32 te;
te.dwSize = sizeof(te);
::Thread32First(hSnapshot, &te);

static int count = 0;

struct Data {
	DWORD Tid;
	DWORD Pid;
	PCWSTR Name;
};
do {
	if (te.th32OwnerProcessID <= 4) {
		// idle and system processes have no windows
		continue;
	}
	Data d{ 
        te.th32ThreadID, te.th32OwnerProcessID, 
        processes.at(te.th32OwnerProcessID).c_str() 
    };
	::EnumThreadWindows(te.th32ThreadID, [](auto hWnd, auto param) {
		count++;
		WCHAR text[128], className[32];
		auto data = reinterpret_cast<Data*>(param);
		int textLen = ::GetWindowText(hWnd, text, _countof(text));
		int classLen = ::GetClassName(hWnd, className, _countof(className));
		printf("TID: %6u PID: %6u (%ws) HWND: 0x%p [%ws] %ws\n",
			data->Tid, data->Pid, data->Name, hWnd,
			classLen == 0 ? L"" : className,
			textLen == 0 ? L"" : text);
		return TRUE;	// bring in the next window
		}, reinterpret_cast<LPARAM>(&d));
} while (::Thread32Next(hSnapshot, &te));
printf("Total windows: %d\n", count);

EnumThreadWindows requires the thread ID to look at, and a callback that receives a window handle and whatever was passed in as the last argument. Returning TRUE causes the callback to be invoked with the next window until the window list for that thread is complete. It’s possible to return FALSE to terminate the enumeration early.

I’m using a lambda function here, but only a non-capturing lambda can be converted to a C function pointer, so the param value is used to provide context for the lambda, with a Data instance having the thread ID, its process ID, and the process name.

The call to GetClassName returns the name of the window class, or type of window, if you will. This is similar to the relationship between objects and classes in object orientation. For example, all buttons have the class name “button”. Of course, the windows enumerated are only top level windows (have no parent) – child windows are not included. It is possible to enumerate child windows by calling EnumChildWindows.

Going the other way around – from a window handle to its owner thread and *its* owner process is possible with GetWindowThreadProcessId.

Desktops

A window is placed on a desktop, and is bound to it. More precisely, a thread is bound to a desktop once it creates its first window (or has any hook installed with SetWindowsHookEx). Before that happens, a thread can attach itself to a desktop by calling SetThreadDesktop.

Normally, a thread will use the “default” desktop, which is where a logged in user sees his or her windows appearing. It is possible to create additional desktops using the CreateDesktop API. A classic example is the desktops Sysinternals tool. See my post on desktops and windows stations for more information.

It’s possible to redirect a new process to use a different desktop (and optionally a window station) as part of the CreateProcess call. The STARTUPINFO structure has a member named lpDesktop that can be set to a string with the format “WindowStationName\DesktopName” or simply “DesktopName” to keep the parent’s window station. This could look something like this:

STARTUPINFO si = { sizeof(si) };
// WinSta0 is the interactive window station
WCHAR desktop[] = L"Winsta0\\MyOtherDesktop";
si.lpDesktop = desktop;
PROCESS_INFORMATION pi;
::CreateProcess(..., &si, &pi);

“WinSta0” is always the name of the interactive Window Station (one of its desktops can be visible to the user).

The following example creates 3 desktops and launches notepad in the default desktop and the other desktops:

void LaunchInDesktops() {
	HDESK hDesktop[4] = { ::GetThreadDesktop(::GetCurrentThreadId()) };
	for (int i = 1; i <= 3; i++) {
		hDesktop[i] = ::CreateDesktop(
			(L"Desktop" + std::to_wstring(i)).c_str(),
			nullptr, nullptr, 0, GENERIC_ALL, nullptr);
	}
	STARTUPINFO si = { sizeof(si) };
	WCHAR name[32];
	si.lpDesktop = name;
	DWORD len;
	PROCESS_INFORMATION pi;
	for (auto h : hDesktop) {
		::GetUserObjectInformation(h, UOI_NAME, name, sizeof(name), &len);
		WCHAR pname[] = L"notepad";
		if (::CreateProcess(nullptr, pname, nullptr, nullptr, FALSE,
			0, nullptr, nullptr, &si, &pi)) {
			printf("Process created: %u\n", pi.dwProcessId);
			::CloseHandle(pi.hProcess);
			::CloseHandle(pi.hThread);
		}
	}
}

If yoy run the above function, you’ll see one Notepad window on your desktop. If you dig deeper, you’ll find 4 notepad.exe processes in Task Manager. The other three have created their windows in different desktops. Task Manager gives no indication of that, nor does the process list in Process Explorer. However, we see a hint in the list of handles of these “other” notepad processes. Here is one:

Curiously enough, desktop objects are not stored as part of the kernel’s Object Manager namespace. If you double-click the handle, copy its address, and look it up in the kernel debugger, this is the result:

lkd> !object 0xFFFFAC8C12035530
Object: ffffac8c12035530  Type: (ffffac8c0f2fdbc0) Desktop
    ObjectHeader: ffffac8c12035500 (new version)
    HandleCount: 1  PointerCount: 32701
    Directory Object: 00000000  Name: Desktop1

Notice the directory object address is zero – it’s not part of any directory. It has meaning in the context of its containing Window Station.

You might think that we can use the EnumThreadWindows as demonstrated at the beginning of this post to locate the other notepad windows. Unfortunately, access is restricted and those notepad windows are not listed (more on that possibly in a future post).

We can try a different approach by using yet another enumration function – EnumDesktopWindows. Given a powerful enough desktop handle, we can enumerate all top level windows in that desktop:

void ListDesktopWindows(HDESK hDesktop) {
	::EnumDesktopWindows(hDesktop, [](auto hWnd, auto) {
		WCHAR text[128], className[32];
		int textLen = ::GetWindowText(hWnd, text, _countof(text));
		int classLen = ::GetClassName(hWnd, className, _countof(className));
		DWORD pid;
		auto tid = ::GetWindowThreadProcessId(hWnd, &pid);
		printf("TID: %6u PID: %6u HWND: 0x%p [%ws] %ws\n",
			tid, pid, hWnd, 
			classLen == 0 ? L"" : className,
			textLen == 0 ? L"" : text);
		return TRUE;
		}, 0);
}

The lambda body is very similar to the one we’ve seen earlier. The difference is that we start with a window handle with no thread ID. But it’s fairly easy to get the owner thread and process with GetWindowThreadProcessId. Here is one way to invoke this function:

auto hDesktop = ::OpenDesktop(L"Desktop1", 0, FALSE, DESKTOP_ENUMERATE);
ListDesktopWindows(hDesktop);

Here is the resulting output:

TID:   3716 PID:  23048 HWND: 0x0000000000192B26 [Touch Tooltip Window] Tooltip
TID:   3716 PID:  23048 HWND: 0x0000000001971B1A [UAC_InputIndicatorOverlayWnd]
TID:   3716 PID:  23048 HWND: 0x00000000002827F2 [UAC Input Indicator]
TID:   3716 PID:  23048 HWND: 0x0000000000142B82 [CiceroUIWndFrame] CiceroUIWndFrame
TID:   3716 PID:  23048 HWND: 0x0000000000032C7A [CiceroUIWndFrame] TF_FloatingLangBar_WndTitle
TID:  51360 PID:  23048 HWND: 0x0000000000032CD4 [Notepad] Untitled - Notepad
TID:   3716 PID:  23048 HWND: 0x0000000000032C8E [CicLoaderWndClass]
TID:  51360 PID:  23048 HWND: 0x0000000000202C62 [IME] Default IME
TID:  51360 PID:  23048 HWND: 0x0000000000032C96 [MSCTFIME UI] MSCTFIME UI

A Notepad window is clearly there. We can repeat the same exercise with the other two desktops, which I have named “Desktop2” and “Desktop3”.

Can we view and interact with these “other” notepads? The SwitchDesktop API exists for that purpose. Given a desktop handle with the DESKTOP_SWITCHDESKTOP access, SwitchDesktop changes the input desktop to the requested desktop, so that input devices redirect to that desktop. This is exactly how the Sysinternals Desktops tool works. I’ll leave the interested reader to try this out.

Window Stations

The last piece of the puzzle is a Window Station. I assume you’ve read my earlier post and understand the basics of Window Stations.

A Thread can be associated with a desktop. A process is associated with a window station, with the constraint being that any desktop used by a thread must be within the process’ window station. In other words, a process cannot use one window station and any one of its threads using a desktop that belongs to a different window station.

A process is associated with a window station upon creation – the one specified in the STARTUPINFO structure or the creator’s window station if not specified. Still, a process can associate itself with a different window station by calling SetProcessWindowStation. The constraint is that the provided window station must be part of the current session. There is one window station per session named “WinSta0”, called the interactive window station. One of its desktop can be the input desktop and have user interaction. All other window stations are non-interactive by definition, which is perfectly fine for processes that don’t require any user interface. In return, they get better isolation, because a window station contains its own set of desktops, its own clipboard and its own atom table. Windows handles, by the way, have Window Station scope.

Just like desktops, window stations can be created by calling CreateWindowStation. Window stations can be enumerated as well (in the current session) with EnumerateWindowStations.

Summary

This discussion of threads, processes, desktops, and window stations is not complete, but hopefully gives you a good idea of how things work. I may elaborate on some advanced aspects of Windows UI system in future posts.

Posted by Felix Wilhelm, Project Zero

Introduction

KVM (for Kernel-based Virtual Machine) is the de-facto standard hypervisor for Linux-based cloud environments. Outside of Azure, almost all large-scale cloud and hosting providers are running on top of KVM, turning it into one of the fundamental security boundaries in the cloud.

In this blog post I describe a vulnerability in KVM’s AMD-specific code and discuss how this bug can be turned into a full virtual machine escape. To the best of my knowledge, this is the first public writeup of a KVM guest-to-host breakout that does not rely on bugs in user space components such as QEMU. The discussed bug was assigned CVE-2021-29657, affects kernel versions v5.10-rc1 to v5.12-rc6 and was patched at the end of March 2021. As the bug only became exploitable in v5.10 and was discovered roughly 5 months later, most real world deployments of KVM should not be affected. I still think the issue is an interesting case study in the work required to build a stable guest-to-host escape against KVM and hope that this writeup can strengthen the case that hypervisor compromises are not only theoretical issues.

I start with a short overview of KVM’s architecture, before diving into the bug and its exploitation.

KVM

KVM is a Linux based open source hypervisor supporting hardware accelerated virtualization on x86, ARM, PowerPC and S/390. In contrast to the other big open source hypervisor Xen, KVM is deeply integrated with the Linux Kernel and builds on its scheduling, memory management and hardware integrations to provide efficient virtualization.

KVM is implemented as one or more kernel modules (kvm.ko plus kvm-intel.ko or kvm-amd.ko on x86) that expose a low-level IOCTL-based API to user space processes over the /dev/kvm device. Using this API, a user space process (often called VMM for Virtual Machine Manager) can create new VMs, assign vCPUs and memory, and intercept memory or IO accesses to provide access to emulated or virtualization-aware hardware devices. QEMU has been the standard user space choice for KVM-based virtualization for a long time, but in the last few years alternatives like LKVM, crosvm or Firecracker have started to become popular.

While KVM’s reliance on a separate user space component might seem complicated at first, it has a very nice benefit: Each VM running on a KVM host has a 1:1 mapping to a Linux process, making it managable using standard Linux tools.

This means for example, that a guest's memory can be inspected by dumping the allocated memory of its user space process or that resource limits for CPU time and memory can be applied easily. Additionally, KVM can offload most work related to device emulation to the userspace component. Outside of a couple of performance-sensitive devices related to interrupt handling, all of the complex low-level code for providing virtual disk, network or GPU access can be implemented in userspace.  

When looking at public writeups of KVM-related vulnerabilities and exploits it becomes clear that this design was a wise decision. The large majority of disclosed vulnerabilities and all publicly available exploits affect QEMU and its support for emulated/paravirtualized devices.

Even though KVM’s kernel attack surface is significantly smaller than the one exposed by a default QEMU configuration or similar user space VMMs, a KVM vulnerability has advantages that make it very valuable for an attacker:

• Whereas user space VMMs can be sandboxed to reduce the impact of a VM breakout, no such option is available for KVM itself. Once an attacker is able to achieve code execution (or similarly powerful primitives like write access to page tables) in the context of the host kernel, the system is fully compromised.
• Due to the somewhat poor security history of QEMU, new user space VMMs like crosvm or Firecracker are written in Rust, a memory safe language. Of course, there can still be non-memory safety vulnerabilities or problems due to incorrect or buggy usage of the KVM APIs, but using Rust effectively prevents the large majority of bugs that were discovered in C-based user space VMMs in the past.
• Finally, a pure KVM exploit can work against targets that use proprietary or heavily modified user space VMMs. While the big cloud providers do not go into much detail about their virtualization stacks publicly, it is safe to assume that they do not depend on an unmodified QEMU version for their production workloads. In contrast, KVM’s smaller code base makes heavy modifications unlikely (and KVM’s contributor list points at a strong tendency to upstream such modifications when they exist).  

With these advantages in mind, I decided to spend some time hunting for a KVM vulnerability that could be turned into a guest-to-host escape. In the past, I had some success with finding vulnerabilities in KVM’s support for nested virtualization on Intel CPUs so reviewing the same functionality for AMD seemed like a good starting point. This is even more true, because the recent increase of AMD’s market share in the server segment means that KVM’s AMD implementation is suddenly becoming a more interesting target than it was in the last years.

Nested virtualization, the ability for a VM (called L1) to spawn nested guests (L2), was also a niche feature for a long time. However, due to hardware improvements that reduce its overhead and increasing customer demand it’s becoming more widely available. For example, Microsoft is heavily pushing for Virtualization-based Security as part of newer Windows versions, requiring nested virtualization to support cloud-hosted Windows installations. KVM enables support for nested virtualization on both AMD and Intel by default, so if an administrator or the user space VMM does not explicitly disable it, it’s part of the attack surface for a malicious or compromised VM.

AMD’s virtualization extension is called SVM (for Secure Virtual Machine) and in order to support nested virtualization, the host hypervisor needs to intercept all SVM instructions that are executed by its guests, emulate their behavior and keep its state in sync with the underlying hardware. As you might imagine, implementing this correctly is quite difficult with a large potential for complex logic flaws, making it a perfect target for manual code review.

The Bug

Before diving into the KVM codebase and the bug I discovered, I want to quickly introduce how AMD SVM works to make the rest of the post easier to understand. (For a thorough documentation see AMD64 Architecture Programmer’s Manual, Volume 2: System Programming Chapter 15.) SVM adds support for 6 new instructions to x86-64 if SVM support is enabled by setting the SVME bit in the EFER MSR. The most interesting of these instructions is VMRUN, which (as its name suggests) is responsible for running a guest VM. VMRUN takes an implicit parameter via the RAX register pointing to the page-aligned physical address of a data structure called “virtual machine control block” (VMCB), which describes the state and configuration of the VM.

The VMCB is split into two parts: First, the State Save area, which stores the values of all guest registers, including segment and control registers. Second, the Control area which describes the configuration of the VM. The Control area describes the virtualization features enabled for a VM,  sets which VM actions are intercepted to trigger a VM exit and stores some fundamental configuration values such as the page table address used for nested paging.

If the VMCB is correctly prepared (and we are not already running in a VM), VMRUN will first save the host state in a memory region called the host save area, whose address is configured by writing a physical address to the VM_HSAVE_PA MSR. Once the host state is saved, the CPU switches to the VM context and VMRUN only returns once a VM exit is triggered for one reason or another.

An interesting aspect of SVM is that a lot of the state recovery after a VM exit has to be done by the hypervisor. Once a VM exit occurs, only RIP, RSP and RAX are restored to the previous host values and all other general purpose registers still contain the guest values. In addition, a full context switch requires manual execution of the VMSAVE/VMLOAD instructions which save/load additional system registers (FS, SS, LDTR, STAR, LSTAR …) from memory.

For nested virtualization to work, KVM intercepts execution of the VMRUN instruction and creates its own VMCB based on the VMCB the L1 guest prepared (called vmcb12 in KVM terminology). Of course, KVM can’t trust the guest provided vmcb12 and needs to carefully validate all fields that end up in the real VMCB that gets passed to the hardware (known as vmcb02).

Most of the KVM’s code for nested virtualization on AMD is implemented in arch/x86/kvm/svm/nested.c and the code that intercepts VMRUN instructions of nested guests is implemented in nested_svm_vmrun:

The function first fetches the value of RAX out of the currently active vmcb (svm->vcmb) in 1 (numbers are marked in the code samples). For guests using nested paging (which is the only relevant configuration nowadays) RAX contains a guest physical address (GPA), which needs to be translated into a host physical address (HPA) first. kvm_vcpu_map (2) takes care of this translation and maps the underlying page to a host virtual address (HVA) that can be directly accessed by KVM.

Once the VMCB is mapped, nested_vmcb_checks is called for some basic validation in 3. Afterwards, the L1 guest context which is stored in svm->vmcb is copied into the host save area svm->nested.hsave before KVM enters the nested guest context by calling enter_svm_guest_mode (4).

Looking at enter_svm_guest_mode we can see that KVM copies the vmcb12 control area directly into svm->nested.ctl and does not perform any further checks on the copied value.

Readers familiar with double fetch or Time-of-Check-to-Time-of-Use vulnerabilities might already see a potential issue here: The call to nested_vmcb_checks at the beginning of nested_svm_vmrun performs all of its checks on a copy of the VMCB that is stored in guest memory. This means that a guest with multiple CPU cores can modify fields in the VMCB after they are verified in nested_vmcb_checks, but before they are copied to svm->nested.ctl in load_nested_vmcb_control.

Let’s look at nested_vmcb_checks to see what kind of checks we can bypass with this approach:

At first glance this looks pretty harmless. control->asid isn’t used anywhere and the last check is only relevant for systems where nested paging isn’t supported. However, the first check turns out to be very interesting.

For reasons unknown to me, SVM VMCBs contain a bit that enables or disables interception of the VMRUN instruction when executed inside a guest. Clearing this bit isn’t actually supported by hardware and results in an immediate VMEXIT, so the check in nested_vmcb_check_controls simply replicates this behavior.  When we race and bypass the check by repeatedly flipping the value of the INTERCEPT_VMRUN bit, we can end up in a situation where svm->nested.ctl contains a 0 in place of the INTERCEPT_VMRUN bit. To understand the impact we first need to see how nested vmexit’s are handled in KVM:

The main SVM exit handler is the function handle_exit in arch/x86/kvm/svm.c, which is called whenever a VMexit occurs. When KVM is running a nested guest, it first has to check if the exit should be handled by itself or the L1 hypervisor. To do this it calls the function nested_svm_exit_handled (5) which will return NESTED_EXIT_DONE if the vmexit will be handled by the L1 hypervisor and no further processing by the L0 hypervisor is needed:

nested_svm_exit_handled first calls nested_svm_intercept (6) to see if the exit should be handled. When we trigger an exit by executing VMRUN in a L2 guest, the default case is executed (7) to see if the INTERCEPT_VMRUN bit in svm->nested.ctl is set. Normally, this should always be the case and the function returns NESTED_EXIT_DONE to trigger a nested VM exit from L2 to L1 and to let the L1 hypervisor handle the exit (8). (This way KVM supports infinite nesting of hypervisors).

However, if the L1 guest exploited the race condition described above svm->nested.ctl won’t have the INTERCEPT_VMRUN bit set and the VM exit will be handled by KVM itself. This results in a second call to nested_svm_vmrun while still running inside the L2 guest context. nested_svm_vmrun isn’t written to handle this situation and will blindly overwrite the L1 context stored in svm->nested.hsave with data from the currently active svm->vmcb which contains data for the L2 guest:

This becomes a security issue due to the way Model Specific Register (MSR) intercepts are handled for nested guests:

SVM uses a permission bitmap to control which MSRs can be accessed by a VM. The bitmap is a 8KB data structure with two bits per MSR, one of which controls read access and the other write access. A 1 bit in this position means the access is intercepted and triggers a vm exit, a 0 bit means the VM has direct access to the MSR. The HPA address of the bitmap is stored in the VMCB control area and for normal L1 KVM guests, the pages are allocated and pinned into memory as soon as a vCPU is created.

For a nested guest, the MSR permission bitmap is stored in svm->nested.msrpm and its physical address is copied into the active VMCB (in svm->vmcb->control.msrpm_base_pa) while the nested guest is running. Using the described double invocation of nested_svm_vmrun, a malicious guest can copy this value into the svm->nested.hsave VMCB when copy_vmcb_control_area is executed. This is interesting because the KVM’s hsave area normally only contains data from the L1 guest context so svm->nested.hsave.msrpm_base_pa would normally point to the pinned vCPU-specific MSR bitmap pages.

This edge case becomes exploitable thanks to a relatively recent change in KVM:

Since commit “2fcf4876: KVM: nSVM: implement on demand allocation of the nested state” from last October, svm->nested.msrpm is dynamically allocated and freed when a guest changes the SVME bit of the MSR_EFER register:

For the “disable SVME” case, KVM will first call svm_leave_nested to forcibly leave potential

nested guests and then free the svm->nested data structures (including the backing pages for the MSR permission bitmap) in svm_free_nested. As svm_leave_nested believes that svm->nested.hsave contains the saved context of the L1 guest, it simply copies its control area to the real VMCB:

But as mentioned before, svm->nested.hsave->control.msrpm_base_pa can still point to

svm->nested->msrpm. Once svm_free_nested is finished and KVM passes control back to the guest, the CPU will use the freed pages for its MSR permission checks. This gives a guest unrestricted access to host MSRs if the pages are reused and partially overwritten with zeros.

To summarize, a malicious guest can gain access to host MSRs using the following approach:

1. Enable the SVME bit in MSR_EFER to enable nested virtualization
2. Repeatedly try to launch a L2 guest using the VMRUN instruction while flipping the INTERCEPT_VMRUN bit on a second CPU core.
3. If VMRUN succeeds, try to launch a “L3” guest using another invocation of VMRUN. If this fails, we have lost the race in step 2 and must try again. If VMRUN succeeds we have successfully overwritten svm->nested.hsave with our L2 context.  
4. Clear the SVME bit in MSR_EFER while still running in the “L3” context. This frees the MSR permission bitmap backing pages used by the L2 guest who is now executing again.
5. Wait until the KVM host reuses the backing pages. This will potentially clear all or some of the bits, giving the guest access to host MSRs.

When I initially discovered and reported this vulnerability, I was feeling pretty confident that this type of MSR access should be more or less equivalent to full code execution on the host. While my feeling turned out to be correct, getting there still took me multiple weeks of exploit development. In the next section I’ll describe the steps to turn this primitive into a guest-to-host escape.

The Exploit

Assuming our guest can get full unrestricted access to any MSR (which is only a question of timing thanks to init_on_alloc=1 being the default for most modern distributions), how can we escalate this into running arbitrary code in the context of the KVM host? To answer this question we first need to look at what kind of MSRs are supported on a modern AMD system. Looking at the BIOS and Kernel Developer’s Guide for recent AMD processors we can find a wide range of MSRs starting with well known and widely used ones such as EFER (the Extended Feature Enable Register) or LSTAR (the syscall target address) to rarely used ones like SMI_ON_IO_TRAP (can be used to generate a System Management Mode Interrupt when specific IO port ranges are accessed).

Looking at the list, several registers like LSTAR or KERNEL_GSBASE seem like interesting targets for redirecting the execution of the host kernel. Unrestricted access to these registers is actually enabled by default, however they are automatically restored to a valid state by KVM after a vmexit so modifying them does not lead to any changes in host behavior.

Still, there is one MSR that we previously mentioned and that seems to give us a straightforward way to achieve code execution: The VM_HSAVE_PA that stores the physical address of the host save area, which is used to restore the host context when a vmexit occurs. If we can point this MSR at a memory location under our control we should be able to fake a malicious host context and execute our own code after a vmexit.

While this sounds pretty straightforward in theory, implementing it still has some challenges:

• AMD is pretty clear about the fact that software should not touch the host save area in any way and that the data stored in this area is CPU-dependent: “Processor implementations may store only part or none of host state in the memory area pointed to by VM_HSAVE_PA MSR and may store some or all host state in hidden on-chip memory. Different implementations may choose to save the hidden parts of the host’s segment registers as well as the selectors. For these reasons, software must not rely on the format or contents of the host state save area, nor attempt to change host state by modifying the contents of the host save area.” (AMD64 Architecture Programmer’s Manual, Volume 2: System Programming, Page 477). To strengthen the point, the format of the host save area is undocumented.
• Debugging issues involving an invalid host state is very tedious as any issue leads to an immediate processor shutdown. Even worse, I wasn’t sure if rewriting the VM_HSAVE_PA MSR while running inside a VM can even work. It’s not really something that should happen during normal operation so in the worst case scenario, overwriting the MSR would just lead to an immediate crash.
• Even if we can create a valid (but malicious) host save area in our guest, we still need some way to identify its host physical address (HPA). Because our guest runs with nested paging enabled, physical addresses that we can see in the guest (GPAs) are still one address translation away from their HPA equivalent.

After spending some time scrolling through AMD’s documentation, I still decided that VM_HSAVE_PA seems to be the best way forward and decided to tackle these problems one by one.

After dumping the host save area of a normal KVM guest running on an AMD EPYC 7351P CPU, the first problem goes away quickly: As it turns out, the host save area has the same layout as a normal VMCB with only a couple of relevant fields initialized. Even better, the initialized fields include all the saved host information documented in the AMD manual so the fear that all interesting host state is stored in on-chip memory seems to be unfounded.

Under the mistaken assumption that I solved the problem of creating a fake but valid host save area, I decided to look into building an infoleak that gives me the ability to translate GPAs to HPAs. A couple hours of manual reading led me to an AMD-specific performance monitoring feature called Instruction Based Sampling (IBS). When IBS is enabled by writing the right magic invocation to a set of MSRs, it samples every Nth instruction that is executed and collects a wide range of information about the instruction. This information is logged in another set of MSRs and can be used to analyze the performance of any piece of code running on the CPU. While most of the documentation for IBS is pretty sparse or hard to follow, the very useful open source project AMD IBS Toolkit contains working code, a readable high level description of IBS and a lot of useful references.

IBS supports two different modes of operation, one that samples Instruction fetches and one that samples micro-ops (which you can think of as the internal RISC representation of more complex x64 instructions). Depending on the operation mode, different data is collected. Besides a lot of caching and latency information that we don’t care about, fetch sampling also returns the virtual address and physical address of the fetched instruction. Op sampling is even more useful as it returns the virtual address of the underlying instruction as well as virtual and physical addresses accessed by any load or store micro op.

Interestingly, IBS does not seem to care about the virtualization context of its user and every physical address returned by it is an HPA (of course this is not a problem outside of this exploit as guest accesses to the IBS MSR’s will normally be restricted). The wide range of data returned by IBS and the fact that it’s completely driven by MSR reads and writes make it the perfect tool for building infoleaks for our exploit.

Building a GPA -> HPA leak boils down to enabling IBS ops sampling, executing a lot of instructions that access a specific memory page in our VM and reading the IBS_DC_PHYS_AD MSR to find out its HPA:

Using this infoleak primitive, I started to create a fake host save area by preparing my own page tables (for pointing CR3 at them), interrupt descriptor tables and segment descriptors and pointing RIP to a primitive shellcode that would write to the serial console. Of course, my first tries immediately crashed the whole system and even after spending multiple days to make sure everything was set up correctly, the system would crash immediately once I pointed the hsave MSR at my own location.

After getting frustrated with the total lack of progress, watching my server reboot for the hundredth time, trying to come up with a different exploitation strategy for two weeks and learning about the surprising regularity of physical page migrations on Linux, I realized that I made an important mistake. Just because the CPU initializes all the expected fields in the host save area, it is not safe to assume that these fields are actually used for restoring the host context. Slow trial and error led to the discovery that my AMD EPYC CPU ignores everything in the host save area besides the values of the RIP, RSP and RAX registers.

While this register control would make a local privilege escalation straightforward, escaping the VM boundary is a bit more complicated. RIP and RSP control make launching a kernel ROP chain the next logical step, but this requires us to first break the host kernel's address randomization and to find a way to store controlled data at a known host virtual address (HVA).

Fortunately, we have IBS as a powerful infoleak building primitive and can use it to gather all required information in a single run:

• Leaking the host kernel's (or more specifically kvm-amd.ko’s) base address can be done by enabling IBS sampling with a small sampling interval and immediately triggering a VM exit. When VM execution continues, the IBS result MSRs will contain the HVA of instructions executed by KVM during the exit handling.
• The most powerful way to store data at a known HVA is to leak the location of the kernel’s linear mapping (also known as physmap), a 1:1 mapping of all physical pages on the system. This gives us a GPA->HVA translation primitive by first using our GPA->HPA infoleak from above and then adding the HPA to the physmap base address. Leaking the physmap is possible by sampling micro ops in the host kernel until we find a read or write operation, where the lower ~30 bits of the accessed virtual address and physical address are identical.

Having all these building blocks in place, we could now try to build a kernel ROP chain that executes some interesting payload. However, there is one important caveat. When we take over execution after a vmexit, the system is still in a somewhat unstable state. As mentioned above, SVM’s context switching is very minimal and we are at least one VMLOAD instruction and reenabling of interrupts away from a usable system. While it is surely possible to exploit this bug and to restore the original host context using a sufficiently complex ROP chain, I decided to find a way to run my own code instead.

A couple of years ago, the Linux physmap was still mapped executable and executing our own code would be as simple as jumping to a physmap mapping of one of our guest pages. Of course, that is not possible anymore and the kernel tries hard to not have any memory pages mapped as writable and executable. Still, page protections only apply to virtual memory accesses so why not use an instruction that directly writes controlled data to a physical address? As you might remember from our initial discussion of SVM earlier in this chapter, SVM supports an instruction called VMSAVE to store hidden guest state (or host state) in a VMCB. Similar to VMRUN, VMSAVE takes a physical address to a VMCB stored in the RAX register as an implicit argument. It then writes the following register state to the VMCB:

• FS, GS, TR, LDTR
• KernelGsBase
• STAR, LSTAR, CSTAR, SFMASK
• SYSENTER_CS, SYSENTER_ESP, SYSENTER_EIP

For us, VMSAVE is interesting for a couple of reasons:

• It is used as part of KVM’s normal SVM exit handler and can be easily integrated into a minimal ROP chain.
• It operates on physical addresses, so we can use it to write to an arbitrary memory location including KVM’s own code.
• All written registers still contain the guest values set by our VM, allowing us to control the written content with some restrictions

VMSAVE’s biggest downside as an exploitation primitive is that RAX needs to be page aligned, reducing our control of the target address. VMSAVE writes to the memory offsets 0x440-0x480 and 0x600-0x638 so we need to be careful about not corrupting any memory that’s in use.

In our case this turns out to be a non-issue, as KVM contains a couple of code pages where functions that are rarely or never used (e.g cleanup_module or SEV specific code) are stored at these offsets.

While we don’t have full control over the written data and valid register values are somewhat restricted, it is still possible to write a minimal stage0 shellcode to an arbitrary page in the host kernel by filling guest MSRs with the right values. My exploit uses the STAR, LSTAR and CSTAR registers for this which are written to the physical offsets 0x400, 0x408 and 0x410. As all three registers need to contain canonical addresses, we can only use parts of the registers for our shellcode and use relative jumps to skip the unusable parts of the STAR and LSTAR MSRs:

The above code makes use of the fact that we control the value of the RBX register and the stack when we return to it as part of our initial ROP chain. First, we copy the value of RBX (0x80040033) into CR0, which disables Write Protection (WP) for kernel memory accesses. This makes all of the kernel code writable on this CPU allowing us to copy a larger stage1 shellcode to an arbitrary unused memory location and jump to it.

Once the WP bit in cr0 is disabled and the stage1 payload executes, we have a wide range of options. For my proof-of-concept exploit I decided on a somewhat boring but easy-to-implement approach to spawn a random user space command: The host is still in a very weird state so our stage1 payload can’t directly call into other kernel functions, but we can easily backdoor a function pointer which will be called at some later point in time. KVM uses the kernel’s global workqueue feature to regularly synchronize a VM’s clock between different vCPUs. The function pointer responsible for this work is stored in the (per VM) kvm->arch data structure as kvm->arch.kvmclock_update_work. The stage1 payload overrides this function pointer with the address of a stage2 payload. To put the host into a usable state it then sets the VM_HSAVE_PA MSR back to its original value and restores RSP and RIP to call the original vmexit handler.

The final stage2 payload executes at some later point in time as part of the kernel global work queue and uses the call_usermodehelper to run an arbitrary command with root privileges.

Let’s put all of this together and walk through the attacks step-by-step:

1. Prepare the stage0 payload by splitting it up and setting the right guest MSRs.
2. Trigger the TOCTOU vulnerability in nested_svm_vmrun and free the MSR permission bitmap by disabling the SVME bit in the EFER MSR.
3. Wait for the pages to be reused and initialized to 0 to get unrestricted MSR access.
4. Prepare a fake host save area, a stack for the initial ROP chain and a staging memory area for the stage1 and stage2 payloads.
5. Leak the HPA of the host save area, the HVA addresses of the stack and staging page and the kvm-amd.ko’s base address using the different IBS infoleaks.
6. Redirect execution to the VMSAVE gadget by setting RIP, RSP and RAX in the fake host save area, pointing the VM_HSAVE_PA MSR at it and triggering a VM exit.
7. VMSAVE writes the stage0 payload to an unused offset in kvm-amd’s code segment, when the gadget returns stage0 gets executed.
8. stage0 disables Write Protection in CR0 and overwrites an unused executable memory location with the stage1 and stage2 payloads, before jumping to stage1.
9. stage1 overwrites kvm->arch.kvmclock_update_work.work.func with a pointer to stage2 before restoring the original host context.
10. At some later point in time kvm->arch.kvmclock_update_work.work.func is called as part of the global kernel work_queue and stage2 spawns an arbitrary command using call_usermodehelper.