Infocon Yellow: Juniper Backdoor (CVE-2015-7755 and CVE-2015-7756)

Published: 2015-12-21
Last Updated: 2015-12-21 19:03:23 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

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

 

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
4 comment(s)

Comments

KUDOS! Great thread.

IC
re: JUNIPER BACKDOOR

>>> ... effected ...

This homonym is not a synonym for 'affected' -- the word that should have been used.



>>> ... other then ...

Sample of Fortran-77 code to try to clarify:

if ( x "greater-THAN" y ) THEN write (*,*) 'True'
else write (*,*) 'False'

[where "greater-THAN" is coded in Fortran-77 as '.GT.']

shows the correct usage of 'THAN' and 'THEN'.

... Melvin (acting word-police & part-time Xmas-Grinch :-)

Feel free during "moderation" to DISCARD this comment.
fixed. should know better by now (I keep making these same mistakes...) but Monday morning diaries
Would it be fair to say that the parties potentially affected here extend beyond those who have Juniper kit to those who have data traversing VPNs with third-parties which terminate on Juniper kit, and thus clear-text passwords and anything else traversing such tunnels may be compromised?

Diary Archives