Since Apple released the iPhone in 2007, it has become one of the most dominant mobile phones in the market. In fact, Canalys forecasts Apple capturing 21.3% of the mobile market in 2010. The iPhone has seen quite a few significant platform security issues along the way. There has been a continual effort on jail breaking (gaining complete control over) the iPhone, and unlocking it (allowing it to be used on any GSM provider). Much of the security news related to the iPhone focuses on the platform itself, while less attention has been paid to individual applications in the app store (and how they are developed). What are the most common security risks affecting iPhone applications? Based on our experience testing iPhone applications we have compiled a top 5 list of security issues for developers:
1.) Sensitive data unprotected at rest – Mobile applications cut right to the heart of software functionality to provide what users absolutely need when they are on the move. For many applications, this can involve displaying, or even storing, sensitive data. Many iPhone applications read and display sensitive data, such as medical lab test results, or personal and business oriented financial data. For example, the Care 360 Mobile iPhone application allows doctors and medical professionals to retrieve and view lab results from Quest Diagnostics. Many large banks also provide mobile applications to provide better user experience than the Safari web browser for online banking. These applications handle some of the most sensitive data (medical and financial) most users will ever possess. Additionally, many applications also provide a variety of “remember me” functionality. Keeping this data secure and out of the hands of a malicious adversary is therefore of paramount importance for both the user and the application provider.
The solution to this problem is careful architecture design with a risk-based approach to help decide the security posture the application has towards data storage. Once the risk has been determined, it is essential to protect sensitive data that must reside on the device using a combination of strong cryptography and the Apple Keychain services, or equivalent cryptographic constructs, to protect this sensitive data while at rest.
2.) Buffer overflows and other C programming issues – The iPhonedevelopment platform is primarily Objective-C based. Objective-C provides a much cleaner environment for the programmer when compared to C. It inherently prevents many common C programming errors, which can result in exploitable bugs and flaws in an application. If a developer writes an application purely from within the confines of Objective-C using the Foundation, UIKit and other pure Objective-C frameworks, the application is relatively safe from most of the security issues that afflict C programs. For example, the NSString class prevents buffer overflow bugs effectively in most cases (assuming there are no flaws in the underlying NSString implementation). Another key point to the pure Objective-C environment of the iPhone is the fact that all object allocations go on the heap, which helps prevent stack overflows since directly programmer controlled memory does not live on the stack. The developer is responsible for allocating and deallocating objects, but the complexity is largely hidden from the developer compared to a C implementation.
However, some parts of the iPhone SDK require the developer to revert to standard C. This is an all bets are off proposition that eliminates the safety provided by the Objective-C platform. It is common to build and include C libraries in an iPhone application to avoid re-implementing code (and it is often the right choice from a time to market standpoint). This means going from relatively safe Objective-C libraries and moving to less safe C style strings for libraries like SQLite, a core part of many iPhone applications, and . Buffer overflows are one of the various issues that plague C programs. Vulnerabilities can stem from heap overflows, format string attacks, integer overflows, and other more subtle issues that are relevant when developing in C for iPhone.
Generally avoiding C libraries when at all possible is ideal. However, when C and C libraries are required developers must follow best practices derived over the lifetime of the C programming language. When observing best practices mistakes may still occur. Development teams must use safe string libraries and individual developers must understand the risks and vulnerabilities that can occur when writing code in C.
3.) Secure communications to servers – Almost every useful application that handles sensitive user data will connect back to some server component. Developers are, thus, faced with the challenge of having to protect sensitive data in transit as it traverses the Internet and sometimes even insecure wireless media. This is done using encryption; that must be implemented correctly.
Effective encryption entails avoiding reinventing the wheel and using trusted libraries that have been thoroughly reviewed. The iPhone SDK is, largely, like any other SDK regarding its SSL libraries. Developers must take care when using the URL loading library as the way the applications use the libraries in a development build or configuration will typically differ from proper usage in production. The default state of operation for the URL loading library is to fail on an invalid server certificate. However, during development it is often required to use an invalid certificate. Failure to use the libraries properly can result in weak client to server communications that allow a malicious adversary to compromise client to server communications.
4.) Patching your application – The App Store could be your worst enemy, a proper risk assessment of an organization’s tolerance for risk should be conducted to determine if the app store policy will match up with, and be acceptable, for any given application. Apple maintains tight control over the App Store and it will not be possible to issue a release in a very short (24-48) hour period in most cases. The Apple approval process generally takes at least a week. If the application has any issues that would cause it to fail, the approval process of the new build could take weeks to reach customers.
Unfortunately, there is very little that an organization can do regarding the risk associated with this issue. The best bet is to ensure that developers have a clear understanding of app store policy and that the testing process is thorough and proactively identifies issues that would cause the application to fail the approval process.
5.) The platform itself – User awareness is also a critical component of application security. Users often perceive and treat their mobile, Internet connected, devices with a different level of care compared to a laptop or desktop. Password policies, anti-virus software, and at least some awareness that their computer may contain sensitive data and that it requires protection is the norm for most users. Mobile devices are often lost, not password protected and get treated with a lower level of security awareness. This means that a user could easily lose their phone to a malicious individual and have their sensitive data compromised.
Thus, it is important to attempt to raise the mobile user’s awareness of the risks they are exposed to through well constructed documentation and application design. A mobile user that is more security conscious may take efforts to secure their environment more, such as by using a PIN or pass phrase to secure their device, and subscribing to Apple services that can help locate and disable lost or stolen devices. From a developers perspective the key thing is to alert the user when they are making security sensitive actions via visual cues and or dialogs/text. Users will generally do whatever is quickest and easiest for them. Developers must design these features to be as unobtrusive as possible.
Published date:  04 May 2010
Written by:  jeremy.allen