Infocon Yellow: Juniper Backdoor (CVE-2015-7755 and CVE-2015-7756)
Today 3pm ET, 12pm PT: Special Webcast "What you need to know about the Juniper backdoor" https://www.sans.org/webcasts/101482
We decided to move to raise our "Infocon" to yellow over the backdoor in Juniper devices. We decided to do this for a number of reasons:
- Juniper devices are popular, and many organizations depend on them to defend their networks
- The "backdoor" password is now known, and exploitation is trivial at this point. [2]
- With this week being a short week for many of us, addressing this issue today is critical
Who is affected by this issue?
Juniper devices running ScreenOS 6.3.0r17 through 6.3.0r20 are affected by the fixed backdoor password (CVE-2015-7755). [1]
Juniper devices running ScreenOS 6.2.0r15 through 6.2.0r18 and ScreenOS 6.3.0r12-6.3.0r20 are affected by the VPN decryption problem (CVE-2015-7756). [1]
| ScreenOS Version | Released | CVE-2015-7755 (telnet/ssh) | CVE-2015-7756 (VPN) |
| 6.2.0r15 | not vulnerable | vulnerable | |
| 6.2.0r16 | March 2013 | not vulnerable | vulnerable |
| 6.2.0r17 | May 2013 | not vulnerable | vulnerable |
| 6.2.0r18 | Oct 2013 | not vulnerable | vulnerable |
| 6.3.0r12 | Aug 2012 | not vulnerable | vulnerable |
| 6.3.0r13 | Dec 2012 | not vulnerable | vulnerable |
| 6.3.0r14 | Apr 2013 | not vulnerable | vulnerable |
| 6.3.0r15 | Sep 2013 | not vulnerable | vulnerable |
| 6.3.0r16 | Dec 2013 | not vulnerable | vulnerable |
| 6.3.0r17 | Apr 2014 | vulnerable | vulnerable |
| 6.3.0r18 | Dec 2014 | vulnerable | vulnerable |
| 6.3.0r19 | May 2015 | vulnerable | vulnerable |
| 6.3.0r20 | vulnerable | vulnerable | |
| 6.3.0r21 | Dec 2015 | not vulnerable | not vulnerable |
There are two distinct issues. First of all, affected devices can be accessed via telnet or ssh using a specific "backdoor" password. This password can not be removed or changed unless you apply Juniper's patch. Secondly, a purposely introduced weakness in the IPSEC encryption code allows an attacker familiar with the weakness to decrypt VPN traffic. [3]
Is there anything I can do other than "patch"?
Not really. To lower the probability of an exploit of the backdoor password, access to ssh and telnet can be restricted. Only administrative workstations should be able to connect to these systems via ssh, and nobody should be able to connect via telnet. This is "best practice" even without a backdoor. No workaround is available for the VPN decryption issue.
How do I know if I am vulnerable?
See the list of vulnerable ScreenOS versions available above. You can also try to log in to the device using the now known backdoor password: <<< %s(un='%s') = %u (less-than, less-than, less-than, space, percent, lower case s, open parentheses, lower case u, lower case n, equal sign, single quote, percent sign, lower case s, single quote, close paranthesis, space, equal sign, space, percent sign, lower case u).
How do I know if I have been exploited?
This login will look like any other login. Audit all logins to your Juniper devices running vulnerable versions of ScreenOS. The password has been made public yesterday (Sunday Dec 20th) evening. In particular if your device can be found in databases like Shodan, you should expect to be targeted.
FoxIT released snort rules that you can use to detect exploit attempts [4]. The first signature just detected if a telnet session was established. It is not used to actually alert, but just sets the flowbit that is used by later signatures that look for the password. For the SSH login, the password is encrypted. The signature below will trigger on all SSH logins to a Juniper device and it just looks for the typical NetScreen SSH banner.
alert tcp $HOME_NET 23 -> any any (msg:"FOX-SRT - Flowbit - Juniper ScreenOS telnet (noalert)";
flow:established,to_client; content:"Remote Management Console|0d0a|"; offset:0; depth:27;
flowbits:set,fox.juniper.screenos; flowbits:noalert; reference:cve,2015-7755;
reference:url,http://kb.juniper.net/JSA10713; classtype:policy-violation; sid:21001729; rev:2;)
alert tcp any any -> $HOME_NET 23 (msg:"FOX-SRT - Backdoor - Juniper ScreenOS telnet backdoor password attempt";
flow:established,to_server; flowbits:isset,fox.juniper.screenos;
flowbits:set,fox.juniper.screenos.password; content:"|3c3c3c20257328756e3d2725732729203d202575|";
offset:0; fast_pattern; classtype:attempted-admin; reference:cve,2015-7755;
reference:url,http://kb.juniper.net/JSA10713; sid:21001730; rev:2;)
alert tcp $HOME_NET 23 -> any any (msg:"FOX-SRT - Backdoor - Juniper ScreenOS successful logon";
flow:established,to_client; flowbits:isset,fox.juniper.screenos.password; content:"-> ";
isdataat:!1,relative; reference:cve,2015-7755; reference:url,http://kb.juniper.net/JSA10713;
classtype:successful-admin; sid:21001731; rev:1;)
alert tcp $HOME_NET 22 -> $EXTERNAL_NET any (msg:"FOX-SRT - Policy - Juniper ScreenOS SSH world reachable";
flow:to_client,established; content:"SSH-2.0-NetScreen"; offset:0; depth:17; reference:cve,2015-7755;
reference:url,http://kb.juniper.net/JSA10713; classtype:policy-violation; priority:1; sid:21001728; rev:1;)
References:
[1] http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10713&actp=search
[2] https://community.rapid7.com/community/infosec/blog/2015/12/20/cve-2015-7755-juniper-screenos-authentication-backdoor
[3] https://www.imperialviolet.org/2015/12/19/juniper.html
[4] https://gist.github.com/fox-srt/ca94b350f2a91bd8ed3f
Critical Security Controls: Getting to know the unknown
The Critical Security Controls (CSC) were recently updated, and quite some changes were made. What did not change, though, was the order of sequence of the first four critical controls, which are:
CSC-1: Inventory of Devices
CSC-2: Inventory of Software
CSC-3: Known secure configurations
CSC-4: Continuous Vulnerability Assessment and Remediation
This order of sequence didn't happen by coincidence. If you don't know what is on your network, you stand no chance of keeping it configured securely, or keeping it up to date. Yet, time and again, in audits we encounter networks where >20% more IP addresses are in use in the server room than are actually accounted for in the inventory. Some of this discrepancy is explained by failover/redundancy addresses. But, on closer investigation, a good chunk of it is usually also chalked up to so-called "appliances" that are treated as black boxes, until an outage or hacker proves that they aren't. With the nascent increase of "internet of things" devices, this will only get worse. Recently, we discovered our first office building door control system with a full-fledged web page of its own, and video feeds covering everyone who walked in our out. No password needed, and running a JBoss version from the Flintstone age. The organization's IT department did not feel responsible for the box because it had been installed by the building management department. The latter in turn did not feel responsible for the box because their vendor had strategically opted to market the device as "maintenance free" and "easy to use".
Keeping these devices under control is indeed a challenge in the DHCP space of user workstations. But it shouldn't be all that hard in the data center! While naked servers might BOOTP to the install server, anything else speaking DHCP in a server room should be hunted down. If the static IP Address assignment inventory is up to date, then the summarized Netflow logs of the datacenter routers can be reconciled daily against the IP addresses that are known as being in use, and everything else will clearly stand out.
Keeping track of software (CSC-2) is a bit more challenging, since everything installed "above" the OS layer can come from a plethora of application vendors, and can (and do) bundle a plethora of libraries and tools. You might remember this mess from when you had to track down how many of your devices were affected by Shellshock, Heartbleed or the recent Java Object Deserialization vulnerability: It is hard to impossible to know with certainty which version is bundled into which product. Nonetheless, the Critical Security Controls have a fair point in stating that you can only secure and patch what you know is running in your environment, and no fight was ever won by giving up at the onset.
Once you have CSC-1 and CSC-2 reasonably backed into a corner and wrestled into submission, it is then time to start with CSC-3 and CSC-4. I'm not saying that any of this is easy, to the contrary, it is tedious and often thankless work. But the number of breaches that were directly or indirectly caused by the organization not knowing what they were running, and not keeping it shipshape, is legion. CSC-1/2/3/4 are indeed at the core of every system security program. If you feel wobbly about yours, start your 2016 with taking a serious stab at getting CSC-1 under control, and then proceed from there.
Comments