[Infowarrior] - Researchers Solve Juniper Backdoor Mystery; Signs Point to NSA

[Richard Forno]

(But I'm sure Congress and the FBI will see no problem in continuing to push for a "good guys only" backdoor in other systems, because, ZMGTERRORISM.  The irony is lost on those clowns.  --rick)

Researchers Solve Juniper Backdoor Mystery; Signs Point to NSA

Author: Kim Zetter. Kim Zetter	Security

http://www.wired.com/2015/12/researchers-solve-the-juniper-mystery-and-they-say-its-partially-the-nsas-fault/

Security researchers believe they have finally solved the mystery around how a sophisticated backdoor embedded in Juniper firewalls works. Juniper Networks, a tech giant that produces networking equipment used by an array of corporate and government systems, announced on Thursday that it had discovered two unauthorized backdoors in its firewalls, including one that allows the attackers to decrypt protected traffic passing through Juniper’s devices.

The researchers’ findings suggest that the NSA may be responsible for that backdoor, at least indirectly. Even if the NSA did not plant the backdoor in the company’s source code, the spy agency may in fact be indirectly responsible for it by having created weaknesses the attackers exploited.

Evidence uncovered by Ralf-Philipp Weinmann, founder and CEO of Comsecuris, a security consultancy in Germany, suggests that the Juniper culprits repurposed an encryption backdoor previously believed to have been engineered by the NSA, and tweaked it to use for their own spying purposes. Weinmann reported his findings in an extensive post published late Monday.

Security experts say the attack on Juniper firewalls underscores precisely why they have been saying for a long time that government backdoors in systems are a bad idea—because they can be hijacked and repurposed by other parties.

They did this by exploiting weaknesses the NSA allegedly placed in a government-approved encryption algorithm known as Dual_EC, a pseudo-random number generator that Juniper uses to encrypt traffic passing through the VPN in its NetScreen firewalls. But in addition to these inherent weaknesses, the attackers also relied on a mistake Juniper apparently made in configuring the VPN encryption scheme in its NetScreen devices, according to Weinmann and other cryptographers who examined the issue. This made it possible for the culprits to pull off their attack.

Weinmann says the Juniper backdoor is a textbook example of how someone can exploit the existing weaknesses in the Dual_EC algorithm, noting that the method they used matches exactly a method the security community warned about back in 2007.

The new information about how the backdoor works also suggests that a patch Juniper sent to customers last week doesn’t entirely fix the backdoor problem, since the major configuration error Juniper made still exists.

“One [more] line of code could fix this,” Weinmann says. He’s not sure why Juniper didn’t add this fix to the patch it sent to customers last week.

Although the party behind the Juniper backdoor could be the NSA or an NSA spying partner like the UK or Israel, news reports last week quoted unnamed US officials saying they don’t believe the US intelligence community is behind it, and that the FBI is investigating the issue. Other possible culprits behind the sophisticated attack, of course, could be Russia or China.

If someone other than the US did plant the backdoor, security experts say the attack on Juniper firewalls underscores precisely why they have been saying for a long time that government backdoors in systems are a bad idea—because they can be hijacked and repurposed by other parties.

How the Backdoor Works

According to Weinmann, to make their scheme work, the attackers behind the Juniper backdoor altered Juniper’s source code to change a so-called constant or point that the Dual_EC algorithm uses to randomly generate a key for encrypting data. It’s assumed the attackers also possess a second secret key that only they know. This secret key, combined with the point they changed in Juniper’s software, the inherent weaknesses in Dual_EC, and the configuration error Juniper made, would allow them to decrypt Juniper’s VPN traffic.

The weaknesses in Dual_EC have been known for at least eight years. In 2007, a Microsoft employee named Dan Shumow gave a five-minute talk at a cryptography conference in California discussing discoveries that he and a Microsoft colleague named Niels Ferguson had made in the algorithm. The algorithm had recently been approved by the National Institute of Standards and Technology, along with three other random number generators, for inclusion in a standard that could be used to encrypt government classified communication. Each of the four approved generators are based on a different cryptographic design. The Dual_EC is based on elliptic curves. The NSA had long championed elliptic curve cryptography in general and publicly championed the inclusion of Dual_EC specifically for inclusion in the standard.

Random number generators play a crucial role in creating cryptographic keys. But Shumow and Ferguson found that problems with the Dual_EC made it possible to predict what the random number generator would generate, making the encryption produced with it susceptible to cracking. But this wasn’t the only problem.

The NIST standard also included guidelines for implementing the algorithm and recommended using specific constants or points—static numbers—for the elliptic curve that the random number generator relies on to work. These constants serve as a kind of public key for the algorithm. Dual_EC needs two parameters or two points on the elliptic curve; Shumow and Ferguson referred to them as P and Q.

They showed that if Q is not a true randomly generated point, and the party responsible for generating Q also generates a secret key, what they referred to as “e”, then whoever has the secret key can effectively break the generator. They determined that anyone who possessed this secret key could predict the output of the random number generator with only a very small sample of data produced by the generator—just 32 bytes of output from it. With that small amount, the party in possession of the secret key could crack the entire encryption system.

No one knew who had produced the constants, but people in the security community assumed the NSA had produced them because the spy agency had been so instrumental in having the Dual_EC algorithm included in the standard. If the NSA did produce the constants, there was concern that the spy agency might have also generated a secret key.

Cryptographer Schneier called it “scary stuff” in a piece he wrote for WIRED in 2007, but he said the flaws must have been accidental because they were too obvious—therefore developers of web sites and software applications wouldn’t use it to secure their products and systems.

The only problem with this is that major companies, like Cisco, RSA, and Juniper did use Dual_EC. The companies believed this was okay because for years no one in the security community could agree if the weakness in Dual_EC was actually an intentional backdoor. But in September 2013, the New York Times seemed to confirm this when it asserted that Top Secret memos leaked by Edward Snowden showed that the weaknesses in Dual_EC were intentional and had been created by the NSA as part of a $250-million, decade-long covert operation to weaken and undermine the integrity of encryption systems in general.

Despite questions about the accuracy of the Times story, it raised enough concerns about the security of the algorithm that NIST subsequently withdrew support for it. Security and crypto companies around the world scrambled to examine their systems to determine if the compromised algorithm played a role in any of their products.

In an announcement posted to its web site after the Times story, Juniper acknowledged that the ScreenOS software running on its NetScreen firewalls does use the Dual_EC_DRBG algorithm. But the company apparently believed it had designed its system securely so that the inherent weakness in Dual_EC was not a problem.

Juniper wrote that its encryption scheme does not use Dual_EC as its primary random number generator and that it had also implemented the generator in a secure way so that its inherent vulnerabilities didn’t matter. It did this by generating its own constant, or Q point, to use with the generator instead of the questionable one that had been attributed to the NSA. Juniper also used a second random number generator known as ANSI X.9.31. The Dual_EC generated initial output that was supposed to then be run through the ANSI generator. The output from the second random generator would theoretically cancel out any vulnerabilities that were inherent in the Dual_EC output.

Except Juniper’s system contained a bug, according to Willem Pinckaers, an independent security researcher in the San Francisco area who examined the system with Weinmann. Instead of using the second generator, it ignored this one and used only the output from the bad Dual_EC generator.

“What’s happening is they managed to screw it up in all the firmware, such that the ANSI code is there but it’s never used,” Weinmann told WIRED. “That’s a catastrophic fail.”

This put the output at risk of being compromised if an attacker also possessed a secret key that could be used with the Q point to unlock the encryption.

Weinmann and others discovered that the attackers altered Juniper’s Q and changed it to a Q they had generated. The attackers appear to have made that change in August 2012—at least that’s when Juniper started shipping a version of its ScreenOS firmware with a Q point that was different than previous versions used.

So essentially, although Juniper used its own Q point instead of using the one allegedly generated by the NSA, in an effort to make the Dual_EC more secure, the company hadn’t anticipated that attackers might break into Juniper’s network, gain access to critical systems used to build its source code, and change the Q again to something of their own choosing. And presumably, they also possess the secret key that works with the Q to unlock the encryption, otherwise they would not have gone to the trouble of changing Q. “It stands to reason that whoever managed to slip in their own Q [into the software] will also know the corresponding e,” Weinmann says.

This would not have been enough to make the backdoor work, however, if Juniper had indeed configured its system the way it said it did—using two random number generators and relying only on the second one, the ANSI generator, for the final output. But we now know it failed to do that. The backdoor remained undetected for at least three years, until Juniper recently discovered it during a code review.

Matthew Green, a cryptographer and professor at Johns Hopkins University, says that the ANSI failure raises additional questions about Juniper. “I don’t want to say that Juniper did this on purpose. But if you wanted to create a deliberate backdoor based on Dual_EC and make it look safe, while also having it be vulnerable, this is the way you’d do it. The best backdoor is a backdoor that looks like a bug, where you look at the thing and say, ‘Whoops, someone forgot a line of code or got a symbol wrong.’ … It makes it deniable. But this bug happens to be sitting there right next to this incredibly dangerous NSA-designed random number generator, and it makes that generator actually dangerous where it might not have been otherwise.”

The evidence that someone intentionally changed the Q parameter in Juniper’s software confirms what Shumow and Ferguson had warned: The inherent weaknesses in Dual_EC provide the perfect backdoor to the algorithm. Even if the algorithm was not intended to create a backdoor for the NSA, it made it possible for someone to piggyback on its weaknesses to turn it into a backdoor for themselves.

Even more worrisome is that Juniper systems are still essentially insecure. Juniper didn’t patch the problem by removing Dual_EC altogether or by altering the configuration so that the VPN encryption scheme relies on output from the ANSI generator; instead Juniper patched it simply by changing the Q point back to what the company originally had in the system. This leaves the firewalls susceptible to attack again if attackers can change the points a second time without Juniper detecting it.

The company, Weinmann says, should at least issue a new patch that makes the system use the ANSI generator and not the Dual_EC one.

“It would take one line of code to fix this,” he says.

And there’s another problem, he notes.

Juniper admitted that it had generated its own Q for Dual_EC, but it has not revealed how it generated Q—so others can’t verify that Juniper did it in a truly random way that would ensure its security. And in generating its own Q, it raises questions about whether Juniper also generated its own secret key, or “e” for the generator, which would essentially give Juniper a backdoor to the encrypted VPN traffic. This should worry customers just as much as the NSA holding a key to the  backdoor, Weinmann says.

“It now depends on whether you trust them to have generated this point randomly or not. I would probably not do that at this point,” he says, given the other mistakes the company made.

Green says because of the weakness inherent in Dual_EC, Juniper should have removed it back in 2013 after the Times story published and should do so now to protect customers. “There’s no legitimate reason to put Dual_EC in a product,” he says. “There never was. This is an incredibly powerful and dangerous code and you put it in your system and it creates a capability that would not have been there otherwise. There’s no way to use it safely.”

--
It's better to burn out than fade away.