Scanner detected vulnerabilities on TLS1.0 and SSL/TLS

[SebastienSentrian]

Hi,
one of our customer using some Netonix switches mainly WS-12-250-AC and they ran few security audits and penetration tests.
In despite of upgrading the firmware for the switches to the latest version 1.5.25, The scanner still generates alerts on :

1. TLS1.0 - ssl-enum-ciphers_TLSv1.0_443
SSL/TLS Server supports TLSv1.0. TLS is capable of using a multitude of ciphers (algorithms) to create the public and private key pairs. For example if TLSv1.0 uses either the RC4 stream cipher, or a block cipher in CBC mode.
RC4 is known to have biases and the block cipher in CBC mode is vulnerable to the POODLE attack. TLSv1.0, if configured to use the same cipher suites as SSLv3, includes a means by which a TLS implementation can downgrade the connection to SSL v3.0, thus weakening security. A POODLE-type attack could also be launched directly at TLS without negotiating a downgrade...

2. ssl-dh-params
Diffie-Hellman Key Exchange Insufficient Group Strength
Transport Layer Security (TLS) services that use Diffie-Hellman groups of insufficient strength, especially those using one of a few commonly shared groups, may be susceptible to passive eavesdropping attacks.
Check results: WEAK DH GROUP 1
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA
Modulus Type: Non-safe prime
Modulus Source: RFC5114/1024-bit DSA group with 160-bit prime order subgroup
Modulus Length: 1024 , Generator Length: 1024 , Public Key Length: 1024

I can't find from the web interface how to deactivate TLS1.0 and the cipher suite "TLS_DHE_RSA_WITH_AES_128_CBC_SHA".
Is there any command line using the "Console" or "SSH" to do the job?
We need to address it otherwise the customer will fail the security audit.
Thank you.
Regards,
Sebastien

[Stephen]

Thank you for the information, given the urgency of this scenario, could you please PM me a PDF report of the scan? I will also need the switch logs preferably taken during the scan, and a backup of the config. That will help us find a solution as quickly as possible.

[sirhc]

Also keep on mind that if you use the Access Control List AS RECOMMENDED only those devices in the access control list can even see the unit, that's why it's there.

The last and only hack was due to PHP which was removed.


Keep on mind we are using TLS v1.2 we just allow backeard compatibility to TLS v1.0 for users using g older browsers.

However this is NOT a vulnerability that would allow a hacker to gain access to your switch.

"IF"they were able to cracked 2 encryption keys which i doubt and they were say monkey in the middle able to intercept communications between you and the switch they could see that communications.

I do NOT see this as an issue. If we turned off downward compatibility from TLS v1.2 to v1.0 I suspect a lot of pissed off people.

[sirhc]

A more detailed explanation by Stephen below:

Regarding the post: "1. TLS1.0 - ssl-enum-ciphers_TLSv1.0_443" translation: TLS 1.0 is technically still enabled by the server, we left it for backwards compatibility. Arguably that time has past, but not sure. (as in, maybe other clients don't need this anymore, but not certain)"

[Flo]

Hi,
one of our customer using some Netonix switches mainly WS-12-250-AC and they ran few security audits and penetration tests.
In despite of upgrading the firmware for the switches to the latest version 1.5.25, The scanner still generates alerts on :

1. TLS1.0 - ssl-enum-ciphers_TLSv1.0_443
...
We need to address it otherwise the customer will fail the security audit.
Thank you.
Regards,
Sebastien

Sebastien,

running the following commands via SSH -> cmdline should resolve your issue:

Code: Select all

sed -i '/ssl.pemfile = .*/{N; /\n\ \ \ \ \ \ \ \ ssl.openssl.ssl-conf-cmd = ("MinProtocol" => "TLSv1.2")$/b; s/\n/\n\ \ \ \ \ \ \ \ ssl.openssl.ssl-conf-cmd = ("MinProtocol" => "TLSv1.2")\n/}' /etc/lighttpd.conf \
&& /etc/init.d/lighttpd restart \
 && echo "restarted lighttpd with modified configuration: allow TLSv1.2 connection or higher versions, only."


You can verify it using OpenSSL:

Code: Select all

 openssl s_client -connect [Netonix-Switch-IP]:443 -tls1_1

Replace tls1_1 with tls1 or tls1_2 if needed.

[sirhc]

Keep in mind this fix above is lost with firmware upgrade or default.

It's really not a high risk vulnerability.

But on next release we will disable TLS v1.0 but I suspect people running old OS or Browsers will complain.

This is a low risk issue. But again use Access Control List and even old hack would not have worked unless a devices in the access list is compromised.

[SebastienSentrian]

Thank you for the wait and for your responses.
The scanner doesn't give more details on this issue unfortunately, I don't have any CVE linked with.
So all the details that I have, I added them to the initial post.

My customer needs to address them to have its Certification after the Audit.
So we need to address it as it is flagged as risk unfortunately.

Thank you Flo for the command to deactivate it. I didn't test it yet, it will depend when the new firmware will be released to avoid to do the job twice.
Sirhc, do you have any release date of the new firmware version which will deactivate TLS v1.0?

Thank you again for your time, really appreciate!!!
Seb

[SebastienSentrian]

The same customer had a penetration test operated few days ago.
They found unsupported version of PHP 5.2.6 on the Netonix switches WS-12-250-AC (firmware 1.5.25 and 1.5.14).

This version is exposed to some vulnerabilities, here the list :
Vulnerability Reference CVSS Score Impact
- CVE-2008-5557 10 - Critical An unauthorised threat actor in a specific context may be able to execute arbitrary code on the underlying host by sending a specially crafted request.
https://www.cvedetails.com/cve/CVE-2008-5557/
- CVE-2012-2376 10 - Critical An unauthorised threat actor may be able to execute code on the underlying host by sending a specially crafted request.
https://www.cvedetails.com/cve/CVE-2012-2376/
- CVE-2015-4599 9.8 - Critical An unauthorised threat actor may be able to obtain sensitive information, perform a DoS (Denial of Service) attack, or execute arbitrary code on the underlying host by sending a specially crafted request.
https://www.cvedetails.com/cve/CVE-2015-4599/
- CVE-2015-4600 9.8 - Critical An unauthorised threat actor may be able to perform a DoS (Denial of Service) attack or execute arbitrary code on the underlying host by sending a specially crafted request.
https://www.cvedetails.com/cve/CVE-2015-4600/
- CVE-2015-4601 9.8 - Critical An unauthorised threat actor may be able to perform a DoS (Denial of Service) attack or execute arbitrary code on the underlying host by sending a specially crafted request.
https://www.cvedetails.com/cve/CVE-2015-4602/
- CVE-2015-4602 9.8 - Critical An unauthorised threat actor may be able to perform a DoS (Denial of Service) attack or execute arbitrary code on the underlying host by sending a specially crafted request.
- CVE-2015-4603 9.8 - Critical An unauthorised threat actor may be able to execute arbitrary code on the underlying host by sending a specially crafted request.
https://www.cvedetails.com/cve/CVE-2015-4603/
- CVE-2015-4642 9.8 - Critical An unauthorised threat actor may be able to execute arbitrary code on the underlying host by sending a specially crafted request.
https://www.cvedetails.com/cve/CVE-2015-4642/
- CVE-2016-2554 9.8 - Critical An unauthorised threat actor may be able to perform a DoS (Denial of Service) attack by sending a specially crafted TAR archive.
https://www.cvedetails.com/cve/CVE-2016-2554/
- CVE-2012-1823 9.8 - Critical An unauthorised threat actor may be able to remotely execute arbitrary code on the underlying system by specifying command line options in a specially crafted request.
https://www.cvedetails.com/cve/CVE-2012-1823/

This time, I've got the link to the CVE as above.
The recommendation is to upgrade PHP to version 8.x .

Is it something that you have in mind and schedule to do in a short period of time?
Sorry but we need to get back to customer with some Remediation plans so we need to check if it is possible to fix the vulnerabilities.
Thank you very much for your time and effort guys.
Seb

[Stephen]

Hey Sebastian,

There is something wrong with those reports. PHP does not exist in any way on 1.5.25, the system was completely redesigned to remove it entirely.

[sirhc]

Yep, terrible report, as stephen said there is no PHP in version 1.5.25.

If you want to secure your switch 100% use the Access Control List.

But again the TLS v1.0 downward compatibility is NOT a vulnerability to gain access to the the switch.


Someone would have to be monkey in the middle then decipher 1024 (TLS 1.0) is not easy. But how do they intercept that traffic and get in middle?

If they are talking across wireless link then they could gain access that way but they would have to crack WPA2 then crack 1024. Who can do this? And besides if they cracked your wireless encryption gaining access to switch is least of your problems.

We do plan to put option in v1.5.26 to disable TLS v1.0 if you choose but I have customers on 3rd wourld countries running Windows 95....

Since v1.5.25 is very stable and secure we don't plan on working on v1.5.26 until late summer.

Again use Access Control List and no one gets into switch even older versions. But if your testing v1.5.14 which is YEARS old and known hack via PHP then again I ask WHY? But again Access Control List will protect you.

Unless you use an Access Control List then even Cisco is vulnerable to a brute force hack pounding away at telnet or SSH or DOS and so on.

The tools are there to use for a reason.