Posted on 10/01/2015 12:30:50 AM PDT by Swordmaker
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:
It's not super complicated, but it effectively completely bypasses Gatekeeper. This provides hackers the ability to go back to their old tricks of infecting users via Trojans, rogue AV scams or infect applications on Pirate Bay. More worrisome to me is this would allow more sophisticated adversaries to have network access. Nation states with higher level access, they see insecure downloads, they can swap in this legitimate Apple binary and this malicious binary as well and man-in-the-middle the attack and Gatekeeper won’t protect users from it anymore.
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.
Photo credit: khd / Shutterstock
If you want on or off the Mac Ping List, Freepmail me.
I don’t fault Apple for being unable to thwart hackers.
Given the complexity of a modern OS and the brilliance of the many truly gifted hackers attempting to break security there is simply no way to be 100% secure.
This is just the world we live in...
:-(
So I shouldn’t click on a “weird trick” malware ad?
That wouldn't do this. . . you'd have to accept a download of a disk image (DMG) file or similar file to install. . . It would have to be able to be acceptable to the Gatekeeper system, in other words from a certified Apple Developer, or not have one of the recognizable Trojans in it. Apple should be able to identify the modified files these would be carrying and flag them as Trojans, once the details come out.
Apple has to approve apps downloaded from the Apple Store. Surely Apple checks them for malware. The certified developer would have to fool Apple’s malware checkers, or the user would have to accept a DMG file from a source other than Apple.
That's the point. This whole proof of concept is built on the idea that a trusted developer is going to sneak malicious files into his valuable downloadable package, renamed so they can replace existing executable Apple system files, to be able to do nefarious things such as key-logging, watching for creditcard numbers, and raiding contact emails for spam lists, whenever they are either loaded by start-up routines or invoked by other programs. . . and go unnoticed.
Apple's curators would notice any apps on the installer duplicating System files. . . That would be a violation of the Developer agreement, which is enough to get a developer banned for life and all of his apps pulled. If a third-party wants to install this stuff on a Mac, sell it outside Apple's curated App Store and convince the unwary to just turn off Gatekeeper for the installation of their software. There's lots of good, Safe Mac OS X software sold that isn't in the App Store. That's the other thing that's stupid about this. You can set Gatekeeper to bypass the Certificates but still check for second level stuff, known Trojan, etc., for those purchases, or the highest level, allow software only from the curated Apple Store. . . or, live dangerously and go naked into the wild. . .
So the standard is that a security feature is "rendered useless" because of one proof-of-concept exploit. As though anything less than 100% effective is 0% effective. Keeping out all the malwares but one has no value? Really? A defense has to be absolutely perfect or else it's worthless?
Nobody has ever judged Windows anti-malware features like that. They range from 70% to 95% effective -- none are 100%.
That's not to excuse the weakness in the defense. Just sayin'...
Tech writers WHORES are so f**kin' corrupt. ANYTHING for a page hit. ANYTHING.
Yep - it requires "helpful authorization" from the user.
Like they say: You can make anything fool-proof, but you can't make it damn-fool-proof....
More than that, Swordmaker, the legit application has to invoke the non-legit application, and not use the system’s application launcher to do so (using something like fork() or exec() instead). Remember that Gatekeeper fires when the application is executed, not when it’s installed.
Of course, there’s no need for the developer to do that, because they could easily embed malicious code in the original signed application. All application signing and Gatekeeper does is identify who distributed the application, it makes no guarantee as to the application’s safety. So whether it’s in the main application or a helper application distributed alongside, the developer is still going to be identified and blacklisted if they distribute malware.
The only real attack vector here is to find non-App Store software that is developer signed and uses additional helper applications launched with the likes of fork() and exec(). The attacker can modify/replace the helper application(s) and redistribute the bundle as if it’s the original distribution. A legitimate threat but very limited; downloading from reputable sites/mirrors and validating checksums will avoid any issues.
Yeah, as I noted above, the only realistic attack vector involves developer-signed software coming from outside the App Store, and that requires a man-in-the-middle attack to make any use of this particular quirk.
Again: Gatekeeper is not an anti-malware tool, it serves merely to identify the developer who signed the application or to alert the user that the application is unsigned, the first time it is run.
Yeah, this one isn’t a big worry at the moment. Most malware writers don’t sign their programs with known developer certificates. If they do, I suspect it’s a quick fix for Apple to revoke that cert.
There's one more threat scenario you might not be considering. If the trusted developer is dumb enough (yes, that is the correct description) to load and execute unsigned (but not malicious) code, then all a malware developer has to do is overwrite the unsigned code with malware to get it executed. That's not an easy trick but possible in user space. The key, as has been the case for almost 2 decades with MS code signing, is that a signed executable should never load and execute anything other than signed code and signed libraries. MS makes it easy to check signatures, and there's no excuse for not doing that. But there are always dumb but "trusted" developers who take the shortcut and don't bother checking the signature.
It's not that simple. If a trusted developer improperly loads and runs executable code, then malware might be able to take advantage of that fact. There's still the important detail of the malware developers being able to overwrite the right file at the right time with their own malicious version, I know it is theoretically possible but I have no idea if it can be done in reality on MacOS.
Um... yeah... that would be the attack vector I’m talking about. The only practical way to get it installed, unless the user is compromised (in which case this particular exploit is not needed), is to include the infected binary as part of a substitute distribution package.
Note also that as long as the application uses the normal mechanism for launching apps, Gatekeeper will still check any of the launched apps. It’s the use of the low-level calls like fork() and exec() that bypass the Gatekeeper check.
All developers have executable code. This supposed vulnerability is to place a renamed system file in the install disk for the installer to use to overwrite the correct official System file with the renamed file with the malicious code. Your take is incorrect. The trusted developer would have to install the malicious renamed system files on his distribution DGM file, not that some other malicious software from some other source could somehow take advantage of it.
One simple way of handling this is to change the permissions of official system files to prevent overwriting even with administrator level permissions. . . the Library folder itself where those files reside could be written to with administrator level permissions, but OS X system files would be inviolate for mere installs of software. Only Apple system upgrades would have permission to overwrite them.
It actually is an anti-malware tool, kevkrom. Gatekeeper holds the signatures of every known Apple Mac OS X Trojan and their families in a database that is kept updated daily. Every download, install, and new app on first run is compared against those signatures and the user is blocked from completing a download, install, or running them without using an Administrator's name and password. In other words, you can download, install, and run such a known Trojan app if you want, but you have to use more than just a continue button to do it. It takes industrial strength stupidity to do get infected with a known Trojan on a Mac.
...But what Gatekeeper fails to do, Wardle said, is check whether an app runs or loads other apps or dynamic libraries from the same or relative directory.... https://threatpost.com/apple-gatekeeper-bypass-opens-door-for-malicious-code/114851/
Looking at the diagram in the article, step 1 is to find a signed app that at runtime loads and runs a relative binary. To that I would add that the developer also broke the rule of always signing any packaged binaries and verifying the signature before loading Since that verifying is done in Apple-signed code, it would be impossible to bypass. It is not difficult and only lazy or uneducated developers skip the signing and verification. Step 2 is to leverage the improperly constructed loader by substituting a different malicious executable or library and trick the user into running two DMGs instead of just one, no easy trick.
It is not unique to system files, any file or library could be loaded and executed by the poorly constructed (lacking proper verification) loader. That could be loaded and run at system privilege in which case the damage is much worse. If it is loaded and run at user privilege it can still be damaging but a privilege escalation is very difficult as we discussed in another threat.
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.
That is true but as I just explained to Swordmaker, a signature check is very easy to implement. It is the responsibility of the developer to do that check in his/her apple-signed, trustworthy code. Such a check cannot then be bypassed by an attacker.
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.
I suspect the number of poorly built packages is very small and even those will be difficult to hijack.
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.