Like the personal computer, the mobile smartphone is susceptible to various types of malware. Throughout this chapter, I will refer to malware and spyware collectively as malware. Even though I do this, it is essential to know the difference between each of these types of hostile applications.
Malware is defined as any piece of malicious software that lives on a user’s computer or smartphone whose sole task is to cause destruction of data, steal personal information, or gain access to system resources in order to gain full control of the device it is on. Malware is written with the sole intent of causing harm; and usually, malware authors will write the malware to target a specific weakness in an operating system or platform. Often, the malware author will want to maximize the spread of her malware and will look to implement a mechanism where his software can copy itself to other, similar devices.
Spyware is a term used to refer to malware that accesses and exfiltrates personal or private information from a device. For instance, in the case of mobile phone malware, the application may be after an end user’s e-mail messages, contact list, SMS messages, or even photos. Spyware generally needs to be stealthy and stay on the device for long periods. Thus, spyware authors will aim to perform little or no disruptive activity on the device, so that the end user is not aware of her data being stolen. Just about anyone can use malware; it is no longer a requirement that you know how to code the malware yourself.
Many companies sell malware to individuals, large corporations, or even governments (see the case study later on in this chapter). I have seen two types of companies selling malware: the ones that sell to large organizations or governments and the ones that sell to individual retail consumers. As we will review later in this chapter, one large Middle Eastern telecommunications provider was caught spying on its entire BlackBerry subscriber base. The software that helped do this was sold by a well known US company that specializes in legal interception. It turns out that the source code was completely developed from scratch, and its sole purpose was to capture and exfiltrate e-mail messages from an infected device.
On the other end of the spectrum, you will find the malware or spyware packaged and sold to any individual who is willing to spy on someone that she knows. In most cases, the companies that sell this type of software will proclaim “Catch cheating spouses!” Apparently, this is quite appealing to some folks! I will also look at one of these versions of retail malware in some detail.
We can classify malware operations into four different, but distinct, stages. While not formal, these stages have been visible in most instances where malware has been discovered on devices.
This is the stage where the malware is introduced to the device. The holy grail of infection is one where no end-user interaction is involved. This occurs when malware can be copied to a device by something as harmless as sending a user an SMS message or compromising the device when it is on a wireless network.
The second method of infection is through a partially assisted action. The user is asked to click a link in a malicious website. Once he does this, the malware will copy itself to the device. An attacker sends this link to a user in an SMS or e-mail message. While effective, this requires user intervention; in most cases, diligent users will always be suspicious about clicking random links sent to them.
The last form of infection occurs when an attacker will physically copy the malware to the device, either through a USB port or via browsing to a website. This takes place in instances where the attacker and end user know each other, or the attacker has physical access to the end user’s device. This technique is not effective if a user has password protected his device and requires a password to use it or install applications on it.
Most often, infection and compromise go hand in hand. In this context, I am using the word compromise to describe how the malware is able to gain super-user access to the device. As a result, the malware can make changes to the device configuration in any manner it chooses to do so—and without requiring device-owner interaction.
As we saw in previous chapters, programs running on Android will require a user to grant it explicit permissions to access facilities like the Internet or read e-mail messages. During the compromise stage, the malware will use a weakness in the operating system to circumvent the permission granting process, thereby allowing it to execute any function without the user being aware.
Unless specifically targeted at an individual, a malware author will typically want to infect a large number of users. He may want to control an army of devices or just access private information from many different people. The Zeus Trojan (found on the personal computer platforms) will spread using weaknesses found in the operating system. Its sole purpose is to collect a user’s keystrokes and collect credentials to banking and social networking websites.
Lately, another popular mechanism of spreading and even infection has been to use the Google Android Market (where authors can sell or freely distribute their applications). Malware authors can upload harmless looking applications like games or social network interaction tools to the Android Market. When an end user buys or downloads this app, her device is infected.
Malware will often target personal or confidential information. It may log keystrokes to try to capture usernames or passwords to websites like online banking and e-mail. However, simply collecting this information is insufficient. The attacker needs to have access to this information, so malware will find a way of “phoning home” or communicating with a remote server, either to receive new instructions or to upload the captured information. This stage is called exfiltration. Let’s take a look at a case study that illustrates how this can work.
Case Study 1: Government Sanctioned Malware
In July of 2009, a telecommunications provider for the United Arab Emirates (UAE), Etisalat, sent an SMS message to its entire subscriber base of BlackBerry device owners to download and install a system patch. This patch was purported to improve performance of the device’s 3G capabilities. It turned out that this “patch” was nothing more than malware designed to read each user’s outgoing e-mail.
To this day, the company maintains that the patch was meant to improve performance. Most of the researchers who examined the malware, including myself and Research In Motion (RIM), can see that there are no performance benefits whatsoever. Instead, examining the code reveals a deliberate attempt to capture all of the device owner’s outgoing e-mail and send a copy of it for examination to the provider’s servers.
The case title, Government Sanctioned Malware, may be a bit strong, especially when you consider that no conclusive evidence has materialized from the investigation of this case. My choice of title was based on the 11 years I spent working in the UAE (five of them for Etisalat), recent events in the media, and my knowledge of how closely the government and regulatory authorities control the media and communications infrastructure of the country.
The media events I mention took place around August of 2010, when the government of the UAE announced that it would shut down all BlackBerry services within the country if RIM did not provide a means of monitoring user messages, including e-mail and BlackBerry Messenger (a native messaging platform that allows BlackBerry users to send messages to each other). Since I’m not writing a spy novel, I’ll shelve all of my theories for my next book and instead take you through some of the more factual aspects of the malware itself. In this case study, we will try to uniquely identify the stages for malware infection.
Etisalat introduced the malware onto its subscriber’s devices by making use of a simple WAP-push message. This is a message that appears in the device’s SMS inbox, and it contains both text and a URL. The text of the WAP-push message was as follows:
Dear Etisalat BlackBerry Customer,
Etisalat is always keen to provide you with the best BlackBerry service and ultimate experience, for that we will be sending you a performance enhancement patch that you need to install on your device. For more information, please call 101
--
Empower your Business with BlackBerry® and Mobile Solutions from Etisalat
Once a user clicked the accompanying URL, the device would download and install and application called Registration. The device would prompt the end user to grant the application specific permissions. Since the WAP-push message arrived from a seemingly legitimate source, most users had no reason to distrust the request and often granted the application full permissions.
In this case, the malware did not rely on a weakness in the OS to gain access to personal information. The user, believing that the application was legitimate, granted all the necessary permissions during the installation phase.
The malware released by Etisalat was designed to remain on the device and collect information. It was not designed to spread to other devices. Rather than spreading, the malware relied on the WAP-push message. The installation would take place in one go and would not spread thereafter.
This is the most important stage for the Etisalat malware. It was designed to attach itself to the sent items of the user’s e-mail messages and send a copy of each outgoing message to a server inside Etisalat. This was taken care of by the built-in BlackBerry API calls.
An actual message (that the malware uses to check in with the server) is depicted in Figure 10-1. This is a message that is sent to the server every hour. The operators of the malware system can then see which devices are infected by the malware, including which of those are checking in regularly.
Figure 10-1. A captured “heartbeat” message as used by the Registration malware
This specific malware was only detected because it was badly written. As soon as the malware was released, the server that was supposed to receive the exfiltrated data was inundated with messages. Unable to bear the load, the server crashed. This caused the malware on the devices to constantly retry the connection to a non-responsive server. This continued set of connection attempts increased processor usage on the devices themselves.
At this point, end users began to notice sluggishness in their device performance and premature battery drain. Some users even noticed their device overheating. This prompted several researchers to investigate the Registration application, whereupon they discovered that it was really malware. Figure 10-2 shows a flowchart of how the malware operates when installed on a device. What follows is a detailed list of the characteristics of the Registration malware:
- It checks to see if it is listed as visible in the BlackBerry installed applications.
- If it is visible, it hides itself from view of the subscriber. This prevents a user from finding it and deleting it.
- It iterates over all the mail accounts on the handheld and attaches itself to each of them, looking for received e-mail messages and PIN messages.
- It intercepts and monitors the state of the handheld for network events that occur. It notifies the service-provider’s server when these events occur.
- It listens for messages received from specific addresses through either e-mail or BlackBerry PIN. These are control messages that can enable or disable the interception of the subscribers’ messages.
- It reports to the predefined service-provider server regularly.
- If enabled, the application will forward a copy of e-mails sent out by the subscriber to the service-provider server.
Figure 10-2. A flowchart of Etisalat malware operation
Case Study 2: Retail Malware—FlexiSPY
Now let’s look at a second malware application: FlexiSPY, a type of retail malware. FlexiSPY eavesdrops on all communications when an attacker installs it on the target device. The latest version of FlexiSPY Omni offers the following features to Android users:
- Capture SMS and e-mails
- Capture call logs
- Discover GPS location through GPS and cell tower information
- Turn the phone into a listening device
- Intercept phone calls
- SIM card change notification
This seems to be sufficient coverage for spying on anyone, and I found the list of features intriguing enough to acquire a copy and analyze it.
Note In the spirit of full disclosure, I’ll mention that, at the time that I reviewed FlexiSPY, I looked at the BlackBerry version because that was my primary phone. The protocols to activate and enable the device are all web-based, so they remain more or less the same, regardless of the supported device platform (including on Android, of course).
Once a buyer parts with her $349, she will receive a user manual that provides information on how the application can be installed on a target’s phone. When going through the user manual, one of the first things that jumped out at me was that it provided . . . explicit instructions to set the Default Permissions of the BlackBerry handheld to Allow All .
This means that, not just FlexiSPY, but every single application the target installs on his phone after this can gain full control (within the scope of the programming interface or API) over the handheld. Obviously, user protection is not a high priority in this case. In a similar twist, looking at the Android manual for FlexiSPY, the device itself has to be rooted before you can successfully install the malware on the device. The site offers a solution to root the device in the form of Super One Click. The site offers no direct links, save for this text. Finding the exploit is left up to the customer.
FlexiSPY requires activation before it can begin to spy on a target. To do this, a user has to dial the number *#900900900, which causes a hidden screen to be activated. On this screen, a user is prompted to enter the activation code. Never one to leave home without my favorite network packet sniffer, Wireshark, I sniffed the traffic that went through during the activation process. Here is the information that went across the wire:
- POST /t4l-mcli/cmd/productactivate?mode=0&ver=0302&pid=FSP_BB_V4.2&actcode=[Activation Code] &hash=[IMEI]&phmodel=8300(4.5.0.44) HTTP/1.1
This request is made to a server with the following second level domain:
aabackup.info
It resolves to the same IP Address as the host djp.cc listed previously. As you can see, the phone’s IMEI is being sent back to FlexiSPY HQ. Also visible is the activation code, which returns a hash value. It appears that the phone calculates a similar algorithm and waits for a matching hash. Once the correct hash is received, the app is activated.
From this point on, it’s a case of configuring the application to intercept SMS messages, e-mail messages, call logs, and so on. The application has a command channel through SMS. Thus, you have a list of eight commands, which do the following:
- Start Capture: Begin capturing events like e-mail, SMS, location, and so on.
- Stop Capture: Stop an already started capture.
- Send Immediate: Send all collected events to the central logging host.
- Send Diagnostics: Send diagnostic info.
- Start SIM Monitor: Watch for any attempt at changing the SIM card.
- Stop SIM Monitor: Stop monitoring the SIM card.
- Start Mic Monitor: Wait for calls from a trigger number.
- Stop Mic Monitor: Stop monitoring calls from that trigger number.
The funny thing is that the command channel SMS messages cannot be deleted, so the manual advises a user to select short phrases like “Good morning” or similar to begin capturing information. The phrases should be chosen so as not to arouse the target’s suspicion.
Bear in mind that I performed the preceding checks on a BlackBerry version of FlexiSPY. Given the similarities of each platform running Java, Android would behave in a similar manner.
Currently, the most widely used detection mechanism is signature based. This means that any anti-malware company writing removal or detection capabilities needs to know about the malware beforehand. If it encounters it, then it can remove it. Consequently, a new strain of malware is unlikely to be detected. This is unfortunate because, if the anti-malware companies are unable to keep up with the evolution of malware, then there is always a lag from the point when malware is released, to the point when it is discovered and addressed. During this lag period, all users are at risk.
As a developer, you have no direct control of whether a user chooses to install anti-malware applications. Your responsibility lies in making sure that your application handles its data securely. We’ve covered most of these techniques in our previous chapters, but I wanted to highlight another available, yet unorthodox, option: anti-forensics.
Anti-forensics is a technique that is used to defeat forensic analysis of computers or mobile devices by reducing the quality of information that can be gathered. Forensic analysis involves examining such devices for evidence. Most often, the evidence that has to be gathered is very fragile. Anti-forensics seeks to destroy this information by using automated tools running at periodic intervals. Then, when a forensic analysis takes place, the investigator will only find garbled or useless data. This considerably lowers the quality of information that can be retrieved. We can use a similar technique to thwart the actions of malware.
I will start with a simple example: let’s say your application reads and writes to a device’s message stores. Since you have access to this data, you can artificially generate e-mail messages and delete them at will. Assume that there is a malware application installed on the device waiting to copy messages entering the inbox. By generating many fake messages and later deleting them on a periodic basis, you are feeding the malware low quality, useless data that will exfiltrate. If done correctly, this process can make it tedious for a malware author to extract valid information. This concept is illustrated in Figures 10-3 and 10-4.
Figure 10-3. Malware intercepting mail messages
Figure 10-4. Generating fake messages
This technique can be considered a bit aggressive; and obviously, an end user should consent to this type of behavior from your application. I have mentioned it here as another technique to consider. I will leave it up to your imagination as to how to come up with additional mechanisms of defeating malware. However, unless your primary goal is to develop such anti-malware applications, you may choose to skip them.
Summary
In this chapter, we looked at malware and spyware and what they are. We also examined the various stages of malware and how we can classify them into broad categories. We learned that malware can be used by anyone and that there are many commercial entities that offer malware to both individual and corporate consumers. Our case study involved a real-world malware infection that took place in 2009 when Etisalat, one of the telecom providers for the UAE, subjected its entire subscriber base of BlackBerry users to a spyware application.
We’ve seen that, as an application developer, you are generally limited in your abilities to control what malware is introduced onto the device. Instead, your goal is to handle your application’s data (and end-user data) securely. We very briefly covered a topic that looks at how some anti-forensics techniques can be used to purposely feed malware with useless data, thus forcing the malware author to wade through these messages to find the real ones. While this is by no means a foolproof solution, this technique mostly acts as a deterrent. Unless a malware author specifically targets you, he is unlikely to waste his time sifting through useless data. Instead, he will simply move onto the next person he has infected.