Vesselin Bontchev

← All papers

Virusability of Modern Mobile Environments

[Bontchev07b] Proc. 17th Int. Virus Bull. Conf., 2007, pp. 186–191.

Dr. Vesselin Bontchev, anti-virus researcher FRISK Software International Thverholt 18, IS-105 Reykjavik, Iceland National Laboratory of Computer Virology Bulgarian Academy of Sciences Acad. G. Bontchev Str., bl. 2, BG-1113 Sofia, Bulgaria E-mail: bontchev@complex.is

Abstract: The vast majority of currently existing malware for mobile devices (PDAs, smart phones, etc.) is for mobile phones running the Symbian S60 R2 operating system – with just some proof-of-concept malicious programs existing for the J2ME, PalmOS and Windows Mobile 2003 environments. The paper examines the security features introduced in the newer versions of the mobile operating systems – Symbian R3, Windows Mobile 6.0, J2ME – and explains why they are much less vulnerable to self-propagating code. While we stop short of claiming that these environments are virus-proof, we maintain that viruses are unlikely to become a huge problem for them.

1 Introduction

Currently, the vast majority of viruses for mobile devices are written for the mobile phones running the Symbian S60 R2 operating system. In fact, the number of viruses and other malware for this environment is increasing exponentially ([Bontchev06b]).

Malicious programs, including proof-of-concept viruses, have been developed for other mobile environments too – PalmOS ([Bontchev05]), Windows Mobile, Symbian UIQ and others. However, the number of such malicious programs for these environments is vanishingly small. There are various reasons behind this fact. For instance, some of these environments are not sufficiently widespread to attract the attention of the malware authors (besides that of some fame-seekers insisting on being “the first” to create some malware for an obscure new environment) and/or to sustain a large enough vulnerable population for a successful epidemic. In other cases, the environment is not sufficiently well documented and/or the contingent of people who are sufficiently knowledgeable to program it well is too small. Other reasons include the mobile environment not providing good enough capabilities for interconnection and information sharing to make self-replicating code successful, or not containing valuable enough information to make stealing or destroying it with a Trojan horse desirable.

Nevertheless, the potential (from the point of view of the virus writers) is there. One could speculate (and some anti-virus producers are not afraid to do so rather vocally) that viral epidemics for mobile devices could become “the next big thing” in the computer security of the near future.

The purpose of this paper is to examine the newest improvements of the most popular operating environments for mobile device and to reach a conclusion of how possible virus attacks for them are and how likely they are to be successful.

2 Symbian S60 R3

As mentioned above, the vast majority of the currently existing mobile malware is for mobile phones running the Symbian S60 R2 operating system. It would be natural to expect that the next version of this OS – R3 – would be similarly at risk.

Fortunately, however, this is not the case. Version R3 has seen some significant new developments on the security front – developments, which have made the existing R2-specific malware irrelevant and the development of successful new R3-specific self-replicating malware rather unlikely. These developments include:

Binary incompatibility. The devices running Symbian S60 R3 are binary incompatible with the programs written for Symbian S60 R2. While under R2 software is installed as SIS packages, under R3 it is installed as SISX packages. These packages have a different format from the SIS packages and SIS packages will simply not install under R3. Furthermore, programs compiled for R2 will be unable to execute under R3, again due to the changed format. This means that all the existing malware (self-replicating or not) for Symbian S60 R2 will not even install under R3, and will not run even if somebody manages to re-package it in SISX form.

Acceptance of digitally signed packages only. By default, only digitally signed SISX packages can be installed under R3. Furthermore, they have to be digitally signed not just by anyone but by Symbian. The signing process is rather rigorous and expensive and the applications submitted for signing must comply with a strictly defined set of rules. For instance, they are not allowed to hide themselves from the task switcher, they must allow the user to uninstall them cleanly and so on. This means that parasitic infectors will be unable to spread (because they will invalidate the digital signature of the SISX packages they infect).

Furthermore, the probability that a virus author would manage to successfully pass their virus through the rigorous requirements of the digital signing process is rather unlikely – and even if it happens, he will have to submit identification data which will make it trivial for the law enforcement to catch him. Of course, the fact that the signing process is also rather expensive means that the virus writers are very unlikely to bother with it.

The actual implementation of this approach has a flaw, though. While the enforcement of installing only packages that are digitally by Symbian is on by default, it is possible for the user to turn it off. In fact, many users are likely to do that, in order to be able to install free software, since the freeware authors are unlikely to bother going through the expensive process of having their software digitally signed by Symbian. Furthermore, once a malicious program is allowed to run on an R3 device, it can turn off this enforcement programmatically, too.

Cryptographically enforced policies. Even if the installation of a SISX package is allowed to be installed on the R3 device because it is digitally signed by Symbian, it is also required to carry a manifest of what functions it is expected to perform. The installed application will not be permitted to use any other functions – this policy is cryptographically enforced, too. In practice, this means that an application claiming to be a calculator will not be permitted to use SMS-sending functions, for instance.

This will significantly reduce the threat of Trojan horses – although, of course, it will not be able to eliminate it altogether. (For instance, a program claiming to be an SMS sending utility can still also be a Trojan horse sending SMS messages for malicious purposes.)

Phasing out of R2 phones. Apparently, Nokia, one of the major producers of Symbian S60 mobile phones, is aggressively phasing out the models running version R2 of this operating system and is replacing them with R3-based models. At the time of writing of this paper (May 2007), it has become extremely difficult to find any R2-based model in the stores. While this will not have an immediate effect, since a very large population of R2-based devices vulnerable to virus infections already exists, in the long run it will basically wipe the existing SymbOS viruses out of existence, as the owners of the R2-based mobile phones gradually replace them with models that are more modern.

The above developments have convinced the author of this paper that, in the near future (perhaps a couple of years) SymbOS viruses will become a non-problem – just like macro malware has become a non-problem, due to similar developments (requirement for digital signatures) from Microsoft ([Bontchev06a]). We would like to note, however, that this by no means should be understood as a belief that SymbOS malware will become impossible – just like macro malware is still being developed and occasionally released by the malware authors.

First, there always will be at least a small population vulnerable to viral attacks – people who are still using the old R2-based phones, or people who have intentionally turned off the cryptographically enforced policies of their R3-based phones. Second, the cryptographic policies will not preclude the creation of Trojan horses that either use social engineering tricks to fool the user or manage to pass through Symbian’s digital signing process. Third, it is always possible that vulnerabilities are discovered in the operating system or in the components that enforce the cryptographic policies – vulnerabilities, which would allow the occasional virus to spread.

In fact, we have already seen a Trojan horse that uses the second of the above approaches ([FlexiSpy]). It is commercial spyware, which monitors the calling data of the phone it is installed on and reports it to a remote Web server. The Trojan horse is digitally signed by Symbian and installs without problems on Symbian S60 R3 phones. It has passed through the digital signing process by claiming to be a tool for backing up the calling data to a remote Web server – obviously, the people responsible for the process have overlooked the fact that it does it without the user’s knowledge and explicit request. Furthermore, since it is commercial, the company behind it has had no problems spending the money required to get their product digitally signed.

We shall certainly continue to see more such cases in the future – maybe to a large enough extent to make non-replicating R3-specific malware a problem. We do maintain, however, that R3-based viruses are unlikely to ever become a serious problem.

3 Windows Mobile 6.0

The previous versions of Windows Mobile (up to version 5.0) are perhaps the most vulnerable of the environments discussed in this paper. They share the same code base as the various versions of Windows for the desktop – meaning that many of the bugs that plague desktops are present, in one form or another, in the PDAs and other devices running Windows Mobile, too. What makes the situation worse is that while the desktop Windows brands are patched more or less automatically by Windows Update, updating Windows Mobile is far from trivial.

Normally, Microsoft does not distribute patches (security-related or not) for this operating system to the end user. Instead, they are provided to the producers who actually make the Windows Mobile based devices. The producers are then responsible for making the patched operating system available to their customers. In reality, however, they don’t bother. Why go through the trouble of making a patch available for free and deal with all the customer support that installing it involves, when they can instead sell a new device (with “new and updated operating system”) to the user?

All this leaves the mobile devices running the early versions of Windows Mobile quite vulnerable to attack. In fact, the only reason why malware for them is not widespread is because the devices themselves are not. For instance, devices running the various versions of the Symbian operating system have approximately 60% of the market – this is why the malware authors are concentrating mainly on them. But there are plenty workable exploits for Windows Mobile 5.0 and earlier ([Whitehouse06b], [Whitehouse07b]) – some of which can be used for virus spreading. In addition, the devices running Windows Mobile are becoming more and more widespread nowadays. Fortunately, the security situation is improving, too – especially with the introduction of Windows Mobile 6.0.

For instance, Microsoft is pushing the concept of digitally signed (trusted) code for its mobile operating system, too. In addition, there are two kinds of devices running Windows Mobile – the so-called “one-tier” and “two-tier” devices ([Whitehouse06a]). One one-tier devices a digitally signed application is trusted to do anything. The user will be prompted for permission before an unsigned application is allowed to run – but once the permission is given (and users are notoriously bad at making proper decisions in this aspect), the application is allowed to do anything.

Two-tier devices are much more secure in this aspect. A signed application will have a manifest of what kind of “dangerous” actions it is allowed to make. The attempt to run an unsigned application will generate a user prompt, just like on one-tier devices. If, however, the application is allowed to run, its access to various “dangerous” APIs (e.g., registry manipulation, debugging, process control, etc.) will be restricted. However, even an unsigned application is allowed to do quite a lot on a two-tier device – e.g., it is allowed to send SMS/MMS messages and this is a possible vector for attack ([Whitehouse06d]).

There are many other security improvements in Windows Mobile 6.0, too ([Whitehouse06c]): safe SEH, secure C run-time libraries, separation of kernel and user space, WPA2 WiFi support, IPv6, improved process isolation, secure boot loaders, hardware-supported security, etc.

At this point of time, the Windows Mobile platform is the one of all the platforms examined in this paper, for which the author is the least sure whether viruses will be a problem for it or not. The reason is not that it is the least secure one – the reason is the lack of sufficient information for evaluating the threat.

We simple don’t know yet whether the vastly improved security in version 6.0 will outweigh the common security holes with desktop Windows brands and the difficulties involved in patching them. We don’t know whether this platform will become sufficiently widespread to be worth attacking – although this seems likely. If we have to make an educated guess, it would still be that, modulo some viruses using an exploit of a security hole that is both widespread and difficult to patch, even on this platform non-replicating malware will be relatively more troublesome than viruses. Just how troublesome it will become, however, we are not confident at predicting. It might stay at its current level of near-insignificance – or it might reach levels of mild annoyance as the current Symbian S60 R2 viruses.

4 J2ME

Java 2.0 Micro Edition – or J2ME for short – is probably the most widespread computing environment for mobile devices. It is supported by a very wide range of mobile phones (even by phones that do not have a real operating system and do not support user-installable compiled executable programs), PDAs and other such devices. The main incompatibilities across devices are usually in the supported screen resolution(s) and the special device-specific capabilities (e.g., phone access would not be available on devices that do not have a phone). Simultaneously, J2ME is a very powerful language, providing a wide range of operations such as file access, sending of SMS and MMS messages, modem and Bluetooth access, and so on.

At first glance, it would seem that the wide population of J2ME-enabled devices and the powerful capabilities of the language make it ideal for the implementation of various kinds of sophisticated malware programs. In practice, though, this is by far not the case.

The main problem arises from the J2ME security model. It is significantly better thought-out than the security model of any other mobile operating environment the author is familiar with. Practically any kind of “dangerous” operation – such as a communication attempt or a file access outside of the subdirectory tree where the J2ME midlet is installed – results in a security warning ([Niemelä]). Even when the midlet is digitally signed with a trusted key, the user will be asked at least once (the first time) when the midlet attempts to do something potentially dangerous.

Of course, it could be argued that such a security model simply shifts the decision for the validity of the dangerous action to the user, who is well-known to lack the proper competence for making correct decisions of this kind. While this is true, and the user might indeed make the wrong decision once or twice, the fact that every dangerous operation results in a security warning means that during the operation of a virus, the user will be constantly annoyed by multiple such warnings and would rather terminate the offending midlet than continuously approving the dangerous actions.

Of course, all this does not mean that malicious programs – even of the self-replicating type – for J2ME are impossible. In fact, we have already seen a Trojan horse for this environment ([RedBrowser]). This Trojan horse uses social engineering tricks to coax the user to approve the dangerous actions. It masquerades as a Web browser, making the user expect it to use communication functions.

Constructing a J2ME-based virus that would have at least a small chance of fooling some users is significantly more difficult – but it, too, is not impossible. For instance, the code of the virus could reside on a Web server and masquerade as some kind of instant messenger. When downloaded and executed, it could examine the user’s contacts and send to each of them a short message on behalf of the user, enticing them to download and try the new “instant messenger”. Of course, these activities will produce a multitude of security warnings, but the user is unlikely to be surprised by them and, with proper social engineering techniques, is likely to be fooled into authorizing the offending actions.

However, server-based viruses are extremely easy to “kill” globally – essentially, all that needs to be done is to shut down the Web page that is distributing them – and the anti-virus people have a lot of experience in shutting down malware-distributing sites. So, while malware for J2ME is certainly possible, it is the firm belief of the author of this paper that J2ME-based viruses will never become a prevalent problem. Trojan horses, SPIM and Smishing are much more likely to cause problems in this environment ([Whitehouse07a]).

However, the strength of the J2ME security model also has a negative side. It means that it is impractical to make a reasonably-well working anti-virus program for this environment. For instance, any attempt to scan the file system of the J2ME-enabled device with a J2ME midlet will result in a security warning every time when a file outside of the subdirectory tree where the midlet resides is accessed. The user is likely to find such a behavior extremely annoying and will refuse to use such an anti-virus program.

5 Other Devices

Finally, in this section we shall consider some of the other, somewhat less popular and significantly different mobile devices and their vulnerability to viral attacks.

5.1 PalmOS-Based PDAs

Mobile devices using PalmOS used to be extremely popular in the past. Various malware, including a proof-of-concept virus for this environment already exists. A detailed discussion of how vulnerable this environment is to virus attacks can be found in [Bontchev05]; here we shall present only a summary.

Although the environment provides adequate capabilities for virus spreading (there are PalmOS-based mobile phones with MMS, Bluetooth and WiFi capability), the environment itself is essentially dead nowadays – even PalmOne Inc. is no longer using it and has based its newest PDA on Windows Mobile. This means that the population of vulnerable machines is too small to support a global pandemic. This is why the author does not expect that viruses for this platform will be a major problem in the future.

5.2 Sony PSP

The Sony PlayStation Portable is a mobile gaming device, about three times the size of a mobile phone. Besides playing games and watching movies, it can also be used for Web browsing.

We have already seen malware written for this platform ([PSPBrick]). The PSP/Brick.A is a Trojan horse which, when executed on the device, makes it non-functional (i.e., “turns it into a brick”). However, this is just a proof-of-concept malware and the author of this paper does not believe that any kind of malware (let alone viruses) for this platform is ever going to become a serious problem.

To begin with, installing third-party applications (i.e., not provided by Sony) on the PSP is extremely non-trivial. The user has to do a significant amount of hacking, in order to achieve it. Furthermore, doing so voids the warranty of the device. Consequently, the platform is not at all friendly to exchange of executables between different devices. Therefore, a virus would have virtually zero changes of spreading successfully.

5.3 BlackBerry

The BlackBerry, produced by Research In Motion (RIM) is a very popular mobile device in the USA – in fact, there it successfully rivals the other models of mobile phones and PDAs. It allows the user to make phone calls, send instant messages, browse the Web and access their e-mail from all over the world.

The earlier models were designed mainly with security in mind, so they are rather resistant to malware attacks ([O’Connor06]). For instance, they do not have a file system as such and their Bluetooth interface is limited to operating the headset. The most feature-rich (and, therefore, the most vulnerable) is the BlackBerry Pearl 8100 model. This model does have a file system (although it still uses a proprietary operating system), a built-in camera and supports third-party applications downloadable to the device.

For an extremely thorough examination of the possible malware threats to this device, the reader is referred to [O’Connor]; here we shall only summarize the most important points.

Any third-party applications for this device must be written in J2ME and, therefore, any malware would be subject to the restrictions mentioned in section 4. There are some additional points, though.

The installed applications are not accessible through the file system of the device, so parasitic viruses are practically impossible. Bluetooth file transfer is possible only between paired devices (and causes prompting when performed by unsigned applications), so Bluetooth-based worms, although possible in principle, are extremely unlikely of being successful.

The various “dangerous” actions, like access to the file system, automatic launching at startup, e-mail access, access to the PIM data stored on the device and access to the telephony logs are simply not available to applications that are not signed by RIM. Making phone calls from the device cannot be done programmatically at all.

However, the process of getting one’s BlackBerry J2ME application digitally signed by RIM is significantly easier, cheaper, more anonymous and subject to much less rigorous restrictions than the equivalent process for Symbian S60 R3 applications (see section 2). Basically, anyone could do it pretty much anonymously by spending $100 and using a pre-paid credit card.

Furthermore, such potentially dangerous operations as SMS sending and receiving and TCP/IP and HTTP/WAP communication can be performed even by unsigned applications, after the user being prompted for permission just once – the first time that the offending application is launched. This allows the creation of various kinds of non-viral malware – especially of the spyware kind. It is relatively easy to create a program that spies on the user’s SMS communication while disguising itself as a game that “uploads the user’s score on-line”. If the attacker manages to get the application digitally signed by RIM (and, as the recent FlexiSpy cases demonstrated, even the signing process of Symbian can be “circumvented” by a determined spyware producer [FlexiSpy]), it will be able to spy on the device’s e-mail and telephony records, too.

Assuming that the attacker can get his malware digitally signed also allows for the creation of server-based worms, similar to the ones discussed in section 4, with e-mail instead of instant messaging used to send messages, enticing the user to download and install the worm from the remote server. However, as already mentioned, such worms are easy to kill by shutting down the server that distributes them. Furthermore, the requirement that their code is digitally signed (in order to be allowed to send e-mail) is an additional burden on the virus author. While we suspect that a few such worms will be created (if nothing else then at least as a proof-of-concept that the BlackBerry platform is “virusable” too), we are pretty confident that they will never become a serious problem for this platform.

While the e-mail messages received by the BlackBerry devices can carry attachments, only a small set of attachments is allowed (DOC, PDF, TXT, WPD, XLS and PPT). In particular, attachments containing J2ME executables (the file extension of such files for the BlackBerry is COD) are not allowed – so, an attachment-based e-mail worm is not possible. The BlackBerry does not allow any kind of scripting in e-mail messages or HTML pages, either.

In addition, the BlackBerry Pearl 8100 device has built-in security features that, if activated and used properly, can further reduce the threat of viruses and non-viral malware. For instance, it has a built-in firewall, which can be used to monitor if an application (even a signed one) is trying to communicate with the outside world. Furthermore, the user can set a wide range of per-application policies; basically specifying what a particular application (or all applications) is allowed or not allowed to do.

5.4 iPod

A very popular mobile device is the iPod media player from Apple Inc. In 2007, a proof-of-concept virus was released for it ([Szor07]). In practice, however, this is significantly less exciting than it sounds.

The virus is written not for the iPod’s native operating system but for iPod Linux – a third-party Linux-based OS that only some hobbyists install on their devices. Furthermore, the virus is extremely buggy and seems to be device- and iPod Linux version-specific. Even better, its infection strategy is unbelievably stupid and basically the only way for it to end up on a clean device is if the user explicitly copies it there. Once executed on the device, the virus would infect all the module libraries there – but will not attempt to move to a new device on its own.

Clearly, this virus has absolutely no chances of surviving in-the-wild. Its operation can clearly be improved – but even then, viruses for this kind of devices are unlikely to ever be successful. The users rarely transfer information from one iPod to another in a way that would facilitate virus replication. The most successful attack is probably to use a multi-platform virus – i.e., a virus with both desktop and iPod components – so that the virus can transfer itself to and from the mobile device during synchronization.

However, even such a strategy is unlikely to be very successful in the global scheme of things, since the users tend to synchronize their mobile devices only with a very limited number (usually one or two) desktops. Therefore, even a multi-platform virus would have trouble spreading successfully between mobile devices. At best, it would look as a PC virus that uses the mobile device as storage.

Other lines of attack are also possible. For instance, vulnerabilities have been discovered in the Firewire protocol used by some iPods – vulnerabilities, which would allow a malicious program running on the device overwrite arbitrary memory parts of the desktop’s memory and install malicious code there. While this does allow the iPod to be used as a vector for an attack, this kind of vulnerable protocol (DMA access over Firewire) is not widely used – for instance, Windows XP does not support it.

Again, it is our conclusion that while malware and self-replicating malware in particular for the iPod is certainly possible and even likely, computer viruses are never going to become a real problem for this environment.

5.5 iPhone

At the time of writing of this paper, Apple Inc. has revealed their new mobile device – the iPhone. Although still not available in the stores, from the information released about it, it is evident that it will be a mobile phone combined with a PDA and an MP3 player. Supposedly, it will be running an operating system derived from OS X (used on Macintosh computers). Since this OS is essentially a brand of UNIX, it has been speculated that malware for the new device would be easy to write.

However, since then Apple’s Steve Jobs has commented that the new device will be closed – in the sense that not just anyone will be able to write programs for it. The software for it will be exclusively controlled by Apple, even if the writing of some of it will be outsourced to third parties ([Chien07]). Even Java applets will not be able to run on the device, unless explicitly authorized by Apple – probably with the means of some kind of public key authentication scheme.

This certainly will not mean that the iPhone will be totally immune to malware attacks. Various kinds of SPIM, Smishing and other kinds of tricks relying on social engineering are likely to work and be used by the attackers. The new operating system or the applications for it are likely to contain vulnerabilities that will be found and exploited, too.

However, we seriously doubt that viruses will ever become a serious problem for this platform, too. While an occasional worm relying on some kind of vulnerability might be released from time to time, we believe that it will be easy to contain and that the occasions will be rare enough not to present a serious problem.

6 Conclusion

Although initially the developers of mobile devices seemed to have made the same old mistakes of ignoring security in favor of flexibility that we know from the MS-DOS and Windows worlds, it seems to the author of this paper that they have started learning. The modern mobile devices and the operating systems for them seem to come with various security-related features, which will be of great help of preventing self-replicating malware from becoming the kind of plague it has become on the desktop platforms.

We are far from claiming that viruses will be impossible for these platforms. As Dr. Fred Cohen has proven in his Ph.D. thesis, there are only three possible ways of making viruses impossible for a computing environment – limited functionality, limited transitivity and limited sharing ([Cohen86]). Unfortunately, neither of these three ways is applicable in practice for consumer-level devices, since either of them renders them practically unusable by the average person.

However, as experience in the macro virus world has demonstrated, a well-selected set of security measures is capable of preventing computer viruses from being a significant problem plaguing the users – even without making them impossible ([Bontchev06a]). It is our hope and belief that the producers and mobile devices will have the foresight to apply this approach to their future products.

Unfortunately, this approach will not prevent many of the problems caused by non-replicating malware like Trojan horses, adware, spyware, SPIM and Smishing. This is why we believe that fighting such malware will dominate the security landscape of the mobile device world in the future.

References