Process and conclusion of CVE-2014-4423 Analysis

Process and conclusion of CVE-2014-4423 Analysis

Introduction

Some time ago, "steamed rice" published an article on its blog "phishing attack (stealing the App Store password) on a non-jailbreaking iPhone 6 (iOS 8.1.3 )", try to reproduce the entire process after seeing the article. Since "steamed rice" clearly describes the entire process, combined with Apple's related documents, it quickly realizes background running, round robin check App running, remote pop-up input box, and user input and upload to the server. But there is a key problem that has not been solved: CVE-2014-4423, get the user's Apple ID on a non-jailbroken device. There is very little public information about this CVE. The following describes this CVE in detail and provides the PoC.

Official description

In the Security Content of iOS 8, Apple described this:

Accounts

Available for: iPhone 4S and later, iPod touch (5th generation) and later, iPad 2 and later

Impact: A malicious application may be able to identify the Apple ID of the user

Description: An issue existed in the access control logic for accounts. A sandboxed application cocould get information about the currently-active iCloud account, including the name of the account. this issue was addressed by restricting access to certain account types from unauthorized applications.

CVE-ID

CVE-2014-4423: Adam Weaver

I didn't get much information from above, and then I checked the description above NVD:

The Accounts subsystem in Apple iOS before 8 allows attackers to bypass a sandbox protection mechanisms and obtain an active iCloud account's Apple ID and metadata via a crafted application.

 

Account System

The Account is mentioned in the above description, which gives us an approximate scope: Account system.

Through Reverse analysis, we can know the module structure and workflow of the account system. The account system consists of four modules:

1. Applications;

2. Accounts. framework;

3. accountsd service;

4. AccountsDaemon. framework

Among them, accountsd encapsulates AccountsDaemon. framework into a service, and the main logic is in AccountsDaemon. framework.

The workflow of the Account System is: The application uses Accounts. the interface provided by the framework Requests account information from the accountsd service. After receiving the request, the accountsd service calls AccountsDaemon. framework interface to determine permissions and return relevant information to the application.

 

Locating Method

Through the analysis of the workflow of the account system, we can basically identify the problematic module as AccountsDaemon. framework. Next, we need to locate the specific part of the code.

This problem has been fixed in iOS 8, so it is easy to think of the differences between this library in iOS 7.1.2 and iOS 8.0. However, it is found that the difference between AccountsDaemon. framework in iOS 7.1.2 and iOS 8.0 is quite large. In this way, it is too much work to identify the problem.

Since the comparison method is too heavy, we will perform a fuzzy test on the Account System on the jailbreak iOS 7.x device. The test method is as follows:

1. First, we need to authorize our test program to access all accounts, that is, to add account-related permissions when signing:

<Key> com. apple. private. accounts. allaccounts </key>

<True/>

2. All account types are obtained.

3. Obtain information by iteration Account type.

4. Then, the account-related permissions are removed and the output changes are compared.

The comparison result shows that when the account type is com. apple. account. Liverpool, the current iClound account name can be obtained even if the account type is not checked into apple. Verification is performed on a non-jailbreaking iOS 7.1.2 device. The problem also exists, but the problem does not exist on iOS 8 devices. It can be determined that the iCloud account information on iOS 7.x is disclosed through the com. apple. account. Liverpool account type.

Problem Summary

The test shows that on iOS 7.x devices, as long as the user logs on to iCloud (you can not log on to AppStore), even if all the permissions of the iCloud account are disabled in the settings, the malicious program can still obtain the username of the iCloud account.

Reason

Through debugging, we can locate the problematic function as follows:

-[ACDAccountStoreFilter _ isClientPermittedToAccessAccountTypeWithIdentifier:]

By comparing the differences between this function in iOS 7.1.2 and iOS 8.0, we find that the Account type is com. apple. account. in Liverpool, the above functions do not perform permission verification at all and are directly omitted. For specific procedures, see:

Suggestions for users

1. Try to upgrade the device to the latest system.