'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.

Re:Welcome to the club

[macs4all]

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

The cost of an IRS Audit, or the threat of same.

Re:Welcome to the club

[ShanghaiBill]

WHICH government?

Where does almost all computer equipment get made?

They found malicious code in the source code to the OS. It is irrelevant where the hardware is assembled, since that is not what was compromised.

Re:Welcome to the club

[macs4all]

This would leave such an easy path to proving it well enough to publish in the newspapers though.

And I'm sure that the .0001% of the population that REALLY understands the issues involved would be duly outraged.

Re:Welcome to the club

[skegg]

Not quite, bud.
I ain't no cryptographer (which will soon become apparent!) but I'll have a go at explaining.

The thing with OTP is that the random component can be *anything*.
Lemme give a very contrived example:

Let's say we've encrypted 1,024 bits of plaintext with 1,024 bit OTP key, resulting in 1,024 bits of cyphertext.
If we reverse that cyphertext with the original 1,024 OTP key, we get the original 1,024 bits of data.

So far so good. However ...

It would be possible to put together a *different* combination of 1,024 bits that, when combined with the cyphertext, would yield another, valid plaintext message.

e.g.
Original Message = Hello, world!
OTP = AAAAAAAAAAAAA
Final Cyphertext = BBBBBBBBBBBBB
Reverse the process, and you get "Hello, world!"

But we could use:
OTP = GGGGGGGGGGGGG
To yield this Cyphertext = I like jelly!

Or:
OTP = PPPPPPPPPPPPP
To yield = Summer's here

which would still trigger alarms when checked for things like the frequency of characters, etc. After all, to someone eavesdropping, the OTP can be anything, can it not? Therefore the plaintext could also have been anything.

I hope the above makes sense. (?)

Re:Welcome to the club

[AHuxley]

Prying Eyes: Inside the NSA's War on Internet Security (December 28, 2014)
http://www.spiegel.de/internat...
It was always interesting to see what govs, mil and related security services made a public issue about vs what is just allowed to be offered to the public without comment over the years :)

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.

Who should you trust?

[Kevin by the Beach]

It will come down to the point where network vendors will need to spend more of their time verifying their code hasn't been tampered with. It wont be enough just to have change control, but we will need to have change locking and verification. Exploits come from many directions, but is it worth the cost to fight both internal and external agents.

This compromise hits the bottom line directly. It will effect purchase decisions, just like having Cisco products intercepted and tampered with by the NSA effected their sales. I guess it's now a matter of who do we want listening in... (State actors...US, China, etc, Corporate actors... Google, Apple, Dell, or Network Providers... Verizon, AT&T , Level 3, Comcast...) Unfortunately it's never just one party attempting to listen in, or glom on....

   

"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.

Re:"Unauthorized"?

[Gr8Apes]

Agile - something invented by people that did not want to document anything, not realizing that all they did was put themselves at the end of a bunch of bungie cords and get bounced about at the stakeholder puppetmasters whims, gathering crap and debris as they go. Not until the project is declared a failure do they come back with "but it didn't fail, we delivered all these incremental and desired items" while missing the point that incremental releases are irrelevant when you're needing a full product to be delivered last year.

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.

what is their development strategy?

[i_ate_god]

Every commit I make at work is required to have at least one peer review and its' recommended to have two and we are not selling security-related software.

I've never heard of this company, but this revelation speaks volumes to their poor development strategy. Maybe they fell in love with buzzwords like Agile or Waterfall or whatever without realizing that proper processes like peer reviews have nothing to do with these buzzwords. Either way, they can not be trusted for letting this happen. Either they do not review their own code on a regular basis, or parts of management are corrupt for letting this happen. Either way, probably time to stop doing business with them.

Translation:

[kheldan]

An undercover (national || foreign national) government agent infiltrated our company and inserted a 'backdoor' into our firewall code

..or..

A member of a (criminal || terrorist) organization infiltrated our company and inserted a 'backdoor' into our firewall code

..or..

A (national || foreign national || criminal) organization (paid off || extorted) a Juniper Networks employee to insert a 'backdoor' into our firewall code

Take your pick from any of the above theories, since 'unauthorized' is about as thinly-veiled a euphemism as you can get.