Microsoft Should Implement Rate-Limiting for CreateFile() API to Combat Ransomware Attacks
In a recent discussion at a private security event on the topic of security by design, it was highlighted that Microsoft has the potential to quickly address the ransomware issue. Surprisingly, many attendees at the event were not aware of this approach, despite being well-informed individuals in the field.
To fully grasp the solution, it is essential to understand how ransomware operates. Ransomware works by systematically encrypting files and replacing their original content with an encrypted version. Microsoft Windows utilizes an application programming interface (API) called “CreateFile” for file access. It is important to note that CreateFile not only creates files but is also the primary method for opening files.
The proposal suggests that Microsoft should implement rate-limiting for the CreateFile() API. In other words, they should restrict how frequently a particular program or application can use this API. Since ransomware attackers cannot encrypt a file until they have opened it, this implementation would significantly impede their progress and buy time for security tools to detect and counteract the attack.
Although it is advised that Microsoft should take action on this matter, it is important to acknowledge the complexity associated with such changes. On the surface, this solution appears straightforward and elegant. However, in practical terms, it is expected that various challenges will arise, unknown effects may occur, and compatibility concerns must be addressed.
One of the critical aspects to consider is determining a reasonable rate limit. Setting the limit too low may result in breaking a vast number of applications, while setting it too high could diminish its protective value. For instance, compilers, which frequently open multiple files, will require a separate limit and the ability to allow bursts of activity. The same can be said for backup software, which also needs to open a large number of files, similar to the destructive intent of ransomware. Moreover, an exception cannot be made for read-only file opens, as ransomware can still exploit this loophole by encrypting the file contents and creating copies.
Considering these factors, it is evident that Windows will require multiple rate limits. A mechanism must be established to exempt certain programs such as compilers and backup tools. It may be necessary to issue a global certificate for specific software creators to obtain this privilege. Additionally, logging and alerts need to be developed, tested, and standardized across different regions. New Group Policy Objects (GPOs), which are Windows administration tools, will need to be created and thoroughly documented. Furthermore, a local approach must be implemented to allow for more CreateFile calls for locally developed or obscure software, or for applications whose creators are no longer active. However, it is vital to ensure that these mechanisms cannot be exploited by ransomware attackers. Perhaps a similar process to that of recent Macs, which require rebooting to implement specific system changes, should be considered.
The challenge lies in finding a solution that balances the system administrator’s power and limitations. Even the act of logging file opens would make it easier to observe which software is rapidly opening multiple files, making it harder for ransomware to operate undetected. However, it is important to note that an excess of alarms can also create additional challenges.
Attackers tend to evolve slowly, focusing on various methods such as phishing through multiple channels. Over the past two decades, the nature of break-ins has shifted from targeting software listening on open ports to exploiting other vulnerabilities. This shift was largely influenced by the requirement for the Windows Firewall to be enabled by default in response to the 2003 “summer of worms” outbreak.
Hyrum’s law suggests that every observable behavior of a system will eventually be relied upon by someone. Therefore, any changes to the system become increasingly complex. The seemingly simple statement, “Microsoft should rate-limit the CreateFile() API,” is, in reality, a significant undertaking with potential unforeseen consequences.
Considering the extraordinary costs associated with ransomware attacks in recent times, it is essential to explore all possible avenues for solutions. Although the proposed rate-limiting implementation may open a can of worms, it is a challenge that the capable individuals at Microsoft are capable of addressing.