SHARE

Security Nightmare in the iPhone App Gold Rush

There’s a gold rush going on out there before our eyes. What, you haven’t noticed? Perhaps you’ve been too busy watching the gloom and doom on Wall Street and Main Street. But it’s there, mark my words, and there are security risks aplenty to be found. Give up? It’s mobile applications—primarily on Apple’s iPhone/Touch, but […]

Written By

Kenneth van Wyk

Jan 7, 2009

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

There’s a gold rush going on out there before our eyes. What, you haven’t noticed? Perhaps you’ve been too busy watching the gloom and doom on Wall Street and Main Street. But it’s there, mark my words, and there are security risks aplenty to be found.

Give up? It’s mobile applications—primarily on Apple’s iPhone/Touch, but also rapidly coming along on other platforms.

No, user-installable applications aren’t anything new on small mobile devices. We’ve seen them for years: Newton, Palm, Blackberry, and others. But leave it to Apple to find the right “special sauce” to make them wildly popular.

I just heard about an iPhone application that simulates a fart noise, where the developer has made some $40,000 in just a couple months. Even if that number is exaggerated, it still represents a gold rush sort of phenomenon.

Is anyone else concerned about the security of this new gold rush? Just how safe is it to download and use, say, an application that can access my Amazon account and make purchases with “one click”? (Gulp!)

I’ll venture this: even if the consumers of these apps are blissfully unconcerned by the security perils they face, there are plenty of others—some good, some not—who are taking a much closer look at the underpinnings of this gold rush, looking for opportunities of their own. I’m in the process of exploring that question in some more technical detail myself (more on that later).

For now, let’s take a quick look at some of the basic architectural issues that are in play with the advent and wild popularity of today’s mobile application environment.

The first wave of applications we’ve seen on the iPhone/Touch have been in a few different general categories. Stand-alone apps and games are one big category—basically, apps that require no special network connectivity in order to be able to run effectively.

We also have networked apps that simply acquire and display data from network sources—think news headlines, weather reports, and that sort of thing. Then there are full-blown network apps that require authentication via user login credentials, and access the user’s account information on a server somewhere—think Amazon, Facebook, and the Apple application store itself. Most of the networked applications we’ve seen to date are basically mobile “desktop” versions of their web-based counterparts.

Now, each of these applications carry with them some degree of risk. I’ve mentioned here previously that (at least early versions of) iPhone firmware run all user applications with root privileges. Thus, even a standalone app can potentially do some harm on the host device.

But it’s not just as simple as downloading some malware and running it on the device, right? After all, there’s the Apple application store that does some screening of the applications before they’re accepted in the app store. Doesn’t that buy us some security?

Well, it does and it doesn’t. The good news is that the applications must be signed by the person who generated them, and it’s a relatively closed community. The bad news is that signing applications only tells us so much. Notwithstanding the recent attacks against MD5 certificates used by SSL and others, signed applications give us a pretty good indication of who wrote the application. Further, the folks at Apple review applications, but my bet is that the reviews consist of verifying policies, and not so much checking the security of each application.

I wouldn’t expect, for example, that Apple’s review process would ensure a client/server application uses a sound identification and authentication scheme that encrypts the user’s credentials while they’re in transit and while they’re at rest on the server side. I wouldn’t expect the review process checks anything at all on the server side, for that matter.

But if the applications are (to date) mostly desktop versions of their web counterparts, isn’t that better than allowing active code (like Javascript) to run in the browser?

Ah, now there’s an interesting point. Since the functionality basically duplicates what the web applications can do already, at least with the mobile applications, the client side code is static, downloaded from a respectable source, and not subject to subversion by pointing the client to a malicious URL that contains some evil Javascript or other active code.There’s a point in favor of the mobile app versions vs. the web versions of the same applications.

My main point here is that it’s a rapidly changing dynamic environment, and we don’t fully understand all the ramifications of that yet. Clearly, time will illuminate the issues more clearly. For now, I sure hope the application developers aren’t consumed by a gold rush mentality and that they’re practicing safe development methods to ensure all the good stuff—solid authentication, encryption of sensitive data, input validation, etc.—are being thoroughly addressed in the code they release into the wild.

It’s very much a gold rush, and a major mistake would do a great deal of harm to us all. The fact that the applications themselves are generating such interest and revenue, even in our troubled economic climate, is a wonderful thing to see unfold. Let’s not ruin it by making stupid mistakes, please!