Attacking Unattended Installs on macOS

Back in 2017, Patrick Wardle presented a talk at DEF CON covering the many risk factors that macOS application installers can pose. A few months ago, he revisited some of these risks with regards to Zoom’s installer for macOS. To summarize these issues without going into too much technical detail: Wardle explains how convenience features allotted in macOS package installers, such as preinstall and postinstall scripts, can pose serious risks to end-users and organizations. Basically, installers that use these convenience features and require the elevation of privileges in order to operate (whether it be prompting a user for a password or performing an unattended installation through some administration tooling like JAMF), pose serious security risks when these features are not properly implemented.

Let’s add a couple more entries to the list of products affected by these flaws.

Druva inSync

Some of you may notice that we’ve covered this product in the past, but this time we’re talking about its installer.

Privilege escalation via Druva inSync installer

In the installation package for macOS provided by Druva (install inSync.pkg), which has since been patched, the postinstall script included in the installer allowed for privilege escalation from a normal user to root. This is due to improperly implemented integrity checks of the LaunchDaemon scripts, which require the installer to run as root in order to be properly installed.

When creating the LaunchDaemon scripts, the scripts that automatically manage the inSync backup services, the postinstall script used by the installer creates these scripts in a location accessible by lower-privileged users.

By creating a malicious plist and attempting to overwrite these files while the installer runs, a lower privileged user is able to gain root access. This is demonstrated in the gif above.

CarbonBlack

In similar fashion, we discovered that the installer for Carbon Black also utilizes insecure directories during the installation process. Since these directories and the files used are user-readable/writable during the installation process, they are all vulnerable to manipulation by a local attacker.

When timed correctly, a local attacker can use this vector to achieve significant information disclosure or denial-of-service conditions.

For example, an attacker with access to a low-privileged user account could do something like the following while the installer is running:

while true; do
    ln -f -F -s /some_root_only_file /tmp/cbdefense-install/cloud.pem
done

The above, while inelegant, has two possible outcomes based on the timing of the attack. In the first possible outcome, the installer will simply overwrite whatever the symlink points to. This outcome happens because of the initial copy from the installer to the tmp directory. This could cause system instability and result in a denial of service like condition for the entire host depending on what the attacker chooses to overwrite. In the second possible outcome, which happens if triggered after the initial copy, the content of the target file will be copied to “/Applications/Confer.app/cloud.pem” (or whatever directory is configured for the host), which is readable by unprivileged users. This can be used as an information disclosure.

As another example, simply symlinking “/private/var/tmp/.cbd” to any arbitrary file can cause the installer to overwrite any file on disk as the root user, which could result in a denial-of-service condition for the entire host.

Additionally, the “postinstall” binary contains a buffer overflow due to an unchecked call to “strcpy()” when parsing configuration files. The following is a snippet from our reverse engineering process showcasing problematic logic:

if (config_file[0] == ‘[‘) { // Checks that we’re in a config section
    _strcpy(local_438,config_file); // copies the file (controllable via the above issues) into a buffer whose bounds are not validated

We were able to confirm this logic as vulnerable in a debugger. When combined with the attacks above (such as manipulating “confer.ini”), an attacker could use this to execute code in the context of the root user. This attack is exceedingly complicated, however, in terms of timing required (the file must remain valid for a short period before the vulnerable code is executed). We do not believe this particular issue to be exploitable in any practical manner, but out of an abundance of caution, VMware has fixed it anyway.

While we were not able to achieve privilege escalation with these vectors during our investigation due to time constraints, we do not doubt that it is possible.

Conclusion

It’s fairly common to see macOS package installers make use of this pre- and postinstall functionality, especially in enterprise products built to allow unattended upgrades or installations. Aside from auditing any and all installers used in your environment, there aren’t any strict rules to follow or mitigations to implement for this class of flaws since they’re almost all dependent on custom implementations and environments.

It’s up to vendors to implement installer best practices by showing the same QA attention to their installation scripts as they do the actual product and to make use of sandboxing features offered to package installers.

For more details on the flaws discussed above, please see: https://www.tenable.com/security/research/tra-2020-69 and https://www.tenable.com/security/research/tra-2020-67