Unrestricted File Upload at Apple.com

Attention - this is a frivolous translation of a note about exactly how Jonathan Bouman found the public AWS S3, which was used on one of the apple.com subdomains. Plus, the note is good because it clearly demonstrates the benefits of several small utilities in conjunction with patience.



Take the coffee and run Aquatone . This utility can detect subdomains in a given domain using open sources and brute force with a dictionary.



Aquatone has four different commands:

1. Aquatone-discover - searches for various subdomains
2. Aquatone-scan - scans the result of claim 1. to open ports
3. Aquatone-gather - takes screenshots of each subdomain, collecting all the results in an html-report
4. Aquatone-takeover - tries to find inactive subdomains hosted by external hosters. Found one? Go register and get your reward!

^{Report output of Aquatone}
Sit, wait, dream.

It usually takes a few minutes to search, scan and collect.
And on Apple.com? It took 30 minutes, 84 reports, 18k unique hosts.

Are we the first to use aquatone for the apple.com scan? Definitely not. Have other people read all 84 pages? Definitely not.

So let's start from page 50 and read only the last 34 pages.

Anomaly search in templates

After 50 minutes of reading the report template is noticed. One of them is that apple.com sometimes uses AWS S3 to store files used by their subdomains. So, if you can get access to write to one of S3 - you can provide access to one of the apple.com subdomains.



Reading all 84x reports is a bore. All reports contain http-headers sent by the server. S3 - always sends the X-Amz-Bucket-Region header. Search this title in reports:



Now everyone needs to manually click to see what will happen if you open the urla. Almost all subdomains give Access denied.



In addition to one: live-promotions.apple.com


^{S3 response, containing the bucket name and directory contents.}

So now there is the name S3 baketa. This allows you to directly connect to it.

How to access, see here .

You need to install the Command Line Interface of AWS and you can try to open this bakt using the name from the answer above

After that you can try to load the fake login page and open it in the browser.

aws s3 cp login.html s3://$bucketName --grants read=uri=http://acs.amazonaws.com/groups/global/AllUsers 

^{alert kuk}

Conclusion
Full read / write access was received on Apple's S3 bakt, which is available on one of their subdomains. Enough for flooding a phishing site or stealing cookies.

Decision
Never give anonymous read / write permission
Fortunately, the S3 protection is pretty simple and defaulted.
see dock: docs.aws.amazon.com/AmazonS3/latest/dev/access-control-overview.html

What was it:

- Phishing page uploaded to live-promotions.apple.com
- It was possible to steal visitors' cookies
- It was possible to extract confidential files from the bake (it contained xcode projects)

Hall of Fame

After 4 hours, I received a response from Apple confirming the bug. On the same day he was corrected and now he is mentioned in the hall of fame


Timeline

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