Critical Security Bulletin SC2024-001-619349 Announced

Index

Your site is probably impacted, and the fix is easy, so get on it:

If all of your content management / standalone instances are locked down already and not accessible to the general public, you can breathe a sigh of relief and take your time to apply the patch.

Every time Sitecore posts a new security bulletin, it leaves the developer community with more questions than answers. This time is no different, so I'll provide my scintillating commentary.

• December 2014: Sitecore 8.0 released, along with the security vulnerability
• Sometime between 2014 and 2024: 3 letter agencies discover and exploit the vulnerability but keep it secret (kidding but also not kidding)
• Some time in 2024: Sitecore discovers / is notified about the vulnerability
• August 2024: Sitecore announces security bulletin SC2024-001-619349
• Not too long after: hacker(s) blog about it
• Not too long after that: script kiddies add it to their botnet reconnaissance scripts

If your ContentManagement and Standalone instances (anywhere you can manage content) are locked down and inaccessible to the general public, the implication is that you, your colleagues, or the content authors are going to exploit this vulnerability (my bet is on the content authors), and therefore you should apply the patch.

If you haven't locked down your content management instances yet, the implication is that anyone could exploit this vulnerability, and therefore you should apply the patch.

I have seen many CM instances which are still publicly accessible. I recently saw an employee from Sitecore corroborate as such, stating that not as many CM instances are locked down as they would like. In some cases, it may be complicated to lock down instances because of non trivial paywalls.

Otherwise, if your content management instances aren't locked down yet, I recommend pitching your stakeholders on Cloudflare Zero Trust. It's fast and easy to implement and it's free for most smaller Sitecore implementations (the first 50 users are free). No VPN needed. It's a no-brainer.

Sitecore's generic response to the questions "can you provide more details" and "how do I know if I've been hacked?" is:

... it is not possible to provide more information regarding the vulnerability due to security reasons. In particular, this might lead to scenario disclosure and cause a severe impact on the customers.

While understandable, I'm reminded of that scene from American Psycho...

However... If the vulnerability is interesting enough, a hacker will blog about it, and then the script kiddies will add it to their botnets within 3 months. That's how it panned out with the last round of vulnerabilities.

Having taken a cursory look at the code, the issue appears to be that unauthenticated users can arbitrarily read files using directory traversal via one or more vulnerable SPEAK pipelines. Luckily I've avoided working with SPEAK so far, but my understanding is that Content Editor and Experience Editor use SPEAK components, and developers can also develop their own SPEAK components to extend the CMS in various ways. Given this, it makes sense why the vulnerability is isolated to the Content Management and Standalone roles.

I'm not a security expert (yet), but this is what I would do: search the network logs for any suspicious calls to SPEAK endpoints. Look for ../ and its various encoded forms in the URL. It's a good idea to flag/block any request URLs containing such strings, given that it's a common attack vector which could also be used to exploit your custom spaghetti code.

I won't go into further details because I don't want to make it too easy for the script kiddies to find this post, nor do I want to help the AI overlords take over the world by exploiting this vulnerability.

Sitecore has no obligation to provide security hotfixes for older versions of Sitecore which are in their "Sustaining Support Phase" (8 years after the initial general availability date). Therefore, it's interesting that Sitecore has provided a fix for those older versions, especially given that 8.0 was released in December 2014. My guess is that it's because the vulnerability is severe enough that it would be bad business not provide a fix for it, but more so because the affected area was isolated enough that the fix was applicable to all versions and thus inexpensive to mitigate.

1. Take this post with a grain of salt because I'm not a security expert (yet)
2. Ensure that none of your content management instances are accessible to the public
3. Assume that those who have access to your content management instances are tech savvy manchurian candidates

Stay vigilant,

-MG