Just when you thought that your week of weekend SecOps downtime would be productive and stress-free…
…and along comes a brand new zero-day hole in Microsoft Exchange! Big love to the Microsoft security team.
A two zero-days were discovered that can apparently be chained together. The first one allowed remote code execution to occur on the Exchange server, which could allow remote code execution to occur on Microsoft’s servers.
Microsoft quickly published an official statement on the situation. They summarized it as following:
Microsoft is investigating two reported zero-day vulnerabilities affecting Microsoft Exchange Server 2013, 2016, and 2019. The first vulnerability, identified as CVE-2022-41040, is a Server-Side Request Forgery (SSRF) vulnerability. The second vulnerability, identified as CVE-2022-41082, allows remote code execution (RCE) when PowerShell is accessible to the attacker.
Microsoft has been made aware of attacks that target the two vulnerabilities, which can enable an authenticated attacker to remotely trigger either vulnerability. The exploit to each vulnerability requires authenticated access to an Exchange Server, so you’ll need a user with permissions to see it if you want them exploited.
There are certain security vulnerabilities which are unique to Exchange Server. These vulnerabilities can only be exploited if the attacker has remote access to an account and exploits corresponding execution bugs. However, just having your server accessible to remote users is not enough to directly expose you to attack, because it cannot be done without authentication.
Think an attacker is taking advantage of a vulnerability to gain access to your server or work environment? Blocking PowerShell Remoting on your Exchange Server’s TCP ports 5985 and 5986 limits their ability even further. Not only can it hinder attackers, but if they’re using PowerShell execution as part of the attack, you’re more likely to learn about that as well.
Though this particular scenario has been closed, a number of other attack vectors remain. To reduce risk to your clients, Microsoft has released new security recommendations on how to exit the attack vector. They recommend that you “disable remote PowerShell access for non-admin users”.
