search

OfficeDev / Office-IT-Pro-Deployment-Scripts

A collection of useful PowerShell scripts to make deploying Office 2016 and Office 365 ProPlus easier for IT Pros and administrators. If you have any feature requests or ideas for future scripts please add the idea to the issues list in this repository
http://officedev.github.io/Office-IT-Pro-Deployment-Scripts
MIT License
887 stars 841 forks source link

Major Bug: Possible Security implications. Remove-PreviousOfficeInstalls.PS1 #259

Closed Lt-Lemming closed 7 years ago

Lt-Lemming commented 7 years ago

We've got an automated deployment script that I have written to do upgrades from previous versions of office to 365.

As part of this script I've tried to have it also handle removing 32 bit version of 365 and install a 64 bit version in it's place. This is mainly for if the user has Office 2010, but Project or Visio 365 installed.

This script is deployed via SCCM and as such has to be able to run in a SYSTEM context. I tried to invoke the "Remove-PreviousOfficeInstalls.PS1" script during this process to remove the already installed 365 apps, but kept running into an error "Unable to set username in Registry".

Recently while trying some other testing of this, I ran the script from a PowerShell ISE window that was running as SYSTEM. Again I got this error, but rather than dismissing it I elected to wait.

It gave that error a few more times.... and then dropped me to a SYSTEM Desktop Session!.

This potentially could be used as an elevation of privileges attack... I.e. replace a known good script with a malformed script that calls this, and then trigger the installation from SCCM, SCCM runs it as system, it kills the desktop sessions and then drops you to a system desktop session.

See the screenshot attached, I'll do some further testing to see if this attack is indeed possible and let you know.

Command I am using to get this to happen:

Remove-PreviousOfficeInstalls -RemoveClickToRunVersions $true -Remove2016Installs $true -Force $true -Verbose -NoReboot $true

dropped to system desktop

command prompt whoami

AStigall commented 7 years ago

@Lt-Lemming Interesting find. We haven't run across this issue yet, but will test again to see what happens.

Lt-Lemming commented 7 years ago

https://www.youtube.com/watch?v=N75Cv1U0zJQ <--- video of this being done.

I've tested from an SCCM script and been unable to replicate the behaviour as of yet from SCCM, but still mildly concerning.

KibagamiJubei commented 7 years ago

@Lt-Lemming This is coming from the VBS scripts which are restarting explorer.exe and PowerShell ISE - the combination causes the logon session to reload in the user context of the user invoking the script and my guess is that PowerShell ISE is somehow related. This should never occur in normal usage.

AStigall commented 7 years ago

Interesting finds! Thank you all for your input.