In the last few years we have seen cross-platform development frameworks become more and more common, with a consequent increase in“hybrid” mobile applications submitted to App stores and to Foregenix for security testing.
The reason is undoubtedly because of the interesting advantages in cross-platforms frameworks, including allowing developers to create mobile apps without learning new (to them) native languages, the idea of having to maintain one single application for different platforms (i.e. iOS, Android, WUP) and so on.
While some of these frameworks did not initially focus much on providing out-of-the-box security, things improved quickly. In this series of posts, we are going to look into two of the most common frameworks, Cordova and Xamarin, and consider some of the most common security issues to see how easy it would be to achieve basic security using the standard features provided by these frameworks when developing on Android and iOS.
This will be a 3 part series where:
Although HTTPS by design offers a secure means of exchanging data, there are a few things to consider when we implement an HTTPS client in a mobile application, or when simply connecting to an HTTPS enabled site. As we tend to carry our smartphone pretty much everywhere and connect to any wireless network that gives us Internet connectivity, how can we guarantee that an attacker-controlled network will not invalidate the controls we set up to secure our connections? How can we guarantee the in-transit security of our data even when a device has been somewhat compromised (e.g. the user was tricked to trust malicious CAs, etc.)?
SSL Pinning is [or more accurately tries to be] the answer to these questions. The idea is pretty simple: upon connection, we double check the SSL certificate provided by our server against a local copy of the certificate, or we compare the fingerprints. This would stop any attempt to compromise communications through a man-in-the-middle attack..
Of course, this control could be bypassed when a device is in full control of an attacker (and this is often how penetration testers carry on their mobile application security analysis), but the aim of SSL pinning is to guarantee secure connections before a device gets compromised.
Since storing data securely became critical in order to produce secure apps, mobile operating systems have introduced features to help developers. Although it’s very common for a novice developer to think that the basic controls offered by the operating systems (i.e. sandboxing) are enough to keep data safe, the reality is that it’s really easy to expose sensitive information stored by an application. Examples include information included in a backup, data exposed by a vulnerable component of the application, or data extracted by an attacker from a stolen device.
Both Android and iOS, the two operating systems (OSs) included in our analysis, offer secure ways to store information which make use of hardware-based modules to offer strong cryptographic controls.
While these solutions are not always 100% bulletproof, they are constantly evolving and surely remain the best option to provide at rest data security on mobile devices.
These issues relate to attackers analysing the application, looking for additional information or anything that could help them when attacking the application.
Logging
Although logs are essential during the development or enhancement of an application, once the application is published to the relevant platform marketplace there is no point in producing local logs on the device it is installed. These could be abused by an attacker and more often than not, prove to be a treasure trove of sensitive information.
Secure code will remain secure even in front of a thousand eyes, as many open-source projects show us. Having said that, source code obfuscation does have a place in the application development and deployment lifecycle, that place being to make an application harder to analyse to the point where a casual attacker is deterred from analysis and moves on to another application. As a side note, source code obfuscation should never be completely relied on to provide security for the application on its own. With the above in mind, we will explain why source code obfuscation is commonly misapplied on cross platform framework applications.
Once our apps are built for the 2 platforms, we are going to have an apk package for Android, and an ipa package for iOS. If we are required to implement source code obfuscation on the apk version of our - for example - Cordova based application, we may naively look for Android obfuscation options, like Android’s built-in ProGuard, just to find out on the penetration testing report that no obfuscation seems to be applied.
The reason for this is that when we generate the platform-specific application, there is minimal native code. That native code has the sole function of“calling” the actual source code containing the app logic, such as HTML/Javascript code for Cordova and .NET code for Xamarin. As such, obfuscation is applied to the wrong component of the cross-platform application.
This is the end of the first part of this blog post series. In this one we discussed the most common mistakes and laid the ground for the next 2 posts, Apache Cordova and Xamarin respectively, to build upon.