Updated: 13 January 2021 at 16:47 UTC
‘Not all code execution bugs in .net are deserialization related’
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 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.
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 list”, Seeley then bypassed the second patch with call operators that circumvented a mode and fulfilled six checks performed by a call to 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.
‘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’.”
The Daily Swig has contacted Microsoft for comment, including on when the final security patch might arrive. We will update the article as and when we hear back.
YOU MAY ALSO LIKE GitLab addresses numerous vulnerabilities in latest security release
Source: The Daily Swig