Azure Application Gateway
An Azure service that provides a platform-managed, scalable, and highly available application delivery controller as a service.
1,166 questions
Hello @Rajoli Hari Krishna ,
I understand that you would like to know how to fix CVE-2011-3389, CVE-2016-2183, CVE-2013-0169 vulnerabilities on your Azure Application Gateway WAF v2.
Currently, you are using the predefined SSL policy "AppGwSslPolicy20220101".
CVE-2011-3389:
The SSL protocol, as used in certain configurations in Microsoft Windows and Microsoft Internet Explorer, Mozilla Firefox, Google Chrome, Opera, and other products, encrypts data by using CBC mode with chained initialization vectors, which allows man-in-the-middle attackers to obtain plaintext HTTP headers via a blockwise chosen-boundary attack (BCBA) on an HTTPS session, in conjunction with JavaScript code that uses (1) the HTML5 WebSocket API, (2) the Java URLConnection API, or (3) the Silverlight WebClient API, aka a "BEAST" attack.
CVE-2016-2183:
The DES and Triple DES ciphers, as used in the TLS, SSH, and IPSec protocols and other protocols and products, have a birthday bound of approximately four billion blocks, which makes it easier for remote attackers to obtain cleartext data via a birthday attack against a long-duration encrypted session, as demonstrated by an HTTPS session using Triple DES in CBC mode, aka a "Sweet32" attack.
CVE-2013-0169:
The TLS protocol 1.1 and 1.2 and the DTLS protocol 1.0 and 1.2, as used in OpenSSL, OpenJDK, PolarSSL, and other products, do not properly consider timing side-channel attacks on a MAC check requirement during the processing of malformed CBC padding, which allows remote attackers to conduct distinguishing attacks and plaintext-recovery attacks via statistical analysis of timing data for crafted packets, aka the "Lucky Thirteen" issue.
All the above vulnerabilities come from the CBC cipher suites used by TLS and DTLS protocols in specific versions.
Application Gateway uses OpenSSL 1.0.2 version as the core TLS component in its data path scope.
Lucky 13 vulnerability (CVE-2013-0169) had already been fixed in OpenSSL 1.0.1 version, and hence OpenSSL 1.0.2 doesn't suffer from the Lucky 13 attack. The reason it shows up in the SSL reports is probably due to the fact that it flags any product as "potentially vulnerable" if it uses CBC cipher suites.
My suggestion would be to use the new Predefined policy 20220101S or Customv2 policy to enhance the SSL security and performance posture of the entire gateway.
Refer: https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-ssl-policy-overview
Using the Predefined policy 20220101S would make sure that there are no cipher suites with CBC mode.
Or you could use a Custom TLS policy per your requirement.
Kindly let us know if the above helps or you need further assistance on this issue.
Please "Accept the answer" if the information helped you. This will help us and others in the community as well.