Microsoft Can Fix Ransomware Tomorrow

Recently, I was at a private event on security by design. I explained that Microsoft could fix ransomware tomorrow, and was surprised that the otherwise well-informed people I was speaking to hadn't heard about this approach.

Ransomware works by going through files, one by one, and replacing their content with an encrypted version. (Sometimes it also sends copies elsewhere, but that turns out to be slow, and sometimes sets off alarms.) Software on Microsoft Windows uses an application programming interface (API) called "CreateFile" to access files. Somewhat confusingly, CreateFile not only creates files but is also the primary way to open them.

Microsoft should rate-limit the CreateFile() API. That is to say, it should limit how often a given program can use the API. Because you can't encrypt a file until you can open it, this would have a dramatic impact on ransomware. It would slow it down, and help defensive tools catch it in time for humans to react.

Now, I say Microsoft should do this, and I hope it does.

Also, I made this suggestion to help show the complexity of maintaining compatibility. On the surface, it's very simple and elegant. In practice — and I say this as the person who drove the Autorun fix into Windows Update — there's going to be both practical complexities and concerns that we don't know what all the effects will be.

What Rate Is Reasonable?

The first question is, what rate is reasonable? Pick low and you break applications; pick high and you lessen the protective value. For a lot of cases, one open per second seems fine, but when we get to things like compilers, which are going to open a lot of files, we see that we may need both a general limit and allow bursts. When we get to backup software, it gets even more complicated. The backup software needs to open all the files, or at least all the changed files, which, if you think about it, is really similar to what ransomware wants to do. We can't allow an exception for read-only opens. The ransomware will open a file, encrypt the contents, write it to a new file or append it to a database, and delete the original.

So, Windows will probably need multiple rate limits. There will need to be a way to exempt programs (like compilers and backup tools), and maybe that needs to be issued globally, which means a process for software creators to get a special certificate. There needs to be logging and alerts created, tested, internationalized, etc. There'll need to be new GPOs (a tool used to administer Windows) created and documented. There needs to be a local way to allow more CreateFile calls for software that is locally developed or obscure, or whose makers are no longer around. We need to make sure that ransomware can't abuse those mechanisms. (On recent Macs, there's a complex process of reboots needed to make certain changes to the system; perhaps something similar is warranted?)

That last is tricky: The administrator has power, by design, and it's hard to limit that power. Even logging file opens would make it easier to see what software is opening lots of new files, and make it harder for ransomware to be stealthy. (And yes, there are too many alarms already.)

As long as we are not hyperfocused on the details, attackers change slowly. They still phish, through more and more channels. Over 20 years, break-ins have gone from abusing software that's listening on open ports to other problems. That was the result of a breaking change of turning the Windows Firewall on by default, in response to 2003's "summer of worms."

Hyrum's law states roughly that somebody will depend on every observable behavior of your system. And change becomes complex. The simple statement "Microsoft should rate-limit the CreateFile() API" is a can of worms.

Given the exceptional cost of ransomware today, I think that can of worms is worth opening. I think my former colleagues are up to the challenge.