Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

Much ado about Juniper

Since this was published, more detailed information has become available: analysis of the SSH backdoor, the VPN backdoor, and the cryptography of the VPN backdoor. If you want a more detailed understanding of what was done, please take a moment to read these pages.

The news is tearing through the information security community – Juniper seems to be on the lips of everyone now, let’s take a quick look at the information available:

This morning, Juniper Networks announced an out-of-cycle update for their ScreenOS firewall operating system (not the newer Junos) to patch two unrelated issues (both identified as CVE-2015-7755):

  • Unauthorized remote administrative access
  • VPN traffic decryption

The meat of the announcement is this one paragraph:

During a recent internal code review, Juniper discovered unauthorized code in ScreenOS that could allow a knowledgeable attacker to gain administrative access to NetScreen® devices and to decrypt VPN connections. Once we identified these vulnerabilities, we launched an investigation into the matter, and worked to develop and issue patched releases for the latest versions of ScreenOS.

I added emphasis to the most important part: code that wasn’t authorized was first released in September 2012, and only now discovered.

They provided very limited technical information; there is some detail on the unauthorized remote administrative access – the log, if not altered, will reveal that the backdoor has been used, as it will log that system connected over SSH instead of an actual user name.

This is the kind of log entry that you would expect in the case of a backdoor that was intentionally hidden – it could easily be looked over, it doesn’t immediately stand out. When designing a backdoor, keeping it subtle is key.

The second issue, decryption of VPN traffic, has no useful information – other than an attacker needs the ability to monitor the encrypted VPN traffic. What this means is that it would only be useful to an attacker that was able to monitor networks – so it would be of most value to nation-state level attackers.

For both vulnerabilities, they state that a knowledgeable attacker could do this – to me, that smacks of NOBUS, or nobody but us, a key strategy for NSA and similar attackers. Attacks that require the knowledge of some secret that couldn’t be easily learned, allowing them to take advantage of it, while keeping risks of others exploiting it as low as possible.

Some are speculating that this could be FEEDTHROUGH:

In the case of Juniper, the name of this particular digital lock pick is “FEEDTROUGH.” This malware burrows into Juniper firewalls and makes it possible to smuggle other NSA programs into mainframe computers. Thanks to FEEDTROUGH, these implants can, by design, even survive “across reboots and software upgrades.” In this way, US government spies can secure themselves a permanent presence in computer networks. The catalog states that FEEDTROUGH “has been deployed on many target platforms.”


Is this FEEDTHROUGH? Is this a backdoor to make it easier to install FEEDTHROUGH (interdiction can’t be cheap)? It’s hard to say – as is the case with many of the ANT documents, there simply isn’t enough details to tell if they are connected.

My hope when the story broke was that it was debugging code that was inserted into a production release, or something of that nature – at this point I’m losing hope. It’s exactly what an intentional backdoor would look like. We shouldn’t speculate too much, but this doesn’t look good.

While writing this, Dan Goodin published his article on this – go read it.

Update: HD Moore posted a list of the modified strings; a change caught my eye, and was pointed out soon after HD posted it. In the version where the backdoors were introduced, a constant was changed:


This changed was reverted in the fixed version, making it clear that this plays some role in the backdoor – as researched progressed, it was suggested that it was a custom y coordinate, or perhaps a public key.

At this point, it appears to be Dual EC DRBG, which has a documented history of being vulnerable to backdooring – at this point, it seems that may be what happened here. The patch by Juniper didn’t remove Dual EC DRBG, but revert the change to it. This makes a lot of sense, as this is a NOBUS backdoor – it requires knowledge of a secret to be able to exploit, which fits with the description that Juniper provided.

Research is still ongoing.

Adam Caudill

Related Posts

  • Juniper, Backdoors, and Code Reviews

    Researchers are still working to understand the impact of the Juniper incident – the details of how the VPN traffic decryption backdoor are still not fully understood. That such devastating backdoors could make it in to such a security-critical product, and remain for years undetected has shocked many (and pushed many others deeper into their cynicism). There are though, some questions that are far more important in the long run:

  • Crypto Front Door: Everyone Welcome!

    For decades, the US Government has fought — sometimes with itself — to prevent the use of secure cryptography. During the first crypto war, they allowed strong cryptography within the US, but other countries were limited to small keys — making brute force attacks practical. But what about those pesky US citizens? They didn’t really want them to have strong crypto either — enter key escrow. What is key escrow? According to Wikipedia:

  • Verizon Hum Leaking Credentials

    or, Christmas Infosec Insanity… A friend mentioned Hum by Verizon, a product that I hadn’t heard of but quickly caught my attention – both from a “here’s a privacy nightmare” perspective, and “I might actually use that” perspective. While looking at the site, I decided to take a look at the source code for the shopping page – what I saw was rather unexpected. Near the top is a large block of JSON assigned to an otherwise unused variable named phpvars – included was some validation code, a number of URLs, some HTML, and the like.

  • The Door to Nowhere

    Today I was walking around, exploring the local downtown area, and I noticed a door. Or more accurately, what used to be a door, and the symbolism was too perfect to ignore. It’s a door to nowhere. A door once stood here, carefully built, thoughtfully placed, well crafted. Long ago someone decided that they didn’t want the door to exist anymore — so they filled it in. They made an attempt at reversing the decisions of the past to suit their desire at the moment — but they couldn’t.

  • Win by Building for Failure

    Systems fail; it doesn’t matter what the system is. Something will fail sooner or later. When you design a system, are you focused on the happy path, or are you building with the possibility of failure in mind? If you suffered a data breach tomorrow, what would the impact be? Does the system prevent loss by design, or does it just fall apart? Can you easily minimize loss and damage, or would an attacker have free rein once they get in?