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 2nd and 3rd 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 2nd 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 2nd 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!