How to log into any backdoored Juniper firewall – hard-coded password published The access-all-areas backdoor password hidden in some Juniper Networks' Netscreen firewalls has been published. Last week it was revealed that some builds of the devices' ScreenOS firmware suffer from two severe security weaknesses: one allows devices to be commandeered over SSH and Telnet, and the other allows encrypted VPN …
This post has been deleted by its author
As we all know, or should, the NSA, and its predecessor, associated, and adversary SigInt agencies were in business for at least forty or fifty years before the onset of modern terrorism. They have a lot on their plates, all of them, beyond what may be going on amongst terrorists, whether in the Middle East or elsewhere. The transmission modes and protocols have changed a lot, and all of them have added the new ones as they came into use while continuing to capture and analyze communications on the older ones like radio, telegraph, and telephone.
A great deal of intelligence analysis is produced from public sources, but it needs to be supplemented by, and validated by comparison with, information that is believed to be private. In the present environment, one tool is penetration of networks guarded by routers, something Juniper claimed to provide security against.
The men don't know but the little girls understand?
(Yes, I know Willie Dixon did it first...)
This has to be added to every dictionary, the <<< can save years plus the outside characters and spaces could really help brute force. It's not about guessing brute force but assuming they might have used this format somewhere else, or just being able to guess the = and spaces is a huge help
I hope they had to choose a password for someting else important, it should have been yX''k877'J@YgG~{T*[X? something not anything readable (assuming 21 characters was the limit).
It was found via disassembly - just not sure if it was before or after the announcement. What is published is a dissassembly.
It was also not done to be obscure (that would have been a crypted pwd). It was done so it is not seen on code source analysis/strings.
"It was found via disassembly"
Interesting concept given how so many EULA's prohibit "reverse engineering" - so even more interesting that Rapid7 have gone public; perhaps this is something the white hats should be doing with software from other major vendors, given that the black hats are likely to be already doing ...
Juniper's advisory says
During an internal code review, two security issues were identified.So, more than a cursory glance, and that is in fact how it was found. The CIO said that the code review identified "unauthorized" code. Whether or not Juniper will share with us how that backdoor got into their code repository remains to be seen; it's interesting that it seems to have been 'camouflaged' to look like a printf() command. That's not what you'd expect from some developer putting in a time-saving routine during development and then forgetting to remove it before release, it looks like something that was designed to stay under the radar in released software.
Depends how and where.
If this went in as assembler in the first place, I doubt that a cursory code review would have found it out. You can really obscure things if you want to :)
You can also obscure this in C too - use the format string in 4-5 places to print so it is fully legit. Then all you need to sneak in is one comparison which can be done simply by replacing == with = in the right place :) Even better - reuse an existing format string.
Exactly - there is existing history for security breaches that are deliberately hard to pick in code reviews, and when very well done are plausibly deniable as a simple slip of the keyboard, and not actually done with malicious intent.
Now in its eighth year - http://www.underhanded-c.org/
No, it is clear that the vulnerability was introduced into the source, it wasn't added as a hack to a binary image. The clue is in the password string. It is one of two things.
1. An intentionally coded backdoor with a password deliberately made to look like a legitimate printf format, so that simple strings analysis of the binary would not suggest it was anything special to any potential attacker.
1a. Actually is a legitimate printf format string that has been reused for an intentionally coded backdoor.
2. It is a legitimate printf format, and someone has tweaked the source code to make it work as a backdoor password by introducing a small but critical flaw in the program.
The difference is that option 1 should show up in a code review. Option 2 may be very hard to pick up. Languages like C and C++ contain a great many ways of burying such exploits in ways that take considerable care and expertise to notice, let alone figure out. Indeed both languages seem to encourage coding habits that make such things hard to detect.
It could be as simple as an extra * in the right place, or the difference between 1 and I in a carefully chosen spot.
"Now I have an itching to start disassembling all the firmware I have access to, then using each line as part of a dictionary attack against the devices to see what pops up."
You won't get far with that, if K = K1 XOR K2, with K being your backdoor, and K1 and K2 being the only strings in the binary ...
The only solution is disassemble the binary ... Possible but VERY time consuming.
Things like this are why I replaced the edge appliances at work with commodity boxes running OpenBSD and decommissioned the old Checkpoints and Cisco ASAs / edge routers. I trust publicly released by a bunch of highly paranoid programmers a lot more than a multi-billion dollar company nowadays, and things like this just help make my case for doing so.
If anything, ScreenOS's use of the Dual EC DRBG random number generator in its encryption is more worrying, and points to potential NSA interference.
I'm not sure I'd call it "more worrying" - it's hard to rank this sort of thing - but it's certainly worrying.
There has never been any good reason to use Dual_EC_DRBG, and particularly not with the default parameters. Security researchers raised very public concerns about it when it was first published. It doesn't offer good performance, and the possibility of a backdoor - and impossibility of proving there isn't one - has been well-known for years.
NIST Special Pub 800-90A, which specified Dual_EC_DRBG, also specified three other CPRNGs, so it's not like Dual_EC was the only choice even if you were going to sell to an entity that demanded a NIST-endorsed CPRNG. And even if someone insisted on Dual_EC (which would be mighty odd), 800-90A says you can generate your own parameters and shows you how to do it.
As with RSA BSAFE, the use of Dual_EC_DRBG is highly suspect. It indicates that either someone was persuaded to put in that particular NSA back door, or the crypto was implemented by people who weren't experts and couldn't be bothered to do some basic research. So either malice or incompetence. There's no other alternative.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
