Anatomy of the Apple ID password reset exploit

When The Verge broke news of Apple’s password reset vulnerability, they cited a step-by-step guide that detailed the process of exploiting the service. They declined to link to the source for security reasons, and rightfully so. However, now that Apple has closed the security hole the topic of how it worked and why is worth exploring.

While iMore doesn’t know what the original source was, we were able to reproduce the exploit independently. In the interest of helping people understand how they were put at risk, and allowing anybody designing their own systems to avoid similar security holes in the future, after a lot of consideration and carefully weighing the pros and cons, we have decided to detail and analyze the exploit.

Normally the password reset process has 6 steps:

1. On iforgot.apple.com, enter your Apple ID to begin the process.
2. Select an authentication method - “Answer security questions” is the one we would use.
3. Enter your date of birth.
4. Answer two security questions.
5. Enter your new password.
6. Be taken to a success page saying your password has been reset.

What should happen in a process like this is that each step can only be performed once all of the steps before it have successfully been completed. The security hole was a result of this not being properly enforced in Apple’s password reset process.

In step 5, when you submit your new password, a form is sent to the iForgot servers with the password change request. The form being sent takes shape as a URL that sends along all of the information needed from this last page to change your password and looks something like this:

https://iforgot.apple.com/iForgot/resetPassword.html? forceBetterPlusPasswordRules=true&password=NEWPASSWORD aolParameter=false&borderValue=true&confirmPassword NEWPASSWORD&findAccount=false&myAppleIdImageURL https%3A%2F%2Fappleid.apple.com%2Fcgi-bin%2FWebObjects%2F MyAppleId.woa%3Flocalang%3Den_US&appendingURL &urlhit=false&accountName=johnny%40apple.com

In the steps above, an attacker would be required to properly complete steps 1-3. The URL had the effect of allowing them to skip step 4, achieve step 5, and get confirmation in step 6 that they had successfully reset a user’s password. With a fix now in place, if you try this, you will get a message saying “Your request could not be completed.” and you’ll have to restart the password reset process.

The necessary URL could be acquired by walking through a normal password reset on your own Apple ID, and watching the network traffic being sent when you submitted your new password in step 5. The URL could also be constructed manually by somebody if they looked at the HTML of the password reset page to see what information the page would be submitting in the form.

When Apple initially put a maintenance message on the iForgot page to prevent users from doing a password reset, it suffered from a nearly identical problem. While you could no longer enter your Apple ID and click Next to get to step 2, if you already knew the full URL with the form info needed, you could put it into your browser and be taken right to the “Select authentication method” page.

https://iforgot.apple.com/iForgot/authenticationmethod.html? language=US-EN&defAppleId=johnny%40apple.com&urlhit=false

From here the rest of the password reset process worked as normal. Upon being made aware of this, Apple took the entire iForgot page offline.

It is still unclear if this exploit was ever used in the wild, but hopefully Apple’s response was fast enough to stop any would-be attackers. Apple also issued a statement to The Verge yesterday in response to the security hole, stating "Apple takes customer privacy very seriously. We are aware of this issue, and working on a fix.”, though we have yet to see any comment from them regarding how it happened or how many users may have been affected.

Update: After finding a link to the original step-by-step guide (via 9to5Mac), it appears that the original hack was slightly different, though with a similar underlying principle of modifying requests to Apple and with the same end result.

Source: http://feedproxy.google.com/~r/TheIphoneBlog/~3/lOxxmJi3nf4/story01.htm

INSIGHT ENTERPRISES INGRAM MICRO INFORMATICA INFOCUS