Resultados 1 a 7 de 7
  1. #1
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010

    [EN] Juniper breach has feds worried

    By Sean Lynga as Dec 18, 2015

    A big breach at computer networking firm Juniper Networks has federal officials fearing that foreign spies had access to the encrypted communications of the U.S. government and private firms for the last three years, according to a CNN report.

    The Sunnyvale, Calif.-based company announced Dec. 17 that it had discovered unauthorized code in its operating software that could allow a "knowledgeable attacker" to gain administrative access to its firewall and decrypt virtual private network connections. The advisory said Juniper had not received reports of the vulnerabilities being exploited.

    "Once we identified these vulnerabilities, we launched an investigation and worked to develop and issue patched releases for the impacted devices," Juniper CIO Bob Worrall said in a statement. "We also reached out to affected customers, strongly recommending that they update their systems and apply the patched releases with the highest priority."

    An FBI spokesperson declined to confirm to FCW that there is an ongoing FBI investigation into the breach, as the CNN report states. A Juniper spokesperson also declined to answer a question about any ongoing federal investigation.

    Computer scientist and cryptrography expert Matt Blaze said on Twitter that, "If nothing else, Juniper deserves credit for being forthcoming that there was a backdoor, and not just quietly rolling out a patch."

    The Department of Defense is among Juniper Networks’ big federal customers; dozens of Juniper products are on the Defense Information Systems Agency's Unified Capabilities Approved Product List.

  2. #2
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010

    Juniper Finds Backdoor in Its Data Center Security Software

    'Unauthorized code' that decrypts VPNs found in Juniper's ScreenOS.

    by Yevgeniy Sverdlik on December 18, 2015

    Juniper, during a routine internal code review, discovered unauthorized “backdoor” code in its ScreenOS software, which powers its firewall and VPN applications for data center, large enterprise, and carrier networks.

    The code can be used by an attacker who knows about its existence to get administrative access to devices running ScreenOS and decrypt VPN connections, Juniper senior VP and CIO Bob Worrall wrote in a security advisory issued Thursday.

    Juniper is one of the largest networking technology vendors for data centers and carriers.

    The company issued patches along with the advisory and recommended that customers running ScreenOS versions 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20 apply the patches “as soon as possible.” The affected versions indicate that the vulnerability may have been present since at least 2008, the year ScreenOS 6.2 came out.

    Companies use software firewalls to protect their networks from intrusion. They rely on VPNs to encrypt connections to their systems by authorized personnel over public networks. In other words, the vulnerabilities Juniper has identified are potentially responsible for gaping holes in enterprise security of many of its customers.

    At this point, Juniper doesn’t know when or how the unauthorized code ended up in the software, according to Worrall. He also mentioned that there’s no evidence that someone has exploited the vulnerabilities.

    The list of potential scenarios is long. Close to the top of it, however, is the possibility that the backdoors were introduced by the NSA or a foreign spy agency.

  3. #3
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010

    NSA suspected in Juniper firewall backdoors

    Dec 24 2015

    Security researchers suspect the United States' National Security Agency may have had a hand in the planting of unauthorised backdoors in Juniper's enterprise firewalls.

    The network equipment vendor last week issued an urgent security alert for its NetScreen enterprise firewalls, after discovering "unauthorised code" in the device operating system that allows them to be fully compromised.

    Juniper had discovered the code during an internal review. The backdoors - which had been in existence since 2012 - meant attackers could gain administrative access and decrypt VPN connections unnoticed.

    Researchers have now said the backdoors could have only been planted by a handful of governments due to their sophistication. But it is unclear how the Juniper vulnerability was planted or by whom.

    Juniper this week admitted to using the Dual_EC cryptography standard developed and promoted by the National Security Agency.

    Microsoft researchers determined in 2007 that the standard was flawed because the output of its random number generator could be predicted, enabling the system's designers or others to break the encryption.

    Many researchers believe files released by former NSA contractor Edward Snowden show the flaw was a deliberate effort by the spy agency to maintain eavesdropping capabilities.

    Juniper developed an alternate standard, but it was still based on the flawed algorithm pushed by the NSA, which paved the way for the security hole detailed last week.

    CEO of German security consultancy Comsecuris, Ralf-Philipp Weinmann, said it appeared the Juniper attackers tweaked an encryption backdoor previously believed to have been engineered by the NSA.

    He said they exploited weaknesses in Dual_EC as well as a mistake Juniper make in configuring its VPN encryption scheme for NetScreen devices.

    Weinmann said adding an extra line of code would have fixed the issue, but Juniper did not do so when it rushed out its patches last week.

    He said the patch might not therefore actually fix the backdoor issue.

  4. #4
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010

    NSA Helped British Spies Find Security Holes In Juniper Firewalls

    Ryan Gallagher, Glenn Greenwald

    Dec. 23 2015

    A TOP-SECRET document dated February 2011 reveals that British spy agency GCHQ, with the knowledge and apparent cooperation of the NSA, acquired the capability to covertly exploit security vulnerabilities in 13 different models of firewalls made by Juniper Networks, a leading provider of networking and Internet security gear.

    The six-page document, titled “Assessment of Intelligence Opportunity – Juniper,” raises questions about whether the intelligence agencies were responsible for or culpable in the creation of security holes disclosed by Juniper last week. While it does not establish a certain link between GCHQ, NSA, and the Juniper hacks, it does make clear that, like the unidentified parties behind those hacks, the agencies found ways to penetrate the “NetScreen” line of security products, which help companies create online firewalls and virtual private networks, or VPNs. It further indicates that, also like the hackers, GCHQ’s capabilities clustered around an operating system called “ScreenOS,” which powers only a subset of products sold by Juniper, including the NetScreen line. Juniper’s other products, which include high-volume Internet routers, run a different operating system called JUNOS.

    The possibility of links between the security holes and the intelligence agencies is particularly important given an ongoing debate in the U.S. and the U.K. over whether governments should have backdoors allowing access to encrypted data. Cryptographers and security researchers have raised the possibility that one of the newly discovered Juniper vulnerabilities stemmed from an encryption backdoor engineered by the NSA and co-opted by someone else. Meanwhile, U.S. officials are reviewing how the Juniper hacks could affect their own networks, putting them in the awkward position of scrambling to shore up their own encryption even as they criticize the growing use of encryption by others.

    The author of the 2011 GCHQ document, an NSA employee who was working with GCHQ as part of an “Access Strategy Team,” takes a similarly adversarial view of encryption, referring to Juniper as a “threat” and a “target” because it provides technology to protect data from eavesdropping. Far from suggesting that security agencies should help U.S. and U.K. companies mend their digital defenses, the document says the agencies must “keep up with Juniper technology” in the pursuit of SIGINT, or signals intelligence.
    “The threat comes from Juniper’s investment and emphasis on being a security leader,” the document says. “If the SIGINT community falls behind, it might take years to regain a Juniper firewall or router access capability if Juniper continues to rapidly increase their security.”

    The document, provided by NSA whistleblower Edward Snowden, shines light on the agencies’ secret efforts to ensure they could monitor information as it flowed through Juniper’s products, which are used by Internet providers, banks, universities, and government agencies. It notes that while Juniper trails its competitors, it is a “technology leader” with gear “at the core of the Internet in many countries,” including several deemed to be high priority from a spying perspective: Pakistan, Yemen, and China.

    Asked about the document, GCHQ issued a boilerplate response asserting that the agency does not comment on intelligence matters and complies with “a strict legal and policy framework.” The NSA could not immediately respond Tuesday. Juniper sent a written statement saying the company “operates with the highest of ethical standards, and is committed to maintaining the integrity, security, and quality of our products. As we’ve stated previously … it is against established Juniper policy to intentionally include ‘backdoors’ that would potentially compromise our products or put our customers at risk. Moreover, it is Juniper policy not to work with others to introduce vulnerabilities into our products.”

    Juniper’s prominence and ubiquity similarly helped draw attention to the more recent hacks against the company, which first came to light Thursday, when the California firm revealed it had discovered “unauthorized code” in ScreenOS enabling two major vulnerabilities. One, first present in an August 2012 release of ScreenOS, could allow access to encrypted data transmitted over VPNs. The other, first surfacing in a December 2014 ScreenOS release, allows an attacker to remotely administer a firewall, thus leading to “complete compromise of the affected device,” according to Juniper. The vulnerabilities remained in versions of ScreenOS released through at least October of this year.

    It is the earlier vulnerability, potentially allowing eavesdropping on VPNs, that has generated vigorous online discussion among computer security experts. Some, like Johns Hopkins professor Matthew Green and security researcher Ralf-Philipp Weinmann, have said that an attacker appears to have subverted a backdoor shown, in previously disclosed documents from Snowden, to have originated with the NSA. Specifically, the attacker seems to have tampered with a 32-byte value used to seed the generation of random numbers, numbers that are in turn used in the process of encrypting data in ScreenOS. ScreenOS uses the value as a parameter to a standard system for random number generation known as Dual Elliptic Curve Deterministic Random Bit Generator. The default 32-byte value in this standard is believed to have been generated by the NSA. Juniper said, in the wake of the Snowden revelations about the standard, that it had replaced this 32-byte value with its own “self-generated basis points.” So the attacker would have replaced Juniper’s replacement of the NSA 32-byte value.

    Matt Blaze, a cryptographic researcher and director of the Distributed Systems Lab at the University of Pennsylvania, said the document contains clues that indicate the 2011 capabilities against Juniper are not connected to the recently discovered vulnerabilities. The 2011 assessment notes that “some reverse engineering may be required depending on firmware revisions” affecting targeted NetScreen firewall models. Blaze said this points away from the sort of ScreenOS compromise behind the more recent Juniper vulnerabilities.

    “With the [recently discovered] backdoor, a firmware revision would either have the backdoor or it wouldn’t, and if it was removed, they’d have to do a lot more than ‘some reverse engineering’ to recover the capability,” Blaze said. “My guess from reading this is that the capabilities discussed here involved exploiting bugs and maybe supply chain attacks, rather than this [recently discovered] backdoor.”
    Blaze said the exploit capabilities in the 2011 document seem consistent with a program called “FEEDTROUGH,” first revealed in a 2007 document published alongside an article in German newsweekly Der Spiegel.

    Even if it outlines capabilities unconnected to the recently discovered Juniper hacks, the 2011 GCHQ assessment makes clear that the author was interested in expanding the agencies’ capabilities against Juniper. “The vast majority of current Juniper exploits are against firewalls running the ScreenOS operating system,” the author wrote. “An effort to ensure exploitation capability” against Juniper’s primary operating system, JUNOS, “should bear fruit against a wide range of Juniper products.”

    The document suggests that the intelligence agencies successfully used the security holes they identified in Juniper’s devices to repeatedly penetrate them for surveillance, stating that “Juniper technology sharing with NSA improved dramatically during [calendar year] 2010 to exploit several target networks where GCHQ had access primacy.”

    The assessment also notes that, because Juniper is a U.S.-based company, there is both “opportunity and complication” in targeting its technology. “There is potential to leverage a corporate relationship should one exist with NSA,” it says, adding: “Any GCHQ efforts to exploit Juniper must begin with close coordination with NSA.”

    It further states that GCHQ has a “current exploit capability” against 13 Juniper models, all of which run ScreenOS: NS5gt, N25, NS50, NS500, NS204, NS208, NS5200, NS5000, SSG5, SSG20, SSG140, ISG 1000, ISG 2000. It reveals that the agency was developing an additional surveillance capability to hack into high-capacity Juniper M320 routers, which were designed to be used by Internet service providers.
    “The ability to exploit Juniper servers and firewalls,” the document says, “will pay many dividends over the years.”

  5. #5
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010

    New Discovery Around Juniper Backdoor Raises More Questions About the Company

    Juniper added the insecure algorithm to its software long after the more secure one was already in it, raising questions about why the company would have knowingly undermined an already secure system.

    Kim Zetter

    When tech giant Juniper Networks made the startling announcement last month that it had uncovered two mysterious backdoors embedded in software running on some of its firewalls, certain people in the security community praised the company for being honest about its discovery. Rather than silently removing the backdoors in a routine software patch sent to customers, Juniper said it was distributing the patch to eliminate “unauthorized code” that someone had placed in the source code of its software. This malicious code was particularly concerning because one of the backdoors, which had gone undetected in the software since 2012, could be exploited for the purposes of decrypting protected data passing through the VPN, or virtual private network, in Juniper NetScreen firewalls.

    But since that revelation, Juniper—whose customers include AT&T, Verizon, NATO and the US government—has refused to answer any questions about the backdoor, leaving everyone in the dark about a number of things. Most importantly, Juniper hasn’t explained why it included an encryption algorithm in its NetScreen software that made the unauthorized party’s backdoor possible. The algorithm in question is a pseudo-random number generator known as Dual_EC, which the security community had long warned was insecure and could be exploited for use as a backdoor. Whoever created the backdoor in Juniper’s software did exactly this, hijacking the insecure Dual_EC algorithm to make their secret portal work.

    Now new information uncovered by a researcher in Chicago makes Juniper’s decision to use this algorithm even more questionable.

    Juniper insisted publicly in 2013 that its use of Dual_EC was fine because its software didn’t rely on the insecure algorithm alone—instead it also used a second, more secure pseudo-random number generator known as ANSI X9.31 that essentially cancelled out any problems with the first one. That latter part turned out not to be true, however, and the very fact that Dual_EC was in the software allowed the intruders to exploit it for their backdoor. Juniper has never provided a timeline of when it inserted the two algorithms into its software, but many assumed that it had either implemented them at the same time so that its software never relied solely on the insecure Dual_EC, or it had added the ANSI algorithm to the software after already using Dual_EC for a while and learning that Dual_EC was not secure.

    But Stephen Checkoway, who teaches computer science at the University of Illinois at Chicago, has found that Juniper actually added the insecure algorithm to its software long after the more secure ANSI algorithm was already in it, raising questions about why the company would have knowingly undermined an already secure system.

    Checkoway worked with a number of other researchers to examine 48 versions of the NetScreen firmware. He looked for the presence of Dual_EC in all of them and found that until version 6.2.0, Juniper had been using only the ANSI X9.31 algorithm. The company only added Dual_EC with the 6.2.0 version.

    It’s unclear exactly when Juniper first released 6.2.0. The company’s website gives a “file date” for the first release of the firmware as October 27, 2008. But the release notes for the firmware have a March 2009 date. Either way, both dates were long after the security community had become aware of the security problems with Dual_EC, which were revealed at a cryptography conference in August 2007 and which many believe the NSA introduced into the algorithm for its own backdoor—vulnerabilities that Juniper’s unknown attackers then hijacked and exploited to create their own backdoor. (For background information on the problems in Dual_EC, see this story from 2013. To understand how the attackers exploited the vulnerabilities in Dual_EC to make the backdoor in Juniper’s software work, see our comprehensive story about it from December.)

    What’s more, Checkoway discovered that the company made an additional change to its software when it added Dual_EC, a change that made it even easier for the person who later installed the backdoor to decrypt Juniper’s VPN traffic. This change involved altering the size or length of the so-called nonce (the random number string generated by the algorithm that the encryption scheme uses to help encrypt data). Juniper changed the size of the nonce from 20 bytes—the size it had been using for the ANSI algorithm—to 32 bytes.

    The change in nonce size is significant, Checkoway says, because in order to attack an encryption scheme that uses Dual_EC, an attacker needs to see enough raw output from the generator to crack it. The increase to 32 bytes of output reduced the amount of calculation and time an attacker would need to undermine the encryption scheme and decrypt data. That new nonce, 32 bytes, is the precise size the security community had specified in 2007 would be the ideal minimal output an attacker would need to undermine Dual_EC.

    “The more output you see [from the generator], the better [it is to crack the encryption],” Checkoway says. “Anything you see over 30 bytes is very helpful. Anything you see less than 30 bytes makes the attack exponentially harder. So seeing 20 bytes makes the attack basically infeasible. Seeing 28 bytes makes it doable, but it takes an amount of time, maybe hours. Seeing 32 bytes makes it take fractions of a second.”

    Juniper could have chosen a nonce size anywhere between 8 bytes and 256 bytes, and Checkoway notes that previous research has shown that the most common value used by developers is 20 bytes. The use of 32 bytes, therefore, is curious. “Twenty bytes, as far as I know, is just fine [for security]. And 32 bytes would be just fine as well—if that random number generator didn’t have a backdoor,” he says.

    Juniper’s decision to increase the nonce to 32 bytes is also perplexing because Dual_EC, by nature, produces just 30 bytes of output at a time, according to Checkoway. To obtain enough output for the 32-byte nonce Juniper wanted for its encryption scheme, it had the Dual_EC generate output twice to produce 60 bytes. Checkoway says it then used only 2 bytes from that second generation and discarded the rest.

    Checkoway says that given the known security problems with Dual_EC, it made no sense for Juniper to add it to the NetScreen software, particularly since it was already using the more secure ANSI X9.31 algorithm. It also made no sense because Dual_EC has another problem—it’s known to be much slower than other algorithms. And because the NetScreen VPN software keeps the Dual_EC generator busy by calling on it repeatedly to produce random output, he says this likely would have caused a performance degradation for customers. The security issues aside, “this is not a particularly fantastic number generator even on its own terms,” he says.

  6. #6
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010

    All of the changes Juniper made to its software in 2008 created an ideal environment for a backdoor, Checkoway says.

    “The key point here is that if any one of the four listed changes in [firmware version] 6.2.0r1 had not happened, then the VPN traffic could not be passively decrypted…,” says Checkoway. “If this backdoor was not intentional, then, in my opinion, it’s an amazing coincidence.”

    So why did Juniper use Dual_EC and change the nonce to 32 bytes instead of the 30 the algorithm normally produced in a single output? These are enduring questions that Juniper has avoided answering since it first revealed the presence of the backdoor. The company refused to even entertain inquiries from WIRED for this story. “We have nothing further to share at this time but I will follow up with you when we do,” spokeswoman Danielle Hamel wrote in an email, without even asking what the questions were.

    Some people in the security community have suggested that one possible reason Juniper may have added Dual_EC to its software was to get its firewalls certified for government use. In 2006, the National Institute of Standards and Technology approved Dual_EC for use in encrypting government data under FIPS (the Federal Information Processing Standards), a standard that technology vendors must meet if they want to sell their products to government agencies and government contractors. In fact, Juniper’s NetScreen software did get FIPS certified, but according to a list on NIST’s web site, version 6.2.0 of its ScreenOS firmware was certified for its use of the ANSI X9.31 algorithm, not for Dual_EC. There’s no mention of Dual_EC on the list at all, in relation to ScreenOS, the name of the firmware running on Juniper’s NetScreen firewalls.

    All of this leaves the security community and the public still baffled about Juniper’s choices.

    In 2013, following the release of NSA documents by Edward Snowden, questions about the security of Dual_EC were reignited, six years after they had first been raised at that cryptography conference in 2007. In response to the renewed concerns about Dual_EC, Juniper posted a little-noticed message to its web site in September 2013 revealing for the first time that the software on its NetScreen firewalls uses Dual_EC. But Juniper wrote that it had designed its encryption scheme to use Dual_EC in a secure way so that the algorithm’s vulnerabilities didn’t matter. It did this by replacing a so-called constant—or static number—that is used with the generator and is part of what made it insecure. And it also designed its encryption scheme so that it didn’t rely solely on output from Dual_EC but instead relied on output from the ANSI X9.31 generator. Essentially, it would take output generated by the Dual_EC and run it through the ANSI generator and use only the final output from the more secure ANSI generator, theoretically canceling out the vulnerabilities that were inherent in the Dual_EC output.

    But a researcher discovered last month that Juniper made a grave error in how it implemented this. Willem Pinckaers, an independent security researcher in California, found a bug in Juniper’s software that actually caused it to ignore the ANSI algorithm altogether and only use that initial raw output from Dual_EC. Researchers have called it a “catastrophic failure” for Juniper and big win for the attackers who inserted the backdoor in Juniper’s software. It was this failure on Juniper’s part that allowed the attackers’ backdoor to work.

    Ironically, at the time that Juniper was making those assertions in 2013 about the security of its software, the attackers’ backdoor had already been in it, undetected, for a year.

    Today, a month after Juniper revealed the existence of the backdoor, it has still not fixed the catastrophic bug that made it possible. The company issued a patch last month that supposedly solved the security problem with Dual_EC by eliminating the unauthorized code the attackers had placed in the software to create their Dual_EC backdoor. But Juniper did not remove Dual_EC altogether, which is what Checkoway and other security experts say it should have done. Nor did it correct the implementation bug that causes its encryption scheme to ignore the ANSI generator and rely soley on output from Dual_EC.

    As long as Dual_EC remains in Juniper’s software, the system that corporate and government customers are using to secure their VPN data is not secure. If an attacker can get access to Juniper’s source code again and introduce malicious code for another Dual_EC backdoor, the situation will be back to where it began.

    Update 1.8.16 8:30 pm PST: Juniper announced late Friday night that it plans to remove both the problematic Dual_EC algorithm as well as the ANSI algorithm from its NetScreen code. “We will replace Dual_EC and ANSI X9.31 in ScreenOS 6.3 with the same random number generation technology currently employed across our broad portfolio of Junos OS products,” the company wrote in a note posted to its web site. “We intend to make these changes in a subsequent ScreenOS software release, which will be made available in the first half of 2016.”

  7. #7
    WHT-BR Top Member
    Data de Ingresso
    Dec 2010

    Juniper Networks will drop code tied to National Security Agency

    By Joseph Menn
    Sat Jan 9, 2016

    Juniper Networks Inc said late on Friday it would stop using a piece of security code that analysts believe was developed by the National Security Agency in order to eavesdrop through technology products.

    The Silicon Valley maker of networking gear said it would ship new versions of security software in the first half of this year to replace those that rely on numbers generated by Dual Elliptic Curve technology.

    The statement on a blog post came a day after the presentation at a Stanford University conference of research by a team of cryptographers who found that Juniper's code had been changed in multiple ways during 2008 to enable eavesdropping on virtual private network sessions by customers.

    Last month, Sunnyvale-based Juniper said it had found and replaced two unauthorized pieces of code that allowed "back door" access, which the researchers said had appeared in 2012 and 2014.

    The 2014 back door was straightforward, said researcher Hovav Shacham of the University of California, San Diego, allowing anyone with the right password to see everything.

    The 2012 code changed a mathematical constant in Juniper's Netscreen products that should have allowed its author to eavesdrop, according to Shacham and his fellow investigators.

    Juniper's initial patch had gotten rid of that constant in Dual Elliptic Curve and replaced it with the version it had been using since 2008.

    But the academics who studied the code said that while Juniper had not disavowed the 2008 code, it had not explained how that constant was picked or why it was using the widely faulted Dual Elliptic Curve at all.

    Still another curve constant, quietly provided by the NSA and required for some federal certification, was exposed in documents leaked by former NSA contractor Edward Snowden as a key to the back door.

    Until now, the most influential adopter of Dual Elliptic Curve was believed to be RSA, part of storage company EMC, which Reuters reported received a $10-million federal contract to distribute it in a software kit for others.

    Though the academic team looking at Juniper has not named a suspect in the 2008, 2012 or 2014 changes, 2008 was one year after veteran cryptographers raised questions about Dual Elliptic Curve.

    A very advanced adversary could have seen how to manipulate Dual EC and in theory managed to insert code through a cooperative or unsuspecting Juniper employee, but the company had not advertised the fact that it was using the formula at all.

    A more logical suspect, said expert Nicholas Weaver of the International Computer Science Institute, was the NSA, which might have been displaced later by other countries' agencies or top-level hackers in 2012 and 2014.

    The NSA did not immediately respond to an emailed request for comment.

    Juniper said it was continuing to investigate.

    It declined to answer questions from Reuters about the revisions.

    (Reporting by Joseph Menn; Editing by Clarence Fernandez)

Permissões de Postagem

  • Você não pode iniciar novos tópicos
  • Você não pode enviar respostas
  • Você não pode enviar anexos
  • Você não pode editar suas mensagens