Juniper Backdoors and vendor stone throwing

By now many in the network and security field will have heard about the announcement from Juniper. Juniper’s commentary about an internal code review identifying malicious code on their ScreenOS platform sparked a marked increase of hype on the Twittersphere. Everywhere ranging from the US Senate down to the local security administrator people have been commenting.

Anything from “Who put it there?”, “Why did they put it there?” and “How did it not get noticed?” have been asked. Was it China or the NSA? Do we know who? No we do not. Should we speculate? No we should not. Will we find out the truth? Not unless it is a controlled media statement. To be honest these things are currently above my pay grade and will stay that way.

So as a network administrator who used to manage (and has upgraded some old ones from my last work places) what should you do?

Lets review what is known to the public

  • Juniper revealed they noticed additional and unauthorised code in the ScreenOS source. This has been in it since 2012.
    • ScreenOS 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20
  • VPN traffic passing through the device can be decrypted and subsequently inspected
  • System access can be gained via any named account active on the device with the password <<< %s(un=’%s’) = %u

Instead of running around like a headless chook calling for blood there are some course of action to take:

  1. Is this firewall internet facing or have internet access? If not, plan and validate the risk profile. Plan to update the version. See 2 and 3.
  2. Juniper have released updated versions of the ScreenOS software. Update as soon as possible.
  3. IDS or SNORT rules to protect against any login by a system account which will generate the idea alert.
# Signatures to detect successful abuse of the Juniper backdoor password over telnet.
# Additionally a signature for detecting world reachable ScreenOS devices over SSH.

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;)

 

Does this put a nail in the coffin of the Security business unit of Juniper? Probably not. What isn’t kosha is the fact that vendors are out for blood and throwing stones. I work for a software company. Network companies are evolving into software companies. I put this tweet out the other day

Now more than ever we should be vigilant. We should work to better ourselves. United we stand and together we fall.

For some more reading this Wired article provides a great summary.

Integrating vSRX into VIRL

Cisco VIRL is a learning platform which allows you to run real devices. It is built on an OpenStack architecture that allows rapid deployment of instances of NX-OS, IOSv, IOS-XE ASA and vSRX. I am going to show you the tips on getting it installed into OpenStack.
Thanks to those who want to remain anonymous for the tips, testing and variables.
Here are the steps so that you can inject a configuration file into the vSRX:
 1. Convert ‘thin provision’ image to ‘fat provision image’. This can be done usingthevmware-vdiskmanager as per below:

 /Applications/VMware\ Fusion.app/Contents/Library/vmware-vdiskmanager -r "junos-vsrx-12.1X46-D10.2-domestic-disk.vmdk" -t 0 “junos-vsrx-12.1X46-D10.2-domestic-disk1.vmdk"
2. The image needs to be modified to accept configuration file injection. This must be done BEFORE loading the image into VIRL via the User World Management (Skinned OpenStack) interface.
You can run the command above on your VIRL VM, so copy the image into the VIRL VM and execute there.
sudo kvm -M pc-1.0 -enable-kvm -daemonize -m 2048 -smp 2,sockets=2,cores=1,threads=1 -hda ./junos-vsrx-12.1X46-D10.2-domestic-disk1.vmdk \
-serial telnet::9101,server,nowait -net nic,model=e1000,vlan=1001,macaddr=00:01:00:ff:88:01 -nographic;telnet localhost 9101
login as ‘root’Edit the file /etc/fstab (nano /etc/fstab). The /etc/fstab should look like this (thevtbd1 disk is theconfig disk)

Device Mountpoint FStype Options Dump Pass#
/dev/md0 / cd9660 ro 0 0
proc /proc procfs rw 0 0
#/dev/bo0s1e /config ufs rw 2 2 
/dev/bo0s1b none swap sw 0 0
/dev/vtbd1s1 /config msdosfs rw 0 0

 

* /dev/bo0s1e /config ufs rw 2 2 is the old configuration disk.

* /dev/vtbd1s1 /config msdosfs rw 0 0 This is the FAT configuration disk.

Save the file.
Now we need to remove the SSH key. Remove the file with:
/etc/ssh/*key - 'rm /etc/ssh/*key
Shut the VM down.
3. The VM image is now ready to be loaded into UWM as a vSRX image.

Using the vSRX image in VIRL

You can add the vSRX image to your VIRL server under the ‘admin/images/’ menu by selecting ‘add’ and choosing ‘VSRX’ from the pick list, as per the picture:

 NOTE – If you want to make the vSRX image your default vSRX image, leave the Name/Version field blank. You can put release version information in the ‘release’ field.
If you create a topology with a vSRX node in it, at simulation start time, the system will look for a default vSRX image. If there is no default image, the simulation will not start and you will need to specifically set the VM_image and VM_flavor field values to the vSRX image that you’ve registered.
Configuration text placed in the ‘configuration’ field for the vSRX, will be automatically loaded into the VM at boot time. A correctly formatted JUNOS configuration will be applied assuming that there are no syntax errors! If you want to provision the VM with a basic set of user accounts, the configuration snippet below can be applied:
system {
  root-authentication {
    encrypted-password "$1$zdCNVrJU$xNlhBZZk8WOn8z3vl6LEs/"; ## SECRET-DATA
                      }
       login {
            user juniper {
                full-name juniper;
                uid 2001;
                class super-user;
                         authentication {
                         encrypted-password "$1$uRcJqW9g$ldwpqqgCZW17bw/tBUeFk/"; ## SECRET-DATA
           }
       }
    }
}
NOTE – if you do NOT pass in any configuration, vSRX will not like you and will crash on you!!! Make sure you pass in a minimal config, like the one below.

Your mileage may vary with this. VIRL is fun because there are lots of things happening behind the scenes.