Forum Discussion
Teams Updater Vulnerability
There are reports circulating that the Teams auto-update process suffers from the same unsigned code execution as other application built with Electron.
Running the Update.exe processStart with any unsigned application binary will run the unsigned application as signed code through a process chain. The Teams Update.exe is signed by Microsoft so the usual AppLocker and Application Guard defences will not block this exploit.
Has anyone got any advice on a work around or information on whether Microsoft are going to plug this exploit?
This particular squirrel vulnerability was fixed in Teams version 1.2.00.21068.
Thanks!
John
17 Replies
This is precisely why enterprise administrators want a standard MSI installer for Teams that puts things into a properly secured location like C:\Program Files location instead of the user's folder. Oh, sure, the vulnerability would still be there but a standard user wouldn't be able to readily leverage it without some other exploit or flaw.
I can confirm that MS has a fix for this already, should be rolling out shortly.
Yep, the problem is with squirrel and affects a long list of apps.
but, you can hunt for them with defender ATP
ProcessCreationEvents| where ProcessCommandLine has "update.exe"| where (ProcessCommandLine contains "http") and (ProcessCommandLine contains "--update")| extend exeURL = case(ProcessCommandLine has "=",split(ProcessCommandLine, "=", 1),ProcessCommandLine !has "=", split(ProcessCommandLine, "--update ",1),"Default")| where exeURL != "Default"| sort by EventTime desc|project EventTime,ComputerName,exeURL,FolderPath,ProcessCommandLine,AccountName,InitiatingProcessCommandLine,ReportId,ProcessId,InitiatingProcessIdthis query only focuses on the update part but you can easily change this to include the procstart param
http://blog.sec-labs.com/2019/07/hunt-for-nuget-squirrel-update/
Mattias Borg Awesome. Great tip. I dig go looking for a Defender ATP hunt command but obviously did not look hard enough.
Andrew Matthews I've updated the query to catch all parameters used by squirrel and 2 URLs I know are legit. Other apps using squirrel which are also affected by this
ProcessCreationEvents| where (ProcessCommandLine has "update.exe") or (ProcessCommandLine has "squirrel.exe")| where (ProcessCommandLine contains "http")| extend URL=extract(@"((http:|https:)+[^\s]+[\w])", 1, ProcessCommandLine)| where URL !in ("https://slack.com/desktop/update/windows_x64", "https://discordapp.com/api/updates/stable")| sort by EventTime desc| project EventTime,ComputerName,URL,FolderPath,ProcessCommandLine,AccountName,InitiatingProcessCommandLine,ReportId,ProcessId,InitiatingProcessIdHappy Hunting!
The Microsoft folks are aware of this already, and with them "owning" Electron now it shouldn't take a lot of time to patch. The more interesting question here is why was this allowed to happen in the first place, considering security is on top of their SDL list. Guess we can always blame it on the open-source model, but whoever decided to use Electron should have put it through the SDL list to begin with...
I have met some of the Teams Dev team at conference. They seem very well meaning and want to build a great product but I get the sense that there is a lack of appreciation for enterprise and security. That shows in the product.
Unfortunately the Electron / Squirrel updater issues are not confined to Teams. Slack and a few other widely used products have the same issues.
Also interesting to note that Electron have deprecated the use of Squirrel on Windows.
