Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
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.

    • by macs4all ( 973270 ) on Friday December 18, 2015 @11:44AM (#51143493)

      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 Anonymous Coward on Friday December 18, 2015 @12:10PM (#51143747)

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

      • by KGIII ( 973947 ) <uninvolved@outlook.com> on Friday December 18, 2015 @04:04PM (#51145745) Journal

        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 other things with his spare time as we had, at that point, three satellite offices (eventually we had two more).

        I've been a Juniper fan ever since. Not quite fanboy at the level of a Mac fan (yes, I had to mention that 'cause, you know) but a fan nonetheless. I've spoken with people and they've gone ahead and moved off of Cisco kit where they could. I didn't, personally, do much of anything with it but I know we got the entire functionality, easier, at a price point that's far less than it would have cost with Cisco. I do think we did end up with some failing hardware but it was still replaced and we had enough to have some redundancy in place.

        God, I don't even know when that was that we had a Juniper rep come visit for the first time. Even our CCNA was impressed. (Or was he a CCNE???) I don't know but if you've ever compared the prices then, well, let's just say when you're rolling out a remote office you can literally save many, many thousands of dollars. It is true that you get what you pay for but they were good enough and did just fine for our needs. (Kind of like MySQL worked well enough to not give Oracle any money, I hate Oracle but that's a story for another day.)

        To the point!!!

        This is disheartening and unfortunate. It is not unexpected, however. They were the underdog when we bumped into them. I'm a pretty geeky guy and I'd never heard of them until getting a cold call and opting to call the number back as the timing was rather convenient. I imagine it's a larger company now and that they've got more holes in 'em than they used to - including hiring someone from a TLA. I'll be interested in finding out how this happened. I can only hope that they release that information and that it was not done as corporate policy. If it turns out it was corporate policy then I will be sad. Anyhow, I'm going to *guess* that I bumped into 'em in 2001-2002 range? I've no idea but that *feels* about right.

      • by swalve ( 1980968 ) on Saturday December 19, 2015 @07:32PM (#51151681)
        Are people really that spineless?
    • by Anonymous Coward on Friday December 18, 2015 @11:59AM (#51143623)

      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?

      • by Anonymous Coward on Friday December 18, 2015 @12:11PM (#51143751)

        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.

      • by ShanghaiBill ( 739463 ) on Friday December 18, 2015 @12:22PM (#51143847)

        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.

        • by Anonymous Coward on Friday December 18, 2015 @02:09PM (#51144691)

          Really, ShanghaiBill? They have a big development office in Beijing. Manufacturing is pretty much all in inland china too. There are no doubt several points in mainland china where direct access to the Juniper enterprise repo is available. Its hardly inconceivable that the employees were coerced by party bosses to put something like this in place. After all, VPNs are what cause the most trouble with the Great Firewall of China, and what better way to execute control over your population than by giving them a tool they think is covertly subversive but in actuality is a direct pipe to Mao's inner sanctum so that dissidents can be summarily purged.

    • by mark-t ( 151149 ) <markt@nerdflat. c o m> on Friday December 18, 2015 @12:02PM (#51143665) Journal

      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 least sympathize with why they feel strong crypto should be outlawed, even if one does not actually agree with the proposal.

      One may call this simply a tenuous conjecture on their part and discount it on that basis, but I would suggest that even if it were true, I do not think it should outweigh the implications for completely innocent parties with regards to their personal information and their privacy.

      • by Anonymous Coward on Friday December 18, 2015 @12:29PM (#51143913)

        Never attribute to incompetence that which can easily be explained by malice.

    • by Anonymous Coward on Friday December 18, 2015 @12:17PM (#51143821)

      If you keep saying that you need crypto back doors and access someone without knowledge of all the existing back doors/zero days/exploits might reasonably believe that his/her encrypted communications or files are actually secure and behave as if they are. This might lead them to rely on that crypto and leave themselves vulnerable to NSA/TSA/CIA/FBI/TLA even though in practice it never seems to go down that way.

      Let's face it, crypto is hard for those without the requisite understanding to know that everything can be cracked eventually. Example Paris where so far the evidence is that they communicated in the clear the entire prep time.

      • by Locke2005 ( 849178 ) on Friday December 18, 2015 @01:41PM (#51144457)
        All ciphers can be cracked eventually, but what about one time pads? How does the government put in a back door to attack them? If it's important enough, can't you have secure communication no matter how the intervening points are compromised? (Secure as in not decrypable, of course the government can always block the message from being delivered.)
        • by Anonymous Coward on Friday December 18, 2015 @02:48PM (#51145047)

          Different AC here. If I read GP correctly, s/he seems to be hinting at the fact that they can zero-day your device/server/etc. If the data ever exists on that device/server as plaintext, it can be hoovered up while it's in that state. Your stash of one time pads can also be hoovered up. Same goes for asymmetric encryption: the private key can be hoovered up.

        • by KGIII ( 973947 ) <uninvolved@outlook.com> on Friday December 18, 2015 @04:12PM (#51145811) Journal

          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.

          • by skegg ( 666571 ) on Friday December 18, 2015 @07:00PM (#51146837)

            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. (?)

            • by KGIII ( 973947 ) <uninvolved@outlook.com> on Friday December 18, 2015 @10:04PM (#51148037) Journal

              Err... Unless you're sending one letter shouldn't you have a few more letters than AAAAAAAAA or BBBBBBBB?

              • by skegg ( 666571 ) on Saturday December 19, 2015 @04:43AM (#51149095)

                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 uncrackable *because the key can be anything*! Of course, this comes with all the caveats regarding key security.

                I generally browse /. as AC, but logged-in to comment when I saw your initial comment. I typically enjoy reading your contributions / comments, and wanted to share this sentiment. What can I say ... it's Christmas ... I'm not my usual cranky self.

    • by unencode200x ( 914144 ) on Friday December 18, 2015 @12:26PM (#51143883)
      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 on Friday December 18, 2015 @12:46PM (#51144045)

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

        • by Anonymous Coward on Friday December 18, 2015 @04:08PM (#51145777)

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

          1. No, Cisco routers have not had this same flaw.
          2. No, this does not affect "Juniper Firewalls". It affects Netscreen firewalls, and while yes they are a Juniper product they are a Legacy, end-of-life firewall which runs an entirely different OS developed on an entirely different codebase than Juniper's current firewalls... which are the SRX series running JunOS.

          The takeaway from this story should be "Hey, even though Juniper EOL'd the entire Netscreen platform years ago, they are willing to continue issuing security updates".

    • by Anonymous Coward on Friday December 18, 2015 @01:31PM (#51144387)

      Well, with a telnet daemon running, who needs a backdoor?

    • by AHuxley ( 892839 ) on Friday December 18, 2015 @08:32PM (#51147443) Homepage Journal
      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 ) on Friday December 18, 2015 @09:10PM (#51147711)

      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 on Friday December 18, 2015 @11:45AM (#51143501)

      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.

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

      Considering Juniper's VPN client still isn't 64-bit, I am not surprised in the least.

    • 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 Anonymous Coward on Friday December 18, 2015 @02:01PM (#51144629)

      You think compilers couldn't introduce these flaws?

    • by thegarbz ( 1787294 ) on Friday December 18, 2015 @03:13PM (#51145279)

      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.

      • by Anonymous Coward on Friday December 18, 2015 @03:21PM (#51145375)

        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.

        We don't know that for certain. Could be a government mole working inside the company unbeknownst to the company. Could be a formerly-honest employee who was compromised by a government. Could be government compromised the build servers or developer machines using APTs or other malware. Could even be multiple governments in the company's network, all playing something that would resemble a cross between Spy vs. Spy and CoreWars simultaneously.

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

    People still use netscreens? Oh wait we do... Luckily our code is too old to be exploited. Yay?

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

    Did the backdoor let just anybody in, or did you have to have some key info to get in?

    Best possible bad behavior: Adding a secure backdoor.
    Worse behavior: Using a zero day instead of trying to get it fixed.
    Worse still: Adding a backdoor that is a zero day for others to find.

  • by Kevin by the Beach ( 3600539 ) on Friday December 18, 2015 @11:47AM (#51143511) Homepage

    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"? (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.
    • by Anonymous Coward on Friday December 18, 2015 @12:12PM (#51143761)

      The phrase "Unauthorized code" smells of weasel wording.

      No, if they are announcing it immediately after it was discovered (which is what they should do), it just means that they haven't yet tracked down how it got inserted into their code. They could have waited until they did that before announcing it-- because the very first thing anybody always asks is "how did it get there?"-- but it's better to announce it without waiting.

      Figuring out how and why comes later, and I presume (or at least hope) that they'll tell us more when they have better information

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

      • by Anonymous Coward on Friday December 18, 2015 @01:06PM (#51144185)

        Overall, if I were still in infrastructure management, I would be less than thrilled about a firmware patch - I never trust those.

        I agree most what you wrote, but could you elaborate a bit more that last sentence, please.

        A hint to a direction that this is just a clever trick to get everybody upgrade* the firmware which eventually now got backdoor, or what?

        Dang, that would be smart move from NSA, but I dunno how hard it would be to coerce or trick a large vendor in that.

        *) free download ie. even without service agreement, just create account if you don't have one yet.

      • by Anonymous Coward on Friday December 18, 2015 @02:07PM (#51144675)

        > apply the Agile processes to not only coding and design, but also testing and deployment.

        The problem with that is that Agile requires if something takes longer than a sprint then you cannot do it. That means a lot of security issues cannot be addressed if you use Agile.

        At my current company, we have feature we promised customers that have not been delivered because our certified scrum master, as he should, refuses to allow any stories be done that take more than one sprint. We've already lost our two largest customers since switching to Agile, and we might lose another two of the ten largest.

        • by Anonymous Coward on Friday December 18, 2015 @02:30PM (#51144867)

          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:"Unauthorized"? (Score:3, Interesting)

            by Gr8Apes ( 679165 ) on Friday December 18, 2015 @03:01PM (#51145161)
            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.
    • by postbigbang ( 761081 ) on Friday December 18, 2015 @12:37PM (#51143975)

      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 *appears* they're doing the right thing. A small, downside possibility is that the new code brings its own problems. We can't and won't know.

  • 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 on Friday December 18, 2015 @12:02PM (#51143657)

    Is this the project codename FEEDTHROUGH that was revealed to the public by Snowden 2 years ago?

  • by yes-but-no ( 4133651 ) on Friday December 18, 2015 @12:07PM (#51143709)
    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.

  • by mschaffer ( 97223 ) on Friday December 18, 2015 @12:19PM (#51143835)

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

  • by Anonymous Coward on Friday December 18, 2015 @12:49PM (#51144063)

    Configuration management? Don't they have it? Did they also remove any log entries showing the changes?

    I smell disgruntled employee (or a paid off one).

  • by Anonymous Coward on Friday December 18, 2015 @01:14PM (#51144253)

    Is the backdoor now officially authorized?

  • by Sir_Eptishous ( 873977 ) on Friday December 18, 2015 @01:24PM (#51144311) Homepage
    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...
    • by Anonymous Coward on Friday December 18, 2015 @05:22PM (#51146327)

      Sonicwall? That's a heck of a downgrade. Certain environments though I could see it since Sonicwalls are easier for systems admin types to administer in addition to servers.

      Also, CDW at least is terrible about recommending Sonicwalls as replacements for anything, so you might have gotten swindled by a vendor. Once had a CDW job come through to replace an HA pair of Checkpoint NGX firewalls with a pair of NSA 3600s. Very painful since there was so much the Checkpoints were doing which a Sonicwall is simply not functionally capable or equivalent. The first conference call with the customer, I outlined there existing VPN structure was a no-go and would certainly be changing.

  • by AnomalousTurd ( 571488 ) on Friday December 18, 2015 @01:25PM (#51144313)
    Maybe they want to ADD a backdoor?
  • by Anonymous Coward on Friday December 18, 2015 @01:30PM (#51144369)

    signed,
    nsa

  • by kheldan ( 1460303 ) on Friday December 18, 2015 @01:51PM (#51144541) 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.

  • by sshir ( 623215 ) on Friday December 18, 2015 @01:54PM (#51144571)
    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 Anonymous Coward on Friday December 18, 2015 @03:45PM (#51145587)

    Saw stacks and stacks of Juniper devices at the location in Nashville where Google is building out their Fiber datacenter.
    [imgur.com]
    [imgur.com]

  • by Anonymous Coward on Friday December 18, 2015 @03:47PM (#51145611)

    Saw stacks of Juniper devices at the location in Nashville where Google is building out their Fiber datacenter.
    http://imgur.com/OzHk9Y6
    http://imgur.com/FQ4htyr

  • by gweihir ( 88907 ) on Saturday December 19, 2015 @11:48AM (#51150071)

    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.

  • by snowsnoot ( 3389789 ) on Saturday December 19, 2015 @03:04PM (#51150837)
    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 ) on Monday December 21, 2015 @12:42PM (#51159235) Homepage

      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 transparent as possible to the user? (Of course it would need to be done carefully, so that it doesn't also automate the subversion of multiple layers for an attacker ;))

Heard that the next Space Shuttle is supposed to carry several Guernsey cows? It's gonna be the herd shot 'round the world.

Working...