Juniper's Backdoor Password Disclosed, Likely Added In Late 2013 (rapid7.com)
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."
Really should be using Cisco gear anyway.
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?
Violence is the last refuge of the incompetent. Polar Scope Align for iOS
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.
Bullshit, Juniper were notified by Snowden leaks their firewalls were under NSA attack:
http://www.spiegel.de/international/world/catalog-reveals-nsa-has-back-doors-for-numerous-devices-a-940994.html
So I expect them to watch their backs, and keep tight control of their software. 2 years to spot a backdoor? Even when you know you're under attack from a group that previously back-doored your products?
> "In the case of Juniper, the name of this particular digital lock pick is "FEEDTROUGH." This malware burrows into Juniper firewalls and makes it possible to smuggle other NSA programs into mainframe computers. Thanks to FEEDTROUGH, these implants can, by design, even survive "across reboots and software upgrades." In this way, US government spies can secure themselves a permanent presence in computer networks. The catalog states that FEEDTROUGH "has been deployed on many target platforms."
The suspicion is that they get paid. UK has just revealed its been spying on everyone for 15+ years using Telecoms act section 94, against non Telecoms companies, like hardware suppliers, database owners etc. Juniper could have been told to backdoor their hardware under Article 94.
Companies don't challenge it, because Article 7:
> "(7)There shall be paid out of money provided by Parliament any sums required by the Secretary of State for making grants under this section."
So the suspicion is that Juniper got paid to backdoor their kit, and now that all these revelations are coming out, (about how Parliaments have been deceived, how Ministers lied, Parallel Construction lies to Judiciary etc.) That Juniper is suddenly finding the backdoor and fixing it as if it just appeared.
Either they're incompetent, or they're complicity, but either way, other companies involvement in this scandal does not mitigate Junipers.
So where do we go? Russian hardware? Chinese hardware? If you think those countries are any safer, I have a bridge in a borough of New York city that's looking for a new owner...
I expect similar things are present in a lot of other security products, just that there they are still undiscovered. Criticizing Juniper for this is entirely the wrong reaction.
I don't understand your logic at all here. It's like saying, "Lots of people murder other people. Criticizing one murderer is entirely the wrong reaction."
You can -- and should -- criticize the murderer and look to solve the greater problem at the same time.
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."
Good people go to bed earlier.