Mobile App Pen Testing - 4

In this post I'll walk you through IOS application security issues. 

iOS Application Security Issues

1. Privacy Issue
• Every iPhone has a unique device identifier called UDID. Mobile Apps may collect the device UDID. With the help of UDID it is possible to observer the user browsing patterns. And also it’s become feasible to locate user’s GEO location with UDID. UDID can be finding out by observation of the network traffic transmission. 
• One such application is
• Openfient: mobile social gaming network: http://corte.si/posts/security/openfeint-udid-deanonymization/
2. Application Data Storage
• Applications that are installed on mobile devices will use phone memory to store the data. 76 percent of mobile Apps store user data on phone. And 10 percent Apps store passwords in clear text. Source: viaforensics.com/appwatchdog
• Applications store information on phone for mainly two purposes. One is application performance will be improved and second is user can still access some data while he/she is offline.
• Application mainly store data on the below locations 
• Plist files
• Keychain
• Logs
• Screenshots
• Home directory
• Application run in sandbox (seatbelt) with ‘mobile’ privileges Each application gets a private area of the file system Example App Home directory: /var/mobile/Applications/[GUID]

  Sub Directory	Description
  Appname.app	Contains the application code and static data
  Documents	Data that may be shared with desktop through iTuens
  Library	Application support files
  Library/Preferences/	App specific preferences
  Library/Caches/	Data that should persist across successive launches of the application but not needed to be backed up.
  Tmp	Temporary files that do not need to persist across successive launches of the application.

• Plist files
• Plist files known as Property list files which is primarily used to store user’s properties of an application. Example: /var/mobile/Applications/[appid]/Documents/Preferences
•  Key value pairs are stored in binary format and can be easily extracted and modified with property list editor, plutil.
• During pen testing look for usernames, passwords, cookies. As Apps may take Authentication/Autherization decisions Example: admin=1, timeout=10
• It is recommended do not store clear text data in plist files.

Mobile App Pen Testing - 3

Now, Let's start with real penetration testing techniques in this post.

Penetration Testing

1. Client Application
• A client software package is installed locally on the mobile device which acts as the front-end for the user. Client application can be downloaded from app store or Google market. To perform penetration testing on the application we require rooted device or jailbroken or emulator. While performing testing we have to pay more attention to check presence of controls for vulnerabilities like 
• Files (temporary, cached, configuration, databases, etc.) on the local file system.
• Insecure file permissions.
• Application authentication & authorization.
• Error handling & session management.
• Business logic testing.
• Decompiling, analysing and modifying the installation package.
• Client-side injections.
2. Tools Requirement:
• Mobile device / Mobile device emulator
• It’s always better to use the original (jailbroken) mobile device for performing penetration testing activities. But in the case of unavailability we can also use Emulator as an alternative.
• Examples of popular mobile client systems are Google Android Emulator, MobiOne, iPhoney, and the Blackberry Simulator.
• Decompiler
• Get an appropriate decompiler in order to decompile the binary application files. During black-box engagements, decompilation is essential in order to have a good understanding of how the application internals work.
• Example decompilers for mobile applications are Reflector.NET (Windows Mobile), otool and class-dump-x (iPhone), dex2jar and JD-Gui (Android), Coddec (Blackberry).
• Code analysis tools
• Once the application code has been successfully decompiled, we can consider using a code analysis tool in order to identify vulnerabilities in the application source code.
• Examples of such tools are Klocwork Solo, Flawfinder, Clang.

Mobile App Pen Testing - 2

Types of Mobile Applications

1. Browser Based Application
• It is always better to use emulator for such applications from a testing point of view as application may not behave in a Windows/Linus/Any-Other-OS as it may in emulator. One example: Application server may render the response based on the User-Agent.
• This application uses JavaScript, CSS and HTML – 5 technologies.
• Browser based application is prone to threats like SQL injection, Cross Site Scripting, Authentication checks, Parameter tempering, Authorization checks, Transport layer security.
2. Native Applications
• These are the .apk(Android),.ipa(iOS), .app(Windows) files, a variant of JAR file, containing all the necessary components coded to perform the desired actions. There are a large group of developers who write such applications, which includes third party applications as well to enhance the feature and the functionality of the various devices. These applications can either be downloaded /installed through Google Play, Appstore, or through the third party sites.

• These applications are developed using Objective-C and Cocoa touch API for iOS, and Java for Android.
• Security issues related to native applications are further discussed in the penetration section.

Mobile App Pen Testing - 1

Introduction

The mobile application security market has seen a massive boom in the last couple of years owing to the availability of affordable smart phones from a variety of vendors and the advent of Bring Your Own Device (BYOD) into work. The usage of these applications has provided users with easy and active access to manage financial transactions, online procurement of various types of goods, access to entertainment and ability to stay connected online. It has helped businesses to increase productivity and flexibility for users. This in turn has made mobile applications vulnerable to hostile online threats from hackers which lead to loss of personal and professional information related to their financials, credit card details, personally identifiable information (PII), email addresses, passwords and making them victims of ever-growing cyber criminals. Thus mobile applications need to be continuously scanned and tested for security risks and exposures.

Improvements in hardware and software have enabled more complex tasks to be performed on mobile devices; this functionality has also increased the attractiveness of the platform as a target for attackers. Android’s “open application” model has captured multiple instances of malicious applications with hidden functionality that secretly harvests user data.

Many organizations are concerned about data integrity, and increased regulation and data protection requirements have placed further obligations on organizations to properly secure data that interacts with mobile devices. As a result, higher levels of security and data protection assurance are required.

Mobile penetration tests are unlike traditional penetration tests in many ways. In a traditional penetration test, there is a significant platform variance between operating systems, patch levels and hardware-specific drivers, balanced by a relatively common platform CPU (Intel or Intel-compatible). While application sandboxing is used in some traditional platform, it is relatively uncommon while being a primary security mechanism used in mobile devices.

Mobile devices fall into a category of device classified as an embedded device, representing systems with a finite amount of storage and memory running on a non-extensible hardware platform with a CPU that deviates from the common Intel platforms. While mobile systems have been expanding in terms of RAM and persistent storage, these devices generally lack the capabilities of traditional platform systems. With this variation, we need to adjust our attack technique accordingly.

For Example, traditional exploit tool such as Metasploit does not work against mobile devices such as the iPad unless specifically written to do so. Further, while some mobile devices exhibit vulnerable behavior in the retrieval of system updates typically exploited with tools such as Evilgrade, it is not possible to deliver a malicious executable to a Windows Phone since they do not typically run unsigned software.

Despite this platform disparity, we can re-use core competencies like performing threat modeling, risk analysis, bug tracking, and report preparation in web application security and same is applied in the analysis and evolution of vulnerabilities against mobile device effectively. The implementation and delivery of attacks to mobile devices changes but the process remain constant.

There are several entry points like Wi-Fi, applications, Bluetooth, flash memory etc. by which device can get affected or attacker can intrude into it.