The new iBotnet

Recent weeks have seen the discovery of a new piece of malware affecting the Apple operating system. This article will take a detailed look at what appears to be the first real attempt to create a Mac botnet.

The malware variants are OSX.Iservice and OSX.Iservice.B; they are both Mach-O format universal executables designed to run on Apple operating systems.

The main binaries are almost identical, but what differs between them are the ways in which they are distributed and installed on the victim system.

The variants have been found inside bogus copies of iWork ’09 and Adobe Photoshop CS4 which were shared on the popular p2p torrent network. The author of the malware downloaded the original/trial versions of each program and introduced a copy of the malicious binary into the packages. Users who then downloaded and installed the applications from the torrent download would have been infected (see Figure 1). It is estimated that thousands of people have downloaded the infected torrent files.

Figure 1. Users who downloaded and installed iWork ’09 and Adobe Photoshop CS4 from the torrent download were probably infected by the OSX.Iservice malware family.

The two variants use different techniques to obtain the user’s password, which is needed in order to execute the malware with full system privileges. Note that the malware will not run if it does not have root access.

The first variant, OSX.Iservice, was bundled within the rogue iWork ’09 installer. The malware author modified the mkpg package to include the ‘iWorkServices’ package (the malicious executable). In this case the malware gets an authenticated session through the installer itself.

In the second variant, distributed through the Adobe Photoshop CS4 torrent file, the trick is a little different. In this case the application package has not been altered. Instead, it is the crack for the application that contains the malicious binary, and once executed it will prompt the user for a password and install the trojan.

The binary that is executed by the OSX.Iservice.B variant is a dropper which performs the following operations:

The main malware binary is embedded in the __data section of the dropper.

We found the trojan’s second installation step very interesting: we discovered that it uses some of the internal functions of Mac OS that relate to the Authorization Services.

The Authorization Services APIs are used by applications in cases where certain functionalities are provided only to specific users with the relevant access rights on the system. The security agent is responsible for prompting the user for their password. It is possible to use the operating system’s authentication facilities to authorize specific applications (see Figure 2).

Figure 2. It is possible to use the OS authentication facilities to authorize specific applications.

Think about the Lock feature in System Preferences: whenever the user wants to make a change he has to provide his password. Every application has access to the Authorization Services API in order to use the OS itself for authentication. The dialog box can also be customized with an icon and a message that will be displayed before the standard text. In this case, the malware author has not customized the dialog box, and the trojan just prompts the user for the password (which may seem a suspicious request). However, with malware authors showing an increasing interest in the Mac platform, we believe that more advanced UI spoofing tricks may be seen in the future.

Figure 3. The dialog box requests the user’s password.

Of course, the whole authentication part could also have been spoofed [1].

When the malware starts, it checks for the presence of its own configuration file: /var/root/.iWorkServices (or /var/root/.DivX for OSX.Iservice.B).

The malware author wasn’t careful enough to remove all of the debug symbols, so some interesting strings such as ‘/Users/jason/diarrhea/aes/aes_modes.c’ are still visible in the code. Although it is not highly sensitive information, this gives us a clue as to the possible username of the creator, the name of the project and the use of the AES algorithm for encryption capabilities.

The configuration files are encrypted using AES with a static key for encryption and decryption. The same key is also used for encrypting and decrypting network traffic. Wrappers around the ‘recv’ and ‘send’ functions allow for the specification of whether or not the traffic needs to be encrypted/decrypted (Figure 4). Some of the malware’s functionalities, such as the peer-to-peer engine, make use of encryption, while others, like the http download routines, use plain text communications (for obvious reasons).

Figure 4. The malware has wrappers around the ‘recv’ and ‘send’ functions.

Although the use of AES makes the malware harder to analyse and will probably annoy network administrators who won’t be able to identify what kind of protocol it is, it is not at all secure. We believe it is possible to create network signatures for this threat since the encryption key is fixed and some invariant packets are sent and received by the trojan.

If the malware does not detect the presence of the configuration file, a new one will be generated.

After having parsed the configuration file the malware will attempt to contact the following hosts:

These hosts were probably the main core of the p2p network – the malware expects their response in order to start the p2p engine.

The botnet is based in a p2p network for communication, and messages exchange between all the infected nodes.

This method of communication is becoming increasingly popular with malware authors, since it provides a more secure channel to control the infected hosts than the usual ‘call to home’. It also allows the network to be kept alive even if the main servers are down – and makes it more difficult to track the controllers and the infected hosts.

Unfortunately, at the time of writing this article the main servers of the botnet were down, so it was not possible to join it in order to capture and analyse the traffic between the servers and other clients.

The p2p engine is built with LUA [2]. The malware author embedded a LUA interpreter and implemented some of the malware functions with it, so it is possible to script over them, and this gives the trojan good extensibility.

Every p2p command is initially registered in a table which holds a command name and a function pointer associated with the command. These functions are registered as LUA functions, thus all the botnet commands are LUA-registered functions (Figure 5).

Figure 5. All the botnet commands are LUA-registered functions.

Once all the commands are registered they can be used as if they were LUA functions.

The following is a list of all the commands that the bot supports. Some of them are part of the peer-to-peer engine itself and have not yet been fully analysed:

The configuration file has a very simple structure:

startup\x00shell(‘31337’)\x00p2pport\x0056620\x00

It expects a sequence of NULL-terminated byte tokens.

The startup token is used to specify a startup LUA code in the configuration file.

Only a few of the malware’s internal functions are bound to LUA and, in fact, the embedded interpreter does not even support the basic functions from the standard LUA libraries. Therefore, this startup code must only be composed of botnet-registered commands which will be executed in the malware loading process.

Another reason why we suspect that the malware author is an experienced programmer, and which also makes the malware harder to analyse and debug, is that almost every part of it is multi-threaded.

OSX.Iservice is an interesting piece of malware – not only does it make use of Mac OS internals, but it is also the first Mac botnet that we are aware of. The botnet was reported to have been performing a DDoS attack through a PHP script running on the infected machines [3].

We guess that the person who wrote the malware is not the same as the person who actually ‘used’ it. The code indicates that, wherever possible, the author tried to use the most flexible and extendible approach when creating it – and therefore we would not be surprised to see a new, modified variant in the near future.