A cross-site scripting (XSS) vulnerability that affected Azure Service Fabric Explorer (SFX) could let unauthenticated remote attackers execute code on a container hosted on an Azure Service Fabric node.
In a March 30 blog post, Orca Security researchers demonstrated how they escalated the XSS vulnerability in SFX (an open source tool for managing Service Fabric clusters) to an unauthenticated remote code execution (RCE) by abusing the metrics tab and enabling a specific option in the console: the “Cluster Type” toggle.
The researchers said the XXS vulnerability, which they named "Super FabriXss," poses more risk than the FabricXss vulnerability they reported on last October. Because a remote unauthenticated attacker can execute code hosted on one of the Service Fabric nodes, attackers could potentially gain control of critical systems and cause significant damage using the Super FabriXss vulnerability.
Orca Security reported the new vulnerability to the Microsoft Security Response Center (MSRC) late last year, which investigated the issue and assigned it CVE-2023-23383 (CVSS 8.2) with an “important” severity rating.
Microsoft then released a fix and included it in this month’s Patch Tuesday March 14. Orca researchers said if automatic updates are applied, security teams don’t need to take any further action.
The Azure vulnerability requires user interaction and also has a high attack complexity, which tends to lower the score, said Zane Bond, head of product at Keeper Security. However, because it’s a remote code execution on a cloud platform, security teams should resolve Super FabriXss ASAP.
Bond said security teams also need to ensure they have a healthy patch management process in place. “If something critical comes up, does the organization’s patch program and schedule have a path to fast-track installation?” asked Bond. “If not, there’s opportunity to improve your patching strategy.”
This recent research covers an interesting attack and could have been an issue if Microsoft had not patched it, said Mike Parkin, who added that it’s a rather convoluted attack path that requires a number of specific circumstances to execute it, which lowered the chance of a threat actor using it in the wild.
“NIST's NVD score for this vulnerability was a 5.4, with an exploitability of only 2.3, which tracks with the researcher's description of their proof of concept,” explained Parkin. “Keep in mind that NIST uses a specific set of formulas to determine the risk score, and they have good (deep) documentation on how they do it, though sometimes the computed score is different from what an analyst would give it. I don't always agree with them myself, for example, but the scores are usually sound."
