Juniper Networks issued an out-of-cycle security advisory on Thursday night (Juniper KB CVE-2015-7755 / CVE-2015-7756 advisory) disclosing what they describe as unauthorised code in ScreenOS, the operating system on their NetScreen firewall product line. Two distinct issues are documented. CVE-2015-7755 is a hardcoded administrative password — present in the binary, allowing remote SSH or telnet access as any user on affected versions, including in the Web UI and the management CLI. CVE-2015-7756 is, in Juniper's wording, an issue that "could allow a knowledgeable attacker who can monitor VPN traffic to decrypt that traffic."
The first issue is straightforward to describe and uncomfortable to think about. There is a string in the ScreenOS binaries — <<< %s(un='%s') = %u — that, if entered as the password against any valid username, authenticates the session. Rapid7 published the password within twenty-four hours of the advisory (Rapid7 community blog). The string was present in ScreenOS releases from late 2012 through mid-2015. Anybody who knew the string had administrative access to any affected NetScreen device they could reach over the network. That is a critical-severity backdoor.
The second issue is, technically, more interesting and politically more freighted. The VPN decryption issue traces, on the analysis being published over the weekend by Stephen Checkoway, Hovav Shacham, Matthew Green, Eric Rescorla, and several others (Checkoway et al, "A Systematic Analysis of the Juniper Dual EC Incident" — preprint forthcoming), to a manipulation of the constants in Juniper's implementation of Dual_EC_DRBG, the much-criticised pseudo-random number generator. Dual EC was the algorithm whose NIST standardisation was alleged in the September 2013 Snowden disclosures to have been backdoored (Checkoway et al on Dual EC, 2014). The Juniper case appears to be: ScreenOS used Dual_EC_DRBG as its random number generator, with a custom Q parameter that was different from the NIST-published value. The unauthorised code change replaced Juniper's custom Q with a different attacker-chosen Q. Anyone in possession of the discrete-log-based "trapdoor" associated with the new Q could, with a few seconds of observed VPN session output, recover internal RNG state and from there decrypt the entire VPN session.
That is — and the analysts are being careful to say "appears to be" — a backdoor on top of a backdoor. The first backdoor was Dual EC itself, suspected of being NSA-controlled. The second was the unauthorised code change replacing the first backdoor's controlling constant with a different actor's constant. The political question is who that second actor is. Juniper has not said. The technical signature points at a sophisticated actor with knowledge both of Juniper's internal Dual EC parameterisation and of the specific cryptanalytic capability needed to choose a useful replacement Q. The candidate set is small.
For operational work this week, the immediate action is patching. Juniper has released ScreenOS 6.3.0r21 and earlier-version backports that remove both issues. The patch propagation needs to be at the top of the December operations queue for any customer running NetScreen. Several of our customers do — NetScreens are a long-tail enterprise firewall, still in many estates despite the SRX successor. The vCISO portfolio is mostly clean — Browne Jacobson and Towry are on Cisco, Northcott is on a Palo Alto core — but I have one mid-size pen-testing client with a NetScreen-50 in their DMZ that is being patched tonight, and another with a pair of NetScreen-208s in HA that need a maintenance window planned for Monday morning. The Christmas-patch-lull timing is operationally awkward. That is, presumably, why Juniper disclosed when they did rather than holding to a January cycle — the alternative would have been four more weeks of vulnerable estates against a now-public backdoor.
The structural commentary, for the longer write-up I will eventually do on this. The Juniper story is the most operationally significant single piece of evidence for the proposition that supply-chain integrity in security products is, as a matter of structural reality in 2015, not assured. Juniper is a major US vendor with a substantial security and compliance posture; their ScreenOS product is in tens of thousands of enterprise estates and many government and military environments worldwide; their development pipeline — code review, build infrastructure, release signing — is presumably as good as any large vendor's. The unauthorised code change made it through that pipeline and shipped, in production releases, for two and a half years. It was caught, on Juniper's disclosure account, by an internal code review that they began for unrelated reasons. The discovery was, by the company's own framing, not the result of a robust process; it was the result of someone deciding to look. That is not a defensive posture. It is a near-miss.
The implication for vCISO programme work is that the supply-chain assumption that has historically underpinned firewall and VPN selection — that the code in the box does what the manufacturer says it does — needs to be supplemented with operational controls that are independent of the manufacturer's integrity. Network segmentation that does not rely on the firewall being honest. VPN concentrator deployment that includes traffic-meta monitoring against expected patterns. Periodic firmware integrity checks against a known-good golden hash. None of these are easy and most are imperfect. But the "trust the vendor" architecture is no longer defensible as a complete answer.
I will be writing more about this in January when the cryptographic analysis of the Dual EC parameter substitution has been peer-reviewed. The first task this week is patching, the second is reviewing every customer's firewall fleet for any other code provenance concerns, and the third is drafting the board briefing for the January Browne Jacobson meeting on what supply-chain risk in security-vendor products looks like from inside an actual incident.