Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

We Hacked Apple for 3 Months: Here’s What We Found- 271

Sam Curry & FriendsPosted 5 Years Ago
  • There are 12 extremely serious bugs that are mentioned (all critical). So, sit back, relax and enjoy findings from all of the Apple platforms!
  • First, a complete authentication bypass was discovered on the Apple Distinguished Educators site, which used a Jive forum to work.
  • This bypass was done because a custom password value (###INvALID#%!3) which was imbedded in the page, was used to determine if this was a new user or not. If this was a new user, then the sigin-with-apple account would be linked to this account, resulting in an authorization bypass with all accounts that had no registered on the site.
  • After this, they wanted to get admin access to the Jive console. The URL admin/ had a deny list on it. However simply adding a semi-colon (/admin;/) to the URL would make it possible to go to the Jive admin console.
  • The next bug was an authorization bypass of the manufacturing and distribution site that Apple used. At first, there is nothing interesting because you need credentials to login; otherwise, you are just redirected back. However, there is a special case where an authenticated user needs to access site functionality: password reset.
  • The password reset functionality gave a user the account name Apple No Password User. Using these credentials, it was possible to use the OAuth endpoint in order to generate a Bearer token to use the rest of the site! After reversing the APIs, they had full access to the site.
  • iCloud has an email client that you can use! The next vulnerability was a stored XSS via bad sanitization and altering of tags. Using this, there was an easy stored XSS (via email) that could be used to steal all iCloud information.
  • What are other good targets for findings XSS? Hyperlinks are typically translated into actual links, within the web browser with anchor tags. However, doing this properly is extremely difficult to properly. So, the author found a way to break out of this with weird parsing to get XSS.
  • The next bug is a simple command injection within the ePublisher functionality. This was found because of an error message that was returned that looked suspiciously like CLI output. From there, they add || test123 and recieved the error message /bin/sh: 1: test123: not found to make this fully known to be command injection.
  • With iCloud and the Open in Pages functionality, the URl was sending a request to a allowed-listed domain on the internal network. However, adding the @ourdomain.com, resulting in the first part of the URL appearing to be a username.
  • Using then bug, a SSRF vulnerability could be used in order to exfiltrate the returned data from Apple, including the source code for iOS and other things.
  • Another bug was providing by messages to a particular API gave back extremely verbose error messages that included authorization tokens. Using these authorization tokens, parts of some applications could be visited.
  • Within Apple Books, they found two interesting bugs. First, a trivial XSS on the book title (no need to talk about this more). Secondly, a noticed that screenshots were being taken of HTML of books in an S3 bucket. By assumption, they assumed this MUST be using PhantomJS to do this.
  • Because PhantomJS was being used, they added JS XSS payloads into the HTML in order to perform SSRF on the internal network. Because this was running in AWS, they could use the SSRF to steal arbitrary data from the S3 bucket and some AWS temporary creds.
  • Next, a SpringBoot (eSign) application exposed the actuator/heapdump endpoint, which allowed for a complete compromise of the application. This dump (a .db file) had valid session tokens for Apple employees! This gave them access to 50+ new application endpoints on the site.
  • XXE (no response) into a blind SSRF was another bug.
  • An SQLi was found in the GBI Vertica endpoint. This endpoint was created custom SQL queries, with the ability to control most parts of a query. Although Vertica was trying to prevent SQLi, it was trivial to escape the queries and return arbitrary data. The only thing was bypassing the restrictions of the keywords with /**/ constants
  • A BUNCH of IDORs were discovered on various applications, including one in FindMyFriends.
  • Overall, this shows a few important things:
    • All things are hackable. Just spend the time, put in the effort and you will find vulns
    • Apple has a high security-by-obscurity by restricting access as much as possible, which can give the illusion of security. However, these findings prove this does NOT work.
    • XSS is still hard to prevent in complicated applications
    • Error messages are really valuable for recon and info disclosure
    • Recon is incredibly important! Take the time to understand the infrastructure and find all of the targets