In previous years, similar tactics were often observed as attackers would use encodings to make filenames and types look harmless, for example, masquerading an executable file as a pdf. The recent research describes possible attacks that take a similar path, putting it into practice in source code to deceive human reviewers

This new vulnerability leverages the bidirectional algorithm in Unicode encoding that normally is used to help display left-to-right and right-to-left languages together in the same documents and files (e.g., Hebrew and English). Using this feature, attackers are able to change the order of words and characters in a way that will look harmless to a human reviewer, but can result in different, and even malicious functionality at runtime.

Cambridge researchers describe three techniques that leverage this vulnerability:

• Early Returns: cause a “return” statement that appears to be in a comment to execute and by that, make a function exit and potentially exclude wanted functionality.
• Commenting-Out: causing a similar outcome as the “Early Returns” technique of preventing code from being executed; doing so by commenting out code snippets that will be ignored at runtime, but look normal for a human reviewer.
• Stretched Strings: can be used to alter string comparison operations by causing portions of string literals to visually appear as code.

The authors of the article also mention an adjacent technique that is tracked as a vulnerability as well. The exploit of this vulnerability will include the use of the known homoglyphs characters as a part of functions’ names. This can mislead a reviewer to think a specific function is called, while in fact, another one is with potentially malicious functionality.

Checkmarx SAST to the Rescue

As previously mentioned, this vulnerability has been around for years, but with the recent increase in popularity, we wanted to make sure our customers are covered. “If our customers are in need of an answer to the growing fear of the Trojan Source vulnerability, we can easily assist them,” says Ori Bendet, Head of Product Management at Checkmarx. “Using our easily extensible query language, CxQL, we added a set of dedicated queries to look for those specific characters in the application source code. It will be added to the relevant presets and every customer can be sure that they are covered for any Trojan Source behavior in their application source code. It was really a no-brainer once we had several discussions around this matter with our customers. It also shows how robust and flexible our SAST solution is and how quickly we can add new scanning capabilities,” summarized Ori.

In addition to our SAST’s full coverage of this issue, Checkmarx supply chain dynamic protection can also detect malicious behavior hidden by these techniques in external open-source packages.

Our customers can be confident that they are covered for similar vulnerabilities like Trojan Source.

Make Sure You’re Updated

For organizations who already have Checkmarx SAST, ensure you are running version 9.2 or above to get the latest coverage for the Trojan Source vulnerability. You can learn more and download the latest version [here].

For organization who are not customers yet, but want to learn more about Checkmarx Application Security solutions, feel free to request a demo [here].

Since Minecraft and their YouTube heroes are often more appealing to them than the online chess platform, they broke their promises more than once, and instead of doing something to improve their critical thinking skills playing chess, I found them listening to idle talks about gaming in general.

I felt like I had to find a way to ensure they were using their idle time wisely. But the question remained, “What is the best way to ensure my children only use lichess.org, which is the online chess game I have approved?” Knowing that other parents are likely facing the same challenges, I started researching a few options.

I tried using some browser extensions, but my 10-year-old figured out how to defeat that approach only after few minutes. So I was thinking, “Now what? Should I develop an internet filtering solution myself? Naaaah…” Instead, I began looking for another solution that would not be as easy to evade – something that someone else already created.

With the help of CTparental, which is an open-source project that allows parents to better control where their children go on the internet, I managed to block every website other than lichess.org. My children tried to get past the block I implemented, but after a while, they gave up. My children now play chess much more often and I am delighted about that.

Now as a responsible Application Security Researcher whose career is based upon researching applications to find coding errors, poor coding practices, exploitable vulnerabilities, etc., I wanted to make sure CTparental was safe and its protections are not easy to evade.

After doing some investigation on CTparental, I did find a few vulnerabilities. And I am happy to report that the project’s maintainer was a true professional and responded very quickly to resolve them. Since the vulnerabilities have been resolved, here are the exact details of what I found.  

Vulnerability #1 – Reflected XSS, CWE-79, CVE-2021-37365

In CTParental versions before 4.45.03, the file “bl_categories_help.php” is vulnerable to XSS.

CVSS Score

CVSS: 3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Score: 6.1 (Medium)

Vulnerability Impact

If a child had some level of ingenuity, they could potentially trick their parent into clicking a crafted link that sends the parent authentication cookie to a server under the child’s control and they would able to gain access to the parent admin panel.

Proof of Concept

To reproduce exploiting the vulnerability, enter the following link in the browser:

https://admin.ct.local/bl_categories_help.php?cat=<script>alert(`xss`);</script>

Cause of the Reflected XSS Vulnerability

At line 85 of bl_categires_help.php, the ‘categories’ variable is assigned with the content of the query string param ‘cat’ without sanitization or encoding, enabling an attacker to inject malicious code into the output webpage with echo in line 145.

083: if (isset($_GET['cat']))
084: {
085:     $categorie = $_GET['cat'];
086: }
087: 
.
.
.
137:    <div class="container">
138:             <div class="header clearfix">
139:                 <nav>
140:                     <ul class="nav nav-pills pull-right">
141:                         <li class="active" role="<?php echo "$l_close"; ?>">
142:                             <a href="javascript:window.close();"><?php echo "$l_close"; ?></a></li>
143:                     </ul>
144:                 </nav>
145:                 <h3 class="text-muted"><?php echo $categorie ;?></h3>

Even though I found the vulnerability manually, I scanned the CTparental lines of code using Checkmarx SAST. CxSAST easily detected this vulnerability as shown in the screenshot below:

Suggested Mitigation

In the context of secure coding practices, never trust the user input. Always sanitize or encode user input before further processing. The input should be encoded according to the context, from URL, from HTTP form, etc. A recommended solution, in this case, is to use a dedicated library that prevents XSS or a templating engine that does all the encoding under the hood.

Vulnerability #2 – CSRF, CWE-352, CVE-2021-37366

An attacker can trick an administrator into clicking a malicious link to a crafted web page in the child’s control that would add the attacker to a privileged group and cancel the filtering for herself and other users. By combining it with XSS, it’s possible to perform the same attack without an external webpage but entirely in CTparental admin panel.

CVSS Score

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Score: 8.8 (High)

Vulnerability Impact

Again, if a child had some level of ingenuity, they could trick their parent into clicking a link to a certain web page. The webpage would run on the parent browser, redirect the browser to the CTparental admin panel, and cause a permission change. Combine this vulnerability with the XSS vulnerability, a child could save the effort of creating a web page, and instead, trick their parent into clicking a crafted link that changes their and/or any other user’s permission in the system and, as a result, cancel the desired filtering.

Proof of Concept

The following POC demonstrates the exploitation of both XSS and CSRF vulnerabilities. To reproduce it, enter the following link below into the browser. The link contains an XML HTTP request that sets the second user as privileged.

https://admin.ct.local/bl_categories_help.php?cat=<script>var xhr=new XMLHttpRequest(); xhr.open(“POST”, “https://admin.ct.local/index.php?dgfile=privileged%20group/”, true); xhr.setRequestHeader(“Content-Type”, “application/x-www-form-urlencoded”);xhr.send(“chk-2%3don%26choix%3dchange_user”); </script>

Cause of the CSRF Vulnerability

The code at line 21 in file gctoff.php generates a form that updates the gctoff.conf without validating that the HTTP POST request is from an authenticated admin panel. (i.e., lack of anti-CSRF protection)

21:     echo "<form action='".$_SERVER["PHP_SELF"]."?dgfile=privileged group' method='post'>";
22:     echo "<input type=hidden name='choix' value="gct_Off">";
23:     echo "<input class='btn btn-success' type=submit value=".gettext('Disable privileged group.').">";
24:     echo "</form>";

Suggested Mitigation

Critical actions like adding a user to the privileged group should be protected against CSRF. The application should utilize anti-CSRF protection, such as synchronizer tokens. For more information, check the following link:

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

Vulnerability #3: Code Execution, CWE-94, CVE-2021-37367

Because The file “bl_categories_help.php” is vulnerable to directory traversal, an attacker can create a file with a name that contains bash scripts and run arbitrary OS commands.

CVSS Score

CVSS:AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Score: 7.8 (High)

Vulnerability Impact

Finally, if a child had some level of ingenuity, they could create a file with a name that contains OS commands and craft a link that traverses to this file and runs an OS command with www-data OS user permission.

Proof of Concept

The attacker has a user on the CTparental machine, and they create a file with the following name:

/tmp/ 1;whoami;#.conf

The attacker clicks the following link:

https://admin.ct.local/bl_categories_help.php?cat=../../../../../../..//tmp/1;whoami;%23

We used the whoami command as a proof-of-concept, but it could be any arbitrary OS command, thus giving an attacker control over the server with www-data user privileges.

Cause of the Vulnerability

The code in the bl_categories_help.php file does not validate that the file from the ‘cat’ query string param is one of CTparental’s configuration files, allowing an attacker to pick up a configuration file of their choice. Later, the code concatenates the file name with an exec command without sanitization or escaping.

83: if (isset($_GET['cat']))
84: {
85:     $categorie = $_GET['cat'];
86: }
87: 
88: $bl_categorie_domain_file = $bl_dir.$categorie.".conf";
89: $ipv4_categorie_domain_file = $ipv4_dir.$categorie.".conf";
90: $ipv6_categorie_domain_file = $ipv6_dir.$categorie.".conf";
91:
92: if (file_exists($bl_categorie_domain_file))
93: {
94:     $nb_domains = exec ("wc -w $bl_categorie_domain_file|cut -d' ' -f1");
95: }
96: else
97: {
98:     $nb_domains = $l_error_openfilei." ".$bl_categorie_domain_file;
99: }

CxSAST easily detected this vulnerability as well as shown in the screenshot below:

Suggested Mitigation

Never trust the user input and concatenate user input to an exec command. Always sanitize or encode user input before further processing. The input should be encoded according to the context, from URL, from HTTP form, etc. In this scenario, check that the requested file matches one from the allowed list of the CTparental configuration files.

Timeline of Disclosure

July 12, 2021 – Disclosure to CTparental

July 14, 2021 – release 4.45.03, mitigating the XSS and CSRF

July 22, 2021 – release 4.45.07, mitigating the OS Command execution

August 10, 2021 – CVE-2021-37365, CVE-2021-37366, CVE-2021-37367 assigned

August 19, 2021 – Public disclosure

Conclusion

I’m delighted to have discovered and helped resolve these issues, to not only protect my children, but other children as well. Again, the maintainer of the CTparental project was a pleasure to work with and they should be commended for their due diligence.

I’m also satisfied when I use my skills and experience to increase security for all parents who may use CTparental or other similar tools. In doing so, I had the chance to research, report, and contribute to the safety of children world wide.

This type of research activity is part of the Checkmarx Security Research Team’s ongoing efforts to drive the necessary changes in secure coding practices for those who contribute to open source projects, and in doing so, improve security for everyone overall.

• The vulnerable method in the library needs to be called directly or indirectly from a user’s code.
• An attacker needs a carefully crafted input to reach this method and trigger the vulnerability.

In the second blog, we discussed some of the challenges in developing such a feature, and our unique approach. Mainly:

• Using a query language over the CxSAST engine for the abstraction of queries over source code. This allows a more language-agnostic approach, so that Exploitable Path works for every programming language supported by CxSAST.
• We walked through the various CxSAST queries that are required to build a full call graph of a user’s source code and its libraries’ source code. By crossing it with vulnerability data, we can know if a vulnerability is exploitable or not.

In this last blog in the series, we will cover more advanced topics we faced during the development of Exploitable Path.

Challenge no. 1 – Supporting Multiple Library Versions

The public data on a CVE usually contains affected versions, but how can we use this information to support Exploitable Path across versions? Meaning, if the source code of a library changes between various versions, how can we have the required data for Exploitable Path for each of those versions?
Let’s assume we have a user’s source code that uses a single open-source library. This library contains a vulnerability, and using Mitre, we can figure out the affected versions.
To be able to assess if the vulnerability is exploitable, we need the following for each version on the library:

• A call graph of the library’s code. This can be done automatically using CxSAST.
• Is the current version vulnerable?
  • If it is, the inner method in which the exploitation occurs is required.

Now the question is, “how can we find this inner method for each vulnerable version”? Going over each version manually is not practical, especially since a library can have hundreds of versions.
The first part of the solution is to find the inner method that’s vulnerable. Usually, a vulnerability goes together with a specific method (or methods) that are responsible for a certain logic. Pull requests and commits for the relevant CVE, help our Analysts uncover the relevant method.
Next, we generate a fingerprint of the fix – if a version contains the fix, we can mark it as not vulnerable to this CVE. This is where our powerful static code analysis tool comes into play again, making it easy to re-assess hundreds of library versions for the vulnerability.
Re-assessing the affected versions of a vulnerability is crucial. As it turns out, this data on public websites like Mitre is often not precise. Versions that are marked as vulnerable can be safe and vice versa. It can be the result of human error, or even a slight difference in the version tags between the public registry and the git repository on which the library is developed. By searching for the fingerprint of the fix, we can ensure the quality and accuracy of our vulnerabilities data.
Using the in-depth analysis process, the vulnerable method is marked for every affected version, eventually resulting in a very accurate Exploitable Path scan.

Challenge no. 2 – Data Flow

Just because your code calls a vulnerable method, that doesn’t mean you are automatically at risk.  To assess the risk properly (and avoid false positives), it’s crucial to have both a call graph and a DFG (Data Flow Graph) of a code to assess its exploitability
Let’s start with an example, and assume that a method called parse(content) has a DoS (Denial of Service) vulnerability given the right input. If parse() is only called with a constant value, meaning parse(CONSTANT_VALUE), there is no attack surface for an attacker to exploit it and cause a DoS. On the other hand, if a user of the application controls the input parameter of parse(), it’s a different story. For example, this input can be a comment or other data provided by the user. In such a case, the attacker can easily exploit the vulnerability and craft the required input.
The reality is more complex, as there are various ways data can be transferred in code:

• Input parameters
• Global or class members
• The return value of another method invocation

Also, not all data options are necessary for exploitation. For example, a method parseRequest(HttpRequest request, Config config) can be vulnerable for exploitation using only the  HttpRequest.Content member in the request parameter.
Now we understand the importance, but how do you incorporate DFG in the process of assessing a vulnerability? To be more specific, how can we know that a vulnerability is exploitable from a data flow point of view?
First, we use CxSAST to build a DFG. We start at the vulnerable method and trace back the origins of data point. Eventually we’ll reach one of the following cases:

• A constant value. This is not exploitable, of course.
• An input parameter of a method that is not called by other methods. This is a potential data flow compromise, as in the context of the static code scan, we don’t know how the method is invoked.
• An internal method of the language is called, such as fopen() in Python.
• A method of a different library is called, and its source code is not available.

The last two cases are the most interesting ones, and have two complementary approaches:

• As a rule of thumb, mark those methods as a potential for data flow compromise since the inner implementation is unknown.
• Mark specific methods as definite data flow compromises. For example, reading contents from a database pipe file. The same goes for parsing HTTP packets, pulling a message from a message queue, etc.

These two approaches are the basis for DFG support in assessing a vulnerability for exploitability.

Summary

In this blog we covered two additional advanced topics in Exploitable Path. We started with the problem of supporting various library versions, and how this is solved using the in-depth analysis process. Then, we discussed the integration of DFG in the vulnerability evaluation process, and how to backtrack the flow of data in the code.
With CxSCA, Checkmarx enables your organizations to address open source vulnerabilities earlier in the SDLC and cut down on manual processes by reducing false positives and background noise, so you can deliver secure software faster and at scale. For a free demonstration of CxSCA, please contact us here.

• The vulnerable method in the library needs to be called directly or indirectly from a user’s code.
• An attacker needs a carefully crafted input to reach the method to trigger the vulnerability.

Now that we know the scope of the problem, let’s dive into how uncovering an exploitable path is done.

Prerequisites

1.     A SAST Engine

Every programming language has its set of quirks and features. Some use brackets; some don’t. Some are loosely typed; others are strict. To be able to develop an Exploitable Path, we needed a certain level of abstraction for example, a “common language.” This is particularly hard when high level concepts like “imports” behave differently across languages.
To solve this issue, Checkmarx uses its powerful CxSAST engine. CxSAST breaks down the code of every major language into an Abstract Syntax Tree (AST), which provides much of the needed abstraction. Imports, call graphs, method definitions, and invocations all become a tree.

2.     An AST Query Language

Having an AST, the next step is having a query language capable of even further abstractions. Checkmarx uses CxQuery that can run queries to answer various questions, for example:

• What are all the import statements in a codebase?
• Which methods have no definition but only usage?
• What’s the namespace of every file?

With a tool like CxQuery, you can get results in a unified format regardless of the programming language, such as, C#, Java, Python, etc.

Assumptions

1.     Vulnerable Methods Are Known

Usually, the public data on a CVE provides a CVSS score, affected products, and versions, etc. However, the inner method in which the vulnerability is triggered is usually unknown. To help with this dilemma, the CxSCA Research Team has application security analysts on board who are responsible for analyzing CVEs and finding the method in which the vulnerability occurs. So, for the rest of the post we can assume that for every CVE, we know the method that triggers it.

2.     A SAST Scan Is Limited to One Project

You can think of a project as a folder containing all source code without the third-party package’s code. This makes life easier since there’s a clear distinction between a user’s code and the dependency’s code.
For example, in case there’s a user code that requires a single third-party package, two scans can be made:

• A scan on the user code.
• A scan on the third-party package.

Static Analysis Steps

Now that we’ve covered the prerequisites and assumptions, let’s understand the challenge itself by looking at the following example, written in Python.
Here’s a simple code, importing an open source library and calling a method in it. This method in turn calls a vulnerable method.

The code of OSLib will be:

Here are the steps:

1.     Find Unresolved Methods in User’s Code

The user code is parsed with CxSAST and a query is run to detect all methods that are called and are missing a definition – hence unresolved and belong to a third-party package. In our example, there are two calls:

• foo() – is defined in the user code and hence resolved.
• lib_foo() – is defined in OSLib and hence an unresolved method must be imported.

In our case, there’s a single import to OSLib, so it’s obvious where the method was imported from.
Usually, there will be multiple imports, in which case a signature of the method is collected and searched across imported libraries. Assuming the code is functional and works, there will always be a single match.

2.     Find Exported Methods in Package Code

The code of package OSLib is also parsed with CxSAST, and a query is run to find all exported methods. In languages like C# and Java, an exported method is a public method in a public class that can be used by the user’s code. In Python, all methods are public so the exported methods in our example will be lib_foo() and inner_vuln_method().
This data is essential since it’s used to match unresolved methods in the step above.

3.     Call Graph

A query for a call graph is run on both user’s code and package code.
For the user’s code, the graph is:

For the package code, the result is similar:

4.     Find Exploitable Path

Using all the data collected so far, a full call graph is built:

All methods in the graph are checked for exploitability. In our example, inner_vuln_method() is the exploitable method, and so an Exploitable Path is found.

Further Topics

The example above provided a simple demonstration of how Exploitable Path is analyzed, but in reality, this problem is much harder. Some other research questions we faced, which are not discussed in this blog post, are:

• Detecting Exploitable Path in a dependency of a dependency
• Matching challenges between user’s code and package code
• Integration of DFG (Data Flow Graph)

Summary

By using CxSAST with queries written in CxQuery, we created an abstraction layer to statically detect vulnerabilities that are exploitable. A single algorithm can detect Exploitable Path across multiple programming languages, and unlike other solutions on the market, CxSCA can easily extend support for more languages. Currently, Java and Python are already supported, with many more languages to follow.
With CxSCA, Checkmarx enables your organizations to address open source vulnerabilities earlier in the SDLC and cut down on manual processes by reducing false positives and background noise, so you can deliver secure software faster and at scale. For a free demonstration of CxSCA, please contact us here.

In the next post in this series, we’ll look at some of the challenges we faced as we developed the Exploitable Path feature.

Executive Summary: CVE-2020-13942

What We Found

Apache Unomi allowed remote attackers to send malicious requests with MVEL and OGNL expressions that could contain arbitrary classes, resulting in Remote Code Execution (RCE) with the privileges of the Unomi application. MVEL and OGNL expressions are evaluated by different classes inside different internal packages of the Unomi package, making them two separate vulnerabilities. The severity of these vulnerabilities is heightened since they can be exploited through a public endpoint, which should be kept public by design for the application to function correctly, with no authentication, and no prior knowledge on the attacker’s part.
Both vulnerabilities, designated as CVE-2020-13942, have a CVS Score of 10.0 (Critical) as they lead to complete compromise of the Unomi service’s confidentiality, integrity, and accessibility, in addition to allowing access to the underlying OS.

Details

Previous RCE Found in Unomi

Unomi offers a restricted API that allows retrieving and manipulating data, in addition to a public endpoint where applications can upload and retrieve user data. Unomi allows complex conditions in the requests to its endpoints.
Unomi conditions rely on expression languages (EL), such as OGNL or MVEL, to allow users to craft complex and granular queries. The EL-based conditions are evaluated before accessing data in the storage.
In the versions prior to 1.5.1, these expression languages were not restricted at all—leaving Unomi vulnerable to RCE via Expression Language Injection. An attacker was able to execute arbitrary code, and OS commands on the Unomi server by sending a single request. This vulnerability was classified as CVE-2020-11975 and was fixed. However, due to further investigation by the Checkmarx Security Research Team, we discovered that the fix is not sufficient and can be trivially bypassed.

Patch Not Sufficient – New Vulnerabilities Discovered

The patch for CVE-2020-11975 introduced SecureFilteringClassLoader, which checks the classes used in the expressions against an allowlist and a blocklist. The SecureFilteringClassLoader relies on the assumption that every class in both MVEL and OGNL expressions is loaded using the loadClass() method of the ClassLoader class. The SecureFilteringClassLoader overrides the ClassLoader loadClass method and introduces the allowlist and blocklist checks. This assumption happened to be incorrect. There are multiple ways of loading a class other than calling the loadClass() method, which leads to the security control bypass and leaves Unomi open to RCE.
First, the MVEL expressions in some cases use already instantiated classes, like Runtime or System, without calling loadClass(). This results in the latest version of Unomi (1.5.1) allowing the evaluation of MVEL expressions inside the condition, which contains arbitrary classes.
The following HTTP request has a condition with a parameter containing a MVEL expression (script::Runtime r = Runtime.getRuntime(); r.exec(“touch /tmp/POC”);). Unomi parses the value and executes the code after script:: as an MVEL expression. The expression in the example below creates a Runtime object and runs a “touch” OS command, which creates an empty file in /tmp directory.

Vulnerability #1

Second, there is a way to load classes inside OGNL expressions without triggering the loadClass() call. The following HTTP request gets Runtime and executes an OS command using Java reflections API.

Vulnerability #2

The payload may look scary but it’s simply Runtime r = Runtime.getRuntime(); r.exec(“touch /tmp/POC”); written using reflection API and wrapped into OGNL syntax.
Both presented approaches successfully bypass the security control introduced in version 1.5.1, making it vulnerable to RCE in two different locations.

Possible Attack Scenarios

Unomi can be integrated with various data storage and data analytics systems that usually reside in the internal network. The vulnerability is triggered through a public endpoint and allows an attacker to run OS commands on the vulnerable server. The vulnerable public endpoint makes Unomi an ideal entry point to corporate networks. Its tight integration with other services also makes it a steppingstone for further lateral movement within an internal network.

Summary of Disclosure and Events

After discovering and validating the vulnerabilities, we notified Apache of our findings and worked with them throughout the remediation process until they informed us everything was appropriately patched.
To learn more about these types of vulnerabilities, OWASP and CWE have descriptions, examples, consequences, and related controls, as shown in the following links:

• https://owasp.org/www-community/vulnerabilities/Expression_Language_Injection
• https://cwe.mitre.org/data/definitions/917.html

Additionally, read the code, analyze the fix, and learn how to mitigate similar issues via our interactive CxCodebashing lesson here.

Timeline of Disclosure

June 24, 2020 – Vulnerability disclosed to Apache Unomi developers
August 20, 2020 – Code with the mix merged to master branch
November 13, 2020 – version 1.5.2 containing the fixed code is released
November 17, 2020 – public disclosure

Recommendations

The evaluation of user-defined expression language statements is dangerous and hard to constrain. Struts 2 is an excellent example of how hard it is to restrict dynamic OGNL expressions and avoid RCE. These attempts to impose usage restrictions from within/on the EL, rather than restricting tainted EL usage for general purposes, is an iterative approach, rather than a definitive one. Instead, a more reliable means to prevent RCE is to remove the support of arbitrary EL expressions entirely, creating a set of static expressions that rely on dynamic parameters instead.
Static Application Security Testing solutions, like CxSAST, can detect OGNL injections in source code and prevent this sort of vulnerability from making its way into production. Meanwhile, software composition analysis (SCA) solutions, such as CxSCA, will have the necessary data about the vulnerable package and will update CxSCA users as soon as the vulnerability is publicly disclosed. To learn how to mitigate similar issues, visit our CxCodebashing lesson here.

Final Words/Summary

This type of research is part of the Checkmarx Security Research Team’s ongoing efforts to drive the necessary changes in software security practices among all organizations. Checkmarx is committed to analyzing open source software to help development teams build and deploy more-secure applications. Our database of open source libraries and vulnerabilities is cultivated by the Checkmarx Security Research Team, empowering CxSCA customers with risk details, remediation guidance, and exclusive vulnerabilities that go beyond the NVD.
To learn more about this type of RCE vulnerabilities, read our blog about Struts 2. For more information or to speak to a Checkmarx expert about how to detect, prioritize, and remediate open source risks in your code, contact us.