Microsoft Exchange and Verkada Hacks: Isolate Your Apps and APIs from the Internet Cesspool

It’s been an interesting start to March in terms of public security incidents.

This month kicked off with multiple zero-day exploits being used to attack on-premises versions of Microsoft Exchange Server. And, as if that wasn’t enough, that attack was quickly followed by the news that a hacktivist “collective” calling itself APT-69420 claims to have breached the internal systems of the Silicon Valley firm Verkada. That particular breach has garnered widespread press coverage as the group claims to have gained access to live video feeds from more than 150,000 surveillance cameras.

For me, both of these incidents – and the responses from the various impacted firms – brought to mind what we as an industry have been talking about for a while: why moats and castles belong in the past.

From my perspective, these incidents represent yet another reason why moving to a Zero Trust security model that leverages a cloud-first approach is the future of security for the majority of us.

Why? It’s pretty simple.

Let’s look at the Exchange remote code execution vulnerability first.

Microsoft strongly urged customers to patch on-premises systems immediately. But, as we all know, patching systems isn’t always as easy or quick as it sounds, especially for IT teams that are generally overwhelmed and understaffed. As one would expect, multiple actors continue to take advantage of unpatched systems to attack organizations with vulnerable on-premises Exchange Servers.

At Akamai, our threat research team rolled out signatures for our web application firewall (WAF), which can stop potentially malicious payloads targeted at vulnerable Microsoft Exchange servers. In other words, Akamai’s WAF can block the malicious payload destined for a potentially unpatched system. Clearly, this does not replace patching in the long run, but can buy precious time for IT teams.

If you are interested in learning more about Akamai’s WAF-related Microsoft Exchange server zero-day mitigations, read How Akamai Can Help You Fight the Latest Exploitation Attempts Against Microsoft Exchange

These incidents also raise the larger question: What should and shouldn’t be exposed to the public internet?

That question takes me back to an appropriately titled Gartner report from 2016 called “It’s Time to Isolate Your Services From the Internet Cesspool” that gives some pretty clear guidance on that front. The answer is fairly simple: only expose to the internet what you absolutely have to; and for those services, make sure the appropriate security controls are in place.

That brings me to the second piece of major news, the Verkada hack.

As with most breaches, there are still a lot of open questions and conjecture, but what has emerged suggests that exposing a Jenkins server on the public internet is quite risky. Combine that with the well-understood tactics, techniques, and procedures of most threat actors to obtain system access and use that initial access to pivot to other resources on the network, and you have a recipe for even more risk.

Either way, in both of these cases restricting access to a vulnerable Exchange or Jenkins server through some form of intelligent access control can stop threat actors from reaching resources directly. I am partial to Zero Trust Network Access (ZTNA) approaches that limit who can send malicious payloads targeted at the vulnerable systems. Obviously, this doesn’t remove the vulnerability, but restricting access to a potentially vulnerable server through ZTNA can stop any malicious actors from reaching it directly.

If external actors can’t reach a vulnerable system directly, they need to redirect their efforts to reaching it through impersonating an actual end user, which becomes increasingly difficult with the use of contextual, adaptive, and identity aware access controls, such as ZTNA reinforced with FIDO2-compliant multi-factor authentication. Combine those access controls with an inline WAF and a positive picture emerges. Control who has access and inspect traffic flows for anything malicious, even for users who have control.

The bottom line: Both of these incidents highlight the need to move to a zero trust-based security model.

If you are interested in learning more, I suggest you start with Akamai Secure Access Service Edge and our Enterprise Defender solution, which combines ZTNA, Secure Web Gateway, Web Application Firewall, and application acceleration as one simple-to-consume security service delivered at the Akamai edge.

Isn’t it time to effectively isolate apps and APIs from the internet?