Security Testing of Mobile Applications(Android - BlackBerry - iOS)

Introduction to Android Security & AppUse

Mobile application threat model - What makes mobile application security so different?• The Android linux OS security• The Dalvik VM• The Android security mechanisms• Application file system isolation• The permission model• Least privilege model• Database isolation• The Android emulator VS. physical device• The AppUse VM ("Android Pen-test Platform Unified Standalone Environment") • The Android Debug Bridge (ADB)• The logcat interface

Traffic Analysis and Manipulation • Intro to server side attacks - SQL injection, XSS• Insecure remote Authentication - client id, IMEI, etc.• Insecure session management• authorization• Traffic interception• Using proxies and sniffers• Importing SSL certificates & trusted CA's• Sensitive information transmission• Bypassing server certificate validations• Exposing insecure traffic

Insecure data K11storage• Exploring deployed application files at the /data/data directory• The file system security model• Insecure file system permissions• Insecure storage of sensitive data in files• The SDcard • The SQLite Database storage• Using sqlite browser• Application shared preferences storage• Storage of sensitive data at the server side• Secrets in code• Insecure log exposure• Bad cryptography

Reverse engineering the application binaries • The APK file package• APK extraction - Investigating layout, manifest, permissions and binaries• Extracting the content of the classes.dex file• Using smali/baksmali Dalvik assembler/disassembler• Using jasmin/jasper JVM assembler/disassembler• Decompilation • Using dex2jar• Identifying interesting API calls - file access, networking, SDcard access, SQLite, etc• Identifying insecure code - certificate validation bypass, insecure xml parsing, clipboard access, geo-location, address book, client xss and html injection, etc.• Finding hard coded secrets in code• Using Android Lint• Code patching and modification• Recreating and resigning the modified APK

Android application components security• Major component types - Activity, Service, Content provider, Broadcast receiver• The Intent message• Components and the manifest file• Using manifest explorer • Component permissions and visibility• Activating components• Accessing restricted screens• Attacking content providers and client side sql injection• Direct component invocation by unauthorized apps

Analyzing Runtime Analysis• Monitoring process activity• Observing file access• Monitoring network connectivity• Debugging• Setting breakpoints• Memory dumping and analysis• Analyzing logs using logcat

Android Platform Security Architecture

Android seeks to be the most secure and usable operating system for mobile platforms by re-purposing traditional operating system security controls to:· Protect user data· ( ) Protect system resources including the network· Provide application isolation

, :To achieve these objectives Android provides these key security features· Robust security at the OS level through the Linux kernel· Mandatory application sandbox for all applications· Secure interprocess communication· Application signing· - - Application defined and user granted permissions

. The sections below describe these and other security features of the Android platform 1Figure . . , .summarizes the security components and considerations of the various levels of the Android software stack Each component assumes that the components below are properly secured With the exception of a small amount of Android OS code running as root all code above the Linux Kernel is restricted by the Application Sandbox

New Android's Feature will Regularly Scan Your Apps

Recently Google has officially announced to increase the security of Android users by adding a new feature to android which will regularly scan all the apps installed on the device to protect you from harmful malwares and viruses as said in an official blog by Rich Cannings.

The new feature by Google would be a part of Verify Apps feature which is already protecting android users from harmful apps installed by third party store. Verify Apps feature was used 4 billion times last year and had protected almost every android user around the world but 0.18% users still installed app which Verify Apps feature warned not to install as that were harmful , this means the Android users are still being targeted.

The feature will scan for spywares , malwares , sending unauthorized messages and in-app installations for changes in app activity after it is installed.

The first comprehensive guide to discovering and preventing attacks on the Android OS As the Android operating system continues to increase its share of the smartphone market, smartphone hacking remains a growing threat. Written by experts who rank among the world's foremost Android security researchers, this book presents vulnerability discovery, analysis, and exploitation tools for the good guys. Following a detailed explanation of how the Android OS works and its overall security architecture, the authors examine how vulnerabilities can be discovered and exploits developed for various system components, preparing you to defend against them. If you are a mobile device administrator, security researcher, Android app developer, or consultant responsible for evaluating Android security, you will find this guide is essential to your toolbox. A crack team of leading Android security researchers explain Android security risks, security design and architecture, rooting, fuzz testing, and vulnerability analysis Covers Android application building blocks and security as well as debugging and auditing Android apps Prepares mobile device administrators, security researchers, Android app developers, and security consultants to defend Android systems against attack Android Hacker's Handbook is the first comprehensive resource for IT professionals charged with smartphone security.

IT Policy:-Primary policy for all protection mechanisms Access to Network/Resources/Settings Prohibited and Mandatory installations of apps Controlling third-party Java application permissions-Per-Handset + Global Policy stored on BES-Initial Policy is signed by master key at pairing Stored in NV RAM Future updates OTA must be signed by master key

Application Controls:- All applications run in the JVM- IT Policy controls how the applications interact-Developed with the user and company in mind Most restrictive overlap- I9 application control policy categories Cross Application Control-Hardware-Network domnains-PIM data/ applications-Inter-application communication-Browser-User Autherntication and Settings-Input Simulation-MDS

Code signing- Core BB applications must be RIM Signed- Class files verified for interface compliance- No user-defined class loaders-No Java Native Interface or user extensions-System classes cannot be overridden

Data Security-Java RMS offers various forms of crypto-Keys must be explicitly shared by apps-PIM protected by Blackberry Attachment Service Renders and decrypts data on the BES Sends rasterized information to display Avoids image exploits Manages PGP on BES

The iOS Security Model

Apple has incorporated four layers of security in iOS to protect the user and their data.

Device SecurityTechniques to prevent an unauthorized individual from using the deviceData SecurityTechniques to protect the data stored on the device, even if the device is stolenNetwork SecurityTools to encrypt data while it is in transit across a networkApplication SecurityMechanisms to secure the operating system and isolate applications while they are running

Information gathering Observe application behavior Determine the application’s data states (at rest, in transit or on display) and sensitivity Identify access methods Identify what frameworks are in use Identify server side APIs that are in use Identify what protocols are in use Identify other applications or services with which the application interacts Decrypt Appstore binaries: the .ipa will be decrypted at runtime by the kernel’s mach loader. Cydia has several applications available: Crackulous, AppCrack and Clutch. Also, you can use GDB. The “cryptid” field of the LC_ENCRYPTION_INFO identifies if the application is encrypted or not. Use otool –l <app name> | grep –A 4 LC_ENCRYPTION_INFO Determine the architecture the application was compiled for: otool –f <app name> or lipo -info <app>. Get information about what functions, classes and methods are referenced in the application and in the dynamically loaded libraries. Use nm <app name> List the dynamic dependencies. Use otool –L <app name> Dump the load commands for the application. Use otool –l <app name> Dump the runtime information from the compiled application. Identify each class compiled into the program and its associated methods, instance variables and properties. Use class-dump-z <app name>. That can be put that into a .h file which can be used later to create hooks for method swizzling or to simply make the methods of the app easier to read. Dump the keychain using dump_keychain to reveal application specific credentials and passwords if stored in the keychain.

Determine the security features in place: Locate the PIE (Position Independent Executable) - an app compiled without PIE (using the “–fPIE –pie” flag) will load the executable at a fixed address. Check this using the command: otool –hv <app name> Stack smashing protection - specify the –fstack-protector-all compiler flag. A “canary” is placed on the stack to protect the saved base pointer, saved instruction pointer and function arguments. It will be verified upon the function return to see if it has been overwritten. Check this using: otool –I –v <app name> | grep stack . If the application was compiled with the stack smashing protection two undefined symbols will be present: “___stack_chk_fail” and “___stack_chk_guard”.

iPhone Analyzer allows you to forensically examine or recover data from in iOS device.It principally works by importing backups produced from iTunes or third party software,and providing you with a rich interface to explore, analyze and recover data in human readable formats.Because it works from the backup files everything is forensically safe, and no changes are made to the data.IPhone Analyzer is now free for Personal use

If you’re an app developer with a solid foundation in Objective-C, this book is an absolute must—chances are very high that your company’s iOS applications are vulnerable to attack. That’s because malicious attackers now use an arsenal of tools to reverse-engineer, trace, and manipulate applications in ways that most programmers aren’t aware of. This guide illustrates several types of iOS attacks, as well as the tools and techniques that hackers use. You’ll learn best practices to help protect your applications, and discover how important it is to understand and strategize like your adversary. · - — Examine subtle vulnerabilities in real world applications and avoid the same problems in your apps· Learn how attackers infect apps with malware through code injection· - Discover how attackers defeat iOS keychain and data protection encryption· - Use a debugger and custom code injection to manipulate the runtime Objective C environment· Prevent attackers from hijacking SSL sessions and stealing traffic· Securely delete files and design your apps to prevent forensic data leakage· , - , Avoid debugging abuse validate the integrity of run time classes and make your code harder to trace

Top 10 Mobile Risks

M1 : Weak Server Side Controls M2 : Insecure Data Storage M3 : Insufficient Transport Layer Protection M4 : Unintended Data Leakage M5 : Poor Authorization and Authentication M6 : Broken Cryptography M7 : Client Side Injection M8 : Security Decisions Via Untrusted Inputs M9 : Improper Session Handling M10: Lack of Binary Protections

What is the Heartbleed bug?

It’s an OpenSSL vulnerability. OpenSSL is a security protocol that encrypts communications between your computer (or device) and a Web server. As the BBC put it, it’s sort of a “secret handshake at the beginning of a secure conversation.”

Most websites, many operating systems, and many apps use OpenSSL. It’s everywhere, and one version of it has a critical bug that lets hackers exploit a function known as the “heartbeat option,” which lets a computer (like yours) send a message to an Internet server to make sure they are still connected — think a tap on the shoulder to see if your buddy is still awake. This bug lets attackers send fake heartbeat messages to trick the server into sending back sensitive data like passwords and credit card numbers. Again, it’s very bad.

Which operating systems are affected:iOS devices are safe.Windows Phone OS is likely safe.BlackBerry is “investigating.”Android is vulnerable if you have version 4.1.1, according to Google.

OWASP Mobile Security Project - 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.

Thank you!