Product Affected

This issue can affect all SRX Series Service Gateways for the Branch, as well as the LN1000 Mobile Secure Router, relying on self-signed certificates, running software prior to the releases listed in the Solution section below.
Low
4.0 (AV:L/AC:H/Au:N/C:C/I:N/A:N)

Problem


Research has shown that when initial RSA certificates are generated immediately after an SRX Series Service Gateway for the Branch or LN1000 is first activated, running a release earlier than Junos 10.4R4, there exists an increased probability of the RSA certificate's public/private key pairs being duplicated on multiple devices. RSA certificates are used by J-Web. Public/private key-pairs used by SSH may also be affected by duplicate key-pair generation. This key strength weakness may make it easier for an attacker to launch a successful Man-In-The-Middle (MITM) attack.

SRX Series Service Gateways for the Branch include: SRX100, SRX110, SRX210, SRX220, SRX240, SRX550, SRX650. The LN1000 Mobile Secure Router is also affected.

A MITM attack is a form of active eavesdropping in which the attacker injects themselves between the victim and the secure endpoint (by exploiting unauthorized access to a transit device or medium) and relays messages, making the victim believe that they are talking directly to the requested resource, when in fact the entire conversation can be viewed and/or controlled by the attacker. When utilizing encryption, the MITM actor would normally be unable to decrypt the conversation, but in the case of weak key generation, the ability to predictably generate the private parts of an SSL certificate or SSH key allows for decryption of an otherwise private conversation.

Customers deploying J-Web using SSL certificates signed by an official certificate authority (CA) are not vulnerable to this issue, since the duplication only affects self-signed certificates.

Juniper SIRT is not aware of any malicious exploitation of this particular vulnerability.

No other Juniper Networks products or platforms are affected by this issue. A similar issue affecting other Junos platforms is described in PSN-2010-04-712.

Solution


The weakness in key generation, which can lead to the creation of duplicate keys on multiple devices, was due to a lack of entropy (randomness) in the initial certificate creation process on Branch SRX devices.

All Junos OS software releases built on or after 2011-07-28 have resolved the issue of limited entropy. Releases containing the fix specifically include: 10.4R4, 11.1R2, 11.2R1, and all subsequent releases (i.e. all releases built after 11.2R1).

After upgrading to a release containing the fix, it is still necessary to regenerate all self-signed SSL certificates and SSH public/private keys. Refer to the Workarounds section below for instructions on regenerating strong RSA certificates.

This issue is being tracked as PR 585830 and is visible on the Customer Support website.

KB16765 [juniper.net] - "In which releases are vulnerabilities fixed?" describes which release vulnerabilities are fixed as per our End of Engineering and End of Life support policies.



How to obtain fixed software:

Security vulnerabilities in Junos are fixed in the next available Maintenance Release of each supported Junos version. In some cases, a Maintenance Release is not planned to be available in an appropriate time-frame. For these cases, Service Releases are made available in order to be more timely. Security Advisory and Security Notices will indicate which Maintenance and Service Releases contain fixes for the issues described. Upon request to JTAC, customers will be provided download instructions for a Service Release. Although Juniper does not provide formal Release Note documentation for a Service Release, a list of "PRs fixed" can be provided on request.

Workaround


The most effective way to avoid weak certificate generation is to upgrade to a release listed above, and regenerate all self-signed certificates and SSH keys. The root cause of the weak certificate generation is due to a lack of entropy. Devices running for an extended period of time have built up additional entropy to ensure that stronger keys are generated in newly created certificates. While upgrading to later versions of Junos OS is still strongly recommended, a temporary, interim solution may be followed to regenerate stronger keys on releases affected by lack of initial entropy.

This process must also be followed after upgrading to a release containing the fix listed above.

Note: Insure that the device has at least one active network interface. Prior to the fix for this issue, network activity over time is crucial for obtaining sufficient entropy.

To replace the self-signed RSA certificate used by J-Web:
  1. Log into the device as the root user and start the command-line interface: 
    % cli
root@junos>
  2. Replace the self-signed certificate: 
    root@junos> clear security pki local-certificate system-generated
  3. This will erase the existing certificate and immediately generate a new one.

To replace the RSA and DSA public keys used by SSH:
  1. Log into the device as the root user via a direct serial connection. Connection via SSH will also work, but could be a problem if you lose your connection to the box before the new keys are regenerated during the process.

  2. Erase the existing SSH host RSA and DSA public keys: 
    % rm /etc/ssh/ssh_host*
  3. Start the command-line interface and enter config mode: 
    % cli
root@junos> config
root@junos#
  4. Deactivate the existing SSH configuration and commit the config: 
    root@junos# deactivate system services ssh
root@junos# commit
  5. Reactivate the SSH configuration, commit and quit: 
    root@junos# activate system services ssh
root@junos# commit and-quit
root@junos>
  6. SSH client software typically retains the public keys of the devices to which it connects. To avoid a warning message from the SSH client that the remote peer public key has changed, delete the cached version of the public key from the SSH client software prior to connecting to the device in the future.

Security Best Common Practices
In addition to the recommendations listed above, it is good security practice to limit the exploitable attack surface of critical infrastructure networking equipment. Use access lists or firewall filters to limit access to the router via J-Web and/or SSH only from trusted, administrative networks or hosts.

There are also well documented limitations to the security provided by self-signed certificates. 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.

Instructions on generating and installing externally signed SSL certificates are available in the Junos documentation. See the Related Links section for more information.

Severity Assessment

Information for 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