Time to Rethink Your Security Strategy

As you may have heard, a massive breach of Microsoft Exchange servers was revealed in the last several weeks. The attack is not over yet. We can always wait for another attack and blame another vendor, but when it comes to Microsoft, well, who can we rely on after that?

SolarWinds, Centreon and now Microsoft Exchange – with almost 80% enterprise market share, Exchange holds the biggest secrets of our times, and now nobody knows where they went. Many of the affected organizations certainly had top-notch security measures and personnel in place. Should we buy and install more security tools? Well, clearly, more isn’t always better.

Why Exchange Server? Why Now?

Microsoft is, arguably, one of the most advanced security companies in the world, with nearly endless resources and skilled talent. The company is understandably concerned for its reputation. Microsoft developed and used many security tools, like Defender, which was likely installed alongside the compromised Exchange Servers, but failed to catch the attack. So, what do we hope will save us in the future?

Several critical vulnerabilities were exploited by the attackers in several waves. For example, Remote Command Execution (RCE) allowed malicious code injection and arbitrary file override to gain persistency and inject remote command-and-control access. These vulnerabilities remained publicly unknown (zero-day) for a long time – at least since the release of Exchange 2013. As Microsoft admitted in this analysis paper, while some attackers find and exploit vulnerabilities, others reverse-engineer the patches faster than legitimate customers update their software. This generates massive secondary waves of attacks. Moreover, often, attackers use the vulnerabilities to sneak in and wait. In this particular case, the attackers installed web shells somewhere inside the networks, which means patching Exchange Server after the attack happened does not help at all.

Some attackers burrowed deep enough that they remove other attackers from the system; that means they also could have cleaned up after themselves and left no trace.

There is a fundamental problem here that requires a different approach to security strategy. I hope that such a high-profile attack will act as a wake-up call for both software vendors and software users.

A recent study shows that over half of the DockerHub public container images harbor critical vulnerabilities. Eventually, somebody will exploit them, leading to more attacks. So, what should we do?

Rethinking Your Security Strategy

Some vulnerabilities may exist in the application logic and configuration of known tools and protocols. They can be mitigated with proper reviews, penetration tests and tools such as web application firewalls (WAFs).

The more sophisticated and dangerous attacks usually involve some form of malicious code injection such as process injection, DLL/SO injection, fileless malware and more. Malicious actors and their payloads may perform the actual attack right away, or  establish a command-and-control backdoor that attackers exploit to slowly explore and gradually take over the environment, move laterally and wait for the perfect time to strike.

The root of the problem is an inability to distinguish between the injected malicious code and the genuine, authentic code. There are multiple methods to authenticate users and devices, but none that authenticates the software code itself, especially during the execution. Therefore, the malicious code can access the same interfaces and data assets the genuine software does.

One way to approach this problem is to use behavior analysis tools. They aim to identify abnormal behaviors, claiming that malicious code will take actions that are markedly different from that of genuine software. These tools generate a lot of false positives, though, and miss many attack vectors. However, the most fundamental problem here is not their accuracy, but the fact that they are reactive – they inform you that you have already been compromised, which is too little, too late. In addition, attackers already know about these tools and therefore take precautions to get around them. For example, the Equifax attack was designed to take 86 days to slowly exfiltrate stolen data and fly under the behavioral analysis tool’s radar. And, of course, it’s clear these tools have missed many Exchange Server attacks for a long time.

An alternative and more efficient approach is to cryptographically authenticate the software during execution and establish strong, healthy identity for every workload. This identity must be used to verify software access rights to the interfaces and data assets. Even though many security best practices require authentication of the software itself, unfortunately the technology is not in widespread use.

Technology like this must identify and authenticate software code and its configuration parameters “in use” during the entire execution session. Instead of guessing what software does or what it is supposed to do, this technology verifies what it is by protecting the validity of every artifact loaded to the application memory to ensure it was not maliciously altered during execution. This establishes true software identity that cannot be faked. Such identity is then used to assign the communication policies and data access permissions to every individual workload. All elements – the identity, the communication and data are protected cryptographically, using appropriate signing and encryption facilities. Any software without verified identity or without proper authorizations will be automatically locked out of the application’s virtual perimeter. It will not be able to communicate with anyone and cannot decrypt any protected assets.

Even if cryptographically signed software includes a vulnerability (whether known or zero-day), it is protected against the exploitation of this vulnerability. This approach provides a wider and more proactive protection strategy against many different types of vulnerabilities, execution environment misconfigurations and dynamic events such as privilege escalation, debugger attachment and the like.

Perhaps if Exchange Server had this kind of protection, the intrusion attempt would have been identified and stopped before it caused any damage.