In a blog post on Rapid7′s community portal Sunday, HD Moore posted some notes on the Juniper ScreenOS incident, notably that his team discovered the backdoor password that enables the Telnet and SSH bypass. Quoting: “Although most folks are more familiar with x86 than ARM, the ARM binaries are significantly easier to compare due to minimal changes in the compiler output. … Once the binary is loaded, it helps to identify and tag common functions. Searching for the text “strcmp” finds a static string that is referenced in the sub_ED7D94 function.”
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.
Juniper’s advisory mentioned that versions 6.2.0r15 to 6.2.0r18 and 6.3.0r12 to 6.3.0r20 were affected.
ScreenOS is not based on Linux or BSD, but runs as a single monolithic kernel. The SSG500 firmware uses the x86 architecture, while the SSG5 and SSG20 firmware uses the XScale (ARMB) architecture. The decompressed kernel can be loaded into IDA Pro for analysis. As part of the analysis effort, we have made decompressed binaries available in a GitHub repository
Although most folks are more familiar with x86 than ARM, the ARM binaries are significantly easier to compare due to minimal changes in the compiler output.
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.
The interesting thing about this backdoor is not the simplicity, but the timing. Juniper's advisory claimed that versions 6.2.0r15 to 6.2.0r18 and 6.3.0r12 to 6.3.0r20 were affected, but the authentication backdoor is not actually present in older versions of ScreenOS.
Detecting the exploitation of this issue is non-trivial, but there are a couple things you can do. Juniper provided guidance on what the logs from a successful intrusion would look like
Although an attacker could delete the logs once they gain access, any logs sent to a centralized logging server (or SIEM) would be captured, and could be used to trigger an alert.
FoxIT has a created a set of Snort rules that can detect access with the backdoor password over Telnet and fire on any connection to a ScreenOS Telnet or SSH service
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.
Firewalls backdoor author found – errand old friend
Information security Scientists believe inquired into how Juniper firewalls, found the back door to work. A large network equipment manufacturer Juniper said last week the place firewalls two rear doors, one of which is made possible through the device encrypted VPN traffic, unloading and playback.
Wiredin according to the relevant familiar with the German security researcher Ralf-Philipp Weinmann Comsecuris, the company believes the US spy agency NSA’s to be responsible for the back door, at least indirectly. Although the NSA is not installed themselves back door Juniper code, it is believed to have developed a vulnerability, which is used in the rear door.
VPN traffic decryption suspects Dual_EC encryption algorithm was used as a deliberate weakness.
Taking into account used for decryption technology, the NSA is the prime suspect Designer Juniper’s back door. On the other hand Wired points out that according to recent news reports, according to anonymous US sources have denied that the intelligence organizations in the case of inclusion. Therefore, there may also be a Russian or Chinese operations.
If the back door is someone other than the US’s handwriting, the incident underscores Wiredin that effectively why the government’s own rear doors are a very bad idea: they can use for their own purposes any who is interested.
The access-all-areas backdoor password hidden in some Juniper Networks’ Netscreen firewalls has been published.
Last week it was revealed that some builds of the devices’ ScreenOS firmware suffer from two severe security weaknesses: one allows devices to be commandeered over SSH and Telnet, and the other allows encrypted VPN communications to be monitored by eavesdroppers.
An analysis by security firm Rapid 7 of the firmware’s ARM code has uncovered more details on that first vulnerability – specifically, a hardcoded password that grants administrator access. And that password is: <<< %s(un='%s') = %u.
regardless of the username given, it allows anyone to bypass authentication, and the password is hardwired into the operating system.
The Rapid 7 team found more than 26,000 internet-facing Netscreen systems with SSH open.
"This is interesting because although the first affected version was released in 2012, the authentication backdoor did not seem to get added until a release in late 2013 (either 6.3.0r15, 6.3.0r16, or 6.3.0r17)."
That date is important because it potentially derails a rumor that has been floating around the internet over the weekend: that the backdoor was created as part of a top-secret NSA plan to hijack Juniper's kit for spying purposes.
This rumor spread after people fished out an NSA document published by Der Spiegel in which the intelligence agency claimed to have full control over Juniper's Netscreen firewalls.
But that slide was made in 2008. That's five years before this particular backdoor was added to ScreenOS. It's possible another backdoor was present in earlier builds, but no one has evidence of that.
Also, the NSA slide focuses on implanting surveillance malware in a device, rather than compromising the firmware's source code to introduce a hidden skeleton key. The backdoor found by Rapid 7 seems too heavy-handed for the US spy agency.
If anything, ScreenOS's use of the Dual EC DRBG random number generator in its encryption is more worrying, and points to potential NSA interference. That algorithm is the same engine that was championed by the NSA even as independent security researchers pointed out that it was seriously flawed.
Security experts have been analyzing the Juniper Networks firewall backdoors whose existence was brought to light last week, and they’ve discovered what appears to be the root cause for both the administrative access and VPN decryption issues.
Networking and security company Juniper Networks revealed last week that it had identified unauthorized code in ScreenOS, the operating system powering the company’s NetScreen firewalls.
The unauthorized code introduces two vulnerabilities: one that can be exploited to gain administrative access to NetScreen devices (CVE-2015-7755), and one that can be leveraged by a “knowledgeable attacker” who can monitor VPN traffic to decrypt VPN connections (CVE-2015-7756).
Authentication Backdoor
The vulnerabilities have been analyzed by several external researchers. Fox-IT experts said it took them just 6 hours to find the password for the ScreenOS authentication backdoor.
After analyzing the differences between the vulnerable and patched versions of ScreenOS, Rapid7’s HD Moore determined that the authentication backdoor, which can be exploited via SSH or Telnet, involves the default password <<< %s(un='%s') = %u.
This backdoor password, which was presumably set this way so that it would be mistaken for one of the many debug format strings present in the code, can be leveraged by an attacker who knows a valid username for the device.
On one hand, it’s difficult to say if this vulnerability has been exploited in the wild since even though an unauthorized access attempt would normally be logged, it’s easy for an attacker to delete the relevant log entries. However, as Moore has highlighted, the logs might be sent to a centralized server, which could result in an alert being triggered.
“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,” Moore explained.
The researcher has pointed out that roughly 26,000 NetScreen devices are open to the Internet via SSH, according to a Shodan search.
Google security engineer Adam Langley has published a blog post summarizing the findings of various experts regarding the VPN decryption issue.
In the wake of the discovery of two backdoors on Juniper’s NetScreen firewall devices, Cisco Systems has announced that they will be reviewing the software running on their devices, just in case.
Anthony Grieco, a Senior Director of the Security and Trust Organization at Cisco, made sure to first point out that the popular networking equipment manufacturer has a “no backdoor” policy.
Matthew Green / A Few Thoughts …:
How hackers piggybacked on an existing backdoor in Juniper’s ScreenOS software to create a backdoor of their own — On the Juniper backdoor — You might have heard that a few days ago, Juniper Systems announced the discovery of “unauthorized code” in the ScreenOS software that underlies the NetScreen line of devices.
You might have heard that a few days ago, Juniper Systems announced the discovery of “unauthorized code” in the ScreenOS software that underlies the NetScreen line of devices. As a result of this discovery, the company announced a pair of separate vulnerabilities, CVE-2015-7755 and CVE-2015-7756 and urged their customers to patch immediately.
The first of these CVEs (#7755) was an authentication vulnerability, caused by a malicious hardcoded password in SSH and Telnet. Rapid7 has an excellent writeup of the issue. This is a pretty fantastic vulnerability, if you measure by the impact on security of NetScreen users. But on the technological awesomeness scale it rates about a two out of ten, maybe a step above ‘hit the guy with a wrench’.
The second vulnerability is a whole different animal. The advisory notes that CVE-7756 — which is independent of the first issue — “may allow a knowledgeable attacker who can monitor VPN traffic to decrypt that traffic.” This is the kind of vulnerability that makes applied cryptographers cry tears of joy.
And while every reasonable person knows you can’t just drop “passive decryption vulnerability” and expect the world to go on with its business, this is exactly what Juniper tried to do. Since they weren’t talking about it, it fell to software experts to try to work out what was happening by looking carefully at firmware released by the company.
Now I want to be clear that I was not one of those software experts. IDA scares the crap out of me. But I’m fortunate to know some of the right kind of people, like Steve Checkoway, who I was able to get on the job
And yes, it was worth it. Because what Ralf and Steve et al. found is beyond belief. Ralf’s excellent post provides all of the technical details, and you should honest just stop reading now and go read that. But since you’re still here, the TL;DR is this:
For the past several years, it appears that Juniper NetScreen devices have incorporated a potentially backdoored random number generator, based on the NSA’s Dual_EC_DRBG algorithm. At some point in 2012, the NetScreen code was further subverted by some unknown party, so that the very same backdoor could be used to eavesdrop on NetScreen connections. While this alteration was not authorized by Juniper, it’s important to note that the attacker made no major code changes to the encryption mechanism — they only changed parameters. This means that the systems were potentially vulnerable to other parties, even beforehand. Worse, the nature of this vulnerability is particularly insidious and generally messed up.
The most famous (alleged) example of deliberate random number generator subversion was discovered in 2007 by Dan Shumow and Neils Ferguson from Microsoft, when they announced the possibility of a backdoor in a NIST standard called Dual_EC_DRBG.
Dual EC relies on a special 32-byte constant called Q, which — if generated by a malicious attacker — can allow said attacker to predict future outputs of the RNG after seeing a mere 30 bytes of raw output from your generator.
The NIST specification of Dual_EC comes with a default value for Q that was generated by the NSA.
Although it was not widely publicized before this week, Juniper’s ScreenOS devices have used Dual EC for some time — probably since before Juniper acquired NetScreen Technologies.
First, ScreenOS doesn’t use the NSA’s default Q. Instead, they use an alternative Q value that was generated by Juniper and/or NetScreen.
Next, ScreenOS uses Dual EC in a strange, non-standard way.
Thus Dual EC is safe only if you assume no tiny bug in the code could accidentally leak out 30 bytes or so of raw Dual EC output. If it did, this would make all subsequent seeding calls predictable, and thus render all numbers generated by the system predictable. In general, this would spell doom for the confidentiality of VPN connections.
And unbelievably, amazingly, who coulda thunk it, it appears that such a bug does exist in many versions of ScreenOS, dating to both before and after the “unauthorized code” noted by Juniper.
So if this was the authorized code, what the hell was the unauthorized code?
The creepiest thing about CVE-2015-7756 is that there doesn’t seem to be any unauthorized code. Indeed, what’s changed in the modified versions is simply the value of the Q point. According to Ralf this point changed in 2012, presumably to a value that the hacker(s) generated themselves. This would likely have allowed these individuals to passively decrypt ScreenOS VPN sessions.
In the more recent Juniper patch to fix the vulnerability, Q is simply set back to the the original Juniper/NetScreen value.
To sum up, some hacker or group of hackers noticed an existing backdoor in the Juniper software, which may have been intentional or unintentional — you be the judge! They then piggybacked on top of it to build a backdoor of their own, something they were able to do because all of the hard work had already been done for them. The end result was a period in which someone — maybe a foreign government — was able to decrypt Juniper traffic in the U.S. and around the world.
So why does this matter?
For the past several months I’ve been running around with various groups of technologists, doing everything I can to convince important people that the sky is falling. Or rather, that the sky will fall if they act on some of the very bad, terrible ideas that are currently bouncing around Washington — namely, that our encryption systems should come equipped with “backdoors” intended to allow law enforcement and national security agencies to access our communications.
One of the most serious concerns we raise during these meetings is the possibility that encryption backdoors could be subverted.
Specifically, that a backdoor intended for law enforcement could somehow become a backdoor for people who we don’t trust to read our messages. Normally when we talk about this, we’re concerned about failures in storage of things like escrow keys. What this Juniper vulnerability illustrates is that the danger is much broader and more serious than that.
The problem with cryptographic backdoors isn’t that they’re the only way that an attacker can break into our cryptographic systems. It’s merely that they’re one of the best. They take care of the hard work, the laying of plumbing and electrical wiring, so attackers can simply walk in and change the drapes.
Kim Zetter / Wired:
Experts’ findings suggest NSA is at least indirectly responsible for Juniper backdoor because of the weakness NSA embedded in the Dual_EC encryption algorithm
Juniper’s security nightmare gets worse and worse as experts comb the ScreenOS firmware in its old NetScreen firewalls.
Just before the weekend, the networking biz admitted there had been “unauthorized” changes to its software, allowing hackers to commandeer equipment and decrypt VPN traffic.
In response, Rapid7 reverse engineered the code, and found a hardwired password that allows anyone to log into the boxes as an administrator via SSH or Telnet.
Now an analysis of NetScreen’s encryption algorithms by Matthew Green, Ralf-Philipp Weinmann, and others, has found another major problem.
“For the past several years, it appears that Juniper NetScreen devices have incorporated a potentially backdoored random number generator, based on the NSA’s Dual EC DRBG algorithm,” wrote Green, a cryptographer at Johns Hopkins University.
“At some point in 2012, the NetScreen code was further subverted by some unknown party, so that the very same backdoor could be used to eavesdrop on NetScreen connections. While this alteration was not authorized by Juniper, it’s important to note that the attacker made no major code changes to the encryption mechanism – they only changed parameters.”
The Dual EC DRBG random number generator was championed by the NSA, although researchers who studied the spec found that data encrypted using the generator could be decoded by clever eavesdroppers.
Backdoors Not Patched in Many Juniper Firewalls
The owners of over 1,500 Juniper firewalls still haven’t applied patches to address a recently disclosed backdoor
The owners of more than 1,500 Juniper Networks firewalls still haven’t applied patches designed to address recently discovered backdoors, an Internet scan conducted by a researcher has shown.
Juniper Networks reported in mid-December that it had identified unauthorized code in ScreenOS, the operating system powering the company’s NetScreen firewalls.
The unauthorized code introduced two vulnerabilities: one that can be exploited to gain administrative access to affected devices (CVE-2015-7755), and one that can be leveraged to decrypt VPN connections (CVE-2015-7756).
Juniper Networks has announced its own investigations have found none of the “oops … how did that code get there” trouble in Junos OS and that it will kill off Dual Elliptic Curve (Dual_EC) encryption in ScreenOS.
The company says it hired a “respected security organization” that “undertook a detailed investigation of ScreenOS and Junos OS® source code.”
“After a detailed review, there is no evidence of any other unauthorized code in ScreenOS nor have we found any evidence of unauthorized code in Junos OS. The investigation also confirmed that it would be much more difficult to insert the same type of unauthorized code in Junos OS.”
Which doesn’t mean the company has a clean bill of health, because Juniper has decided to remove Dual_EC from Screen OS sometime in the first half of 2016.
Senior veep and CIO Bob Worrall writes that the Dual_EC and ANSI X9.31 crypto will both be replaced by “the same random number generation technology currently employed across our broad portfolio of Junos OS products”.
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
We are a professional review site that has advertisement and can receive compensation from the companies whose products we review. We use affiliate links in the post so if you use them to buy products through those links we can get compensation at no additional cost to you.OkDecline
14 Comments
Tomi Engdahl says:
Juniper’s Backdoor Password Disclosed, Likely Added In Late 2013
http://it.slashdot.org/story/15/12/21/1257200/junipers-backdoor-password-disclosed-likely-added-in-late-2013
In a blog post on Rapid7′s community portal Sunday, HD Moore posted some notes on the Juniper ScreenOS incident, notably that his team discovered the backdoor password that enables the Telnet and SSH bypass. Quoting: “Although most folks are more familiar with x86 than ARM, the ARM binaries are significantly easier to compare due to minimal changes in the compiler output. … Once the binary is loaded, it helps to identify and tag common functions. Searching for the text “strcmp” finds a static string that is referenced in the sub_ED7D94 function.”
CVE-2015-7755: Juniper ScreenOS Authentication Backdoor
Posted by hdmoore Employee in Information Security on Dec 20, 2015 6:00:44 PM
https://community.rapid7.com/community/infosec/blog/2015/12/20/cve-2015-7755-juniper-screenos-authentication-backdoor
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.
Juniper’s advisory mentioned that versions 6.2.0r15 to 6.2.0r18 and 6.3.0r12 to 6.3.0r20 were affected.
ScreenOS is not based on Linux or BSD, but runs as a single monolithic kernel. The SSG500 firmware uses the x86 architecture, while the SSG5 and SSG20 firmware uses the XScale (ARMB) architecture. The decompressed kernel can be loaded into IDA Pro for analysis. As part of the analysis effort, we have made decompressed binaries available in a GitHub repository
Although most folks are more familiar with x86 than ARM, the ARM binaries are significantly easier to compare due to minimal changes in the compiler output.
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.
The interesting thing about this backdoor is not the simplicity, but the timing. Juniper's advisory claimed that versions 6.2.0r15 to 6.2.0r18 and 6.3.0r12 to 6.3.0r20 were affected, but the authentication backdoor is not actually present in older versions of ScreenOS.
Detecting the exploitation of this issue is non-trivial, but there are a couple things you can do. Juniper provided guidance on what the logs from a successful intrusion would look like
Although an attacker could delete the logs once they gain access, any logs sent to a centralized logging server (or SIEM) would be captured, and could be used to trigger an alert.
FoxIT has a created a set of Snort rules that can detect access with the backdoor password over Telnet and fire on any connection to a ScreenOS Telnet or SSH service
Tomi Engdahl says:
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.
Source: https://community.rapid7.com/community/infosec/blog/2015/12/20/cve-2015-7755-juniper-screenos-authentication-backdoor
Tomi Engdahl says:
Firewalls backdoor author found – errand old friend
Information security Scientists believe inquired into how Juniper firewalls, found the back door to work. A large network equipment manufacturer Juniper said last week the place firewalls two rear doors, one of which is made possible through the device encrypted VPN traffic, unloading and playback.
Wiredin according to the relevant familiar with the German security researcher Ralf-Philipp Weinmann Comsecuris, the company believes the US spy agency NSA’s to be responsible for the back door, at least indirectly. Although the NSA is not installed themselves back door Juniper code, it is believed to have developed a vulnerability, which is used in the rear door.
VPN traffic decryption suspects Dual_EC encryption algorithm was used as a deliberate weakness.
Taking into account used for decryption technology, the NSA is the prime suspect Designer Juniper’s back door. On the other hand Wired points out that according to recent news reports, according to anonymous US sources have denied that the intelligence organizations in the case of inclusion. Therefore, there may also be a Russian or Chinese operations.
If the back door is someone other than the US’s handwriting, the incident underscores Wiredin that effectively why the government’s own rear doors are a very bad idea: they can use for their own purposes any who is interested.
Source: http://www.tivi.fi/Kaikki_uutiset/palomuurien-takaoven-tekija-loytyi-asialla-vanha-tuttu-6241470
Tomi Engdahl says:
Some Analysis of the Backdoored Backdoor
http://rpw.sh/blog/2015/12/21/the-backdoored-backdoor/
Tomi Engdahl says:
How to log into any backdoored Juniper firewall – hard-coded password published
Did the NSA knacker ScreenOS? Probably not
http://www.theregister.co.uk/2015/12/21/security_code_to_backdoor_juniper_firewalls_revealed_in_firmware/
The access-all-areas backdoor password hidden in some Juniper Networks’ Netscreen firewalls has been published.
Last week it was revealed that some builds of the devices’ ScreenOS firmware suffer from two severe security weaknesses: one allows devices to be commandeered over SSH and Telnet, and the other allows encrypted VPN communications to be monitored by eavesdroppers.
An analysis by security firm Rapid 7 of the firmware’s ARM code has uncovered more details on that first vulnerability – specifically, a hardcoded password that grants administrator access. And that password is: <<< %s(un='%s') = %u.
regardless of the username given, it allows anyone to bypass authentication, and the password is hardwired into the operating system.
The Rapid 7 team found more than 26,000 internet-facing Netscreen systems with SSH open.
"This is interesting because although the first affected version was released in 2012, the authentication backdoor did not seem to get added until a release in late 2013 (either 6.3.0r15, 6.3.0r16, or 6.3.0r17)."
That date is important because it potentially derails a rumor that has been floating around the internet over the weekend: that the backdoor was created as part of a top-secret NSA plan to hijack Juniper's kit for spying purposes.
This rumor spread after people fished out an NSA document published by Der Spiegel in which the intelligence agency claimed to have full control over Juniper's Netscreen firewalls.
But that slide was made in 2008. That's five years before this particular backdoor was added to ScreenOS. It's possible another backdoor was present in earlier builds, but no one has evidence of that.
Also, the NSA slide focuses on implanting surveillance malware in a device, rather than compromising the firmware's source code to introduce a hidden skeleton key. The backdoor found by Rapid 7 seems too heavy-handed for the US spy agency.
If anything, ScreenOS's use of the Dual EC DRBG random number generator in its encryption is more worrying, and points to potential NSA interference. That algorithm is the same engine that was championed by the NSA even as independent security researchers pointed out that it was seriously flawed.
Tomi Engdahl says:
Juniper Firewall Backdoor Password Found in 6 Hours
http://www.securityweek.com/juniper-firewall-backdoor-password-found-6-hours
Security experts have been analyzing the Juniper Networks firewall backdoors whose existence was brought to light last week, and they’ve discovered what appears to be the root cause for both the administrative access and VPN decryption issues.
Networking and security company Juniper Networks revealed last week that it had identified unauthorized code in ScreenOS, the operating system powering the company’s NetScreen firewalls.
The unauthorized code introduces two vulnerabilities: one that can be exploited to gain administrative access to NetScreen devices (CVE-2015-7755), and one that can be leveraged by a “knowledgeable attacker” who can monitor VPN traffic to decrypt VPN connections (CVE-2015-7756).
Authentication Backdoor
The vulnerabilities have been analyzed by several external researchers. Fox-IT experts said it took them just 6 hours to find the password for the ScreenOS authentication backdoor.
After analyzing the differences between the vulnerable and patched versions of ScreenOS, Rapid7’s HD Moore determined that the authentication backdoor, which can be exploited via SSH or Telnet, involves the default password <<< %s(un='%s') = %u.
This backdoor password, which was presumably set this way so that it would be mistaken for one of the many debug format strings present in the code, can be leveraged by an attacker who knows a valid username for the device.
On one hand, it’s difficult to say if this vulnerability has been exploited in the wild since even though an unauthorized access attempt would normally be logged, it’s easy for an attacker to delete the relevant log entries. However, as Moore has highlighted, the logs might be sent to a centralized server, which could result in an alert being triggered.
“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,” Moore explained.
The researcher has pointed out that roughly 26,000 NetScreen devices are open to the Internet via SSH, according to a Shodan search.
Google security engineer Adam Langley has published a blog post summarizing the findings of various experts regarding the VPN decryption issue.
https://www.imperialviolet.org/2015/12/19/juniper.html
Tomi Engdahl says:
Cisco Systems will be auditing their code for backdoors
http://www.net-security.org/secworld.php?id=19266
In the wake of the discovery of two backdoors on Juniper’s NetScreen firewall devices, Cisco Systems has announced that they will be reviewing the software running on their devices, just in case.
Anthony Grieco, a Senior Director of the Security and Trust Organization at Cisco, made sure to first point out that the popular networking equipment manufacturer has a “no backdoor” policy.
Tomi Engdahl says:
Matthew Green / A Few Thoughts …:
How hackers piggybacked on an existing backdoor in Juniper’s ScreenOS software to create a backdoor of their own — On the Juniper backdoor — You might have heard that a few days ago, Juniper Systems announced the discovery of “unauthorized code” in the ScreenOS software that underlies the NetScreen line of devices.
On the Juniper backdoor
http://blog.cryptographyengineering.com/2015/12/on-juniper-backdoor.html?m=1
You might have heard that a few days ago, Juniper Systems announced the discovery of “unauthorized code” in the ScreenOS software that underlies the NetScreen line of devices. As a result of this discovery, the company announced a pair of separate vulnerabilities, CVE-2015-7755 and CVE-2015-7756 and urged their customers to patch immediately.
The first of these CVEs (#7755) was an authentication vulnerability, caused by a malicious hardcoded password in SSH and Telnet. Rapid7 has an excellent writeup of the issue. This is a pretty fantastic vulnerability, if you measure by the impact on security of NetScreen users. But on the technological awesomeness scale it rates about a two out of ten, maybe a step above ‘hit the guy with a wrench’.
The second vulnerability is a whole different animal. The advisory notes that CVE-7756 — which is independent of the first issue — “may allow a knowledgeable attacker who can monitor VPN traffic to decrypt that traffic.” This is the kind of vulnerability that makes applied cryptographers cry tears of joy.
And while every reasonable person knows you can’t just drop “passive decryption vulnerability” and expect the world to go on with its business, this is exactly what Juniper tried to do. Since they weren’t talking about it, it fell to software experts to try to work out what was happening by looking carefully at firmware released by the company.
Now I want to be clear that I was not one of those software experts. IDA scares the crap out of me. But I’m fortunate to know some of the right kind of people, like Steve Checkoway, who I was able to get on the job
And yes, it was worth it. Because what Ralf and Steve et al. found is beyond belief. Ralf’s excellent post provides all of the technical details, and you should honest just stop reading now and go read that. But since you’re still here, the TL;DR is this:
For the past several years, it appears that Juniper NetScreen devices have incorporated a potentially backdoored random number generator, based on the NSA’s Dual_EC_DRBG algorithm. At some point in 2012, the NetScreen code was further subverted by some unknown party, so that the very same backdoor could be used to eavesdrop on NetScreen connections. While this alteration was not authorized by Juniper, it’s important to note that the attacker made no major code changes to the encryption mechanism — they only changed parameters. This means that the systems were potentially vulnerable to other parties, even beforehand. Worse, the nature of this vulnerability is particularly insidious and generally messed up.
The most famous (alleged) example of deliberate random number generator subversion was discovered in 2007 by Dan Shumow and Neils Ferguson from Microsoft, when they announced the possibility of a backdoor in a NIST standard called Dual_EC_DRBG.
Dual EC relies on a special 32-byte constant called Q, which — if generated by a malicious attacker — can allow said attacker to predict future outputs of the RNG after seeing a mere 30 bytes of raw output from your generator.
The NIST specification of Dual_EC comes with a default value for Q that was generated by the NSA.
Although it was not widely publicized before this week, Juniper’s ScreenOS devices have used Dual EC for some time — probably since before Juniper acquired NetScreen Technologies.
First, ScreenOS doesn’t use the NSA’s default Q. Instead, they use an alternative Q value that was generated by Juniper and/or NetScreen.
Next, ScreenOS uses Dual EC in a strange, non-standard way.
Thus Dual EC is safe only if you assume no tiny bug in the code could accidentally leak out 30 bytes or so of raw Dual EC output. If it did, this would make all subsequent seeding calls predictable, and thus render all numbers generated by the system predictable. In general, this would spell doom for the confidentiality of VPN connections.
And unbelievably, amazingly, who coulda thunk it, it appears that such a bug does exist in many versions of ScreenOS, dating to both before and after the “unauthorized code” noted by Juniper.
So if this was the authorized code, what the hell was the unauthorized code?
The creepiest thing about CVE-2015-7756 is that there doesn’t seem to be any unauthorized code. Indeed, what’s changed in the modified versions is simply the value of the Q point. According to Ralf this point changed in 2012, presumably to a value that the hacker(s) generated themselves. This would likely have allowed these individuals to passively decrypt ScreenOS VPN sessions.
In the more recent Juniper patch to fix the vulnerability, Q is simply set back to the the original Juniper/NetScreen value.
To sum up, some hacker or group of hackers noticed an existing backdoor in the Juniper software, which may have been intentional or unintentional — you be the judge! They then piggybacked on top of it to build a backdoor of their own, something they were able to do because all of the hard work had already been done for them. The end result was a period in which someone — maybe a foreign government — was able to decrypt Juniper traffic in the U.S. and around the world.
So why does this matter?
For the past several months I’ve been running around with various groups of technologists, doing everything I can to convince important people that the sky is falling. Or rather, that the sky will fall if they act on some of the very bad, terrible ideas that are currently bouncing around Washington — namely, that our encryption systems should come equipped with “backdoors” intended to allow law enforcement and national security agencies to access our communications.
One of the most serious concerns we raise during these meetings is the possibility that encryption backdoors could be subverted.
Specifically, that a backdoor intended for law enforcement could somehow become a backdoor for people who we don’t trust to read our messages. Normally when we talk about this, we’re concerned about failures in storage of things like escrow keys. What this Juniper vulnerability illustrates is that the danger is much broader and more serious than that.
The problem with cryptographic backdoors isn’t that they’re the only way that an attacker can break into our cryptographic systems. It’s merely that they’re one of the best. They take care of the hard work, the laying of plumbing and electrical wiring, so attackers can simply walk in and change the drapes.
Tomi Engdahl says:
Kim Zetter / Wired:
Experts’ findings suggest NSA is at least indirectly responsible for Juniper backdoor because of the weakness NSA embedded in the Dual_EC encryption algorithm
Researchers Solve Juniper Backdoor Mystery; Signs Point to NSA
http://www.wired.com/2015/12/researchers-solve-the-juniper-mystery-and-they-say-its-partially-the-nsas-fault/
Tomi Engdahl says:
Juniper’s VPN security hole is proof that govt backdoors are bonkers
If you let in the Feds, you’ll let in anyone
http://www.theregister.co.uk/2015/12/23/juniper_analysis/
Juniper’s security nightmare gets worse and worse as experts comb the ScreenOS firmware in its old NetScreen firewalls.
Just before the weekend, the networking biz admitted there had been “unauthorized” changes to its software, allowing hackers to commandeer equipment and decrypt VPN traffic.
In response, Rapid7 reverse engineered the code, and found a hardwired password that allows anyone to log into the boxes as an administrator via SSH or Telnet.
Now an analysis of NetScreen’s encryption algorithms by Matthew Green, Ralf-Philipp Weinmann, and others, has found another major problem.
“For the past several years, it appears that Juniper NetScreen devices have incorporated a potentially backdoored random number generator, based on the NSA’s Dual EC DRBG algorithm,” wrote Green, a cryptographer at Johns Hopkins University.
“At some point in 2012, the NetScreen code was further subverted by some unknown party, so that the very same backdoor could be used to eavesdrop on NetScreen connections. While this alteration was not authorized by Juniper, it’s important to note that the attacker made no major code changes to the encryption mechanism – they only changed parameters.”
The Dual EC DRBG random number generator was championed by the NSA, although researchers who studied the spec found that data encrypted using the generator could be decoded by clever eavesdroppers.
Tomi Engdahl says:
Juniper stock notable hit because of the news:
http://finance.yahoo.com/echarts?s=JNPR+Interactive#{%22range%22:%225d%22,%22allowChartStacking%22:true}
Tomi Engdahl says:
Juniper disclosed the vulnerability in a security post and strongly recommended that customers upgraded to a fixed release.
The company said it is unaware of any exploitation of the vulnerability. It only affects ScreenOS 6.3.0r17 through 6.3.0r20, Juniper said
2015-12 Out of Cycle Security Bulletin: ScreenOS: Multiple Security issues with ScreenOS (CVE-2015-7755, CVE-2015-7756)
http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10713&cat=SIRT_1&actp=LIST
Tomi Engdahl says:
Backdoors Not Patched in Many Juniper Firewalls
The owners of over 1,500 Juniper firewalls still haven’t applied patches to address a recently disclosed backdoor
Backdoors Not Patched in Many Juniper Firewalls
By Eduard Kovacs on January 06, 2016
http://www.securityweek.com/backdoors-not-patched-many-juniper-firewalls
The owners of more than 1,500 Juniper Networks firewalls still haven’t applied patches designed to address recently discovered backdoors, an Internet scan conducted by a researcher has shown.
Juniper Networks reported in mid-December that it had identified unauthorized code in ScreenOS, the operating system powering the company’s NetScreen firewalls.
The unauthorized code introduced two vulnerabilities: one that can be exploited to gain administrative access to affected devices (CVE-2015-7755), and one that can be leveraged to decrypt VPN connections (CVE-2015-7756).
Tomi Engdahl says:
Juniper resets ‘days since last rogue code incident’ clock
Proclaims Junos OS clean, takes out the trash by killing off Dual_EC in ScreenOS anyway
http://www.theregister.co.uk/2016/01/10/juniper_promises_to_dump_dual_ec/
Juniper Networks has announced its own investigations have found none of the “oops … how did that code get there” trouble in Junos OS and that it will kill off Dual Elliptic Curve (Dual_EC) encryption in ScreenOS.
The company says it hired a “respected security organization” that “undertook a detailed investigation of ScreenOS and Junos OS® source code.”
“After a detailed review, there is no evidence of any other unauthorized code in ScreenOS nor have we found any evidence of unauthorized code in Junos OS. The investigation also confirmed that it would be much more difficult to insert the same type of unauthorized code in Junos OS.”
Which doesn’t mean the company has a clean bill of health, because Juniper has decided to remove Dual_EC from Screen OS sometime in the first half of 2016.
Senior veep and CIO Bob Worrall writes that the Dual_EC and ANSI X9.31 crypto will both be replaced by “the same random number generation technology currently employed across our broad portfolio of Junos OS products”.