Hoo boy, most of these things don't worry me, but this one does.<p>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.<p>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.<p>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.<p>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.
I 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.<p>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).<p>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.
This 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]<p>I wonder if the reasoning behind the SHA-1 is (possibly) that they were starting to notice some strange activity.<p>I applaud them for disclosing all of this. That could not have been an easy thing to have to do.<p>[0] <a href="https://web.archive.org/web/20150422145246/http://www.juniper.net/support/products/screenos/ns5gt/6.2/#sw" rel="nofollow">https://web.archive.org/web/20150422145246/http://www.junipe...</a><p>Archive link:<p><a href="https://archive.is/jdw13" rel="nofollow">https://archive.is/jdw13</a>
Your 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.<p>Your government put CISA (Warrantless Wiretaps) into the budget bill.<p>Wake up.<p>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.
Should 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"?
An attempt at a diff: <a href="https://gist.github.com/hdm/107614ea292e856faa81" rel="nofollow">https://gist.github.com/hdm/107614ea292e856faa81</a>
Isn't this somewhat unprecedented: a major vendor announced their source base has been actively compromised by a malicious party?<p>If so, this is a potentially industry-changing event.
"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?
Sounds more like an insider committing an obfuscated exploit, or a plausibly deniable bug.<p>Props to Juniper for owning up. Unless that is part of the con...
Can 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?
There'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.<p>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.
If anyone is interested, I have been working on diffing the code for the backdoored vs patched versions: <a href="https://github.com/hdm/juniper-cve-2015-7755" rel="nofollow">https://github.com/hdm/juniper-cve-2015-7755</a>
tl;dr Project aurora was a series of attacks in 2010/11 where Chinese attacked the SCM of major companies. Juniper <i>may</i> have had its SCM polluted without going through normal review processes<p>And so signing code patches looks like a good idea.
I 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.