In a lengthy breakdown, Patrick Wardle explains how the exploit utilizes document handlers, which request permission to open a link or a file in another app – like a PDF in Preview, for example – and URL handlers, which work similarly in the way they notify macOS that they can accept certain file formats.
The exploit occurs when a user visits a malicious website and a ZIP file is downloaded and automatically unzipped by Safari, whereby the custom URL scheme is initially registered on the user's filesystem.
Once the target visits our malicious website, we trigger the download of an archive (.zip) file that contains our malicious application. If the Mac user is using Safari, the archive will be automatically unzipped, as Apple thinks it's wise to automatically open "safe" files. This fact is paramount, as it means the malicious application (vs. just a compressed zip archive) will now be on the user's filesystem, which will trigger the registration of any custom URL scheme handlers! Thanks Apple!In the next stage, the malicious web page runs code that can load or "browse" to the custom URL scheme, which causes macOS to activate the URL handler and launch the malicious application.
This action is enabled through the Safari user prompt that includes options to "Allow" or "Cancel" the process, however the popup text and available options are controlled by the attacker, and are therefore easily changed to trick or deceive the user.
The standard defenses built into macOS – Gatekeeper, for example – are said to be ineffective when it comes to the attack described above, and while Apple could always revoke the malicious app's signature, that course of action would obviously be too late for anyone who had already gone ahead and launched it.
Until then, turning off automatic unzipping of "safe" files should be enough to prevent the malicious procedure from ever occurring. Concerned users can do so by clicking the Safari menu bar, selecting Preferences..., and under the General tab, unchecking Open "safe" files after downloading.
Discuss this article in our forums