#modified app execution

Digital devices typically come with a pre-installed security program. Windows has Defender, Linux has AppArmor, and macOS has Gatekeeper. They are all designed to do essentially the same thing: make sure the programs and apps that run on a particular OS are safe. This is usually done by verifying that the software is from a trusted source or registered developer. If anything changes, the permissions involved with running said software are supposed to be checked again.

In a perfect world, this would be enough to keep one’s system secure. But it’s not a perfect world. Instead we have threat actors who continually try to break down the defenses of a system in order to accomplish whatever their goal might be. Data scraping, credential harvesting, ransomware, secrets theft, you name it, they try it. And vectors for intrusion have become vastly more complex than downloading a dodgy file and getting a Trojan. App poisoning, prompt injection, and compromised supply chains are all techniques that use stealth or evasion to get into one’s device. Not all intrusions are malware these days. Vulnerabilities and flaws play a large role in access from external forces. And sometimes what a program says it’s doing and what it’s actually doing are two different things.

Researchers Talal Haj Bakry and Tommy Mysk claim, and have tested in a proof-of-concept scenario, that Gatekeeper has a gap that allows an attacker to silently replace the main executable of any application downloaded from the web – as opposed to the App Store – without requiring elevated privileges. Meaning that any app, once run and verified, can be replaced with a malicious version that doesn’t trip the security to verify it anew. Of which there are many out there these days, as supply chain compromise becomes more of a problem with poisoned dependencies embedded in package trees. This issue is not a zero-click vulnerability that a remote attacker can deploy, it requires user-level code execution. But considering how many users don’t actually follow through (or know that they need to) on checking the veracity of apps themselves, this becomes a significant issue. Let’s face it, social engineering relies on users not checking.

As noted above, apps from the App Store are not vulnerable to this issue. Since those are owned by root, a process running with current user privileges won't be able to overwrite them, according to the research team. But for apps downloaded from elsewhere – browsers, Signal, Visual Studio Code, etc – the risk is present. Verification of the initial download proceeds accordingly, and is supposed to prevent changes in the downloaded bundle from being executed. The gap lies in archived downloads, however. The team discovered that apps archived with tar, a file utility for this purpose, can then be removed and replaced with a malicious version that doesn’t trigger reauthorization, possibly because of cached value retention.

Mysk is quoted, “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. 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.”

According to The Register’s report on this, Apple’s response to the research boils down to ‘not our problem; this is user error’, saying that archived apps no longer fall under the macOS guardrails, since the process of archiving then modifying makes it a local build. I’m sorry, what? That’s like health insurance companies charging through the nose and then telling the customer that their ailment isn’t covered due to pre-existing conditions. Then what is the point of paying the premium? Most people do not scrutinize every single app that passes through their device; that’s the point of having security programs. And regardless of actual user error that may rewrite directories and/or change permissions, there are entirely too many packages in various software that have been maliciously modified further upstream in the supply chain to simply relegate all of this issue under one umbrella. I’ve covered a number of npm poisoning instances that work exactly like this, changing the executable functions of apps after download.

There is a disturbing trend in the tech industry whereby flaws pointed out by independent research get dismissed. And the onus of responsibility gets passed onto the consumer, rather than the vendor being held accountable for releasing a product that’s vulnerable. I’m going to call it out: that is also social engineering. Companies like Apple are abusing the trust of their userbase. Users should be aware that they’ll get no help from their provider and make sure they have a secondary security program in place.