Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×
Encryption Security

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

This discussion has been archived. No new comments can be posted.

'Unauthorized Code' In Juniper Firewalls Could Decrypt VPN Traffic

Comments Filter:
  • Welcome to the club (Score:5, Interesting)

    by nehumanuscrede ( 624750 ) on Friday December 18, 2015 @11:27AM (#51143419)

    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)

      by macs4all ( 973270 )

      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.

      • by KGIII ( 973947 )

        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

      • by swalve ( 1980968 )
        Are people really that spineless?
    • by mark-t ( 151149 )

      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

    • I skimmed TFAs and searched them for Cisco and don't see that they have anything to do with this . How does Cisco come into play?
      • by Anonymous Coward

        It was a joke, Aspergers Man. It was in relation to how Cisco routers have had the same "flaw" reported as of late.

    • by AHuxley ( 892839 )
      Prying Eyes: Inside the NSA's War on Internet Security (December 28, 2014)
      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 :)
    • by mikael ( 484 )

      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)

    by Anonymous Coward on Friday December 18, 2015 @11:29AM (#51143427)

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

  • Trust? (Score:5, Interesting)

    by Anonymous Coward on Friday December 18, 2015 @11:29AM (#51143429)

    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.

    • by Anonymous Coward

      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)

      by Anonymous Coward on Friday December 18, 2015 @12:21PM (#51143843)

      Sufficiently advanced malice is in distinguishable from incompetence.

      • by AmiMoJo ( 196126 )

        Indeed. Most people wrote "GOTO fail" off as a mistake, but I'd say more than likely it was planted.

        • by Jeremi ( 14640 )

          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

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

  • 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

    • by AHuxley ( 892839 )
      The typewriter is looking rather useful again :)
      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)

    by fuzzyfuzzyfungus ( 1223518 ) on Friday December 18, 2015 @11:47AM (#51143513) Journal
    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"? (Score:5, Insightful)

      by rickb928 ( 945187 ) on Friday December 18, 2015 @12:34PM (#51143951) Homepage Journal

      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.

    • 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

  • by Anonymous Coward on Friday December 18, 2015 @11:50AM (#51143537)

    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.

    • by Anonymous Coward

      "I wonder how Dreamy Smurf can do something that is a system protected function without the help of Google or Apple."

      NSL

  • If my vim/emacs or any other text editor is compromised [or why not compromise the file-system itself..so it will serve "good" file for reading and supply the souped-up version only to the compiler], how will I even spot the issue?

    Come on ..when you can put in wrong code directly in the OS.. they should've gone ahead and put it right inside the file-system/editor/display-system. Reminds the story of login program vulnerability put inside C compiler by Ritchie.
  • by i_ate_god ( 899684 ) on Friday December 18, 2015 @12:12PM (#51143769) Homepage

    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.

    • Very likely they directly changed in the SCM and covered the tracks [erase in log files etc]. That is not going through a developer workflow (using code-review, commit etc). Once you know which file to add the snippet too, it's a simple task. And in a very stable OS, some of the OS related code [things which manage TCP say] hardly change for years and it's very easy to hide the malware and be spotted.
    • by Anonymous Coward

      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?

    • 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]

  • So, they were sitting around the table at the code review meeting and nobody knew which government asked for THAT back door?

  • A while back we migrated from a Juniper to a Sonicwall NSA(Network Security Appliance).
    I can just imagine the laughter generated at Sonicwall and at the NSA when this product line was announced...
  • Maybe they want to ADD a backdoor?
  • by kheldan ( 1460303 ) on Friday December 18, 2015 @01:51PM (#51144541) Homepage Journal

    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.

  • Assuming that NSA did that, can this even be legal? I mean, to sabotage an entire line of products of an American company by an American government agency? It's like if FDA went and injected all MacDonald's happy meals with cadmium.

    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?
    • by Jeremi ( 14640 )

      They'll have to wait their turn -- the Congressional investigating committees are all booked up until November 2016, investigating Benghazi and Planned Parenthood.

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

  • 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.
    • by Jeremi ( 14640 )

      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

Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.

Working...