Microsoft Exchange and Verkada Hacks: Isolate Your Apps and APIs from the Internet Cesspool
March kicked off with multiple zero-day exploits 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 breached the internal systems of the Silicon Valley security firm Verkada -- a breach that garnered widespread attention as it 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 impacted firms -- brought to mind what we as an industry have been talking about for a while: the perimeter defenses of moats and castles belong in the past. These recent breaches are evidence that moving to a Zero Trust security model with 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.
The Exchange breach
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. While this does not replace patching in the long run, it 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 2016 Gartner report, "It's Time to Isolate Your Services From the Internet Cesspool," which provides guidance on that front. The answer is clear: 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.
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 -- an increasingly difficult feat with the use of contextual, adaptive, and identity-aware access controls, such as ZTNA reinforced with FIDO2-compliant multi-factor authentication (MFA). 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 solution
The bottom line: both of these incidents highlight the need to move to a zero trust-based security model. It’s time to effectively isolate apps and APIs from the internet.
If you are interested in learning more, check out Akamai’s Secure Access Service Edge and Enterprise Defender solutions, which combine ZTNA, Secure Web Gateway, Web Application Firewall, and application acceleration as one simple-to-consume security service delivered at the Akamai edge.
