'Unauthorized Code' In Juniper Firewalls Could Decrypt VPN Traffic (arstechnica.com) 112
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.
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.
Welcome to the club (Score:5, Interesting)
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: (Score:2, Insightful)
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: (Score:2)
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: (Score:2)
Re: (Score:1)
I was so excited to get off Cisco gear and onto Juniper (way back, a very long time ago and in a galaxy far away, namely - North Carolina) and the savings were so lovely. I was able to resell our kit and almost pay for the Juniper gear. And, oh, even *I* could figure out how to use it. We didn't fire our CCNA but we did move him into a slightly more productive role - he did more than manage networks after that. He was up to speed with Juniper before their reps left the building. He was then able to do a few
Re: (Score:2)
Re: (Score:1)
I'm not entirely certain why the government is bothering to raise such a fuss about strong crypto.
WHICH government?
Where does almost all computer equipment get made?
And WHO is to blame for that shit?
We want to sit here and talk about "evil" China while kissing their ass to manufacture for pennies.
We deserve what we get if this was State-injected offshore.
We also deserve what we get if we allowed OUR government to give China that directive, which sad to say is not inconceivable.
Re: (Score:3)
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: (Score:1)
I dunno but I'm pretty sure Mao is dead. Other than that, spot on. I'm just hoping it wasn't knowing collusion with Juniper 'cause I'm kind of a fan and it would make me sad. They really should do a checksum type of thing before rolling that shit out. I'm hoping that it could have (should have?) been caught with a bit of oversight.
Re: (Score:1)
I'm thinking they've got more than one repository?
Re: (Score:2)
Barring simple ignorance as a factor, about the only reason I can think of that they could be making a fuss about crypto is that for some reason, they are thoroughly convinced that there are some significant subset of criminals that use unbreakable cryptography and do not get caught because of it, but who would be too incompetent to get away without getting caught if strong cryptographic choices were simply not as readily available to them (through legal channels).
If this belief is correct, one could at
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Of course they know that banning widespread use of strong encryption won't guard against 'smart criminals', but I would argue that they likely believe there are far more 'dumb' ones.... laymen who are committing relatively small scale crimes and getting away with it because of the convenient and legal availability of strong encryption, where law enforcement cannot determine the difference between legal activity that happens to be private and illegal activity.
Banning encryption would do nothing to stop th
Re: (Score:2)
Re: (Score:1)
I believe the theory is that one-time-pads can be broken, eventually, by throwing enough at them until they stop spitting back gibberish. It's just a long and complex process. At least that's my understanding. I'm a mathematician and even I get confused with cryptography. I understand that certain letters are also used more frequently so that they can tune things to get a slightly quicker result but that it is still a lot of compute power.
Re: (Score:3)
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* combinatio
Re: (Score:1)
Err... Unless you're sending one letter shouldn't you have a few more letters than AAAAAAAAA or BBBBBBBB?
Re: (Score:2)
Most definitely. (And of course, I know you know that.)
I used very simple strings as keys in an attempt to aid the example. Apologies if that caused confusion.
I recall the first time I heard about OTP.
I remember thinking the same as you wrote earlier: that if you throw enough raw power at it you can still solve it; just that it's harder than "regular keys".
Then I read a wonderful explanation here on Slashdot (far better than my terrible attempt) and the penny dropped with a heavy thud. OTP are completely un
Re: (Score:1)
Why thank you. I wrote a bit more on this.
http://slashdot.org/comments.p... [slashdot.org]
I could have sworn that I'd seen some of this discussed and maybe it's never really just clicked. The problem is, I don't have a clue where I read it. It might have been here? It might have been a scholarly work?
Re: (Score:1)
But what are the odds of the results being gibberish vs. the actual message?
Re: (Score:2)
The odds are 1 in ({number of different symbols per character} to the power of {length of ciphertext}) - 1 of it being the plaintext.
If the OTP is truely random, then a ciphertext can be decoded to any possible permutation of the same length with equal probability.
Take for example the ciphertext TIGZIFZOMASDRVBTJFVTS:
With an OTP of ABCDEFGHIJKLMNOPQRSTU it decodes to THEWEATHERISFINETODAY,
while an OTP of LPOIIXMGZUQDYDBGGCHNA yields ITSRAININGCATSANDDOGS.
Without knowing the original OTP you have no way of k
Re: (Score:1)
Thank you and that confirms that I had thought to understand but can't one still crunch and then look at, systematically, to throw out all probable gibberish and then use machine learning, or similar, to make probable guesses and then keep refining either by human, circumstance, or additional metrics to reduct the probable answers until you can make a few educated guesses?
Of course, that would probably be defeated by making the code gibberish to begin with. Maybe that's what I'm missing? "PINKANDPURPLEGARBO
Re: (Score:2)
Thank you and that confirms that I had thought to understand but can't one still crunch and then look at, systematically, to throw out all probable gibberish and then use machine learning, or similar, to make probable guesses and then keep refining either by human, circumstance, or additional metrics to reduct the probable answers until you can make a few educated guesses?
No. One-time-pads are random.
There is nothing in the transmitted ciphertext to even start any kind of probablility guessing.
The ciphertext you get by XORing the message with a random number of equal length is itself a
random number.
Of course, you now can generate random numbers of said length yourself and try them on the
ciphertext, but this is mathematically equivalent to just generating random cleartext
messages, without any input at all.
If you have some bits of intercepted ciphertext, all "decrypt
Re: (Score:1)
I'm going to have to take your word for it but I am a mathematician and I don't really think we've got anything that's truly random. We have unpredictable pretty well covered but not true random. That's why most anything is a PRNG or CSRNG. In math we have some unpredictability that appears random, such as the occurrence of the number nine in pi. There's pretty good improbability results from decay - that *might* be random but probably isn't, we're just not able to know why so we still call even that pseudo
Re: (Score:2)
I'm going to have to take your word for it but I am a mathematician and I don't really think we've got anything that's truly random. We have unpredictable pretty well covered but not true random. That's why most anything is a PRNG or CSRNG.
Yeah, OK. However: You being a mathematician, it should be clear to you that
"the amount of randomness" in an XOR operation is always the one from the more
random side (XOR preserves randomness) - that's why XORing multiple sources of entropy
never makes the randomness worse.
So the entropy of the ciphertext is equal to the entropy of the OTP keystream, and none of
the structural properties of the plaintext survive.
But it seems likely that, with enough time and enough compute power, that if you sent a message to Tim and Tim burned down a house we'd be able to throw out any results that look like the Mona Lisa.
No, it doesn't. No, we wouldn't.
The Mona Lisa, "burn down that house", "defend that house
Re: (Score:1)
I get where you are missing my point which, I admit, was probably made in a separate thread. This is, of course, simply defeated and (probably) unbreakable by sending "PINKANDPURPLEGARBONZOBEANS" which will mean nothing to you but there are five of us on the planet who will absolutely know what it means and giggle like little school girls. So, it's useful but is it *truly* unbreakable if the message is "GOKILLHARRY" or the likes? By truly unbreakable, I don't mean damned hard - I mean truly unbreakable, tha
Re: (Score:2)
So, it's useful but is it *truly* unbreakable if the message is "GOKILLHARRY" or the likes? By truly unbreakable, I don't mean damned hard - I mean truly unbreakable, that it can *never* be solved?
YES! Provably (and proven) so [wikipedia.org]!
(provided of course that your cipherstream stays secret.)
Again, in a OTP-generated cipherstream, there is nothing to solve.
It's random noise. Structureless. This is not an algorithmic cipher where the cipherstream
suddenly makes sense once your brute-forcing hits the right key bit-pattern. It's a random(!)
bitstream that, if XORed with a pre-shared key known to Alice and Bob, results in a plaintext.
But all other plaintexts generated by all other possible keystreams are e
Re: (Score:1)
Hmm... I read that and, well, I noted the part below your link. Namely, the problems section. Allow me to quote, if you will and do not object, to your own link:
Despite Shannon's proof of its security, the one-time pad has serious drawbacks in practice because it requires:
Truly random (as opposed to pseudorandom) one-time pad values, which is a non-trivial requirement. See Pseudorandom number generator.
Also, this but not as important:
The theoretical perfect security of the one-time-pad applies only in a theoretically perfect setting; no real-world implementation of any cryptosystem can provide perfect security because practical considerations introduce potential vulnerabilities.
I surmise that, simply, the proof is wrong as we have no true random and may never have true random. Hard as fuck, yes. Perfect? I object.
I'm pretty sure that I am missing something. Again, I thank you for your patience. Some things sink in slowly - I'm thinking that I'm not explaining it well.
If you send a cypher via
Re: (Score:2)
Hmm... I read that and, well, I noted the part below your link. Namely, the problems section. Allow me to quote, if you will and do not object, to your own link:
Despite Shannon's proof of its security, the one-time pad has serious drawbacks in practice because it requires:
Truly random (as opposed to pseudorandom) one-time pad values, which is a non-trivial requirement.
Drawbacks? Yes. Unsolveable ones? Absolutly not.
...
There are several natural processes that can be used to generate
random numbers (without pseudo-): Radioactive decay, thermal noise,
cosmic rays,
It's quite bothersome indeed to generate a useful amount (gigabytes+)of
randomness, but it is in no way impossible, and actually routinely done for
cryptographic purposes.
Also, this but not as important:
The theoretical perfect security of the one-time-pad applies only in a theoretically perfect setting; no real-world implementation of any cryptosystem can provide perfect security because practical considerations introduce potential vulnerabilities.
That's extremely weasel-wordy and gives no example of a vulnerability. This paragraph
should be removed as being totally content-free.
Yes,
Re: (Score:1)
Thank you for explaining and I see where you're coming from. I'm an applied mathematics grad, actually. I know, literally, almost nothing about encryption as it was simply not something that interested me and we barely covered it in any of the classes that I took.
And I think I get it now. We can go on and on about randomness. Now that I understand, I hope, one wouldn't really need true random in order to make use of this - even outside of a perfect world.
Re: (Score:1)
Yeah, I think I understand that now. Thanks. I've taken a look at a few links and I kind of grok it now. I'm mostly unfamiliar with cryptography though it was briefly, very briefly, discussed. It had nothing to do with the things I was planning on and so I never took an interest and never did any additional study. I probably should but I probably won't except to pick up bits and pieces here and there for curiosity.
Re: (Score:2)
Re: (Score:1)
It was a joke, Aspergers Man. It was in relation to how Cisco routers have had the same "flaw" reported as of late.
Re: (Score:2)
Re: (Score:3)
http://www.spiegel.de/internat... [spiegel.de]
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
Re: (Score:2)
That wouldn't work. There would still be code reviews, a change list and all sorts of logs. Easier to just hack into a server and make the changes on the trunk branch.
Snowden (Score:5, Informative)
This is EXACTLY a vulnerability that Snowden leak suggested. Juniper and ScreenOS by name.
Trust? (Score:5, Interesting)
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: (Score:1)
And you think there are security softwares - open OR closed source - that you can use which have NOT been back-doored by the NSA?
How cute.
Re:Trust? (Score:5, Interesting)
Sufficiently advanced malice is in distinguishable from incompetence.
Re: (Score:2)
Indeed. Most people wrote "GOTO fail" off as a mistake, but I'd say more than likely it was planted.
Re: (Score:2)
Indeed. Most people wrote "GOTO fail" off as a mistake, but I'd say more than likely it was planted.
If so, then at least the attackers there had the common decency to make it look like it could have been a mistake. Here they don't even try to hide their tracks -- shameless! :p
Re: (Score:1)
This is indicative of a poorly managed, haphazard approach to managing software development.
There's nothing poorly managed or haphazard about it. This looks like software designed as required by a company which was told compliance will be rewarded.
Re: (Score:2)
Once the key gets out (and too many people know it for this not to happen) option 1 becomes option 3.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Who should you trust? (Score:2)
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 eff
Re: (Score:2)
Re: "I guess it's now a matter of who do we want listening in."
Share a long paper book to a friend and have a one time pad system with all work done on paper before the encoded message is entered into any computer, network, system.
"Unauthorized"? (Score:5, Interesting)
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"? (Score:5, Insightful)
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"? (Score:2)
If you've managed or freaky or dealt with complex systems, you know that software upgrades are often troublesome. Outright failures, bricked devices, lost functionality or configurations, intermittent problems, new bugs or interfaces, any or all these are a risk.
Re: (Score:1)
We do week long sprints so no fundamental improvements ever get done. There's a ton of known security problems after our last PCI audit, but most of the items can't be fixed since they can't be completed by development, tested, and verified by stakeholders within a week. Agile is going to put us out of business. An article I read about eight years ago about Agile that called it a suicide pact was right.
Re: (Score:3, Interesting)
Re: (Score:2)
Could be onerous, might be someone slipped in a fast fix because a big customer bitched that their ancient stuff wouldn't work, so how 'bout an exception?
The pending retirement of SHA-1 is just such an exception-handling nightmare.
Could also have been a stupid patch for a genuine bug.
And perhaps, their random-number seed generation was actually pseudo-random, and predictable. This is the problem with closed source: you don't know and must trust vendors to do the right thing. At least in this case, it *appea
Did Juniper give NSA source code? (Score:4, Insightful)
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.
Re: (Score:1)
"I wonder how Dreamy Smurf can do something that is a system protected function without the help of Google or Apple."
NSL
compromise my text-editor (Score:1)
Come on
what is their development strategy? (Score:3)
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.
Re: (Score:1)
Re: (Score:1)
Just because you peer review it, doesn't mean that is the actual package that gets submitted :) Do you check it post submit or is it just one of those things they do to say "we peer review" and get management credit for it?
Re: (Score:2)
goes through branches before making it to trunk
Re: (Score:2)
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.
You may vet your code all you want, but if someone compromises your build server's compiler, your binaries may contain backdoors anyway, just ask Ken Thomson [scienceblogs.com]
Not the official back door? (Score:2)
So, they were sitting around the table at the code review meeting and nobody knew which government asked for THAT back door?
Sonicwall NSA (Score:2)
I can just imagine the laughter generated at Sonicwall and at the NSA when this product line was announced...
Alternatively ... (Score:1)
Translation: (Score:3)
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.
Congressional investigation? (Score:2)
One thing is to pay them, as they did with RSA, and another is to actually break their code. Or maybe Juniper was paid, but subscription has lapsed?
Re: (Score:2)
They'll have to wait their turn -- the Congressional investigating committees are all booked up until November 2016, investigating Benghazi and Planned Parenthood.
So they do not have working source-code management (Score:2)
Because if they had that, then all code would be authorized and signed off on. At least they found the problem, but this is really amateur-level.
Security is a matter of layers (Score:1)
Re: (Score:2)
This is why you should not rely on a VPN or any single layer solely as your entire security solution. Multiple layers of encryption and AAA and best practices are required. Its all about making it harder for the bad guys. No solution is fool proof.
I don't disagree, but the usual problem in practice is that each additional layer of security adds an additional layer of inconvenience for the user, and at some point people who want to just get their work done start finding ways to "get around" the inconvenience (e.g. by using their personal laptop instead of the difficult-to-use company-issued laptop), and then we're back to square one.
I wonder if there is any practical way to automate the layering of multiple levels of security, so that it would be as t
Re: (Score:1)
No, we must deal with the biggest threat first.