How to fix CVE-2011-3389, CVE-2016-2183, CVE-2013-0169 attacked on Azure Application Gateway?

Rajoli Hari Krishna 396 Reputation points

I have Azure Application way is linked with the Azure App Services.

Below is the table of Azure Security vulnerabilities found by Defender Cloud scan.

How to fix?

If the TLS/SLS Certificate is renewed to latest TLS 1.3 version, will all the below vulnerabilities will be solved in One-go or any other solutions has to be done?

User's image

Azure Application Gateway
Azure Application Gateway
An Azure service that provides a platform-managed, scalable, and highly available application delivery controller as a service.
1,007 questions
{count} votes

Accepted answer
  1. GitaraniSharma-MSFT 49,391 Reputation points Microsoft Employee

    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".


    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.


    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.


    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.


    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.

    1 person found this answer helpful.

0 additional answers

Sort by: Most helpful