Sitecore CMS flaw let attackers brute-force ‘b’ for backdoor – Source: go.theregister.com

Security researchers have issued a warning about a pre-authentication exploit chain affecting a CMS used by some of the biggest companies in the world.

Sitecore Experience Platform is a content management system (CMS) used by United Airlines, Procter & Gamble, Microsoft, Fujitsu, and more. Today, the team at watchTowr disclosed three distinct vulnerabilities that could be chained together to achieve full system takeover.

There are seven vulnerabilities in total, only three of which were disclosed today, since customers have had time to apply patches. The other four flaws are not yet fixed, so these will be publicized at a later date.

WatchTowr started looking at Sitecore in February, and at the time the vulnerabilities were reported, they affected the latest available version.

The bugs don’t have CVE identifiers yet, nor do they have severity assessment scores, but to offer an indication, one is a hardcoded credentials issue in which internal account passwords are set to a single letter, and the other is path traversal – one of the so-called unforgiveable vulnerability classes.

The hardcoded password of internal accounts was found to be set to “b,” which the researchers brute forced in three seconds.

“This is sadly not a joke,” the team blogged.

The “b” refers to an old default configuration for Sitecore admin accounts, the passwords for which were always set as “b,” although this is no longer the case.

“The reality is that most users, especially enterprises that leverage Sitecore, are going to be conservative and not amend credentials for users for fear of breaking the environment and CMS,” said watchTowr.

It also noted that Sitecore itself advises customers against changing default user account credentials.

“Sitecore provides a number of default user accounts that you should not change… Editing a default user account can affect other areas of the security model,” its documentation states.

The team went on to authenticate themselves as the ServicesAPI user and played around with post-authentication bugs, including the path traversal affecting the ZIP unpacking mechanism. 

Using the internal user account, the team uploaded a ZIP archive containing a webshell and found that with some tinkering to the CMS’s upload form, they could achieve authenticated remote code execution (RCE) on unpatched versions.

The researchers were able to chain these two vulnerabilities together to achieve RCE, although they said the second was not as trivial to exploit as they might have hoped because the ServicesAPI account had no roles assigned.

The third vulnerability, however, is more attractive to attackers since it is “much easier to exploit” than the ZIP mechanism path traversal, watchTowr said.

The third and final bug disclosed today is an unrestricted file upload flaw that can be exploited as the ServicesAPI user. So, bug 1 + bug 2 = RCE. Bug 1 + bug 3 = RCE.

However, it only works when the external Sitecore PowerShell Extension is installed, and while that is a limiting factor, watchTowr said installing it is required if users want to use “an extremely popular” Sitecore Experience Accelerator (SXA) add-on, unnamed for safety reasons.

• Feds want devs to stop coding ‘unforgivable’ buffer overflow vulnerabilities
• CISA says ‘no more’ to decades-old directory traversal bugs
• Dump C++ and in Rust you should trust, Five Eyes agencies urge
• The US government wants developers to stop using C and C++

“When one installs Sitecore, the installer asks you if you want to install the SXA alongside,” the researchers said. “You should expect many environments to have the PowerShell Extensions installed, but not all.”

As ever, watchTowr’s blog goes into low-level detail and in its trademark style throws in a sarcastic meme every few paragraphs, for those who want a longer, illustrated read.

In it, the team demonstrated exactly how the third vulnerability can be exploited with a carefully crafted HTTP request after first gaining access to the ServicesAPI user.

WatchTowr said at the time of carrying out its research that more than 22,000 Sitecore instances were exposed.

Today’s news comes after the researchers and Sitecore agreed to hold off disclosing the findings until users had ample time to apply the patches in version 10.4, which were made available on May 11. ®