As it looks at (yep, more) reported vulnerabilities in Microsoft Exchange Server that affect the software’s 2013, 2016, and 2019 editions, Microsoft has released some consumer guidance. According to the business, “few targeted assaults employing the two vulnerabilities to access users’ computers” have been reported. The decision was made in response to an internet debate over whether two new Exchange zero-day vulnerabilities were actually brand-new flaws or merely updated exploits for previously known flaws.
So let’s begin with the most crucial section: What should you do if you have been given the responsibility of managing an Exchange Server? Microsoft is attempting to expedite the distribution of a remedy. In the interim, it offers advice on detection and mitigation:
Customers of Microsoft Exchange Online do not need to take any action.
To prevent known attack patterns, users of the on-premises product should apply a blocking rule in IIS Manager. Microsoft claims that the URL Rewrite instructions below, which are now the subject of public discussion, are effective in dismantling current attack chains:
- Open the IIS Manager.
- Expand the Default Web Site.
- Select Autodiscover.
- In the Feature View, click URL Rewrite.
- In the Actions pane on the right-hand side, click Add Rules.
- Select Request Blocking and click OK.
- Add String .*autodiscover\.json.*\@.*Powershell.* and click OK.
- Click Edit under Conditions after expanding the rule and choosing the rule with the Pattern.*autodiscover.json.*@.*Powershell.*.
- Replace the word “URL” with “REQUEST URI” in the condition input.
On the Microsoft site, you may get screenshots of the aforementioned instructions. In addition, it states that if the URL Rewrite module is implemented as advised, there is no known effect on Exchange functionality.
Another solution is to restrict HTTP: 5985 and HTTPS: 5986, which are used for Remote PowerShell.
The vulnerabilities
While providing security monitoring and incident response services, GTSC found the vulnerabilities. It was possible to determine that the assaults relied on requests for exploits that had the same structure as ProxyShell. But even the patches that disable ProxyShell were present on the servers that were being targeted.
Web shells, a script that allows an attacker to conduct remote commands and keep persistent access on a computer that has already been hacked, were dropped on the Exchange servers as a result of the attacks.
Many Exchange servers have been backdoored, according to security expert Kevin Beaumont. However, he adds that this is not rare because ProxyShell is not patched and users wind up using outdated Content Updates as a result of the patching process being such a mess.
On his blog post on the issue, he makes the point that those who do not use Outlook Web App (OWA) or Microsoft Exchange. Their on-premises are also unaffected. Microsoft adds that in order to take advantage of either of the two vulnerabilities related to these attacks. Attackers need to have authorized access to the affected Exchange Server.
The following vulnerabilities are linked together:
SSRF (Server-Side Request Forgery) vulnerability CVE-2022-41040. A web security flaw called SSRF enables an attacker to force a server-side application to send requests to other services located inside the infrastructure of a company.
CVE-2022-41082, a flaw that enables remote code execution (RCE) when an attacker has access to PowerShell.
