Nessus reports "SSL 64-bit Block Size Cipher Suites Supported" potential Vulnerability against TCP 1443

  • 7020258
  • 06-Jun-2017
  • 09-Jun-2017

Environment

NetIQ Access Manager 4.3
NetIQ Access Manager 4.2
NetIQ Access Manager Admin Console

Situation

A Nessus scan was run against NAM 4.3.1 and the following vulnerability in relation to some weaker ciphers (DES) used in some of the internal communication port like (1443) was reported. Since these protocols and ciphers do not appear to be configurable using any configuration file, should I be worried.

Synopsis

The remote service supports the use of 64-bit block ciphers.

Description

The remote host supports the use of a block cipher with 64-bit blocks in one or more cipher suites. It is, therefore, affected by a vulnerability, known as SWEET32, due to the use of weak 64-bit block ciphers. A man-in-the-middle attacker who has sufficient resources can exploit this vulnerability, via a 'birthday' attack, to detect a collision that leaks the XOR between the fixed secret and a known plaintext, allowing the disclosure of the secret text, such as secure HTTPS cookies, and possibly resulting in the hijacking of an authenticated session.

Proof-of-concepts have shown that attackers can recover authentication cookies from an HTTPS session in as little as 30 hours.

Note that the ability to send a large number of requests over the same TLS connection between the client and server is an important requirement for carrying out this attack. If the number of requests allowed for a single connection were limited, this would mitigate the vulnerability. However, Nessus has not checked for such a mitigation.

See Also

https://sweet32.info
https://www.openssl.org/blog/blog/2016/08/24/sweet32/

Solution

Reconfigure the affected application, if possible, to avoid use of all 64-bit block ciphers. Alternatively, place limitations on the number of requests that are allowed to be processed over the same TLS connection to mitigate this vulnerability.

Resolution

Fixed in NAM 4.4.

The SSL session tcp port 1443 is triggered when the Admin Console (AC) pushes and update to the IDP/AG, or when healthcheck information is being sent back to AC. Without access to this communication path, one cannot intercept the traffic. To further lock down security, one can use iptables on IDP/AG to only allow communication on TCP 1443 from the AC.