DroidDreamThe problem of mobile malware has evolved along with mobile devices for over a decade. Early examples of mobile malware either were proof of concept and merely spread for the sake of propagation or contained overtly malicious payloads. These pieces of malware were likely created out of misplaced intellectual curiosity or to increase the notoriety of their authors. Consider LibertyCrack, a Trojan horse masquerading as pirated software for Palm OS devices (identified in 2000), that performed an unwanted “hard-reset” of the device to restore it to factory defaults when executed. Or consider the first known computer worm affecting mobile devices: Named Cabir, it spread to other Symbian devices by sending itself within an SIS file to nearby devices via Bluetooth for the sole purpose of displaying the author’s virus writing group’s name. The source code for Cabir was released by the 29A virus group in 2004, and a number of variants by other authors using similar propagation techniques quickly appeared in the wild. What could possibly go wrong if you develop a mobile operating system that allows receiving installation scripts from nearby devices via a wireless technology? Granted, the victim had to agree to install the installation script, but a percentage of users will always agree to do something without understanding the security implications. Therefore, mobile operating system designers should carefully consider these design choices.
As with the evolution of malware on other platforms, and the hacking scene in general, there was a clear shift from developing mobile malware for fame, an intellectual challenge, or schadenfreude, to developing mobile malware designed to conduct toll fraud or bank fraud. Early examples of fraudulent mobile malware include Redbrowser, which was identified in 2006 and was a Trojan horse affecting J2ME devices that sent SMS messages to premium-rate Russian numbers, thus running up the victim’s phone bill. Even early on abusing premium-rate telephone services became a common theme in mobile malware, while bank fraud followed later as mobile banking and the use of mobile devices as a secondary authentication factor slowly gained in popularity.
In this chapter, we’ll first explore malware that affects the Android platform and then briefly discuss iOS malware, or the lack of it so far, and then conclude with a discussion of the possible reasons for the lack of malware on the iOS platform compared to the Android platform. The malware examples discussed in this chapter were selected because they are representative of a far larger set of malware that affect mobile devices. Each malware described takes a unique approach to violate the victim’s privacy, conduct fraud, disrupt the victim’s device, or conduct malevolent pranks by exploiting features distinctive to the mobile space.
Given Android’s large market share, that it has been targeted by malware authors is not surprising. According to a report from F-Secure, 79 percent of all mobile malware in 2012 was targeted toward Android (f-secure.com/static/doc/labs_global/Research/Mobile Threat Report Q4 2012.pdf). We’ll take a look at why Android is such a large target compared to other mobile OSs later in this chapter.
Now let’s look at some specific examples of Android malware.
DroidDreamAlthough most Android malware is distributed by third-party application marketplaces or requires the user to download and install it manually, the DroidDream family of malware was primarily distributed by the Google Play store. Various legitimate applications from the Play store were repackaged to include DroidDream and then put back in the Play store. Users downloaded this software believing it to be safe since it came from a trusted source. An application repackaged to include DroidDream requires a large number of dangerous permissions, as shown in Figure 5-1, which is one indicator that something may be wrong. However, users may ignore the installation prompt or not understand what the requested permissions allow and proceed with the installation.
Figure 5-1 Permissions requested by a repackaged application containing DroidDream
Once the application is launched, the Setting service is created, followed by the actual application. The Setting service attempts to send some information about the infected device to a remote server whose address is hard coded into the application. As you can see in the following code, the device’s International Mobile Station Equipment Identity (IMEI), which is used to identify a specific mobile device on the network, and the user’s International Mobile Subscriber Identity (IMSI), which is used to identify the mobile subscriber, along with two other values (Partner and ProductID) are sent to the remote server.
The following code snippet was recovered from a DroidDream sample using the techniques outlined in Chapter 4. Unless otherwise noted, all of the Android malware code snippets in this chapter were recovered from actual malware samples.
After contacting the server, the next step is to root the device. DroidDream includes two different root exploits. The first exploit, known as RageAgainstTheCage, exploits a vulnerability in the Android Debug Bridge Daemon (adbd). The second exploit, exploid (CVE-2009-1185), exploits a vulnerability in the way Android handles udev. Both of these exploits were fixed in Android 2.2.2 (Froyo). Devices running a version of Android prior to 2.2.2 are likely vulnerable to at least one of these exploits.
Once DroidDream has root access, it proceeds to install another application that was packaged with it. It copies the file sqlite.db from the assets directory to /system/app/ DownloadProvidersManager.apk. This application allows DroidDream to download new updates or additional applications silently.
At this point, DroidDream now has full control over the infected device. With root access and the ability to download and install new packages as directed by the Command and Control (C&C) server, the malware can perform any actions, such as stealing account information or SMS messages. As with traditional malware, the C&C server is in charge of managing the malware once it is registered by sending commands to infected devices and recovering information sent by the malware.
Once Google was made aware of the DroidDream threat, the repackaged applications housing it were quickly removed from the Play store. Symantec estimated, however, that anywhere from 50,000 to 200,000 users were infected while the applications were available. DroidDream continued to be available on various third-party application marketplaces even after it was taken down from Google Play.
NickiSpyMobile phones continue to become more powerful and add more features. With the ability to record sound, pictures, and location information via GPS, a smartphone knows a lot about its user. Combine that with an Android application’s ability to recover SMS messages, listen to phone calls, and read files stored on the file system, and you have a powerful tool that can be used to spy on unsuspecting users. NickiSpy and its variants make use of this fact to literally spy on their victims.
Like other mobile malware, NickiSpy is commonly packaged into other popular software. Once the victim installs the malicious application, NickiSpy stays dormant, waiting to receive the android.intent.action.BOOT_COMPLETED broadcast from the system, meaning that the malware does not activate until the device has been rebooted. Upon rebooting, the malware sends an SMS message to a hardcoded C&C number along with the device’s IMEI number. The variant described here (referred to as NickiSpy.B) then immediately begins gathering information about the victim, although other variants may wait for a command SMS before initializing. The malware then waits to receive additional commands via SMS.
Figure 5-2 shows the services created by NickiSpy when the device reboots.
Figure 5-2 NickiSpy services start when the device boots.
MainService is the heart of the malware. It starts the various spying services depending on its configuration, which can be updated via SMS commands. In this sample, all the services were started by default. The first, GpsService, makes use of Android’s LocationManager to get the device’s location.
The location information is then uploaded to the remote server defined by the malware’s configuration stored in the shared preferences XML file, named XM_All_Setting, by the SocketService class.
The XM_SmsListener class, as the name suggests, is responsible for recording SMS messages by registering a ContentObserver to watch the SMS ContentProvider. When a new SMS message is sent or received, it is forwarded to the remote server by the SocketService. Finally, the XM_CallListener, XM_CallRecorderService, and RecordService services are responsible for recording calls made by the device. XM_CallRecorderService watches for new phone calls by using a PhoneStateListener. When it detects a new phone call, it calls RecordService to record the call to a file:
RecordService uses a MediaRecorder to record the call audio by using the microphone. This is configured by using setAudioSource() with a value of MediaRecorder.AudioSource.MIC, which is equal to one. It then writes the call audio to a file, which triggers the XM_CallListener class to send the recorded call and information about the call from android.provider.CallLog to the remote server via the SocketService. Some variants of NickiSpy use this functionality to record sound when the phone is not in use. The malware waits until it sees the screen has turned off, and then turns on the microphone and records the sound input to a file while making sure the screen remains turned off. Android 2.3 (Gingerbread) removed the ability for an application to change the phone state without user interaction, so this attack is no longer possible.
NickiSpy was never discovered in the Google Play store, but it did appear in various third-party marketplaces. Although it did not have the ability to root devices remotely like DroidDream, it was still able to compromise the device in a significant way using features available to any application.
SMSZombieSMSZombie was discovered on the popular third-party Chinese application marketplace GFan. The malware targets China Mobile users, and once the malware has infected a device, it attempts to make fraudulent payments using the China Mobile SMS Payment system.
The malware is packaged inside a variety of live wallpaper applications. When installing these applications, no permissions are requested during installation, which makes it difficult for a user to determine whether the application is malicious or not. Once the application is installed and the user chooses it as the active live wallpaper, the application checks to see if the malware payload has been installed. If it has not, then the jifenActivity class is loaded. This class first extracts a second APK file from an image in the assets folder:
After retrieving the second application, the jifenActivity class creates a dialog box, asking the user to install another application in order to receive 100 points (With Google Translate, we got this message: “Please install the program can be Take 100 points to earn points After the game permanently”). The Cancel button on the dialog box has been disabled in an attempt to force the user to proceed with installation:
If the user does manage to back out (by pressing the Home key), he will be prompted with the dialog box again, as jifenActivity checks to see if the malicious payload has been installed every few seconds.
Once the user clicks OK, the application installation screen appears, where the user is prompted to install another application with a large list of requested permissions, as shown in Figure 5-3.
Figure 5-3 Permissions requested by the malicious application
Once installed, the SMSZombie malware attempts to become the device administrator. The user will continue to be prompted to allow this until he or she presses Activate, as shown in Figure 5-4. The Android Device Administrator API allows an application to perform a number of otherwise protected actions, such as setting the password policy for the device, locking the screen, forcing the use of encryption, disabling the camera, or even wiping the device! Once the application has become a device administrator, it is now virtually impossible for the user to uninstall the malware, as Android will not allow the user to uninstall an application that is an active device administrator.
Now that the malware is installed, it sends an SMS message back to a hard-coded phone number stating whether the device is rooted or not. SMSZombie does not have the capability to root the device, but checks to see if the device is already rooted by attempting to execute the su binary. An XML file called phone.xml is then created. This file contains the phone number SMSZombie will send messages to as well as a list of keywords.
SMSZombie sends all SMS messages currently on the device to the target phone number listed in phone.xml. When a new message is received, it first checks the list of keywords in phone.xml. If one of the keywords is found, the message is forwarded to the target phone number and deleted from the device. Otherwise, the message is forwarded but not deleted. This allows the malware to keep messages related to financial transactions hidden from the user, so fraudulent transactions are not immediately noticed.
ZitmoAs Zeus and similar banking Trojan horses became more popular, banks began to rely more heavily on two-factor authentication to prevent man-in-the-browser (MiTB) attacks. During a MiTB attack, a Trojan horse installed on a victim’s computer hooks multiple Windows API calls associated with networking, such as HttpSendRequestW from wininet.dll, to intercept information between the browser client and the target web server. This technique allows the attacker to easily intercept and manipulate HTTP requests and responses associated with a banking web application served over HTTPS regardless of the browser used, assuming the correct APIs are hooked, in order to steal banking credentials and display false information to the user while criminals conduct fraudulent transfers using captured credentials.
To initiate a bank transfer using a mobile device as the secondary authentication factor, a consumer first logs into the banking web application on her desktop computer and sets up the transfer information. Then the bank sends an SMS text message, which includes the mobile transaction authentication number (mTAN) to the consumer’s mobile device. The consumer then types the mTAN into the banking web application on the desktop computer to initiate the transfer.
With these new mitigations in place, attackers began to explore how to circumvent this type of two-factor authentication to transfer money from the victim’s banking account to a Romanian bank account at a time of their choosing. Working in concert, the Zeus and Zitmo malware is one simple solution to their problem.
The attack begins when the victim’s desktop computer is infected with the Zeus Trojan horse. Attackers typically use browser exploit kits, such as the Blackhole exploit kit, or targeted phishing campaigns to infect their victims’ machines. The next time a victim logs into a banking web application, Zeus manipulates the bank’s HTTP responses to encourage the user to install a mobile security application written by Trusteer onto the user’s Android device. Obviously, this malware is not written by Trusteer, who does produce security software in the mobile space, but the victim is tricked into installing a malicious APK on his mobile device by typing a URL into the mobile browser. After installation, the victim will notice a new application called “Trusteer Rapport” on his device, as shown in Figure 5-5. Because Trusteer is a well-known security firm and the link to the APK comes from a trusted banking domain over HTTPS, victims are likely to fall for this deception.
Figure 5-5 Zitmo appears as the “Trusteer Rapport” application.
The victim is then asked to start the application and enter the activation code provided by the Android application into the banking web application. This step is irrelevant and is designed to make the victim feel all warm and fuzzy inside, but actually the malware now has the capability to monitor SMS and send the data to an attacker-controlled server to capture mTANs. By reviewing the AndroidManifest.xml file, we can determine that the malware has the capability to access the Internet (android.permission.INTERNET), to receive SMS (android.permission.RECEIVE_SMS), and to read the phone’s state (android.permission.READ_PHONE_STATE). The activation code shown to the user is either based on the IMEI or ESN returned by the getDeviceId function associated with the TelephonyManager class, as demonstrated by the following code located in the com.systemsecurity6.gms.Activation class. Because we are analyzing the malware using an emulator that does not have a device identifier, the activation code will be all zeros, as shown in Figure 5-6.
Figure 5-6 Zitmo generates an activation key based on the device identifier.
To catch incoming SMS text messages, Zitmo registers a BroadcastReceiver called SmsReceiver that listens for android.provider.Telephony.SMS_RECEIVED actions and sends the protocol description units (PDUs) to the MainService class for further processing, as shown in the following code:
Then the MainService class extracts out the SMS message and originating address by creating an android.telphony.SmsMessage object based on the PDUs, acquires the device ID (IMEI or ESN), and then sends this information to the ServerSession class. The ServerSession class then sends all this information to an attacker-controlled web server (softthrifty.com) as shown in this code via an HTTP POST request:
To test this malware, we simulate sending inbound SMS text messages to the emulator using a telnet client, and then intercept outbound HTTP requests using a web proxy tool to verify that the malware sends this information to an attacker-controlled server. Follow these steps to send SMS text messages to your AVD:
1. Specify both the AVD and web proxy information as command-line arguments to the emulator command:
2. Determine which port the emulator is listening on. The devices command shows a list of connected mobile devices or running emulators. If the name of the emulator is emulator-5554, then you know that you can connect to this port via telnet.
3. Use a telnet client such as PuTTY to connect to localhost using the proper port number to connect to the Android console.
4. Send an SMS message to the device to see how Zitmo responds (see Figure 5-7):
Figure 5-7 The Android console allows us to send SMS text messages to the emulator.
As expected, Figure 5-8 shows that the malware sends the incoming SMS text messages (b0), the originating address (f0), and the device identifier (pid) to the attacker-controlled web server (softthrifty.com), which would compromise any mTANs generated by banks along with any other SMS text messages destined for the victim’s device. Since the domain is no longer active, we simply modified our host file so the emulator would resolve softthrifty.com to 127.0.0.1. Alternatively, you could use a network sniffer, such as Wireshark to monitor the traffic, but we know from static analysis that this version of Zitmo uses HTTP to exfiltrate data.
Figure 5-8 Using Burp Proxy to intercept HTTP traffic between Zitmo and the attacker-controlled server
The version of Zitmo that we analyzed is rudimentary, especially when compared with its Blackberry cousin, but later versions of Zitmo gained additional functionality. Newer versions of the malware can be remotely turned on or off via SMS, and the hardcoded C&C number can be changed via SMS. Additionally, the victim’s SMS text messages are exfiltrated via SMS as opposed to HTTP, and the malware authors changed their disguise from “Trusteer” to the “Android Security Suite Premium” and later to “Zertificat.”
It is unclear why the malware authors switched to using the text messaging service as their means of data exfiltration, since the use of a C&C number has some clear disadvantages because consumers can review SMS billing information through their MNO. However, the attackers might believe that their C&C web servers are more likely to be taken down than their C&C numbers or that C&C numbers might be easier and cheaper to set up.
Regardless of the network protocols used, the malware’s basic premise has stayed the same. Steal mTANs and profit. One successful campaign of targeted attacks reportedly netted 36 million euros for the thieves (threatpost.com/en_us/blogs/zitmo-trojan-variant-eurograbber-beats-two-factor-authentication-steal-millions-120612).
FakeTokenThe primary goal of most banking mobile malware is to work in concert with traditional banking Trojan horses to compromise the secondary authentication factor, such as mTANs. In the previous section, we explored how the Zitmo malware works with the Zeus Trojan horse, but authors of other popular crimeware have quickly followed suit. For instance, the Spitmo malware also compromises mTANs using a similar approach on Android devices and works with the SpyEye Trojan horse. There’s also Citmo that compromises mTANs and works with the Carberp Trojan horse. Citmo was found on Google Play, which raises concerns about Google’s ability to police its official marketplace effectively, but automated malware analysis is not a particularly easy problem to solve—especially when some of the mobile malware mimics functionality available in legitimate SMS management applications.
FakeToken works differently than Zitmo, Spitmo, and Citmo by attempting to compromise multiple forms of authentication factors on the mobile device to avoid having to compromise the victim’s computer and mobile device. Allegedly, the malware was distributed through phishing campaigns against consumers or by utilizing previously infected computers similar to how Zeus and Zitmo work. After installation, the victim will notice the TokenGenerator application on her mobile device, as shown in Figure 5-9. In this case, the malware reuses the Santander Consumer Bank’s logo, which is a major bank in Spain. Other versions of the malware reused Banesto and BBVA logos, which are also both major banks in Spain.
Figure 5-9 FakeToken appears as the TokenGenerator application using Santander’s logo.
During installation, the malware requests the following permissions, including a number of suspicious ones, such as the capability to install and delete new applications, to send and receive SMS messages, and to receive the boot completed event:
• android.permission.READ_PHONE_STATE
• android.permission.ACCESS_NETWORK_STATE
• android.permission.RECEIVE_SMS
• android.permission.INTERNET
• android.permission.WRITE_EXTERNAL_STORAGE
• android.permission.INSTALL_PACKAGES
• android.permission.DELETE_PACKAGES
• android.permission.READ_CONTACTS
• android.permission.RECEIVE_BOOT_COMPLETED
The INSTALL_PACKAGES and DELETE_PACKAGES permissions are both “signatureOrSystem” permissions, which means that only applications installed on the system partition or applications signed with the firmware’s signing key can successfully request these permissions. Therefore, the FakeToken malware will thankfully not be granted these dangerous permissions that allow for silently installing and uninstalling software. The malware authors were likely confused about Android’s permission model. Some malware have successfully requested this permission, such as the jSMSHider malware, which exploited the fact that some custom ROMs are signed with a publicly known private key in order to gain elevated privileges by reusing the known private key to sign jSMSHider.
When the user starts the application, the FakeToken malware allows the victim to type a banking password into a legitimate-looking user interface in order to generate a token, as shown in Figure 5-10. The malware authors opted to use a WebView component to create the user interface, as shown in the following code, from the MainActivity class. Interestingly, they set up a JavaScript interface to allow the JavaScript code in the WebView component to call Java functions exposed by the WebApi class and any other Java function using reflection. This bridge between JavaScript and native mobile code within the malware is used for communicating information such as the fake token value or the victim’s password. Legitimate applications that create bridges between JavaScript and native mobile code often contain JavaScript injection vulnerabilities, which allow for trivial exploitation and full control over the host application.
Figure 5-10 FakeToken generates a random authentication token using a pseudorandom number generator.
After the victim clicks the “Generar” (generate) button, the JavaScript code invokes Java code by calling the WebApi’s sendPass function. This function then sends an SMS message to the attackers that includes a prefix value (stored in an XML configuration file), the IMEI, the IMSI, and the user-entered password via the MainService class, which, in turn, uses Android’s SmsManager class. At this point, the JavaScript code also invokes WebApi’s getToken function in order to acquire a randomly generated token and displays this value within the WebView component with the intention of pretending to be a working security product. Additionally, the password is also sent to the C&C web server defined in the XML configuration file.
To capture mTANs, FakeToken sets up a BroadcastReceiver to capture incoming SMS text messages similarly to Zitmo, but only forwards them to a phone number via SMS and to the C&C server via a multipart/form-data POST request, if the recipient phone numbers are on the “catch” list. The malware authors appear to be interested only in SMS messages from select banks as opposed to the SMS messages that you receive from your family, friends, and enemies. The malware periodically polls the C&C server in order to update the server used, the phone number used to capture mTANs, the “catch” list, and the “delete” list, which is used to suppress incoming messages, such as warnings from a financial institution about pending transactions.
Interestingly, the malware supports a number of other commands such as the ability to send the victim’s contacts (list of phone numbers) to the C&C server and the ability to download an APK from a remote server to the SD card for installation at a later time. The latter feature is probably used to update the malware to the latest and greatest version, or to install other malware or root exploits. The following code shows how the malware downloads the APK to the SD card within the MainApplication class:
A custom update screen is later displayed to convince the user that she needs an updated version of the software. When the victim clicks the only button on the screen, the normal Android application installation process starts. The victim then has to agree to install the malicious update after reviewing the requested permissions, since the malware was unsuccessful at acquiring the INSTALL_PACKAGES permission, as mentioned earlier. Additionally, the victim also needs to change her device’s security setting to allow installation of APKs from unknown sources unless she already performed this step when installing FakeToken in the first place.
As the popularity of mobile banking and the use of mobile devices as secondary authentication factors increase, we expect that malware authors will continue to develop mobile banking malware of increasing complexity that attempts to compromise multiple authentication factors similarly to FakeToken as long as they continue to profit. So expect more in the future.
In response to the large amount of malware targeting Android, Google announced in February 2012 that it had created an automated tool called Bouncer to scan all apps submitted to the Google Play store for malicious functionality (googlemobile. blogspot.com/2012/02/android-and-security.html). Although Google did not go into the specifics of how Bouncer worked, researchers quickly began testing it. Jon Oberheide and Charlie Miller showed that Bouncer ran applications in a custom emulator, and they were able to gain remote access to the Bouncer environment (http://jon.oberheide.org/blog/2012/06/21/dissecting-the-android-bouncer/). Other researchers from TrustWave’s SpiderLabs tested the effectiveness of Bouncer and found ways to hide malicious code from Bouncer by looking for telltale signs that their application was running in Bouncer and not executing malicious code unless installed on a non-Bouncer device (media.blackhat.com/bh-us-12/Briefings/Percoco/BH_US_12_Percoco_Adventures_in_Bouncerland_WP.pdf). It appears that Bouncer relies on dynamically testing applications for suspicious behavior rather than performing static analysis on applications.
Even though Bouncer can be tricked, its release shows that Google is aware of the malware problem on Android and is taking steps to address the problem. In Android 4.2 (Jellybean), Google added another protection against malware by implementing the Application Verification Service. This feature is enabled, by default, on 4.2 devices, but the user can turn it off. This feature scans all applications being installed on the device, including applications from third-party marketplaces and other sources, and either notifies the user or blocks the installation outright if it detects a malicious application. A study done by Xuxian Jiang showed that this application verification service was less effective than existing Android antivirus software (www.cs.ncsu.edu/faculty/jiang/appverify/).
Although these current countermeasures still fall short of their goal of preventing malware from reaching Android devices, they are a step in the right direction and should help to reduce the amount of malware successfully being installed on Android devices. Hopefully, Google will continue to improve its ability to combat malware by improving the Bouncer and Application Verification Service or by introducing other mitigating controls since the problem of malware infecting Android devices has become significantly worse over the last couple years. Trend Micro noted in their 2012 Mobile Threat and Security Roundup report that it detected 350,000 malicious Android application samples in 2012 but only detected 1,000 samples in 2011. The significant increase in mobile malware targeting Android users is quite a disturbing trend that hopefully will be curbed in the future.
While Google has been plagued with malware in both Google Play and third-party Android markets, Apple has so far been relatively unscathed. There have only been a handful of notable malware affecting iOS devices and most of the malware to date has targeted jailbroken devices. We explore possible reasons for the lack of malware on iOS devices later in this chapter because that discussion is more complicated than simply claiming that Apple has better platform security.
The first malware discovered on iOS devices was discovered in June 2009 and disguised itself as “iPhone firmware 1.1.3 prep” software. It stated that it was “an important system update. Install this before updating to the new 1.1.3 firmware.” After uninstalling this firmware “prep” software, a number of common utilities installed on jailbroken devices would stop working properly, such as Doom, Launcher, Erica’s Utilities, and SSH, which caused users a minor annoyance by forcing them to reinstall these utilities. Because this Trojan was found on a third-party repository, it posed no threat to devices that had not been jailbroken. Supposedly, members of the ModMyiFone forum tracked down the father of the author of the malware by calling the phone number listed on the domain registration. The author turned out to be an 11-year-old kid, or so claimed the person on the phone.
After jailbreaking an iOS device, many users install a SSH daemon on their phone in order to control their device remotely, but some users forget to change the default password, which is set to “alpine” (Apple’s codename for iOS 1.0). In early November 2009, a Dutch teenager scanned for iPhone’s on T-Mobile’s 3G IP range and exploited this vulnerability to install ransomware on users’ mobile devices. The ransomware displayed a message stating that “your iPhone’s been hacked because it’s really insecure! Please visit doiop.com/iHacked and secure your phone right now!” When victims visited the website to learn how to “secure” their phone, they were instructed to pay $4.95 via PayPal to acquire information about how to change their root password and remove the malware. The Dutch teenager quickly apologized for his unethical behavior and later offered information about how to change the root password and remove the ransomware for free.
Later in November 2009, an Australian teenager, Ashley Towns, released the first worm to target iOS devices by exploiting the same the SSH vulnerability. This worm, dubbed iKee, was relatively harmless and somewhat amusing compared to other mobile malware since it only changed the user’s wallpaper to a picture of Rick Astley and then attempted to find other vulnerable iOS devices in specific IP ranges. We explore the details of this worm in the next section. Within weeks, an unknown malicious actor created another worm, labeled duh or iKee.B, since it was believed to be based on IKee, which exploited the same SSH vulnerability, but included command and control functionality that allowed the attacker to execute arbitrary shell commands on the victim’s iOS device, thus creating the first iOS botnet for the purpose of data exfiltration.
In July 2012, the first iOS malware/spyware was discovered in the Apple App Store. Named Find and Call, the malware also made an appearance in Google Play. Once the application is run by the user, Find and Call uploads the user’s contacts to a web server. Once the web server has the victim’s contacts and phone number, the web server proceeds to launch an SMS spam campaign against all of the contacts. Each contact receives an SMS message with the “From” field set to the victim’s phone number so the SMS message appears to originate from a friend. The SMS message contains a link to download the Find and Call application. There has been some active debate over whether this application should be classified as malware because it only attempts to boost installations via deceptive SMS spam. While this application is certainly not as harmful as banking malware, or as invasive of victim’s privacy as NickiSpy, an application that launches SMS spam campaigns against your friends without your knowledge should not be tolerated in either the Apple App Store or Google Play.
iKeeAs mentioned earlier, the first worm to hit iPhones, named iKee, appeared in November 2009, and its purpose was to “rickroll” victims by changing their background image to an image of Rick Astley, a 1980s British pop star, and to disable their SSH daemons. An Australian teenager admitted to creating the worm along with the initial infection of about 100 mobile devices. Given the fact that the worm only affected jailbroken devices with an unchanged root password and running SSH daemon, it is surprising that the worm was able to infect 17,000 to 25,000 devices in a short period of time. Local law enforcement took no interest in pursuing criminal charges, and the malware author even got a job offer as an iOS developer owing to the notoriety shortly after the release of the worm.
The worm is designed to scan for devices in the 3G IP range, in the IP ranges controlled by a number of MNOs such as Vodafone, Optus, and Telstra, in part of the private IP address space, and also some random IP ranges. Given the heavy focus on targeting Australian MNOs, the vast majority of the infections were reported in Australia, but there were reports of iPhone infections in other countries. The following C code snippet shows the IP ranges that the worm targets. AT&T’s network was apparently deemed “TOO BIG” to attack.
To determine whether a scanned host is vulnerable, iKee simply uses the sshpass utility, which connects to a host via SSH in a noninteractive mode, to run the echo command on the victim’s iOS device. The worm only tries one password defined by the VULN_PASS constant, which is set to the default root password that we previously mentioned is “alpine.” Thankfully, the worm did not attempt a more complicated attack by launching an online dictionary or brute-force attack against the root account. If the command executes successfully on the remote host, then iKee will know because the output from the sshpass utility will be “99” since that was the command-line argument provided to the echo command. The following C code snippet demonstrates the process of determining whether the scanned host in question is vulnerable:
After determining that an iOS device is vulnerable, iKee runs a series of commands to propagate itself to the new host. First, the worm deletes the sshpass utility (/bin/sshpass) and the worm itself (/bin/poc-bbot) from the remote host. Next, the worm copies the sshpass utility and the worm itself from the current mobile device’s file system to the remote host’s file system. iKee then copies an image to the remote host (/var/log/youcanbeclosertogod.jpg) to replace the background image (/var/mobile/Library/LockBackground.jpg). The image’s filename (youcanbeclosertogod.jpg) is most likely a reference Nine Inch Nails’ ode to self-loathing sexual activity or a failed attempt to spread the word of God via a computer worm. Then, the worm copies over its daemon configuration file (/System/Library/LaunchDaemons/com.ikey.bbot.plist) and executes the worm on the remote host. Additionally, the worm prevents further exploitation of the vulnerability by other malicious actors, or a reinfection by similar worms, by deleting the SSH daemon’s configuration file (/Library/LaunchDaemons/com.openssh. sshd.plist) and killing the SSH daemon (sshd). At this point, the remote host is now infected and scanning for other victims in the defined IP ranges. The process of propagating to a new host is demonstrated by the following C code snippet. The author apparently did not want to perform the last operation, which involves deleting the SSH daemon’s configuration file, as shown in his commentary that states that “I didn’t want to have to do this.”
The next time the victim views his or her iPhone, Rick Astley will be the new background image, as shown in Figure 5-11. This payload is clearly a joke and not particularly malicious, but it does eat up users’ monthly data allowances and causes the victims to have to figure out how to remove the malware and reinstall the SSH daemon, thus infuriating a large number of people. Earlier variants of the worm had a bug, which caused the victim’s original background image to be copied over to a newly infected remote host instead of a picture of Rick Astley. This buggy version of the worm was dubbed the “Asian Child” virus, because the iKee worm started spreading with an image of an Asian baby’s face by accident. The Australian malware author claimed that the purpose of the worm was to raise awareness about how many people do not change their root password after installing the SSH daemon from Cydia. Future iOS malware may not be as forgiving as iKee, as demonstrated by the duh malware (IKee.B), but so far Apple’s mobile platform has been largely untouched by crimeware, which is strange given its sustained popularity.
Figure 5-11 iKee changed the user’s background to “rickroll” the victim.
The lack of malware seen on iOS devices and the multitude of samples identified on Android devices have prompted some to proclaim that Apple has developed a more secure platform, but we feel the situation is a little more complicated. The following are some of the reasons for the difference in the amount of malware seen on the two platforms:
• Market share There is a reason that malware authors target Windows systems more often than Mac OS X systems. According to Strategy Analytics, Android’s share of the global smartphone market grew from 49 percent in 2011 to 70 percent in 2012. Apple’s iOS continues to be a strong contender by capturing 22 percent of the market share in 2012, but Apple’s market share is nowhere near Google’s in 2012. To maximize their return on investment, most malware authors looking to commit toll or banking fraud will continue to target Android devices as long as Google continues to dominate the market, just like malware authors targeted the Symbian platform when the Symbian OS had a significant market share years ago.
• Application approval process After paying a one-time developer registration fee of 25 dollars, anyone can upload an Android application to Google Play. Within 15 to 60 minutes, the Android application appears in the Google Play store. Google relies on an automated malware detection system named Bouncer to detect and remove malicious applications after submission into Google Play. As mentioned previously, a number of security researchers have questioned the effectiveness of Bouncer and, in some cases, have published research illustrating potential deficiencies, but we doubt anyone would be surprised by the conclusions that an automated malware analysis system can be defeated by a dedicated malicious actor. On the other hand, Apple performs an automated review via static analysis tools to detect improper API usage and performs a manual review of submitted applications, so the approval process usually takes about a week. Additionally, developers are required to pay a 99 dollar annual developer fee, thus creating a slightly higher barrier to entry. We could argue that Apple’s more stringent registration and review process reduces the amount of malware found in its application store, but the thoroughness of their review in relation to identifying vulnerable or malicious code in submitted iOS applications is unknown.
• Support for third-party application stores Android devices support installing applications from unknown sources, which means that users can install software from third-party application stores and users can be tricked into installing malware from a hostile website. The ability to install software from unknown sources is not enabled by default, but many users enable this setting and users can also be tricked into changing their security settings. Although Android will not install unsigned APKs, Android does not actually care who signs the application—so Google, or some other trusted party, does not need to sign the Android application. Apple, on the other hand, only allows users to install iOS applications from its App Store or an enterprise application store (assuming the proper enterprise provisioning profile is installed on the device). The iOS kernel enforces this restriction by only executing code signed by an approved party. Users must jailbreak their iOS device to install software from a third-party application store. Undoubtedly, malicious actors could attempt to trick users into jailbreaking their iOS device and then installing malware, but this step is unnecessary on Android devices.
Apple’s walled-garden approach and its strict code-signing mechanisms certainly have benefits when it comes to reducing the amount of malware on its platform. But Google is unlikely to adopt a similar walled-garden approach because countless Android users would feverishly oppose such changes that hinder openness. They do, however, expect improvements to Google’s automated malware analysis via Bouncer and the Application Verification Service, and improvements to their platform’s code-signing capabilities to combat the emergent problem.
As mobile platform security has continued to mature, so have malware authors. The increase in forms and variants of malware and their complexity continue to outpace the development of preventative measures. Android’s preventive measures are becoming more robust, although Android still has a long way to go to reduce the amount of malware currently available. Though iOS has so far been spared the brunt of the malware attack, we expect to see an increase in malware targeting the platform as mobile malware authors continue to produce more sophisticated software and the number of jailbroken devices increases (the evasi0n jailbreak for iOS 6.1 was downloaded over 5 million times in the first 48 hours after it was released, to give you some idea of how popular iOS jailbreaking is). As the players on both sides continue to adapt, expect to see some interesting attacks in the coming years.
