Hello guys and welcome back,
On the 10th of March, 2016 I decided to start looking for Cross Site Scripting vulnerabilities in Apple's websites, I really can't remember what motives drove me to start looking for bugs there, but it was a good idea anyways.
I first started enumerating the targets as usual, found a big list of subdomains and started to look for XSS bugs on each of them.
Spending a couple of hours looking for XSSes and finding nothing at all, I started to notice that most of the subdomains need the users to be logged in first to start using them, so I created an Apple ID and started logging in each of the subdomains to have some deeper look into each of them.
The first XSS I found was a reflective XSS on the subdomain
https://checkcoverage.apple.com, which is designed for users that want to check their Apple products' warranty status and whether they are eligible for support and extended coverage or not.
While surfing the subdomain I just mentioned, I found a GET parameter called "sn", which is -obviously- the placeholder of the serial number of the product the user wants to check, I started probing to see if the parameter's value gets reflected in the page, so I used a string as simple as <"xss' to check if any of those special characters gets removed or encoded. See the following screenshot:
The injected payload is reflected inside a <script> tag with no encoding or sanitization of the special characters at all, thus injecting "-alert(document.domain)-" was enough to trigger the following alert box:
The second XSS is a stored one and lies in the subdomain
https://iadworkbench.apple.com/, this subdomain is for advertising purposes and business related stuff, where I found that the organization's name gets reflected inside a <script> tag without any sanitization.
Again, using "-alert(document.domain)-", I was able to come up with the following alert box:
The third XSS I found was on the subdomain
https://appleid.apple.com, if you click on that link, you will find the message "Your account for everything Apple." written between two <h2> tags. Yes, this subdomain is there for users to manage their Apple IDs, which allows them to access everything they use, related to Apple.
I started missing around with the parameters I see, until I came across the GET parameter "key", which over and over again, gets reflected inside a <script> context without any cleansing, leaving one of Apple's most important online services vulnerable to one of the simplest, yet very devastating attacks. See the following screenshot:
This time, just to change the XSS vector, I decided to close the <script> tag prematurely and inject my own <script> tag, and I noticed that <script> and </script> were getting removed completely from the input, but </script/strukt> for example is not removed, so I tried to inject </script/x><script/x>alert(1)</script/x>, but the alert box didn't appear.
I found out that <script/x> was still removed, so I tried </script/x><scr<script>ipt>alert(1)</script/x> and this time it worked, showing that Apple was protecting one of their most important online services with one of the worst approaches ever.
The fourth XSS affects the subdomain
http://mynews.apple.com, and honestly, this is one of the weirdest and easiest XSSes I have ever met.
Developers often do some mistakes, like getting parameter values and letting them into the page source with inappropriate handling first. But in this case, the case was pretty different, the developers were getting he value of the "locale" GET parameter, appending it to some URL, and then using it as the action attribute of a <form> on the page, nothing strange, right ?!
Actually no, the very bizarre thing here was that they were correctly encoding the " and < of the injected payload correctly, but they used the value of the action parameter unquoted. See the following screenshot for more understanding:
Breaking out of the action attribute then was a piece of cake, adding a %20 (space) after the value of the "locale" parameter and adding an event handler with a payload such as "onmouseover=alert(document.domain)" was all that is needed to do the job.
The fifth and last XSS in this series was found on the subdomain
https://atlaslms.apple.com, this XSS was pretty straight forward, a GET parameter called "criteria" was being inserted as the value attribute of some hidden <input> tag and no sanitization at all was there, so I just injected the string "><svg onload=alert(document.domain)> to alert.
Conclusion:
While Apple may be doing a good job securing their OSs and devices, they fail big time when it comes
to protecting their own online services, including those who are somewhat critical to users.
The other thing I'd like to mention is that Apple, being a tech giant, doesn't pay bounties to whitehats. Which, from my point of view, is the main reason why they're not well secured, as well as the reason why a blackhat was happy to get paid to hack into the iPhone the U.S government was trying to convince Apple to get them access to.
Finally, I would like to mention that, after more than 3 months of reporting the issues, some of the bugs are still reproducible at the time this post is released. Also, I was asked to provide my information on the 23rd of March to enter Apple's Hall of Fame for
https://appleid.apple.com's XSS, yet my name still doesn't appear there.
Thanks for reading, see you in another post.
