From our analysis of the exploits, we know that the fake kernel task port (which gives kernel memory read and write) is always destroyed at the end of the kernel exploit. The implant runs completely in userspace, albeit unsandboxed and as root with entitlements chosen by the attacker to ensure they can still access all the private data they are interested in.

Using jtool we can view the entitlements the implant has. Remember, the attackers have complete control over these as they used the kernel exploit to add the hash of the implant binary’s code signature to the kernel trust cache.

Many system services on iOS will try to check the entitlements of clients talking to them, and only allow clients with particular entitlements to perform certain actions. This is why, even though the implant is running as root and unsandboxed, it still requires a valid entitlements blob. They’re assigning themselves three relevant entitlements:

keychain-access-groups is used to restrict access to secrets stored in the keychain; they’ve given themselves a wildcard value here.

com.apple.locationd.preauthorized enables the use of CoreLocation without explicit user consent, as long as Location Services is enabled.

com.apple.coretelephony.Identity.get allows retrieval of the device’s phone number.

Reversing

Structure

[Service startTimer] will ensure that the Service instance’s timerHandle method is invoked every 60 seconds:

timer_handle is the main function responsible for handling the command and control communication. Before the device goes in to the timer_handle loop however it first does an initial upload:

This performs an initial bulk upload of data from the device. Let’s take a look at how these are implemented:

Note the call to NSLog is really there in the production implant. If you connect the iPhone via a lightning cable to a Mac and open Console.app you can see these log messages as the implant runs.

Here’s the output which gets sent to the server when the implant is run on one of my test devices:

This method collects a myriad of identifiers from the device:

• the iPhone model
• the iPhone name (“Ian’s iPhone”)
• the ICCID of the SIM card, which uniquely identifies the SIM
• the iPhone serial number
• the current phone number
• the iOS version
• total and free disk space
• the currently active network interface (wifi or cellular)

The IP address of the server to upload content to is hardcoded in the implant binary. This function uses that address to make an HTTP POST request, passing the contents of the files provided in the files argument as a multipart/form-data payload (with the hardcoded boundary string “9ff7172192b7” delimiting the fields in the body data.)

Let’s take a quick look at buildBodyDataWithParams:

This is just building a typical HTTP POST request body, embedding the contents of each file as form data.

There’s something thus far which is conspicuous only by its absence: is any of this encrypted? The short answer is no: they really do POST everything via HTTP (not HTTPS) and there is no asymmetric (or even symmetric) encryption applied to the data which is uploaded. Everything is in the clear. If you’re connected to an unencrypted WiFi network this information is being broadcast to everyone around you, to your network operator and any intermediate network hops to the command and control server.

This means that not only is the end-point of the end-to-end encryption offered by messaging apps compromised; the attackers then send all the contents of the end-to-end encrypted messages in plain text over the network to their server.

The command loop

[Service status] uses the SystemConfiguration framework to determine whether the device is currently connected via WiFi or mobile data network.

[Service cmds] calls [Service remotelist]:

This method makes an HTTP request to the /list endpoint on the command and control server and expects to receive a JSON-encoded object in the response. It parses that object using the system JSON library (NSJSONSerialization), expecting the JSON to be in the following form:

Each of the enclosed commands are passed in turn to [Service doCommand]:

This method takes a dictionary with a command and an optional data argument. Here’s a list of the supported commands:

Each command is responsible for uploading its results to the server. After each command is complete a GET request is made to the /list/suc?name=X endpoint, where X is the name of the command which completed. A cookie containing the device serial number is sent along with the GET request.

The majority of these commands work by creating tar archives of fixed lists of directories based on the desired information and the version of iOS which is running. Here, for example, is the implementation of the systemmail command:

This uses the [Util tarWithSplit] method to archive the contents of the /private/var/mobile/Library/Mail folder, which contains the contents of all locally-stored email sent and received with the built-in Apple Mail.app.

Here’s another example of a command, locate, which uses CoreLocation to request a geolocation fix for the device. Because the implant has the com.apple.locationd.preauthorized entitlement set to true this will not prompt the user for permission to access their location.

Here’s the response to the location command, which can be sent up to every 60 seconds (note: I have changed the location to be the peak of the Matterhorn in Switzerland):

App contents

If the attackers were interested in other apps installed on the device they could use a combination of the applist and app commands to get a listing of all installed app ids, then upload a particular app’s container directory by id. The allapp command will upload all the container directories for all apps on the device.

Impact