High Sierra installer reverts XProtect rules

October 19th, 2017 Update: Apple has just silently pushed an updated XProtect configuration package that appears to address this issue. The package changes the receipt identifier that was the root cause of the problem. It does not change the configuration version number nor introduce any changes to XProtect rules. We’ve confirmed that previously ‘stuck’ machines are now updating properly.

TLDR; High Sierra installer replaces XProtect config version 2095 with version 2094. SoftwareUpdate fails to re-update them once High Sierra is installed

After installing High Sierra late last week, we fired up UXProtect to further explore XProtect Yara rules and blacklists. Much to our surprise, the XProtect v2095 signatures installed on September 29th were rolled back to v2094 (August 24th) during the upgrade process. When we attempted to reinstall the v2095 update, it failed! SoftwareUpdate still believed that v2095 was installed.

XProtect config v2095 doesn’t exactly include groundbreaking new signatures. It adjusts previous signatures and adds a new adware variant as we documented in this tweet. However, we certainly don’t like the idea of silently being downgraded without the ability to automatically recover.

Timing

This issue presents itself only if XProtect configuration v2095 was installed before a High Sierra upgrade. High Sierra was released on September 25th, 2017. The XProtect configuration update was made available for silent install on September 29th, 2017. If you’ve enabled auto updates, your machine likely installed them shortly thereafter.

Mitigation

Follow these instructions at your own risk if you find yourself stuck on v2094 signatures after installing High Sierra.

Download and install the XProtect configuration package manually, via Apple’s online catalog or use a product such as SUS-Inspector to manage the download and install.

Details

This image shows a machine that is updated to macOS Sierra 10.12.6 and XProtect configuration version 2095. UXProtect shows that the XProtect signatures are the most recent available, including signatures for HMining.D and the renamed ExtensionInstaller.A as part of the most recent update.

After this same machine is updated to macOS High Sierra, we can see that the XProtect signatures have now been reverted to v2094 and that SoftwareUpdate does not believe that there is an update available.

UXProtect also now shows that v2094 is installed. The HMining.D and renamed ExtensionInstaller.A signatures are no longer a part of the package. However, UXProtect properly notes that v2095 is available for download and prompts the user to take action. As you might suspect this fails because UXProtect calls upon SoftwareUpdate to install the package.

Additional Notes

While we originally noticed this issue though our use of UXProtect, we verified that initiating XProtect configuration updates (both before and after installing High Sierra) via other known means did not affect the results. These installation procedures included:

• Allowing the updates to happen “organically” via Apple’s background process
• Forcing background updates via the widely used sudo softwareupdate --background
• Forcing select configuration update via undocumented steps that we previously shared via tweet. (Note: Used by UXProtect)
  • sofwareupdate -l --include-config-data followed by
  • softwareupdate -i XProtectPlistConfigData-1.0 --include-config-data

Additionally, The recently released High Sierra supplemental update was also tested and and suffers from the same issue. The issue was encountered on at least 2 physical MBP laptops and was consistently reproduced on virtual machines.

Reporting

This issue has been reported to Apple and we are awaiting response. In the meantime, because this isn’t a vulnerability per se and it manifests itself in UXProtect, we thought it was important to offer our users, colleagues and fellow mac enthusiasts a detailed explanation and mitigation.