Finding XSS on .apple.com and building a proof of concept to leak your PII information

Back in February of this year I hacked with members of BugBountyHunter.com on a public bug bounty program and we chose Apple as our target. This post will detail how we discovered some XSS and built a PoC to leak PII information across multiple .apple.com subdomains. The teamwork from this event was phenomenal and I can’t wait to do another soon.

Initial ‘recon’

One file that stood out for me in the requests was a “bag.xml” file (https://apps.apple.com/bag.xml) which is requested when opening various apps on your iPhone. It appeared to contain endpoints as well as headers & parameters required to interact with them. (In the URL above you can’t see headers needed but there’s a way to get it to respond differently with various information but I won’t mention that here. :D Go play yourself!!). There wasn’t any guessing, the information was here for me. Now this is the kind of ‘recon’ stuff I like because there’s no fuzzing for /backup.zip and instead I know these endpoints are going to have some sort of code execute. When there’s code to be executed there’s me the other side wanting to find out how things work and break it.

Reading this in detail? If you check Sam currys post you will see “WebObjects” is used in a lot of requests. :-) Be pro-active and you will find some interesting things in places

I shared the file with members and we began hunting through. I personally gathered all of the endpoints listed in this bag.xml file and ran them through Intruder (https://zseano.medium.com/using-xampp-and-burp-intruder-when-scanning-for-subdomains-to-look-for-interesting-behaviour-code-f24c511d15ed) with a simple cURL request querying these endpoints with custom headers. I started browsing the responses to various different requests but also went to start checking google & github, as well wayback, to see if there was anything extra info on these endpoints. Some members started their tools and others went hunting on newly disclosed subdomains and it was honestly great to see everyone go hands on and working as a team.

Tip: Some .apple.com domains & endpoints will only respond with certain user-agents and headers set. You can check this when testing on your iPhone and checking user-agent. Don’t blindly scan with default user agents — know your target!

As my intruder went BRRRRRR I noticed some endpoints responded with various interesting errors and this is where the collaboration with members of BugBountyHunter came into play. I fuzzed GET/POST requests and various different content types and on 4 endpoints we discovered we could control the POST Data but our input was getting URL encoded on response. Doh.

But, one member, YouGina, then mentioned our FORM post should have enctype=text/plain set and it should work. This is something I overlooked when testing so massive kudos to him as he was correct and now we have a working XSS!

Hacking as a family

(There is lots to mention, why not check our epic hackers yourself — https://www.bugbountyhunter.com/ourhackers)

But what can we do with this XSS?

Making a proof of concept

As well as this I mentioned to check for any interesting tokens when logging into various apps/services and note it down for us to maybe use further down the line.

Let the hunt begin.

Persistence pays off. Next tip: Don’t give up too early. I get some DMs with people saying they can’t find anything and i’m like “well how long have you been hacking on it?” and they reply ‘2 days’. Go for one target for 3–6 months then DM me! ;)

I personally opened as many Apple apps on my iPhone and other members went to check lots of web applications. It took a bit of time but eventually we found endpoints which contained PII information and also allowed *.apple.com in the Origin header which affected every domain we’ve found XSS on. As our subdomains were all whitelisted in the Origin: header (*.apple.com was allowed) from here it was a simple case of building a simple PoC to send a request and retrieve PII info. We use alert to demonstrate but it wouldn’t be hard to send this to an attackers domain. (https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Using_XMLHttpRequest)

Full name, address, appleID

We now had 4 separate XSS (unique endpoints!) across multiple domains which could be used to retrieve PII info on multiple Apple services. Our POC didn’t really require any user interaction apart from visiting our site (totallynotevil.com) and the XSS on .apple.com would execute. (As we could automate the FORM post right?!). For me personally I felt like this finding would be something Apple is interested in because lots of users were affected based on the subdomains we discovered we could leak PII information on. We sent off our report and waited a few months only to be told our finding was not novel enough and there’s no bounty which was a shame, but it is what it is. All of the XSS have been confirmed fixed for over 90 days and the Origin: header is now locked down on the discovered endpoints and only allow certain subdomains. Nice work!

However, actually, after sending this blog post to them for review they mentioned that they would re-adjudicate (I literally just asked if the blog was okay to post, so this is really cool of them!). will update!

Tip: When i’ve reported leaking PII information with a “wonky” Access-Allow-Control-Origin: i’ve seen the bug bounty program only fix the XSS and you can use further XSS to leak PII information. This is actually something which helps you get a “feel” for things over at your chosen program. How are they fixing issues? Are they treating XSS as all the same with a flat rate of $500 for example no matter the poc (alert vs account takeover) or are they being pro-active and thinking further, “Oh, does this account.json really need to allow for *.domain.com? That dev-test.example.com domain probably doesn’t need access…”.

The total time hacking was around 5 days max (not full days, 3–4 hoursish a day) but this is how we went from using something as intended (opening an App on iphone), seeing an interesting file, investigating and understanding the information it contained, then finding XSS and finding a way to increase the impact via leaking PII information from a wonky AACO. It was a case of poking around, seeing what’s what, and then when discovering something, understanding the goal of how we can achieve more impact. From digging deeper actually it will help you learn more of the assets your testing and getting familiar with what’s out there.

This event was actually the first ever Hackevent over at BugBountyHunter.com where Level 2+ members and myself hacked together on a chosen program as part of ‘bounty training’ (applying what you’ve learnt on bug bounty programs). There was over 20+ hackers involved and I really enjoyed hacking with them all. Current hackevent formats have changed but I strongly feel I have built a ‘1337’ ;) team over the last year whilst getting to know them on a personal level through triage and events and I’m looking forward to what the future will bring for us all when it comes to hacking together! :-)

stay safe and keep hacking!

UK WebApp Security Researcher. Creator of BugBountyHunter— designed to help people learn and get involved with hacking. zseano.com & bugbountyhunter.com