Knowledge Search


×
 

Juniper Security Notice: Juniper Networks' Self-Signed Certificates Are Not For Operational Use

  [JSA10495] Show Article Properties


Legacy Advisory Id:
PSN-2011-11-419
Product Affected:
This issue affects devices and releases which are provided with default self-signed certificates generated by Juniper Networks.
Problem:

NSM software distributions contain a default self-signed certificate, generated in advance by Juniper Networks, which is needed for initial configuration and deployment of the product. While investigating reported vulnerabilities (unrelated to the specific issue described in this security notice), the Juniper Networks Security Incident Response Team (Juniper SIRT) has detected an alarming, recent increase in the number of customers placing their systems at risk by continuing to use the default Juniper Networks self-signed certificates beyond the initial bootstrap/deployment time period.

The certificate is identical in all copies of the same version of the software distribution, and both key parts, public and private, are included, making it possible for an attacker to mount a variety of successful compromises against systems continuing to use the default self-signed certificate in production. For example, an attacker with access to the data path between NSM server and client would be able to use a variety of off-the-shelf tools with the default certificate to extract a complete, unencrypted packet trace of the management connection. Depending on circumstances, an attacker could masquerade as the NSM server, exchanging information with an unaware NSM client and possibly modifying instructions and replies between the legitimate NSM server and client. This practice is equivalent to using a vendor-supplied default username/password for the administrator account in a production environment: When a username/password pair is available to the public, anyone can log in without authorization and gain control of the system. A similar risk exists for operational use of a vendor-supplied, default, self-signed certificate.

It is critically important for customers to replace the Juniper-provided self-signed certificate as soon as possible after initial configuration. Ideally, customers should obtain a signed certificate from a well-known, established Certificate Authority (CA) and install it in place of the Juniper-provided certificate. In lieu of that, customers can replace the certificate with another certificate generated and signed by the customer. Instructions are available for generating, installing, and managing self-signed certificates on various Juniper Networks products, as cited below. Please note that although this notice focuses on NSM and Juniper's network management solutions, the issue may apply to other Juniper products to varying degrees, now or in the future.

With regard to NSM specifically, the Juniper SIRT has previously published a security advisory on this same topic, PSN-2010-05-761, in May 2010.
Solution:

There is no fixed software for this issue; the product is functioning correctly as designed.

A "public-key certificate" provides a guarantee for the association between an entity's identity and the entity's public key. For example, the server's certificate provides some assurance to the client that the client is communicating with the server using the server's legitimate public key. Certificates are signed to increase assurance by showing that the relationship between identity and the key has been verified and to provide a means to determine that the certificate has not been corrupted or subverted. A "self-signed certificate" has been signed only by the same entity which generated it. A third-party "Certificate Authority" (CA) can be employed to sign the certificate, providing much stronger assurance to prove the association between the entity and its public key.

Purchasing and installing a certificate from a well-known (or well-trusted) commercial CA is the preferred solution. If obtaining a certificate from a commercial CA is not feasible or practical, it may be possible to obtain a certificate from a non-commercial CA, perhaps operated elsewhere within the customer's organization. A self-signed certificate is adequate but is the least secure solution. If a self-signed certificate must be used, it is essential that it be generated and installed by the customer. In all cases, a certificate should be protected in the same way as a username/password pair: the private key can be used to regenerate the certificate, masquerade as the legitimate server, or subvert the system in general, so the private key must be kept confidential. For example, if a certificate must be installed remotely, then a password-safe connection such as Secure Shell (SSH) should be used to transfer the certificate to the server.

Workaround:


Replacing the Juniper-supplied self-signed certificate on NSM and NSMXpress is explained in KB 14949, "How to Create Self-Signed TLS Certificate between NSM Client and NSM Server": http://kb.juniper.net/KB14949

Instructions for replacing self-signed certificates for other Juniper Networks products are available by searching Juniper's Customer Support web for "self-signed cert".
Implementation:

There is no fixed software for this issue; the product is functioning correctly as designed.
Related Links:
CVSS Score:
10 (AV:N/AC:L/Au:N/C:C/I:C/A:C/E:H/RL:U/RC:C)
Severity Level:
High
Severity Assessment:
Information regarding how Juniper Networks uses CVSS can be found at KB 16446 "Common Vulnerability Scoring System (CVSS) and Juniper's Security Advisories".