With the explosive use of smartphones and other mobile devices, it's no wonder mobile platforms are getting so...
much attention from security researchers and opportunistic criminals. Mobile device topics were all the rage at this summer's 2012 Black Hat Briefings and DEF CON 20, and we've seen interesting developments in the mobile malware arena in recent months. Consider Charlie Miller’s near-field communication (NFC) hack or DKFBootKit, the first known Android bootkit that loads itself during the device’s boot sequence.
For enterprises, the new exploits and threats against mobile platforms mean a lost mobile device is far from the only risk they face with the rise of the bring-your-own-device (BYOD) trend. Users are downloading mobile applications from a variety of app stores - some legitimate, some not – and rogue applications could carry malware or have other negative consequences for a business. Internally developed applications, if not coded securely, can also pose a risk.
Let's take a look at the mobile application threat landscape and mobile application security best practices enterprises can implement to protect themselves.
MOBILE APPLICATION SECURITY THREATS
The first three items in Deloitte's Top 10 Mobile Threats list set the table for a discussion about mobile application security:
- Mobile device attack surface is narrow but deep
- Mobile malware
- Application proliferation
Miller's NFC hack at the BlackHat Briefings helps illustrate the first threat - the premise of an attack surface that is narrow but deep, born of rich service offerings and coupled with user-centric attack vectors. As NFC becomes more popular (think in terms of paying for as soda at a vending machine with a wave of your phone) additional devices manufacturers will add NFC to their offerings. Miller discovered that the most interesting attacks opportunities exist at the application layer while analyzing Android Beam on Android phones and the Nokia Content Sharing app on a Nokia N9 running Meego. Android Beam allows an Android user to touch another similarly enabled Android and have it load a webpage. As such, while the attack surface in this scenario is browser-specific (narrow), it runs the gamut of browser-centric attacks via scripts, audio, video, and graphics (deep). Nokia Content Sharing is similar but an even worse offender as it can force another user’s phone to load content without interaction. There's no vulnerability per se, just application design that tips the hand in the attacker’s favor.
Consider the impact here from the enterprise perspective. If an attacker can force a device laden with corporate data to browse to a site offering a malicious payload, without any user interaction, the adversity far exceeds the feature’s benefits. Loss of proprietary data and intellectual property with a simple proximity attack could be devastating.
The mitigations here are relatively straightforward. As pointed out by the NFC Forum after Miller’s presentation, it’s important that appropriate security measures are provided at the application layer. The onus here is on device manufactures to develop more robust security settings for NFC. Such measures should enable users to adjust security settings to their needs and preferences. Users and/or enterprise managers will then need to ensure that these features are put to good use. Miller reiterated that NFC-enabled device manufacturers would be wise to include the option to seek explicit user approval before allowing any data received over NFC to be processed by applications.
The second threat cited by Deloitte, mobile malware, is a category that's undoubtedly on an explosive growth curve. Case in point: According to Juniper Networks, the period between July and November 2011 saw a 472% increase in Android malware. The DKFBootKit is a recently discovered and rather frightening example. According to NQMobile’s research, the Android malware mounts a writable system partition, inserts itself in the /system/lib directory, replaces several common utility programs, and modifies related services and scripts. Translation: total Android pwnzor. Much like well-known recommendations for running PCs, if you don’t need root or administrative privileges, don’t use them; DFKBootkit infects utility apps that require root privileges to run.
Bootkits are still an edge case, but other types of mobile malware are proliferating. SMS Trojans, man-in-the-mobile (MitMo), and QR code attacks all made Kaspersky Lab's Mobile Malware Evolution, Part 5 with SMS Trojans (evil sent via text message) making up 27 percent of all mobile malware targeting the Android platform. MitMo attacks are particularly popular with attackers targeting banking victims as they bypass second factor authentication systems that send codes via SMS text messages to a mobile device to confirm identity. Of all mobile threats assessed by platform, 65 percent targeted Android with J2ME (Java) a distant second at 27 percent.
All major antimalware providers offer mobile protection, including free and commercial offerings, but users needn’t limit themselves to antimalware. Behavioral analysis tools are also useful. Apple iOS device users can download an inexpensive app from iTunes called Clueful from Bitdefender, which will scan your iPhone or iPad for installed apps and filter them in an ordered list based on various kinds of behavior such as location tracking, reading the address book, and battery drain. It also determines if apps use an iPhone's unique ID, display ads, or gather analytics. It will also tell you if your data is being encrypted and if apps anonymize you as a user. There are similar low-cost or free offerings for Android, often bundled with antimalware packages.
For those of you who really want to dig in to Android devices in order to study the landscape or analyze a possible compromise, there are tools such as Androguard for reverse engineering and analysis of Android applications. There’s the Mercury Framework which automates the discovery and interaction with exposed Android application features, a process that often requires numerous custom scripts, in a single console. Andrubis, a Web service you can submit Android Package files (APKs) to, is excellent for static and dynamic analysis approaches to various behavioral aspects and properties of unknown apps for the Android platform. You can also conduct physical memory analysis of Android devices with LiME - Linux Memory Extractor. Memory analysis, as a leading edge forensic technique for PC-based systems, can also aid mobile investigators given that volatile memory yields a wealth of essential information when performing incident response or analyzing advanced malware that otherwise doesn’t utilize non-volatile storage.
Deloitte's third entry in its list of mobile threats, application proliferation, touches on a theme you’ll hear over and over again in discussion of mobile application security: Only download apps from trusted app stores, but even then your absolute safety is not guaranteed. In July, NIST released a draft version of Revision 1 for SP 1 for 800-124 "Guidelines for Managing and Securing Mobile Devices in the Enterprise." The guide indicates that “organizations should plan their mobile device security on the assumption that unknown third-party mobile device applications downloadable by users should not be trusted.” There also is lots of conventional wisdom about ensuring apps run only with the permissions necessary and don’t leverage system resources beyond those that are explicitly necessary.
This is all sound advice but easier said than done. Prohibiting third-party apps, whitelisting only known good apps, and sandboxing to isolate organizational data are all viable mitigations but not the easiest to implement. Whitelisting and blacklisting require user acceptance testing to ensure enterprise app needs are met to maintain productivity, and data sandboxing requires specific network infrastructure architecture to enforce. These mitigations also typically assume your organization maintains centralized mobile device management (MDM) technology, which comes with expense, administrative overhead and can meet with user resistance. There is an industry trend towards MDM as a service where organizations can avoid internal hosting challenges while still benefitting from centralized policy configuration, push authentication, device tracking, and remote wipe to offset loss or theft. In the realm of BYOD, certain restrictions still can help strengthen your defenses when facilitated with MDM. These should include restricted use of synchronization services, distribution of organization-specific applications from a dedicated mobile application store, and limited or no access to enterprise data if the mobile device’s operating system version or mobile device management software client versions are not current.
SECURE MOBILE APP DEVELOPMENT
In addition to mitigating the risk of users downloading rogue mobile applications, companies need to take care that the mobile applications they develop internally are secure. Here is where threat modeling and a secure development lifecycle are critical. The fledgling OWASP Mobile Security Project’s Security Testing Guide offers general mobile application testing methodology to describe analysis from an application developer’s perspective with attention to application vulnerabilities while examining their relevance relative to its underlying architecture. Information gathering (reconnaissance and mapping) and dynamic analysis (runtime and interaction) are discussed in the guide but the rubber really hits the road in the static analysis content. Source code review is inherent here to frame a developer’s heightened awareness regarding authentication, authorization, session management, data storage, transport layer protection, information disclosure, and Web application issues. The Denim Group offers an outstanding Secure Mobile Application Development Reference that gives equal coverage to iOS and Android development and leads off with guidance specific to threat modeling.
More than three years ago when I wrote Microsoft’s Solution Accelerator - IT Infrastructure Threat Modeling Guide, I described a fictitious organization's communications system as an example for the IT infrastructure threat modeling process. Given the rapid introduction of mobile devices into IT infrastructure, such systems make for a target rich environment for attackers. While I intended the scenario to promote threat modeling the infrastructure that supports mobile devices, the scenario easily crosses into discussion of threat modeling as part of secure mobile application development.
Incorporating threat modeling and following secure development lifecycle practices also helps address another item on Deloitte’s list: immature security solutions. Given that there are a number of popular mobile operating systems and proprietary implementations per major carrier, it’s easy to see how failing to adhere to standards and ensuring industry wide best practices may deter from mature, universal security solutions. Following guidance such as that prescribed by OWASP and organizations such as the Denim Group when developing mobile applications will go a long way towards overcoming diversity in the mobile device industry. Quick and easy implementations, such as use of SSL for application data transmission, also help offset development quality disparity. Mobile applications, particularly financial apps and those transacting in personally identifiable information (PII), should automatically fail on invalid certificates and disallow degrading sessions from HTTPS to HTTP.
Training core members of your enterprise security teams to understand mobile security issues also lends to strengthened defensive tactics. As an example, the Mobile Device Security and Ethical Hacking course from the SANS Institute assists students in building critical skills necessary to support the secure deployment and use of mobile devices in your enterprise, including details on analyzing and evaluating mobile software threats.
Finally, organizations with an appetite for more extreme measures may consider deploying the National Security Agency’s Security Enhanced (SE) Android, a security-hardened version of the Android OS that aims to “limit the damage that can be done by flawed or malicious apps and in order to enforce separation guarantees between apps.” Security-Enhanced Linux (SELinux), developed by the NSA, has aided in protecting Linux operating systems for years; now the same capabilities can be applied at lower layers of the Android software stack to confine root exploits and application vulnerabilities.
Common sense and heightened awareness for enterprise mobile device users cannot be understated in their value. All due diligence to address mobile application risks must be applied to protect the enterprise in this, an era of explosive mobile device use. Whether your organization develops mobile applications or supports and consumes them, make securing mobile applications one of your highest priorities.
About the author:
Russ McRee is a security analyst, researcher, and founder of holisticinfosec.org, where he advocates a holistic approach to the practice of information assurance. He also writes toolsmith, a monthly column for the ISSA Journal, and has written for numerous other publications. Please send comments on this article to firstname.lastname@example.org.