Unsafe Application State Restoration (iOS)

What Does Unsafe Application State Restoration Actually Mean?

Despite the fancy title, it essentially means that a mobile application saves the state of a view location that is only presented to an authenticated user, or that contains sensitive data.  Within the event of the application being unexpectedly terminated, the state is restored and loaded back into the UI without first validating or re-authenticating the current user.

Conceptually this happens all the time within mobile applications.  A developer focused on making things easy and enjoyable for the user, will implement this type of functionality, so if by chance the application closes, the user will be brought back into the same state they left off at.

This functionality makes sense, and is a nice addition to many of the applications we use day in and day out, but what if this existed in your mobile banking application, or on a shared device in a hospital for an application that stored and operated on PHI?  If an attacker has direct access to an unlocked device with these applications, he can potentially re-open them after they have been closed, and be presented with very critical data.

So hopefully we can start understanding what this vulnerability actually means and its potential impact.

Preservation and Restoration

For this specific scenario we will explore the technical details surrounding the vulnerability paired with Apple’s UIKit Framework.  The UIKit Framework has a state restoration system that allows for the preservation and restoration for the application’s view controller objects.  UIKit allows the developer to choose which view controllers and views he wants to ultimately preserve and restore.  To do this, a restoration identifier marks a restorable object, which is a string that identifies the view or the view controller to UIKit and the application.

During preservation the application will:

• Tell UIKit it supports state preservation
• Tell UIKit which view controllers to preserve
• Encode all data for the targeted objects

During restoration the application will:

• Tell UIKit it supports state restoration
• Provide the restorable objects
• Decode the state for all relevant objects and return

Class Dump Inspection

To figure out whether or not the application supports preservation and restoration, we can take a look at the output from class-dump-z.

We can see within the Application’s Delegate the method ‘application:willEncodeRestorableStateWithCoder:‘ – this is used to encode the state information for the targeted object.  You can also see the corresponding method for decoding – ‘application didDecodeRestorableStateWithCoder:‘ – which is called when the application finishes its restoration of the decoded objects.

Unsafe Application State Restoration, So What Is The Risk?

The problem is rooted purely in context, meaning it is all based off what the application’s overall business impact will be (i.e. Healthcare).  The biggest recommendation I have so far is there really isn’t a good reason to mark view objects for preservation that exist in a post-authenticated world.  Even if it is solely meant to provide a better user experience, it still is inherently dangerous.

If by chance a developer still chooses to implement this risky functionality, the user still needs to be forced to identify themselves and authenticate back into the application.  It would make the most sense that this process begins before initializing and decoding object state.