Following the disclosure of the two zero-day security vulnerabilities in Microsoft Exchange, the Redmond firm has posted 2 mitigation measures so that companies can protect themselves while waiting for a security patch. Problem, security researchers have managed to bypass these preventive measures. Let’s do a check in.
Since Friday, September 30, 2022, security breaches CVE-2022-41040 et CVE-2022-41082 are talking a lot about them, and obviously, it is not ready to stop with this new twist. As a reminder, it is the company GTSC which is at the origin of the discovery of these vulnerabilities reported to Microsoft through the Zero Day Initiative. All versions of Exchange 2013, Exchange 2016, and Exchange 2019 are affected, whether on-premise or hybrid mode instances connected to Exchange Online (in case the on-premise Exchange server is exposed on the Internet).
Following the publication of a report about these security vulnerabilities, Microsoft reacted by confirming that they were used in a few attacks. Then, the American company shared temporary solutions to be applied to limit the risk of exploitation of these vulnerabilities.
First, it should be block access to ports 5985 and 5986 associated with remote management via PowerShell (WinRM connection). Second, there is a rule to create in the IIS configuration to block certain malicious requests (more details here). This can be deployed using the official script EOMTv2.
IIS: an insufficient rule
Security researcher Jang says this rule in IIS is too limited and after some effort, he managed to bypass the rule in order to exploit these vulnerabilities. For his part, Will Dormann, analyst at ANALYGENCE, agrees with Jang and he asserts that the “@” in the URL provided by Microsoft “seems unnecessarily precise, and therefore insufficient.“. To validate the work of Jang, it was the security researchers at GTSC, at the origin of the discovery of these vulnerabilities, who validated that the protection was not sufficient.
For the rule to be able to block more malicious requests, it needs to be a bit less precise. Jang suggests using this URL value in the IIS rule instead:
If you have implemented the rule in IIS, all you have to do is adapt your configuration. Microsoft has not confirmed at this time that the rule should be adjusted in IIS, and a fix is still pending.
To be continued in the next episode…
Logiciel – OS,Sécurité,Exchange,Microsoft,
#IIS #rule #insufficient