Juniper Reveals 'Unauthorized Code' That Decrypts VPN Connections
from the let-the-speculation-begin dept
Well, well, well. Yesterday morning, Juniper Networks announced that it had discovered some “unauthorized code” in its ScreenOS that would allow “knowledgeable” attackers to decrypt VPN traffic on Juniper’s NetScreen devices:
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.
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.
Not surprisingly, speculation is running rampant concerning how this happened. Since this isn’t just using some sort of zero day exploit, but rather “unauthorized code” — it’s pretty clear this isn’t just some random security folks having fun. The most obvious possibilities here are nation-state level actors — with a lot of finger pointing in the NSA’s general direction. I would imagine, whether or not it’s the NSA, there was a lot of freaking out at Ft. Meade yesterday as this came out. Either their own handiwork was exposed… or their own failure.
You may recall that, almost exactly two years ago the German newspaper Der Spiegel had a fairly revealing article about the NSA’s Tailored Access Operations (TAO) unit, that focused on figuring out how to get into basically any computer or network. The article also discussed another group, Advanced or Access Network Technology (ANT) which focused on creating exploits in equipment. In the accompanying article about the “catalog” that ANT produces for the NSA to “purchase” exploits, it discusses targeting Juniper equipment:
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.”
Of course, if the code is already directly in the OS, that explains why the code can “survive ‘across reboots and software upgrades’.” In other words, while the original article suspected malware, perhaps the malware was already in the OS itself.
And, remember, this is the same government/NSA that now wants tech companies to share even more information with it via CISA…
Filed Under: decryption, encryption, feedthrough, network, nsa, screenos, surveillance, unauthorized code, vpn
Companies: juniper, juniper networks
Comments on “Juniper Reveals 'Unauthorized Code' That Decrypts VPN Connections”
'Better to ask forgiveness than permission'
And, remember, this is the same government/NSA that now wants tech companies to share even more information with it via CISA…
Assuming it was the NSA responsible, I can’t see how you could fault them for trying to be helpful. I mean really, both they and various companies know that the NSA would really like approximately all the data they can get their hands on, they were just being courteous and polite, saving Juniper time and effort by getting it themselves, rather than bothering Juniper by asking them for the data.
Everyone raise their hand...
…if you think that this has only been done to Juniper’s devices and that it’s only been done once.
source code revision control system
Juniper has an awesome RCS. It’s interesting they “revealed” this back door but did not “reveal” anything about who or how or when it was put in.
I’m also wondering if they have a recourse. If this was done by a private individual it would constitute a blatant violation of the CFAA, property damage, and reputational damage.
E
Re: source code revision control system
crickets chirp
Re: Re: source code revision control system
sorry meant for above post
Re: source code revision control system
I wonder about the recourse issue as well. This revelation could hurt them in the market (though you could argue their disclosure means they can be trusted). If they were able to show that the NSA directly harmed them, can they sue?
Re: source code revision control system
Most systems don’t have the cryptographic guarantees of git. If I wanted to hide something like this, I’d insert it as a change in the distant past—ideally something like “initial import from CVS” not associated with any actual person (rewriting all subsequent versions too, of course). Don’t go through the public APIs when you can just hack the RCS server directly.
It could be hard to prove anything if it’s disguised as a bug. See the Underhanded C Contest. And even if a person did check it in, maybe the NSA edited the code sitting on the developer’s system so they’d check in the wrong thing. After all, they’ve been known to hack sysadmin computers, and a hacked admin account could remotely edit your laptop’s hard drive. If I were caught inserting a backdoor I’d be claiming something like that.
So. It wasn’t the corporation the NSA approached with their little request but rather an individual developer within that corporation. Interesting. And clever.
Back in the late 90s, I was working for a company that made network switches. I was a software engineer and only once visited a customer site to debug a difficult problem. The VP of engineering came with me and we brought a couple of spare switches to help in debugging. The site was Livermore National Laboratories, in particular, the group that oversaw the National Ignition Facility (you know, the big building filled with massive lasers that was supposed to be used for controlled fusion but ended up just as a way of testing nuclear weapon design). During our visit, with their head IT guy present, we found that the password had been set for one of our spare switches and no one there knew it. The other engineer who came with us mentioned there was a backdoor, a hard-coded password, to gain administrative control. I was unaware of that despite knowing most of the code. Both that engineer and the VP seemed not to be fazed by the existence of a backdoor. I desperately tried to change the subject while entering the hard-coded password. When we got back I immediately changed the code to eliminate the backdoor. My point is that the backdoor was introduced just as a convenience for the development engineers who weren’t terribly concerned about security repercussions. I am not dismissing the possibility that Juniper’s backdoor was introduced for nefarious reasons. If the code is designed to allow access to VPN keys once you have administrative access, it is conceivable that this backdoor was an ill-advised convenience rather than intentionally set for allowing surreptitious surveillance.
Re: But it was "unathorized code"
Quite a few similar stories exist. See: http://www.iss.net/security_center/reference/vulntemp/Rlogin_-froot_backdoor.htm for a more blatant example, but the “WIZARD” mode of the old sendmail SMTP program is about the same.
I wanted to parse the Juniper “unauthorized code” tag to say that what you’re advocating isn’t what Juniper meant, but after thinking about it, I now believe that “unauthorized code” could mean exactly what you mention.
After that, it occurred to me that even if the “unauthorized code” was a spy agency hack, then deep cover spy agency sock puppets would be writing exactly what you wrote to muddle the issue. Some fraction of tech journalists
are going to rationalize this away, using your writing and similar historical bugs/backdoors as above. NSA/FBI/CIA shills like Stewart Baker, Richard Burr and John Schindler will probably use exactly the same rationale in their parts of the he said/she said “journalism” that will come out in the next few days.
Re: Re:
It’s one thing to put in back doors for testing and debugging.
But not removing them when testing and debugging are done is negligent.
And a device that may need to be reset needs to be a hard button reset at the device, not remotely.
Re: Re:
Good point. The enduser of hardware such as you describe have no idea what is in the box. I worked in process control, living in machine code heaven. Back in late 70’s thru 90’s debugging embedded OS (mostly ROM) was hell. I bet this “backdoor” was requested by hardware designers as a tool. Oops, forgot to tell the make to kill it for production.
maybe.
First I wasn't
First they came for the Communists, but I wasn’t a Commy and did nothing.
Then they came for the Terrorists, but I wasn’t one of those either and kept to myself.
After that they went after the drug dealers, child abusers and hardened criminals, but again I didn’t belong to those groups and allowed it to happen.
Next they went after everyone who was on the secret lists for secret reasons and I did nothing because I had no standing or support to undo decades of erosion of rights.
The land of the free and home of the brave is now less free then at any time in history because we have traded our freedom for the illusion of safety. The terrorists aren’t foreigners trying to make us afraid of leaving our homes, it is the government trying to justify their actions and hating truth and openness more and more every day.
By their fruits, you will know them.
Re: First I wasn't
I get what you are trying to say, but what you wrong doesn’t really fit the original poem. There’s nothing wrong with the government pursuing terrorists, drug dealers, and child abusers. How they pursue matters, but the fact that they are after bad guys is a good thing.
Re: Re: First I wasn't
Yes! What would you do? Cut a great road through the law to get after the Terrorists and Drug Dealers and Child Abusers? And when the last law was down, and the Terrorists turned ’round on you, where would you hide, the laws all being flat? This country is planted thick with laws, from coast to coast, Man’s laws, not God’s! And if you cut them down do you really think you could stand upright in the winds that would blow then? Yes, I’d give Terrorists, Drug Dealers and Child abusers benefit of law, for my own safety’s sake!
Take that, Senators Graham and Burr.
Re: Re: Re: First I wasn't
It is a slippery slope to deny rights to some and trust that the good guys will keep it from being abused. If we are willing to give up freedom for the illusion of safety, we deserve neither.
“And a device that may need to be reset needs to be a hard button reset at the device, not remotely.”
I’m not being facetious, but I would bet money some sites have robots or control gear to do resets. Which just moves the problem to one of backdooring the robot. Sometimes something has to be done *now* instead of waiting for an engineer or authorized person (*) to reach a (potentially remote) site.
(*) = who is sure that the employee or authorized person isn’t the backdoor?