Synopsis
Local Privilege Escalation via teams_osx.pkg
In the latest installation package for Teams for macOS provided by Microsoft (Teams_osx.pkg), the "postinstall" script included in the installer allows for privilege escalation from a normal user to root due to improper permissions on files used throughout the installation process.
During the installation process for Teams, the application contents are moved to "/Applications" as normal. The "postinstall" script creates a LaunchDaemon that points to the TeamsUpdaterDaemon application ("/Applications/Microsoft Teams.app/Contents/TeamsUpdaterDaemon.xpc/Contents/MacOS/TeamsUpdaterDaemon"), which will run with root permissions. The issue here is that if a local attacker is able to create the "/Applications/Microsoft Teams" directory tree prior to installation, they can overwrite the TeamsUpdaterDaemon application with their own custom payload, which will be run as a LaunchDaemon, and thus give the attacker root permissions.
For example:
# Prep Steps Before Installing/tmp ❯❯❯ mkdir -p "/Applications/Microsoft Teams.app/Contents/TeamsUpdaterDaemon.xpc/Contents/MacOS/"
# Just before install, just have this running. inelegant, but it works.
# Payload can be whatever. It won't spawn a GUI, though, so a custom dropper or other application would be necessary/tmp ❯❯❯ while true; doln -f -F -s /tmp/payload "/Applications/Microsoft Teams.app/Contents/TeamsUpdaterDaemon.xpc/Contents/MacOS/TeamsUpdaterDaemon"done
# Run installer. Wait.
The above simply creates a symlink to an arbitrary payload at the file path used in the postinstall script to create the LaunchDaemon. In order to fix this issue, we recommend verifying the integrity of the TeamsUpdaterDaemon prior to creating the LaunchDaemon entry, or using the preinstall script to verify permissions on the "/Applications/Microsoft Teams".
Solution
Microsoft has not released a fix for this issue. Users are encouraged to verify that the permissions of the "/Applications/Microsoft Teams.app/" directory prior to installation.Disclosure Timeline
All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.
Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.
For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.
If you have questions or corrections about this advisory, please email [email protected]