(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:
1 2 3 4 5 6 7 8 9 10 11 12 |
-----BEGIN DSA PRIVATE KEY----- MIIBugIBAAKBgQDNDKy0QXmdcrbJJmTuSQMk84FQf2LEqL3nf80pvUdMei/CwVhX z59cgs7v9WCIwh1QHC27o77zYur7ogWVmNi9sF/eKLYrqdr0gJqnkAcDuMBEpwGB XYS2gb7BMf/NdAm5ebaxHLg+tt5fEVtryD00PCbojeoJ4CwaX5uTvOCdDQIVAJaX Q5MlbnSiT6IW9N8VXxjX5c41AoGASurznqfCCztT51ARlwpFJpU80ZxMJ40EVxb1 hd6sWs3Bn81ZraFHKCYCpdUgKjC65gUr/bWi7NBYG5SsvC6FiedqlJSM/Ez0NnzC xorxxyyBAyfkyvE4Y4YFVvhPck6tvLjWueNq7BJpDvJbUiUcoQm3VV/3LHHnkWea TbfpUUMCgYB4sdYhcT5ikdgu6CeG1PfKrlhO/azxLK5BrJjGgvsFm1d0TqRHu6dk RAffqcEUZBVougCvwxmRRNBU8EinphyCrimK61QaBDfXnMTzOLOItiYrCS4hSgzy kZND8iJQvuUXBhZe9EvL1XIi95C3DKjDo5GxV1G1U6lOKr8cml3kvgIUPjxDmEc8 IMkoCVKQ+XnA4kLYQis= -----END DSA PRIVATE KEY----- |
1 |
ssh-dss AAAAB3NzaC1kc3MAAACBAM0MrLRBeZ1ytskmZO5JAyTzgVB/YsSoved/zSm9R0x6L8LBWFfPn1yCzu/1YIjCHVAcLbujvvNi6vuiBZWY2L2wX94otiup2vSAmqeQBwO4wESnAYFdhLaBvsEx/810Cbl5trEcuD623l8RW2vIPTQ8JuiN6gngLBpfm5O84J0NAAAAFQCWl0OTJW50ok+iFvTfFV8Y1+XONQAAAIBK6vOep8ILO1PnUBGXCkUmlTzRnEwnjQRXFvWF3qxazcGfzVmtoUcoJgKl1SAqMLrmBSv9taLs0FgblKy8LoWJ52qUlIz8TPQ2fMLGivHHLIEDJ+TK8ThjhgVW+E9yTq28uNa542rsEmkO8ltSJRyhCbdVX/csceeRZ5pNt+lRQwAAAIB4sdYhcT5ikdgu6CeG1PfKrlhO/azxLK5BrJjGgvsFm1d0TqRHu6dkRAffqcEUZBVougCvwxmRRNBU8EinphyCrimK61QaBDfXnMTzOLOItiYrCS4hSgzykZND8iJQvuUXBhZe9EvL1XIi95C3DKjDo5GxV1G1U6lOKr8cml3kvg== root@ipm1 |
# Pre-generated RSA keys:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
-----BEGIN RSA PRIVATE KEY----- MIICWgIBAAKBgQC5zlj1iPoUM5ekobeIVV6eC2B2onqIkLHz86p3UE12wW+CU4Tj mHxcnJZ08UQXqFLRvci6xII7HTdw+8haXp6LWA677L3wxYmGR9ONa+4an7QusIKX WwvMyNderPq8fWjvipSIlhNNotAYrw/dUtB6gIDAgp9fN7L8IGFihpyK5QIBIwKB gD+0dkWODJk2Qp7YXC6+LxGdgCisvEwUWkUDFd/DwsmhaA9tF559bHeGJPTlAWcy ZYm9aWSbJVYYpUtPAt0nwVPB/+Mzm306bCWuzj9U13Q+2MMQsNs5ra/chUNz9TM2 TD1jMCjOajVzo6RicfXtzDldQeoOvAuSdjuqfPofHnaLAkEA9uuuPCYnvJEjhOyx egeRakT8ck1eR0Od8TDnP17B96RQZ0DmrWaTsM+MSMlDYx6820xWB9KSdnH2eSY/ 79cbMQJBAMCjYa9nm8k89NpiozpyINN2+U2GuauNmJR3HVtmJSdmQWyx1Y6hngtj Qkck4foeFlU0Knp9qwC9gktOnmaslfUCQQC+e0vlQgFllIkdZiKCtWGMflxYLQ42 +aW6D8hVdPwILkynbJSxpub2HHOIm0Kc69OEmfk5PAqV4uK1OsObwzI7AkBokzUH csJIrA/kRCy5U+XvI1QixXq8Nuxt2kMi/O+ZC5/b64KPQcrS+15+ZHqsWXnWe2eE UtksSZ6ApwWIMc2/AkBkitgYiFwS+A7GJjQ/5FYQMQrR6ksyf8JZGD/FqNSGkcmW UwYOYB3feqvpAW4N9Y4FUfgpFd0iBCbT2VCx8T2R -----END RSA PRIVATE KEY----- |
1 |
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAuc5Y9Yj6FDOXpKG3iFVengtgdqJ6iJCx8/Oqd1BNdsFvglOE45h8XJyWdPFEF6hS0b3IusSCOx03cPvIWl6ei1gOu+y98MWJhkfTjWvuGp+0LrCCl1sLzMjXXqz6vH1o74qUiJYTTaLQGK8P3VLQeoCAwIKfXzey/CBhYoaciuU= root@ipm1 |
HTTPS SSL Key & Certificate Details
File Location: /etc/lighttpd/
# server.pem file:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
-----BEGIN RSA PRIVATE KEY----- MIICWwIBAAKBgQCoNVA4wWDqXQZkZGmlGEppj1/ssMMckPOnM9uod9pIAiximAtF 3N/WlbrlsnkyjQ78QVk+bLsGTR3YFgV4EEFb89hz0vz6qKCrjHo0+3f+kkiBkUbd 01KV9gUIL85lqTHRRv84upnd7NOQbuepR3Wj8ie3T4FNPY1cpbAVz7lSdwIDAQAB AoGAJaRYoXrU/1118r1tzt5SuLC3HLap0xi1DfPS8i5wELE70YyI6Ud2aAT14DVC XgenFNhi6k9WwyA6z4KOEsJAfcB/WKQrKsCJW0pHH80aDQuN4N7N20ugbL0yD0tc DSVhkvWYPfTNd83Zwxd6LVM+xifp2pP/snpaF0KHQh3eR5ECQQDSXrYp3bVJZczh /0hQIrLlviaEZXYBN0ysmwt2WD602id9qowGzmEbJGRifs7TukejBvok5QJdiZWd kDWr01rLAkEAzLF5LKJPQcNxgbKAO5YxJhVT4bfcL+GtYd9ZLZX7XGYKXSgRDWK+ tRmZKFnT5iHnWKiIa0KiL5D2iMvVk9mVhQJAAKlHjU4jGb32LOeuhIH3af11BYmE G3DfDtPV72NLnynoYd69XfAcIge1QRIA+G1neD23X5JQtZaPH9WqNYYOjQJAK3+f d4u6egg1i9FKDN+a7DPmEnaG9SnpNX5ILjbMJtOMakWEcirEyil5cai9Lg+QYTfX XavYWXFd4q4mYfgAHQJADxKFfugi5/B0++FAFBKJ3iyXOXJJb/usdvQ8fM8HWzq6 AILHMqQfJkmPFNlqrPFACIwfetFBfVxrLaAP5GK6Gw== -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIC2TCCAkICAQAwDQYJKoZIhvcNAQEEBQAwgbQxCzAJBgNVBAYTAlVTMREwDwYD VQQIEwhOZXcgWW9yazEVMBMGA1UEBxMMQ2xpZnRvbiBQYXJrMSowKAYDVQQKEyFE aWdpdHJvbmljcyBJbnZlbnRpb25lZXJpbmcgQ29ycC4xDzANBgNVBAsTBlNJWE5F VDEZMBcGA1UEAxMQd3d3LnNpeG5ldGlvLmNvbTEjMCEGCSqGSIb3DQEJARYUc3Vw cG9ydEBzaXhuZXRpby5jb20wHhcNMDAwMTAxMDAxNTM1WhcNMzQxMjMxMDAxNTM1 WjCBtDELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE5ldyBZb3JrMRUwEwYDVQQHEwxD bGlmdG9uIFBhcmsxKjAoBgNVBAoTIURpZ2l0cm9uaWNzIEludmVudGlvbmVlcmlu ZyBDb3JwLjEPMA0GA1UECxMGU0lYTkVUMRkwFwYDVQQDExB3d3cuc2l4bmV0aW8u Y29tMSMwIQYJKoZIhvcNAQkBFhRzdXBwb3J0QHNpeG5ldGlvLmNvbTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAqDVQOMFg6l0GZGRppRhKaY9f7LDDHJDzpzPb qHfaSAIsYpgLRdzf1pW65bJ5Mo0O/EFZPmy7Bk0d2BYFeBBBW/PYc9L8+qigq4x6 NPt3/pJIgZFG3dNSlfYFCC/OZakx0Ub/OLqZ3ezTkG7nqUd1o/Int0+BTT2NXKWw Fc+5UncCAwEAATANBgkqhkiG9w0BAQQFAAOBgQB8TeLtDoefrLElT34FgjfgxQYx znvgFAzJQvRjeNmz8hJ4Mea+0xeTIxUst6sFfG0wVSqiSw8fU3amuQpsYN5EbM7P wyQDjSATg8ZC+A5XQKkAGlKBfoQFH5ExdgdfEClmbS+q60wMPdmfYS3YG0iEXAxy uf28T8iyDVVJGiQJpw== -----END CERTIFICATE----- |
# https.conf configuration file
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
$SERVER["socket"] == "[::]:443" { ssl.engine = "enable" ssl.pemfile = "/etc/lighttpd/server.pem" # ssl.ca-file = "/etc/CA.crt" server.name = "www.sixnetio.com" server.document-root = "/var/www/htdocs/" } $SERVER["socket"] == "0.0.0.0:443" { ssl.engine = "enable" ssl.pemfile = "/etc/lighttpd/server.pem" # ssl.ca-file = "/etc/CA.crt" server.name = "www.sixnetio.com" server.document-root = "/var/www/htdocs/" } |
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:
1 2 3 4 5 6 7 8 9 |
root:FVKARGRgureGENX:0:0:root:/:/bin/echo bin:*:1:1:bin:/bin: ftp:*:0:0:anon ftp:/: nobody:*:99:99:Nobody:/: admin:lwRH8eYw8OfAc:101:101:Switch Administrator:/home/admin:/usr/local/bin/adminsh cli:lwRH8eYw8OfAc:102:101:Switch Administrator CLI:/home/admin:/usr/local/bin/cfgcli sertest::99:99:Factory Test:/:/usr/local/bin/loopsertest.login guest:*:500:500:guest:/: PPPLink:*:601:601:PPPLink:/: |
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.
Congratulations! Great to see you are making waves.
Thanks mate…