Juniper Network’s fateful December 2015 security bulletin (CVE-2015-7755, CVE-2015-7756) verified a threat IT security professionals have been concerned about for a while now. That of unauthorized code or components designed to sidestep security somehow being planted in networking products used in their data centers.

As to what the announcement means, Juniper Networks Derrick Scholl writes, “At this time, we have not received any reports of these vulnerabilities being exploited; however, we strongly recommend that customers update their systems and apply the patched releases with the highest priority.”

One has to wonder though as the security bulletin clearly states, “There is no way to detect that this vulnerability was exploited.”

Made matters worse

To Juniper Network’s credit, they reacted quickly by issuing corrective updates. However, the announcement and issued fixes afford the bad guys a real opportunity. First, anyone not privy to the backdoors now knows about them. Second, the fixes are road maps. Ronald Prins, CTO of the Dutch security company Fox-IT told Wired’s Kim Zetter, “Once you know there is a backdoor there, … the patch [Juniper released] gives away where to look for [the backdoor] … which you can use to log into every [Juniper] device using the Screen OS software.”

And historically speaking, more than a few Juniper Network’s devices will remain unpatched.

Captured encrypted data

Prins raises another concern. In this age of big data, it is not unreasonable to assume that nefarious types interested in a target “long-term” may have been capturing encrypted traffic, hoping for a break similar to what just happened with Juniper Networks gear. He tells Zetter, “If other state actors are intercepting VPN traffic from those VPN devices, … they will be able to go back in history and decrypt this kind of traffic,”

Other vendors

If anything, what happened to Juniper Networks has other networking manufacturers looking at their code. Anthony Grieco, senior director of Cisco’s security and trust organization, affirms that Cisco has a “no backdoor” policy. However, Grieco adds,

“Cisco launched a review because the trust of our customers is paramount. We have not been contacted by law enforcement about Juniper’s bulletin, and our review is not in response to any outside request. We are doing this because it’s the right thing to do.”

Fortinet engineers and quality assurance team members also reviewed their networking products. In so doing, they discovered a potential vulnerability. A Fortinet spokesperson mentions, “The vulnerability was designed with the intent of providing seamless access from an authorized FortiManager to registered FortiGate devices. It is important to note, this is not a case of a malicious backdoor implemented to grant unauthorized user access.”

That said, Dan Goodin of ArsTechnica mentions, “At this point, it’s too early to definitively identify the suspect routine as a backdoor that was planted for the purpose of providing unauthorized access. Still, there’s little doubt the code had precisely that effect.”

Any options?

As to what can be done, the experts have a few ideas as to what should help minimize any damage from backdoors. Information Security Architect John D. Swanson, not trying to sound trite by stating the obvious, suggests adhering to good patch management and code update practices. “Staff should regularly be monitoring or automatically alerted to security advisories and code updates issued by critical infrastructure vendors,” says Swanson. “In the event of critical vulnerabilities allowing remote code execution or unauthorized access, staff should schedule and perform updates as soon as feasible once updated code is available.”

Swanson advises there a number of preventative things that can be done rather than waiting for or completely relying on the vendor’s patch to fix the problem, suggesting, “Critical infrastructure such as firewalls and switching needs to be appropriately hardened following vendor best practices. Hardening guides designed to assist with this can usually be found in vendor documentation.”

This typically includes:

• Disabling unnecessary services.
• Using strong passwords and removing or disabling built-in administrative accounts.
• Enabling strong encryption for administrative connections and VPN services.
• Using more secure monitoring protocols (SNMPv3 instead of SNMPv1).
• Ensuring valid SSL certificates are used where applicable.

Then Swanson talks about security from a network perspective. Management access should be via SSL secured web or SSH only (Telnet should be disabled) and should be on dedicated out-of-band management interfaces in secure, isolated networks only, not on interfaces accessible to the public or other internal users or devices. “Additionally, most infrastructure will allow access restrictions to be set, allowing administrative access only from certain networks or IP addresses,” adds Swanson.” This feature should be used to allow only authorized administrators on trusted networks access to the devices.”

Something else data center operators can implement if they have not already is monitoring and auditing of critical infrastructure for signs of unauthorized or anomalous access. “If SIEM (Security information and event management) or other log management tools are available and support alerting, they should be configured to notify staff if unexpected login activity is detected,” says Swanson. “While this is not a preventative measure, detecting unauthorized access early and responding swiftly is key to reducing the impact of an intrusion.”

Chain of custody

Organizations need to hold their vendors accountable for secure coding practices. If they cannot be part of the evaluation and procurement process for new hardware, might it not be a good idea to ask for a verifiable chain of custody document similar to what is applied to evidence used in courts? Swanson says to pay attention to the following:

• Are code reviews regularly performed during both initial development and the supported lifetime of the code?
• Is the code vetted or audited by a trusted third party?
• Are modern cryptographic standards with strong and secure number generation used by the hardware?

More to consider

As to how the code got installed in the Juniper equipment, obviously, someone put it there. But, as to who, that is anyone’s guess. One thing it seems is that Jupiter Network’s code change and version control needs to be reevaluated. Good change and version control practices would have caught this sort of unauthorized code modification almost immediately.

One more thing, securing data once it leaves an organization becomes a lot more difficult. In a sense, the Juniper VPN decryption backdoor is the worst type of vulnerability. Data center operators might adhere to every best practice there is within their organizations and still be vulnerable when the traffic leaves the building.

“It’s always a good practice to secure communications starting at the application,” mentions Swanson. “One should not rely on a VPN as the only layer of encryption unless forced to do so. Any traffic that is already tunneled or encrypted via SSH, SSL, or other methods before passing through the IPSEC VPN will not be fully decrypted as a result of this or similar vulnerabilities.”

As an example, a common use for this type of VPN is to protect traffic bound for off-site backup locations. Many enterprise backup solutions, however, offer the ability to encrypt backups before they go over the wire. This layered approach to encryption is just another example of defense in depth at work and should provide protection from VPN decryption attacks.

No for-sure answer

While no organization can completely prevent something like the Juniper VPN decryption issue, many of the practices outlined above will help reduce the overall attack surface of critical infrastructure and thereby reduce the likelihood of successful hardware compromise. These measures will also help limit the scope of any compromise and potentially reduce response time to that compromise.