Search
Close this search box.

Written by: Mike Yang

With the release of iOS 10 on Tuesday, Apple made a number of significant changes to the mobile operating system. The most attention-grabbing security upgrade is the move to push software updates over an encrypted connection, a fix that is more than two years in the making.
In 2014, researcher Raul Siles of DinoSec discovered that an attacker could intercept the traffic between an iOS device and Apple’s update servers and prevent the device from receiving an update. The vulnerability was a major one, as it would allow the attacker to block security fixes from reaching a device and effectively freeze the device on a given iOS version. The attacker could then exploit known vulnerabilities in the software.
Siles disclosed the bug to Apple at the time, and the company released a patch for it in iOS 8, but the fix was incomplete. It’s only now, more than two years and two major iOS releases later that the root cause of the vulnerability has been addressed. By not using HTTPS for the software update process, Apple had left the attack scenario open for years.
“An attacker can impersonate Apple’s servers by intercepting and manipulating the traffic exchanged between iOS-based mobile devices and the specific Apple servers used for the software updates, both in a MitM position while sharing the network with the victim device (or from any intermediate network point) or by offering a fake Wi-Fi network connection to the victim device,” Siles said via email.

“An attacker can impersonate Apple’s servers by intercepting and manipulating the traffic.”

The patch that Apple included in iOS 8 for the vulnerability was only a partial one. After it was released, Siles looked at the fix and discovered that he could still exploit the issue.
“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,” he wrote in a post at the time.
What’s unclear in all of this is why Apple wasn’t using HTTPS for the entire process all along.
“Why Apple didn’t use HTTPS (and certificate pinning) for the iOS update check process? Was it due to performance reasons? Even in this case, it is crucial to differentiate between the update check process (to verify if there is a new version available) and getting the update contents, that is, the update process itself (to download and install the new available version),” Siles said.

More
Blogs