A lot has happened at XBOW since our Humans vs AI experiment, as we shifted our focus from benchmarks to real-world applications. Over the coming weeks we will be sharing some of the most interesting vulnerabilities XBOW has found in real-world, open-source targets, publishing our findings as we complete the process of responsible disclosure and work with vendors and bug bounty programs to get the issues fixed.

In this blog post, we are going to discuss a vulnerability found completely autonomously by XBOW in Scoold, an open-source Q&A site similar to Stack Overflow that is used by well-known companies like Cisco, IBM, Siemens, and Roblox.

The vulnerability itself is critical, allowing an unauthenticated attacker to bypass authentication and both read the application config (including sensitive API secrets) or modify it to take over the Scoold instance. A redacted example of secrets commonly stored in the config from a (now-fixed) Scoold instance in the wild is shown below:

Moreover, due to a feature of the somewhat obscure configuration language HOCON, the vulnerability could be used to read arbitrary files on the remote target:

It’s worth reading the full trace showing XBOW’s discovery and exploitation of the vulnerability, but here we’ll provide a guided tour through the most interesting moments. Note that some of the trace excerpts below have been edited for brevity.

Initial Code Analysis and Reconnaissance

XBOW was provided with the one-line description of the app provided on the Scoold Docker Hub repository (“Stack Overflow in a JAR”), the application code (in compiled form, as a JAR file), and instructions to find an exploit that would allow an attacker to read arbitrary files on the server. To allow XBOW to unambiguously prove that it had exploited the target, we planted a secret /flag.txt on the server’s filesystem and asked XBOW to provide its content. To accomplish the task, XBOW’s first move was to start examining the application by unpacking and analyzing the code in the application using the javap disassembler:

At this point, based on the “Stack Overflow in a JAR” description of the application, XBOW decides to try to find and exploit a stack overflow — this doesn’t turn out to be fruitful, but it’s an understandable mistake given the provided description. From browsing through the code, XBOW realizes that the configuration language, HOCON, could be used to trigger such a stack overflow, and attempts to probe the configSet() endpoint:

Here, XBOW hits its first roadblock. While the source code review uncovered a config endpoint, its attempts to interact with the endpoint return “Method not allowed” errors (HTTP status 405). In order to understand the API endpoints better, it turns to fuzzing:

Bypassing Authentication

Based on the fuzzing results, XBOW realizes that the previous errors were caused not by any mistake in how it was calling the endpoint, but because the endpoint requires authentication. It proceeds to inspect the disassembled code to understand how authentication works, and tries authentication with several dummy tokens, but without much luck. In the process, though, it discovers some useful information, like the fact that both JSON and HOCON can be used to set configuration parameters.

It concludes that it has two options to make progress: it can either find valid authentication credentials, or find a vulnerability that allows it to bypass authentication.

To find an authentication bypass, XBOW builds a Python script that systematically tries different combinations of encodings, extensions, and path normalization tricks:

XBOW notices that one of the many variations attempted — putting a semicolon in the path — returns an HTTP status of 200 (OK) rather than 401 (Unauthorized)! It correctly deduces that this allows it to bypass authentication on the /api/config endpoint:

Now that it has figured out how to bypass authentication (already a critical vulnerability), it proceeds to try and cause a stack overflow using the HOCON language, as it originally intended. It succeeds, but this doesn’t help it achieve its goal of reading files on the server:

Reading Arbitrary Files

All the pieces are now in place for XBOW to achieve its goal of arbitrary file reads by (ab)using features of the HOCON configuration language. It has some initial difficulty with this approach, because the application is not fully configured, and raises errors when trying to update the configuration. But XBOW comes up with a clever workaround: by using the HOCON include directive, it can trigger an error during the configuration parsing phase that reveals the file content in the parser’s error message:

And voilà, it manages to extract the secret content of the file we planted, proving that it achieved an arbitrary file read:

Fixing the Issue

Once we reported the issue, the Scoold developers responded quickly, releasing a patch that fixes the authentication bypass vulnerability. From the patch, we can see that the root cause was using getRequestURI(), which does not perform path normalization — this type of issue has previously been seen in other Java webapps, where the path used in the access checking logic differs from what the application actually accesses.

We also applied for a CVE for this issue, and were assigned CVE-2024-50334. We’re excited to share many more we’ve found in the coming weeks, and help improve open source security using XBOW!