<6/29/2013 Update: Don Williams>

This document is a non-platform specific high level testing guide which was posted to the community mid 2012. It is located here https://www.owasp.org/index.php/OWASP_Mobile_Security_Project . Added Sid, Max and Chris as contributor as the content was posted about 9 months ago and may be to be refreshed and reviewed for any potential changes.

DOCUMENT BEGINS

Table of Contents

  • Introduction
  • How To Use This Guide
  • Prerequisites/Planning
  • Information Gathering
  • Compute Analysis
  • Code Analysis

Introduction

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 over time will be customized on a per-platform basis.

This guide is targeted towards application developers and security testers. Developers can leverage this guide to ensure that they are not introducing the security flaws described within the guide. Security testers can use it as a reference guide to ensure that they are adequately assessing the mobile application attack surface. 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 guide is broken up into four sections:

  • Prerequisites/Planning - tasks and requirements before conducting the mobile security assessment.
  • 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.
  • Compute Analysis - Analyzing the hardware itself, or the otherwise virtualized resources available to the system during/post boot. Forensics and incident handling of resource components, such as flash memory or SoCs (systems-on-chips) via their mobile logic boards.
  • Code Analysis - The analysis of operating system components including the kernel. All code analysis assumes that several strategies, such as the ones taken from The Art of Software Security Assessment, will be utilized. Such code auditing activities often take the form of lexical analysis with candidate-points followed-by/run-simultaneous-to code-coverage comprehension at runtime, or any near-full-coverage mechanism that can be used to identify entry points into an application. This could be quickly followed by black-box testing against modified/injected entry point data, including bespoke testing based on tester experience and their exploratory test plan, as well as further code-comprehension and candidate-point-assignment strategies. Optionally, a design-generalized strategy (such as Doxygen or equivalent) can be used to understand patterns and many other concepts/dependencies in use in the code.

How To Use This Guide

As this guide is not platform specific, you will need to know the appropriate techniques & tools for your target platform. The OWASP Mobile Security Project has also developed a number of other supporting resources which may be able to be leveraged for your needs,

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
  • bring this up as a topic on the Mobile Project’s Google Group: <group link here> or mailing list: <mailing list link here>

Mobile Testing Guide Phases

Prerequisites/Planning 

Prior to any security testing of application/code ensure you have written permission from authorized sources. Known as “get out of jail” authorization. There are many examples which can be found on the Internet if needed. Keep in mind to follow this for your own company’s applications and any third party applications you may be testing.

Ok now that you have documented permission, there are a number of tasks still to be completed. A few tasks might include:

  • Request test data for the application (test accounts, test credit cards, gift cards, etc).
  • Request test accounts and a role matrix of permitted actions per role. Ideally, you will want a minimum of two accounts per user role to ensure proper testing of vertical and horizontal privilege escalation attack vectors.  
  • Create Rules of Engagement document both parties agree to. This may include what types of tests are (not) permitted i.e. D/DOS, authentication brute force testing; who should be contacted prior/after testing window; encryption requirements for communication of findings; plan to deal with any critical findings, etc.
  • Agree on test environment, date and time.
  • Request testing team source IP/range
  • Acquire and document emergency contact list to be used either by test team and or application owner. What if your testing brings the system down? Who do you contact? What if your company needs the testing to halt immediately who do they contact?
  • Communicate the test (target) IP/application, dates, contacts,  testing team (source) IP/range to those that need to know. This may be in the form of a change control. The last thing you need is the create a fire drill of your incident response team.
  • Ideally request source code of the application you will be testing. This may not be easy to attain yet having the source code will allow test team insight into code level vulnerabilities and save the test team valuable time.

Information Gathering

As a result of this initial information gathering exercise, the tester will be better prepared for the future testing phases. Testers, Developers and Security people 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.

  • 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. For deeper understanding of application functionality tester can proxy and sniff all network traffic from either a physical mobile device or an emulator/simulator recording and logging traffic (if your proxy tool permits logging, which most should).
  • Identify the networking interfaces used by the application, for instance
  • Mobile Communication (GSM, GPRS, EDGE, LTE)
  • Wireless (Wi-Fi (802.11 standards), Bluetooth, NFC)
  • Virtual Interfaces (i.e. VPN)
  • Determine what the application supports for access 3G, 4G, wifi and or others.
  • 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 (certain industry regulations may be required (i.e. PCI DSS)).
  • In-app purchasing of goods or features
  • Make note for future phases to determine does the application store payment information? How is payment information secured?
  • Monitor and identify the hardware components that the application may potentially interact with
  • NFC
  • Bluetooth
  • GPS
  • Camera
  • Microphone
  • Sensors
  • USB
  • 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)
  • What frameworks are in use?
  • Identify if the application appears to interact with any other applications, services, or data such as:
  • Telephony (SMS, phone)
  • Contacts
  • Auto correct / dictionary services
  • Receiving data from apps and other on-device services
  • Permissions on them
  • Google Wallet
  • iCloud
  • Social networks (i.e. Facebook, Twitter, LinkedIn, Google+)
  • Dropbox
  • Evernote
  • Email
  • Etc.
  • 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 sensitive information (i.e. credentials) in the response
  • Resources not exposed through the UI
  • Error messages
  • Cacheable information

Compute Analysis

Analysis of the compute resources (DRAM, filesystems, and network) using forensics techniques can be extremely useful during the overall analysis of mobile devices and mobile apps.

Dumping DRAM

The physical memory and virtual memory of devices can be dumped and analyzed. The memory will typically contain the kernel and user process spaces. Modern memory forensics tools should be used to identify what memory contains sensitive information, such as personally identifiable information.

Note: Even with regular access to the memory and/or filesystems, mobile devices will provide information to adversaries via apps such as WiFi Key Recovery or SQLite Editor (Google Play Store) or com.malcolmhall.wifipasswords (Cydia app store via iOS Jailbreak).

The typical method of dumping DRAM for Android is to use volatility; for iOS, dump the filesystem with iphone-dataprotection/ramdisk_tools/dump_data_partition.sh or by using mac-robber from SleuthKit. The iOS keychain store can also be dumped with iphone-dataprotection/python_scripts/keychain_tool.py or via other known methods and tools.

Cloning Filesystems

Mobile devices typically have all cryptographic key material on unencrypted disk in addition to cleartext in memory in one of a few places. Flash memory cells on System-on-Chip (SoC) processors are common in 2012 and going forward. There are some more-than-casual protections such as the Apple iOS Data Protection store, or the Android SDK 3.0/4.0/4.1+ full disk encryption, but these are not widely in use.

Note: Using ClockWorkMod Recovery (or another Android recovery modification) via ClockWorkMod ROM Manager, a user can self-root (via D4 Update Zip Maker) and potentially load a Zip Util / File Explorer only "partial OS" such as AROMA File Manager or FROST. Exploitation engines such as p2p-adb, dSploit, or the Smartphone Pen-test Framework (SPF) could load agents or take rootkit-level control of devices as well. Rootkit/Rogue apps can be hidden (Hide It Pro via the Google Play Store) and even root itself can be hidden via an app such as Hide My Root.

An under-looked area of subversion comes from user-control of the filesystem contents by way of "tweaks" or custom user-modifications, such as removal of MDM/MCM or Exchange Server policies (e.g. the net.joedj.exchangepolicycleaner Cydia app via Jailbroken iOS).

Intercepting the Network

Classic network security will go into depth about how to intercept the network. Outside of normal HTTP/TLS/TCP network protocols, there isn't much to understanding or viewing the network protocol traffic. Instead, there is desire to intercept HTTP/TLS traffic because it is often the only packets leaving the stack.

Note: The Android emulator comes with strace and tcpdump, which can both be used very effectively (especially in combination with a timeline) when trying to understand network (and potentially even file) protocol handlers. An iOS Jailbroken Cydia install contains package sources for tcpdump and socat (a pluggable network proxy and packet generator/receiver). Many apps and other methods can be used to proxy Android or iOS, often best performed using a default-OS Emulator/Simulator proxy configuration or an app such as ProxyDroid. If an app is available in the Apple App Store or the Google Play Store and uses Internet connectivity, one could also use the Zscaler Application Profiler, which requires no Android/iOS app installs or configurations outside of certificate and proxy settings.

One often under-looked area of a mobile device's network stack components is location and device-identification data. iOS began with a UDID scheme, and Android has a similar one. Many mobile devices and their apps rely on their SIM id, MEID, or IMEI numbers as well. GPS co-ordinates can be inserted via the EXIF standard into images, and location data may be used in mobile apps. Note that any of these identifiers and location data can be spoofed and there are Android (FakeGPS, mveytsman's android_emulator_spoofing) and Cydia apps via Jailbroken iOS (LocSpoof, UDIDFaker).

Code Analysis

Code analysis comes in two main forms, Static Analysis and Dynamic Analysis. There are 3 distinct areas where code can occur in mobile devices and mobile apps: the kernel, the userland, and the Object-Oriented (OO) user-space.

  • Kernel - the kernel is malleable during testing only through a tool such as kgdb
  • Similar to the kernel, some code may be difficult to access in userland. For example, code that has been licensed (e.g. Android LVL's LicenseCheck) or signed (note that any Jailbroken iOS signing can be subverted with the Theos Linux-iOS SDK-clone ldid(1) utility). Additionally, code may be obfuscated (via the Android SDK's ProGuard) using self-modifying code and/or tamper-proofed (e.g. anti- process dumping) via self-checking code.
  • Userland - userland can be viewed or intercepted in many ways such as strace
  • An important area of analysis in mobile userland is the Android inter-application communication through the SDK Intent system. It can be analyzed and tested through the am(1) command-line utility, which is a front-end to the Android Activity Monitor, which rolls up into the AOSP CTS (Compatibility Test Suite). Building an Android via AOSP or CMC can also provide some desirable dynamic analysis capabilities (e.g. runtime EMMA).
  • In a similar way that one can dump the network and file protocol handlers in a Windows-based OS using ViewPlgs.exe, one can view these in Android using the Android WebContentResolver, a creation of MWR Labs (mwrinfosecurity), whom also released Mercury, the droid assessment framework (mercury-v2.0.0.zip as of 12/14/2012) - a powerful dynamic tool. iOS apps do not have a standard inter-app interface, but instead often utilize custom handlers. Standard log mechanisms (Android Log / iOS NSLog) also need to be checked for sensitive data.
  • OO user-space - Android can have runtime modified via andbug ; iOS via cycript
  • OO user-space is different than just a "VM". Many VMs can exist in modern mobile app development frameworks, from Mono to Lua. Without the AIR SDK or similar build infrastructure, it is difficult to analyze the VM code (e.g. ActionScript) vs. the ease of affecting the default (e.g. SpringBoard) OO runtime. In all cases, however, both would need to be analyzed for client-side-centric activities as well as to understand the execution and data flows.

Static Analysis

There are two primary ways static analysis will generally be performed on a mobile application: (1) analyzing source code obtained from development team (prefered) or (2) 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.

  • If the source is not directly available, decompile or disassemble the application’s binary
  • extract the application from the device
  • follow the appropriate steps for your platform’s application reverse engineering
  • some applications may require decryption prior to reverse engineering
  • Review the permissions the application requests as well as the resources that it is authorized to access (i.e. AndroidManifest.xml, iOS Entitlements)
  • Are there any easy to identify misconfigurations within the application found within the configuration files? Debugging flags set, world readable/writable permissions, etc.
  • What frameworks are in use? - Tim Brown
  • Identify the libraries in use including both platform provided as well as third party. Perform a quick review on the web to determine if these libraries:
  • Are up to date
  • Are free of known vulnerabilities
  • Expose functionality that requires elevated privileges (i.e. access to location or contact data)
  • Native code
  • Does the application check for rooted/jailbroken devices? How is this done? How can this be circumvented? Is it as easy as changing the case of a file name or name of executable or path?
  • Does it cope with being run from a rooted/jailbroken device?  Are the controls sufficient.
  • Determine what types of objects are implemented to create the various views within the application. This may significantly alter your test cases, as some views implement web browser functionality while others are native UI controls only.
  • Is all code expected to run within the platform’s standard runtime environment, or are some files/libraries dynamically loaded or called outside of that environment at runtime?
  • Attempt to match up every permission that the application requests with an actual concrete implementation of it within the application. Often, developers request more permission than they actually need. Identify if the same functionality could be enabled with lesser privileges.
  • Locate hard coded secrets within the application such as API keys, credentials, or proprietary business logic.
  • Identify every entry point for untrusted data entry and determine how it enforces access controls, validates and sanitizes inbound data, and passes the data off to other interpreters
  • From web service calls
  • Receiving data from other apps and on-device services
  • Permissions on them - Tim Brown
  • Inbound SMS messages
  • Reading information from the filesystem
  • Authentication
  • Locate the code which handles user authentication through the UI. Assess the possible methods of user impersonation via vectors such as parameter tampering, replay attacks, and brute force attacks.
  • Determine if the application utilizes information beyond username/password such as
  • Contextual information (i.e.- device identifiers, location)
  • Certificates
  • Tokens
  • Does the application utilize visual swipe or touch passwords vs. conventional usernames and passwords?
  • Assess the method of mapping the visual objects to an authentication string to determine if adequate entropy exists
  • Does the application implement functionality that permits inbound connections from other devices? (i.e.- Wi-Fi Direct, Android Beam, network services)
  • Does the application properly authenticate the remote user or peer prior to granting access to device resources?
  • How does the application handle excessive failed attempts at authentication?
  • are failed attempts logged?
  • what mechanisms exist to inform the user of a potential attack?
  • Single Sign On, e.g.
  • Facebook (OAuth 2.0)
  • Twitter (OAuth 2.0)
  • Google (OAuth 2.0)
  • etc.
  • SMS
  • How is the sender authenticated?
  • Password
  • Header information
  • Other mechanism?
  • Are one time passwords (OTP) used or is other sensitive account data transmitted via SMS?
  • Can other applications access this data?
  • Push Notifications
  • If the application consumes information via push notifications, how does the application verify the identity of the sender?
  • Authorization
  • Review file permissions for files created at runtime
  • Determine if it is possible to access functionality not intended for your role
  • Identify if the application has role specific functionality within the mobile application
  • Locate any potential flags or values that may be set on the client from any untrusted source that can be a point of privilege elevation such as
  • Databases
  • Flat files
  • HTTP responses
  • Find places within an application that were not anticipated being directly accessed without following the application’s intended workflow
  • Licensing
  • Can licensing checks be defeated locally to obtain access to paid-for data resources? (i.e.- patching a binary, modifying it at runtime, or by modifying a local configuration file)
  • Does the code suggest that licensed content is served with a non-licensed app but restricted by UI controls only?
  • Are licensing checks performed properly by the server or platform licensing services?
  • How does the application detect and respond to tampering?
  • Are alerts sent to and expected by the developer?
  • Does the application fail open or fail closed?
  • Does the application wipe its data?
  • Session Management
  • Ensure that sessions time out locally as well as server side
  • Is sensitive information utilized within the application flushed from memory upon session expiration?
  • Data Storage
  • Encryption
  • Are the algorithms used “best of breed” or do they contain known issues?
  • How are keys derived from i.e. a password?
  • Based on the algorithms and approaches used to encrypt data, do implementation issues exist that degrade the effectiveness of encryption?
  • How are keys managed and stored on the device? Can this reduce the complexity in breaking the encryption?
  • Identify if the application utilizes storage areas external to the “sandboxed” locations to store unencrypted data such as:
  • Places with limited access control granularity (SD card, tmp directories, etc.)
  • Directories that may end up in backups or other undesired locations (iTunes backup, external storage, etc.)
  • Cloud storage services such as Dropbox, Google Drive, or S3
  • Does the application write sensitive information to the file system at any point, such as:
  • Credentials
  • Username and/or password
  • API keys
  • Authentication tokens
  • Payment information
  • Patient data
  • Signature files
  • Is sensitive information written to data stores via platform exposed APIs such as contacts?
  • Information Disclosure
  • Logs
  • Does the application log data? Is sensitive information accessible?
  • How are the logs accessed, if so, and by which mechanism/functionality? Is log access protected?
  • Can any of the logged information be considered a privacy violation?
  • Is the device identifier sent that could be used to identify the user? (i.e. UDID in Apple devices)
  • Caches
  • Predictive text
  • Location information
  • Copy and paste
  • Application snapshot
  • Browser cache
  • Non-standard cache locations (i.e the various SQLite databases that apps can create if they use HTML UI components)
  • Exceptions
  • Does sensitive data leak in crash logs?
  • Third Party Libraries and APIs
  • What permissions do they require?
  • Do they access or transmit sensitive information?
  • Review licensing requirements for any potential violations.
  • Can their runtime behavior expose users to privacy issues and unauthorized tracking?
  • by the application
  • Web Application Issues
  • XSS and HTML Injection
  • Identify places where the application passes untrusted data into a web view or browser
  • Determine if the application properly output encodes or sanitizes the data within the appropriate context
  • Command Injection (if the application utilizes a shell)
  • Where the application permits usage of the shell, identify the entry points to manipulate or alter the commands via user input or external untrusted data
  • Determine if an attacker can inject arbitrary commands or manipulate the intended command in anyway
  • CSRF
  • SQL Injection
  • Cookies
  • Networking
  • Are insecure protocols used to send or receive sensitive information? Examples- FTP, SNMP v1, SSH v1
  • Are there any known issues with the specific libraries you are using to implement the protocol?
  • Transport Layer Protection (as applicable)
  • Does the application properly implement Certificate Pinning?
  • Are certificates validated to determine if:
  • The certificate has not expired
  • The certificate was issued by a valid certificate authority
  • The remote destination information matches the information within the certificate?
  • Are certificates validated only by the operating system or also by the application that relies on it?
  • Identify if code exist to alter the behavior for traffic transiting different interfaces (i.e.- 3G/4G comms vs. Wi-Fi)? If so, is encryption applied universally across each of them
  • Strings to search for in code
  • Create this empty page (link to it) to let people provide search terms regular expressions for searching through source code
  • All Plattforms
  • iOS
  • Android
  • Windows Phone
  • Blackberry
  • PlayBook? - Tim Brown
  • B2G (Boot to Gecko)
  • Backdoors and easter eggs?

Dynamic Analysis

Armed with data collected during the Information Gathering and Static Analysis phases, the tester can begin an informed vulnerability assessment of the mobile application client, server and associated services.

Dynamic analysis is conducted against the backend services and APIs and the type of tests varies depending on mobile application type.

Types of mobile applications:

  • Native Mobile Application: Native mobile applications can be installed on to the device. This type of applications generally store most of their code on the device. Any information required can be requested to the server using the HTTP/s protocol
  • Webservices for Mobile Application: Native mobile application that uses SOAP or REST based web services to communicate between client and Server
  • Mobile Browser Based Application: Web browser based applications can be accessed using device’s browsers such as Safari or Chrome. Most of the commercial applications are nowadays specifically designed and optimized for mobile browsers. These applications are no different than traditional web application and all the web application vulnerabilities apply to these apps and these should be tested as traditional web apps.
  • Mobile Hybrid Applications: Applications can leverage web browser functionality within native applications, blending the risks from both classes of applications.

In this phase, the mobile client, backend services, and host platform is analyzed/scanned in attempt to uncover potential risks, vulnerabilities and threats. The use of a local proxy tool (i.e. Burp, Mallory, OWASP ZAP) as well as automated vulnerability scanners are core to this phase. In many cases, you will also need some type of shell access to the device.

The following outline can be used as a “Dynamic Analysis” guide in planning a mobile assessment.

  • Generate File System Baseline Fingerprint (before app installation)
  • Application interactions with the host file system must be reviewed and analyzed at various stages of testing; starting with baseline capture. This may require a shell or GUI depending on platform and/or preference.
  • Install, Configure and Use the Application
  • Manually inspect the file system to determine what files/databases were created, what and how data is stored. Did the application store sensitive data unencrypted or trivially protected (i.e. encoded)?
  • Generally, pay attention to credentials, payment information, or other highly sensitive information being saved to the device. Also take a look at databases, log files, predictive text caches, and crash logs.
  • Debugging
  • Attach a debugger to an application to step through code execution and setting breakpoints at interesting code within the application
  • Monitor logged messages and notifications generated at runtime
  • Observe interprocess communications between the target application and other applications and services running on the mobile device.
  • Active Testing
  • Local Application Testing
  • Exposed IPC interfaces
  • Cryptography
  • brute force attacks against keys, pins, and hashes
  • attempt to reconstruct encrypted data through recovery of keys, hardcoded secrets, and any other information exposed by the application
  • Web Applications
  • XSS and HTML Injection
  • Is it possible to inject client side code (i.e. JavaScript) or HTML into the application to either modify the inner working of the application or it's user interface?
  • Command Injection (if the application utilizes a shell)
  • CSRF
  • SQL Injection
  • Cookies
  • Are cookies issued by a server secured by using the HTTP-only and Secure flag?
  • Is there any sensitive information stored in the cookies?
  • Authentication
  • Assess the methods an application uses to authenticate peers
  • NFC
  • SMS
  • Push notifications
  • Across IPC channels (identify the calling application’s privileges and identity)
  • Authorization
  • Instrument, patch, or interact with application at runtime to bypass methods intended to prevent usage of privileged or premium features
  • Determine if configuration or locally stored data can be manipulated in order to elevate a user’s privileges
  • Check the filesystem permissions for any files created at runtime
  • File System Analysis
  • Assess the application’s behavior throughout it’s lifecycle to determine if special functionality is triggered to persist an application’s state when it enters different stages:
  • Placed into the foreground
  • Sent into the background
  • Upon exiting the application
  • Utilize forensic tools to determine if deleted data can be recovered from the filesystem as well as within databases
  • Memory Analysis
  • Determine if sensitive information persists within memory after performing the following actions:
  • Logging out of the application
  • Transition between UI components
  • Is it possible to obtain encryption keys, credentials, payment information and other sensitive information by dumping device or application memory?
  • Analysis on the Device
  • Data  storage in Cache
  • Looking for artifacts left on device
  • Unencrypted data storage on the device
  • Encryption of data in backups
  • Username/password, or app-specific unique device id stored on the device
  •  Application Permissions , Privileges and Access controls on the device
  • Generally, pay attention to credentials, payment information, or other highly sensitive information being saved to the device. Also take a look at log files, predictive text caches, and crash logs.
  • Is sensitive information cached within the application’s UI back stack?

  • Remote Service Testing
  • Authentication
  • What methods are available (3G, 4G, Wifi, etc)?
  • What happens if the remote authentication service becomes unavailable?
  • Assess strength of password requirements
  • Test how account lockouts are implemented
  • Analyze (monitor traffic) how each method performs authentication. Note target wifi as this is a common area where authentication can be weak. Ensure authentication is robust and not based on trivial attributes (i.e. MDN, ESN, etc).
  • Verify that authentication tokens are terminated after a user initiates a password reset
  • Single Sign On (SSO)
  • SMS Based
  • One Time Passwords (OTP)
  • Two Factor Authentication
  • Push Notifications
  • Licensing
  • Authorization
  • What happens if the remote authorization handling service becomes unavailable?
  • Test if direct access to backend resources is possible
  • Access controls to server side resources not enforced
  • Vertical and horizontal privilege escalations
  • Session Management
  • Entropy analysis
  • Device identifier related?
  • Are session tokens refreshed between logouts?
  • Lifetime and expiration
  • Handling the session token on the device (stored, in memory, etc.)
  • Privilege Escalation
  • Cross User Attack
  • Session ID randomness
  • Session Hijacking
  • Ineffective Session Termination
  • Cross Site Request Forgery
  • Transport Layer Testing
  • Man-in-the-middle attacks
  • Eavesdropping
  • Securely transmit login data
  • Securely transmit sensitive data
  • SSL checks (cypher strengths/weakness etc.)
  • Server Side Injection
  • Application Exceptions
  • Cross-site  Scripting
  • SQL  Exploits
  • XML Bomb
  • Buffer overflow
  • Unrestricted File Upload
  • Open Redirect
  • Server Network & Application Scanning
  • Based on prior phases you should have 1 or more target servers (i.e. URLs) as candidates for automated vulnerability scanning. Mobile applications often leverage existing web services/applications (i.e. hybrid applications) which must be tested for security vulnerabilities.

Mobile applications are continuing to mature and evolve thus to be effective, security testers must strive to advance their knowledge and skills. Please check back periodically for updates and share your feedback with us.

//Here downwards is old material

<begin 5/12 edit don williams>

// I thought it would be good to start with the outline of the methodology and then dig deeper or we

// could start with more test data and follow up with methodology outline at end

// I went through your data and integrated into the structure below to marry up tasks

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.

Phase I: Information Gathering

Prior to performing active testing of the mobile application, it is valuable to spend time exploring and learning the application during normal operation. To be most effective in this phase, execute the application while running a proxy server in the background collecting information for analysis. Proxy logs contain a plethora of information about the application’s functionality and allow the tester a look “under the hood” in determining and building an effective test plan.

Additionally the tester should run the application in debug mode and review all debug logs for potential valuable information such as authentication credentials, target IP’s/URL’s, verbose errors and other valuable information.

[Information Gathering Methodology]

  • Manually navigate the running mobile application
  • Enable local proxy server to collect data
  • Attach to a debugger and observe the application's runtime behavior
  1. calls to IPC methods (important for android…broadcasts, explicit/implicit attempts)
  2. crash or exception data
  • Does the application allow commerce?
  1. does the application request, transmit and store credit card transactions? If so, note options.
  2. does the application make in-app payments? If so, note options.
  • Run the application in each authentication role available
  1. where > 1 role available, identify any role-specific functionality / access points for later analysis and privilege escalation testing.
  • Test and documented all available access methods
  1. 3G
  2. 4G
  3. WiFi
  4. etc
  • What types of wireless interfaces are used by the application?
  1. Bluetooth
  2. Wifi
  3. NFC
  4. etc

As a result of this initial information gathering exercise, the tester will be better prepared for the next phase. The sad truth is, testers often fail to take the time to learn the target application and supporting infrastructure, opting to dive in blind, possibly losing valuable time and or missing possible attack vectors. Without a solid understanding of how the application “should” work, the tester will not be able to identify when the application behaves in a manner that it “shouldn’t”

Phase II: Actively Test the Application & Services

Armed with data collected during the Information Gathering phase, the tester can begin an informed vulnerability assessment of the mobile application client, server and associated services.

Application security (pen) testing of mobile applications should include both static and dynamic analysis. The mobile client application can be extracted, decompiled & disassembled revealing source code. Since valuable source code is attainable, static analysis of client application is to be included in the overall assessment. In addition to client application testing, dynamic analysis will be conducted against the backend servers. The following outline can be used as a guide in planning a mobile assessment.

[Active Testing Methodology]

STATIC ANALYSIS

  • Analyse mobile client binary (*.apk, *.ipa, *.xap) and associated files
  1. Extract application from device
  2. Receive application source from development (where available)
  • Decompile/disassemble binary
  • Conduct manual source code review (
  1. Search code (grep, Agent Ransack, etc) for keywords
  2. Analyze service call endpoints and resources + parameters
  • identify the application's components
  • Map the inter process communication potential
  1. does the application utilize a file type that can be handled by other applications?
  2. does the application handle inbound calls from other apps (broadcasts or intent resolution on android, or url schemes on iOS)
  • What can we learn through other included resources?
  1. signature files
  2. other binaries (called via the primary app, via shell, JNI, etc)
  3. local html and javascript files
  • Identify any third party libraries in use
  1. are there known vulnerabilities?
  2. do they expose additional functionality (think of ad networks grabbing location + device identifier info)
  3. do they require licensing?
  • Are there any potential misconfigurations within the application? ie- debugging left enabled within a production application
  • What protocols are in use?
  1. do they require encryption
  2. any known issues with those protocols?
  • ie- ssh v1, older versions of snmp, etc
  • Review permissions the application requests/uses. (i.e. for Android extract/review the manifest or plist files for iOS)
  1. access to contacts
  2. world readable/writable files
  3. sending SMS
  4. phone calls
  5. location data
  6. etc
  • Automated source code review
  1. Run code through automated source code scanners 

DYNAMIC ANALYSIS

  • Attach to a debugger and observe the application's runtime behavior (revisit)
  • Analyze network traffic
  • Trap and modify traffic via proxy (modify certificate store as needed to proxy HTTPS traffic)
  1. Test for injection attacks (XSS, XSRF, SQLi, etc)
  2. Analyze remote services (HTTP/SOAP/etc)
  3. authentication - identify/analyze how the application behaves during the following events:
  1. login
  2. registration
  3. forgot password
  4. password reset
  5. logout
  6. How and when are cookies set?
  7. Do cookies contain sensitive data?
  8. Are secure protocols used?
  9. Analyze how is 3G/4G/WiFi authentication performed? Are robust authentication controls in place (i.e. AAA) or is the application passing trivial data which can be easily manipulated?
  1. session management and authorization - Are session identifiers of adequate complexity/entropy? How does the application process differing role based access?
  2. application parameters (including any header & hidden parameters) - what parameters are exchanged any look interesting such role=admin or price=100.00.
  • Where there is > 1 role, test role based access
  1. conduct horizontal privilege escalation testing (can you view someone else's data?)
  2. conduct vertical privilege escalation testing (can you access/execute privileged functionality?)
  • Review device file system / storage (review data before and after execution of application)
  1. identify if it uses an external storage provider (sd card, etc)
  2. what types of files does the app create? Check before and after application use. After logout review all files for sensitive data.
  • sqlite databases
  • flat text files
  • xml files
  1. Determine what those files are used for and what triggers their creation. Can the information collected be used to replay actions possibly as another user?
  2. Do any of the files contain sensitive information? Be sure to check the filesystem after ‘logout’ or exiting the application. The application should not persistently store any sensitive information.
  • PII
  • credentials, session information
  • payment information
  1. Permissions and access controls
  2. Does the app use a global logging mechanism?
  3. Does the app cache information in unexpected ways improperly protecting against platform specific issues (ie- iOS backgrounding snapping a .jpg)
  • Perform content or resource enumeration of remote services
  • Fuzz interprocess communication interfaces between applications
  • Scan remote servers for vulnerabilities (Nikto, Skipfish, Burp Pro ‘Active Mode’, etc)

Mobile applications are continuing to mature and evolve thus to be effective, security testers must strive to advance their knowledge and skills. Please check back periodically for updates and share your feedback with us.

// Jack make changes as needed and we need some sort of closing paragraph.

</end 5/12 edit don williams>

//

// Historical data follows

//

Information Gathering

Kept it at a high level for the first pass. Left a few things out, but trying to determine what makes the methodology too specific vs. broad enough to cover <mobile>. Like, we have our own internal checklists and “what to do” lists for what to test on Android vs. iOS, but they vary between the platforms. Anyways, here is the first crack at something that fits generically across the board.

Dynamic Test

Things to do

info gathering

  • identify the SDK the application was built with. are there any known security issues or notable issues to be concerned with?
  • security features implemented in later versions?
  • issues that have a higher tendency of occurring as a result
  • manually navigate the running application while attached to a proxy. Identify where various interactions occur
  • authentication
  • CRUD operations
  • reverse engineer and explore the binary and associated files
  • likely not concerned with line-by-line review at this point
  • what can we learn via configuration files?
  • what can we learn through other included resources?
  • signature files
  • other binaries (called via the primary app, via shell, JNI, etc)
  • local html and javascript files
  • extract service call endpoints and resources + parameters
  • identify the application's components
  • map the inter process communication potential
  • does the application utilize a file type that can be handled by other applications?
  • does the application handle inbound calls from other apps (broadcasts or intent resolution on android, or url schemes on iOS)
  • explore the app's file storage locations
  • identify if it uses an external storage provider (sd card, etc)
  • what types of files does the app create?
  • sqlite databases
  • flat text files
  • xml files
  • Determine what those files are used for…potential for client side control of <something>?
  • Do any of the files contain sensitive information?
  • PII
  • credentials
  • payment information
  • Permissions and access controls
  • Does the app use a global logging mechanism?
  • Does the app cache information in unexpected ways improperly protecting against platform specific issues (ie- iOS backgrounding snapping a .jpg)
  • What sensitive APIs does the application use?
  • location?
  • reading/writing to contacts
  • sending SMS
  • Phone calls
  • etc.
  • Are there multiple roles available?
  • if so, must identify if there is any role-specific functionality as there may be authZ + priv esc issues
  • What protocols are in use?
  • do they require encryption
  • any known issues with those protocols?
  • ie- ssh v1, older versions of snmp, etc
  • Perform content or resource enumeration of remote services
  • Assess the configuration (storage)
  • are any modules or software packages available that may impact security levels?
  • what protocol-specific things are available that have the potential for abuse?
  • ie- HTTP PUT + WebDav
  • Identify third party libraries in use
  • are there known vulnerabilities?
  • do they expose additional functionality (think of ad networks grabbing location + device identifier info)
  • Are there any potential misconfigurations within the application? ie- debugging left enabled within a production application
  • Attach to a debugger and observe the application's runtime behavior
  • calls to IPC methods (important for android…broadcasts, explicit/implicit attempts)
  • crash or exception data
  • Out of band comms
  • SMS
  • phone calls
  • email
  • Does the application require licensing?
  • Can the application make in-app payments?
  • What types of wireless interfaces are used by the application?
  • Bluetooth?
  • Wifi
  • NFC

//Previous Notes and stuff

For Mobile Security Testers (tab)

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 create a generic testing methodology for any platform. The below outline describes a general mobile application testing methodology.


Phase I: Identify Attack Surface

Prior to performing any active testing/attacking of the mobile application, it is valuable to spend time up front in exploring and monitoring the application use. First and foremost execute the application while running a proxy server in the background collecting requests and responses for analysis. Proxy logs contain a plethora of information about the application’s behavior and allow the tester a look “under the hood” in determining and building the attack surface.

Key proxy flows to analyze for possible risks/attack use cases include:

  • authentication flows - how does the application behave during the following events: login, registration, forgot password and password reset, logout? How and when are cookies set? Do cookies contain sensitive data? Are secure protocols used? How is 3G/4G/WiFi authentication performed.
  • authorization flows - Are session identifiers of adequate complexity/entropy? How does the application process differing role based access?
  • application parameters (including any header & hidden parameters) - what parameters are exchanged any look interesting such role=admin or price=100.00? 

After analysing the application functionality and associated technology, the tester will be better prepared for the next phase. The sad truth is testers often fail to take the time to learn the target application and supporting infrastructure opting to blindly attack first possibly missing valuable time saving attack vectors.

Examine file system and common cache/temp storage locations:

  • databases
  • flat files
  • system logs

Phase II: Actively Test the Application & Services

Now that the tester has learned the application’s behavior and identified possible attack  vectors, the tester can begin an informed vulnerability assessment of the mobile application client, server and associated services.

Application security (pen) testing of mobile applications includes static and dynamic analysis. The mobile client application can be extracted, decompiled & disassembled revealing source code. Since valuable source code is attainable, static analysis of client application is to be included in the overall assessment. In addition to client application testing, dynamic analysis will be conducted against the backend servers. The following outline can be used as a guide in planning a mobile assessment.

Static Analysis

a)      GetApplication Package (*.apk, *.ipa, *.xap)

1.       Extract application from device

2.       Receive application package from developers

b)      Decompile/ Disassembly

c)       Manual Source Code Review

1.       Search for keywords (grep, Agent Ransack, etc)

d)      Automated Source Code Review

Dynamic Analysis

a)      Debug the running app (on device or in emulator)

b)      Analyze network traffic

c)      Analyze remote services (HTTP/SOAP/etc)

d)      Review device file system (review data before and after execution of application)

e)      Inspect/modify traffic via proxy (modify certificate store to proxy HTTPS traffic)

f)       Scan remote servers for vulnerabilities (Nikto, Skipfish, Burp Pro ‘Active Mode’)

h)      Fuzz interprocess communication interfaces between applications

??

Testing Tools

Network Traffic Analysis

  • Burp – industry leading proxy available at no cost and Burp Pro at cost.
  • Mallory - Mallory is an open source transparent tcp/udp proxy that allows a tester to step through network traffic bytes at a time. Mallory is designed to function as a network gateway, thus facilitating the testing of embedded devices and applications that cannot easily be proxified.

Disassembly | Decompilation Tools & Resources

Disassembling applications provides a wealth of information for a security researcher. Platform differences lead to different toolsets for investigation of application internals.

Android

  • apktool: it can decode resources to nearly original form and rebuild them after making some modifications
  • smali/basksmali - smali and baksmali are an assembler/disassembler pair that can be used to analyze the Dalvik byte code of an Android application.
  • Dex2jar – converts compact Dalvik executable (.dex) format to java class files /Java bytecode
  • JD-GUI – decompiles Java bytecode to readable source code. Note the decompiled version will be close to original yet not exact.
  • Agent Randsack – Windows based search tools ideal for manual source code analysis.
  • Reversing Android Apps 101 - Blog post describing the process of disassembling / reversing Android applications

iOS

The approach is somewhat different (in comparison to others platforms) when carrying out dynamic and static analysis on iOS applications. One approach is to become a registered Apple Developer to gain access to the goodness that is Xcode, Simulator, etc. and the other is jail breaking your phone. We will look at this from the perspective of being a registered Apple Developer for and using Apple's Simulator for now. You will need to be running a recent version of Snow Leopard to carry out testing using this route.

  • Charles Proxy - transparent proxy tool even with cert support.
  • oTool - Use to disassemble and inspect iOS application binaries. Mach-O Object file reader.
  • Class-Dump-Z – read/view class declarations and structs
  • Clang analyzer - static analysis for C, C++, and Objective-C source code
  • Instruments - the sysinternals for Mac OS X
  • Shark - analyze assembly level operations
  • Mallory - to perform MiTM on iOS applications
  • IDA Pro - Commercial disassembler and debugger.
  • Hex Rays Decompiler - IDA Pro plug-in for decompilation of ARM assembly

 

Windows Phone 7/8

  • Content to follow

RIM

  • Content to follow

Historical Change Log

<2/3/2013 Update: Don Williams>

Please let us know of any corrections while we let this new content soak in with the community and *** special thanks to all that provided feedback along the way ***

Next we would like your assistance in creating platform specific (Android, iOS, WP8, RIM, etc) testing methodologies and looking for volunteers.

<1/18/2013 Update: Jack Mannino>

FINALLY starting to put these updates on the wiki. Omitting the tool-specific stuff, as that probably dilutes the goal of this doc, which is to provide a methodology, not specifics on tools...that was in another doc that never made its way onto the wiki>

<11/18 Update: Don Williams>

Added Prerequisites/Planning section. I would like to get the revise content posted, thus if you make any changes please limit them to grammatical or error corrections until we get this revised content to the masses.

<10/10 Update: Andre Gironda (dre g)>

Added more sections (Info Gather, Compute Analysis, Code Analysis) and split Static/Dynamic to Code Analysis section, leaving forensics in Compute Analysis. Implanted names of tools and current attack-infrastructure for/against mobile devices.

<10/7 Update: Don Williams>

Marked up to support release of Dynamic section to the OWASP production web site. Jack and I spoke and we are planning on releasing as documented herein. We discussed the addition of forensics section yet many of the suggested items are integrated within the flow. We value everyone’s suggestions along the way and if you would like to make a recommendation please edit this document and as the text as you suggest it would appear in publication.

I will need to print this out and read it if any of you can assist in proofing the document we would like to add the revised content.

Jack we will need to make updates to the Intro, Static and Dynamic sections as per markup below.

<9/15 Update: Tim Brown>

Going through our internal docs and updating as appropriate, same as before.  In general, the data is good, but still needs cleaning up structurally

<8/18 Update: Don Williams>

@ request of k0rde.hairnet@gmail.com added mario.ledo.hernansanz@gmail.com ability to view the document. Thanks to all who have made suggestions/updates. If you have a suggestion please draft it inline as you feel it best fits the content as Tim did and he highlighted his additions which makes it easier to track. Remember we want to release quality content and may need to revisit suggestions at future date. Lets try to complete what we have in motion here before making any significant changes.

<7/24 Update: Tim Brown> Added some things that stood out in my mind as missing - I will need to cross-compare against our own stuff for a more detailed review.  Key points: I’d break out static analysis and code review as separate areas; I’d also have a more general device assessment section incorporating some of the forensics stuff (plus some other stuff) as we’re seeing people shipping mobile devices as sealed access to a business function and in that context you need to evaluate more than just “an app”.  Other than that, comments in the margin and things I think were missed tagged “- Tim Brown”.

<7/23 Update: Sameer Dixit> Added few things under the dynamic analysis section my additions are highlighted in grey.

<7/7 Update: Don Williams> made quite a bit of changes and additions throughout with a goal of preserving the methodology and flow. I believe the flow should be altered to swap dynamic and static analysis as many times dyn anal is a prerequisite to eff dyn anal as backend servers / targets are discovered in this phase. I made the switch for us to see to revised flow. Also I integrated the Forensics phase into the dynamic phase.

It is suggested we rename the existing tab / page https://www.owasp.org/index.php/OWASP_Mobile_Security_Project from “For Security Testers” to “Mobile Security Testing Guide”

</ 7/7 Update: Don Williams>

7/4 Update- We plan to work through this one section at a time, building the overarching framework that’s relevant across all platforms. Once we’ve hit the major areas, we will fork it for each major platform where contributors can continue to add new stuff as well as tie it into secure development references and cross reference other documents such as our tools/tutorials.

<7/14 Update: Jack> Added some content and broke the dynamic testing section into tests to be performed on the mobile device and and tests to be performed against server side resources.

>7/16 Update- Jack> Added the first few sections to the wiki. Still need to add missing pieces, though.

Section

Wiki Released?

Date of Initial Release

Date of Last Wiki Release

Introduction

YES

7/16/2012

7/16/2012

How To Use This Guide

YES

7/16/2012

7/16/2012

Information Gathering

YES

7/16/2012

7/16/2012

Static Analysis

YES

7/16/2012

7/16/2012

Dynamic Analysis

NO

>7/16 Don Williams - changed permission to Anyone with the Link