Apple macOS apps that have been downloaded from the internet and run at least once can be swapped with malicious versions, a pair of researchers say, calling into question the thoroughness of the company's "Gatekeeper" defenses. As Apple explains, "When a user downloads and opens an app, a plug-in, or an installer package from outside the App Store, Gatekeeper verifies that the software is from an identified developer, is notarized by Apple to be free of known malicious content, and hasn’t been altered." Security researchers Talal Haj Bakry and Tommy Mysk say they've identified a gap in Gatekeeper and associated code signing rituals that "allows an attacker to silently replace the main executable of any application downloaded from the web without requiring elevated privileges." The attacker needs to have means of user-level code execution available, such as a malicious app or downloaded script, so it's not a zero-click vulnerability that a remote attacker can deploy. Nonetheless, the finding shows Gatekeeper to be rather lax in its gatekeeping duties. Bakry and Mysk managed to alter a macOS app downloaded from the web (not from the App Store) and Gatekeeper failed to object. Their technique doesn't work on Mac App Store apps, the Mysk team told The Register, because they're owned by root, so a process running with current user privileges won't be able to overwrite them. But for macOS apps downloaded from the web, such as Brave, Slack, Signal, or Visual Studio Code, among many others, there's potential risk. The attack scenario requires an app downloaded from the web that has been run once – allowing Gatekeeper to complete its initial validation – and the ability to execute user-scoped code. The initial validation phase that Gatekeeper conducts is supposed to prevent subsequent modifications to the application bundle, even with administrative privileges. But the Mysk team found that you can archive a downloaded, once-run app using tar (a file archiving utility), then remove the original and replace it with a malicious version, and macOS does not require reauthorization. They've recorded a video demonstrating how the attack works. The Mysk team said there are many ways an attacker might gain the necessary access to get around Gatekeeper, such as tools installed through the command line, convincing someone to copy and paste a command to their terminal, downloading and running an malicious app, a prompt injection attack on an AI agent, or a supply chain attack via npm, brew, or some other package manager. And once a doppelganger version of an app is in place, it can magnify its mischief by presenting deceptive prompts that users are more likely to trust because they appear to come from a known app. Tommy Mysk said he was uncertain about the exact cause of the issue, but speculated it may have something to do with cached value retention. "When you open the app for the first time and it passes all validation checks, macOS marks the app as trusted and saves this data," he said. "Later when I modify the executable, macOS detects a change in the bundle and tries to revalidate its integrity. It seems the cached value of the trust causes macOS to pass the validation even though the bundle has changed." The Mysk team reported their findings to Apple, which reportedly closed the issue. "Apple doesn't consider this attack to be 'modifying' the signed executable," the Mysk team explained. "Instead, Apple says that by archiving/restoring the app bundle, the proof-of-concept code overwrites the entire app bundle, making it locally built. "Locally built app bundles are not covered by macOS guards. And this is why access to Keychain or TCC protected directories require system authorization prompts. And for users to accept those is a matter of social engineering attacks that Apple considers out of scope." Apple did not respond to a request for comment. ®
