narayanayv (Community Member) asked a question.
How to fix Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade') (CWE ID 757)(5 flaws)
See the below app scan results.
Description:
A protocol or its implementation supports interaction between multiple actors and allows those actors to negotiate which algorithm should be used as a protection mechanism such as encryption or authentication, but it does not select the strongest algorithm that is available to both parties.
Recommendations:
Do not support SSLv2 or weak SSL/TLS ciphers (i.e. 56-bit key length or less, or other inherent weaknesses).
.png){kind=logo}
To address this issue, you need to reconfigure your web server, proxy or load balancer (whichever is terminating the SSL/TLS connections) to not allow the CBC ciphers. This may not be possible in all situations, for instance, using AWS Elastic Load Balancer, you have limited options for selecting the cipher suites available, and if you pick the restrictive setting that does not include these ciphers, you may end up excluding other ciphers needed for older clients (such as IE 11 on Windows 10).
Using Apache Tomcat, the following configuration extract (applied in the appropriate place in your server.xml) will remove the CBC ciphers from the list of available ciphers:
<!--
// with CBC ciphers enabled (less secure)
ciphers="HIGH:!CAMELLIA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
// CBC ciphers disabled (more secure)
ciphers="HIGH:!CAMELLIA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA:!ECDHE-RSA-AES256-SHA384:!DHE-RSA-AES256-SHA256:!ECDHE-RSA-AES128-SHA256:!DHE-RSA-AES128-SHA256:!ECDHE-RSA-AES256-SHA:!DHE-RSA-AES256-SHA:!ECDHE-RSA-AES128-SHA:!DHE-RSA-AES128-SHA:!ECDHE-ECDSA-AES256-SHA384:!ECDHE-ECDSA-AES128-SHA256:!ECDHE-ECDSA-AES256-SHA:!ECDHE-ECDSA-AES128-SHA"
-->
<SSLHostConfig protocols="+TLSv1.3+TLSv1.2"
honorCipherOrder="true"
ciphers="HIGH:!CAMELLIA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA:!ECDHE-RSA-AES256-SHA384:!DHE-RSA-AES256-SHA256:!ECDHE-RSA-AES128-SHA256:!DHE-RSA-AES128-SHA256:!ECDHE-RSA-AES256-SHA:!DHE-RSA-AES256-SHA:!ECDHE-RSA-AES128-SHA:!DHE-RSA-AES128-SHA:!ECDHE-ECDSA-AES256-SHA384:!ECDHE-ECDSA-AES128-SHA256:!ECDHE-ECDSA-AES256-SHA:!ECDHE-ECDSA-AES128-SHA"
hostName="myhost.com">
Another tool you can also use yourself directly to validate the SSL/TLS ciphers being used (and other things) is testssl.sh (available at https://testssl.sh/) - it will reference this specific issue on the line with:
Obsoleted CBC ciphers (AES, ARIA etc.)
Hopefully that will set you in the right direction,
Robert
Hi @Robert (Community Member) ,
Thank you for helping @narayanayv (Community Member) ! Your advice is spot on.
Thank you,
Boy
How are you recommending teams handle this on AWS ALBs where we can't choose specific ciphers? We use https://ssl-config.mozilla.org/#server=awsalb&version=2019.8.1&config=intermediate&guideline=5.6 to set our minimums which was a confirmed best practice approach on a consultation call. Would that be a "mitigate by network environment" scenario?
My personal recommendation (I'm not with Veracode) is to select the AWS ALB setting that best matches your business need (Possibly in consultation with a Veracode consultant if required), and then if that doesn't meet the recommendations (due to a requirement to support certain ciphers), you would need to mark your flaw as Mitigated using "Accept the risk". Also, raise support tickets with AWS to support TLS 1.3 on the ALB, and better cipher selections as well (like omitting the CBC ciphers, but not the others).
@Robert (Community Member) your recommendation is on-point as usual.
@ig596 (Community Member) we have seen several customers who make use of AWS have CWE 757 flaws reported on their configuration for example for CloudFront which we report primarily on use of CBC. You can find more information on why the industry is moving away from CBC ciphers here: https://security.stackexchange.com/a/210073/3206 . The AWS implementation is also affected as specifically tested by the authors of the Lucky13 vulnerability: https://eprint.iacr.org/2015/1129 .
As mentioned in Amazon AWS documentation the SHA256 cipher is referred to as ECDHE-RSA-AES128-SHA256 ( https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html#secure-connections-openssl-rfc-cipher-names ). The SHA384 cipher appears to be missing from the documentation but is likely grouped under the same name.
In the same documentation you can also see that all current versions of CloudFront Security Policies still support this cipher.
A Security Policy is available in s2n but not yet made available (as of 16th of April 2021) by Amazon ( https://stackoverflow.com/a/62073038/4512 ).Unfortunately, this leaves you with only 2 choices:
1. Use an alternative to Amazon CloudFront for SSL termination that allows you to disable these ciphers.
2. (Temporarily) accept the risk. Only your organizations Security Team can do this. I would recommend discussing this with your security team, if your security team would like they can also schedule a consultation to investigate the risk to your users and your business.
You can find the documentation for AWS ALB TLS configuration here: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#tls-security-policies . Unfortunately, the same recommendation applies.
Thank you,
Boy Baukema
We have noticed that for our company a majority of mitigation requests have been for CWE 757, and it is by far our most prevalent finding category from DAST across all of our sites.
We do realize that SSL is vulnerable to known attacks such as DROWN and POODLE, and as it is no longer supported, should definitely not be used. The following comments are regarding TLS.
We are mainly interested in understanding why Veracode reports these findings as Medium severity. We are aware that other industry-leading tools report them as Informational or Low. Veracode's description does not say "Do not use", rather its more like "Veracode recommends" or "Prefer ___ over ___ ." While we agree that the industry should begin to move away from less secure algorithms in the long run, we believe these should be categorized as best-practice/informational unless they can be tied back to a known exploit being used in the wild.
The issue we are encountering is that is does not appear possible to to accept the risk or reduce severity for specific cipher suites or protocols at a global level using Veracode policies. This is because it can only be altered at the CWE level. You should be able to get more granular in the policies and set the severity for any encryption protocol or cipher, since most organizations will have a differing appetite for risk when considering this topic. We would prefer to deal with these findings at a global level and before they get reported to developers, but it seems like right now the only option is the after-the-fact solution of mitigating each finding individually.
Please consider registering your idea for increased granularity with Veracode Community Ideas at https://community.veracode.com/s/ideas .
Thank you,
Boy