Top Trending CVEs of September 2023

September was an exciting month for NopSec as we hosted our Customer Advisory Board meetings in New York City. Thanks to all who participated! September has been a busy month for threat reports as the security community embraces a wave of conferences from Defcon to Pwn2Own. Microsoft SharePoint was in the crosshairs this September, which saw the collaboration platform featured in a high profile role in a Vancouver Pwn2Own challenge. Additionally, researchers found that ASP.Net core functions introduced the threat of remote command execution (RCE), which impacted Sitecore and SharePoint platforms using the same novel methods. Interestingly, all of the vulns we cover this month are in some way, shape, or form related to namespace manipulation. Roll up your sleeves and drop to a command line as we cover some trending CVEs for September 2023.

1. SiteCore and the TemplateParser RCE CVE-2023-35813

The path to achieving remote command execution on a Sitecore server via TemplateParser abuse isn’t direct, but under the correction conditions, it is possible. The research begins with the humble ASP.Net TemplateParser. TemplateParsers are at the core of ASP.Net Web Forms and facilitate the parsing of various .Net source files that include *.aspx and *.asmx. 

This is not the first time TemplateParsers have been the target of research, however all previously reported vulnerabilities have relied on compilation of code. CVE-2023-35813 differs in this regard. The premise of the vulnerability resides in how ASP.Net parses various page templates. Recall that this vulnerability does not rely on compilation, but instantiation. When a page is being parsed it can result in the instantiation of user defined objects via tokenization. The tokenization portion of the parsing process detects specia syntax elements which are in turn represented by ControlObjects. One such ControlObject can be defined in the “runat” directive, also known as a server control. This also opens the possibility to instantiate custom server controls using the @ Register directive. The easiest way to visualize this behavior is to map very simple *.aspx gadgets to the equivalent C# code. For example, take the following ASP.Net (*.aspx) code:

<%@ Register
    TagPrefix="MyPrefix"
    Namespace="MyNamespace"
    Assembly="MyAssembly"
%>
<MyPrefix:MyTypeName runat="server" Foo-Bar-Baz="…" />

The equivalent C# code to instantiate this object would look something like this:

var controlType = Assembly.Load("MyAssembly").GetType("MyNamespace" + "." + "MyTypeName");
var property = controlType
    .GetProperty("Foo").PropertyType
    .GetProperty("Bar").PropertyType
    .GetProperty("Baz");

The basic idea here is that it’s possible to instantiate public parameterless constructors or web controls via tokenized input. These conditions can result in deserialization attacks or calling of dangerous Parse() methods.

This brings us to SiteCore, an enterprise caliber content management platform. Researchers found that Sitecore maps “sitecore_xaml.ashx” to  Sitecore.Web.UI.XamlSharp.Xaml.XamlPageHandlerFactory. The parent type of the XamlPageHandlerFacotry type implements the Sitecore.Web.UI.XamlSharp.Ajax.IIsAjaxEventHandler interface, which facilitates calling arbitrary methods on the corresponding instance. It’s a lot, I know. The execution sink in this case revolves around the ability to inject a page or control using tokenized inputs, that ultimately result in the istantiation of unintended user defined objects – all without compilation. The following provides a more accessible example.

POST /sitecore_xaml.ashx/-/xaml/Sitecore.Xaml.Tutorials.Styles.Index HTTP/1.0
Content-Type: application/x-www-form-urlencoded

__ISEVENT=1&__SOURCE=&__PARAMETERS=…

Here, the __PARAMETERS parameter is expected to be of the form Method(“arg1”, “arg2”, “arg3”) where the Method can be the name of any public instance method and the arguments a comma separated list of double-quoted strings matched by “([^”]|””)*”. That means, ParseControl(“…”) results in calling TemplateControl.ParseControl(“…”). Using some novel gadgets it’s possible to do things like define a “runat” property that results in RCE or any other <%#…%> or <%$…%> element. I’m not certain how popular Sitecore is, but this is a clever attack technique that requires a low level of complexity. It’s worth noting that the methods utilized against Sitecore are likely applicable against other targets that have yet to be identified as vulnerable. If you’re running Sitecore, a patch is available. Get on it!

Systems Impacted: 

• The vulnerability impacts all Experience Platform topologies (XM, XP, XC) from 9.0 Initial Release to 10.3 Initial Release; 8.2 is also impacted
• Managed Cloud customers who run the affected Experience Platform versions are affected

Read more:

• https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1002979
• https://code-white.com/blog/exploiting-asp.net-templateparser-part-1/

2. SharePoint RCE CVE-2023-33160

We’ve got a theme going. This is our second TemplateParser vulnerability of the month and it (more or less) uses the same novel techniques that impacted Sitecore. One of the core features of Sharepoint is that it enables users to deploy custom *.aspx pages. However, there are guardrails in place that prevent server side code from being included in any scripts. There’s also a Safe Control List that Microsoft recommends be included in the “web.config” for more granular control. The implementation of the Safe Control list involves comparing the server control type in the source code against the safe control list, which is handled by the SPPageParserFilter.  

Based on what we know about TemplateParsing, this sounds promising. Recall that using a TemplateParser we can define arbitrary Type via the @ Register directive and that property types are derived from server control types through reflection. So the first objective is to determine how this can be leveraged to istantiate user defined objects. It turns out that the namespace of the assembly definition, which is just the Type list, isn’t parsed securely. It was observed that if the namespace contains a null byte then the parsing stops and ignores anything in the appendix. Exploiting this behavior allows users to control the type and property type. It would then be possible to define a TemplateParser such that arbitrary code can be executed. We don’t have access to a SharePoint instance and the researcher stopped short of a complete exploit, however the detailed research almost guarantees that public exploit code is soon to follow. Successful exploitation does require authenticated access, however the account does not require elevated privileges. Microsoft has released a patch to address the vulnerability.

Systems Impacted: 

Upgrading your Spring Security version to one of the following is strongly advised:

• Microsoft SharePoint Server Subscription Edition
• Microsoft SharePoint Server 2019
• Microsoft SharePoint Enterprise Server 2016

Read more: 

• https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-33160
• https://code-white.com/blog/exploiting-asp.net-templateparser-part-2/

3. SharePoint PreAuth RCE CVE-2023–29357 & CVE-2023–24955

When it rains it pours and SharePoint is riding the flood waters. Researchers participating in the Vancouver Pwn2Own challenge have identified a pre-authentication exploit chain that results in RCE. The chained vulnerabilities follow a time honored tradition of authentication bypass, which gives way to code injection. 

It was observed that an unauthenticated attacker could impersonate any SharePoint user by supplying a spoofed JSON Web Token (JWT) with the signing algorithm set to “none”. This subverts signature verification allowing user defined objects to be present in the JWT. The authentication bypass vulnerability only grants access to the SharePoint API, which is where the research becomes more interesting.

This is highly simplified and leaves out a fair amount of technical details from the authentication bypass, however suffice to say there are default SharePoint URLs that will allow OAuth authentication. If you go deep enough down the rabbit hole, we arrive at a ReadToken() function that parses and validates the JWT. A logical flaw in the function entirely skips signature validation. At this point in the authentication process, the JWT has been parsed and the identity of the user has already been validated, in the sense that the user is real and exists. The value of the aud (user) field adheres to the following format <client_id>/<hostname>@<realm>. 

• client_id  – static value, 00000003-0000-0ff1-ce00-000000000000 (valid for all on-prem instances)
• hostname – hostname of the SharePoint instance
• realm – GUID that defines the authentication ID, which the server happily returns when authorization fails for a NULL JWT value 

Having identified all these elements, it’s still necessary to bypass the issuer signature validation, which is conveniently skipped because we have a hash proof token and by forcibly setting the “ver” field in the JWT to “hashprooftoken”. Finally, we can calculate the signature of the request url using a simple algorithm:

base64_encode(sha256(request_url))

When you package all this up, you have an authentication bypass using a crafted JWT payload like the one below.

base64(‘{“alg”: “none”}’).base64(‘{“iss”:”00000003-0000-0ff1-ce00-000000000000″,”aud”:  “00000003-0000-0ff1-ce00-000000000000/splab@3b80be6c-6741-4135-9292-afed8df596af”,”nbf”:”1673410334″,”exp”:”1693410334″,”nameid”:”c#.w|Administrator”,   “http://schemas.microsoft.com/sharepoint/2009/08/claims/userlogonname”:”Administrator”,   “appidacr”:”0″, “isuser”:”0″, “http://schemas.microsoft.com/office/2012/01/nameidissuer”:”AccessToken”,  “ver”:”hashedprooftoken”,”endpointurl”: “FVIwBWTuuWfszO7WYRZYiozMe8OaSaWO/wyDR3W6e94=”,”name”:”f#xw|Administrator”,”identityprovider”:”windOws:aaaaa”,”userid”:”asaadasd”}’.base64(‘nopsec’)

Great, so we can now bypass authentication and access the SharePoint API. It was found that the DynamicProxyGenerator.GenerateProxyAssembly() method contained a vulnerability that allows code to be injected into the proxy namespace property allowing for arbitrary code execution when the assembly is ultimately generated. I left out some steps to save you the headache, but I fully encourage everyone to dive into the beautifully documented research. Proof of concept code is mature and publicly available. I have no actual idea how this was only assigned a CVSS3 score of 7.2. Unauthenticated RCE on a SharePoint system is at least a 9.8. This vulnerability was technically reported and patched back in May 2023. Expect an uptick in threat hunters with the release of the POC.

Systems/Applications Impacted:

The following version of Quantum Appliances and Quantum Security Gateways are vulnerable

• Microsoft SharePoint Server Subscription Edition
• Microsoft SharePoint Server 2019
• Microsoft SharePoint Enterprise Server 2016

Read more:

• https://github.com/Chocapikk/CVE-2023-29357
• https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-24955
• https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2023-29357
• https://starlabs.sg/blog/2023/09-sharepoint-pre-auth-rce-chain/

To stay up to date on the latest trending and critical celebrity vulnerabilities, subscribe to NopSec’s newsletter. If you don’t like having to keep up with vulnerabilities like these yourself, let the NopSec platform do it for you. It takes into account new critical vulnerabilities as they emerge, ensuring your risks are prioritized accordingly in your unique environment. If you’d like to see what the NopSec platform can do in action watch this on-demand product tour.