Running Invisible in the Background in iOS 8

Since iOS 8’s release, a number of security improvements have been made since publishing my findings last July. Many services that posed a threat to user privacy have been since closed off, and are only open in beta versions of iOS. One small point I made in the paper was the threat that invisible software poses on the operating system:

“Malicious software does not require a device be jail- broken in order to run. … With the simple addition of an SBAppTags property to an application’s Info.plist (a required file containing descriptive tags iden- tifying properties of the application), a developer can build an application to be hidden from the user’s GUI (SpringBoard). This can be done to a non-jailbroken device if the attacker has purchased a valid signing certificate from Apple. While advanced tools, such as Xcode, can detect the presence of such software, the application is invisible to the end-user’s GUI, as well as in iTunes. In addition to this, the capability exists of running an application in the background by masquerading as a VoIP client (How to maintain VOIP socket connection in background) or audio player (such as Pandora) by add- ing a specific UIBackgroundModes tag to the same property list file. These two features combined make for the perfect skeleton for virtually undetectable spyware that runs in the background.”

As of iOS 8, Apple has closed off the SBAppTags feature set so that applications cannot use that to hide applications, however it looks like there are still some ways to manipulate the operating system into hiding applications on the device. I have contacted Apple with the specific technical details and they have assured me that the problem has been fixed in iOS 8.3. As for now, however, it looks like iOS 8.2 and lower are still vulnerable to this attack. The attack allows for software to be loaded onto a non-jailbroken device (which typically requires a valid pairing, or physical possession of the device) that runs in the background and invisibly to the SpringBoard user interface.

The presence of a vulnerability such as this should heighten user awareness that invisible software may still be installed on a non-jailbroken device, and would be capable of gathering information that could be used to track the user over a period of time. If you suspect that malware may be running on your device, you can view software running invisibly with a copy of Xcode. Unlike the iPhone’s UI and iTunes, invisible software that is installed on the device will show up under Xcode’s device organizer.

The flaw here is in the SpringBoard application itself, which (as of iOS 8) only honors the SBAppTags array for applications signed by Apple.

Screen Shot 2015-03-17 at 11.44.41 AM

Or does it? Actually, the pseudocode above demonstrates that SpringBoard doesn’t actually check to see if the application is signed by Apple, but only if it has an identifier with a prefix of com.apple. Apple has assumed that this can’t be spoofed, as they disallow the com.apple identifier prefix in the developer portal.

While the developer portal does specifically disallow com.apple, it looks as though it does allow wildcards that could easily match it, including com.*, com.ap*, or even just *.  I was able to easily register com.* as an identifier and download a provisioning profile with this wildcard.

Screen Shot 2015-03-17 at 11.27.19 AM

Using the wildcard, application identifiers prefixed with com.apple can be signed by Xcode and loaded onto the device. At this point, all of the invisible goodness that allowed SBAppTags to get taken advantage of for so long is back, and the application will magically disappear from the user interface.

App tags aren’t the only thing that can be abused by using the com.apple identifier prefix. Internal controls for widgets and precomposed icon variants can also be used exclusively by apps using this identifier. Potentially more serious, I also glanced across some kernel level code related to kext loading and USB operations that appears to check for this prefix, potentially leaving some room for exploitation if 8.3 hasn’t addressed it here too.

Apple seems to have gone a different route in fixing this than I thought they would. I initially withheld this information from my blog because I thought it was a website vulnerability they’d need to fix. Instead, they’re telling me that they’ve fixed it in the 8.3 betas, which tells me that they’re probably no longer trusting the application identifier to establish any level of trust, which I think is smart.

I’ll have a closer look at 8.3 when it’s released to see how they’ve fixed this. In the meantime, be aware that attacks similar to those demonstrated in my previous white papers, as well as the Mactans (malicious charger) talk and others are all still viable in iOS 8. If you are concerned about this, Xcode’s Device Organizer can be used to display all developer applications installed on the device, and will display hidden applications as well.