'Unauthorized Code' In Juniper Firewalls Could Decrypt VPN Traffic (arstechnica.com)

m2pc writes: Ars Technica reports that Juniper Networks firewalls have been discovered to include "unauthorized code" inserted into their ScreenOS software. Juniper has has published an advisory addressing the matter, with instructions to patch the affected devices.

From the Ars article: "NetScreen firewalls using ScreenOS 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20 are affected and require immediate patching. Release notes published by Juniper suggest the earliest vulnerable versions date back to at least 2012 and possibly earlier. ... The first flaw allows unauthorized remote administrative access to an affected device over SSH or telnet. Exploits can lead to complete compromise. 'The second issue may allow a knowledgeable attacker who can monitor VPN traffic to decrypt that traffic,' the advisory said." The rogue code was discovered during a recent internal source code review conducted by Juniper.

Comments

Welcome to the club

[nehumanuscrede]

says Cisco . . . . .

I'm not entirely certain why the government is bothering to raise such a fuss about strong crypto. ( Other than to make it look like they have no options ) While no evidence exists that Big Brother is responsible for it, they are the most likely suspects. Not much of a need to break the crypto itself when you can install a bypass of some sort into the mix.

I wonder how much it costs to coerce a programmer type to insert a few bits of code into your project.

Snowden

[Anonymous Coward]

This is EXACTLY a vulnerability that Snowden leak suggested. Juniper and ScreenOS by name.

Trust?

[Anonymous Coward]

Thanks for disclosing this, Juniper, but why didn't you know about it three years ago? What else is hiding in your products? This is quite different from a software flaw introduced by a mere human. This is indicative of a poorly managed, haphazard approach to managing software development.

Re:Trust?

[Anonymous Coward]

Sufficiently advanced malice is in distinguishable from incompetence.

"Unauthorized"?

[fuzzyfuzzyfungus]

The phrase "Unauthorized code" smells of weasel wording. If the malware was injected afterwards(either through a network attack or a physical intercept-and-tamper, then the manufacturer could reasonably call it "unauthorized" or "malware" or similar; but if they shipped it, how much more 'authorized' do you get?

Perhaps "mistakenly authorized after slipping past scrutiny" or "authorized by one or more of our employees who is also a spook", or "we fucked up"; but not really "unauthorized". Were I a customer, I'd want a much, much, better account of how exactly this 'unauthorized code' came to be present, when, and who knew about it, who didn't, and why or why not.

Re:"Unauthorized"?

[rickb928]

Don't overthink this, and don't bother to conflate naivete with malice.

Despite multiple code reviews, it's probably insanely easy to slip in code that isn't reviewed for functionality or compliance. If they use Git or something similar, compromises there lead to the same thing.

Demanding a line by line code review doubles the work, but for that level of network hardware is probably essential now. Bad actors will make every effort to inject their backdoors into production code, and I suspect this was an inside job.

I also would not discount the possibility that this was someone's clever idea of some diagnostics to help them. Doubt they will take credit for this.

At work I am seeing a change in our development to apply the Agile processes to not only coding and design, but also testing and deployment. This has led to a team relying on unit testing, and failing to do functional testing on the product - with predictably disastrous results. This Juniper problem has heightened my interest in application security, and this will only lead to more testing, longer sprints, and longer development cycles. None of which will get traction with management unless someone takes an interest in the security risk.

But at work our security team defaults to assuming threats come from both within and without the corporate infrastructure. Rightly so. We see risks of data loss and unauthorized access equally inside and outside, and so we must also monitor all traffic, and they do identify and fingerprint all apps. Our most recent debacle involved an internal app. This data should never be sent outside the corporate network unless via VPN to an authorized device.

Juniper deserves some credit for finding this, though the time interval for reviewing code will probably need to be shorter. Overall, if I were still in infrastructure management, I would be less than thrilled about a firmware patch - I never trust those.

Did Juniper give NSA source code?

[Anonymous Coward]

So are Juniper one of the companies that provided source code to the NSA? We can pretend its Russian hackers or Chinese hackers or whatever, but the reality is NSA has the history of doing this, probably had the source code and maybe even the assistance of employees.

Because the extra code would have to be in the SOURCE CONTROL system to survive every incremental upgrade, and so will have some user name associated with it to track it.

And this reminds me of the other big revelation, that the UK Spooks did mass surveillance and lied to UK Parliament to cover it up. Which included planting malware in a slightly cruder way:

http://www.theregister.co.uk/2015/12/16/big_brother_born_ntac_gchq_mi5_mass_surveillance_data_slurping/

"PRESTON, which collects about four million intercepted phone calls a year, has also recently been used to plant malware on iPhones, according to disclosures by former NSA contractor Edward Snowden. The phones were then targetted for MI5 "implants" (malware), authorised by a ministerial warrant."

You may also remember GCHQ 'Smurfs' software for mobile phones.

Dreamy Smurf. turns phones on when they are off.
Tracker Smurf turns on the GPS
Nosey Smurf turns on the microphone and listens in

I wonder how Dreamy Smurf can do something that is a system protected function without the help of Google or Apple. It seems remarkably easy to get around the security.