APPENDIX A
Mobile Malware
Even before the advent of smartphones, malicious software and viruses were already a recognized threat to mobile devices. Although the prevalence of such malware has not yet reached the level of desktop platforms, mobile devices are becoming an increasingly attractive target. Before the advent of application mass-distribution outlets such as Apple’s App Store and the Android Market, mobile applications were obtained in an ad hoc fashion by savvy users from arbitrary websites, with no vetting of the apps by a third party. This resulted in a low bar for malware authors, but the spread of these programs was limited due to the relatively small percentage of the user base that installed third-party applications at all.
As of 2009, applications allowing users to view and manipulate financial accounts, auction listings, and shopping accounts linked to credit cards are becoming commonplace. For the time being, many companies are testing the waters with relatively watered-down versions of their full web applications (for example, financial institutions offering mostly read-only access to accounts, requiring some transactions to be done on a PC, and so on). The functionality of such applications is expanding to the point where they will be an irresistible target for online criminals.
Aside from the risk of exposure of credentials to critical online services, mobile devices can also expose information such as business contacts, call logs, positional data, and internal company information. Malware has been seen that runs up SMS or phone bills, destroys data, harvests tracking information on users, and even uses desktop computers to spread itself. Worms have expanded to use Bluetooth, MMS, memory cards, and Wi-Fi as replication channels. Some of these vectors cause real financial impact to users; MMS and SMS both cost money, especially to premium rate numbers, as do phone calls and data plans.
Unfortunately, the malware that has appeared thus far has been accompanied by considerable hype by vendors hoping to profit from its proliferation. Even proof-of-concept worms and Trojans have been subjects of widely published press releases by security and antivirus vendors, which has made it somewhat unclear what the real threats posed are. Let’s take a look at some of the software that has generated all this attention thus far, and try to separate reality from marketing.
A Tour of Important Past Malware
There are in fact a large number of mobile viruses and malicious programs, but few have had much success in terms of infection rate. Arguably, some were never much of a threat to begin with and mostly served the purpose of illustrating the potential for future attacks. What follows is our hit parade of notable malicious mobile programs.
Cabir
The first discovered mobile malware was designed for the Symbian OS in the form of the Cabir worm, and was largely analogous to early PC viruses—the purpose was simple replication or vandalism. Cabir spread over Bluetooth connections, prompting users within range to install an application and asking repeatedly until the user accepted. The worm then made system modifications and began to scan for other Bluetooth peers within range. Cabir never gained a significant foothold, but set off a huge flurry of speculation as to what the future would bring.
Commwarrior
In March 2005, another Symbian worm surfaced that, in addition to replication over Bluetooth, could send copies of itself via MMS. News of the worm was widely reported, and some antivirus vendors used this as an opportunity to sow fear in users of mobile worms. However, Commwarrior was not widely circulated. Currently, reputable antivirus vendors rate Commwarrior as being very low risk. Many variants have appeared, but none has spread extensively. Still, this worm illustrated yet another path that could be used to spread malicious mobile software.
Beselo.B
The first worm of note to use supposed media files to spread was Beselo.B. This worm sent either JPG, MP3, or RM files over Bluetooth and MMS. It also copied itself onto MultiMedia Cards (MMC), where it would infect any other phone into which the card was inserted. Its codebase is fairly similar to Commwarrior, but this worm illustrated the utility of encouraging user assistance using media as a lure.
Trojan.Redbrowser.A
In February 2006, what has been reported as the first J2ME Trojan appeared, targeted at Russian-speaking users. Redbrowser requests SMS sending capabilities, and repeatedly attempts to send SMS messages to premium-rate numbers. However, because the user is prompted for each message to be sent, the impact to the individual is fairly minimal. This does illustrate, though, how crucial these capability and permission schemes are in preventing the spread and impact of mobile malware.
WinCE/Brador.a
The Brador.a Trojan infected Windows Mobile 2003 devices, notifying the Trojan’s “owner” of the compromise and then listening on a TCP port for remote instructions. Brador.a had simple backdoor capabilities, allowing for uploading and downloading files, executing commands, and sending directory listings. Aside from being a prominent Trojan on the Windows Mobile platform, the new twist with this Trojan was that its client software was reportedly for sale on underground markets.
WinCE/Infojack
The first Windows Mobile Trojan of real impact was Infojack. This code was distributed bundled with malicious versions of a number of standard mobile applications. Besides replicating itself to memory cards and protecting itself from deletion, the application disables installation prompts for unsigned applications. It uses this to update itself silently, but also allows for silent installation of future malware.
Infojack has been disarmed by a shutdown of the creator’s site by law enforcement, but the exposure to other malware due to the removal of installation prompts remains for affected devices.
SMS.Python.Flocker
In early January of 2009, Kaspersky discovered a novel approach to Symbian worms. As the name suggests, Flocker was written in Python rather than C/C++. This was quite possibly a first for a Symbian worm, but a poor choice, because it requires that a Python interpreter be installed on the phone. It’s possible that Flocker was a simple proof of concept, but its functionality indicated the intent to profit from the worm’s spread—it targeted a money-transfer feature implemented by an Indonesian mobile phone provider, sending small transfers under US$1 to numbers owned by the attackers.
Perhaps due to the poor design decision of using a non-native language for writing a worm, a J2ME port soon appeared, named Trojan-SMS.J2ME.GameSat.a, which exhibited almost identical behavior.
Yxes.A
Yxes.A surfaced in February 2009, again on the Symbian platform, gaining significant media attention. This worm gathered users’ phone numbers, IMSI (International Mobile Subscriber Identity) and IMEI (International Mobile Equipment Identification) numbers, and other local identifying data, sending it back to servers in China. This worm actually had a valid certificate, signed by Symbian, allowing it to install cleanly on unmodified devices. The mode of transmission between devices was sending URLs via SMS. Infections were reportedly primarily identified in Asia, but very little data exists on how extensively Yxes.A spread.
Others
Due to its early popularity, Symbian has largely been the platform of choice for mobile malware authors. Symbian still makes up over 45 percent of the mobile device market share. A variety of different worms have been reported as being in the wild, such as Doombot, Skulls, and Pbstealer. Some even target desktop PCs, dropping payloads to be run by systems synced with the device. However, none thus far have gained a significant foothold. Although the threats posed by many specific worms have been overhyped, it seems likely that a worm with real impact will surface before long—and as the variety of mobile operating systems increases, new techniques and prevention methods will surely be developed.
Threat Scenarios
Fake Firmware
In 2008, US-CERT warned users of an iPhone OS 1.1.3 firmware “prep” that contained a Trojan circulating online. The threat turned out to be relatively small, but illustrated the potential for malware spreading by targeting phone unlockers, and potentially normal users looking to upgrade. Malicious firmware updates are a good method to gain extremely low-level control of a device, but many modern mobile devices implement firmware-signing schemes that make this method difficult—and certainly it can be more challenging to encourage users to install trojaned firmware. However, the low-level control this vector gives over the target device could make it an attractive option.
Classic Trojans
The most obvious and common attack on end users is through malicious software that appears legitimate. As seen earlier, these Trojans can offer backdoor access to attackers, gather information, update dynamically, and generally make life difficult. This vector is made somewhat harder on some platforms (the iPhone being the prime example), because software must make it through a review process before even being offered to users. This means that programmers have to be at least skilled enough to make a marginally useful iPhone application, and able to conceal time-delayed malware functionality.
Android, of course, has taken a different approach to vetting applications, relying on a community reputational system, which does not require application review.
One troubling twist to the Trojan threat is that of Trojans installed by service providers themselves. In 2009, the United Arab Emirates telco Etisalat pushed out a “performance-enhancement patch” to its BlackBerry users. This was found to be spyware of U.S. origin, designed to intercept e-mails and accept remote control messages (see http://www.wired.com/threatlevel/2009/07/blackberry-spyware/).
Worms
We’ve discussed several instances of mobile worms. These can be spread by attempting to force user approval, or they can potentially be spread completely silently, if exploiting a vulnerability in a driver or networked system process. Other vectors include SMS, MMS, MMC, Bluetooth, Wi-Fi, Edge/3G data connections, and frequently some combination thereof.
An aggressive and widespread worm could even use phone carriers’ resources and infrastructures to such a degree that it would cause real performance degradation for the carriers and their customers. Such software is likely to be the most troublesome mobile device affliction in the future.
Ransomware
More than one instance has been found in the wild where a malicious program will disable a device or sequester user data, usually encrypting it, and then demand payment in return for decryption keys or a return to normal functionality. On a desktop, this may not always be successful—a user may not have much important data locally, instead storing it on web services. The disabling of a mobile phone can be far more urgent to the user, increasing the odds they might pay up.
In this scenario, the user’s data is encrypted with a symmetric key. The attacker then informs the user they must either purchase a tool to decrypt it, purchase the symmetric key directly, or send an SMS message which accrues charges. However, depending on the infection vector and platform, application sandboxing may limit the amount of data which can be encrypted.
Mitigating Mobile Malware Mayhem
So, what can be done about this situation before it worsens? Are we doomed to run antivirus software on our phones, and click “Allow” constantly? A few different approaches involving users, developers, and platform vendors can help curb the impact of mobile malware.
For End Users
Modern mobile platforms implement application signing, third-party verification, and/or reputation systems to prevent malicious applications from being distributed to end users. It is critical that users be educated as to the meaning of these, and made aware of the risks of installing untrusted third-party software, opening unrecognized SMS/MMS messages, and acquiring untrusted media files. These behaviors should be developed before the advent of high-impact malware; at least in the mobile space, we have the advantage of advance warning.
In enterprise environments, administrators should use available platform facilities to restrict permission sets and push policy updates.
For Developers and Platform Vendors
The App Store and Android Market offer an interesting contrast. The former relies on manual vetting of applications by Apple, and the latter works on a community trust-based system. Symbian implements signing mechanisms for different capabilities, and Windows Mobile implements...nothing. One thing that is crucial, regardless of platform, is that vendors pay serious attention to security UI. Users can only be expected to be diligent about preventing the spread of malware if prevention mechanisms are simple and easy enough to use and understand. This has historically proven to be no simple task—even simple mechanisms such as the browser Secure Sockets Layer (SSL) “lock” icon have had poor efficacy. And sadly, security UI often relies on making actions difficult and annoying. Striking a balance takes careful attention and testing.
Vendors can help by implementing usable capability systems to make applications adhere to a principle of least privilege. Also, enabling exploit-prevention features such as nonexecutable stack and heap can also help to prevent against the spread of malware via vulnerabilities in C software.
For developers, we hope that some of the secure development practices in this book will encourage the proliferation of more usable and secure software as well as minimize common security mistakes. Mobile software should be subject to the same type of secure development life cycle (SDL) processes that web and desktop software is; mobile versions of software are often expected to be small projects quickly produced by engineers whose primary skill sets are in other areas. Care must also be taken that sensitive data stored on both the client and the server is secured by standard platform mechanisms, and encrypted if at all possible. Server-side data should be kept as anonymous as possible, and data-retention policies should be in place to retire this data. As mentioned before in this book, storing personally identifiable information can present a risk to both the developer and user, so keep as little data as you can.
Using the least level of privilege to complete the application’s task not only minimizes the impact of a vulnerability in a developer’s program, but can make users feel better about installing the application. Apps that request tons of sensitive privileges and require more user interaction to install tend to get installed less frequently. Therefore, keep things simple!