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."
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.
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..
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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.
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 mass communications surveillance. It that case, Congress had to pass a law giving the telecoms and the NSA backwards immunity from prosecution and civil lawsuits.
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.
How did it get signed with his key if he didn't do it?
His system is compromised with a dozen backdoors, and CIA / Shin Bet signed it with his key?