06-27-2019 01:07 AM
06-27-2019 01:07 AM
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?
06-27-2019 09:47 AM
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...
06-27-2019 12:20 PM
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.
07-01-2019 05:12 AM
Yep, the problem is with squirrel and affects a long list of apps.
but, you can hunt for them with defender ATP
this query only focuses on the update part but you can easily change this to include the procstart param
07-01-2019 10:31 PM - edited 07-01-2019 10:48 PM
@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
07-02-2019 08:49 AM
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.