This cheat sheet provides a checklist of tasks to be performed when testing an iOS application.
When assessing a mobile application several areas should be taken into account: client software, the communication channel and the server side infrastructure.
Testing an iOS application usually requires a jailbroken device. (A device that not pose any restrictions on the software that can be installed on it.)
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”.
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
Authentication
Authorization
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)
Runtime analysis
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
Client side injection
Runtime injections
Having access to sources, test the memory by using Xcode Schemes
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)
A tool to assist security assessments and dynamic analysis of iOS Apps, includes runtime views of obj-c classes and methods, and options to modify those values