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!

Cloudkit is a data storage framework written by Apple, which is their equivalent of Google's Firebase. The access controls on this are vastly complicated and the author constantly made mistakes while trying to set it up himself.

Cloudkit has lots of features. If you want more, read the docs. But, this is a good overview:

• Containers are the top level storage system within Cloudkit. They all belong within a single iCloud account.
• The container has a production and a development environment.
• There are three different scopes. Private is when a data is only accessible by the one user. Shared is used for data shared between users. Public is accessible anyone with a public API token.
• Each environment has different zones. These zones are created by users to store the data and the organization is defined called record types.
• The record types have standard fields, such as INT, BOOL and TEXT.
• Each record type has records, which are individual stored data.

The main reason for this research was "It was quite complex to understand all different authentication flows, and security roles, and this made me curious. Could it be that this was not only complex for me to understand, but also for teams using it internally at Apple?" This is a wonderful reason for the research, since Apple eats its own dogfood.

While browsing through lots of websites, they found a few bugs, all relating to access control issues within Cloudkit. The first one in iCrowd+. They found that the public token had write and deleting permissions, which allowed them to modify the website directly.

Different APIs may interact with Cloudkit differently. While testing the the iCloud app, they wanted to see if the iCloud container was accessible from the Notes application. By changing the scope of the request, this appeared to be possible! What does this mean though?

By using this API instead of the more complicated iCloud one (which had been semi-reverse engineered by this point), the calls were easier to make. Through this API, the author made a substantial amount of calls, such as creating, updating, replacing and many other things. However, the forceDelete action actually worked on AppleNews!

This meant that any channel or article could be deleted that were stored in the com.apple.news.public container. This is because authenticated calls to Cloudkit were being made through the Notes app, which was improperly scoping the requests being sent.

The final bug was found in Apple Shortcuts, which allows you to trigger actions across app on the devices. Even though this should have been in the shared scope, it was in the public scope with a large GUID. Doing the standard API testing (like it was done above), did not work though. So, the author decided to use their own container and change the scope to com.apple.shortcuts instead. This mis-configuration did not allow for direct editing but got him a properly scoped token.

After a while, the author looked at the zones on this site. They noticed that even though iCloud did not support other zones, shortcuts did for some reason. With a permissions overlook, they could add their own zones. Finally, they tried to delete a zone and ... they bricked Apple Shortcuts.

The author was shocked when the deletion worked. Bricking something this big is bad, but I felt they took precautions to prevent this from happening. How else are you supposed to find this bug unless you try and test it? From these bugs, they author made 64K!

Overall, it is interesting to see Cloudkit used in action and real bugs that were wrong with it. I found the permissions issues to be interesting, particularly the deletion cases, since this is not seen all the time.