How It Took Two Years to Resolve Remote Code Execution Vulnerability CVE-2020-17091

Microsoft Teams vulnerability exposed serious risk to the software supply chain

In two previous blog posts, I explained a newly discovered vulnerability type called dependency confusion and reported what happened when I uncovered the vulnerability in the Microsoft Teams desktop application. In those two posts, I noted that I had previously identified remote code execution (RCE) vulnerabilities in the same application, so I thought I would tell the story of one such discovery—especially since it was resolved recently (finally). It is a good illustration of the process that security researchers face when they discover and report a vulnerability.

This kind of security research is an integral part of what the Contrast Labs team does, and it is important work. Security researchers are vastly outnumbered by cyber criminals, and they do much of their work on their own time. Most of us have “day jobs” that include many other responsibilities. In fact, the entire Common Vulnerabilities and Exposures (CVE) database, which contains upwards of 100,000 vulnerabilities, is probably a small fraction of vulnerabilities that actually exist in open-source libraries. The human energy devoted to discovering them is simply inadequate to the task.

REMOTE CODE EXECUTION: RISKING A CATASTROPHE

First, a bit of background on remote code execution. RCE vulnerabilities can be extremely dangerous to an organization, as they can enable an attacker to do anything that a logged-in user can do in an account. Imagine the impact that could have in a business-critical application used to manage sensitive data. Malicious actors could access confidential customer data (financial, personal, or health information), employee data (personal or HR information), or intellectual property (product development data and go-to-market plans).

RCE vulnerabilities often attract attention in the press when they are discovered, and fixing them is often urgent. A serious RCE vulnerability was recently identified (and fixed) in the SolarWinds Orion platform, which is still reeling from the massive attack that was revealed last December.

RCE IN THE MICROSOFT TEAMS DESKTOP APPLICATION

As I pointed out in my last blog post, Microsoft Teams has become a business-critical application at a growing number of organizations, a trend that accelerated over the past year due to the COVID-19 pandemic. Notably, Microsoft Teams saw an 894% growth in usage between March and June 2020—a bigger growth rate than that of Zoom during the same time frame. In December, Microsoft announced Teams had reached 115 million daily average users. And as every Teams user knows, Microsoft heavily promotes the use of the Teams desktop application. Anyone who logs into the web interface sees multiple promotions for downloading the application.

The Teams desktop application is built on the Electron framework, one of my areas of specialty security research. Because of its architecture, the way Teams integrates with other collaboration tools (like chat platforms, for instance) is through plug-ins. This enables much deeper and richer integrations than, say, the superficial integrations found in Slack. In a nutshell, the plug-ins embed an external website into the Teams application and place it on a tab that is easily accessible by the user.

It was through one of these plug-ins that I was able to exploit a specific functionality in Electron—a sandbox known as “context-isolation.” This feature was enabled for the actual plug-in rendering section of the application. However, I realized that I could use a feature in the plug-in API to open a new “Authentication” window with my own URL where this security feature was not enabled. Without context-isolation, the externally controlled application and the internal Electron share an object space. This gives the external code the ability to execute in the privileged (node) environment instead of the much more restrictive browser-based environment. The proof of concept (POC) for this exploit can be found at this gist.

With default permissions, I could not add a plug-in to a general or group room, but I was able to add one to any room that I own. Then, I was able to invite anyone to that room. Specifically, for anyone who joined the room and clicked on the tab, I could run code on the computer and take it over their account. Further, it was an infinite process; I could continue inviting anyone in the company to the room.

If an attacker exploited this vulnerability, they could potentially get into a corporate network by inviting employees from that company to a Teams channel. And as any user of Teams knows, it is very easy to click on such an invitation just to investigate what the message says.

Proof of concept for Microsoft Teams RCE vulnerability.

As a disclaimer, I wrote and tested this payload in MacOS, but a similar attack could be carried out via Microsoft Windows. The execution happens in the internal node process and can branch off any process or read and edit any file to which the current user has access.  

AN EXTENDED BACK-AND-FORTH

I reported this vulnerability to the Microsoft Security Response Center (MSRC) on September 1, 2018. Below are some highlights of the history since then. Each time there is a deployment process for a bug fix, there is a three-month turnaround for development and testing. In two instances, I found that the fix prepared by Microsoft did not work, which lengthened the process significantly.

→ Sep 01, 2018 – Reported to MSRC.
→ Nov 27, 2018 – Request for update; BBP questions.
← Dec 03, 2018 – Response: We will get back to you.
→ Mar 25, 2019 – Request for update.
← Mar 25, 2019 – All Desktop apps excluded from BBP. No issue update.
← Apr 16, 2019 – Rolling out fix, request for reproduction.
→ May 06, 2019 – Still reproducible; suggested fix not in place.
← May 07, 2019 – Response: Suggested fix not being used; it would break too much.
← Jun 19, 2019 – The patch was a “progressive” rollout and only went to 10% of users.
→ Jun 20, 2019 – Reversed the feature flag enableRemoteModuleFilteringV5 out and sent update confirming that this would not fix the issue.
← Jun 20, 2019 – MSRC confirms and will pass the info along.
→ Jul 18 2019 – New version and electron update breaks exact POC. Warned of incomplete fix. Request coordinated disclosure.
→ Aug 02 2019 – New POC sent.
← Aug 15, 2019 – Response: They are working on a “more comprehensive fix.”
→ Aug 27 2019 – Some changes to remote—require break POC, new POC sent.
→ Oct 14, 2019 – Request for update.
← Nov 21, 2019 – MSRC back and forth about the correct version. Ended up not being in the correct “ring” for me to download. MSRC eventually schedules a call.
→ Dec 10, 2019 – Call with MSRC about the issues.
← Jan 31, 2020 – MSRC communicates that the fix is part of a larger fix, which includes updating the core electron version.
← Oct 27, 2020 – MSRC sends an update that this will be given CVE-2020-17091.
← Nov 16, 2020 – MSRC states they have fully rolled out a fix for this vulnerability, and added to the acknowledgments page.

This vulnerability was finally registered in January of this year as CVE-2020-17091. The patch that addresses this vulnerability was included in an auto update in conjunction with the release of the CVE. As a result, users of the Microsoft Teams desktop application should ensure that all updates have been successfully installed.

A NOTE ABOUT BUG BOUNTIES

For those who actively participate in bug bounty programs—or are interested in doing so—I should mention one thing. Despite the fact that Microsoft has long offered a bug bounty program for Office 365, the Teams desktop application is explicitly excluded from the program. I have no idea why this exclusion exists, but it is interesting that the desktop application for Microsoft Yammer—also based on the Electron platform—is also excluded. 

I continue to do research on this application despite the lack of a bug bounty, because it is an area of specialty for me and my main motivation is to contribute to the greater good. However, researchers who want (or even need) to be compensated for their work would always have the option to report a vulnerability to a third party or in a bug bounty competition. Incidentally, the Pwn2Own 2021 competition included a vulnerability that had been discovered in Microsoft Teams.

PROTECTING THE SOFTWARE SUPPLY CHAIN

Because of an elongated process and two patches that turned out to be ineffective, this specific RCE vulnerability remained in the Microsoft Teams desktop application for more than two years after I discovered it. It was not publicized, and no bad actor exploited that vulnerability to my knowledge. But this is a risk few want to take. If I was able to discover this vulnerability, any number of cyber criminals could have discovered it just as easily. In doing so, an attacker could have caused significant damage at one or more Teams customer sites.

It is another reminder that every organization needs to think of the entire software supply chain when considering application security:

• What you write: Custom code developed in-house accounts for most software vulnerabilities.
• What you build with: Organizations often do not track which developer tools are in use, and more than 1,000 of them exist.
• What you use: Third-party libraries create a complex web of dependencies in an application.
• What you buy: Off-the-shelf Software-as-a-Service (SaaS) applications provide business-critical functionality, but their users have no control over the integrity of the software.

Just as the dependency confusion vulnerability did earlier this year, this vulnerability further accentuates the risk posed by the software supply chain. Organizations must heed the risk posed by all the software they use, whether internally developed or purchased. Further, the risk is not simply to one organization or application. In the case of RCE, the risk could literally expose thousands of companies and tens of millions of users.

For more detail on this RCE vulnerability in Microsoft Teams, you can listen to my Inside AppSec Podcast interview (“CVE-2020-17091: Remote Code Execution Vulnerability in Microsoft Teams Found by Contrast Labs”).