back to article 'Unauthorized code' that decrypts VPNs found in Juniper's ScreenOS

Juniper Networks has admitted that “unauthorized code” has been found in ScreenOS, the operating system for its NetScreen firewalls. The code “could allow a knowledgeable attacker to gain administrative access to NetScreen devices and to decrypt VPN connections.” And on The Register's reading of the situation, the …

  1. The_Idiot

    "So you've reprogrammed to add the new code to all devices?"

    "Yes, Agent Black."

    "Then you're approved to 'find' the old one. It will build trust."

    "Yes, Agent Black."

    "No, I'm Agent White. Agent Black said the first sentence."

    "Well, it's hard to tell the difference between you two..."

  2. razorfishsl

    So how about why it is "unauthorized"?

    Was it debug code placed their by staff or by some external agency doing work for the company?

    or was it "unauthorized" , just because it was not part of the remit for the original Kernel?

    1. elDog

      It was "unauthorized" because they were "found out"

      There are too many ways for perps to get some quirky code into a box.

      Simple bribery works frequently, bits of virus encodings on some stick stuck into the hole, visits to a nice little pr0n-promising URL.

      But also just slipping a dude high up in the chain-of-command a bit of cash, or perhaps a blackmail about other dark-alley dalliances.

      Just like VW (sorry for the non-sequitur), "some errors were made".

    2. TeeCee Gold badge

      Presumably they still haven't worked out whether it's malicious or a cockup, so the only fact is that it's not supposed to be there. So it's "unauthorised".

      Presumably we'll find out more when their witch huntinvestigation has worked out who to sackdrawn it's conclusions.

  3. Glenn Amspaugh
    Holmes

    Will this impact the workings of the monitoring code burnt into the chipsets?

  4. noodle heimer

    A few years back, I had an SSG 550 series go titsup and pulled the memory for a peek.

    The workstation I was looking at it on pointed out that there was a trojan in the filesystem.

    My impression is that Juniper's been a target for this kind of thing for a long time. I'll need to see where the sample is - I'm fairly sure I still have it or can find it.

    1. Anonymous Coward
      Anonymous Coward

      More than likely it was just a false positive from your AV app, seeing as the AV probably doesn't grok the binaries (they're probably ELF vs Windows PE).

    2. Anonymous Coward
      Anonymous Coward

      "My impression is that Juniper's been a target for this kind of thing for a long time."

      And maybe see if it's GCHQ, NSA or PRC?

  5. David Roberts

    Conspiracy or cockup?

    Did some naive engineer stick in some "special" code just to make support easier. Avoid all this juggling of one time passwords for remote support? Saw this kind of thing done a long time ago and people who should have known better didn't think "security breach" but thought "isn't that clever".

  6. a_yank_lurker

    From 2008?

    It has been awhile, I wonder how many have been quietly using this bug.

  7. Anonymous Coward
    Anonymous Coward

    I guess they've finished their full-take NSA program and are trying to get into heaven now.

  8. Chris King

    They probably won't care anyway

    ScreenOS 6.2 is already EOL, 6.3 has EOL extended to 2021 along with some of the hardware platforms.

    I had lots of grief with their low-end SRX kit as well. Oh dear, this new version of JunOS won't run on your 512Mb SRX100 and licencing the High Memory Option to turn on the other 512Mb already in the box won't save you either. Would you like to buy an identical SRX100 with a 2Gb DIMM in it to replace it ?

  9. bazza Silver badge

    So That's How Well...

    ...their code review process works. Seven years.

    Sigh...

    For a company whose entire offering relies on them having a reputation for doing things properly, they don't seem to have done that very well. They've just learned that their system of code review has been pointless all along.

    So what else is lurking in their code base, how are they going to find it, and what procedures are they going to impose on their staff to ensure that this doesn't happen again? Proper multi-team clean room review is very expensive, but not half as expensive as destroying your entire business by going without it and running into something like this.

  10. This post has been deleted by its author

  11. Anonymous Coward
    Anonymous Coward

    'tis the season...

    Sales of Bacofoil on the up I see

  12. ForthIsNotDead

    Back door

    See title.

  13. naive

    Closed source considered harmful

    So much about the "security" provided by appliances from big names. Better invest some time in getting VPN's to run on Linux boxes. Unless Snowdon publishes some revelations on this, for sure other networking box shops will have this type of code too, if only to get rid of this nosy IRS guy looking for trouble in the books.

    1. Anonymous Coward
      Anonymous Coward

      Re: Closed source considered harmful

      Anyone who says "closed source considered harmful" and considers it a 100% serious statement does not deserve to be remotely affiliated with the IT industry.

      There are *countless* examples of where the open source that many hail as the panacea has delivered facepalm moments.

      We could, for example, cite any number of OpenSSL vulnerabilities.

      Or perhaps more recently the big song and dance that was made over the latest Joomla vulnerability, which, if you look into their recent vulnerability list is just *yet another* failure to perform input validation on data from untrusted sources, a security requirement that you would even find in a "programming for dummies" book.

      So please. Wipe the open source smugness off your face. There are examples of good and bad in both open and closed source, and indeed, there may well be more examples of "harmful" in open source because not all projects are subjected to the same degree of scrutiny of the same quality.

      1. CAPS LOCK

        Re: Closed source considered harmful

        At least with open source cock-ups you can look at them and decide how, or even if, you're affected, Closed source? Potentially no information whatsoever.

        1. Anonymous Coward
          Anonymous Coward

          Re: Closed source considered harmful

          Oh don't give me that old chestnut !

          If you can't read source code with a sufficiently security trained eye then you're in the same boat as the closed-source brigade !

          1. CAPS LOCK

            Re: Closed source considered harmful

            Rubbish. If I can't read it I can find someone who can. Therefore I am in a very different boat.

            1. Anonymous Coward
              Anonymous Coward

              Re: Closed source considered harmful

              Load of codswallop and you know it "CAPS LOCK" !

              Large companies, such as Amazon, no doubt have either employ "someone who can" or have the resources to "find someone who can".

              That hasn't stopped them being caught with their pants down when faced with vulnerabilities in open sourced software and having to go round patching stuff in a hurry.

              Both open and closed source are likely to have security bugs in them, its a fact of life of programming being done by humans.

              But in the case of open source:

              (a) The quality of programming can vary widely by open source project depending on how careful they are in their code review process (i.e not many go to the extremes that the OpenBSD crowd do, for example)

              (b) The ease of firing up projects on Github (or other platforms) and the ease of merging in pull requests from minimally vetted third parties only further contributes to (a).

              (c) I am no mathematician, but given the significant number of "popular" open source projects vs a smaller number of "popular" closed source projects, the statistics are likely to tell you that you have a higher chance of being caught out with vulnerabilities.

              A typical Linux installation for example, even a fairly minimal "server" version has dependencies on how many third-party open source packages ? Are you or your "someone who can" seriously going to sit there reviewing the base code and then every single commit that comes after it ?

              Same goes for stuff like OpenSSL.... you would have thought that given what OpenSSL does, and its prominence everywhere from Enterprise to Home, that enough people like you or "someone who can" would have picked their way through the source code.

              But the reality of life (and the reason that major projects such as OpenBSD,Mozilla and Wikipedia end up having to have cash-collection begging sessions), is that behavior in the Open Source world is no different to the Closed Source one. In other words, other than core commiters and other people who choose to subscribe to (and actually read and contribute to) the "dev" mailing lists, the vast majority of the Open Source community takes without giving back anything (not even code review).

              Realistically the only people who really do security code review on open source projects (other than those few projects with a distinct security focus such as OpenBSD) are pentesters seeking a bit of free publicity, or government agencies seeking an exploitable avenue.

              1. CAPS LOCK

                Re: Closed source considered harmful

                What? Did you even read my original post? Clearly not.

  14. Bronek Kozicki

    This might have been a bug, poorly designed "support feature", rogue developer or something more sinister, we might never know.

    However what worries me is that the state wants to make such backdoors a norm, using individual developers to insert them and then making it a crime either to refuse to cooperate or to tell about such a thing to anyone - including MPs or judiciary. These are the provisions of the new snoopers charter, being considered here in UK. This is scary stuff.

    1. Paul Smith

      That doesn't worry me...

      It would be a government contract so it is never going to work.

    2. Destroy All Monsters Silver badge

      > we might never know

      we will never need know

      VENDOR DROPPED!

  15. Prst. V.Jeltz Silver badge

    Fail of the year

    is that a thing? if not El reg should implement it. Wonder what the other contenders are

    1. Anonymous Coward
      Anonymous Coward

      Re: Fail of the year

      OPM would be my vote for clear winner, but there have been plenty of other contestants.

  16. Anonymous Coward
    Anonymous Coward

    No reassurance they're more secure now

    So, potentially an unknown actor has been able to access their network, inserting code, at least some years ago.

    If that actor (or another) still has access... this round of patching won't help. They may just lie low for a few weeks/months (or just seconds), then install new "unauthorised code" to re-enable the functionality.

    If this is the only info Juniper are able to come up with, then they should be removed from approved purchasers lists.

  17. chris 17 Silver badge

    So whats in the Huawei code then?

    Remember when BT ditched Marconi for Huawei for their 21CN project, security bods were up in arms that the code couldn't be trusted yet BT ploughed on regardless, shuttering Marconi in the process. Now unauthorised code has been found in JunOs, that unencrypts encrypted traffic, what will be found in Huawei's code if anyone bothers to check?

    1. Anonymous Coward
      Childcatcher

      Re: So whats in the Huawei code then?

      "Now unauthorised code has been found in JunOs"

      JunOS (L2/3 switches) is not ScreenOS (routers I believe). Now I know that JunOS looks suspiciously BSD based, probably FreeBSD with lots of stuff on top. I presume that ScreenOS is similar. So you get the worst of both the open source and closed source worlds in a hybrid. I use a lot of pfSense boxes which are based on FreeBSD. I watch them quite closely and I haven't seen them decrypting their own VPNs - IPSEC and OpenVPN are the ones I use, more are available.

      It seems odd that in eight years, no one has taken a look at the packet contents going through their Juniper routers, eg by spanning ports. An IDS is also likely to flag odd flows and someone would have seen that before now.

      There's more to this story.

      1. Anonymous Coward
        Anonymous Coward

        Re: So whats in the Huawei code then?

        Agreed... review the code after seven years? Something must have triggered it.

    2. Anonymous Coward
      Anonymous Coward

      Re: So whats in the Huawei code then?

      That just means their unauthorised code instead of our unauthorised code.

      Same play, different actors.

  18. patrickstar

    When I first read this, I immediately thought of SWIFT. They (atleast back when I worked with it) used Juniper VPN gear, and the information would certainly be very interesting to various spook agencies. The actual messages are MACd/signed so compromising the VPN wouldn't give you any immediate financial gain, but the message content is plaintext before going out on the VPN and thus ripe for harvesting.

    What's interesting is that the timeline for the Juniper compromise seems to line up with when the US lost unrestricted access to SWIFT data...

    And no, an IDS wouldn't help against this unless the attack was implemented by a complete moron. Even something blatant like sticking an encrypted copy of the session key in the relevant messages would just be random data on the wire. Hell, even if you are actually looking at the traffic dumps and know the protocol chances are there is something in it that could hold 16-32 extra high-entropy bytes without raising an eyebrow.

  19. Anonymous Coward
    Anonymous Coward

    Further investigation is ongoing

    People are looking into it further. Seems like it's related to the NSA-sponsored Dual_EC_DRBG backdoor. Possibly someone's modification of that to make it easier for themselves too:

    https://www.imperialviolet.org/2015/12/19/juniper.html

  20. Henry Wertz 1 Gold badge

    elliptic curve

    Per the link AC above points to, there are two vulnerabilities here. The ssh/telnet administrative access one (which sounds like some kind of programming blunder, but there's no actual info on it yet except that it exists and is being patched) and the VPN one. The link discusses the VPN change... the VPN uses an elliptic curve-based pseudo-random number generator, and the patch changes the constants fed into this PRNG to initialize it. So speculation would be that the former values were found to be exploitably weak. I'll leave it as an exercise to the reader to decide who would want to snoop into VPNs.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like