OS X Gatekeeper rendered useless by new malware exploit

On the day that Apple releases El Capitan details of an exploit that makes it possible to bypass the Gatekeeper feature of OS X have emerged. Designed to combat various forms of malware, the security feature can be bypassed using a simple trick involving the use of a signed binary.

Even when Gatekeeper is configured to use its highest level of protection, the ease with which the fortifications can be slipped through is staggering. Using a file that has already been deemed trustworthy by Apple, it is possible to trick OS X into executing a malicious file stored in the same folder as the signed one. No patch is yet available, and it is believed the problem affects all versions of OS X.

The vulnerability was discovered by security researcher Patrick Wardle from Synack. Talking to Threatpost, he explains that he has already shared his findings with Apple but the company is yet to produce a patch. Wardle found that Gatekeeper, while checking for authentication of files from Apple, failed to determine whether apps make calls on other apps or code that have not been signed.

Once an app has been given the go-ahead by Gatekeeper, it is free to execute whatever code it wants on the computer, and this is precisely how the exploit works. Users could be easily tricked into executing a signed, infected file that could wreak untold damage. Wardle says:

The issue is not being described as a bug, but as a limitation of Gatekeeper. A fix could take some time to appear as Wardle warns that it would require "significant code changes" to OS X.

You can't change permissions of existing system files to prevent this since an unverified load at system privilege has permission or can change it easily. Obviously not all installs go to system privilege (you know because it asks you for a password) and those that do are usually more carefully constructed. Obviously relatively few developers load extra libraries and executables and those that do are probably mostly doing it properly by signing in advance and checking the signature at install time in their trusted code.

I know what you are saying. . . and you are right as far as this is going. The point is that it still requires the DEVELOPER to be the malicious bad actor, installing the malicious files in his own distribution. I don't think any developer would do such a self-destructive thing.

Actually, on a Mac it might be possible protect system files from ordinary installers of software as the "Administrator" is not the ultimate level of user. There is still the superuser level. The Administrator is the level required to install software, but the superuser is the level of administrator required to do everything including modify certain system files. Structuring the installers to limit that to not allow these files to permit modifying any of these is certainly possible. The vast majority of Mac users never have access to that super level user as it is turned off by default and is only accessed when an update is being done to the operating system. A mere Administrator level is what they may have access to allow them to install software. . . and they should only be running as a standard user, without even administrator access.

Giving a DMG installer an Administrator name and password should never give it permission to overwrite any critical system files. . . only to install its own executables.

In other words to bypass fully nested code signing, the developer has to deliberately put executable code (libraries or actual executables) into a data resource, then copy that data into files at installation time, then run it (fork/exec or load a library). That is not just foolish but deliberately wrong. As they say next "Always put code and data into their proper places" That's not hard and good practice.

Also, Palmer, that was one of my points. . . Apple can easily find such code during curation. . . because this supposed vulnerability is that a trusted, certificated DMG, will replace these renamed bogus, malicious files in the resource fork of the DMG for the legitimate files on the targeted computer during install. . . if they were allowed to be installed by file permissions of the legitimate library/executable or library. Apple looks for such shenanigans in the curation process. Such renamed files would stand out like a sore thumb. They don't belong there. They'd install the software and look for any modifications to the test system it was installed on. . . finding such, all hell would be rained on the developer who submitted the app.

The point is that it still requires the DEVELOPER to be the malicious bad actor, installing the malicious files in his own distribution.

No the developer uses invalid practices to load untrustworthy executables or libraries and run them. The attacker overwrites those untrustworthy executables or libraries with malicious ones.

There is still the superuser level.

Yes, there are three levels of permission on every file and every directory for every operation (read write exec) for a total of nine permissions. So that does give a middle level of permission for users who are in the admin group to alter some files.

Your broader point is that root access is the only way to get malware to be persistent. It is possible to run malware on a mac (e.g. with a vulnerable version of flash, from a rogue website that the user was enticed to go to). But that malware is running as user and can't alter any files that would allow it to persist through a reboot or logout/login. One reboot and it is completely gone.

The relationship to this thread is that most software installations have very limited and standardized places to put executable code (e.g. in the /Applications directory). Thus there is no random unsigned executable stuck any old place and executed. There is simply no need to do that. Even a (uneducated) developer did that, they would do it as user level and it would be unable to alter any system files and persist if it were hijacked by an attacker (no easy task in itself).

Apple looks for such shenanigans in the curation process

As they should. And they stick out and can be found. Executable code can be easily distinguished from data. For a developer to get around that they would have to encode the executable code to make it look like data. In my mind, that is basically equivalent to malware because I can't think of another reason to hide code. But there could be other reasons that less scrupulous developer (with a Apple cert) might have.

What is the most telling point in all the articles I read about this is what was not said. The guy who found this "exploit" gave no examples of installers that he was able to hijack. That's probably because the few that he found were essentially malware (e.g. some program that masquerades as a cleaner or other utility, but actually pops up ads or ransom notes). So it may well be a case of very bad malware authors exploiting crapware authors who managed to get code signing certs from Apple.

Palmer. . . that is NOT the attack mode here . The attack mode is that the malicious files are IN the DMG to begin with. . . FROM the developer's download. . . in a trusted file. There is no second malicious attacker in the middle involved. The point is that only the single DMG is signed. . . or the application itself.

No the developer uses invalid practices to load untrustworthy executables or libraries and run them. The attacker overwrites those untrustworthy executables or libraries with malicious ones.

This is not about a man-in-the-middle intercept of the download, inserting a malicious file into the DMG, and then sending it on, that's child's play to strip out legit content and pad out to match check sums with the original certs. . . or, as he asserts, having someone putting an altered version on the App store which I maintain is not possible with Apple's curation.

The idea is the file could have been adulterated at the source of the download, whether the app store, the trusted vendors' own websites, or other download location, or on a purchased disk. It is also NOT about some third-party malicious software somehow getting on the Mac through another vector and taking advantage of some hidden function added to these altered files hidden in these malicious executables or libraries.

It IS about unknowingly downloading a trusted DMG or other trusted app signed with an Apple issued certificate that has the modified files already in them from a trusted or other trusted source. . . not anything else. The guy who came up with this actually made the claim that Apple would not find the hidden files with curation in the App Store. He's wrong.

Perhaps if one downloads it from a pirated software site, this would be a big risk. . . but then we're back to you get what you expect from pirate software. . .

The attack mode is that the malicious files are IN the DMG to begin with. . . FROM the developer's download. . . in a trusted file. There is no second malicious attacker in the middle involved.

I found a better article: http://arstechnica.com/security/2015/09/drop-dead-simple-exploit-completely-bypasses-macs-malware-gatekeeper/ In the diagram there is a signed executable without any malicious code. That is step 1 in the diagram in the previous article that I posted. You are only referring to step 2 in that article when you talk about the DMG with the malicious code.

As I suspected, but was not clearly explained in the first article, there are two DMGs. One is from a legitimate although uneducated developer. That developer improperly executes code from his/her signed DMG without first verifying the signature. The attacker creates a second DMG, it is unsigned and it contains the malicious executable.

Here is ArsTechnica talking about the first DMG: "Wardle has found a widely available binary that's already signed by Apple. Once executed, the file runs a separate app located in the same folder as the first one." IOW, he has found exactly one poorly created DMG that executes unverified code. Although he says it is "widely available", my guess is that it is not widely used. Pulling that one code signing cert will take care of that one and there may not be any or many others.,

His attack is to swap out binary B with a malicious binary B. IOW the original DMG contains no malicious code. There is an attacker with a second DMG and it inserts best with man-in-the-middle (e.g. someone downloads with HTTP instead of HTTPS) although it could be done without MITM by tricking the user to download the second DMG.

Exactly. . . but for anyone to even download that DMG in the first point, it is necessary to turn off Gatekeeper's most stringent level. So what exactly is his point?

Thus, now we know this distribution he claims is widely distributed could not have been on the Apple App Store. . . so must be on some third party distribution site, or more likely one he had already downloaded himself where he could manipulate it easily himself. My point is that Apple would find any malicious executable in a DMG submitted to the Apple Store. I already grant that the basic certificate cannot cover every single piece inside a certificated software distribution, and that it cannot stop someone from adulterating a distribution from a third-party distribution site, that is done all the time.

Therefor, he could create his masterpiece malware that gets around Gatekeeper and test the download, install, and run based on the distribution he found NOT ON APPLE'S APP STORE. Were he to submit it, red flags would start flying.

Several years ago a Trojan was distributed as a pirated copy of Microsoft Office for Mac 2011. . . very amateurish attempt as the download was only 240K in size. Anyone who thought they could download an entire Office suite in 240K deserves what they get. LOL! A true professional malware writer would have buried the malware in a real version exchanging their malware executable for some portion of the original code and the size of the download would have matched. A bit later, a profession did do exactly that and Gatekeeper caught it.

Patrick Wardle, director of research of security firm Synack, said the bypass stems from a key shortcoming in the design of Gatekeeper rather than a defect in the way it operates. Gatekeeper's sole function is to check the digital certificate of a downloaded app before it's installed to see if it's signed by an Apple-recognized developer or originated from the official Apple App Store. It was never set up to prevent apps already trusted by OS X from running in unintended or malicious ways, as the proof-of-concept exploit he developed does.

That bolded statement is not true. Gatekeeper also holds the definitions, updated daily if necessary (it hasn't been), of every known OS X trojan and the Trojan families, and will scan the file for their presence on download, installation, and first run. The claim it merely checks the Certificate is just plain wrong.

My point is that Apple would find any malicious executable in a DMG submitted to the Apple Store

The DMG that Wardle found had no malicious executables in it. But he never says he got it from the Apple Store. However it was signed by Apple. The DMG might be very old. We really don't know anything about it except it was signed. But certificates can be revoked Apple has revoked several that I have read about and probably others I have not. So for this case revocation is a no brainer.

Several years ago a Trojan was distributed as a pirated copy of Microsoft Office for Mac 2011

There have been many attempts to distribute Trojans in DMGs, but to my knowledge none of them were signed. Users would have to bypass Gatekeeper (nontrivial) and ignore the warnings.

The claim it merely checks the Certificate is just plain wrong.

True, but remember that original signed DMG that Wardle discovered (somewhere, we don't know where) contained no malware. The second unsigned DMG that Wardle created did.. And a user would have to be tricked into downloading or download the signed DMG with HTTP instead of HTTPS with an elaborate MITM involved. All very unlikely and as far as we know, never done in the real world.

I think the fact that Wardle didn't reveal the signed DMG origin, nor it's purpose is very revealing. Probably obscure software and only quasi-legitimate although signed with a valid cert. Like a DVD decoder or something like that.

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.