11 ms·
Unauthorized code in Juniper ScreenOS allows for administrative access
- tptacek 11y agoHoly shit. You thought you'd read the important security news of the day on HN, but, nope: Netscreen VPNs were backdoored!
- blacksmith_tb 11y ago"Unauthorized" seems strangely vague - does that suggest something was released without code review, or that an attacker actually managed to get something into their codebase?
- tptacek 11y agoIt pretty strongly suggests the latter: that the code was malicious.
- bch 11y agoI don't know their organization/development structure, but couldn't it also mean (for example) an overzealous intern committed where not authorized, and it passed into a production release? It's early to tell, and hard to tease from Junipers message. On the one hand, one might say they'd like to see more info from Juniper, but on the other, courageous of Juniper to be as forthcoming as they are.
- marshray 11y agoIf it had been simply an overzealous intern, wouldn't they have just announced that like a normal security bug?
- bch 11y agoI guess the question is: "why qualify the bug at all?" and work backwards. If it's a bad actor that did this, did they qualify it because the effects are so heinous they don't want to take responsibility for the code (but admit to being hacked)? If it were an intern, they are still disavowing the code, but admitting something slipped through audit cracks. What's worse, or what's the motivation (and cost) for qualifying the flaw? I don't know the answer, just putting out a question. [Edit: lots of swype typos]
- mpeg 11y agoLots of network devices don't do any kind of real validation of the updates they get from a remote server, beyond using SSL which only checks that the origin is correct. A while ago I accidentally stumbled upon the file servers that served updates for a major router manufacturer. The host vulnerability itself was reported and fixed, but I doubt they told their clients (the router company) anything. In that case, anyone who found the vulnerability could have modified the binary blobs, I wonder if this is a similar case.
- earlz 11y agoheh I found such a thing once for modems, wasn't writeable, but for a device that's not suppose to have public firmware files, it was interesting. Included old versions and probably debug versions and internal docs too, but that stuff scares me too much to look at more than the initial file listing that happened to be indexed by google heh
- jlgaddis 11y agoIt sounds much more like someone made their own "contribution" to the source code. For JunOS, updates are digitally signed (and verified when installing) so any modifications would have had to occur before the images were built, but I really can't remember if ScreenOS updates are signed or not (it's been a long time).
- redbeard0x0a 11y agoIt seems that an exploit in ScreenOS that is this large and knowing some of the things the NSA has been up to over the past few years. The coincidences are a little scary. Looking at the leaked catalog of NSA Exploits, you find that the NSA had a backdoor for Juniper equipment called FEEDTHROUGH: > 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. (http://www.spiegel.de/international/world/catalog-reveals-nsa-has-back-doors-for-numerous-devices-a-940994.html http://www.spiegel.de/international/world/catalog-reveals-ns...)
- geofft 11y agoShould we take that as a dysphemism for "code that wasn't security-reviewed by someone who should have been Cc'd on the review" instead of the much more obvious "malicious commit, either from an employee or an attacker"?
- hcf 11y agoThe former would be authorized but unreviewed, unauthorized seems to mean they got owned.
- deleted 11y ago[deleted]
- mhurron 11y agoI doubt they would be so open if that were the issue. My bet is unreviewed code or including an open source library without proper oversight. A revelation that their code repositories have been compromised and injected code has been released would call into question all of Junipers products.
- dogma1138 11y agoIf it was an open source library that was imported there would be a link to the CVE affecting that library most likely and that CVE would've been updated to announce that it affects additional systems (JUNOS/ScreenOS) this would usually not trigger a completely new CVE from being issues (i.e. Heartbleed and Shellshock which got updated for weeks and even months when new systems were discovered to be affected). The "unauthorized code" also introduced 2 separate and unrelated vulnerabilities one which allows you to bypass the authentication by some means (logs you in as a SYSTEM user), and another which allows you to decrypt VPN traffic. The overall phrasing (knowledgeable attacker), the fact that a fresh CVE was issued, and the fact that 2 unrelated but very specific vulnerabilities were introduced into the system makes me think that this was more intentional than just an issue with importing code from a 3rd party.
- 11y ago
- reiger 11y agohttp://arstechnica.com/security/2015/12/unauthorized-code-in-juniper-firewalls-decrypts-encrypted-vpn-traffic/ http://arstechnica.com/security/2015/12/unauthorized-code-in...
- frik 11y ago"It's not clear how the code got there or how long it has been there. An advisory published by the company said that NetScreen firewalls using ScreenOS 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20 are affected and require immediate patching" If the use a Subversion/Git code repo to maintain their codebase, they should be able to track down who wrote the code and when.
- fabulist 11y agoUnless someone tampered with the logs, of course.
- tlrobinson 11y agoIt's trivial to forge authorship in VCSs like svn and git, unless authors regularly sign commits with GPG or something.
- creshal 11y agoexport GIT_AUTHOR_NAME="Barack Obama" export GIT_AUTHOR_EMAIL="potus@whitehouse.gov"
- zaphirplane 11y agoThat's the who not the when or how
- radialbrain 11y agoFor the when: GIT_COMMITTER_DATE="Tue Dec 8 12:33:03 2015 +0000" git commit --date="Tue Dec 8 12:33:03 2015 +0000" That will change the commit and author dates.
- snowpanda 11y agoThis might not mean anything, but NetScreen-5GT 6.2.0r15 (The first affected version) was the first release with a SHA-1 sum. April 2015 is the first archive of this page I could find.[0] I wonder if the reasoning behind the SHA-1 is (possibly) that they were starting to notice some strange activity. I applaud them for disclosing all of this. That could not have been an easy thing to have to do. [0] https://web.archive.org/web/20150422145246/http://www.juniper.net/support/products/screenos/ns5gt/6.2/#sw https://web.archive.org/web/20150422145246/http://www.junipe... Archive link: https://archive.is/jdw13 https://archive.is/jdw13
- adrtessier 11y agoHoo boy, most of these things don't worry me, but this one does. I'm semi-responsible for some Juniper gear, thankfully all Junos (BSD) based, but I no longer trust any of it if this is malicious injection vs. a bad review. However, what the hell can I do? I can't audit the code. I trusted Juniper, and now I'm stuck with that trust being burned. Running to any other proprietary network vendor is just as uncertain. If Junos gets a bulletin, I have a lot of work on my hands very soon, as do a good chunk of service providers. I remember there being rumors of a certain three-letter agency saying they had some type of exploit for the Cisco ASA as well; I wonder if it was something this deep, vs. just a run of the mill RCE vuln. This is one more reason to use open-source products for actually security-sensitive systems, maintain a good amount of defense in depth, and do a little bit of auditing of the code you're using yourself. More often than not these days, it sure pays to be paranoid. EDIT: At the same time, this also really makes me respect Juniper more than I have previously. A company that finds this internally, on their own audit, could have patched it silently and said nothing about it to anybody. It probably would have been better for them PR-wise. The honesty is worth me not jumping ship to another (probably compromised) proprietary vendor, but you betcha if I can get away with it, I'll run something open-source and community audited when I can.
- jlgaddis 11y agoIf JunOS gets a bulletin, the whole Internet has a lot of work on its hands. If JunOS gets a bulletin, shit, that's really, really bad. I feel it's very likely that the NSA had something to do with the recent Cisco ROMMON "discoveries", so it would not surprise me one iota if they were involved here as well (although it's obviously pretty early to speculate on something like that -- and impossible to {dis}prove).
- adrtessier 11y agoI am eagerly awaiting the incident report on this, although I find it unlikely we'll ever hear anything more than this from JTAC and friends. If this is the work of an intelligence agency, it will likely be gagged under the guise of "national security" unless there's a press-worthy indictment coming out of it.
- ossreality 11y agoCan someone detail how widely Juniper/ScreenOS is deployed in the wild?
- olivah 11y agoI got 8 boxes deployed for ~1,000,000 users
- NetStrikeForce 11y agoIt was a best seller before Juniper started using JunOS on their new firewalls (SRX) and it continued for a while due to being rock solid and their ability to do pretty much anything in a fairly easy way. I remember working with my first SRX in 2009 and nowadays I still talk to customers rocking ScreenOS devices. I've lost any trust on them due to this news, of course, but boy their OS and feature set was awesome... I did like them so much that I bought a tiny NetScreen 5GT a few months ago for £10 only to gather dust on my desk for weeks, until I gave it away to a colleague that had a better use for it :) Anyway, I derailed. They were everywhere and they're probably still around in many SMBs.
- marshray 11y agoIsn't this somewhat unprecedented: a major vendor announced their source base has been actively compromised by a malicious party? If so, this is a potentially industry-changing event.
- nostrademons 11y agoNot really: https://en.wikipedia.org/wiki/Operation_Aurora https://en.wikipedia.org/wiki/Operation_Aurora http://www.nytimes.com/2014/03/23/world/asia/nsa-breached-chinese-servers-seen-as-spy-peril.html http://www.nytimes.com/2014/03/23/world/asia/nsa-breached-ch...
- marshray 11y agoNote how information about Operation Aurora always carefully stops just short of saying that any source code was modified. Whereas the NYT story is not a statement from a vendor.
- nostrademons 11y agoTechnically, this announcement also stops short of saying that any source code was modified. It just says that they "discovered unauthorized code in ScreenOS that could allow a knowledgeable attacker to gain administrative access to NetScreen® devices and to decrypt VPN connections". We all interpret that as a hacker having placed a backdoor there, just as we interpret the Operation Aurora announcement as the Chinese government placing a backdoor in GMail and the NYTimes article as the NSA placing a backdoor in Huawei routers. We are probably not wrong in this assumption. But the same CYA deniability is in all three.
- DCoder 11y agoThere was also https://lwn.net/Articles/57135/ https://lwn.net/Articles/57135/
- cypherpunks01 11y agoThat is a certainly a compromise attempt, but I wouldn't call that 'actively compromised'—looks like a secondary CVS mirror repo was pushed to, and it was noticed "quickly". No damage done there.
- lifeisstillgood 11y agotl;dr Project aurora was a series of attacks in 2010/11 where Chinese attacked the SCM of major companies. Juniper may have had its SCM polluted without going through normal review processes And so signing code patches looks like a good idea.
- fabulist 11y agoJuniper hasn't released nearly enough details to conclude that this was related to Operation Aurora.
- lifeisstillgood 11y agoI meant that the implication seems to be the code got there not by an authorised committer adding bad code, but by external party adjusting the SCM - the conversation seemed to be heading off into wilds of "code review practises"
- late2part 11y agoYour government is illegaly modifying commercial software so they can spy on you without warrants. Your government is doing this through illegal breaking and entering, or by paying people to defraud their employers, or by using extortion to force people do these illegal acts. Your government put CISA (Warrantless Wiretaps) into the budget bill. Wake up. Vote against any elected official that supports these things. Tell your elected officials you want your privacy and you will work to put them out of office if they don't defend it.
- x5n1 11y agoDon't hate me I voted for Kodos.
- rmc 11y agoThey aren't my government. This is the actions of a foreign government.
- antocv 11y agoIts laughable that you still think, despite this all, that you, a mere peasant, still has any kind of power in government, in policy/law making. You should wake up.
- firebones 11y agoSounds more like an insider committing an obfuscated exploit, or a plausibly deniable bug. Props to Juniper for owning up. Unless that is part of the con...
- nathanb 11y agoI work for a company which makes network devices. We've detected many hostile intrusions in our network. If you make hardware or software that runs in enterprise datacenters, someone is surely going to be trying to steal your source code to find exploits and possibly put backdoors in. We use multi-factor authentication just to get in the corporate network and a separate, airlocked engineering network to store our IP. From what I've talked to from my colleagues at other major device manufacturers, this is becoming the industry standard (seven years ago I scoffed at Ericsson's paranoia for having a sequestered engineering network. Turns out they just saw the attacks earlier than we did). In our case, doesn't seem to be the NSA. Looks more like China. Could easily be either one, or yet another party. This is the world we live in.
- beagle3 11y agoI was doing this for a fintec company in 2002, and was scoffed at by just about everyone. These things have been going on since the world became connected (somewhere in 1992 or so), and have been getting prevalent and intricate - but they are not new.
- ghshephard 11y agoWhen I set up the Stock Options system at Netscape (as the Desktop Support guy) back in 1997, It consisted of two computers, connected to each other via a switch, in a Locked room, with a wall all the way to the ceiling to reduce false-ceiling access, with that room also located inside the Secure Legal Office Space. Systems were backed up daily by the users, using encrypted backups to Zip Drives. It's interesting how when you don't know what the hell you are doing, you sometimes do something reasonably secure by pure happenstance. (Also, I had probably read too much Bruce Schneier when I was a teenager.)
- beagle3 11y agoWhat exactly did the Stock Options system do? Was it the registry of options? Did the accounting department have such a secure setup?
- 11y ago
- kccqzy 11y agoCan someone explain how the code is able to decrypt VPN traffic? I'm no expert on VPNs but I thought they provide end-to-end security and the protocols could detect tampering?
- NetStrikeForce 11y agoIf I have access to one of the endpoints I can read the decrypted traffic. It doesn't necessarily break the VPN, but it kills its purpose. In other words, why won't you go the easy route and just sniff the traffic where it's already the decrypted?
- seanieb 11y agoSome VPN's terminate SSL at this point. So the connection from the client to the server is encrypted, but the internal network traffic in the data center is sent unencrypted on the private network.
- cheeseprocedure 11y agoThere is speculation it compromised the cryptography used for VPN traffic, enabling someone with access to that traffic to decrypt it through brute force: https://twitter.com/matthew_d_green/status/677871004354371584 https://twitter.com/matthew_d_green/status/67787100435437158...
- yuhong 11y agoAn attempt at a diff: https://gist.github.com/hdm/107614ea292e856faa81 https://gist.github.com/hdm/107614ea292e856faa81
- secfirstmd 11y agoI think a lot of the focus here is on technical penetration of organisations. Much easier in many cases to just do a human intelligence penetration of an organisation to put the code in place.
- rmdoss 11y agoTLDR: ScreenOS was backdoored.
- chiph 11y agoThere's no proof at this stage that a government agency is behind this. It could easily have been an employee inserting this code in an attempt to blackmail the firm, or perhaps to gain financial advantage by learning corporate secrets that would allow them to beat the stock market. Hopefully there are source-control logs that show when this alteration was made and by whom, but given how hardware companies treat software I doubt it.
- hdmoore 11y agoIf anyone is interested, I have been working on diffing the code for the backdoored vs patched versions: https://github.com/hdm/juniper-cve-2015-7755 https://github.com/hdm/juniper-cve-2015-7755