SSL/TLS: Renegotiation DoS Vulnerability (CVE-2011-1473, CVE-2011-5094)

[Leo LemogrA]

We are using wazuh 4.5.0 and getting below Result with Greenbone Security Assistant for our wazuh server.

Summary

The remote SSL/TLS service is prone to a denial of service (DoS) vulnerability.

Detection Result

The following indicates that the remote SSL/TLS service is affected: Protocol Version | Successful re-done SSL/TLS handshakes (Renegotiation) over an existing / already established SSL/TLS connection ---------------------------------------------------------------------------------------------------------------------------------- TLSv1.2 | 10

Insight

The flaw exists because the remote SSL/TLS service does not properly restrict client-initiated renegotiation within the SSL and TLS protocols. Note: The referenced CVEs are affecting OpenSSL and Mozilla Network Security Services (NSS) but both are in a DISPUTED state with the following rationale: > It can also be argued that it is the responsibility of server deployments, not a security library, to prevent or limit renegotiation when it is inappropriate within a specific environment. Both CVEs are still kept in this VT as a reference to the origin of this flaw.

Detection Method

Checks if the remote service allows to re-do the same SSL/TLS handshake (Renegotiation) over an existing / already established SSL/TLS connection.

Details:

SSL/TLS: Renegotiation DoS Vulnerability (CVE-2011-1473, CVE-2011-5094... OID: 1.3.6.1.4.1.25623.1.0.117761

Version used:

2021-11-15T10:28:20Z

Affected Software/OS

Every SSL/TLS service which does not properly restrict client-initiated renegotiation.

Does anyone know how to fix this?

[Nahuel Figueroa]

Hi Leo!

To fix the vulnerability related to the remote SSL/TLS service, you need to properly restrict client-initiated renegotiation within the SSL and TLS protocols. This can be achieved by implementing the necessary configuration changes in your Wazuh server. Specifically, you should ensure that the server deployments prevent or limit renegotiation when it is inappropriate within your specific environment. By doing so, you can mitigate the risk of a denial of service (DoS) attack. 

[Leo LemogrA]

Hello Nahuel,

First of all thank you for your response. Do you have any idea how to handle this. I have searched a bit but i'm out of options at the moment.

For my case mentioned vulnerability is on wazuh-api and it runs on port 55000.

The exact process is like below

root@w1:~# netstat -ntlpu | grep 55000
tcp        0      0 0.0.0.0:55000           0.0.0.0:*               LISTEN      479452/python3
root@w1:~# ps aux | grep 479452
wazuh     479452  0.0  0.2 694336 43836 ?        Sl   Aug17   0:39 /var/ossec/framework/python/bin/python3 /var/ossec/api/scripts/wazuh-apid.py
root@w1:~#

Many Thanks In Advance

[Nahuel Figueroa]

Hi Leo! The only way to solve it would be to disable client-initiated renegotiations in openssl.
It should be pretty straightforward with something like SSL_set_options(s, SSL_OP_NO_RENEGOTIATION); 

Apparently one can test if renegotiations are still enabled or not with openssl s_client: https://myakamai.force.com/customers/s/article/How-to-test-Client-TLS-Renegotiation?language=en_US

[Nahuel Figueroa]

The API uses TLSv1.2 when defining the SSL context because TLSv1.3 is not fully supported by Python yet. A couple of years ago, the team carried out this issue https://github.com/wazuh/wazuh/issues/9328 where the version was tested, determining that the TLS renegotiation was not supported.