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.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.
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.
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...
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: decryption, encryption, feedthrough, network, nsa, screenos, surveillance, unauthorized code, vpn
Companies: juniper, juniper networks
Reader Comments
Subscribe: RSS
View by: Time | Thread
'Better to ask forgiveness than permission'
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.
[ link to this | view in chronology ]
Everyone raise their hand...
[ link to this | view in chronology ]
source code revision control system
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
[ link to this | view in chronology ]
Re: source code revision control system
[ link to this | view in chronology ]
Re: Re: source code revision control system
[ link to this | view in chronology ]
Re: source code revision control system
[ link to this | view in chronology ]
Re: source code revision control system
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.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
[ link to this | view in chronology ]
But it was "unathorized code"
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.
[ link to this | view in chronology ]
Re:
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.
[ link to this | view in chronology ]
Re:
maybe.
[ link to this | view in chronology ]
First I wasn't
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.
[ link to this | view in chronology ]
Re: First I wasn't
[ link to this | view in chronology ]
Re: Re: First I wasn't
Take that, Senators Graham and Burr.
[ link to this | view in chronology ]
Re: Re: Re: First I wasn't
[ link to this | view in chronology ]
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?
[ link to this | view in chronology ]