Mobile application security testing (MAST, CSA guideline)
Android platform basically needs to be secure at two levels, i.e., the application level and the device level. For application level security, we look up for server-side as well as client-side security vulnerabilities in the application. Methodology that we follow includes acquiring the APK file, decompile and install. Intercept the requests and check for local storage. We check for the API’s as part of the end-to-end testing. We follow MAST (Mobile Application Security Testing) methodology based on Cloud Security Alliance program.
- A web application proxy (Burp Suite, Mallory)
- A phone emulator (Android SDK)
Burp Suite—Burp Suite is an intermediate proxy that is employed to intercept the traffic between the mobile application and the end-point server:
- Repeater, used for capturing a request and analyzing.
- Intruder, used for automating customized request for attacks on apps.
- Scanner, for automated testing while manually testing the application logic.
- Sequencer, used for analyzing the randomness in random tokens being generated by the application from server side.
- Decoder, used for a quick encode/decode task when we encounter a encoded string in the assessment.
ADB (Android debug bridge) —ADB is a command line tool along with the Android SDK. This allows communicating from the system to the Android device in terms of file transfers, application installations, working on device shell, etc. This has mainly three components:
- A client that runs on the main machine. As soon as we pass any ADB command, a client is invoked.
- A server that runs as a background process on the main machine and manages the communication between the client and ADB daemon.
- A daemon that runs as background process on the device.
ADB gives huge flexibility while interacting with the device. Some of the most commonly used commands are:
- adb shell—Starts a remote shell in the target emulator
- adb install
—Installs the given APK file into the device. –swill make it install on the /sdcard.
- adb push—Copies a file from machine to your device.
- adbpull—Copies a file from device to your machine.
- adblogcat—Prints log data on the screen.
- Download the VM image of App-Use from the website and extract the files in a folder.
- Open this file in VMware-player
- Get the APK file (Either from OLX source OR obtain from Google Play store)
- Static analysis—In this phase, uncover the vulnerabilities on the client side, i.e., insecure storage, etc. The objective is to find out some critical data that can be gained from the APK file itself. (APK file contains the entire program’s code (in DEX files), all resources, certificates, and manifest file.
Manual Process: Copy the APK file and extract the content. Analyze this information with the Java source code. Initiate with android_manifest.xml (This file contains the file permission for the application while accessing the Android operating system on the device.)
While exploring the application on the device, check the website assigned has any unwanted permission. For this, we either use dextojar for converting the Dalvik executable code to the corresponding Java code in the form of a JAR file. JAR file can be analyzed for any malicious strings within the package.
Background: iOS mobile applications are tested taking into account the client software, the communication channel and the server side infrastructure. Testing an iOS application usually requires a jail broken device. (A device that does not pose any restrictions on the software that can be installed on it.)
The following are the steps employed in iOS Testing:
- 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
| grep –A 4 LC_ENCRYPTION_INFO
- Determine the architecture the application was compiled for: otool –f
or lipo -info .
- Get information about what functions, classes and methods are referenced in the application and in the dynamically loaded libraries. Use nm
- List the dynamic dependencies. Use otool –L
- Dump the load commands for the application. Use otool –l
- 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
. 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.
- 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
(otool should be run against the app *binary* after unzipping the ipa, it should not be run directly against the ipa)
- 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
| 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”.
Application traffic analysis
- Analyze error messages
- Analyze cacheable information
- Transport layer security (TLS version; NSURLRequest object )
- Attack XML processors
- SQL injection
- Privacy issues (sensitive information disclosure)
- Improper session handling
- Decisions via untrusted inputs
- Broken cryptography
- Unmanaged code
- URL Schemes
- Push notifications
- Session management
- Data storage
- Data validation (input, output)
- Transport Layer protection – are the certificates validated, does the application implement Certificate Pinning
- Denial of service
- Business logic
- UDID or MAC ID usage (privacy concerns)
- Disassemble the application (gdb)
- Analyze file system interaction
- Use the .h file generated with class-dump-z to create a method swizzling hook of some interesting methods to either examine the data as it flow through or create a "stealer" app.
- Analyze the application with a debugger (gdb): inspecting objects in memory and calling functions and methods; replacing variables and methods at runtime.
- Investigate CFStream and NSStream
- Investigate protocol handlers (application: openURL - validates the source application that instantiated the URL request) for example: try to reconfigure the default landing page for the application using a malicious iframe.
- Buffer overflows and memory corruption
- Decisions via untrusted inputs
- Broken cryptography
- Unmanaged code
Insecure data storage
- Investigate log files(plugging the device in and pulling down logs with Xcode Organizer)
- Insecure data storage in application folder (var/mobile/Applications), caches, in backups (iTunes)
- Investigate custom created files
- Analyze SQLlite database
- Investigate property list files
- Investigate file caching
- Insecure data storage in keyboard cache
- Investigate Cookies.binarycookies
- Analyze iOS keychain (/private/var/Keychains/keychain-2.db) – when it is accessible and what information it contains; data stored in the keychain can only be accessible if the attacker has physical access to the device.
- Check for sensitive information in snapshots
- Audit data protection of files and keychain entries (To determine when a keychain item should be readable by an application check the data protection accessibility constants)