This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "IOS Application Security Testing Cheat Sheet"

From OWASP
Jump to: navigation, search
Line 5: Line 5:
 
<p>This cheat sheet provides a checklist of tasks to be performed when testing an iOS application.</p>
 
<p>This cheat sheet provides a checklist of tasks to be performed when testing an iOS application.</p>
 
<p>When assessing a mobile application several areas should be taken into account: client software, the communication channel and the server side infrastructure.</p>
 
<p>When assessing a mobile application several areas should be taken into account: client software, the communication channel and the server side infrastructure.</p>
<p>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)</p>
+
<p>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.)</p>
  
 
== Information gathering ==
 
== Information gathering ==
 
<ul>
 
<ul>
<li>Observe application behavior (for each role available)</li>
+
<li>Observe application behavior</li>
<li>Does the application request/store/transmit transactions (performs payments)</li>
+
<li>Determine the application’s data state (at rest, in transit or on display) and sensitivity </li>
 
<li>Identify access methods and interfaces used</li>
 
<li>Identify access methods and interfaces used</li>
 
<li>Identify what frameworks are in use</li>
 
<li>Identify what frameworks are in use</li>
Line 16: Line 16:
 
<li>Identify what protocols are in use</li>
 
<li>Identify what protocols are in use</li>
 
<li>Identify other applications or services with which the application interacts</li>
 
<li>Identify other applications or services with which the application interacts</li>
<li>Decrypt Appstore binaries: the apps will be decrypted at runtime by the kernel’s mach loader. Cydia has two applications available: Crackulous and AppCrack. 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</li>
+
<li>Decrypt Appstore binaries: the .ipa will be decrypted at runtime by the kernel’s mach loader. Cydia has two 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</li>
<li>Determine the architecture the application was compiled for: otool –f <app name></li>
+
<li>Determine the architecture the application was compiled for: otool –f <app name> or lipo -info <app>.</li>
 
<li>Get information about what functions, classes and methods are referenced in the application and in the dynamically loaded libraries. Use nm <app name></li>
 
<li>Get information about what functions, classes and methods are referenced in the application and in the dynamically loaded libraries. Use nm <app name></li>
 
<li>List the dynamic dependencies. Use otool –L <app name>
 
<li>List the dynamic dependencies. Use otool –L <app name>
Line 26: Line 26:
 
<li>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></li>
 
<li>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></li>
 
<li>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”.</li>
 
<li>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”.</li>
<li>Identify the use of Automatic Reference Counting (ARC – memory management feature). Set the compiler option “Objective-C Automatic Reference Counting” to “yes”. Check this using: otool –I –v <app name> | grep “_objc_release”. Check for symbols that indicate the presence of ARC: _objc_retainAutoreleaseReturnValue, _objc_autoreleaseReturnValue, _objc_storeStrong, _objc_retain, _objc_release, _objc_retainAutoreleaseReturnValue </li>
 
 
</ul>
 
</ul>
  
Line 63: Line 62:
 
<li>Buffer overflows and memory corruption</li>
 
<li>Buffer overflows and memory corruption</li>
 
<li>Client side injection</li>
 
<li>Client side injection</li>
<li>Injection using dynamic linker attack</li>
+
<li>Runtime injections</li>
 
</ul>
 
</ul>
  
 
== Insecure data storage ==
 
== Insecure data storage ==
 
<ul>
 
<ul>
<li>Investigate log files</li>
+
<li>Investigate log files(plugging the device in and pulling down logs with Xcode Organizer)</li>
 
<li>Insecure data storage in application folder (var/mobile/Applications), caches, in backups (iTunes)</li>  
 
<li>Insecure data storage in application folder (var/mobile/Applications), caches, in backups (iTunes)</li>  
 
<li>Investigate custom created files</li>
 
<li>Investigate custom created files</li>

Revision as of 10:27, 26 January 2013

DRAFT CHEAT SHEET - WORK IN PROGRESS

Introduction

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 state (at rest, in transit or on display) and sensitivity
  • Identify access methods and interfaces used
  • 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 two 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>

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 usage (privacy concerns)

Runtime analysis

  • Disassemble the application (gdb)
  • Analyze file system interaction
  • 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

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.bynarycookies
  • 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

Tools

Tool Link Description
Mallory proxy http://intrepidusgroup.com/insight/mallory/ Proxy
Charles/Burp proxy http://www.charlesproxy.com/  ;

http://www.portswigger.net/burp/

Proxy
OpenSSH http://www.openssh.com/ Connect to the iPhone remotely over SSH
Sqlite3 http://www.sqlite.org/ Sqlite database client
GNU Debugger http://www.gnu.org/software/gdb/ For run time analysis & reverse engineering
Syslogd https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man8/syslogd.8.html View iPhone logs
Tcpdump http://www.tcpdump.org/ Capture network traffic on phone
Otool http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/otool.1.html Odcctools: otool – object file displaying tool
Cycript http://www.cycript.org/ A language designed to interact with Objective-C classes
SSL Kill switch https://github.com/iSECPartners/ios-ssl-kill-switch Blackbox tool to disable SSL certificate validation - including certificate pinning
Plutil http://scw.us/iPhone/plutil/ To view Plist files
nm Analysis tool to display the symbol table, which includes names of functions and methods, as well as their load addresses.
sysctl https://developer.apple.com/library/mac/#documentation/Darwin/Reference /ManPages/man8/sysctl.8.html A utility to read and change kernel state variables

Related Articles

Authors and Primary Editors

Oana Cornea - oanacornea123[at]gmail.com

Other Cheatsheets

OWASP Cheat Sheets Project Homepage