13 ms·
Juniper screenOS authentication backdoor - master ssh password posted
- deleted 11y ago[deleted]
- _jomo 11y agoYou can telnet or ssh to a Netscreen device, specify a valid username, and the backdoor password <<< %s(un='%s') = %u. If the device is vulnerable, you should receive an interactive shell with the highest privileges.
- deleted 11y ago[deleted]
- ghshephard 11y agoFrom the post: On December 18th, 2015 Juniper issued an advisory indicating that they had discovered unauthorized code in the ScreenOS software that powers their Netscreen firewalls. This advisory covered two distinct issues; a backdoor in the VPN implementation that allows a passive eavesdropper to decrypt traffic and a second backdoor that allows an attacker to bypass authentication in the SSH and Telnet daemons. Shortly after Juniper posted the advisory, an employee of FoxIT stated that they were able to identify the backdoor password in six hours. A quick Shodan search identified approximately 26,000 internet-facing Netscreen devices with SSH open. Given the severity of this issue, we decided to investigate. Did you read that paragraph (It's the first one)? I think the downvoting occured because it didn't even appear that you clicked on the article. Presumably anybody reading HN on a regular basis would have had little difficulty understanding the content of that paragraph.
- biot 11y agoThe article already states: > 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. The fact that you thanked _jomo for explaining something that effectively quotes almost verbatim what the article tells you indicates you probably didn't bother to read the article. Like with asking help on various forums, it's generally appreciated (or expected, depending on the community) that you do some homework yourself to understand things, state your current understanding, and then ask for confirmation or clarification if your understanding is incorrect. Saying "ELI5 please" comes across as intellectual laziness on your part. If you haven't made any effort to understand an article in plain English (it's no scientific paper we're discussing) then why should others make that effort for you?
- _jomo 11y ago> 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. That's very clever from the attackers point of view, extra kudos to hdmoore for finding it!
- scrollaway 11y agoWell I definitely expect to find that password in the very next Person of Interest episode. :) This has gotten me to wonder just how much software out there is backdoored in such a serious and absolute way... Scary.
- Vexs 11y agoHuh, is that show coming back around? I kinda liked how they would spin current tech events, and the idea of an AI that spread itself over power boxes was neat to say the least.
- scrollaway 11y agoThey have a final season 5 scheduled for some time in the next few months. I'm very excited myself. It's the only show, other than Mr. Robot, that has plausible tech scenes and often drops real bits of hacky trivia, remaining very enjoyable for a techie despite the premise itself being far-fetched. And their political commentary on mass surveillance is beautiful. And the way it transitions from criminal procedural to scifi ... beautiful.
- joeyrideout 11y agoYou may also be interested in Continuum. I love that show for its spot-on perspective of present-day technology mixed with a believable vision of the future. Anecdotally, I remember reading that Continuum had a hacker writing their technical scenes -- news that didn't surprise me one bit :)
- jdiez17 11y agoIt was a matter of time before it leaked. If you're going to put a back door in, at least make sure only you can use it (Nobody But Us). Why didn't they use a keypair?
- _jomo 11y agoMy guess is a hardcoded public key would be easier to find in code and/or binaries, whereas this cryptic password was quite challenging.
- jdiez17 11y agoThat's what I thought as well, but it might have been worth the effort to obfuscate it. I mean, they must've known it was going to leak sooner or later, leaving a lot of vulnerable boxes behind.
- dogma1138 11y agoIt is obfuscated in a way that will still avoid detection during static code analysis and casual code review. This looks like debug or logging string builder which no one would give it a second look while glancing over it. Hashes and binary blobs will look out of place, same thing goes for intentionally obfuscated secure string builder. When you put in a back door the best one will always be the shortest possible complicating it will only increase the likelihood of it being detected. The sign of a true high level adversary isn't overly complicated and obfuscated software but one which is remarkably simple and elegant whilst still achieving the desired functionality. Obfuscation and complexity screams cyber criminals which care more about covering their own trail than ensuring functionality.
- psykovsky 11y ago>>> Obfuscation and complexity screams cyber criminals which care more about covering their own trail than ensuring functionality. spies, you mean? The NSA, that is
- nodesocket 11y agoForgive me if I am wrong, but these devices phone home right? Can't they just hot fix this over the air?
- zouhair 11y agoHow can we know that it is the only backdoor? Wouldn't be safer to just stop using Juniper's products altogether?
- ghshephard 11y agoOn the flip side - now that this product, and it's code base, is presumably under such close inspection by Juniper, perhaps Juniper's product is more secure than others that aren't going through such close review.
- dogma1138 11y agoIf othe back doors are as well hidden as this one it will take a while to find them out and even then you might not find all of them. ScreenOS has probably 2 decades worth of code in it, some of it is sure to no be well documented.
- ghshephard 11y agoOnce you know that your code has been corrupted, it would take a team of consultants put together by someone like ptacek a relatively short period of time to find the holes (and, at the same time, discover 10x or more code weaknesses that weren't deliberately put there.) If the toolchain wasn't corrupted, and this was in the original source code (C?) - it's not going to be too difficult to find in code review, if you are looking for it - but how many companies are willing to spend the time (and $$$) to review their presumed secure code for holes added by third-parties? Now that Juniper knows that their source-code/tool chain has been breached, they will be prepared to spend the money to clean it up - which, for any reasonable amount of code, will cost millions of $$$ if not tens of millions. I'm wondering if patio11/ptacek didn't show some pretty amazing foresight in tracking down the resumes of the top security intrusion people in the industry - I have to believe that the Ciscos, Junipers, and other security hardware/software companies in the world are going to be in desperate need of Top People, and are going to be ready to pay large sums of $$$ for fast service in this space.
- 11y ago
- ra1n85 11y agoBrutal. From conversations with other engineers, this is a very common network operating system with banks in Europe. Would not be surprised if urgent code reviews and security audits are taking place at the campuses of other large network software/hardware vendors.
- theklub 11y agoYeah, some people aren't getting sleep this week.
- revelation 11y agoSo, did they have time for a git blame yet? It's one thing to say you have found a backdoor, another is to clear up how it got there in the first place.
- StringyBob 11y agoIf you are capable of inserting this kind of backdoor, how easy is it to compromise a version control system? (or the login details of one of the programmers?). Is it possible to prevent history of the code being modified? Do DVCS use blockchains?
- hueving 11y agoIf a git commit is modified, every commit hash after it will change and will break every clone.
- deleted 11y ago[deleted]
- wosos 11y agoTrue, it could've been easier to use fake credentials from the start
- escape_goat 11y agoThat's a system that would still be entirely vulnerable to collision attacks, though, right?
- vishbar 11y agoI'd imagine it would be nearly impossible to generate a collision that a.) does what you want, b.) is small enough to be unobtrusive, and c.) can be discovered in finite time with the computing power reasonably available to NSA/GCHQ/insert SIGINT organization of choice.
- 11y ago
- kabdib 11y agoThis smells like: - Underhanded C . . . maybe. Seems difficult to just insert a strcmp in the middle of a sensitive piece of the login path - A compromised toolchain that is inserting the code Would love to hear what Juniper has to say about it, but I doubt that they will, or will be allowed to say.
- ghshephard 11y agoCompromised toolchain/Underhanded C perhaps explains why whoever did this didn't take even the slightest bit of effort to compare against a hash.
- rdtsc 11y agoThat was my first guess. Based on how password looked it could have been a multi-line split or some sort of other such trickery. A set of macros perhaps...
- stordoff 11y agoThat was my first thought on seeing the password: the string wasn't chosen per se; it was a string they could assemble (or block of memory reused) in a way that appears benign in a code review.
- buserror 11y agoActually, it's very likely the string was used for some other (valid) purpose and the pointer is being hijacked afterward -- it's VERY unlikely to appear as a singleton string constant anywhere. The password looks like what someone would put at the start of a function to trace stuff; and, there's very likely a macro that does that all over the software. Lets imagine what that might look like: #define TRACE(__f, ...) \ const char *tok="<<< " __f;\ printf(tok, __func__, __VA_ARGS__); u32 check_pass(const char *un, const char *tock) { u32 res = valid(un, tock); TRACE("(un='%s') = %u", __func__, un, tock); res += valid(un, tok); /* could look like a cut/paste blip... */ return res; }
- tw04 11y agoCan I just point out I find it hilarious reading about all the people debating how amateur it was to put the password into the code in plaintext was... all while ignoring the fact that this backdoor survived for 3 YEARS of code reviews? Obviously the way it was implemented was ingenious, and it likely far surpassed whoever put it there's wildest expectations.
- BinaryIdiot 11y ago> ignoring the fact that this backdoor survived for 3 YEARS of code reviews While I don't disagree with the rest of your comment it's possible that this portion of the code was only reviewed once (if at all) during the entire 3 years whereas your comment makes it sound like it was constantly reviewed over the period of 3 years.
- 7952 11y agoI wonder if it would be better to treat this as a technical defect that needs to be detectable at compile time through something like static analysis.
- sandworm101 11y agoSo ... if this is a backdoor for some three-lettered agency, what are the chances that this backdoor, even this same password, is present in other products?
- BinaryIdiot 11y agoUnlikely in my opinion. You don't reuse the same backdoor across any products if you don't want to be noticed. Reusing means someone could run some sort of statistical analysis and find a commonality. Ideally every product you get a backdoor into is one done in a different way so that even if one is found the others won't be found easily.
- rdtsc 11y agoI'd like to hear how this was discovered and who's name ended up on git blame line next to that password. I have done a malicious source code injection as part of a network security exercise at the university. That was before git or other sane source control and I basically inserted a semi-obfuscated piece of code in the source repository, which gave our team an advantage in the game (the game was to crack and find a weakness in a protocol, but the whole machine was a target/battlefield). The clever part was first rooting the server via suid vulnerability. I won the contest, but while doing it I thought, yeah, this shit will never work in the real world. And then this story made me remember that. That's pretty crazy.
- forgotpwtomain 11y agoGit does not give strong guarantees for authorship unless you are signing every single commit with GPG (which is only a recently available as of 1.7 or 1.8).
- nickpsecurity 11y agoI assure you it will and that's been known since Myer's landmark paper on Subversion a long time ago. Interestingly, I predicted your move in a post earlier (last para): https://news.ycombinator.com/item?id=10767504 https://news.ycombinator.com/item?id=10767504 Even university students come up with this approach. Status quo seems hopeless against nation states unless companies learn from the past and start doing high assurance at least where it counts. ;)
- rdtsc 11y agoYeah I remember it was an interesting thought process. I put so much energy into rooting the system, and after a short celebration when I got a root shell, it was a "well now what?" moment. We debated intercepting the trafic to the game server and retransmitting (a man in the middle), initially. Then I wanted to run a hidden process (with some system looking like name) that have injected java byte code into the running server to give our team an advantage, but that proved too difficult, so the idea to just change the source in the repo that the TA kept on the same machine, was kind of a boring and un-exciting conclusion. It didn't seem very clever at all and felt like giving up.
- deleted 11y ago[deleted]
- gbin 11y agoAnybody tried to see in their logs if someone used it ?
- rasz_pl 11y ago> We were unable to identify this backdoor in versions 6.2.0r15, 6.2.0r16, 6.2.0r18 and it is probably safe to say that the entire 6.2.0 series was not affected this sounds fishy, like Juniper trying to push users to upgrade from _non affected_ builds to a new firmware with a fresh set of NSA backdoors.
- jwildeboer 11y agoNot really fishy. The 6.3.x series is the only version that is under active development [1] so quite naturally it follows that at least since 2013 (EOL of 6.2) many users have upgraded to the supported version. A bit more disturbing IMHO is that you need an active support contract to even get the updates (based on information I got from Juniper customers, I couldn't find a direct confirmation on their site) meaning that aftermarket users are left in the cold. [1] https://www.juniper.net/support/eol/screenos.html https://www.juniper.net/support/eol/screenos.html
- rasz_pl 11y agoThat makes more sense. Juniper lied about older firmwares being backdoored to force old customers into fresh support contracts. Not as fishy, just more Oracle.
- Deregibus 11y agoIt'll be interesting to see a more in-depth look at the code surrounding this and some theories on how it could have been implemented in a way that avoided obvious detection. The naive assumption is that someone just added to the code: if(!strcmp(password, "<<< %s(un='%s') = %u")) return true; which is certainly possible, but seems too easily detectable and risky for someone on the inside, and too lazy for someone on the outside that had already gone through the trouble to get write access to the source. The string itself looks like it's part of some logging system, so my guess is that it already existed and was opportunistically chosen rather than created. If this was passed through a macro, then it's possible that the attacker didn't have to touch the auth code at all and may have been able to implement this by changing only a handful of characters in an area of code that was more amenable to obfuscation.
- pfortuny 11y agoA useful macro is a good way to prevent detection of these hacks.
- emillon 11y agoThat is my opinion too, but I would go even further and say that this change could have been made on the compiled binary. This kind of statement must take 10-15 bytes max to patch and the build boxes are typically less safe than source control systems.
- xorcist 11y agoWhy would you choose that particular password if you patched the binary? That particular string would stick out in a binary, it certainly looks more like source code.
- emillon 11y agoThat's assuming that this particular string was already present somewhere in the binary. Since it is only present as a reference, you would not see the string in a binary patch.
- 11y ago
- isido 11y agoNow that the cat's out of the bag, could the esteemed hacker(s) just post the source code, so that we can see how it was implemented :) (j/k)
- mmaunder 11y agoAnyone running ScreenOS was already scrambling as fast as they could to patch the issue before the backdoor password was posted. Just thought I'd point that out.
- _yy 11y agoYou wish. Some orgs move slowly.
- wepple 11y agoThis may be a good time to bring up the various big corps who are trying to prevent reverse engineering... while even they can't keep tabs on knowing what is actually being executed on the hardware we pay them for.
- rmdoss 11y agoIf you follow good security practices and restricted your SSH access, you were safe against it: https://twitter.com/danielcid/status/678907293770059776 https://twitter.com/danielcid/status/678907293770059776 If you are managing any login system, try to implement ip white listing whenever possible.