I saw the vulnerability warning information from Weibo, so I wanted to start recording the process of reproducing the nday vulnerability from scratch. Although there is very little code auditing involved this time, it can still be considered a path, so let's record it.
First, let's look at the warning information.
First, extract the keywords: accessToken default, configured in application.properties, bypass authentication call executor.
Next, let's go to the official repository of xxl-job to find this file.
This file has multiple copies but the content is the same, so let's take the one under xxl-job-admin as an example. We can see that there is indeed a configuration item for accessToken in application.properties, and its value is default_token. Because properties is a purely static file, there are no syntax variables, so it is confirmed that these characters "default_token" are the ones.
Okay, now that we have determined the value of accessToken, this will be the key to constructing our payload. Next, we need to figure out what can be bypassed through this value. That is, what the warning information refers to as executor.
Looking at the project directory, I found a similar folder.
There are two more inside, and frameless and springboot appear inside, so it is speculated that they are two versions or compilation methods.
I dare not continue to delve into it, as I don't understand it and it might become an endless loop. So let's go back to the beginning and take a look at the official documentation to see what information we can find to understand the software architecture.
Through the documentation, we can know that xxl-job is actually divided into two parts, similar to the client/server structure of Docker, or the middle platform/agent architecture. The scheduling center (default port 8080) is xxl-job-admin, and the executor (default port 9999) is the so-called executor. The executor receives commands issued by the scheduling center, executes them on the local machine, and returns the results. And there must be an identity verification to receive higher-level instructions to prevent abuse, and this verification is accessToken.
So now we have a general idea of the exploit process of the vulnerability, which is simply to construct a command request from the scheduling center to the executor. When accessToken is set to default, we can impersonate the executor as our Trojan horse. So what is the format of this request? Initially, I tried to trace it from the code level, but it became too complex to go deeper, so I changed direction and started from the internet. I searched for keywords: xxl-job executor rce, and found a vulnerability that was discovered a long time ago.
Clicking on it, it is the same component with the same problem. The one we have now is the default value, while that vulnerability is for an empty value. Looking at the time, someone has reproduced and analyzed it as early as 2022. So can we use their payload?
Obviously, the accessToken field is not mentioned in it, probably because if it is an empty value, there is no need to pass any parameters. But we got another piece of information, that data is transmitted between components through RESTful API, so the format of this field must also be in the documentation. Let's go back to the documentation and take a look.
Okay, now we can directly construct the request packet according to the documentation. (For the glueType field, there may be other types to explore, which may be beneficial for bypassing).
We can also directly use the fingerprint mentioned in the article, such as: shodan request, HttpMethod not support. That is, the body content is "invalid request, HttpMethod not support." For other domestic search engines, please construct it yourself.
Next, let's try a target.
Successfully execute the command and bring it out through DNS log.
If the default value is changed, it will be like this.
In summary, that's it. But sometimes you may find that the server's executor cannot be exploited. This is because of the client/server architecture, and the agent does not necessarily have to be on the same machine as the admin. Although this reduces the success rate of exploitation, it plays a certain role in lateral movement within the internal network.
One last Easter egg:
After the 2022 executor unauthorized vulnerability, the official took remedial measures and started using a default token. But they used a fixed value for hard coding. That is, this fix opened up a bypass for the executor. As the saying goes, is it really fixed? Who knows?
I don't know why such a simple vulnerability took a year to be discovered.
Final words: Although this time I did not analyze it from the perspective of code auditing, I pointed out another path, which is to make good use of internet searches and known vulnerabilities, which is often a shortcut.