Bug in Juniper Software Enabled Severe IPSec Vulnerability
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

Bug in Juniper Software Enabled Severe IPSec Vulnerability

Major vulnerability will hopefully have small impact on internet security.

A major bug in Juniper Networks’ Junos OS was fixed this week in a new patch released by the company. In the IKE/IPSec protocols, the software’s implementation of certificate validation, a key part of how X.509 certificates provide a secure connection, did not work properly. Juniper Networks is one of the largest manufacturers of network and internet infrastructure devices.

In the release of their patch, Juniper wrote that “Junos incorrectly validated self-signed certificates when the ‘issuer name [matched] one of the valid CA certificates enrolled in Junos.’” This means the software was only looking at the name of a certificate when determining its legitimacy.

Luckily, the bug only affects “certificates used for IKE/IPSec,” which is just one of the many protocols that use security certificates for encryption and authentication. Juniper stated that, “other public key-based authentication is unaffected by this vulnerability,” so the widely used SSL/TLS protocols were not at risk from this vulnerability.

In order to provide authentication, one of the core purposes of the X.509 certificate standard, there needs to be cryptographic validation of the certificate being used. This proper way to do this is for the client device to check the digital signature of the certificate, and locally compute it to make sure that there is a match with the issuing Root CA.

When that process is done correctly, the client device can prove if the certificate being presented was really signed by the trusted Root CA, or if the certificate is a forgery. Junos’ code did not do this. Instead, it skipped all the mathematics, and just looked to see if the issuer name matched any of the Root CAs.

Junos’ process involves no cryptographic proofs and provides no security. Using the bug, an attacker could simply create their own certificate with an Issuer name matching a trusted Root and have Junos trust it. They could then use the certificate to impersonate any server and receive sensitive information. It’s equivalent to a store accepting a piece of paper that someone wrote “$20 Bill” on with a pen.

To say this was a mistake is an understatement. Hanno Böck, a cyber security journalist, said “[the code] was implemented by people who had no idea what they were doing.”

Juniper says they have no knowledge that this vulnerability has actually been exploited, and no other evidence has suggested it has. If this vulnerability has been used it would make it extremely easy for malicious actors to undermine the security of IKE/IPSec connections being made with Junos.

The affected protocols are not very popular – they are primarily used in securing VPN connections, though most VPNs opt for other protocols for security. IPSec’s lack of popularity is likely a contributing factor to the bug, as it would be under far less scrutiny from code-auditing projects and researchers.

Juniper’s problems also made headlines late last year when a backdoor was discovered in the code used in another one of their operating systems. The backdoor had been present for years and was part of the code for a random number generator, one of the tools used in establishing secure connections. This backdoor allowed for the decryption of those connections, particularly VPN connections where the software was frequently used. It is not known how that backdoor appeared in their software, but some suspect it may have been done under the influence or supervision of a government.