Endpoint Protection

While analyzing the recent OSX.Iservice.B threat I noticed some interesting API calls that were dealing directly with the Mac OS X authorization mechanism. There are plenty of interesting analyses and discussion about Windows UAC, both regarding Vista (Ollie’s post) or the recent Windows 7 UAC.

 

The authentication mechanism is an important part of the overall OS security, especially when we’re talking about malicious code that tries to hide as real and safe applications in order to fool the end users. Before digging into details, I’d like to stress one fact: it’s not a vulnerability, but simply a feature of the OS that can be used and abused from a social engineering perspective in order to spoof the authentication dialog box.

With Mac OS, the phrase “yes, but it requires the password” has always been used for reducing the real impact of certain malicious code. This simple statement delegates the final responsibility of a risky decision to the user and as we know, the weakest point in this chain is always the human factor.

What if the window asking for the password can spoof itself as System Preferences, or perhaps Safari? This trick may sound obvious, but it’s the key that has made a lot of malware successful on Windows for years. Until now, malicious code affecting the Mac OS never cared much about user interface spoofing since most of them required the use of some vulnerability (Apls.Saprilt.A) in order to perform a privilege escalation, or they used some poorly coded apple script in order to prompt for a password (OSX.Saprilt.C).
 
However, the recent OSX.Iservice.B is using at least some internal API instead of relying completely on a bunch of system() and open(). In this case the malware author used the Authorization Services in order to ask for the password without the need for spoofing the dialog box. This clearly shows that Mac Trojans are slowly evolving in terms of complexity and “features.” It was around this point in time I decided to investigate the Authorization Services.

 

 

 

Figure 1: OSX.Iservice.B Authorization Services usage

In figure 1, above, we can see a piece of the recent OSX.Iservice.B Trojan that is invoking AuthorizationCreate() followed by an AuthorizationExecuteWithPrivileges(). You can find all of the information related to Authorization Services on the Apple developer website:

 

http://developer.apple.com/documentation/Security/Reference/authorization_ref/Reference/reference.html

 

“Authorization Services defines a programming interface that facilitates fine-grain control of privileged operations, such as accessing restricted areas of the operating system and self-restricted parts of your Mac OS X application.”

The idea behind the Mac OS authorizations is that if we want to provide certain functionalities through our application, but we want only certain users with specific rights on the system to be able to use those, we need to ensure that the users are going to authenticate themselves before being authorized to use that specific part of the application.

“Authorization is performed through an agent so the user doesn’t have to trust the application with a password. The agent is the user interface— operating on behalf of the Security Server[…] The Security Server—a Core Services daemon in Mac OS X that deals with authorization and authentication—determines whether no one, everyone, or only certain users may perform a privileged operation.”

The Apple developer website shows a perfect method of achieving this with some useful code snippets. What I find interesting is the following part:

 

AuthorizationItem myItems;
myItems.name          = kAuthorizationRightExecute; /* system.privilege.admin */
myItems.valueLength     = 0;
myItems.value         = NULL;
myItems.flags         = 0;

AuthorizationItem myAuthItems[2];
myAuthItems[0].name          = kAuthorizationEnvironmentPrompt;
myAuthItems[0].valueLength    = strlen(PROMPT);
myAuthItems[0].value         = PROMPT;
myAuthItems[0].flags         = 0;

myAuthItems[1].name         = kAuthorizationEnvironmentIcon;
myAuthItems[1].valueLength    = strlen(ICON)
myAuthItems[1].value        = ICON
myAuthItems[1].flags        = 0;

 

 

This piece of code is actually defining some custom aspects of the dialog box for the authentication process. It is possible to specify, for example, a custom message (kAuthorizationEnvironmentPrompt) that will get tacked on to the front of the standard message. One can also specify a custom icon (kAuthorizationEnvironmentIcon).

Wondering what all of this means? Let’s have look at two examples of a “customized” authentication dialog box:

 

 

 

Figure 2: Customized authentication dialog boxes

In the first picture we can see that there’s something wrong, probably because of the blank space before “This malicious application which will install a trojan …”[sic]. That blank space seems immediately suspicious ;-). In the second picture, it seems pretty clear that “System Preferences” is asking for our password. Well, in both cases it’s nothing more than a simple application that I wrote using the Authorization Services API, which is asking for the user password in order to perform privileged operations.

The impact—to make it simple—is that a malicious program can spoof itself as something else (for example, System Preferences) when it asks for the password in order to obtain full system privileges. Obviously this is a social engineering trick, but the “look and feel” of the dialog box, the icon, and the message all increase the effectiveness of this social engineering attack.

Is this all an obvious trick? I don’t think so, also given the fact that Mac users are not used to these types of “situations.” Windows users are more accustomed to thinking that their computers always need some kind of new codec or another, but that isn't usually the norm with Mac OS X.

How can users defend against this type of UI spoofing? One way for determining if we’re dealing with a real or a fake application is to click on the details and check the Application field (yes, users will need to take an extra step). In our case, by clicking on “System Preferences” we can verify the execution path of the real program asking for the password, which is definitely not the clean System Preferences Path:

 

 

 

Figure 3: Application execution path

The author of OSX.Iservice.B didn’t go this far in that implementation, but the fact that the program already uses Authorization Services could mean he or she is already headed down this path.

From now on, we advise that Mac OS X users don’t rely simply on familiar icons or messages from the authentication dialog box, but take an extra little step in order to verify the execution path of the program that is asking for the password. Furthermore, if we are prompted for a password by any Apple/clean/trusted application when we’re not really expecting it, checking for any suspicious running processes would certainly help.