Slashdot Mirror
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."
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
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
The register had article saying the devteam is in China.
Um, given TFS, I'd say they put it in so they probably knew about it from day 1.
There are two types of people in the world: Those who crave closure
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 that were just spoon fed another attack to run over the Christmas period.
I work in the industry, and while there's not one major issue I can fault them on, it just feels wrong. Perhaps they need to consider that responsible disclosure doesn't just mean waiting until the vendor has released a fix, but to allow a reasonable time for users to be notified and organise installation of the patch. Perhaps they've lost touch with would a reasonable period of time to patch is. A security researcher may think, patch immediately, but in an organisation with a large deployment it's not as simple as this. I'd love to patch our devices as soon as the vendor patch is available, but with inperfect vendor updates, particularly with this vendor, an update is just as likely to break things as fix them, so testing has to be carried out first.
Well, if I buy hardware from China, it maybe has a Chinese backdoor.
If I buy hardware from the USA, it maybe has an USA backdoor and a Chinese backdoor.
So I buy hardware from China, thank you very much.