By Dan Cornell
[See this post on Smart Phones Dumb Apps for updated iPhone and Android security information along with presentation slides and sample code.]
Everyebody (myself included) is all excited about the iPhone. ActiveSync connectivity to Exchange makes it a viable option for Enterprise users and the AppStore opens up all sorts of possibilities to extend the device's capabilities. However, organizations looking to deploye iPhone apps should take a few things into consideration:
- The iPhone is a new device that will host sensitive information. iPhones can be lost and stolen. How much of your data is going to be sitting unencrypted on the device when that happens? It is true that the iPhone SDK has a number of built-in cryptographic routines and that is great. However when we've looked at the use of crypto in other mobile environments (commercial applications for Windows Mobile in particular) we have found that things like key storage and proper use of algorithms are sorely lacking. I don't expect this will change for iPhone developers who are not specifically looking into security. A recently-discovered bug allows attackers to bypass the phone keypad lock and view sensitve information like web history and contacts. Expect more issues like this to surface and be careful what you store on your iPhones.
- This is a new platform and is not terribly open - many risks are still unknown. We've posted here before about Apple's application kill switch. What else is going on under the hood? What data is Apple slurping off iPhone devices and sending back for their analysis? The Independent Security Evaluators folks made an excellent observation that the security features associated with iPhone applications are more geared toward protecting Apple's revenue model rather than protecting developers and users of applications. The iPhone is a classic example of technology being deployed first and then secured later.
- The application development environment is C/C++/Objective-C based which re-opens the danger of buffer overflows. At least J2ME and mobile .NET environments try to provide some protections against this traditional software security bugbear. The iPhone development environment is a big step back if you want to avoid remote code execution flaws. And everyone wants to avoid remote code execution flaws, right? Issues with Apple's own Safari browser have already been documented and if organizations are developing their own applications they should expect more of the same.
- Applications are often a combination of native applications and web applications, opening the possibility of Cross Site Scripting (XSS) and Cross Site Request Forgery (CSRF). One iPhone developer I talked to said that the only way they were able to have their application ready by the iPhone 2.0 launch date was to use web controls and re-purpose a lot of web-based code they had running a similar application and incorporate it into their app with embedded web controls. Being able to re-use existing functionality is great for productivity, but creating hybrid web/native applications re-opens the possibility for web-only attacks like XSS and CSRF. Combine that with buffer overflows and you have the worst of both worlds.
- The attack surface of the device is variable. Between WiFi, bluetooth, 3G, and Edge wireless how do you know what can find your device at any given time? With the built-in GPS and location services who knows who your device is telling about your location at any given time? The iPhone is a very cool device because you can do a lot of stuff with it. Security-minded organizations are going to ask what they should be doing with it.
iPhones are certainly cool and with new features like ActiveSync integration for Exchange they are going to increasingly penetrate enterprise environments. However it is important that organizations understand the security risks associated with rolling out iPhones and running custom iPhone applications.
So what can be done?
- Think about the information you are going to deploy to your iPhone devices and use the available cryptographic routines to protect data while it is at rest on the device.
- This one you mostly just have to live with for a while unless Apple decides to open up or until the platform has been through more testing. The important thing is to make decisions with eyes open and understand the risks.
- Train your developers in secure coding techniques to avoid buffer overflows and other issues plaguing C-based applications and use well-tested libraries to help reduce the risk of buffer overflows in your application code.
- Use threat modeling to know what data sources your application is using. Train your developers to properly validate incoming inputs and to escape application outputs.
- Have users turn off features they don't need. Not using WiFi? Turn it off. Not using bluetooth? Turn it off too. Entice your users to do this with promises of extended battery life.
I love my new iPhone, but I don't harbor many illusions about the risks it poses.
Contact us to talk about building security in to your iPhone applications.
--Dan
@danielcornell
dan _at_ denimgroup.com
