‘Not all code execution bugs in .net are deserialization related’
UPDATED A remote code execution (RCE) vulnerability in Microsoft Exchange Online remains unresolved after security researchers bypassed two patches for successive exploits.
Rated as critical, the zero-day flaw impacts multiple Software as a Service (SaaS) providers as well as on-premise installations of Exchange Server.
The bug in Exchange Online, part of the Office 365 suite, could be exploited to gain “access to millions of corporate email accounts”, said Steven Seeley of the Qihoo 360 Vulcan Team in a blog post published yesterday (January 12).
Office 365’s user base is burgeoning along with demand for cloud deployments more generally, reaching 200 million active users by the end of 2019.
Seeley said he was motivated to probe the environment for RCEs given that six other such bugs in Microsoft Exchange Server had emerged in the last two years, most notably CVE-2020-0688 and CVE-2019-1373, the latter prompting him to “focus on the powershell remoting interface”.
That the vulnerabilities were all authenticated did not diminish the severity “since a malicious tenant can be created with ease and the necessary permissions applied” – a “fundamental” yet often “overlooked” difference between targeting cloud-based versus on-premise environments, said Seeley.
Microsoft assigned the initial flaw (CVE-2020-16875) as a high-risk classification (CVSS 8.4), though marked it as having a low attack complexity.
As per the security advisory, the vulnerability was found within the New-DlpPolicy cmdlet and arose from improper “validation of user-supplied template data when creating a dlp policy”.
Seeley triggered the flaw via both the ecp and powershell interface.
To his surprise, targeting outlook.office365.com and outlook.office.com servers proved that he could “execute commands as SYSTEM on Microsoft’s cloud and exfiltrate sensitive data over http without being caught”.
He added: “Using your own zero-day found in Microsoft’s own code to attack their cloud servers is quite satisfying!”
Triple smart bypass
There were two ways to bypass Microsoft’s first patch, resulting in CVE-2020-171324 with a CVSS of 9.1.
Seeley, a 2020 Master of Pwn, bypassed the fix, which addressed the bug in DlpPolicyTemplateMetaData.ValidateCmdletParameters, with powershell call operators, using the ‘&’ symbol to call powershell cmdlets.
Another team of researchers – Leonard Rapp, Markus Vervier, and Yasar Klawohn – independently discovered that the patch failed to block execution of inline code in the powershell console.
“After looping through the cmdlet list”, Seeley then bypassed the second patch with call operators that circumvented a RestrictedLanguage mode runspace and fulfilled six checks performed by a call to CmdletValidator.ValidateCmdlet that were designed to thwart an attack.
Microsoft rewarded Seeley “handsomely” for his findings under their Online Services Bounty Program, which pays up to $20,000 for critical RCE flaws.
The researcher sent his initial report to Microsoft on May 22, and a security advisory was released on September 8.
The final bypass was reported on December 9, one day after Microsoft’s monthly Patch Tuesday. With a final patch yet to (hopefully) land, there remains “no mitigation against this attack”, warned Seeley.
A spokesperson for Microsoft told The Daily Swig: “We are aware of the report and will take necessary steps to keep our customers safe.”
They also suggested that the risk is somewhat mitigated because “the technique described requires an attacker to have already compromised a target machine and have permission to run malicious code”.
However, Markus Vervier, who found one of the bypasses for the first patch, told The Daily Swig, that this was not accurate.
“The vulnerability can be exploited by accounts having Data Loss Prevention (DLP) rights. This does NOT mean an an attacker is able to run malicious code on the system and we cannot confirm the statement made by Microsoft.
“The vulnerability allows privilege escalation to SYSTEM on the on-prem versions of Exchange. Additionally, the vulnerability allowed a compromise of Exchange Online from a testing organization. X41 could confirm within the limits of the bug bounty program that access to infrastructure and data was possible.”
Microsoft later responded: “The technique described has already been mitigated in Exchange Online. For the on premise version of Exchange Server, the attacker would need administrative permissions to leverage the vulnerability.”
‘Single point of failure’
“Is relying on a cloud providers with a single point of failure system the right approach?” asked the researcher.
With relatively new technologies “it’s always wise to re-evaluate the threat landscape”, he added. Attackers may “have more access than you initially thought”.
Addressing security researchers, Seeley said: “Not all code execution bugs in .net are deserialization related. It’s easy to fall into the tunnel vision trap so it’s important to remember not to ‘follow the crowd’.”
This article was updated on January 14 with comments from Microsoft. It was then updated later on the same day with a further response from Markus Vervier. A third change was made on January 16 setting out Microsoft's subsequent response
YOU MAY ALSO LIKE GitLab addresses numerous vulnerabilities in latest security release