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.
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:
During restoration the application will:
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 is finishing its restoration of the decoded objects.
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.
VerSprite's Research and Development division (a.k.a VS-Labs) is comprised of individuals who are passionate about diving into the internals of various technologies.
Our clients rely on VerSprite's unique offerings of zero-day vulnerability research and exploit development to protect their assets from various threat actors.
From advanced technical security training to our research for hire B.O.S.S offering, we help organizations solve their most complex technical challenges. Learn more about Research as a Service →
View our security advisories detailing vulnerabilities found in major products for MacOs, Windows, Android, and iOS.