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

Initial ‘recon’

If you’ve followed me for a while you’ll know that I am not someone to run lots of tools and do much ‘recon’. I prefer just diving straight in. After reading Sam Curry’s post (https://samcurry.net/hacking-apple/) one key thing that stood out to me was the fact he ran Burp whilst playing with various features on his iPhone. To be honest I was quite like ‘o wow’ to the fact I hadn’t thought to try this before even though i’ve proxied traffic through my iphone for a long time. I went and tried replicated some of the bugs Sam described such as find my friends idor. I saw the requests (and confirmed fixed :D) and started the hunt.

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

Hacking as a family

As there is a diverse group of members on BugBountyHunter and each has their own expertise & talent, as members such as 0xblackbird, iBruteForce, JTCSec and Prime were hunting through apps manually, a lot of others such as HolyBugx, xnl-h4ck3r and flag_c0 were running tools to discover more subdomains. After finding a valid XSS and celebrating in chat, various other researchers then mentioned the 4 endpoints we’d discovered were actually on lots of Apple subdomains. This wasn’t just example.apple.com, this affected 30+ subdomains. Nice! Teamwork ❤

Making a proof of concept

Apple won’t pay for just alert(0) right?. So we need to do something to impress those over at Apple. I’ve always mentioned to set goals so I told members it was a case of using the XSS and finding something to leak (token/session info-> account takeover, pii info) and working from there, so the focus at first was set on finding a CORS ‘misconfig’ on an Apple endpoint that contained something useful to an attacker that Apple cares about. PII information for example. (Tip: usually when querying your info a request is sent and you’ll see a response in JSON format. test origin: on these.. we’ve all seen ‘em!)

Let the hunt begin.

Hunting through we noticed lots of Apple endpoints will respond if Origin: is set, but actually most are locked down to specific Apple subdomains. This is a good approach so kudos to Apple for that. Not all of them were as secure and some were semi-relaxed (would allow for multiple .apple.com subdomains rather than just a single subdomain). One thing I mention in my methodology (which is free btw — https://www.bugbountyhunter.com/zseano) is to learn your target as you’re hunting through. The fact some Apple endpoints would respond to Origin:, and some were more relaxed than others, said to me that SOMEWHERE, somewhereeee on Apple, there will be the golden snitch that we’re looking for. Any .apple.com domain whitelisted in Origin:

Full name, address, appleID

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store