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!

Leveraging An Order of Operations Bug to Achieve RCE in Sitecore- 1545

AssetNotePosted 1 Year Ago
  • Sitecore is a popular CMS used by many Fortune 500 companies. This was the target of this post.
  • The title of the post contains "Order of Operations Bug." Some code needs to run in a very specific order. If it's done in the wrong order, then the protections are for nothing. The author tries to explain this with an example. They have file upload code that A) prevents directory traversal, B) decrypts the file path, and C) saves the file. The problem is that the directory traversal check on the encrypted file is useless since it's the decrypted content being used.
  • In SiteCore, there is a file read vulnerability right along the same lines but slightly more complicated. They have a nice graph that shows how this works but I'll just put some bullet points:
    1. Initial validation is done
    2. Check for the folder being allowed and check the file extension.
    3. URL decode and strip out some content.
    4. Access the file with the path.
  • The issue in the process from above is that the validation happens first, then a transformation occurs. Using this fact, URL encoding the path will bypass the validation and allow for reading of an absolute file path. This fairly classic vulnerability class is found in things requiring complicated parsing. For example, here's an XSS in Skiff from Paul Gereste that relies on modifications being made after calling DOMPurify.
  • To trigger this, a full path needs to be known. In configurations return exceptions, it's possible to leak the absolute path via an error message. With configurations without errors, some brute forcing and educated guessing must be done. Both are viable options, though.
  • In .NET systems, an arbitrary file read is effectively RCE. This is because the web.config contains a validation key for sessions. The sessions have a known vulnerability (or feature) for deserialization to arbitrary objects that leads to RCE. The protection to this is normally you need the key to sign the object. But since we have the key from the file read, we can make the object now.
  • I enjoy reading about new tips and tricks to look for. To me, order of operations bugs make total sense and there are probably a lot more out there.