(CVE-2017-9335) Red Lion Controls Sixnet-Managed Industrial Switches, AutomationDirect STRIDE-Managed Ethernet Switches Vulnerabilities

Background:

On the 16th October 2016 I discovered a number of vulnerabilities in Red Lion Controls’ Sixnet SLX Managed Industrial Switches and AutomationDirect’s STRIDE Managed Ethernet Switches. The industrial switches are commonly deployed worldwide in critical infrastructure environments and were identified to Use Hard-coded Cryptographic Keys (CVE-2017-9335 | CWE-321) as well as Incorrect Permissions Assignment for a Critical Resource (CWE-732).

Coordinated disclosure regarding the identified vulnerabilities was undertaken with the US Department of Homeland Security’s ICS-CERT, Red Lion Controls, and Automation Direct, resulting in the release of ICS-CERT Advisory ICSA-17-054-02.

The Department of Homeland Security’s ICS-CERT advisory (ICSA-17-054-02 ) can be found here.

In response to the coordinated disclosure activities, Red Lion Controls have released SLX firmware version 5.3.174 to address one of the vulnerabilities. Red Lion Controls have advised that they will not be actioning the vulnerability pertaining to the Incorrect Permissions Assignment for a Critical Resource.

Use of Hard-coded Cryptographic Keys (CVE-2017-9335 | CVSS 10)

Summary

Product: AutomationDirect STRIDE Managed Ethernet Switches
Version: Latest firmware 5.0.190
Model/s: SE-SW5M, SE-SW5M-2SC, SE-SW5M-2ST, SE-SW8M, SE-SW8M-2SC, SE-SW8M-2ST, SE-SW8MG-4P, SE-SW10MG-2P, SE-SW16M

Product: Red Lion Controls Sixnet SLX Managed Industrial Switches
Version: Firmware version 5.0.196 and prior
Model/s: SL and SLX series, EK/EF series, ET MIL-rated switches, ET OEM (board-level) switches

Hard-coded SSH and SSL keys were identified in AutomationDirect STRIDE Managed Ethernet Switches running the current and up-to-date firmware, as well as Red Lion Controls Sixnet SLX Managed Industrial switches running firmware version 5.0.196 and prior.

Disclosure Timeline

16 October 2016 – Hardcoded SSH Key vulnerability discovered. Further testing commenced.
31 October 2016 – Emailed ICS-CERT with full vulnerability details
03 November 2016 – Advice from ICS-CERT that a ticket had been assigned.
22 November 2016 – 08 February 2017 – Multiple emails between all parties
15 February 2017 – Initial draft advisory and CVE assignment from ICS-CERT
15 February 2017 – Acceptance of CVE’s and advisory draft.
23 February 2017 – Full disclosure of vulnerabilities to the public.

Tested versions

This vulnerability was tested on the following firmware:

– AutomationDirect STRIDE Managed Ethernet Switch firmware 5.0.190
– Red Lion Controls Sixnet SLX Managed Industrial Switch firmware 5.0.196

Details

Vulnerable versions of the AutomationDirect STRIDE Managed Ethernet Switches and Red Lion Controls Sixnet SLX Managed Industrial Switches use hardcoded SSH and SSL keys for secure communication. As the secure keys cannot be regenerated by a user, all deployed Managed Ethernet and Industrial Switches utilise the same key.

An attacker may leverage this vulnerability by copying the secure keys from the firmware available on the vendors FTP servers. Once the secure key has been obtained, it could be possible for a malicious actor to intercept or disrupt communications utilising the SSH and SSL protocols.

SSH Key Details

File Location: /etc/ssh/

# Pre-generated DSA keys:

# Pre-generated RSA keys:

HTTPS SSL Key & Certificate Details

File Location: /etc/lighttpd/

# server.pem file:

# https.conf configuration file

Incorrect Permission Assignment for a Critical Resource

Summary

Product: Red Lion Controls Sixnet SLX Managed Industrial Switches
Version: Firmware version 5.0.196 and prior
Model/s: SL and SLX series, EK/EF series, ET MIL-rated switches, ET OEM (board-level) switches

Product: AutomationDirect STRIDE Managed Ethernet Switches
Version: Latest firmware 5.0.190
Model/s: SE-SW5M, SE-SW5M-2SC, SE-SW5M-2ST, SE-SW8M, SE-SW8M-2SC, SE-SW8M-2ST, SE-SW8MG-4P, SE-SW10MG-2P, SE-SW16M

Hard-coded Secure Shell (SSH) and Secure Socket Layer (SSL) keys were identified in AutomationDirect STRIDE Managed Ethernet Switches running the current and up-to-date firmware, as well as Red Lion Controls Sixnet SLX Managed Industrial switches running firmware version 5.0.196 and prior.

Disclosure Timeline

16 October 2016 – Hardcoded SSH Key vulnerability discovered. Further testing commenced.
31 October 2016 – Emailed ICS-CERT with full vulnerability details
03 November 2016 – Advice from ICS-CERT that a ticket had been assigned.
22 November 2016 – 08 February 2017 – Multiple emails between all parties
15 February 2017 – Initial draft advisory and CVE assignment from ICS-CERT
15 February 2017 – Acceptance of CVE’s and advisory draft.
21 February 2017 – Vendor advised they will not release a patch or CVE for this issue as they believe it is not a vulnerability, but rather a bad security practice.
23 February 2017 – Full disclosure of vulnerabilities to the public.

Tested versions

The incorrect file permissions vulnerability was tested on the following firmware:

– Red Lion Controls Sixnet SLX Managed Industrial Switch firmware 5.0.196
– AutomationDirect STRIDE Managed Ethernet Switch firmware 5.0.190

Details

Vulnerable versions of the AutomationDirect STRIDE Managed Ethernet Switches and Red Lion Controls Sixnet SLX Managed Industrial Switches have incorrect world-readable permissions applied to the passwd file storing user credentials. The vulnerable switches also use weak password storage practices by not implementing best practice shadowing capability.
An attacker who gains access to the devices may leverage this vulnerability by copying the user credentials in the passwd file and performing a brute force attack against the password hashes, thus exposing account details.
/etc/passwd Details

File Location: /etc/passwd
File permissions: -rw-r–r–(611)

# Default passwd file:

POC

This POC details the steps to be undertaken in order to replicate the above vulnerability identification. The information is purposely verbose in order to help those who are starting out with firmware analysis for the purpose of vulnerability identification.

Step 1: Obtain the vulnerable firmware version from the vendor (note that no authentication is required to obtain vendor firmware):

• wget http://ftp.automationdirect.com/pub/stride_firmware.zip

Step 2: unzip the firmware and run the file command to initially identify the file type.

Step 3: As the file has only been identified as ‘data’, we will use the binwalk tool to identify the data in the binary.

• binwalk automationdirect-ms5_0_190.fwb

Step 4: As we can see, binwalk has identified a JFFS2 filesystem exists within the file. We can extract the filesystem by using the –e argument with binwalk. By default, binwalk extracts files into a directory where the binary is being executed. Running file now identifies that we are indeed working with a JFFS2 filesystem.

• binwalk –e automationdirect-ms5_0_190.fwb
• cd _automationdirect-ms5_0_190.fwb.extracted/
• ls
• file A3.jffs2

Step 5: Unlike other filesystems, we cannot directly mount a JFFS image as a loopback device. We will create temporary flash device and mount our filesystem image with the following commands (note you will need to be root to perform these actions):

• modprobe mtdblock
• modprobe mtdram total_size=32768 erase_size=256
• dd if=A3.jffs2 of=/dev/mtdblock0
• mkdir jffs2
• mount -t jffs2 /dev/mtdblock0 jffs2/

Step 6: Taking a look at our mounted file system we can see that we have similarities to a standard *nix environment. From here, it is just a matter of enumeration to identify possible vulnerabilities in the system.

Use of Hard-coded Cryptographic Keys (CVE-2017-9335 | CVSS 10)

Step 7: We can identify our vulnerable hard-coded SSH RSA and DSA keys by issuing the following command:

• cat etc/ssh/ssh_host_rsa_key etc/ssh/ssh_host_rsa_key.pub

In order to verify that these keys are hard-coded, you need to compare the results on another device running the same firmware version.

Step 8: The vulnerable hard-coded SSL key and certificate can be found by issuing the following command:

• cat etc/lighttpd/server.pem

Step 9: By investigating the https.conf configuration file, we can see that the above private key and certificate is in fact utilised by the web server on the device:

• cat etc/lighttpd/https.conf

In order to verify that these keys are hard-coded, you need to compare the results on another device running the same firmware version.

Incorrect Permission Assignment for a Critical Resource

Step 10: As you can see in the following screenshot, the passwd file has weak world-readable permissions allocated. As such, if an unauthorised or low privileged user was able to gain access to the system, they could easily identify the password hashes associated with a user’s account. This is an example of very poor credential security which not only has poor file permissions, it also does not utilise password shadowing, which is considered best practice for *nix based systems.

• ls –al etc/passwd
• cat etc/passwd

Implemented fixes

Red Lion Controls and AutomationDirect have released firmware version 5.3.174 in order to rectify the identified vulnerabilities.

Important note: Neither Red Lion Controls or AutomationDirect provide MD5 or other checksums for downloadable files. As such, it is difficult to verify the authenticity of file versions downloaded from the Internet, and appropriate precautions must be taken prior to updating devices and associated software.

Red Lion Controls’ updated firmware release is available here.

AutomationDirect’s updated firmware release is available here.

In relation to the Incorrect Permission Assignment for a Critical Resource vulnerability, it is recommended that users of the affected products contact the vendor Red Lion Controls or AutomationDirect should the unmitigated risk be identified as a threat to their infrastructure.

The MD5 and SHA1 checksums for the firmware version I downloaded are as follows:

The fixes which relate to the hard-coded vulnerabilities come in the form of two scripts which execute upon boot-up, and two further scripts which are called should certain conditions be met.

The boot-up scripts, named ssh and webserver, have been introduced in the /etc/init.d/ directory. The complimentary scripts, named generateSSHKeys and generateSSLKeys, have been introduced in the /usr/local/bin/ directory.

No fixes have been implemented for the insecure file permissions and the unshadowed passwd scheme.

/etc/init.d/ssh script

This script simply checks if a file (/usr/local/bin/required_ssh_keys_exist) exists upon device boot-up. This file simply sets a flag based upon whether new and random SSH keys have been generated. If the file does not exist, a second script (/usr/local/bin/generateSSHKeys) is called, which, as the name suggests, will generate new random SSH1 RSA, SSH2 RSA, and SSH2 DSA keys.

/etc/init.d/webserver script

Similar to the ssh script, this script is executed upon device boot-up, and simply calls a second script (/usr/local/bin/generateSSLKeys), which, as the name suggest, will generate a new 2048-bit private key and x509 certificate.



2 Comments

  1. Adam B wrote:

    Congratulations! Great to see you are making waves.