In September 2022, a dangerous vulnerability was disclosed in the Jenkins NS-ND Integration Performance Publisher Plugin, tracked as CVE-2022-38666. Jenkins is one of the most popular automation servers, widely used for building, testing, and deploying software. The NS-ND plugin, up to version 4.8..146 and earlier, was found disabling SSL/TLS certificate and hostname validation for some key plugin features. This opens the door to man-in-the-middle (MITM) attacks, allowing attackers to intercept, modify, or steal confidential data.

The Root Problem

SSL/TLS (Secure Sockets Layer/Transport Layer Security) certificates are the backbone of secure network communication. They authenticate servers and encrypt data, making sure your information gets to the right place. If a program disables certificate and hostname validation, it has no way to tell if it is really connecting to the intended server. This means attackers can easily impersonate servers or intercept sensitive data.

Vulnerable Features

The plugin disables SSL/TLS certificate and hostname verification for several of its integration features, which can impact anyone using affected versions.

Looking at the Code

Jenkins plugins are written in Java. SSL validation in Java is handled with classes like javax.net.ssl.TrustManager and HostnameVerifier. A bad practice is overriding them to accept any certificate.

Here's a typical anti-pattern that's highly similar to what happened in the plugin

TrustManager[] trustAllCerts = new TrustManager[] {
    new X509TrustManager() {
        public java.security.cert.X509Certificate[] getAcceptedIssuers() { return null; }
        public void checkClientTrusted(X509Certificate[] certs, String authType) { }
        public void checkServerTrusted(X509Certificate[] certs, String authType) { }
    }
};

SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());

// Disable hostname verification
HostnameVerifier allHostsValid = (hostname, session) -> true;
HttpsURLConnection.setDefaultHostnameVerifier(allHostsValid);

By using the above code, any certificate is accepted, and any hostname is trusted. That's exactly what you DON'T want!

How an Attacker Exploits the Flaw

Let’s say you have Jenkins using this plugin to fetch test results from a remote server. If the connection doesn’t check certificates:

`

3. Direct Jenkins/Plugin's remote server address to attacker IP (using DNS spoofing or ARP poisoning).

The plugin will accept the forged cert, exposing all communications.

Note: This is for educational/demonstration purposes only. Never try this without permission.

Remediation and Secure Practices

The Fix:  
The plugin maintainers pushed a fix where SSL/TLS validation is no longer bypassed. Certificates and hostnames are properly validated in all communications.

Official Jenkins Plugin site:

https://plugins.jenkins.io/performance

- Jenkins Security Advisory: CVE-2022-38666
- Jenkins Plugin: Performance Publisher
- NVD Entry: CVE-2022-38666
- Jenkins Plugins Update Guide

Official Mitigation Details:  
> The plugin now verifies the server certificate when establishing an HTTPS connection, protecting users from man-in-the-middle attacks.

Conclusion

CVE-2022-38666 serves as a strong reminder:  
Disabling SSL/TLS certificate and hostname validation is never acceptable, even for convenience. The Jenkins NS-ND Integration Performance Publisher Plugin was dangerously exposed until version 4.8..146. All users should upgrade and review their code for similar weak spots.

Timeline

Published on: 11/15/2022 20:15:00 UTC
Last modified on: 11/18/2022 21:28:00 UTC