iOS: Back To The Future II

Last year I disclosed publicly the "iOS: Bact to the Future" vulnerability affecting iOS Apple devices, from version 5.x up to version 7.x (the video of the presentation is available in Spanish, and dubbed into English). Anyone intercepting the target mobile device traffic could freeze a iOS victim device into its current operating system (OS) version forever. Once I notified Apple, in March last year they modified their update servers to behave differently when they identify a client request with a future date (in the "If-Modified-Since" header). As a result, the vulnerability could be still exploited but limited to freezing the iOS victim device into its current OS version till the next update is released, that is, bypassing the most recent updates available.

In September 2014, Apple addressed the "iOS: Back to the Future" vulnerability in iOS 8 and identified it with CVE-2014-4383. After doing some research I discovered that the changes introduced by Apple in iOS included similar checks as the ones previously described for the update servers but on the client side, in particular when iOS identifies a server response with a future date (in the "Last-Modified" header). However, again, the new verifications only check for future dates, opening the door to manipulating requests and responses with a date between the date of the last update and the current date.

Therefore, last month I presented the current state-of-the-art for this vulnerability as "iOS: Back to the Future II", emphasizing not only that nothing has changed from an exploitation perspective since March 1, 2014, but some deep thoughts about the fact that vulnerabilities might be supposedly fixed, even when a CVE gets assigned to them, but perhaps they are not. Perhaps involving the researchers in the verification process for the fix might help to confirm if the vulnerability is really solved...

Although the presentation is in Spanish, I think you can easily follow the timelines on slides 11 and 19, and the technical details on slides 12, 14, 16 and 17.

The following videos demonstrate the current iOS 8.x behavior in different exploitation scenarios:

1. The first video shows an iPhone device running iOS 8.0.2 attacked using the StarWars (Jedi) temporary variant, although the most recent iOS version available is 8.1:

2. The second video shows an iPhone device running iOS 8.0.2 attacked using the Matrix permanent variant (as if iOS 8.0 were the most recent version on 07 Nov 2014), although the most recent iOS version available is 8.1 (officially published on 20 Oct 2014):

3. The third video shows how the update server replies with the current update when receiving a request with a date in the future (07 Nov 2024), and how when an iPhone device running iOS 8.0.2 is attacked using the Matrix permanent variant (with a response using a date in the future, year 2024), it does not process it, requesting subsequent updates from scratch. The most recent iOS version available is 8.1 (officially published on 20 Oct 2014):

4. The fourth video shows how a previous victim iPhone device running iOS 8.0.2 is manually forced (on purpose, "07 Sep 2014") to discover the most recent iOS version available, 8.1 (officially published on 20 Oct 2014) and it even downloads the current update documentation. Then, it is attacked again using the Matrix permanent variant (as if iOS 8.0 were the most recent version on 07 Nov 2014), and it becomes a victim again:

5. The fifth video shows how the attack is not possible once the victim iPhone device has already downloaded the most recent update (e.g. iOS 8.1), as it does not even try to check for new updates till the local pending update gets installed: