2021 was a year where cyberattacks exploded, and if you did not know about the dangers of the cyber world, you probably do now. The pandemic got everyone into their homes and focused on their IT devices, so there was plenty of time to think about security vulnerabilities. In this blog, we will look at the top 10 software vulnerabilities of 2021 based on CWE, and collect some statistics about them according to data collected from MITRE’s CWE.

The above table ranks the top 10 software vulnerabilities of 2021 based on CWE, from most dangerous to least dangerous. Starting from the left, we have the CWE Id and Name, then we have the Number of Vulnerabilities related to that CWE that occurred in the year, the average CVSS Score of those vulnerabilities, and finally the Programming Language that is related to those vulnerabilities.

We can see that almost all vulnerabilities have an average of High criticality level, except for Cross Site Scripting and Out-of-Bounds Read, that have a Medium severity; however, these occupy the 2^nd and 3^rd place because they have a high popularity. Thus, the ranking of the CWEs is done not only by severity (CVSS score) but also by its popularity (the number of occurrences). For instance, one interesting factor is that Cross Site Scripting (the 2^nd most dangerous CWE of 2021) actually has the most occurrences of vulnerabilities. However, having only Medium severity, it loses its place to Out-of-bounds Write due to the High CVSS score, which makes it much more dangerous.

Moreover, we can see that 30% of the vulnerabilities only happen in C/C++, and another 30% are in Web-based languages, meaning that only websites or web apps are affected. The remaining 40% are Language-Independent—meaning that these are independent of any specific programming language or technology/application type.

C and C++ languages

In C and C++ languages, the vulnerabilities that tend to happen are due to the fact that these programming languages do not perform their memory management and do not provide overflow protection. What this means is that the developer is the one who needs to programmatically implement logic to allocate and manage the application memory, which in other languages is done automatically. This is directly related to the overflow attacks since these languages allow us to directly access memory, and there are no built-in protections against accessing or writing data to any part of the memory.

Web-based languages

In Web-based languages, we see very distinct vulnerabilities. But one similarity in all of them is that the common way for attackers to reach their victims is trying to somehow inject malicious content into the web application, in order to change its behavior and execute unintended actions. For instance, in “Unrestricted Upload of File with Dangerous Type” the intention is to try to upload a file to the application in order for it to be later used and perform unintended/unauthorized actions. Another similarity that we see in XSS and CSRF, is that these attacks are mainly directed at the users of the applications in order to try to exploit them, or use them to indirectly exploit the application.

Language-Independent

In Language-Independent vulnerabilities, these are similar in the sense that they are related to the incorrect or inexistence of input validation checks, and the difference is the component that is exploited. Applications should always check and validate the input that is being submitted to them, in order to prevent maliciously formed data from tampering with the application’s actions, which can lead to either the access to sensitive data, the unauthorized access to a database, or the execution of unwanted commands.

The CWE list

Below, we discuss each one of the vulnerabilities in more detail:

1 – We see Out-of-bounds Write being the number 1 vulnerability in 2021. Typically, attackers exploit this issue by overwriting the memory of an application to try to make the program execute some malicious code.

Let’s look at CVE-2021-24036 as an example. The following is one of its vulnerable functions. The ‘size’ variable enters as input to the function, so this means it can be controlled by the user/attacker. This raises some issues because if its value is too big, when it is added to the heap storage, it can cause an integer overflow leading to an out-of-bounds write.

Despite its danger, this can be easy to mitigate though. In this case, as seen in the following code snippet, the fix is to first validate if the ‘size’ variable is bigger than a certain limit, specified by the ´kMaxIOBufSize´ variable, and in case it is, the function throws an exception about it and simply does not proceed—never reaching out of its memory pointer.

2 – Cross Site Scripting (XSS) was the 2^nd most dangerous vulnerability of 2021. This is a popular Web issue that happens when the application does not sanitize user-controlled input before it is placed as output in some place of the web page. With this, attackers can inject malicious code into a web page and compromise the users that access it.

To check what happens at code level, we will look at CVE-2021-23327. In the following code snippet, you can see that a ‘span’ is being created with an inner ‘text’ that comes from user input. The problem here is that this input is not being sanitized, which means an attacker could inject malicious code, and it would be generated in the web page.

To mitigate this vulnerability, you need to sanitize the input to remove any unwanted characters and strings, in order to prevent harmful codes. The following code snippet shows the fix of the vulnerable code, where you can see that the input passes through the function ‘sanitizeDom’, which replaces characters related to HTML tags, disabling the execution of any malicious code.

3 – In 3rd place, we see Out-of-bounds Read. This vulnerability is similar to Out-of-bounds Write, but the difference here is that instead of the attackers trying to change the execution of the application, they try to read data from other memory locations to get sensitive information.

4 – Next is Improper Input Validation, which happens when the application does not properly validate an input, or data that it receives and considers it as safe to process. This has various consequences, for instance, an attacker can either provide a bad input and crash the program, read or modify arbitrary data, execute malicious code, and more.

Let’s look at CVE-2021-28918 as an example. If you check the following function, there is already a loop iterating through the ‘ip’ which validates each of its bytes. This validation, however, is not proper, because parsing is only being done for decimal values, as seen in ‘parseInt(byte, 10)’. This can allow unauthenticated attackers to bypass the validation and perform other types of attacks like SSRF, Remote File Inclusion, or Local File Inclusion.

In order to mitigate these issues, developers need to understand the type of input that is being dealt with, and provide a proper validation to prevent malformed data from entering and tampering with the application. In this case, the fix consists of parsing not only decimal, but also octal bytes. We can see the fix changes in the following code snippet.

5 – OS Command Injection happens when the application does not properly validate an input that it receives to construct an operating system command. This gives an attacker the ability to modify the intended command and execute arbitrary commands on the operating system through the application.

6 – SQL Injection occurs when the application does not properly validate an input that it receives to construct a SQL query. Not validating input can allow an attacker to modify the query logic and read or modify data from the database as well as execute other operations in it.

7 – Use After Free takes place when the application tries to access a memory location that has been freed, which could lead to various consequences such as: crash the program or allow remote code execution.

8 – Path traversal happens when the application does not properly validate or normalize an input that it uses to construct a pathname to a file or directory. Attackers exploit this vulnerability to cause the pathname to resolve to a location outside the application directory, and access or modify arbitrary content on the machine.

9 – Cross-Site Request Forgery (CSRF) is a vulnerability that happens when a web server does not verify that a request from a client is made from the authentic page. As a result, an attacker can craft a malicious website that sends a request to the application on a visitors’ behalf. For example, a victim that visits the crafted website can send a request to the application and perform unintended actions such as changing a password.

10 – Finally, we have Unrestricted Upload of File with Dangerous Type. This vulnerability occurs when an application does not validate the files that are uploaded to it. A typical exploit is an attacker uploading a file containing malicious code (e.g., a php file) which can then be used, for instance, to execute arbitrary commands through the URL.

Do you usually scan your code to check if it has any vulnerabilities that relate to these CWEs? At Checkmarx, we can help! Our application security testing solutions are designed to quickly alert you of these types of risks. Whether you want to perform source code scanning with Checkmarx SAST or software composition analysis with Checkmarx SCA, we have solutions designed to help secure your code.

Learn more about Checkmarx One Application Security Platform, start a free trial, or request a demo today!

One continually evolving attack vector for nefarious actors is the software supply chain, particularly within open source software package solutions and repositories.  Many of these exploits are not sophisticated, but they are particularly potent due to their ease of execution, potential wide impact across organizations and projects, and difficulty to detect.  These exploits include, but are not limited to:

• RepoJacking – identifying vulnerable legitimate open source repositories (e.g., no 2FA authentication) and using brute-force or phishing tactics to secure access to the project and surreptitiously adding code or dependencies without the original authors or consumers noticing. Additionally, attackers have leveraged the user renaming capability within GitHub to take over a previously legitimate project.
• StarJacking – effectively “cloning” the star rating/download numbers of an upstream project to lend (false) credibility to a nefarious package (e.g., creating a new package on PyPi and sending PyPi metadata indicating it is a fork of a legitimate project, whereas in fact it is not).
• TypoSquatting – creating malicious packages with names derived from other popular reputable packages in the hopes that developers typo the name in their package manifests and pull the malicious package on accident (e.g., attackers naming an NPM package reqest, reuqest, requesst in hopes a developer makes a mistake an imports the attacker’s package rather than the legitimate one)
• Dependency Confusion – cloning the code from a legitimate project and simply adding an otherwise unneeded package dependency on a malicious package. This attack can be implemented by RepoJacking or an iteration on the above Typo Squatting.
• Source Control Action/Automation Manipulation – leveraging CI automation tools (e.g., GitHub actions) to automatically build and run malicious code during push or release actions

Checkmarx team of researchers and engineers proactively pull down and test thousands of packages published weekly within a dedicated “detonation chamber” environment to identify and index nefarious or exploited packages and we report our findings to the relevant package management platform.  In our testing, we have observed many of these exploits occurring “in the wild,” and while there are no clear-cut solutions, there are relatively small actions we as open source community members can take to avoid hackers from exploiting the fruits of their spoils. These actions include (but are not limited to):

• Developers can ensure they only import dependencies (and those dependencies’ dependencies) that are needed.
• Developers can ensure our package manifests are free of typos and are using strict versioning so as to prevent automated upgrading of packages
• Developers can leverage both static and dynamic code scanning and SCA analysis to identify vulnerabilities early and ensure their projects and software are not “calling home” to unknown destinations
• Open source developers can implement 2FA for their open source software project repositories to prevent brute force attacks and takeover of projects
• Package and repository solutions (e.g., NPM, Pypi, GitHub) can enforce project forking tracking and improve project credibility enforcement to prevent or mitigate StarJacking
• Package and repository solutions, open source developers, and security organizations can establish and agree upon a common standard for identifying and flagging malicious software packages and repositories to improve identification, detection, and removal of malicious software packages and code (target resolving the “Package Naming Problem”)

Ultimately, improving security within the open source community is our responsibility as developers, project contributors, and stewards. Checkmarx can help you and your organization protect your applications from software supply chain vulnerabilities through our suite of application scanning tools such as Checkmarx Supply Chain Security offering (SCS), SAST, and KICS, all of which are available as services within the integrated Checkmarx One platform. Often, and given the nature of supply chain attacks, we need to correlate the results from multiple scans to identify vulnerabilities or malicious code within our projects.

With Checkmarx Fusion correlation engine integrated within Checkmarx One, we automate and illustrate the results from these multiple scans to make it simple and easy for developer teams and information security teams to identify and remediate quickly. Lastly, be sure to check out our open source tool, ChainJacking, which can help you identify which of your direct GitHub dependencies are susceptible to RepoJacking attacks.

For more information, watch our recent session at The Linux Foundation Open Source Summit North America entitled The Simple, Yet Lethal, Anatomy of a Software Supply Chain Attack presented by Jossef Harush, Head of Engineering of Supply Chain Security at Checkmarx. Additionally you can download the Understanding Open Source Supply Chain Attacks whitepaper.

We believe, Checkmarx continues to maintain its strong position in the AST market and we’re very proud of that.  More and more organizations are embedding AST throughout their modern application development and cloud-native initiatives, driving rapid AST market growth that trends alongside the proliferation of software amidst worldwide digital transformation.

We believe that the observations made by Gartner support the need for enterprises to not only implement a strong foundation of testing proprietary code and open source libraries via SAST and SCA scans, but to also account for emerging cloud-native technologies including APIs, containers, microservices, and Infrastructure as Code (IaC). Beyond that, evolving risks in the open source supply chain continue to increase as more open source becomes part of today’s codebases.  

To address the growing need of AST solutions that fit well into modern application development, we released the Checkmarx AST Platform late last year. And just last month, we added Checkmarx Supply Chain Security to our portfolio of solutions. Built for the cloud development generation, our AST Platform delivers essential application security testing services from a unified, cloud-based platform. In one scan, it analyzes source code, open source dependencies, supply chain risks, and IaC templates, correlates and verifies the results, and augments them with expert remediation advice. Best of all, these services integrate right into your existing software development tools and processes.

Application security testing solutions that address the broadening risk landscape are no longer a ‘nice to have,’ but rather a ‘must have,’ and today, it’s imperative to leverage innovative solutions that address all code types and the associated risks within modern applications. As a result,  Checkmarx is laser-focused on helping our customers navigate software complexity and expand their test coverage to address the way applications are being developed and deployed, so they can improve the security and quality of their software without slowing down development. With 16+ years of innovation in AST, we remain committed and intensely passionate about delivering powerful solutions to organizations that thrive on the software they develop.

As we celebrate being named a Leader in the 2022 Gartner Magic Quadrant for Application Security Testing, we’d like to thank our incredible customers, partners, and employees who have been, and will continue to be, the cornerstone of our success.

Read the Full Report

Download a complimentary copy of the 2022 Gartner Magic Quadrant for Application Security Testing here.

To learn more about the Checkmarx AST Platform and our suite of Checkmarx AST solutions, visit: www.checkmarx.com

¹Gartner, Magic Quadrant for Application Security Testing, Dale Gardner, Mark Horvath, and Dionisio Zumerle, 18 April 2022.

Gartner Disclaimer:

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

Gartner and Magic Quadrant are registered trademarks of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.