In recent days, two zero-day vulnerabilities against Microsoft on-premises Exchange Servers have been publicized and attacked. The good news is Exchange Cloud users, such as Microsoft 365 customers, need not worry, as these exploits are only against on-premises versions.
While working on the full answer, Microsoft is offering some early repairs, including only allowing administrators to remotely access PowerShell and creating a URL rewrite block rule on the Exchange server.
LoadMaster load balancers help on both accounts. On the URL rewrite front, LoadMaster performs quickly and easily. I’ll detail exactly how later in the blog.
These exploits also rely on hackers gaining authenticated access to Exchange servers, which can be thwarted with strong and easily managed two-factor or multi-factor authentication. Again, more on this in a bit.
Not surprisingly, Microsoft strongly recommends moving from on-premises Exchange to the cloud, though this is not a timely fix to the new zero-day exploits.
Now, I want to dive into the details of the exploits.
“Microsoft is aware of using two reported zero-day vulnerabilities affecting Microsoft Exchange Server 2013, Exchange Server 2016, and Exchange Server 2019. The first one, identified as CVE-2022-41040, is a server-side request forgery (SSRF) vulnerability, while the second one, identified as CVE-2022-41082, allows remote code execution (RCE) when Exchange PowerShell is accessible to the attacker. Refer to the Microsoft Security Response Center blog for the mitigation guidance,” a Microsoft blog said. “CVE-2022-41040 can enable an authenticated attacker to remotely trigger CVE-2022-41082. However, authenticated access to the vulnerable Exchange Server is necessary to successfully exploit either vulnerability, and they can be used separately.”
Microsoft has tracked these exploits since August and “observed activity related to a single activity group in August 2022 that achieved initial access and compromised Exchange servers by chaining CVE-2022-41040 and CVE-2022-41082 in a small number of targeted attacks,” Microsoft said. “These attacks installed the Chopper web shell to facilitate hands-on keyboard access, which the attackers used to perform Active Directory reconnaissance and data exfiltration.”
Microsoft has “medium confidence” that the single activity group is likely to be a state-sponsored organization.
Exploits explode once there is public disclosure — and that is what happened after Sept. 28 when GTSC published a blog breaking news of the exploit. “It is expected that similar threats and overall exploitation of these vulnerabilities will increase, as security researchers and cybercriminals adopt the published research into their toolkits and proof of concept codes become available,” Microsoft cautioned.
Once a vulnerability is disclosed, attacks are no longer zero-day. Once patches and/or updates are released to close the hole, attacks generally increase and become more dangerous. The public disclosure and the patches or updates create a blueprint for cybercriminals who spring into action exploiting the vulnerabilities. Often, attacks are shared and even sold as services, so even the most amateur hackers can go after networks. That is why it is vital to patch or update systems once security fixes are available.
Elevation of privilege attacks allow hackers to gain access to the deepest reaches of the network. One shortcut is to take over the admin accounts themselves, often through phishing. For example, an IT admin may get an email tricking them into disclosing their credentials.
In other cases, IT admin accounts are all too easy to crack given that far too few use multi-factor authentication tools, or MFA. In fact, Microsoft surveyed attendees at its Ignite conference and found, quite shockingly, that fewer than 2% off all Office 365 global admins have MFA enabled. Results of a survey by CoreView were better, but far from great — 78% of Office 365 admins do not have MFA activated.
Yes, this does sound quite ridiculous, but admins often have many, many accounts and that extra login step is in fact a nuisance. But is it as bad of a nuisance as having a hacker steal privileges and put your very enterprise at risk? You decide.
While these are cloud examples, one can assume MFA and excess privilege are just as bad on-premises.
We see how phishing can compromise admin accounts. This is if not one justification for two-factor authentication — whether using a one-time password token or SMS. You could consider using a two-step verification service, such as Microsoft Authenticator. Using two-factor authentication is effective against bots, as they won’t be able to satisfy the secondary challenge. LoadMaster has native support for all major two-factor authentication providers, making integration simple. And, if you need, you may also further lock down access by enforcing the use of client certificates on client devices.
Earlier, I mentioned how these attacks rely on hackers hijacking admin privileges. This is precisely what Zero Trust and least privilege access aim to prevent.
Zero Trust Network Access, or ZTNA, is an approach to application and resource access that trusts no client entity and only grants access when explicitly defined by policies. Zero Trust never implicitly trusts and only grants access after the client has successfully authenticated. Access to resources is explicit in the policy, which prevents users from stepping outside their permitted access.
Zero Trust starts by considering the identity of the client and the context of the access request, such as what device or network a user is coming from. It asks questions like: Is it from a corporate managed device? Are they working from home? Are they in a third country?
Once authenticated, clients are then authorized based on the policy with just enough access to allow them to connect to the resources. LoadMaster can act as a ZTNA gateway with easy definition of policies via an API, simplifying the integration with other security and policy tool sets.
LoadMaster can add significantly to an organization’s cloud security as an integrated security enforcement point. LoadMaster augments cloud platform security services to deliver a multi-layered approach to application security and availability. LoadMaster is available on all major cloud platforms and also as a virtual appliance if you want to do an on-premises deployment.
Another on-premises Exchange security measure is to stop relying on SSL, seen by many as a legacy cryptographic security protocol — at least for Exchange — and move to TLS 1.3. “TLS 1.3 eliminates obsolete cryptographic algorithms, enhances security over older versions, and aims to encrypt as much of the handshake as possible,” Microsoft stated in its Exchange Server Roadmap update.
Do note that while TLS 1.3 does not stop these Exchange exploits, it is an important overall security step for Exchange servers.
LoadMaster speeds the URL rewrite. While Microsoft offers instructions in its Customer Guidance for Reported Zero-Day Vulnerabilities in Microsoft Exchange Server, we believe we have a better way.
Microsoft has provided some mitigations. It involves creating a URL rewrite block rule on the Exchange server via IIS Manager under the Autodiscover virtual directory to block the specific PowerShell URL syntax used for gaining remote access over Autodiscover. This can also be achieve on LoadMaster. The URL rewrite block rule can be created as a content rule on the LoadMaster and applied to the Autodiscover sub virtual service. Here are some steps to achieve this on LoadMaster: