About  Project Blog Resources

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!

Bypass IIS Authorisation with this One Weird Trick - Three RCEs and Two Auth Bypasses in Sitecore 9.3- 1194

AssetNotePosted 2 Years Ago
  • Sitecore is a CMS written in .NET. They pwned this in 2019 but wanted to see if any new bugs had been added or if they missed anything big years ago. To start with, they do a large amount of recon to look at the functionality without authentication. Additionally, they looked into the Web.config to see how the routing was working.
  • The Sitecore APIs had a standard MVC setup, where the executed route was api/sitecore/{controller}/{action}. While digging around into what they could instantiate with only a few restrictions; it ensures that the object is .NET type and implements the IController interface. A super large attack surface!
  • The class Sitecore.Mvc.DeviceSimulator.Controllers.SimulatorController had the action Preview with the parameter previewPath. This was calling Server.execute under the hood with the parameter that we control. This allows for arbitrary redirects within the application itself without fancy 302s. Damn, that creates a pretty neat authorization bypass!
  • Server.Execute had no restrictions on where it could redirect to. All it had to be was something within the webroot. This function does not rerun the HTTP pipeline (including auth), allowing for bypasses of the IIS setup. Using this, they were able to leak the Web.config file by reading backups.
  • Sitecore's dependency Telerik UI had a known CVE for deserialization that requires knowledge of the Telerik encryption keys. However, since we have this from the backup, we can exploit a deserialization bug to get RCE.
  • While auditing the code base for more things, the path /sitecore/shell/Invoke.aspx caught their eye for obvious reasons. This allows for the arbitrary instantiation of a class and execute any method, with restrictions. In particular, no static items were allowed, a user had to be authenticated and it could only take string parameters. They decided to look for sinks for RCE gadgets.
  • Eventually, they came to DeserializeObject() within the Telerik UI. They followed this back up to find a method that sets this value within a class! Now, they can send in a deserialization method once again to get code execution. They wanted this to be unauthenticated though. A third similar deserialization issue exists as well.
  • Anonymous users couldn't hit the shell endpoint. The endpoint did allow for ANY user to hit the endpoint. If the user wasn't authenticated, the page was still ran but the execution still happened. Within EXM mailing list, the user is set to the Renderer User. They used the Server.execute issue from before to hit this code to trigger the second deserialization attack mentioned above. Neat!
  • I had no idea about the internal redirects causing so many problems. It is super interesting seeing the subtle flaws that can be built with .NET applications. Good read!

Maxwell DulinEmail me!TwitterGithubAdminBlog RSS FeedResources RSS Feed