Product Affected

All NSM products are affected by this issue if they are running an affected version of NSM software, versions 2007.3 through to the current version.
Critical
10 (AV:N/AC:L/Au:N/C:C/I:C/A:C/E:H/RL:U/RC:C)

Problem

Certain versions of NSM products are supplied with a default self-signed certificate containing both public and private components. The certificate is identical across multiple installations of the product and software releases. In later versions, the key pair is used to encrypt TLS traffic between NSM client and NSM server, and thus the knowledge of the key pair can make it possible for an attacker to decrypt the traffic between the client and server if the attacker has access to the encrypted traffic. The decrypted traffic may include the user name and password for the administrative account, thus possibly leading to a complete compromise of the victim's NSM product.

Juniper Networks began including self-signed certificates, by default, in NSM software with version 2007.3. Through version 2008.1, the certificate was only used for instantiation of a local proxy web server and the same certificate was distributed with all copies of the software distribution. Beginning with version 2008.2, NSM uses TLS with the installed certificate to protect the administrative connection between client and server. If the certificate has not been replaced by the customer, then the TLS traffic is protected with the same self-signed certificate provided by default to all other customers using the same version of NSM software. All subsequent releases of NSM software contain self-signed certificates and, if they have not been replaced, they are used with TLS to protect sensitive administrative traffic between NSM client and NSM server.

Solution

There is no fixed software for this issue. The threat can be completely mitigated by replacing the default self-signed certificates provided by Juniper Networks with:

  • certificates which the customer has purchased from a Certificate Authority, or
  • self-signed certificates which the customer can generate using scripts provided by Juniper Networks as described below in this document.

This issue is being tracked in PR 461557. Although customers cannot view that PR, it can be used as a unique identifier to refer to this specific issue when discussing it with JTAC.

"Self-Signed Certificate" Is a Misunderstood Term

The issue is complicated by widespread misunderstanding regarding the term "self-signed certificate". A self-signed certificate means only that the certificate is signed by the same entity that generated the certificate, essentially a "circular trust". In particular, a self-signed certificate is not provided by a well-known Certificate Authority, and thus it lacks the industry-wide trust hierarchy standing behind commercially-provided certificates. Unless signed by other entities, a self-signed certificate is authenticated only by itself; there is no transitive trust that can be applied. The self-signed certificates provided in NSM are only signed by Juniper Networks and do not have any additional signatures from other entities. The additional fact that the certificates in question are self-signed by "Juniper Networks" may have inadvertently made them appear as though they were generated by a Certificate Authority; that is not the case, the certificates are self-signed with no additional web of trust standing behind them.

Self-signed certificates are appropriate and valid if used for the original, intended purpose in NSM: to bootstrap the initial provisioning and deployment of the product. However, the NSM software does not have any supported mechanism to prevent a customer from continuing to use the default self-signed certificate after the initial set-up. The self-signed certificates provided in the NSM software distributions should not continue to be used in the day-to-day operation of production networks. Customers are strongly urged to replace the certificates as soon as possible.

The issue can be resolved by replacing the self-signed certificate provided in the NSM software distribution, preferably with a commercially-provided certificate from a recognized, established Certificate Authority.

If that is not feasible or practical, a self-signed certificate signed by the customer can be generated by following the instructions in KB 14949 [juniper.net] and installing it in place of the default Juniper Networks self-signed certificate. Please refer to the Related Links section below for additional KB articles regarding this topic.

Severity Assessment

Self-signed certificates were introduced with NSM release 2007.3. The certificate was only used for set-up and configuration functions in versions from 2007.3 to 2008.1, inclusive. In version 2008.2, NSM began using TLS with the installed certificate to protect the administrative connection between client and server. The private key component of the default self-signed certificate provided by Juniper Networks can be used to decrypt the TLS traffic of another customer who is using the same self-signed certificate, revealing the username and password for the administrator's login (assuming the unauthorized user has access to the administrative traffic).


Information regarding how Juniper Networks uses CVSS can be found at KB 16446 [juniper.net] "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories".

Related Information