As a new security researcher, submitting my first valid vulnerability to Microsoft was an exciting experience that gave me a chance to take a deeper look into securing Electron applications. The opportunity provided me with valuable lessons that I want to share with other aspiring researchers that want to explore similar research.
There recently has been a lot of discussion around gaining initial access to Microsoft Teams, however I wanted to move past this and discuss how attackers can expand across the network once access has been gained. In this blog post, I will discuss how insecure Electron configurations can be used to bypass security measures to achieve malicious file delivery. Additionally, I want to highlight the dangers that custom protocol handler infections can present to your users and network, especially if you use Electron based applications that have not been hardened against these types of attacks.
TLDR
I was able to identify an issue in the online/desktop client instance of Microsoft Teams where a URL field did not enforce the use of https. This type of unrestricted input can lead to XML injection causing unexpected redirects in the Microsoft Teams desktop client. Further research into the Microsoft Teams desktop client revealed security bypass vulnerabilities that could be used to deliver malicious files to users that would otherwise be blocked.
The search-ms:// protocol handler was recently highlighted again to show the dangers that it can present to users. I wanted to expand my knowledge around how this OS native handler could be used to identify other attack vectors that could then be escalated by using custom protocol handlers.
If attackers use this opportunity to present a payload that infects the user with a custom protocol handler, then this can lead to attackers reestablishing persistence or taking other local actions (with user interaction) at a later time. The injection point was fixed by Microsoft (medium severity XML injection) and protocol handler restrictions were added to the desktop client; however, the Microsoft Teams desktop client remains vulnerable to malicious file delivery through HTML smuggling.
Overview of the initial vulnerability
As remote work and hybrid models become the norm, Microsoft Teams has become a go-to choice for organizations worldwide. With its many features, including the ability to collaborate, chat, and share documents, Microsoft Teams has enabled companies to maintain their productivity and communication. However, as with any software, the application also provides a potential escalation point for cyber attacks.
The Viva Connections hub is one of the many applications within Microsoft Teams that companies use to interact with their users and provide company insights. Viva Connections integrates with SharePoint and provides a dashboard for users to access company news, events, and other relevant information.
Viva Connections is a customizable app in Microsoft Teams that gives different audiences in your organization a personalized destination to discover other Viva apps your organization is licensed for, relevant news, conversations, and the tools they need to succeed.
https://learn.microsoft.com/en-us/viva/connections/viva-connections-overview
The Viva Connections application offers the option to establish links to other internal Viva applications. Alternatively, administrators may create custom web cards that can link to external resources. While Microsoft Teams does its best to enforce HTTPS connections for all URL input fields, this restriction was inadvertently missed for Viva Connections web cards and other parts within the desktop application. Consequently, any link could potentially be utilized, even if the protocol handler is modified to use less secure redirects similar to FTP, SMB, and so forth. If the link is clicked by a user, then the expected functionality is that the default application for that protocol would launch. While this requires administrative permission for Viva Connections cards, the additional injection points that were found later do not.
Fortunately, modern browsers prompt users with a warning message prior to launching external applications. However, not all applications process protocol handlers the same way, as is the case with the Electron-based Microsoft Teams application.
A closer look at protocol handlers
Most of us aren’t too familiar with protocol handlers and that’s ok because most of the process happens in the background. Most internet users will be familiar with common protocol handlers like http(s):// and mailto://, but there is actually a wide variety of these handlers that are available. Custom protocol handlers are essentially shortcuts that allow a web application to communicate with another application on a user’s device. For example, if a user clicks on a link that has the email protocol handler mailto: in it, then it will open their email application and start composing a new email. Windows users can specify which application they would like to use based on the protocol by adjusting the setting within the operating system.
Native and custom protocol handlers are set within the registry and will point towards a specific executable file that will be called when the protocol handler is invoked. If you’re curious about all of the available protocol handlers that are on your system, then you would want to look in your registry under HKEY_CLASSES_ROOT. The executable that is being called can then be found under shell > open > command.
A great example of a custom protocol handler that’s installed by a program is the ms-teams:// handler. If we test the ms-teams:// protocol handler in Microsoft edge, then we can confirm that it launches the Microsoft Teams application once it’s invoked.
Protocol handlers also allow us to add specific parameters to them to customize the action that the link will take. Unfortunately, custom protocol handlers can sometimes be used to launch applications that have known vulnerabilities or weaknesses. For example, if a user clicks on a link that launches a vulnerable application, it can be exploited by an attacker to gain access to the user’s device or network.
One example of protocol handlers that could be used for malicious actions is the popular WinSCP clients protocol sftp:// handler, which could be used to open local files. If the user has the vulnerable version of WinSCP installed and has the application set as their default handler for the sftp protocol, then this can trigger the opening of local files or other malicious actions when the link is clicked (CVE-2021-3331).
Luckily there is still a warning in modern web browsers (most of the time), so that users can opt out of the malicious action before anything happens. If the same vulnerability is introduced in another application framework though, then things can get a bit more dangerous.
The Electron framework functions to watch out for
When it comes to desktop application development, there are several frameworks available. However, one of the most popular in recent times is the Electron framework. The Electron Framework is an open-source framework that lets developers create cross-platform desktop applications using web technologies. It was initially developed by GitHub and is currently maintained by both GitHub and a community of developers. Electron is built on top of Node.js and Chromium, which means that developers can use JavaScript, HTML, and CSS to create desktop applications. Electron developers can also create cross-platform applications for Windows, macOS, and Linux using a single codebase. This reduces the development cost and time, making it economical for both developers and businesses.
If you’re curious about some of the applications that have been built using the Electron framework, then you can check out the Electron showcase page at https://www.electronjs.org/apps
Despite its benefits, there are some concerns about the use of the Electron framework, especially when it comes to creating large applications. The Electron framework uses the Chromium browser for rendering its applications. This results in large file sizes and high memory usage, resulting in slow application performance. Large applications built using Electron can take up a significant amount of system resources, affecting other applications and leading to a potentially poor user experience.
Additionally, since Electron is based on web technologies, it’s susceptible to web-based attacks such as cross-site scripting (XSS) and cross-site request forgery (CSRF). Developers need to be vigilant in keeping their applications secure and up-to-date to prevent security breaches, especially when using some of the internal Electron functions.
One of those functions is shell.openExternal, which provides developers with the option to add deep linking to their application. Shell.openExternal is a function in Electron that enables applications to open URLs or files using the default browser or application. It is commonly used in many applications to allow users to access external links. However, this function can pose a significant threat to security. Hackers can exploit vulnerabilities in this function or inject malicious code through links that the application opens, leading to potential security breaches.
There have been numerous shell.openExternal CVE’s in the past years where applications were vulnerable due to the input fields allowing arbitrary URL’s that could lead to malicious actions:
CVE-2020-25019 – Jitsi-Meet-Electron
CVE-2022-44567 – Rocket.Chat shell.openExternal
CVE-2020-15258 – Wire shell.openExternal
The Electron developers have also released a security advisory for shell.openExternal to inform the public about the dangers of allowing unfiltered content to be used with shell.openExternal.
How do you identify vulnerabilities within Electron applications?
There are specific security issues that are common in Electron framework applications that you will need to be aware of before trying to audit these kinds of applications. Some of these issues include Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), SQL Injection, and Remote Code Execution (RCE).
Before getting started with analyzing Electron based applications you will need to understand what an ASAR file is (Asar stands for “Atom-shell archive.”). To put it simply, an asar file is a compressed, single-file archive that contains all the files in an Electron Framework application. This includes everything from the HTML, CSS, and JavaScript files, along with any assets or binaries that the app uses. An asar file can be considered a packaged version of the app that developers can distribute to users.
If we take the time to unpackage the asar file and enumerate internal files, then it can provide us with some very valuable information. One of those examples would be identifying explicit allow lists that have been added to functions that can help us with circumventing protocol handler restrictions.
Another great option for enumerating Electron based applications is Electronegativity, which can be used to analyze the locally installed instance of the application.
Software developers and security auditors can use this tool to detect and mitigate potential weaknesses and implementation bugs when reviewing Electron based applications. A good understanding of Electron security is still required when using Electronegativity, as some of the potential issues detected by the tool require manual investigation.
The tool does a fantastic job when it comes to identifying some of the more common vulnerabilities, especially when attempting to identify the use of shell.openExternal and custom protocol handlers, which are discussed further into this article.
Malicious File Delivery Method 1: Using shell.openExternal with native protocols for malicious file delivery
One of the biggest dangers when using shell.openExternal is that it does not support native security features present in modern browsers. Applications with this function enabled will not benefit from the browser’s security features such as restrictions and warning messages that prevent access to pages with insecure application links.
A recent example of a Microsoft native protocol handler that can be abused is the search-ms:// (or just search://) protocol handler. Further research into the search-ms:// protocol handler shows that this has been known as early as 2020, when security researchers Benjamin Altpeter published papers regarding the dangers of some of these protocol handlers.
The research shows that if the protocol handler is invoked from the Microsoft Teams application, then the Windows file explorer application will launch and retrieve files that would’ve otherwise been blocked by security features. Additionally, the protocol handler can be used to establish a connection to internal or external SMB shares, which can enable attackers to present their own malicious files through publicly available attack infrastructure.
This type of file delivery can also result in social engineering and other bypass opportunities because the title of the window can be changed with the displayName parameter through the protocol handler link.
Other security researchers have also revealed that specific executable file types like jar files can be used to bypass Windows defender prompts and retrieve/execute externally hosted PowerShell scripts. While this requires that the user has the prerequisites installed to run these types of file types, it’s important to realize that common protections can be bypassed.
Malicious File Delivery Method 2: HTML Smuggling through website tabs
While testing the Microsoft Teams desktop client further for injection vulnerabilities, I noticed that the application allows the inclusion of external websites throughout various functions. Some of those functions would pull the external page into the desktop client frame, which made the navigation a bit more flawless. Unfortunately, I found that the Microsoft Teams desktop client will attempt to execute scripts that are on pages before the rest of the content is loaded.
In the Electron based Microsoft Teams client that would mean that malicious users can add website tabs to different parts of the application (without requiring admin permissions), which would then execute our payload as soon as the user navigates to it. Microsoft Teams also has a feature that will automatically post an announcement to channels and private messages, which can then be used to make our message more visible, so that it can be used as a jumping point to get users to click on the website tab link.
Some users may argue that XSS alert messages are not too dangerous, but in this case, they can give an interesting insight into where the payload is executed. When the XSS payload is executed from the Teams web instance, then the expected XSS alert will mention that an embedded page is attempting to execute the payload. If a Microsoft trusted page or function (like the web tab announcement message) is used first, then the Microsoft Teams desktop client will execute the payload before loading the rest of the page.
From an attackers perspective that is an important piece of information, because it can give an indication that the behavior can be escalated into other unintended actions. The Microsoft Security Response Center previously released an article regarding some of those actions, which discusses the dangers of malware delivery through html smuggling. If you’re unfamiliar with this topic, then I highly recommend that you check out the MSRC blog post to learn how ATP’s use this evasive technique to deliver malware.
HTML smuggling can be summarized as a technique where malicious actors hide base64 encoded executables in a websites code, which will then be reassembled by browsers at a later time to bypass security filtering like firewalls.
I was able to identify that the same HTML smuggling technique mentioned by the article was a viable option to deliver malicious payloads through the Microsoft Teams desktop client. Usually, if an internal user sends an attachment that is detected as malicious, then users are protected through browsers prompts to verify that they want to fully download the file.
If that prompt option is not available (like in the Electron based desktop client), then the download request will simply be refused without any direct indication to the user. Due to the MS Teams unrestricted external loading behavior that the client provides, this restriction can be bypassed by presenting an HTML smuggling file that gets executed by the desktop client when the file is loaded. The base64 encoded payload that is hidden in the html page will then be reassembled locally, and the malicious file is automatically downloaded on the user’s machine.
It’s important to clarify that this only downloads the file and that user interaction is required for file execution and other malicious actions. Users should never run a unknown file, however if this technique is combined with the previously mentioned XSS alert, then you have a fairly dangerous combination for social engineering.
Clarification disclaimer regarding custom protocol handler infections with MS Teams
A quick disclaimer before continuing with this article: The Microsoft Security Response Center team has requested that I clarify that this custom protocol handler attack is only plausible if the user initially runs the malicious payload that will install the custom protocol handler.
I was not able to achieve direct RCE, however I believe that it’s important to highlight how the same unprotected Electron shell.openExternal function can be used for further (more dangerous) actions at a later time using a combination of native and custom protocol handlers.
Combining Electron’s shell.openExternal with custom protocol handler attacks
During the testing of various Electron applications, I encountered the challenge that the applications were susceptible to protocol handler abuse, but available actions were limited. All of the current proof of concepts (PoCs) relied on an outdated third-party vendor’s vulnerable software being installed on the user’s machine. If looking at this from a red team perspective, then it’s not easy to convince a user to install outdated software, however most users will happily install new software updates to protect themselves from the latest cyber security threats.
This is what drove me to conducting further research into exploring the possibility of introducing my own vulnerability at an earlier stage of the attack. Once the user was infected, then the unsecured Electron functions could be leveraged to trigger these backdoors later.
I found that it’s feasible to install custom own protocol handlers into systems by developing a PowerShell payload that would inject the relevant values into the registry. The Windows operating system is fairly permissive with respect to adding protocol handlers, as it is an anticipated non-malicious action for an installer program to be capable of adding these.
This approach also provides options for obfuscation of the payload via encoding and enables delivery through a range of methods, depending on the circumstances. The payload also provides attackers with the option of customizing the commands so that it could fit the situation. The PoC that I developed for my initial demo uses a reverse shell that connects back to my attacking machine, however other backdoor commands could be used to help establish persistence in other ways. It’s important to remember that custom protocol handlers can call any executable with the addition of command arguments, which enables ‘living off the land’ opportunities (abusing valid OS executables for malicious reasons) for attackers.
Additionally, I found that it’s possible to package the payload into an executable file, so that our malicious installer could mimic a program that the user has already installed. This could then be combined with the spoofable window title option of the search-ms:// protocol handler (or HTML smuggling) to provide a fairly reliable initial infection vector.
The below example shows packaging the PowerShell payload as an executable file that mimics the Microsoft Teams icon that users would expect. The payload is then executed against a Windows 10 machine with Windows Defender / Real-time protection enabled to show the installation behavior (the initial execution installs the handler quietly, while the second attempt provides an overwrite warning).
Furthermore, if needed, the payload can be externally hosted as a PowerShell script to exploit other local security configurations that might’ve been missed. If the user is persuaded through social engineering to execute the appropriate PowerShell command, the script can be retrieved from the external source in an endeavor to circumvent local execution policy restrictions.
This is what caused me to reach out to a colleague of mine Connor Fancy, who is very experienced with creating offensive solutions for our Team. We worked together to start developing a PoC C2 framework that would enable us to continuously install a multitude of protocol handlers, so our capabilities could be expanded past the initial infection.
Even if the injection occurs at an earlier stage, in most cases, the user will remain uninformed unless the local antivirus/intrusion detection filtering solution actively monitors for registry changes. The backdoor payload can remain dormant in the registry until it is invoked at a later stage.
Again, fortunately modern web browsers offer a warning message, as demonstrated in the example mentioned earlier. However, it is worth noting that the content within all connected Teams applications is updated when a cloud-based administrator pushes new content through the web instance of Microsoft Teams. Thus, if an on-prem user on the same tenant with the malicious protocol handler clicks on the link via the Electron-based application at a later time, the harmful action will be executed without any further warning notification to the user. If the initial user infection doesn’t occur but the malicious link is activated, then the OS will simply prompt the user for guidance on what application to use for the protocol.
The following example shows the same infected user clicking on the web card link with the malicious TeamsMeeting:// protocol handler from my PoC to spawn a reverse shell from the Microsoft Team desktop client.
Unfortunately, other security research also revealed that further local protections like Microsoft Defender could be bypassed by using executable files that are not monitored by the solution. Again, it’s important to clarify that certain pre-requisites have to be installed for some of these file types to work. If those conditions are in place though, then these files can then be used to remotely retrieve the PowerShell payload and infect the user without causing further alerts on the machine. Once the user is infected, then the attacker just has to switch out the web card link at a later time to trigger the custom handler for local actions.
In the following demo I am using a compromised Teams account to update the website (top left), while hosting my malicious payload on a attacking machine (bottom left). If the user (right side) click on the Update link from the Microsoft Teams desktop app, then the search-ms:// handler is invoked to present the payload file to the user (without warning prompts). Once the malicious file is executed, a remotely hosted PowerShell script is retrieved and executed to enable the pings:// handler for local actions.
Remediation recommendations for Developers
When it comes to protecting Electron applications it’s important to follow the guidelines that have been created by the framework designers. Per the security advisory it’s important to restrict and control all content that users are allowed to insert into fields that are available through the Electron based application.
Additionally, if developers decide that shell.openExternal is needed in their application, then an implicit allow list can be added. This will restrict the protocol handlers that are trusted and allowed by the application, which creates a more secure environment for the user.
Administrators can also take actions within their own networks to help protect against protocol handler attacks. The following tips may help protect your users:
- User Education: Educate users about the risks of clicking on unfamiliar links or allowing untrusted applications to make changes to their systems.
- Regular Patching and Updates: Ensure all applications and systems are regularly updated to include the latest patches and security fixes.
- Security Audits: Conduct regular security audits of software to discover and fix vulnerabilities. (Such as using tools like Electronegativity mentioned in the article)
- Restricted Registry Access: Use group policies to prevent registry edits by non-administrative users. In this case, it would aim prevent the creation of a new protocol handler in the registry (The user may be less susceptible to an attack if they have no administrative access – least privilege principle).
- Antivirus and Intrusion Detection Systems: Use security software that can detect changes to the registry, as well as other types of malicious activity. (Tools such as Snort could to prevent custom protocol handler injections by understanding the signature or pattern of the custom protocol handler injection you want to prevent). Use security solutions (Endpoint Detection and Response (EDR) solutions and/or Intrusion Detection System (IDS) software) that are capable of decoding PowerShell encoded commands in real-time
- Software Restriction Policies/AppLocker: Windows security features can be used to block executables running from specific paths (Example: like the TEMP directory)
- PowerShell Constrained Language Mode: Using a model where PowerShell is restricted to a subset of its capabilities, blocking certain potentially harmful actions.
Reporting the issue to Microsoft
The XML injection issue was originally reported to Microsoft on March 11th, 2023 and was reported as fixed on May 15th, 2023 (full time line below). The web issue was categorized as low – medium severity and Microsoft provided and acknowledgement on their Microsoft online-service package, however I was able to identify some additional injection points outside of the Viva Connections app, which caused some of the delays in the timeline.
These injection points do not require administrative permissions. This additional information was submitted with a formal request to fix this on the desktop client framework level vs patching the web fields.
Microsoft Teams Electron open.shellExternal timeline:
- March 11th – The issue is reported through the MSRC website.
- March 16th – Custom protocol exploit information is provided.
- March 23rd – Electron security advisory is provided regarding shell.openExternal
- May 25th – Additional evidence is provided to Microsoft showing that other web cards can be used to exploit the same vulnerability. Microsoft requests a new ticket.
- June 8th – MSRC closes the ticket due to the issue not meeting the bar for servicing. Clarification is provided and the ticket is re-opened.
- June 9th – Additional evidence is presented to Microsoft showing that protocol handlers can be used outside of the Viva Connections application without requiring administrative permissions. Another request is made to fix this on the framework level.
- June 21st – Microsoft releases Microsoft Teams desktop update 1.6.00.16472
- July 6th – Microsoft marks the case as resolved – medium severity XML web injection vulnerability.
Usually, Electron applications implement an explicit allow list within the Electron code to prevent these kinds of issues, which appears to be the case for this fix. If the search-ms:// handler is invoked now within the updated application, then the action is prevented from launching.
Unfortunately, it appears that Microsoft was able to push the update to Microsoft Teams, but our testing shows that previous payloads may not have been removed from Tenants. That means that users are vulnerable until they update to Microsoft Teams version 1.6.00.16472.
I’ve also informed Microsoft of the other vulnerabilities that were discussed in this article, however the MSRC team stated that the issues do not require immediate attention. The HTML smuggling and XSS issues may be considered for future fixes, but no date has been provided for any potential updates.
Teams version 2.0 will not be using the Electron framework
Microsoft has already announced that the new version of the Microsoft Teams application will be updated to not utilize the Electron framework anymore. While the Electron framework provides great cross platform opportunities for developers to provide their product to more users, it can also introduce some performance and security challenges that development teams need to be aware of. The new Microsoft Teams client will be using WebView2, which will address some of the vulnerabilities discussed in this article.
Luckily, the Microsoft Teams Viva Connections application is now forcing https:// for all links and the desktop client is no longer allowing arbitrary protocol handlers due to an allowed protocol handler list.
