How to disable support for 3DES suite through dev Firewall?

[DCIM_Support]

Hello,
Our security scan has found the following vulnerability with our all APC AP8888 devices
***TLS/SSL Birthday attacks on 64-bit block ciphers (SWEET32)***
Is there any firewall rule that I can create in the device through the GUI under security >>firewall options to disable 3DES cipher suite? So that we can provide mitigation to this vulnerability?
Thanks in advance for any information you may provide.

(CID:129413129)

[DCIM_Support]

Dear Cristian Arias Lopez,

Please clarify:

• What version of firmware on your AP8888 is used?
• On your AP8888 devices the HTTP protocol (80 port) is disabled and only the HTTPS protocol (443 port) is enabled (or not)?
• What is the minimum supported encryption method used on your AP8888 devices (SSLv3, TLSv1, TLSv1.1 or TLSv1.2)?

The more information you provide, the sooner we solve your problem.

With respect.

(CID:129413313)

[DCIM_Support]

Hello, 

Thank you for the prompt reply. All our PDU devices have the same configuration, however, we have different FW versions since there are various models.

These are for the settings for the models

AP8888

Firmware 6.4.4

HTTP: Disable

HTTPS: Enable/port443/ minimum protocol TLS 1.2

FTP: Disable

Telnet: Disable

SSH: Enable/port22

SNMPv1: Disable

SNMPv3: Enable/SHA/AES

Firewall: Disable

Thank you for all your assistance.

 ******Vulnerability Title******

TLS/SSL Birthday attacks on 64-bit block ciphers (SWEET32)

*******Vulnerability Description******

Legacy block ciphers having a block size of 64 bits are vulnerable to a practical collision attack when used in CBC mode. All versions of the SSL/TLS protocols that support cipher suites which use 3DES as the symmetric encryption cipher are affected. The security of a block cipher is often reduced to the key size k: the best attack should be the exhaustive search of the key, with complexity 2 to the power of k. However, the block size n is also an important security parameter, defining the amount of data that can be encrypted under the same key. This is particularly important when using common modes of operation: we require block ciphers to be secure with up to 2 to the power of n queries, but most modes of operation (e.g. CBC, CTR, GCM, OCB, etc.) are unsafe with more than 2 to the power of half n blocks of message (the birthday bound). With a modern block cipher with 128-bit blocks such as AES, the birthday bound corresponds to 256 exabytes. However, for a block cipher with 64-bit blocks, the birthday bound corresponds to only 32 GB, which is easily reached in practice. Once a collision between two cipher blocks occurs it is possible to use the collision to extract the plain text data.

******Proof****

* Negotiated with the following insecure cipher suites: * TLS 1.0 ciphers: * TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA * TLS_PSK_WITH_3DES_EDE_CBC_SHA * TLS_RSA_WITH_3DES_EDE_CBC_SHA * TLS 1.1 ciphers: * TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA * TLS_PSK_WITH_3DES_EDE_CBC_SHA * TLS_RSA_WITH_3DES_EDE_CBC_SHA * TLS 1.2 ciphers: * TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA * TLS_PSK_WITH_3DES_EDE_CBC_SHA * TLS_RSA_WITH_3DES_EDE_CBC_SHA

(CID:129413634)

[DCIM_Support]

Dear Cristian Arias Lopez,

I believe, that at the moment, even if you have the latest firmware v.6.5.2 on your devices (I highly recommend upgrading since you use SNMPv3), you can not get rid of the above mentioned vulnerability.

I.e., the enable and subsequent configuration of the firewall in this case are useless. This vulnerability can be closed only by making the necessary changes in the firmware of the devices, i.e. refusing to use 3DES cipher suite altogether. More information about this can be found at link Impact and Mitigation on site https://sweet32.info/.

For information, here is the result of scanning my rPDU with the latest firmware v.6.5.2 with the minimum supported protocol TLSv1.2:

bashnmap -p 443 --script ssl-enum-ciphers 192.168.0.76# nmap -p 443 --script ssl-enum-ciphers 192.168.0.76 Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-30 11:42 EEST Nmap scan report for 192.168.0.76 Host is up (0.044s latency). PORT STATE SERVICE 443/tcp open https | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_PSK_WITH_3DES_EDE_CBC_SHA - strong | TLS_PSK_WITH_AES_128_CBC_SHA - strong | TLS_PSK_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | compressors: | NULL | TLSv1.1: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_PSK_WITH_3DES_EDE_CBC_SHA - strong | TLS_PSK_WITH_AES_128_CBC_SHA - strong | TLS_PSK_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | compressors: | NULL | TLSv1.2: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong | TLS_PSK_WITH_3DES_EDE_CBC_SHA - strong | TLS_PSK_WITH_AES_128_CBC_SHA - strong | TLS_PSK_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA256 - strong | compressors: | NULL |_ least strength: strong MAC Address: 00:C0:B7:xx:xx:xx (American Power Conversion) Nmap done: 1 IP address (1 host up) scanned in 17.74 seconds

Therefore, at the moment, while this vulnerability is not completely closed, I highly recommend reconnecting all your rPDUs to an isolated private LAN, which only the DCE server has access to. It is this design, that initially assumes DCE software by default.

If this is not possible, and your rPDU should be on the public LAN, I recommend that you enable the firewall and restrict access by rules with the exact host(s) name from which access to port 443 is allowed. And of course, on the host(s) from which you will be accessing the web-GUI of your rPDU on port 443, you must work with a modern browser, as indicated on the resource https://sweet32.info/:

• Web browsers should offer 3DES as a fallback-only cipher, to avoid using it with servers that support AES but prefer 3DES.

Only then this solution can very much minimize the risk from the above vulnerability and simply not use the vulnerable 3DES cipher suite for communicate.

I hope this helps you.

With respect.

(CID:129413740)

[DCIM_Support]

Hello, 

Thank you for the prompt reply I was really hoping that there was a simpler way to work around this vulnerability. I'll follow with the security team to discuss to discuss our options.

Thanks again for all your assistance.

(CID:130091598)

[DCIM_Support]

Dear Cristian Arias Lopez,

Ok, thanks for the feedback 😀.

I will also be interested in knowing your way of solving this problem.

(CID:130091596)

[DCIM_Support]

This question is closed for comments. You're welcome to start a new topic if you have further comments on this issue.