A Remote Code Execution in JXPath Library (CVE-2022-41852)

Source :- https://tutorialboy24.blogspot.com/2022/10/a-remote-code-execution-in-jxpath.html

On 6th October 2022 new CVE was released for critical vulnerability with the identifier CVE-2022-41852. This vulnerability affects a Java library called Apache Commons JXPath, which is used for processing XPath syntax. All versions (including latest version) are affected by this vulnerability.

According to NIST the vulnerability score is 9.8 CRITICAL with CVSS:

Currently, there is no official fix for this vulnerability, but we might have a solution that should protect the application, however, it will disable the use of functions in all XPaths completely.

Are You Vulnerable?

If your application uses the JXPath library (artifact commons-jxpath:commons-jxpath), you might be vulnerable. According to CVE information, all methods for XPath processing are weak, except for compile() and compilePath(). If the user can provide value for the XPath expression, it might allow him to execute code on your application server (in the application context).

ArtifactId: commons-jxpath

GroupId: commons-jxpath

Package: org.apache.commons.jxpath

Version: <= 1.3

If you use SCA (Software Composition Analysis) tools like OWASP Dependency Check, BlackDuck, CxSCA and others, they will probably notify you about this vulnerability automatically.

Proof of Concept

First, let’s look at the proof of concept that I created for this vulnerability on a simple Spring framework application. The PoC contains just a simple vulnerable endpoint method that takes user input and uses it to retrieve specified data from the Person class. Valid user inputs for this endpoint are “author”, “name” and “/”.

If we call this endpoint with the query string ?path=website, it will return the person’s website:

However, attackers can send malicious input with Java code. For example, we can send query string:

This will cause the application to exit. See the following Spring application log:

There might be use cases, where the user’s input is prefixed / suffixed by the application. For example, there might be a preceding slash character (/):

But that does not stop the attacker, because he can simply utilize XPath pipe and send query string (note: %7C is encoded pipe character):

This payload will also cause the application to crash.

Executing Commands

Ok, now we know, how to kill the application server. However, how to run commands on the server? There might be lots of ways that will allow attackers to execute commands on the server. One of them is taking advantage of Spring's ClassPathXmlApplicationContext, which allows loading beans using XML configuration.

Our payload will load an external XML file from our server:

The XML file will contain the configuration for the creation of a bean from Java's ProcessBuilder with parameters for a running calculator using CMD on Windows:

This simple exploit will open a calculator on our Windows server:

Proof of Concept GitHub

You can find code with simplified PoC on GitHub (https://github.com/Warxim/CVE-2022-41852).

Payloads

How to check if some parameter is vulnerable? If you are a pentester and you want to test applications for this vulnerability, these payloads might be helpful:

• java.lang.System.exit(42)
• java.lang.Thread.sleep(10000)
• /|java.lang.System.exit(42)
• |java.lang.System.exit(42)

Of course, you can create your own payloads. Official documentation might be helpful, see the chapter below.

It’s Not a Bug It’s a Feature

What is more interesting is that the above-described vulnerability is actually a feature of the JXPath library. You can even find a user guide for this feature, which describes that we can use fully qualified class names to call functions:

https://commons.apache.org/proper/commons-jxpath/usersguide.html#Standard_Extension_Functions

Solution

Currently, the library does not have a secure version. I have seen opened pull request on JXPath GitHub (see https://github.com/apache/commons-jxpath/pull/25), which adds function-filtering options. However, if you have the library in your project and the user can affect at least part of XPath, there is currently no official solution.

I have a solution that might work for some of you, however, it comes with a cost – no functions will work in XPath expressions. So, if you use functions like size() in our XPath expressions, this solution will not be good for you.

How the partial solution works? During code analysis of the JXPath library, I found that there is the following code in JXPathContext class for creating the GENERIC_FUNCTIONS constant. This constant is used as the default value if no Functions object is specified:

Vulnerable Default In JXPath Code ↗

The code above allows all functions from all packages to be called. If we want to prevent this default to be used, we can specify our own Functions object. For that, we can use empty FunctionLibrary:

Secured JXPath Functions ↗ PoC

Using pathContext.setFunctions(new FunctionLibrary()); we replace the default with empty function library, so the exploit payloads mentioned above will not work. Sending one of the payloads will lead to JXPathFunctionNotFoundException.

Conclusion

If your application is affected, consider using the mentioned solution above. If this solution does not fit your needs, because you need the XPath functions to work, you will have to wait for a new release of this library with the potential fix (note that the library was not released for a long time) or wait for new solutions to arise.

Source :- https://tutorialboy24.blogspot.com/2022/10/a-remote-code-execution-in-jxpath.html