AI PRP: Request Spark Exposed UI & API

[maoning]

Investigate if exposing any of the following UIs & APIs lead to code execution and test for that in the plugin:

• https://github.com/projectdiscovery/nuclei-templates/blob/b686b1aea279093c30b35486db65a0e9917b66c4/http/vulnerabilities/other/unauth-spark-api.yaml#L4
• https://github.com/projectdiscovery/nuclei-templates/blob/b686b1aea279093c30b35486db65a0e9917b66c4/http/exposed-panels/spark-panel.yaml#L4
• https://github.com/projectdiscovery/nuclei-templates/blob/b686b1aea279093c30b35486db65a0e9917b66c4/http/vulnerabilities/other/spark-webui-unauth.yaml#L4

Please read the rules of engagement first at https://github.com/google/tsunami-security-scanner-plugins/issues/409.

[timoles]

Hi @maoning , I would like to contribute to this PRP request.

After a confirmation of this issue I would start with the step: Vulnerability Research: As a first step, the contributor has to provide detailed vulnerability research & an implementation design for the plugin to the review panel.

I assume, as all the mentioned nuclei templates are exploitable with GET requests, I would base the plugin based on other similar vulnerability detectors. Or should I also submit an RCE payload which, for example, creates a referenceable file?

[maoning]

Hi @timoles ,

Ideally the Tsunami plugin can use either an RCE payload from you or the callback server payload to verify the existence of an RCE. The nuclei template only does regex matching on status code which is too false positive prone.

[maoning]

Here are the tasks for this requests before starting the implementation:

• [x] Conduct vulnerability research with a brief description of how the plugin would work
• [x] Submit the vulnerable configuration of the target application to google/security-testbeds.
• [x] Please submit our participation form

[timoles]

I haven't had time yet to submit to the security-testbeds, will do that tomorrow. However, the rest is completed.

Potential Issues / missunderstandings

From your 3 linked Nuclei templates, one has a CVSS score of 10 due to an unauthenticated RCE. This RCE relies on an attacker to have access to the Spark REST API. However, this UI is not enabled by default. In order to enable it an administrator has to set the environment variable spark.master.rest.enabled true. I just wanted to note that, as the app is not vulnerable by default.

I'm pretty sure this template, which you linked to, has the wrong title. If we have a look at the PR, the shodan screenshot only contains 5 discovered hosts. A shodan query from today revealed 4 active hosts. The matchers are also weird, and do (as far as I can tell) not belong to Sparks. The linked page hypeinnovation talks about Spark, however it seems to be an unrelated platform. (seen here) If we check the HTML source code here. We can see that the supposedly "Apache Sparks" matcher matches something unrelated. The following two screenshots show the supposedly Sparks page. Due to the circumstances I would say this linked nuclei template is a false-positive.

Vulnerability Research

The RCE occurs due to unauthenticated access to the Sparks REST API. This API needs to be enabled by setting the environment variable spark.master.rest.enabled true. This starts another service on the default port 6066. Through this port an attacker can create new jobs by sending a POST request to the endpoint http://<ip>:6066/v1/submissions/create.

Within a job an attacker is able to specify a remote job source. This can be a .jar which is remotely loaded by the server. We can then run the constructor of an arbitrary class within this jar file. As we control the jar, the constructor call, and arguments, we can create a malicious jar which allows us to execute arbitrary code.

Full exploitation of this issue requires us to run a web server (or host a static resource) from which the vulnerable Sparks instance runs the code. Instead of executing code, I would match vulnerable services through the interaction service. If the vulnerable Sparks instance issues an HTTP request to our attacker-controlled collaborator server, then we can be reasonably sure that it is vulnerable. This would avoid the requirement to host a malicious payload and a webserver.

The following screenshots illustrate how a malicious submission triggers an HTTP request to an attacker-controlled server.

Exploit Request:

Request from Apache Sparks to our interaction Server:

Please note, the Apache Sparks instance only executes our malicious task if it has a worker node configured. I couldn't bring the master node to execute tasks, if no workers are available. In real-world systems this shouldn't be an issue thoguh.

Regarding the third Nuclei template (Unauthenticated Spark WebUI: From my perspective this issue is simply a information disclosure vulnerability. There's no way to achieve RCE, and we would need to match the response code and response body to determine a finding.

Apache Spark does not see the two previously mentioned issues as vulnerability. In their security doc they state that access to the API needs to be protected, either through a proxy an authentication method implemented in a javax servlet filter. https://spark.apache.org/docs/latest/security.html#web-ui

For this reason I assume Apache Sparks won't require authentication in the near-future. This might allow us to always use the latest tag when building the Apache Sparks vulnerable service. However, just to ensure the lab environemtn doesn't break in the future, I would still tag it to spark v3.4.2 (the currently latest version)

TL:DR Plugin Design

For the remote code execution vulnerability we send a GET request which attempts to retrieve the current API version. Then we send a POST request (even if we can't determine the API version) with a payload which includes an URL to our interaction server. If the interaction server is triggered, the application is vulnerable.

For the Exposed UI vulnerability we send a GET request and match on the status code and response body.

Best Regards Timo

[maoning]

Thank you @timoles for your detailed analysis, I'm really impressed by its thoroughness and look forward to your plugin implementation.

Please see my past comment at https://github.com/google/tsunami-security-scanner-plugins/issues/334#issuecomment-1662896328 about how to use Tsunami callback server to receive OOB interactions. There are several Tsunami plugins that already have callback integration and you can use them as examples.

Let me figure out a location on the github repo to host the jar file, you can proceed forward with the plugin implementation.

[maoning]

You can now add the remote payload to https://github.com/google/tsunami-security-scanner-plugins/tree/master/payloads

[timoles]

Thank you for establishing the payloads folder. Just a quick update, the development of the plugin took a bit longer than expected and I had less time on the weekend than expected. The plugin needs some cleanup but is mostly done. You should expect a PR tomorrow.

[maoning]

@timoles Thanks for the contribution, the reward has been granted.