iOS security testing

Posted on
Symbols count in article: 10k | Reading time ≈ 0:10

Basics of iOS and application

ios开发证书，描述文件，bundle ID的关系

refer link
refer link

Some key features of the iOS security model are as follows:

  • Security architecture is layered as hardware level, OS level, and application level
  • Encryption right from hardware/firmware level
  • Application sandboxing Robust sandboxing features have been built by iOS that prevent the applications from accessing the data or files of other applications.
  • Data protection using encryption
  • Code signing

iOS secure boot chain

  • Boot ROM

This is implicitly trusted It is known as a hardware root of trust This code is contained in the processor and cannot be updated or changed This also contains the Apple root certificate with authentic public key and uses it to verify that the low-level boot loader is properly signed and has not been tampered before loading

  • Low-level boot loader

This is the lowest level of code that can be updated It also verifies the signatures of firmware of iBoot before loading it

  • iBoot

It verifies the signature of the iOS kernel before starting the kernel This secure boot chain also prevents any malwares that can affect at the boot level

iOS application signing

The following is the overall process about how Apple publishes an iOS app on App Store:

  • All applications running on iDevice are signed by Apple
  • The developer signs the apps and submits application to Apple Apple verifies it (performs some rudimentary checks, not vulnerability assessment of app) If app meets with Apple requirements, Apple signs the application
  • Finally the app is available on Apple App Store

Jailbreak

Jailbreaking allows us to do the following:

  • Access complete filesystem on iDevice
  • Install any app from outside App Store

With iOS 8.3, Apple has blocked each application’s sandbox directory. It means that you cannot access application files using widely used tools, such as iExplorer, iFunbox, and so on, even if the device is rooted. Cydia has introduced Apple File Conduit 2, which allows third-party tools to access application files

Some tools for Jailbroken Device

  • Transferring files to iDevice : any SFTP client such as FileZilla or WinSCP on your PC/Mac
  • Connecting to iDevice using VNC : You can connect to iDevice over VNC using tools such as Veency, which comes with Cydia.
  • manually reverse-engineer the code from binary : class-dump-z
  • Cycript: It’s a command-line debugger, which we will require while conducting dynamic analysis of the app. You can install it from Cydia.
  • In our pentesting process, we will look at both, manual and automated, ways to exploit the vulnerabilities. The idb tool can help to automate many tasks.
  • install the third-party application using command line : AppSync, Installipa

You can find all the installed third-party applications under /var/mobile/Containers/Data/Application directory
Each application is assigned a universally unique identifier (UUID). You can find specific application files using simple search command or by looking into the iOS plist file.

Test methodology

Identifying the Flaws in Local Storage

  • Insecure data in the plist files

plist保存的地方

1，工程沙盒里（就是程序user Document文件夹下，以读取文件，写入文件方式）
2，工程自身里（就是在工程里手动创建一个如.plist文件，把固定的内容写入，这个需要人工手动写入）
3，工程沙盒里（保存到user Document下，不过不需要读写文件，用系统的 NSUserDefaults 可以快速保存添加读取删除基本数据类型，类似于android里的Sharedpreferences ）

plist是什么？

它全名是：Property List，属性列表文件，它是一种用来存储串行化后的对象的文件。属性列表文件的扩展名为.plist ，因此通常被称为
plist文件。文件是xml格式的。Plist文件通常用于储存用户设置，也可以用于存储捆绑的信息。

  • Insecure storage in the NSUserDefaults class

As per the Apple documentation, NSUserDefaults is used for customization as per the user’s preferences. Many times, the developer uses the NSUderDefaults format to store sensitive information.

  • Insecure storage in SQLite database

You can make use of SQLCipher to encrypt the data that will make it impossible to view the contents unless you have the encryption key.

  • SQL injection in iOS applications

The developers should always perform escaping/sanitizing on the user input before proceeding for it. You can make use of parameterized queries that will prevent the SQL injection-like attacks

  • Insecure storage in Core Data

Core Data is an object-relational mapping (ORM) that creates a layer between user interface and database. The developers prefer Core Data as it is faster in terms of record creation than the traditional SQLite format.
From security point of view, these files are similar to SQLite, with the only difference being that the tables are prefixed with Z.

You may have noticed all tables starting with prefix Z and credentials are stored in plain text. You can check ZUSERNAME and ZPASSWORD column values.
Although Core Data is easy to use and fast, it should never be used to store sensitive information.

  • Insecure storage in keychain

There are different conditions depending on which a developer can decide when a keychain item can be readable by an application. These various conditions are known as data protection accessibility constants that can be classified as:

kSecAttrAccessibleWhenUnlocked
kSecAttrAccessibleAfterFirstUnlock
kSecAttrAccessibleAlways
kSecAttrAccessibleWhenUnlockedThisDeviceOnly
kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
kSecAttrAccessibleAlwaysThisDeviceOnly

Keychain refer link

You can get keychain_dumper from GitHub and then use SFTP to copy files on Device. Once you copy the files, use the #./keychain_dumper command to dump the keychain data.

As per preceding constants, the data is accessible when the device is in an unlocked condition or when it got first unlocked after reboot. Developers can also set constant to make the data accessible all the time.

Keychain is known to be a secure place and requires many prerequisites for an attack, such as iDevice should be rooted, unlocked, and so on, to view the contents.

Developers should also avoid storing sensitive information locally. You can store sensitive information on server side. If the information is required to be stored locally, use an encrypted format of database over plain-text formats.

Traffic Analysis for iOS Application

You can bypass SSL pinning by using tools such as SSL Kill Switch. However, note that this is available only for jailbroken devices. I would encourage you to go further and study from its wiki on how it helps in bypassing SSL verification.

Sealing up Side Channel Data Leakage

  • Data leakage via application screenshot

One of the features of iOS is that it takes a screenshot of the application when it moves into the background. An attacker having physical access to the system can easily access this screenshot and view sensitive information contained in it.

You can also automate this process using the idb tool.

  • Pasteboard leaking sensitive information

use Cycript or Idb to find the sensitive data

It’s recommended to use custom pasteboard for sensitive data of your application. You should always clear pasteboard when the application is going in the background.

  • Device logs leaking application sensitive data

You can use the Organizer utility provided with Xcode. Connect the iDevice to Mac, start the Organizer and dump the device logs:

You can automate this process using the idb tool. Use the Log option to capture all device logs and check whether the iDevice is leaking any sensitive information:

This issue arises when the developers forget to remove logs during the release of the application. So, make sure that you have not enabled logs after debug mode.

Analyzing iOS Binary Protections

  • Decrypting unsigned iOS applications

We will first study how to decrypt unsigned applications, which means decrypting applications that are not downloaded from App Store. Let’s decrypt the apps provided with the book. These apps are not signed by Apple. In Chapter 2, Setting up Lab for iOS App Pentesting you have already installed class-dump-z, which is used for dumping code of iOS applications.

  • Decrypting signed iOS applications

  1. select the app that you want to decrypt and provide a name to clutch; it will decrypt the app and show the location where it’s been decrypted:

  2. Once the application is decrypted, you can use class-dump-z. Provide a decrypted IPA file to class-dump-z and it will show you the source code of the application:

  • Analyzing code by reverse engineering

Hopper Disassembler
iGoat application

  • Analyzing iOS binary

Along with reversing iOS apps and analyzing code, you can also perform analysis on binary to check whether it has implemented address space layout randomization (ASLR), and stack smashing protection.

use Mobile Security Framework (MobSF) to try try

  • Hardening binary against reverse engineering

The iOS App Dynamic Analysis

  • Understanding Objective-C runtime

  • Dynamic analysis using Cycript
    The idea is to hook Cycript in the target application’s process ID and perform actions using JavaScript or Objective-C or both.

  • Dynamic analysis using Snoop-it

  • Dynamic analysis on iOS Simulator

How to prevent Ptrace

So, dynamic analysis is one of the most important aspects when it comes to iOS applications developed in Objective-C. An attacker can change the application’s behavior as per requirement.

Here, the problem is that the application allows debuggers to attach files. Application should crash if any debuggers try to attach it, which would prevent you from performing dynamic analysis for application. You can prevent debugging to some extent, at least for important methods that handle sensitive data.

You can make use of the ptrace function in order to prevent debuggers from getting attached to your application. I would encourage you to go through the ptrace function’s documentation provided by Apple at:

[refer link]https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/ptrac

You can import the ptrace.h file and add the following code in the main function:

ifndef DEBUG ptrace(PT_DENY_ATTACH, 0, 0, 0); #endif

This function will prevent debuggers who trace an application while debugging from getting attached to it. There could be many ways to make it difficult for attacker to perform debugging. For sensitive application such as those in the financial sector, you can apply check whether the device is jailbroken; if it is, you can stop executing the application, which will not allow any debuggers to attach it. Developers can also make use of multiple techniques together in order to make it almost impossible to debug the sensitive part of the application.