Security company Nyotron recently announced that it found a new vulnerability in Microsoft’s Windows 10 that could be used in ransomware attacks. Nyotron released details of what it called a “potentially unstoppable” technique for bypassing one of Windows 10’s built-in protections against ransomware, the practice of taking over a computer and demanding payment for returning control.
Nyotron says the technique, which it calls “RIPlace,” can be used to allow ransomware to bypass “Controlled Folder Access” (CFA) in Windows 10. You can see their video demonstration here:
Nyotron specializes in endpoint security, focusing on end user devices and the networks that connect to them. Nyotron hasn’t been a regular contributor of vulnerability reports but the claim sounded potentially serious, and given the importance of endpoint security, I decided to take a deeper look, speaking with Nyotron and Microsoft to better understand the issue.
In short, while I wouldn’t agree with Nyotron’s claims that this is a vulnerability, the company has found an issue that people in the security field should know about. Fortunately, both Nyotron and Microsoft agree that this isn’t something that’s been seen in the wild in active attacks, at least not yet.
Background
Controlled Folder Access is a feature that Microsoft introduced to Windows 10 in October 2017. CFA, as it’s known, provides an additional layer of security for files that are typically targeted for encryption by ransomware.
CFA does this by adding additional monitoring to detect attempts to encrypt files in the directories that it’s watching. Since encryption is a key technique in ransomware attacks, this is a reasonable countermeasure that can be successful in preventing ransomware attacks.
The idea behind CFA is simple: if you haven’t prevented malware from executing on the system, say because a user chose to bypass security warnings and run an executable file, CFA can at least provide protection by thwarting the main thing that ransomware does: encrypt key files.
CFA is configurable so that you can include folders of your choosing. And CFA has capabilities that make it configurable for enterprises using Group Policy, PowerShell, System Center Configuration Manager (SCCM) and mobile device management (MDM) tool.
Based on Microsoft’s documentation about CFA and its behavior, it’s important to note that CFA is a “defense in depth” (DiD) measure. This means that it is not a primary security barrier per se, but something that’s meant to provide additional protections in case other security barriers fail. You can think of DiD measures as something akin to seat belts. They’re not meant to prevent crashes. But they are meant to make crashes less serious when they happen.
This distinction between a security barrier and a DiD measure is important, and we’ll come back to it shortly.
Nyotron’s claims
In Nyotron’s demo, above, you can see a technique that appears to bypass Controlled Folder Access. The demo first shows a directory that is protected by CFA. It shows that directory’s files being successfully protected by CFA against encryption by malware. And then it shows another attack where CFA protection is unsuccessful and the files are encrypted.
Nyotron provides more detail in a whitepaper, including this flow chart, which helps show more of what’s going on in the background.
This flow chart shows one very specific instance where CFA appears not to work. Specifically, in the “RIPlace” technique, malicious code replaces the file with its encrypted version rather than deleting the file first. Based on conversations with Nyotron, this situation occurs due to an error in the way that CFA is monitoring files to protect them. To get into technical details, it’s an error in passing a DosDevice path when DefineDosDevice is used. DefineDosDevice is a legacy function (remember DOS?). Microsoft appears to be using this when creating the filter driver they need as part of the extra checking and processing that makes CFA.
Another important point from Nyotron’s report: this issue occurs in limited-privilege account scenarios. In other words, this issue doesn’t require administrative privileges to work.
Put simply, there’s a bug in CFA that prevents it from protecting files from replacement.
I asked Nyotron if it has seen this used in any attacks, and a company spokesperson said it had not.
As for Microsoft’s official response, here’s what a spokesperson said: “This technique is not a security issue and does not meet the conditions of our Security Servicing Criteria. Controlled folder access is an opt-in defense-in-depth feature and not a security boundary.”
Microsoft did indicate that it will look into addressing this in a future release. This means that Microsoft agrees with the fundamental technical details from Nyotron but doesn’t view this as a security vulnerability. As such, this doesn’t meet its bar for near-term patching, but it could be resolved in a future Windows version.
Technical analysis
What to make of this? Is this a vulnerability? Is this an issue to be concerned about?
Based on Microsoft’s criteria, it’s not a vulnerability. It doesn’t represent a failure of a security boundary. Instead, it is a valid bypass of a Defense in Depth measure, apparently resulting from an issue with legacy function from the old DOS days that most of us forgot even exists. Unfortunately, this is also typical of vulnerabilities: vulnerabilities tend to crop up in old code.
Microsoft’s indication that it may address the issue in a future release is consistent with its practice. And, given that we are talking about an issue from a legacy function, this is reasonable: older code has more unknown dependencies and there is a lot of testing that has to happen any time changes are made to legacy functions. There’s always an inherent stability risk in updates, and that risk has to be balanced against the security risk an issue presents. And that risk increases when you touch older, lower-level code like this is.
Both Nyotron and Microsoft agree that this issue isn’t actively being used. That’s another point in favor of this being a longer-term fix. As noted, changes to legacy code like this can be risky and cause stability issues (i.e. crashes). You wouldn’t want to protect against a potential security risk by applying an update that causes actual crashes: you’ve just traded one problem for another. And in this case, the cure becomes more dangerous than the cause for the cure.
Of course, the threat environment can change. And if this technique is picked up and used more widely, Microsoft could move to address it more quickly.
Very often, vulnerability reports aren’t cut and dried. And this is one of those cases. Yes, there is an issue. No Microsoft hasn’t fixed it yet. No, it’s not currently being used. Yes, it could be used in the future. Yes, there is a solution available today from Nyotron. Maybe (likely yes) Microsoft will address it in the future.
Until Microsoft addresses it, companies running Windows 10 have to make your own risk assessment. The last thing I will say is to reiterate that this is a DiD measure and won’t be an issue so long as ransomware isn’t on your systems. And ransomware authors are creative enough that even without this issue they can and will find ways to bypass DiD measures like this.
If you’re concerned about ransomware, my recommendation is to first spend time on a solid backup and recovery program so that you can restore to a pre-attack state if you experience a ransomware attack. More than five years into the rise of ransomware, this remains the single most-effective and proven remedy for these kinds of attacks.
