It’s been a while since the last time I jotted down my thoughts in advance of an FTC workshop, but here I am again tapping away at the keyboard on my laptop on my way to Washington D.C. I’m doing last minute preparation for being on a panel tomorrow at FTC’s mobile marketplace workshop with another security professional from US CERT and an academic/engineer. While I’m normally guided by a slide deck, slides are verboeten on panels like this and the most important thing to be armed with is well-formed thoughts. So in the spirit of cementing the thoughts in my head after doing a few days of research and mulling things over, here’s my notes on the questions I’m expecting tomorrow.
fair warning: this ended up pretty techie...Who are the stakeholders in the mobile security market?
The carriers – it’s their job to keep the networks clean and running smoothly. Since they often get paid by how much services you use, they have a high level of incentive to make sure everything runs as smoothly as possible.
The handset manufacturers – they are responsible for making sure the hardware is designed with at least basic defenses in mind. For example, it would be great if they had onboard encryption, but they should at least make sure that the combination of the OS & hardware provide sufficient support for security related aspects of protocols such as GSM and UTMS.
The OS vendor – they have the same responsibility as the handset manufacturers to make sure all the basics are covered, but since they are also application providers (and service providers to phone applications) they have all the normal software security concerns (buffer overflows, dos conditions, etc.). Code re-use for windows exemplifies this, as the old IGMP DoS flaw was a direct carry over to Windows Mobile 5. Mobile OS have many years of security expertise to draw on from the PC space—in some areas the lessons seem to have been learned (code signing is standard), in other areas, they have not. There are also new issues here related to privacy & mobility, such as location tracking, which really are a bit different than the PC space (which assumes your device is not terribly mobile, probably not true anymore with laptop sales outpacing desktop sales, but I still carry my phone more places than my little thinkpad x60.
The user – given the movement of attacks to exploiting people, no matter how good a job the above players do, the user has to make the right decisions about what data to store on their phone (how sensitive?), how to protect it (use a password?), what to install on it (can I trust this file claiming to be a background or ringtone?), and what to connect it to (hotspot, Bluetooth device, etc.). The biggest risk here is loss or theft, phones are lost at 15 times the rate of a PC! Hence, the most important thing you can do is carefully consider how much sensitive data you store on your phone, password protect your phone, and use encryption when it is available. I use a password on my phone and store most of my sensitive data in other places, like on my lappie or in a file in gmail (not the best, but better than in a flat file in my phone).
Note that in systems that accommodate payment by phone, as you now see in Japan, you also have the merchants and more importantly the payment processor in the mix. Nothing really new here, just all the same security practices you would expect from players accustomed to handling credit cards and other payment instruments.
What is the future of malware & mobile phones? How is it different from PCs?
| PC | Mobile |
| Homogeneous OS: Windows | At least 4 different OS (RIM, Apple, Symbian, Windows Moile), 1 with the most market share is Symbian at 65% -- Linux is out there too, and what about Motorola’s OS? Conclusion: threats cannot spread as easily since they cannot assume a single, dominant OS. |
| Hardware abstracted from the OS: Single threat will run on any Windows-supported hardware (AMD, Intel processors make no difference as long as long as it is the same bit rating) | Hardware and OS more tightly linked—at least differences across platform force application development challenges such that you cannot compile for Symbian and then expect it to run across all Symbian devices—has to be recompiled for the specific processor used on the phone if not the phone itself Conclusion: not only can threats not assume a single OS, but even on that OS, threats cannot cross processor architectures (i.e.in 05, CommWarrior could not jump from a Nokia phone to a Sony Ericsson phone via BT or MMS, even though both used Symbian Series 60). |
| Incentive: $$$ | Phones are not used for cash transactions in most places—yet. The data they store on average is more useful for spammers than anyone else. Conclusion: there is less incentive for malware to afflict a mobile phone since the authors cannot directly monetize their theft. |
| Unauthorized installs quite easy along with exploits or fake alerts | Code-signing and platform issues (mentioned above) make this difficult, forcing attackers to resort to trickery and low volume attacks Apple gates this by forcing everything through iTunes (all apps have to register and be sold via iTunes). Symbian forces applications to be signed by them. MSFT has code-signing with Windows Mobile 6, unsigned apps will prompt the user once and will not have access to certain “dangerous” APIs. J2ME could facilitate this, but would have to vulnerable and installed on the vast majority of devices—and you would have to have a static IP address or some vector of exploit, such as a popular browser like FireFox. J2ME attacks will force prompts for every dangerous action, so social engineering a la RedBrowser may be effective, but self-replicating malware is unlikely. RIM uses same model as J2ME. Conclusion: Unauthorized, silent installs are unlikely without physical theft of a phone itself due to the level of control the OS/device manufacturers exert over the handset. |
| No money trail for spamming | If someone is spamming via your phone, many users will receive an “out of whack” bill (SMS is not free for many), funny charges or have a monthly bill they are accustomed to receiving. Conclusion: Not foolproof, but it’s harder to remain unnoticed on a phone when spamming. |
| Proximity unlimited—completely remote attacks are du rigueur | Remote attacks are possible today with repeaters and antennas, but there are still geographic limitations. Conclusion: an attack like Slammer which spanned the globe in 15 minutes is highly unlikely. It hinged on auto-execution of code, poor centralized control, and no proximity limits. |
| ISPs serve as the transportation network—many of them and they sprang up quickly. Sharing relationship were new as they were not well acquainted with one another and intensely competitive. This is how phishing “takedown” services proliferate, basically they are go-betweens across ISPs for brands asking for fraud sites to be taken down. If ISPs had better fraud detection services and coordination, phishing would not be the problem that it is. Not to mention the existence of rogue ISPs like the Russian Business Network. | Telcos are the transportation networks—while very competitive, they have longstanding relationships and are more likely to work together to solve resolve a large threat than an ISP. |
What does the market for phone-based security services look like?
§ Easy data encryption and backup
§ Potentially includes privacy services
§ Identity protection
§ Safety services for file download & install, hotspot access, etc.
§ Parental controls (centralized, across devices)
What can consumers do to protect themselves?
1. Don’t store sensitive info on your phone.
Names and addresses are understandable, but don’t put your SSN and CC data on your phone. At least not unencrypyted.
2. Password protect your phone.
It’s irritating, but it will prevent most data theft if the phone is lost or stolen.
3. Back-up your phone data.
You never know when you will need it.
4. Set your device’s Bluetooth to undiscoverable.
Will prevent unsolicited requests and will not affected paired devices.
5. Don’t accept incoming BlueTooth requests unless you asked for it.
No good can come from it.
6. Review your monthly bill for any funny business.
Will help you identify fraudulent charges/spam impact.
7. Don’t install files from untrusted sources on your phone.
Might affect your phone performance, stability, or security.
Closing statement
§ Watch for transaction increases to drive more malware author incentive
§ Watch for IPv6 and dedicated IP addresses—promises for more issues and concern
§ Malware itself is not likely to target an OS platform, but rather the web which is quickly becoming the platform for all devices.
o Windows has been the target of choice b/c it is pervasive, the web is becoming this today given the proliferation of devices and increased functionality (i.e. web 2.0)
o Attackers in the future will aim for the web since it offers the biggest return, but even these attacks will be language specific (unless you can get at a global ad network)
§ Threats will therefore “merge” from the PC world to phones and other web-enabled devices where they will exhibit traits we are already seeing today
o More reliant on deception than technology exploits
o Service specific
o Language specific
And they will likely be non-persistent “flash” attacks.
So we won’t have to worry too much about self-replicating malware, but malware and spyware will be a worry, especially those that focus on install via deception (Trojans).
§ Nonetheless, we think the market is much broader than malware protection alone, it encompasses
o Easy data encryption and backup
o Potentially includes privacy services
o Identity protection
o Safety services for file download & install, hotspot access, etc.
o Parental controls (centralized, across devices)
.jpg)
