icloud-08-700x393

In january of this year, I decided to take a look at Apples Icloud.
I already had participated in their program before, in 2015 I found a web server misconfiguration that could lead to remote code execution in their discussion forum. I didn’t feel satisfied with this since I had not been able to execute actual code on the server. I reported it and it was patched in a few hours.

Because of the Apple-FBI issue, I decided to take a look at the Icloud, since a lot of private information is stored there.

The first thing I try when researching a web application is checking if XSS and CSRF protection is in place. It seems like they have implemented a good CSRF token system, so I started to check for XSS.

When I search for XSS I try to think a little outside of the box, and think about all possible ways to get my input being loaded in the webpage.
Then I found this functionality to add a password to a file being stored on the Icloud.

If a user likes to lock his file with a password for safety reasons, he is served a form to fill in the desired password and a hint in case you typed the password wrong for 3 times in a row.

and  yes.
I had to try it.

;poiuytf

When you request to print the file, you’ll be promted to insert the password. and after 3 times… the magic happend.

xssyaylol

Now, this is triggered in the  Icloud dashboard itself, and for an attacker, triggering the vulnerability this way is far from ideal. So I opened the file in the editor, and I also had to insert my password to unclock the file.
The vulnerability worked here as well, so I tought this would be a better way to trigger the attack.

I then created a payload that would grab the cookies/tokens/other secrets, and send them to my server, and then redirect the user to a valid file on the Icloud, hosted by me.
This is pretty silent since the victim thinks he just typed the correct answer.

The impact

After I discussed this  bug with another security researcher, Arne Swinnen, I realised I could  only steal httpOnly cookies, which limits the attackers options to perform actions on the iCloud as the target.

But a thing to consider here, since we have complete access to the structure of the webpage is that I could easily hack people by injecting a re-authentication phishing page into the iCloud document authentication page. It’s a guess, but since it’s the iCloud itself that’s asking for a re-authentication, 90% of the users would login, and therefore, give me their login credentials.

I made a proof of concept that uses this attack scenario.