Device42 Java Client Trusts Any SSL Certificate Due to Disabled Certificate Verification

[0xrehan]

Summary

The d42-java-client library disables TLS certificate validation by trusting all X.509 certificates and disabling hostname verification.

An attacker capable of performing a man-in-the-middle (MITM) attack can intercept HTTPS traffic between applications using this client and the Device42 API, potentially exposing sensitive information such as API credentials and Device42 data.

Affected Component

File:

src/main/java/com/device42/client/services/Device42ClientFactory.java

Affected version:

1.0.13

Vulnerable Code

The client creates an SSL context that trusts every certificate:

return new SSLContextBuilder()
    .loadTrustMaterial(null, new TrustStrategy() {
        public boolean isTrusted(
            X509Certificate[] x509Certificates,
            String authType
        ) throws CertificateException {
            return true;
        }
    }).build();

Additionally, hostname verification is disabled:

HostnameVerifier hostnameVerifier = NoopHostnameVerifier.INSTANCE;

and:

.setSSLHostnameVerifier(NoopHostnameVerifier.INSTANCE)

Impact

Because certificate validation and hostname verification are disabled:

• Self-signed certificates are accepted.
• Expired certificates are accepted.
• Certificates issued for different domains are accepted.
• A network attacker can impersonate the Device42 API endpoint.

The library also configures username/password authentication:

credentialsProvider.setCredentials(
    AuthScope.ANY,
    new UsernamePasswordCredentials(username, password)
);

Therefore, an attacker performing MITM can potentially capture:

• Device42 username/password credentials.
• API requests and responses.
• Infrastructure inventory information returned by the API.

Steps to Reproduce

1. Clone the repository:

git clone https://github.com/8x8/d42-java-client.git
cd d42-java-client

2. Review:

src/main/java/com/device42/client/services/Device42ClientFactory.java

3. Observe:

TrustStrategy.isTrusted() {
    return true;
}

and:

NoopHostnameVerifier.INSTANCE

4. Configure the client to connect to an HTTPS endpoint using a certificate that is:

   • self-signed, or
   • issued for another hostname.

5. The connection succeeds instead of failing certificate validation.

Security Impact Example

A user runs:

Device42ClientFactory.createDeviceClient(
    "https://device42.example.com",
    "username",
    "password"
);

While on a compromised network, an attacker presents a fake certificate for the endpoint.

Normally Java TLS validation would reject this connection.

However, because this library accepts any certificate and skips hostname verification, the connection succeeds and sensitive credentials/data may be exposed.

Recommended Fix

Remove the custom trust-all SSL configuration.

Use the default JVM trust store:

SSLContext sslContext = SSLContexts.createSystemDefault();

Remove:

NoopHostnameVerifier.INSTANCE

and use the default hostname verifier.

Only allow custom certificates through an explicit, documented configuration option rather than disabling validation globally.

CWE Classification

• CWE-295: Improper Certificate Validation
• CWE-297: Improper Validation of Certificate with Host Mismatch

Severity

High

The vulnerability affects all applications using this client library because TLS security protections are disabled by default.