Unrestricted File Upload at Apple.com
Are you aware of any (private) bug bounty programs or platforms?
I would love to get an invite. Please get in touch with me: Jonathan@Protozoan.nl
To explain this type of bug we need a target. The most powerful brand in the world would therefore be a perfect fit: Apple.com
Get your coffee and start Aquatone. This tool can discover subdomains on a given domain by using open sources and a dictionary brute force approach.
Aquatone has four different commands:
1. Aquatone-discover: looks up different subdomains from open sources and tries commonly used subdomains
2. Aquatone-scan: scans the result from step 1 for open ports
3. Aquatone-gather: creates screenshot of every subdomain, combines all the results in a nice HTML report.
4. Aquatone-takeover: tries to find inactive subdomains that are hosted by external hosters/services. Found one? Go to the external host, register an account with the subdomain, earn your bounty! See this github for a list of external services that allow takeovers.
Sitting, waiting, wishing
Normally it takes a few minutes for the discovery, scan and gather commands to finish. At Apple.com? It took a staggering 30 minutes, 84 pages report 18k of unique hosts to scan.
Are we the first one that use aquatone to scan Apple.com? Definitely not. Did the other people read all the 84 pages? Definitely not.
So we will start at page 50, and only read the last 34 pages.
Search for anomalies in the pattern
After 50 minutes of reading reports we will see patterns. One of them is that Apple.com sometimes uses AWS S3 for hosting the files used by their subdomains. So if we’re able to gain (write)access to one of those S3 buckets, we may provide ourselves with access to one of the subdomains of Apple.com. Great!
Reading all the 84 reports is quite boring, so let’s try something different. All the reports contain the headers sent by the server. S3 buckets always send the
X-Amz-Bucket-Region header. So let’s search for this string in our reports.
We now look for every hit manually, what happens if we open the url? Almost all of the subdomains give an
Access denied response if you try to visit them.
Except for one: http://live-promotions.apple.com
So we now have the S3 bucket name. This allows us to directly connect to it.
Let’s look up how we access this bucket: https://docs.aws.amazon.com/cli/latest/reference/s3/
We need to install the Command Line Interface of AWS and we may try to open this bucket by using the name from the response above.
After that we try to upload our fake login phishing html and see if we are able to open it in the browser.
aws s3 cp login.html s3://$bucketName --grants read=uri=http://acs.amazonaws.com/groups/global/AllUsers
We now have full read/write access to an Apple S3 bucket and the files are accessible through one of their subdomains. Enough to setup our phishing website or to steal cookies.
Never allow anonymous users full read/write access.
Luckily securing your S3 bucket is quite easy, they are private by default.
See the documentation: https://docs.aws.amazon.com/AmazonS3/latest/dev/access-control-overview.html
- We may upload a phishing website on live-promotions.apple.com
- We may steal subdomain shared Apple.com cookies from visitors
- We may steal confidential files from the bucket (it contained xcode projects)
Hall of Fame
Within 4 hours I received a reply from Apple, confirming the bug. The same day it got fixed and in return I’m now mentioned in their Hall of Fame
19–06–2018 Discovered and reported bug
19–06–2018 Apple confirmed the bug
19–06–2018 Apple fixed the bug
22–06–2018 Apple mentioned me in the Hall of Fame
22–06–2018 Published this blog