Projects/OWASP Mobile Security Project - Security Testing
Mobile Security Testing
A major priority of the OWASP Mobile Security Project is to help standardize and disseminate mobile application testing methodologies. While specific techniques exist for individual platforms, a general mobile threat model can be used to assist test teams in creating a mobile security testing methodology for any platform. The outline which follows describes a general mobile application testing methodology which can be tailored to meet the security tester’s needs. It is high level in some places, and should be customized on a per-platform basis.
This resource targets analysis from an application developer’s perspective. This includes vulnerabilities within an application and examining their relevance relative to its underlying architecture. The ideal mobile assessment combines dynamic analysis, static analysis, and forensic analysis to ensure that the majority of the mobile application attack surface is covered.
On some platforms, it may be necessary to have root user or elevated privileges in order to perform all of the the required analysis on devices during testing. Many applications write information to areas that cannot be accessed without a higher level of access than the standard shell or application user generally has. For steps that generally require elevated privileges, it will be stated that this is the case.
This resource is broken up into three sections:
- Information Gathering- describes the steps and things to consider when you are in the early stage reconnaissance and mapping phases of testing as well as determining the application’s magnitude of effort and scoping.
- Static Analysis- Analyzing raw mobile source code, decompiled or disassembled code.
- Dynamic Analysis - executing an application either on the device itself or within a simulator/emulator and interacting with the remote services with which the application communicates. This includes assessing the application’s local interprocess communication surface, forensic analysis of the local filesystem, and assessing remote service dependencies.
How To Use This Resource
As this guide is not platform specific (initially), you will need to know the appropriate techniques & tools for your target platform. The OWASP Mobile Security Project has also developed a tools guide that provides a reference for tools to perform many tasks as well as quick-start guides for many of them. <Link Here>
In this current draft release, the guide is a work in progress. We need additional contributors to help fill in the blanks. If you think something is missing (there certainly is), add it.
The steps required to properly test an Android application are very different than those of testing an iOS application. Likewise, Windows Phone is very different from the other platforms. Mobile security testing requires a diverse skillset over many differing operating systems and a critical ability to analyze various types of source code.
In many cases, a mobile application assessment will require coverage in all three areas identified within this testing reference. A dynamic assessment will benefit from an initial thorough attempt at Information Gathering, some level of static analysis against the application’s binary, and a forensic review of the data created and modified by the application’s runtime behavior.
Please use this guide in an iterative fashion, where work in one area may require revisiting previous testing steps. As an example, after completing a transaction you may likely need to perform additional forensic analysis on the device to ensure that sensitive data is removed as expected and not cached in an undesired fashion. As you learn more about the application at runtime, you may wish to examine additional parts of the code to determine the best way to evade a specific control. Likewise, during static analysis it may be helpful to populate the application with certain data in order to prove or refute the existence of a security flaw.
In the future, contributors to the testing guide should consider adding entries under each section relevant to a specific platform. Over time, OWASP contributors will write platform specific guides and expand upon this body of knowledge.
If a specific area of interest is not covered in this guide, please feel free to either:
- write the material yourself by registering for a wiki account and contributing content: Wiki Registration
- bring this up as a topic on the Mobile Project’s mailing list: Mobile Mailing List
As a result of this initial information gathering exercise, the tester will be better prepared for the future testing phases. The sad truth is, testers (i.e. Developers, QA & Security) often fail to take the time to learn the target application and supporting infrastructure, opting to dive in blind, possibly losing valuable time and missing possible attack vectors. Without a solid understanding of how the application “should” work as well as the technologies in use, the tester will not be able to identify when the application behaves in a manner that it “shouldn’t”.
Prerequisites of this phase may require specific operating systems, platform specific software development kits (SDK’s), rooted or jailbroken devices, the ability to man-in-the-middle secure communications (i.e. HTTPS) and bypass invalid certificate checks.
- Proxy and sniff all network traffic from either a physical mobile device or an emulator/simulator. Begin recording and logging traffic (if your proxy tool permits logging, which most should).
- Register for and/or provision test accounts. Ideally, you will want two accounts per user role to ensure proper testing of vertical and horizontal privilege escalation attack vectors.
- Manually navigate through the running application to understand the basic functionality and workflow of the application. This can be performed on a real device or within a simulator/emulator.
- Identify the networking interfaces used by the application
- Near Field Communication (NFC)
- Virtual Private Network (VPN)
- Is all functionality available over 3G/4G or is wifi required for actions such as data synchronization?
- What networking protocols are in use? Are secure protocols used where needed? Can they be switched with insecure protocols?
- Does the application perform commerce transactions?
- credit card transactions and/or stored payment information.
- in-app purchasing of goods or features
- Monitor and identify the hardware components that the application may potentially interact with
- Perform open source intelligence gathering (search engines, source code repositories, developer forums, etc.) to identify source code or configuration information that may be exposed (i.e. 3rd party components integrated within the application)
- Identify if the application appears to interact with any other applications, services, or data such as:
- Telephony (SMS, phone)
- Google Wallet
- Social networks (i.e. Facebook, Twitter, LinkedIn, Google+)
- Can you determine anything about the server side application environment?
- Hosting provider (AWS, App Engine, Heroku, Rackspace, Azure, etc.)
- Development environment (Rails, Java, Django, ASP.NET, etc.)
- Does the application leverage Single Sign On or Authentication APIs (Google Apps, Facebook, iTunes, OAuth, etc.)
- Any other APIs in use
- Payment gateways
- SMS messaging
- Social networks
- Cloud file storage
- Ad networks
- Perform a thorough crawl of exposed web resources and sift through the requests and responses to identify potentially interesting data or behavior
- leaking credentials
- resources not exposed through the UI
- error messages
- cacheable information
There are two primary ways static analysis will generally be performed on a mobile application:
- Analyzing source code obtained from development team (prefered)
- Using a compiled binary. Some level of static analysis should be performed for both dynamic and forensic analysis, as the application’s code will almost always provide valuable information to the tester (i.e. logic, backend targets, APIs, etc).
In scenarios where the primary goal is to identify programmatic examples of security flaws, your best bet is to review pure source code as opposed to reverse engineering compiled software. For source code reviews, it is highly beneficial to have access to either a development or production instance of any web services. This includes both source code and a working test environment to perform the assessment within in order to expedite understanding of the code.