Juniper’s NetScreen series of firewall and VPN devices have not one but two backdoor vulnerabilities, Juniper disclosed. One of these vulnerabilities is an authentication bypass for telnet or SSH logins to the firewall. The other is an encryption weakness that allows for eavesdropping on VPN traffic. Needless to say there has been a lot of discussion in the technicalpress, especially in light of the current political climate around encryption and back doors.
Patches are available to cover both vulnerabilities. Juniper notes that no other Juniper products, in particular JunOS based products, are affected by these vulnerabilities.
The Authentication Bypass
Unauthorized code added to ScreenOS 6.3.0r17 through 6.3.0r20 allows the use of a hardcoded password to authenticate any valid login ID via either telnet or SSH. The team at Rapid7 reverse engineered the patch code to discover the password which has been published.
Since the password is in the wild, you should patch any vulnerable devices ASAP, even if your organization is in an end-of-year change freeze.
Until you patch, other mitigations suggested by SANS include:
- If telnet is enabled disable it. This is a best practice anyway.
- Do not expose any administrative interfaces (telnet, SSH, HTTP(S)) on the external interfaces of the firewall. (Also a best practice).
- Consider changing ports and banners from the default
I’d also delete any default Netscreen accounts to force the attacker to guess what valid account to use.
The Encryption Weakness
This vulnerability affects ScreenOS 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20. It’s not clear exactly what the bug is, but speculation centers around Juniper’s use of the now-discredited Dual_EC_DRBG pseudo-random number generator (PRNG) in generating keys. Juniper apparently tried to work around the issue by using different curve points to seed the PRNG but the unpatched algorithm contained the means to leak session keys to the attacker, presumably by an unauthorized code change.
Note that exploitation of this weakness is really only possible for nation-state actors. It requires both the computing power to do the decryption and access to the raw internet feeds coming from the target, but you still need to fix it.
Whodunnit?
We really don’t know. Both vulnerabilities required access to the code base to make changes. The changes to authentication weren’t even particularly subtle, as evidenced by how quickly they were reverse-engineered by non-Juniper researchers armed only with the patches.
We do know that it is generally accepted (including by NIST) that the vulnerable PRNG started life in the NSA as a NOBUS (nobody but us) passive backdoor. We don’t know if this variation in ScreenOS came from the same source, or is a case of a “good guy” backdoor being exploited by another actor against the interests of those who originally created it. If so, then we are experiencing the risk that the crytpographic community have been warning about in opposing encryption backdoors, although this was likely no a simple exploit of the existing backdoor since it involved code modifications. But the presence of the original backdoor was a strong enabler.
It remains to be seen how these events affect the current political arguments over encryption.
Patches
ScreenOS 6.2.0r19 and 6.3.0r21 (and anything later) resolve both of these issues. For organizations that want to minimize the amount of code changed by the patch, Juniper has also created “b” releases of older versions of 6.3.0 that differ from the corresponding version only by fixing the two vulnerabilities. Those patches are 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. Apply those patches if you want to stay at the same firmware version but fix these two bugs.
A Final Word
We just want to reiterate that if you are running a vulnerable version of ScreenOS you should patch your systems without delay, and without waiting for your end-of-year freeze to end. Get an exception.
You should also lock down your environment as suggested above, to help mitigate the impact of future vulnerabilities in your network infrastructure.
[EDITED 12/21 to clarify the nature of the cryptographic vulnerability and the nature of the threat actors. Thanks to a friend in the crypto community for setting me straight.]