Cell phone zombies a possibility? -- Theoretical discussion

[mark_boyle2002]

HT Was right.

I just found this under my bed !

[slarty]

On the issue of smart phones, one can implement a MIDP applet to listen to the speaker on the handset when it starts to transmit data, the applet then just collects the data and pushes this out somewhere when the user connects to the net via his handset.

MIDP does not allow applications to do either of those things without user authorisation. And on many phones, they aren't allowed to record from the microphone at all.

The MIDP system has been thought out reasonably well from a security standpoint. There is nothing inherently insecure about the API. Unfortunately, some vendor implementations might have serious holes in, and as vendors are free to implement their own APIs, some of those may be less well thought out.

At least it's better than the native-code game APIs, which generally let the game do anything it likes. A Symbian game can copy itself to a part of the filesystem that the user has no access to (hence can't delete it), and run continously, if it wants to.

Having said that, there are still some controls over things being sent to phones, the software generally asks the user before downloading anything or installing anything. If the user is not present (i.e. the phone is in a pocket or something), the item won't be downloaded. In the case of Bluetooth, the sender would have to continue to try and send until the user confirmed it.

Slarty

[Trojan]

MIDP does not allow applications to do either of those things without user authorisation.

AFAIK, MIDP1.0 does not implement any security controls at all, MIDP2.0 recommends to use JSR 177, which is the recommended security practice (this implements the Mexe like security domain system) - most importantly it is not mandated. Thus, I believe you will see many phones that have KVM's which will allow you to do almost anything on the handset, in-fact it is possible with the digital camera on most phones i.e. take photos and have them posted to some server without any user consent.

The MIDP system has been thought out reasonably well from a security standpoint.

Not true for MIDP1.0, possibly true for MIDP2.0 - only if JSR177 is implemented.

At least it's better than the native-code game APIs, which generally let the game do anything it likes.

Indeed, I agree that Symbian native code is much less secure in terms of the application writer having API's that let him get to the core of the OS and also access the radio stack, meaning attacks on the air interface can be possible (that should be very worrying to network operators), bear in mind MIDP2.0 without implementation of JSR177 can also be used for some fairly complicated attacks however the API's are not as rich as Symbian C. Nokia have 'hidden' API's only available to Nokia developers and possibly some others , which allow all sorts of platform specific (i.e. Series 60) features.

Having said that, there are still some controls over things being sent to phones, the software generally asks the user before downloading anything or installing anything.

Agreed, however, unfortunatly this is due to the implementation on not usually to do with a particular standard and implementation specific controls usually can be by passed by the application/software, the key point in your quote above is that the software will ask.

Regards,

[spamdies]

Its only a matter of time before there is a necessity for an av for cell phones. And any device thats got any sort of os. I heard a claim that the AV would be handled on the cell phone providers servers but. This question has been in my mind since. The blue tooth connection that alowwed that virus to travle didn't spread though the providers server but though a direct connection. The idea of norton on a nokia amuses me.

[Trojan]

Its only a matter of time before there is a necessity for an av for cell phones.

True, in the Japanese market AV is already deployed on the client side. This is mainly to do with network operators having the liability and not the handset vender. We will soon see anti-virus solutions for the European market fairly soon, but I'm not sure that a client side solution will come to market too soon.

I heard a claim that the AV would be handled on the cell phone providers servers but. This question has been in my mind since. The blue tooth connection that alowwed that virus to travle didn't spread though the providers server but though a direct connection.

I'm not sure which Bluetooth 'virus' you are referring to? However, if you look at some propogation models, for a Bluetooth self-replicating worm with a virus attached to penetrate a vast amount of subscribers I think is still fairly low. If you take into account that not everybody has bluetooth enabled handsets, then those that do do not activate it (it is usually switched off by default) and then each subscriber has to be in specified range to be vunerable the odds are stacked against it. Thus, the reason for network filters at the moment, a virus will propogate a lot quicker through a GSM/GPRS/UMTS network than something like Bluetooth. I think network operators are assessing the costs to the real impacts and pumping money into those areas.

I do see client side solutions being implemented but not any time soon, I think users have difficulty updating the time, internet settings on their handsets let alone trying to configure any AV software. Until network operators start to offer true Device Mangament capabilites I don't really see client side AV happening for Mass market subscribers.

The idea of norton on a nokia amuses me.

Don't be surprised, F-Secure already have an AV solution for Nokia Symbian based handsets and other AV vendors are quickly following suite. NT DoCmo, have a client side AV solution implementd by Network Associates - McAfee.

Regards,

[slarty]

Originally posted here by Trojan
[B]AFAIK, MIDP1.0 does not implement any security controls at all ...

... Thus, I believe you will see many phones that have KVM's which will allow you to do almost anything on the handset, in-fact it is possible with the digital camera on most phones i.e. take photos and have them posted to some server without any user consent.

I totally fail to see how:

1. There is no API in most phones to access the camera, or the filesystem where you might find pictures already taken
2. Access to the internet is denied by default, and on my phone it asks the user each time. Most phones I've seen always ask the user before allowing network access. Even then they only get HTTP (probably only on port 80).

Ok, so you could implement some kind of mal-ware, like a scanner, which ran as a MIDlet, but the user would have to keep the application running continously for it to work.

If the user doesn't see anything interesting happening on the phone, they will terminate the application (due to the fact that phones can't generally do anything much else while an app is running, they suspend the app temporarily on an incoming call)

MIDP1.0 may have no security features, but it has no security-vulnerable features either - there is no filesystem API, limited networking, no access to camera, bluetooth, IR, microphone.

Unless there's something I've very much overlooked. The classloaders aren't so stupid as to give the MIDLet full API access to the host VM, are they?

Mark

[methsnax]

Well, I see cell phone viruses and worms being very rare if the market stays like it is now, diverse. With many different phones, different OS, different emulated OS, etc... Why are computer viruses so prevailent? We are virtually a virtual monoculture of Win32 and PE32 based "stuff". I am approaching this from an almost purely theoretical, ecological standpoint. By increasing diversity (types of phones, OS, etc, that have non portable/compatible executable formats) of the gene pool you severely limit the ability of viruses to spread and affect/destroy the majority of the sample.
Example:
There is an island that just has horses. These horses have inbred for so long that their genes are almost exactly the same (blue skinned ). A virus comes along and kills all of them. That is the current situation with computers (and Windows) today. And it could be the future of cellphones unless we keep the market healthily diverse. Not only is it good from a viral standpoint, but also from an economic one. Providing many choices, keeping prices down.

-Cheers-

[Trojan]

1. There is no API in most phones to access the camera, or the filesystem where you might find pictures already taken

Not true, most MIDP2.0 supporting handsets have access to the camera, and because JSR177 has only beeen approved recently those handsets do NOT implement any security model. Even now, handsets such as the SE P900, Nokia 6600 do NOT implement JSR177 but have most MIDP2.0 supporting API's. Having said that, most handset vendors also provide propritary classes which adds to the problem, in-fact it opens up a new can of worms because these API's give much more deeper access to the base Symbian or propritary OS's. Just because something has been specified in the standard, it does not mean it has to be implemented unless it is mandated. On a side note, JSR 075 has just been approved and will allow a standardised way to access most parts of an OS file system.

2. Access to the internet is denied by default, and on my phone it asks the user each time. Most phones I've seen always ask the user before allowing network access.

Indeed, this is IMPLEMENTATION SPECIFIC and not stated anywhere in a JSR apart from JSR177, which explicitly states the user MUST be asked before the terminal accessing the internet, see above about current JSR177 support. However, because it's the software that implements such control, it can easily be digusied or overridden.

Ok, so you could implement some kind of mal-ware, like a scanner, which ran as a MIDlet, but the user would have to keep the application running continously for it to work.

Yes and No. If you look at some API's such as the JAVA Push registry, it allows for the application to triggred each time the handset is switched on (after the user has installed the application), such that the Push port will always listen regardless of the user executing the application or not, along with this, MIDP2.0 has the capability for allowing one midlet to execute another... do I need to say more....

If the user doesn't see anything interesting happening on the phone, they will terminate the application (due to the fact that phones can't generally do anything much else while an app is running, they suspend the app temporarily on an incoming call)

On newer handsets, it will be possible to hold a voice call and a data call at the same time, however, you are right, in most handsets today this is not possible.

MIDP1.0 may have no security features, but it has no security-vulnerable features either - there is no filesystem API, limited networking, no access to camera, bluetooth, IR, microphone.

Agreed, however, I wouldn't go to the length to say no security vulnerablities , what you need to remember is that MIDP1.0 supporting handsets were very limitied in memory and hence I regard something malicious when it can distrupt the normal working of the handset - If you have a program that can loop 1000 times and open up a graphical window and sound the ringtone buzzer at the same time.... hey presto, you've probably crashed a handset!

[RoadClosed]

Interesting discussion. Outside of the blutooth interface on the phone you still have to break through the "firewall" wich is the cell system. Those phones don't just hang out on a loose network. And based on my experience with a particular system they aren't even tcpip devices. The protocol is changed as it passes through the system. At the same time regardless of the protocol used, when you start puting Windows CE and Palm on phones that are openly surfing the web; eventually something will learn the system and introduce ways to exploit them through the "firewall" but then again these aren't really phones anymore, the voice capability is just a side job.

[Trojan]

Outside of the blutooth interface on the phone you still have to break through the "firewall" wich is the cell system. Those phones don't just hang out on a loose network.

Indeed, however it depends on how the network operator has set up its GPRS system. Most operators will use NAT and then have a firewall implemented, this way it's fairly difficult to get to a particular handset from the outside. However, again depending on how the network is implemented, it may possible for subscribers within the same network to see each others local addresses, kind of like a LAN environment, thus 'insiders' could launch attacks on the other subscribers. Because most newer handsets will support open OS's and TCP/IP, it will be possible to perhaps implement trojans that make the handset connect out by-passing firewall rules.

And based on my experience with a particular system they aren't even tcpip devices.

Well, it depends. Most N. American and European network operators have chosen to run with WAP protocols, now called OMA (Open Mobile Alliance). WAP 1.1 supported and independant protocol stack that mimicked the internet TCP/IP stack - I wonder why?? , now that the guys within WAP/OMA have come to their senses, they follow a TCP/IP stack with some profiling done to facilitate for the wireless bearer. Therefore any hanset that support WAP2.0 will support a TCP/IP stack and will support TCP/IP straight to the handset.

Regards,