Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Security Networking Hardware

Juniper's Backdoor Password Disclosed, Likely Added In Late 2013 ( 107

itwbennett writes: In a blog post on Rapid7's community portal Sunday, HD Moore posted some notes on the Juniper ScreenOS incident, notably that his team discovered the backdoor password that enables the Telnet and SSH bypass. Quoting: "Although most folks are more familiar with x86 than ARM, the ARM binaries are significantly easier to compare due to minimal changes in the compiler output. ... Once the binary is loaded, it helps to identify and tag common functions. Searching for the text "strcmp" finds a static string that is referenced in the sub_ED7D94 function. Looking at the strings output, we can see some interesting string references, including auth_admin_ssh_special and auth_admin_internal. ... The argument to the strcmp call is <<< %s(un='%s') = %u, which is the backdoor password, and was presumably chosen so that it would be mistaken for one of the many other debug format strings in the code. This password allows an attacker to bypass authentication through SSH and Telnet, as long as they know a valid username. If you want to test this issue by hand, telnet or ssh to a Netscreen device, specify a valid username, and the backdoor password. If the device is vulnerable, you should receive an interactive shell with the highest privileges."
This discussion has been archived. No new comments can be posted.

Juniper's Backdoor Password Disclosed, Likely Added In Late 2013

Comments Filter:
  • by Anonymous Coward on Monday December 21, 2015 @09:59AM (#51158151)
    Really should be using Cisco gear anyway.
    • Shouldn't that be modded "Funny" or at least "Redundant"?

      • by Anonymous Coward


  • Version control? (Score:5, Insightful)

    by Ecuador ( 740021 ) on Monday December 21, 2015 @10:17AM (#51158229) Homepage

    They must be using some sort of version control, right? So it should be trivial to find out who inserted the code and find out what exactly is going on (and prosecute those responsible). I mean, they'd like to "clear their name", wouldn't they?

    • i expect the answer will be something like 'David' where David will have no recollection of inserting anything like that.

      on a related note, is there a version control system that requires/allows users to cryptographically sign their commits? (i've only ever used svn and git)

    • Not necessarily anything conclusive. Commercial software providers can be somewhat hidebound about version control systems.

      I wouldn't be surprised if they were using CVS, and if multiple people didn't have access to the repository storage. In which case it's pretty trivial to insert the code in a way where it's impossible to tell the origin.

      Git with signed commits would be resistant to hiding the identity of the commit author, but a lot of corporations are paranoid about using it because of a perceived lack

    • Re:Version control? (Score:5, Interesting)

      by DarkOx ( 621550 ) on Monday December 21, 2015 @10:42AM (#51158373) Journal

      Yes but you have to consider the sophistication here. This was code designed to appear to be a debug statement. It might not be the very most cleverly obfuscated code in history but it was done by someone with a lot of knowledge about internal style and practices, and software development skills in general. Its like state sponsored as well. So we have at least the potential for a fairly advanced threat actor here.

      I would say its highly unusual a skilled pentester doing an internal test does not enjoy at least some success. Even if they don't end up pwning all the key systems etc, they will as rule at least be able to get on some developers or administrators boxes. Somebody always slips up up somewhere. Assuming this person was willing to be patient and wait weeks or months and was on the inside, maybe a plant who got hired on, they could eventually compromise some developers box and get hold of their creds, signing keys, or whatever was needed to do a source commit. So attribution might be easy but correct attribution might be a hard problem. Just because someone clicks 'blame' and Bob Smith shows up, does not mean Bob had much to do with it other than he clicked the wrong link sometime, used a backdoored tool, etc..

    • by Teckla ( 630646 )

      They must be using some sort of version control, right? So it should be trivial to find out who inserted the code and find out what exactly is going on (and prosecute those responsible). I mean, they'd like to "clear their name", wouldn't they?

      Where I work, our source code repository has logins but no passwords (unless you set one, and most developers don't, for whatever reason). My old boss used to check in things under my name.

      After I set a password, he used to throw code "over the fence" and have me check it in verbatim.

      Having your name/login on checked in code is not a terribly reliable way to identify the guilty party.

      (btw, I'm not saying my old boss ever did anything nefarious -- I'm quite sure he didn't -- I'm just demonstrating that your

  • by Anonymous Coward

    This interesting part will be the detective story for how it got into the code base.

    That story may have similar versions for other equipment.

    • by Anonymous Coward

      The register had article saying the devteam is in China.

      • by Anonymous Coward

        "The Capitalists will sell us the rope with which we will hang them."
        -Vladimir Lenin

        There are no words...

  • by sizzzzlerz ( 714878 ) on Monday December 21, 2015 @10:23AM (#51158269)

    Maybe there are reasons to still have concerns about them but this goes beyond just concerns. How did this get into Juniper's code baseline? Is there a mole, working inside the company or did their servers get hacked. Why would their code servers be accessible from outside the company in any case? More importantly, how does this get fixed? Has Jupiter sent out patches yet or done a complete review of their code to verify that there aren't other security holes? Can this backdoor be disabled without patching? IT groups in a lot of companies must be having the cold sweats about now.

    • Their code servers don't have to be accessible from the outside. Juniper has many employees, and hacking a single one of them is probably sufficient to sneak in a backdoor.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      I am, because Huawei actually stole Cisco code and even hardware designs in a breach in the 90s for the 7200 series. They should not be allowed to sell products in the western world. Chinese will cheat their way to the top.

  • by iCEBaLM ( 34905 ) <icebalm&icebalm,com> on Monday December 21, 2015 @10:24AM (#51158273)

    Whoever put it in was an Art of War fan....

  • Community Defense (Score:4, Insightful)

    by bill_mcgonigle ( 4333 ) * on Monday December 21, 2015 @10:27AM (#51158285) Homepage Journal

    Assuming Juniper has secure code audit logs and can personally identify the person who checked this in ("find the spook" if you will), will his identity be swept under the rug for some BS "privacy concerns" or will the Internet security community learn his identity so that he may be properly ostracized and precluded from any such future work?

    Juniper has the money to settle any threats of lawsuits arising from such disclosure - doing the right thing here is probably the only way people will ever trust Juniper again - it may even be a 'cost of sales'.

    If Juniper can't positively ID the perp then nobody can trust them going forward, so let's hope they can and do.

    • by xaxa ( 988988 ) on Monday December 21, 2015 @10:34AM (#51158321)

      Whoever put it there may well have hacked a developer's computer, whether they were working at Juniper or not.

      • by Anonymous Coward

        The last time we investigated this they had used the key of the director of development.....and the pc was 'leaking and receiving' data so 'who checked it in' doesn't tell you much.

    • I would very much hope that Juniper act publicly in this matter. Companies who are truly not in the feds pockets need to stand up for themselves. It's insane that it is even remotely legal for government agencies to do some of the things that are going on. However, you can bet if the person who did this did so because a government agency instructed him to do so that this will get covered up. When you have companies like Cisco altering shipping practices in the hopes of not having their gear intercepted and
    • And if Juniper was paid by the gov't to do exactly this, then what?

      • by arth1 ( 260657 )

        And if Juniper was paid by the gov't to do exactly this, then what?

        Paid? Forced is more likely.

        The secret courts working for your dollar!

    • by AHuxley ( 892839 )
      Did the world community of experts find much per Snowden "live" on the internet? Huge amounts of data split domestically and internationally without comment, question or any understanding flowed into a few nations security services without much wider public understanding. 24/7 collect it all was just never noticed ...
      Lots of years old traces, code samples, some splitter locations for collect it all...
      If any top regional security experts get too near that nations security services take over.
      Recall Opera
  • Good thing people stopped using ScreenOS before 2013. Seriously they've been migrating people onto the vastly superior SRX/JunOS platform for over a decade. ScreenOS is purely legacy garbage at this point. Only resistance I've seen to people leaving ScreenOS is having to learn a new CLI, aka IT lifers who hate learning.

  • by nimbius ( 983462 ) on Monday December 21, 2015 @10:44AM (#51158393) Homepage
    I blame windows for this, but mostly because im a neckbeard. This is every bit as much the IT Managers fault for investing in technology and not people. What we have in this foul year of our lord 2015 is infrastructure managed by support ticket and not seasoned admin and as an old unix hand Im frankly chuckling whenever I see revelations of backdoors. These vendors include this garbage because they understand the race to the bottom includes hiring a junior admin to handle the stack for half the cost of a greybeard. The consequence of this is paying the rest of that greybeard salary times three to Juniper, who in turn need a way to un-fsck the device once junior leaves, or completely cocks up the device.

    dont think of it as a backdoor. think of it as the technological equivalent of child safety locks or those little plastic outlet covers. The vendor doesnt trust you to handle the device on your own terms, because the majority of the vendors customers cant seem to make it much beyond the boot prompt before bricking the device. an argument could also be made that its not the fault of the admin here. Juniper took the logical, moneytrain route of locking away all their documentation to the licensed cloistered elite, so if youre out 3 admins of turnover and the support contract has been ignored for a month, that backdoor is likely getting used to bring you back into the loving embrace of the vendor.

    now for the soap box. Back in my day there were real repercussions for not knowing your kit. You couldnt just open a support ticket and wait for a fix on an HPUX handling thirty million transactions per second. You needed to have a good escalation path in your organization to make sure problems got solved quickly, and management has forgotten the value of the most expensive part of this equation, the greybeard. Maybe we never had good visibility, or our people skills were just mediocre, but i for one am ambivalent about this kind of dictatorial lording over appliance, SaS, and anything "cloud."
    • by Anonymous Coward

      Every network appliance vendor has backdoors (mostly), for your safety :D

      Synology, is at least creative in having a daily backdoor lol

    • "infrastructure managed by support ticket" I'd like to see how this works. In my experience, tech support at major vendors know very little of how their products work and won't admit when they don't have a clue on how to proceed. Once we get ahold of a manager's contact info we use it mercilessly to to get every case escalated.
  • by Anonymous Coward

    Juniper is saying they were hacked and that the code was likely produced by a state-sponsored entity, but has that been confirmed? It seems to me that given the FBI's recent statements about requiring encryption backdoors in various applications and network products is perhaps a cover for those manufacturers that have already started to comply with a secret policy put forth by the FBI/NSA. This situations kinda reminds me of what happened when it was found out that telecoms were giving access to the NSA for

    • by wjcofkc ( 964165 )
      A good argument. that will probably get modded up. For the sake of argument, I shall propose an alternate. If Juniper as a company overall did not know this was happening, it still looks like an inside job. Perhaps this is the true cost of handing out H1B Visa's left and right. If that is the case, that individual or those individuals are long since back in their country.
  • by Anonymous Coward

    Given reduced manpower and increased difficulty in obtaining change approvals at this time of the year, doesn't it strike anyone else a bit soon to be publicly listing the exact password to use? Also they're publishing unpacked Juniper software, which may ellicit a Cease and Desist.

    Yes I get that the bad guys could do this reverse engineering as well, but the reality is that there's a limited number of attackers with the engineering knowledge to proceed, compared to the much larger number of scipt kiddies

  • by JimMcc ( 31079 ) on Monday December 21, 2015 @12:26PM (#51159123) Homepage

    One thing that surprised me is that symbols were still in the executable. I'll admit that I'm kind of long in the tooth and have been out of the industry for 15 years now. It used to be that a standard practice was that the final compile had the symbols stripped out. It was done for space consideration mostly, which probably isn't a concern anymore, but also for security. Is it now standard practice to leave symbols in shipped code? If so, why? Yes it is somewhat of a security by obscurity, but leaving symbols in is like leaving the combination to your lock taped to the back of it, or at least a note as to where you've hidden the combination.

    • by TheCarp ( 96830 ) <> on Monday December 21, 2015 @03:34PM (#51160635) Homepage

      There is no actual security gain from stripping symbols. If the logic of the code allows for something to be performed which shouldn't be, then stripping symbols changes nothing at all.

      The most stripped symbols would do, is slow down a person reverse engineering the code, once done they still get their access and can reuse their knowledge, and even that assumes they don't have direct access to the source code...clearly a bad assumption here.

      Its similar to the old "no compilers in production". It doesn't actually protect you from anything but the most unsophisticated attackers. Which, admittedly, is a form of protection, but only from opportunists who don't care that much.

  • It should be trivial for the FBI to discover who did this and why. Unless, of course, the NSA doesn't want them to...

In seeking the unattainable, simplicity only gets in the way. -- Epigrams in Programming, ACM SIGPLAN Sept. 1982