2013-05-22T14:49:41Z

Jack Mannino:

== iMas ==

iMAS is a collaborative research project from the MITRE Corporation focused on open source iOS security controls. Today, iOS meets the enterprise security needs of customers, however many security experts cite critical vulnerabilities and have demonstrated exploits, which pushes enterprises to augment iOS deployments with commercial solutions. The iMAS intent is to protect iOS applications and data beyond the Apple provided security model and reduce the adversary’s ability and efficiency to perform recon, exploitation, control and execution on iOS mobile applications. iMAS will transform the effectiveness of the existing iOS security model across major vulnerability areas including the System Passcode, jailbreak, debugger / run-time, flash storage, and the system keychain. Research outcomes include an open source secure application framework, including an application container, developer and validation tools/techniques.

[https://www.owasp.org/index.php/OWASP_iMAS_iOS_Mobile_Application_Security_Project iMas Project Page]

The source code for iMAS is available on GitHub: [https://github.com/project-imas/about iMAS Source Code]

== GoatDroid ==

The OWASP GoatDroid Project is a fully functional and self-contained environment for learning about Android security.

GoatDroid requires minimal dependencies, and is ideal for both Android beginners as well as more advanced users. The project currently includes two applications: FourGoats, a location based social network, and Herd Financial, a mobile banking application.

You can find GoatDroid on GitHub: [https://github.com/jackMannino/OWASP-GoatDroid-Project GoatDroid Source Code]

[https://www.owasp.org/index.php/Projects/OWASP_GoatDroid_Project GoatDroid Project Page]

== iGoat ==

iGoat is a learning tool for iOS developers (iPhone, iPad, etc.). It was inspired by the WebGoat project, and has a similar conceptual flow to it.

As such, iGoat is a safe environment where iOS developers can learn about the major security pitfalls they face as well as how to avoid them. It is made up of a series of lessons that each teach a single (but vital) security lesson.

The lessons are laid out in the following steps:

# Brief introduction to the problem.
# Verify the problem by exploiting it.
# Brief description of available remediations to the problem.
# Fix the problem by correcting and rebuilding the iGoat program.

Step 4 is optional, but highly recommended for all iOS developers. Assistance is available within iGoat if you don't know how to fix a specific problem.

iGoat is free software, released under the GPLv3 license.

[https://www.owasp.org/index.php/OWASP_iGoat_Project iGoat Project Page]

The iGoat source code is available on Google Code [http://code.google.com/p/owasp-igoat/ iGoat Source Code]

== MobiSec ==

The MobiSec Live Environment Mobile Testing Framework project is a live environment for testing mobile environments, including devices, applications, and supporting infrastructure. The purpose is to provide attackers and defenders the ability to test their mobile environments to identify design weaknesses and vulnerabilities. The MobiSec Live Environment provides a single environment for testers to leverage the best of all available open source mobile testing tools, as well as the ability to install additional tools and platforms, that will aid the penetration tester through the testing process as the environment is structured and organized based on an industry‐proven testing framework. Using a live environment provides penetration testers the ability to boot the MobiSec Live Environment on any Intel-based system from a DVD or USB flash drive, or run the test environment within a virtual machine.

[https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_MobiSec Project Page]

MobiSec can be downloaded from Sourceforge: [http://sourceforge.net/p/mobisec/wiki/Home/ MobiSec Download Repository]

Projects/OWASP Mobile Security Project - Mobile Tools

2013-05-22T14:47:27Z

Jack Mannino:

Projects/OWASP Mobile Security Project - Mobile Tools

2013-05-22T14:44:58Z

Jack Mannino:

OWASP Mobile Security Project

2013-05-22T14:40:13Z

Jack Mannino:

=Project Overview=

The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation. 

We have a Google Doc up where anyone that wants to be involved with the project can add their thoughts, suggestions, and take ownership of initiatives. [https://docs.google.com/document/d/1bScrvrLJLOHcSbztjBxYoN-jN3kR8bViy9tF8Nx0c08/edit https://docs.google.com/document/d/1bScrvrLJLOHcSbztjBxYoN-jN3kR8bViy9tF8Nx0c08/edit]. There are various tasks that people have started over the past 6 months with varying levels of quality and completeness.

{{:Projects/OWASP Mobile Security Project | Project About}}

 

= Top Ten Mobile Risks =

{{:Projects/OWASP Mobile Security Project - Top Ten Mobile Risks | Top Ten Mobile Risks}}

= Mobile Tools =

{{:Projects/OWASP_Mobile_Security_Project_-_Mobile_Tools}}

= Mobile Security Testing =

{{:Projects/OWASP Mobile Security Project - Security Testing | Mobile Security Testing}}

= Mobile Cheat Sheet Series =

{{:Projects/OWASP Mobile Security Project - Mobile Cheat Sheets Series | Mobile Cheat Sheet Series}}

= Secure Mobile Development =

{{:Projects/OWASP Mobile Security Project - Secure Development Guidelines | Secure Development Guidelines}}

= Top Ten Mobile Controls =

{{:Projects/OWASP Mobile Security Project - Top Ten Mobile Controls | Top Ten Mobile Controls And Design Principles}}

= OWASP Mobile Threat Model Project =

{{:Projects/OWASP Mobile Security Project - Mobile Threat Model | Project About}}

__NOTOC__
<headertabs />

[[Category:OWASP_Project|Mobile Security Project]] [[Category:OWASP_Document]] [[Category:OWASP_Alpha_Quality_Document|OWASP Alpha Quality Document]]

2013-01-18T16:27:36Z

Jack Mannino:

== 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 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, 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.

'''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.'''

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 by registering for a wiki account and contributing content: [https://www.owasp.org/index.php/Special:RequestAccount Wiki Registration]
*bring this up as a topic on the Mobile Project’s mailing list: [https://lists.owasp.org/mailman/listinfo/owasp-mobile-security-project Mobile Mailing List]

Collaboration on building the guide is being performed within Google Docs. You can find the latest and greatest material here: [https://docs.google.com/document/m/?id=1N7zMXlFHtWfc00xa6lRHnVB60U4BZO4SbUrWYMbojVM&pli=1&login=1 Testing Guide Google Doc]

== 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
**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

== Static Analysis ==

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.

=== Getting Started ===
*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 also require decryption prior to reverse engineering (note: decryption and code obfuscation are not the same thing)

*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? Is the application built using a cross-platform framework?

*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 vulnerabilities
**expose functionality that requires elevated privileges (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?

*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
**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.
**OAuth
**Facebook
**Google Apps

*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?

=== 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 any way
*CSRF
*SQL Injection
*Cookies
*HTML5

=== 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 ===
*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

=== Helpful Search Strings and Regular Expressions ===
-To do

== 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.

*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 an intercepting proxy tool 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.

Projects/OWASP Mobile Security Project - Security Testing

2013-01-18T16:24:17Z

Jack Mannino:

Projects/OWASP Mobile Security Project - Security Testing

2013-01-18T16:12:36Z

Jack Mannino:

Projects/OWASP Mobile Security Project - Security Testing

2013-01-18T15:55:17Z

Jack Mannino: