Security experts have been analyzing the Juniper Networks firewall backdoors whose existence was brought to light last week, and they’ve discovered what appears to be the root cause for both the administrative access and VPN decryption issues.
Networking and security company Juniper Networks revealed last week that it had identified unauthorized code in ScreenOS, the operating system powering the company’s NetScreen firewalls.
The unauthorized code introduces two vulnerabilities: one that can be exploited to gain administrative access to NetScreen devices (CVE-2015-7755), and one that can be leveraged by a “knowledgeable attacker” who can monitor VPN traffic to decrypt VPN connections (CVE-2015-7756).
Juniper initially believed both vulnerabilities affect ScreenOS versions 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20. However, the company later determined that the administrative access flaw only impacts ScreenOS 6.3.0r17 through 6.3.0r20.
The security holes have been patched with the release of ScreenOS 6.2.0r19 and 6.3.0r21. The fixes are also included in versions 6.3.0r12b, 6.3.0r13b, 6.3.0r14b, 6.3.0r15b, 6.3.0r16b, 6.3.0r17b, 6.3.0r18b and 6.3.0r19b.
Authentication Backdoor
The vulnerabilities have been analyzed by several external researchers. Fox-IT experts said it took them just 6 hours to find the password for the ScreenOS authentication backdoor.
After analyzing the differences between the vulnerable and patched versions of ScreenOS, Rapid7’s HD Moore determined that the authentication backdoor, which can be exploited via SSH or Telnet, involves the default password <<< %s(un=’%s’) = %u.
This backdoor password, which was presumably set this way so that it would be mistaken for one of the many debug format strings present in the code, can be leveraged by an attacker who knows a valid username for the device.
On one hand, it’s difficult to say if this vulnerability has been exploited in the wild since even though an unauthorized access attempt would normally be logged, it’s easy for an attacker to delete the relevant log entries. However, as Moore has highlighted, the logs might be sent to a centralized server, which could result in an alert being triggered.
“If you want to test this issue by hand, telnet or ssh to a Netscreen device, specify a valid username, and the backdoor password. If the device is vulnerable, you should receive an interactive shell with the highest privileges,” Moore explained.
The researcher has pointed out that roughly 26,000 NetScreen devices are open to the Internet via SSH, according to a Shodan search.
VPN Decryption Vulnerability
Google security engineer Adam Langley has published a blog post summarizing the findings of various experts regarding the VPN decryption issue.
The problem could be related to the fact that ScreenOS uses the Dual Elliptic Curve Deterministic Random Bit Generator (Dual EC DRBG) as a pseudo-random number generator (PRNG). Dual EC DRBG came in the spotlight in late 2013 when reports surfaced that the U.S. National Security Agency created a backdoor in the encryption algorithm and then allegedly paid RSA $10 million to get the company to use it by default in one of its toolkits.
“If an attacker can predict the output of the PRNG then they can know the keys that one or both sides of a VPN connection will choose and decrypt it,” Langley explained.
Juniper Networks has admitted using the Dual EC DRBG standard in ScreenOS, but the company claims it hasn’t been used as the primary RNG and it doesn’t use the pre-defined points cited by NIST, which means that it should not be vulnerable.
“In short, they used a backdoored RNG but changed the locks. Then this attack might be explained by saying that someone broke in and changed the locks again,” Langley noted. “We’re not sure that’s actually what happened, but it seems like a reasonable hypothesis at this point. If it’s correct, this is fairly bananas. Dual-EC is not a reasonable RNG: it’s massively larger, slower and more complex than standard RNGs. It’s output isn’t even very uniform.”
Attribution
In December 2013, German news magazine Der Spiegel reported obtaining a document describing tools used by the NSA to compromise routers, servers and firewalls from various vendors, including Juniper’s NetScreen firewalls. This resulted in speculation that the NSA might be behind the backdoor.
Initially, it appeared that the code for both the authentication backdoor and the VPN decryption issues was introduced sometime in 2012. However, since it has been clarified that the authentication bypass flaw only affects ScreenOS 6.3.0r17 through 6.3.0r20, Moore believes the administrative access backdoor was only introduced sometime in late 2013.
“Assuming [the Dual-EC] hypothesis is correct then, if it wasn’t the NSA who did this, we have a case where a US government backdoor effort (Dual-EC) laid the groundwork for someone else to attack US interests. Certainly this attack would be a lot easier given the presence of a backdoor-friendly RNG already in place,” Langley said.
Juniper Networks has not commented on these allegations.
