The security of mobile applications is a serious and growing concern for users and mobile application market places (Apple’s App Store, Google Play, BlackBerry® World™, Windows Phone Store), where users are the target and the market places enable the delivery of malware. We have reviewed the recent history of the mobile space, looking at the vectors available to hackers and malware producers. We’ll highlight some facts and figures that should cause many to rethink the device that they give all their information to, and carry everywhere with them.
Table of Contents
Mobile App Security
When an application is submitted for inclusion on any of the main supplier stores it is scanned for malware and its usage permissions are collated and presented to the user. They range from “network level access” which basically “should” mean the application requires connection to the internet. However more and more applications seem to include the permission “collects location information” or “collects personal information such as contacts”. For many applications this can be a boon, applications such as Facebook will use this to tag where a photo is taken and suggest other users of Facebook to you, based on their email address or mobile number contained in your contacts list. The flip side of this is the growing number of applications that harvest the information for no application based reason and seemingly just because they can.
This can also affect application updates. Permissions changes are again highlighted to the user but often in high level/technical language and without the user comprehending the purpose or usage of that collected data. The lesson for users is, if they choose to give their information away, they shouldn’t be upset if the people they give it to mishandle or misuse it.
Mobile Devices
Android OS
If an attacker “found” your work-issue Android handset what could they do? Even if your screen is locked is it vulnerable to a bypass exploit? Remember the flaw in 4.1.2 that allowed the installation of an unlock app using just voice and touch? How about simply pulling the SD card and reading whatever’s on that? Encryption Manager for Android will let you encrypt the SD, and once a PIN is set up you can use the standard security settings to enable crypto on the device memory.
The bigger concern is the risk posed in a BYOD environment. A handset that’s been attached to a corporate network and is running work email is likely to have stored enterprise data, and a route to data stored on corporate servers. Pretty scary when all too many people don’t even use a lock passcode.
To cap it all how do you know what rubbish they’ve been downloading to their device? What are you allowing onto your network when they join? Malicious apps that create a nice backdoor? That’s the worst case scenario.
iOS
This mobile OS is locked-down more heavily than any carrier-branded Android OS. As a result there are plenty of Apple iDevice users who will run untrusted privilege escalation exploits- jailbreaks. Getting root access is desirable as it allows the running of unsigned code, unapproved apps.
The issue for users is the potential for having personal and usage data harvested by those unsigned rogue apps. However as it is possible to get a malicious app approved by Apple the risk is similar for all users. Targeted attacks which are iOS version specific are also enabled by OS vulnerabilities. For example a phishing attack can get a user to give up the spec of their device, which is then followed by sending them a poisoned link, usually to an image or PDF which contains the exploit. Apple deals with these issues by constantly providing updates.
What Apple can’t deal with so efficiently are vulnerabilities in the read-only bootrom (SecureROM). They can only be exploited locally, requiring physical access to the device. The exploits enabled by these vulnerabilities are only dealt with through subsequent hardware improvements. So, exploits written for older version iDevices will be permanently vulnerable/jailbreakable.
The risks to corporate networks from jailbroken devices and/or rogue apps is very real. Email access can be gained via Exchange, and if a compromised device is plugged-in unchallenged the risk of infection is high. In particular the MDM for iOS should be configured to wipe, thoroughly, any sensitive data if it finds the device is jailbroken.
MDMs and Policies
MDM solutions can only handle issues well if they’re configured properly. For example complex passwords should be default. There are loads of recommended MDM best practices out there, but these are the fundamentals that should be the bare minimum in any policy:
- Enforce encryption
- Keep an eye on apps
- Know your industry’s regulations
- Monitor your devices
- Enforce passcodes
- Restrict device features where needed
- Test your policies