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

1. Develop and implement a plan for ongoing security and privacy assessments;
2. Perform testing/evaluation;
3. Produce evidence of the execution of the assessment plan and the results of the testing and evaluation;
4. Implement a verifiable flaw remediation process;
5. Correct flaws identified during testing and evaluation.

Control SA-11, which is quite comprehensive, also calls out:

1. STATIC CODE ANALYSIS
2. THREAT MODELING AND VULNERABILITY ANALYSIS
3. INDEPENDENT VERIFICATION OF ASSESSMENT PLANS AND EVIDENCE
4. MANUAL CODE REVIEWS
5. PENETRATION TESTING
6. ATTACK SURFACE REVIEWS
7. VERIFY SCOPE OF TESTING AND EVALUATION
8. DYNAMIC CODE ANALYSIS
9. INTERACTIVE CODE ANALYSIS

In light of Control SA-11, it appears that the 9 recommendations above do adhere to industry best practices. However, federal agencies and their software developers will likely be challenged when attempting to release software in today’s fast-paced, iterative world of software releases. The control methods listed above will likely add considerable delays to federal agencies wanting to release new or updated software that supports their mission objectives. Often, federal standards and guidelines driven by FISMA list many sound objectives, but they frequently fail to adequately describe how they can be achieved overall.

Today, many agencies are attempting to adopt DevOps fundamentals within their software development practices, while at the same time, desiring to move toward DevSecOps by adding security practices into the mix. Therefore, agencies are at a crossroads whereby they must (and should) adhere to the proposed NIST requirements, while at the same time trying to pivot quickly like their commercial counterparts who deploy multiple software releases per day. This represents quite the quandary, but it’s not insurmountable. The key is making use of security automation within their software development efforts.
When looking closer at the list above, notice that items 2, 3, 4, 6, and 7 can, in many cases, be performed before the application is developed. These items are often performed no more than once per application overall. On the other hand, Static Code Analysis (1.), Dynamic Code Analysis (8.), and Interactive Code Analysis (9.) should be performed during the software development process itself for every software version and updated sub-version. And finally, Penetration Testing (5.) is normally performed post-delivery and/or deployment. That being said, the real challenge agencies face is how to automate and accelerate the code analysis process during software development, and not allow security to become a roadblock to release.

Recently, and to help agencies chart this complex landscape, DLT partnered with the Institute for Critical Infrastructure Technology (ICIT) aka “The Cybersecurity Think Tank” and top government and industry leaders for an online discussion: Interactive Security Testing, DevSecOps, and NIST SP 800-53 Rev. 5., which was well attended. Jeff Hsiao, ICIT Contributor & Security Solutions Engineer, Checkmarx, AWS, and Dr. Ron Ross participated in the discussion and demonstrated their highly valuable technical insight pertaining to the topic. All agreed that Interactive Security Testing plays an important role in the code analysis process, however, agencies must also consider static analysis, open source analysis, and developer AppSec awareness and training. At the end of the day, vulnerability detection, remediation, and secure coding practices are the goals for all federal agencies.

Here at Checkmarx, we are experts at DevSecOps and fully deliver on automating code analysis and vulnerability remediation during the software development process. In fact, we scored highest for the DevOps/DevSecOps use case in the 2020 Gartner Critical Capabilities for Application Security Testing Report.  If you would like to learn more about how we can help your agency comply with the pending standards and guidelines from NIST, don’t hesitate to contact us here. Not only will our approach streamline all of your code analysis and vulnerability remediation efforts, we’ll measurably reduce your time to software release.