I suspect that at the moment, the phone market is too fragmented for phone viruses to really work well, but I have no doubt that the malware authors are trying to figure out what they can do. At this point the social engineering attacks to gain passwords are pretty much platform independent anyways..

Ignoring "dumb" phones which don't have enough capability or horsepower to be worth infecting, you have a couple of different groups - iPhone, Android and Blackberry.

Within the iPhone market you have those phones that the user has jailbroken and those that are not. I suspect the vast majority of iPhones are not jailbroken.

And within the Android community you have those phones that have been "rooted" (the user has gained root access somehow) and those that have not. Here again, I suspect the vast majority of Android phones have not been rooted.

In theory you could download a malware app for a phone, but for an iPhone you would need to jailbreak the phone or someone would need to sneak the malware into the iPhone store.

For Android phones, it is easier to install apps that don't come from the Android market, but you still have to check the box to enable apps that don't come from the market (or once again someone would need to sneak something into the market).

John, your remark made me realize that attackers might just as well *use* mobile apps as an attack vector for Windows PC's.

Consider the research published here: http://www.darkreading.com/insiderthreat/security/client/showArticle.jhtml?articleID=223200001
The researchers published a backdoored "weather app" and observed the speed of growth of their "mobile" botnet:
-----------
Within an hour of the app being set up on the SlideME and ModMyI app sites, the researchers had 126 downloads, and 702 after eight hours. "After 24 hours, we had 1,862," Tijerina says. And as of yesterday, the count was 7,800 iPhones and Androids running the app. "This was really surprising because if this was malicious code, that's a lot of bots we would control," he adds.
-----------
Similarly, attackers might also (or instead) put autorun malware on the SD card typically present in any modern phone. Afterwards, any Windows PC that is not properly protected may get infected by connecting the phone to the PC using a USB cable. Perhaps something similar happened in the Vodafone incident you mention...

BTW alternative, and probably more reliable, ways to prevent Autorun.inf from running (compared to KB967715 == modifying the NoDriveTypeAutoRun registry values) are:

(1) By using "@SYS:DoesNotExist" as originally proposed by Nick Brown, see:
http://en.wikipedia.org/wiki/Autorun#Initialisation_file_mapping
http://nickbrown-france.blogspot.com/2007/10/memory-stick-worms.html
https://www.kb.cert.org/vuls/id/889747
This blocks autorun from *any* device, including CD, DVD, *and* CDFS partitions on U3-like USB sticks. Note that some manufacturers store installation settings in autorun.inf, which is rendered unreadable when accessed through WinAPI calls to read .ini file contents (see http://blogs.technet.com/fdcc/archive/2009/09/28/the-case-of-the-unexplained-installation-failure-and-an-ill-advised-registry-hack.aspx). Finally this method is not supported by Microsoft.

(2) By blocking processing of Autorun.inf on *any* device except on CD, DVD or CDFS partitioned USB drives, see http://support.microsoft.com/kb/971029
This manual update creates a new registry value "IsAutorunForCDROMOnly" (REG_DWORD), sets it to 1 and updates shell32.dll (older versions do not evaluate the new registry value). Note that documentation of "IsAutorunForCDROMOnly" is still virtually non-existent. If I'm correct this is what W7 uses by default.

IMO Microsoft should provide a good overview of all possibilities and disadvantages of blocking Autorun.inf processing *per OS/SP release* documenting all involved registry entries. Furthermore, IMO Microsoft should push an automatic XP update that at least blocks Autorun.inf on both network drives and USB memory devices (both FAT and NTFS). Finally perhaps Microsoft should push a control panel applet (or security center component) that allows any user to set the HKCU NoDriveTypeAutoRun registry value, and admins to set the HKLM NoDriveTypeAutoRun registry value (which, if set, overrules any HKCU setting).

(sorry if this eventually gets posted twice, somehow my first post didn't show up)

I'm horrified as I see more and more services related to payments or ticketing introduced for phones, not just on the popular 'smartphones' (iPhone/Blackberry/Android) but for some of the more basic phones too.

Until now I think the most serious threat from malware on these devices was loss of personal data (contacts, messages, stored media). But there are lucrative opportunities for fraud rapidly opening up and that's what attracts most attention.

I'd maybe go as far as to describe many of the devices running closed-source, buggy, perhaps non-updatable firmware, as 'ticking bombs' that could create a mess that may take years to clean up.

Hi John, Steven, - great post, and Steven, I have to believe an attacker noticed how many contributions were made to haitian relief efforts right after the earthquake. Even money malware will be making auto payments from user bank accounts from cellphones in under 12 months ( ; ^ ). Regards, Pat