In the world of attacker vs. defender, security teams often feel they’re behind the eight ball, operating in a state of perpetual reactionary-mode. Although they tirelessly try to get ahead of attackers and their campaigns, defenders’ efforts often fall short. This is not due to a failure on their part. Instead, attackers’ tactics, techniques, and procedures (TTPs) are in constant flux and with relentless inventiveness. And what we witnessed in 2022 has motivated Checkmarx to be the industry’s first software security vendor to deliver supply chain threat intelligence to those who rely on the open source software ecosystem.

2022 was another year of unrelenting attacks against organizations that thrive on the very software they develop, but it was much different than anything our researchers ever saw before. Last year, we observed an increasingly advanced level of ingenuity as attackers took complete advantage of a system built upon trust—the open source software supply chain. And this time, having caught them red-handed on multiple occasions, we now know what it will take to stay one step ahead of their attacks.

Last March, Checkmarx released its Supply Chain Security solution as our research teams witnessed the evolution of attackers’ TTPs firsthand. Currently, the solution is being widely adopted by organizations who depend on the software supply chain, since open source packages play an important role as part of their code base. Understanding that organizations are going to continue using open source packages in their applications for the foreseeable future, Checkmarx just announced another arrow in the quiver of enterprise-class, open source supply chain defenses—Checkmarx Supply Chain Threat Intelligence.

How our threat intelligence is different

Traditionally, real-time threat intelligence has mostly been about identifying nefarious source IP addresses that were engaging in attacks. Many of these IP addresses were compromised devices that became part of a botnet, being centrally controlled from somewhere in the world, and used to strike organizations with denial of service, credential stuffing, password guessing, site scraping, spamming, and probing attacks. Consumers of this type of threat intelligence would block traffic coming from these nefarious addresses somewhere in the cloud or at their perimeters.

However, Checkmarx Supply Chain Threat Intelligence is much different than what has been traditionally available. This threat intel solely focuses on the software supply chain the world depends on. Also, the solution Checkmarx is delivering is not based upon vulnerable packages that are commonly tracked by cve.mitre.org. Instead, this intel is all about tracking purpose-built, malicious packages that often contain ransomware, cryptomining code, remote code execution, and other common types of malware. Malicious packages are designed to infect organizations worldwide and are much different than packages that contain unintentional coding errors that end up leading to vulnerabilities.

What our threat intelligence delivers

Based exclusively on proprietary research by Checkmarx Labs, our Supply Chain Threat Intelligence is for organizations that want:

• • Identification of malicious packages by attack type such as dependency confusion, typosquatting, chainjacking, and more

• • Analysis of contributor reputation through identification of anomalous activity within open source packages

• • Intelligence on the malicious behavior of packages, including static and dynamic analysis to understand how the code runs

• • Historical Archives in the form of a data lake that allows the ongoing analysis of packages long after they have been deleted from package managers

How to consume our threat intelligence

Checkmarx Supply Chain Threat Intelligence is delivered via an application programming interface (API). Users obtain a unique token from Checkmarx, send in a package name and version, and receive threat intelligence on the package. The intel is simple to integrate into many dashboards and to automate into your software development environments.

Why you need our threat intelligence

The best part of Checkmarx Supply Chain Threat Intelligence is that it is designed for you, the developer and AppSec professional. Subscribing to the service, and using it regularly, will help you:

• • Avoid malicious packages before they become part of your code base – and, critically,  before code containing them is ever deployed

• • Understand the evolution of attackers’ TTPs against the supply chain

• • Collect intelligence on large numbers of packages at once using bulk queries

• • Increase security awareness with real-time updates and alerts on new threats

• • Make better open source package selections using our valuable insights and context

Next steps

To learn more about Checkmarx Supply Chain Threat Intelligence, you can check out the interactive demo below and download our Solution Brief to share with others.

If you’d like a live demo of the solution, don’t hesitate to contact us here.

Or you can download the following white papers to learn more about supply chain attacks and the Checkmarx approach to supply chain security:

• • Introduction to Open Source Supply Chain Attacks

• • Software Supply Chain Security: Why You Should Care

• • Introduction to Checkmarx Supply Chain Security

• • SBOMs: You Can’t Secure What You Don’t Know

We are proud to announce that Checkmarx SCA now allows for vulnerability analysis in Ruby code dependencies. For us, supporting another programming language allows the coverage of a wider range of vulnerabilities. This also provides our customers the required security knowledge of their code and its dependencies since you can now detect vulnerabilities in code dependencies that were undetected before. With this announcement, we would like to give a small introduction to the Ruby language and explain some of the most dangerous vulnerabilities we have observed when using this language.

Ruby is…

A dynamic, open-source programming language with a focus on simplicity and productivity. It was developed by Yukihiro Matsumoto and released in 1995. Its syntax allows for a natural understanding of the code and it’s easy to write. Ruby is ranked 15 in PYPL PopularitY of Programming Language, which is an analysis for how often language tutorials are searched on Google. This is an indicator that Ruby is in the top 20 of programming languages that people want to learn.

Ruby is based on other programming languages like Perl, Eiffel, and Ada. It is a pure object-oriented language, and in Ruby, everything appears as an object. It is used in typical scripting language applications and to connect different software components—being also considered a glue language.

The main uses of Ruby are web development, higher-level server management projects, and data science.

Ruby Gems

Like many other programming languages, Ruby allows for third-party libraries or packages to be invoked by a program. In Ruby, these packages are called Gems and they can be obtained through Ruby’s default package manager, RubyGems.

A Gem is a collection of code, libraries, dependencies, and metadata which is compressed into a “.gem” file to be used as a dependency in your code. Ruby gems are the primary target of Checkmarx SCA in finding code dependencies vulnerabilities, so we’ve had to find a generalized way to search the source code of each Gem. We looked at the structure of Ruby gems and quickly found that a gem package file is simply a tarball file which consists of three “.gz” files.

— shiny.gem
     |

      — checksum.yaml.gz
     |

      — metadata.gz
     |
      — data.tar.gz

The “checksum.yaml.gz” file contains the gem hashes that ensure the integrity of the package.

The “metadata.gz” file is the result of the “gemspec” file. A “gemspec” is where all the metadata information for the gem is defined. You can find the name of the package, version, dependencies, and a list of all the source code files there. It basically tells you what’s in the gem, who made it, and the version of the gem. It’s also the interface to the RubyGems package manager.

The “data.tar.gz” file contains the actual gem code. This is the file we’re looking for in order to search what versions are vulnerable to a specific CVE.

Each Gem used in our customers code will be scanned by our SCA to provide you with the most accurate security knowledge of your code.

Ruby on Rails

We can’t talk about Ruby without mentioning its most famous web framework, Ruby on Rails.

Rails is a web development framework, written in Ruby. It helps developers build websites and applications, because it abstracts and simplifies common repetitive tasks. Since Ruby is one of the simplest languages to understand, while also being powerful enough for experienced programmers, it makes sense that Ruby on Rails would be one of the most popular web development frameworks.

Ruby on Rails works seamlessly alongside HTML, JavaScript, and CSS. It follows the MVC architecture and has design philosophy of “Don’t Repeat Yourself” (DRY), which emphasizes not writing repetitive code. It also follows the “Convention Over Configuration” (CoC) philosophy, meaning you should focus on whatever makes the programmer’s life easier. Being this popular doesn’t come without a cost. There are a lot of vulnerabilities associated with Ruby on Rails. Here are a few examples of the CVEs with the highest CVSS score for Ruby on Rails covered by Checkmarx SCA.

CVE-2008-4094

This CVE is a multiple SQL injection vulnerability in Ruby on Rails in versions prior to 2.1.1. Attackers are able to execute arbitrary SQL commands via “:limit” and “:offset” parameters. The affected Ruby on Rails components are ActiveRecord, ActiveSupport, ActiveResource, ActionPack, and ActionMailer. This CVE has a CVSS version 2.0 score of 7.5.

CVE-2013-0277

This CVE is a DoS vulnerability in the Active Record component of Ruby on Rails. Active Record is the M in MVC – the model – which is the layer of the system responsible for representing business data and logic. It affects versions prior to 2.3.17 and 3.x prior to 3.1.0 and allows remote attackers to cause a denial of service or execute arbitrary code via crafted serialized attributes that cause the “+serialize+” helper to deserialize arbitrary YAML. This CVE has a CVSS version 2.0 score of 10.

CVE-2019-5420

In development mode Rails versions 5.2.0 prior to 5.2.2.1, there is a RCE vulnerability that allows an attacker to guess the automatically generated development mode secret token. This secret token can be used in combination with other Rails internals to escalate up to a remote code execution exploit. This CVE has a CVSS score of 9.8.

What we’ve seen so far with Ruby

Since we’ve supported Ruby code dependencies scans with SCA, we’ve seen a few CVEs that have been detected the most by our customers. Here are a few examples of the most dangerous Ruby vulnerabilities detected when using Checkmarx SCA.

CVE-2020-36599

The OmniAuth Ruby gem is a library that standardizes multi-provider authentication for web applications. It contains a vulnerability in versions prior to 1.9.2 and 2.0.0.pre.rc1, where the environment variable “message_key” is not properly escaped, which could lead to malicious content being replaced by the intended content. This CVE has a CVSS score of 9.8.

CVE-2022-25765

This CVE affects the PDFKit Ruby gem. The package is used to create PDF files using HTML and CSS. It uses the well-known “wkhtmltopdf” library on the back end which renders HTML using Webkit. The vulnerability has a CVSS score of 9.8 and is a command injection vulnerability in versions through 0.8.6, where a URL parameter is not properly sanitized. If the URL contains any user input, it could lead to commands being executed by the user.

CVE-2022-39281

This CVE affects the Fat Free CRM package. This package is a well-known open-source Ruby on Rails-based customer relationship management platform. In versions prior to 0.20.1, an authenticated user can perform a remote Denial of Service attack against Fat Free CRM via bucket access. This CVE has a CVSS score of 6.5.

Final remarks

As we’ve seen in the blog, with Checkmarx SCA supporting the Ruby language, we can assure you that your Ruby code will not be left behind when it comes to security. There are a lot of known Ruby vulnerabilities and our SCA team will keep highlighting them to provide you the best vulnerability coverage of your Ruby code. You can learn more about Checkmarx SCA here.

The package affected by the CVE is Apache Commons Text, an open-source Apache library that is “focused on algorithms that are applied to strings” (string substitution, lookups, matching and other algorithms). The discovered vulnerability exists throughout versions 1.5 to 1.9 and may lead to arbitrary code execution when untrusted data is processed and interpolated.

Executive Summary

A new vulnerability, CVE-2022-42889, commonly referred to ‘text4shell’, is a critical severity vulnerability affecting the popular Apache Commons Text. It is reminiscent, at its technical core, of the now infamous Log4Shell vulnerability – by processing values in a way that would allow invoking internal functionalities, which could, in turn, result in execution of arbitrary malicious code.

Fortunately, not all users of this library would be affected by this vulnerability – unlike Log4J in the Log4Shell vulnerability, which was vulnerable even in its most basic use-cases. Apache Commons Text must be used in a certain way to expose the attack surface and make the vulnerability exploitable.

Regardless, this vulnerability is severe, and users should make the effort to update this library to its latest version as soon as possible.

Technical details

In the Apache Commons Text, there is a feature that expands the text with lookups. Functions like replacing a string will call the vulnerable lookup function. This functionality is an implementation of a very basic expression language, which allows invoking several methods from within the interpolated string.

The lookup has number of fields which it tries to identify as shown below:

The fields that introduce security threats are the dns, url, and script − the worst one being script which opens the door for Arbitrary Code Execution. Using the ‘replace’ function, we can invoke a lookup with the expression language string ‘${<lookup field>:<lookup string>}’

The following PoC uses the replace function with the payload containing the symbols “${}” for the lookup to execute. The second part of the code demonstrates invoking the lookup directly.

Log4Shell vs. CVE-2022-42889

When first seeing this vulnerability, we immediately associate it with Log4shell, hence the similar name, Text4shell (despite having nothing to do with the number 4). String interpolation of basic EL invoking code, with similar file names in (e.g. StringSubstitutor.java), invoking potentially dangerous methods are all very much reminiscent of Log4Shell. Despite the many resemblances to the infamous CVE-2021-44228, however, we must point out that the vulnerable package and functions is not as widely used in the wild. Another major difference is in implementation. While the most fundamental use-cases of Log4j were vulnerable in Log4Shell, this vulnerability requires an implementation pattern that may not affect all of its users.

Regardless, this vulnerability is significant, and the potential impact remains the same as unauthenticated RCE (remote code execution) is the most impactful attack one can have.

Remediation

The fix applied by the Apache team was the removal of the dns, script, and url lookups from the default interpolator behavior. In the StringLookupFactory.createDefaultStringLookups() method the DefaultStringLookup.DNS, DefaultStringLookup.URL and DefaultStringLookup.SCRIPT are now not added by default. In the previous versions, all the DefaultStringLookup instances were added by default.

The recommended action is to upgrade the package to the fixed version (1.10.0).

In case an upgrade is not possible, the StringSubstitutor can be initialized with safe StringLookup configurations.

If the dangerous lookups are necessary in the application, all user input should be sanitized before being interpolated. A possible solution can be the use of a whitelist in the input validation phase.

Conclusion

In conclusion, the vulnerability may cause some panic in the wake of Log4shell. Despite it being less used in the wild, and despite requiring specific implementation for exploitation to be viable, it is still an important vulnerability since it is easy to exploit where vulnerable, it is widely used, and has significant impact. Checking if your code is vulnerable is highly important.

Checkmarx SCA customers can scan their code for similar types of vulnerabilities and get the latest remediation guidance.

Timeline

• 2022-03-09: Issue reported to security@commons.apache.org
• 2022-03-25: Apache Commons security team acknowledged receiving the report
• 2022-05-27: GHSL requested a status update
• 2022-05-27: Apache Commons security team notifies they are working on disabling the script interpolation by default
• 2022-06-29: Apache Commons security team states that “Commons Text” will be updated, in order to make the programmer’s intention completely explicit on using a “dangerous” feature
• 2022-08-11: GHSL requested a status update
• 2022-10-12: Apache Commons Text releases version 1.10.0 where script interpolation is disabled by default

References

• https://nvd.nist.gov/vuln/detail/CVE-2022-42889
• https://securitylab.github.com/advisories/GHSL-2022-018_Apache_Commons_Text/
• https://lists.apache.org/thread/n2bd4vdsgkqh2tm14l1wyc3jyol7s1om

Untracked Vulnerabilities

There is a common assumption that all open source vulnerabilities hold a CVE. Still, others believe that the National Vulnerability Database (NVD) has the final word when deciding what is a vulnerability and what is not. However, can a vulnerability exist that isn’t tracked by a CVE, or is not in the NVD?

NVD is the top reference, that’s irrefutable. It’s why those of us on the Checkmarx SCA research team use NVD as our main source of vulnerability information. However, we’ve also explained previously how NVD’s data is often not enough. Moreover, NVD relies on various AppSec authorities and maintainers to maintain a comprehensive database of vulnerabilities.

In that sense, we must pursue other sources to increase the magnitude of the vulnerability coverage within our SCA solution. To every vulnerability that isn’t present in the NVD, and hence, doesn’t have a CVE, we call them an “Untracked Vulnerability.”

Our Challenges

Tracked or not, an exploitable vulnerability in your code can become a gateway to your application being compromised. And like the dark side of the moon that we can’t see, we simply know it’s there. These two assumptions are where the real risk resides.

However, researching untracked vulnerabilities is a process that come with some challenges that we need to tackle. The most prominent are:

• Untracked vulnerabilities usually have less information available than ones that are tracked. Which means it requires more difficult research to cover the vulnerability.
• The fact that they aren’t validated by a trusted authority requires more work on our part to measure and validate the risk as well. Sometimes, we even need POCs (Proof of Concept) to prove that a vulnerability exists.

Both challenges are always present, yet a third challenge arises from time to time. It is common for Untracked Vulnerabilities to be unfixed and they may affect the latest versions of popular packages. So sometimes we must exhume vulnerabilities we’ve covered before and confirm if the research and information about them is still accurate.

Recently, we had to validate two of these vulnerabilities in the NPM package “debug.” The “debug” package is one of the most popular packages on NPM with hundreds of millions of weekly downloads—one more reason to perform our research as thoroughly as possible.

Memory Leak in “debug”

Confirming the vulnerability

One of the vulnerabilities was a Memory Leak, and the starting point was this issue. It wasn’t mentioned anywhere else, and there was no CVE nor any info about this on NVD. So, we knew we would have to research this issue as an Untracked Vulnerability.

Where could the issue lead us?

When the information about an issue is limited, we must analyze everything from the beginning, and every crumb of information can add up to something. There are references to other issues, commits, etc., in addition to comments that might hold essential information. We must also look for leads on the old analysis that could indicate a misunderstanding or anything that went unnoticed.

A vigilant journey through the comments showed us how the vulnerability went from being exposed to fixed, and along the way, we gathered enough information to trust the validity of the vulnerability and its fix. There was proof in the comments (including answers from the maintainer) and a fix commit. Still, we analyzed the code thoroughly and ran our tools to confirm this.

But at this point, it wouldn’t suffice to completely trust the issue was fixed. We would have to reproduce the vulnerability and finally extinguish any doubt.

Proof of Concept (POC)

We know that a memory leak implies that memory that is no longer needed isn’t being freed correctly. In the cybersecurity jargon, it means that the memory will keep on accumulating until something crashes, thus, if intentional, leading to a Denial of Service (DoS).

That was precisely the situation here, and all it required was to instantiate “debug” in a loop.

That’s what we did using a public POC. One look at the CPU usage and the picture was clear. We could see the memory growing, bit by bit, and it was even clearer after running more instances of the POC. But we needed to make it better to showcase, so we made our own POC. Everything went the same, except that we made it easier to visualize the vulnerability and its results.

The only thing that was left was to confirm our previous conclusions regarding the versions. So, we ran the POC for the latest vulnerable version and some of the older ones, only to confirm what we already knew. At last, running it for the first fixed versions and the latest one showed that the vulnerability was indeed fixed.

ReDoS in “debug”

Confirming the vulnerability

The other vulnerability was a Regular Expression Denial of Service, aka, ReDoS. We found it through this issue.

We saw that the issue was open and there was no fix yet. And from the comments we confirmed it was indeed a vulnerability. Hum… an unfixed vulnerability? The person reporting the issue had neatly described the problem and affected code, and the maintainer agreed that it should be handled. However, it was planned to be fixed in a later version.

Nonetheless, we had to reproduce it and create proof that the vulnerability exists.

Proof of Concept (POC)

To begin with, the POC was also easy because we already had info about the affected components. We needed to call the `enable()` function and give it the regex. However, there was a challenge.

To summarize, a ReDoS happens when an application accepts regular expressions as input, but it does not validate catastrophic exponential-time regular expressions. Thus, we had to craft a specific malicious regex that would break it and cause the Denial of Service in the application. So that is what we did.

We used the regex `(a+)+`, which searches for the letter “a” and its repetition, and checks if the entire expression is repeating. If we then supplied something like `aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaX` as input, we could see the application hanging and running for an undetermined amount of time. This is because each “a” causes the regex function to check for the repetition of an additional expression, thus doubling the amount of processing time, and then, by having something other than an “a” in the end, it causes catastrophic backtracking. Mission accomplished!

Finally, we ran the POC for some earlier versions and for the latest released version, to confirm that the vulnerability was indeed not fixed – all the versions were vulnerable and could easily be exploited.

Last words

As we’ve shown in this blog, Untracked Vulnerabilities are vulnerabilities nevertheless, and they must never be underestimated. We will keep working towards increasing our coverage of these Untracked Vulnerabilities since they are a surplus to our customers, and are as critical to security, if not sometimes more critical, than the tracked vulnerabilities.

The SCA research team continues to cover both tracked and untracked vulnerabilities with the same due care. You can learn more about Checkmarx SCA here.

There is no doubt that NVD (National Vulnerability Database) is the go-to reference when it comes to the universe of vulnerabilities. For one thing, it is the most comprehensive database. By the time of writing this, it contains more than 185 thousand vulnerabilities. Since NVD is the best solution to keep track of security issues, we at Checkmarx adopted CVE (Common Vulnerabilities and Exposures) as the main identifier for our vulnerabilities.

Apart from just tracking and numbering vulnerabilities, NVD is a solid ground of information—it collects additional useful data for interested parties. For us, NVD is a starting point for much deeper research.

Let’s draw the curtains

So, every day, the Checkmarx SCA (Software Composition Analysis) Team receives all the new vulnerabilities (CVEs) that come from the NVD.

From those, we filter what’s relevant for us:

1. Since SCA operates in the open source market, we put aside all the CVEs that are not related to open source packages.
2. Then we only get the CVEs for the languages and package managers that our clients need—the ones we offer support for.

And since at Checkmarx we value quality, we don’t just limit ourselves to getting data from the NVD.

In Checkmarx SCA, that’s where the core of our work comes in. The analysts got the petroleum, and now they need to turn it into fuel. Hence, each CVE must undergo a meticulous research process before that data is ready to be used in our SCA.

Information, more information

Let’s take CVE-2018-16469 as an example.

NVD’s information is our first chance to begin building some initial understanding.

• What is the vulnerability? Prototype Pollution that might lead to a Denial of Service attack?
• Which product is affected? NPM package “merge”?
• How severe is it? It can have a High Impact in the Availability (CVSS score of 7.5)?
• Etc.

Then we get hands-on with as much information as possible—information is our friend. We start by looking for leads, checking external references, the repository, related issues, official disclosures (like https://hackerone.com/reports/381194), etc.

At this point, the data we’ve gotten so far is fairly trustworthy, but now we need to:

• Start validating everything and developing a more solid understanding.
• If we confirm that NVD’s data (Description, CWE, CVSS, etc.) is correct and suitable, that’s what we will want to show our customers. If possible, it’s good to be aligned with the number-one reference.
• However, if something is not correct, we will investigate further and fix the information accordingly. If we know of a more appropriate CWE, we will change it. For instance, here we replaced the Weakness Enumeration CWE-20 with CWE-1321, which back then was still in neglect, but it’s more proper for Prototype Pollution.

Show me where

We work with packages for package managers, but NVD often mentions the product and not a specific package. So, it’s fundamental that we discover which packages are affected. Here, it’s the NPM package “merge”.

Sometimes packages are affected by using vulnerable code from another package, like wrappers. We know that often the vulnerability is in the actual product, but finding the exact vulnerable source is not straightforward. For example, usually in Maven, the “core” packages (which contain most of the source code) are vulnerable. But we don’t want to limit to the “core” since it’s more general. Instead, we aspire to identify the specific artifact that contains the vulnerable code.

Another focal point here is the versions of the product. NVD’s description mentions the affected versions, but often not all versions are mentioned, or sometimes the mentioned versions are not correct—like this one that described versions prior to 6.4.9 as affected. But we found version 6.4.9 was vulnerable as well. For this, we lean on different methodologies and tools. Release Notes can be valuable, Commits are an immense help. But also, Disclosures, Issues, Pull Requests, etc. are valuable as well. Above all, we aim to confirm the exact fixed and vulnerable versions, which, among other methods, can be achieved by comparing the code between different versions or checking the source code.

Back to the initial example, we can confirm that the fix was released in version 1.2.1, with the line ` if (key === ‘__proto__’) continue; `.

We then mark each version accordingly and fix the description if needed so that Checkmarx SCA scan will respond precisely to the customer’s products.

Those references that we find along the way might have valuable information to show our customers, especially those curious to know and read more. In that sense, we also supply the links for all the relevant references.

Yet, we need to make our results even more fulfilling. We don’t just want to show where the vulnerability exists through references. That’s why we have the Exploitable Path feature. Our analysts work exhaustively to make sure that they don’t miss any possible location for the vulnerability. We try hard to identify the vulnerable files, classes, and functions where the vulnerability lies.

A few last words

We went through a deep research process to make the CVE data as accurate as possible, but before it becomes available in Checkmarx SCA, we must make sure that the end product is correct. In that sense, each CVE moves in line to be reviewed by our experienced team. If everything aligns with our internal practices, then the CVE can be approved and will finally be ready to enter our SCA scans.

By going through this process, and meticulously following these steps for each CVE, we guarantee that data that shows in our SCA gets curated in the best interests of quality. It’s also why our number of False Positives or Negatives is so low.

…

Checkmarx SCA not only excels in identifying vulnerabilities in packages that you directly scan but also in all the vulnerable dependencies that you might have in your code. If you use open source packages (which you likely do), your code might be exposed and insecure. If you have never tried Checkmarx SCA before, request your demo here. We will be glad to help.

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

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

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

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

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

Read the Full Report

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

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

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

Gartner Disclaimer:

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

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

The Evolution of TTP

In the very beginning of cyberattacks, attackers would spend time creating self-propagating viruses and worms to exploit vulnerable operating systems and desktop applications. For example, the “I Love You” virus, which dates back to the year 2000, infected over ten million computers worldwide. Names like Code Red, SQL Slammer, Sobig, MyDoom, Netsky, Stuxnet, Zues, and so on, made headlines all over the globe. As a result, antivirus companies proliferated, holes were plugged in operating systems, devices and perimeters were hardened, bug bounties were initiated, and many of these TTPs were defeated.

During much of this same period, a new genre of TTPs emerged in concert with these highly successful malware examples, and phishing became the new name – of an old game. Since perimeter and workstation defenses were somewhat difficult to overcome from the outside-looking-in, attackers knew that if they could fool someone into clicking on a link in an email, back doors could be opened, and perimeter defenses may well be defeated.

Therefore, a whole new generation of malware surfaced in the form of ransomware and botnets. For example, names like Locky, Tiny Banker Trojan, Mirai, WannaCry, Petya, and many more were the next malware variants to gain notoriety. Email phishing defenses, spam detection systems, employee email phishing training, etc. proliferated and helped defeat some of these attacks.

As a result, attackers likely began to conclude, “If we can infect a software supply chain, our malware proliferation and victim count could grow exponentially.” And in December of 2020 they did just that. The SolarWinds supply chain attack took place, leading to both government and enterprise data breaches that made headlines worldwide. However, the SolarWinds’ attack was leveraged against a commercial software supply chain and was not necessarily focused on what is called the open source supply chain.

Why Supply Chain – Why Now?

Today’s attackers realize that infecting the supply chain of open source libraries, packages, components, modules, etc., in the context of open source repositories, a whole new Pandora’s box can be opened. And as we all know, once you open that box, it’s nearly impossible to close. In fact, Checkmarx leadership saw this coming. Back in December of 2019, Maty Siman, Founder and CTO of Checkmarx contributed to this predictions blog.

Maty wrote, “With organizations increasingly leveraging open source software in their applications, next year, we’ll see an uptick in cybercriminals infiltrating open source projects. Expect to see attackers ‘contributing’ to open source communities more frequently by injecting malicious payloads directly into open source packages, with the goal of developers and organizations leveraging this tainted code in their applications.

As we see this scenario unfold, there will be a growing need for processes like developer and open source contributor background checks [contributor reputation]. Currently, open source environments are based entirely on trust – organizations typically don’t vet developers’ past projects or reputations. However, as attackers take advantage of open source projects, this trust will begin to erode, forcing organizations to take proactive mitigation steps by thoroughly vetting the open source code within their applications, as well as those providing it.”

So, as we see here, Maty Siman was spot on. Not only did Checkmarx see attacks on the open source supply chain coming, in fact, they did something about it by acquiring Dustico in August of 2021. Now, TTPs like dependency confusion, typosquatting, repository jacking (aka ChainJacking), and star jacking are the new name of the game. In fact, Checkmarx just released a new white paper today, Introduction to Supply Chain Attacks, explaining how these attacks actually work.

Landscape Changer: Checkmarx Supply Chain Security

As a result of Maty’s predictions (which did come true, by the way), and their proactive stance on defeating supply chain attacks, Checkmarx just announced a new arrow in the quiver of enterprise-class, open source supply chain defenses. Checkmarx SCA with Supply Chain Security (SCS) is now available, and the solution sets an entirely new bar for all SCA solutions.

Checkmarx is first to market with supply chain defenses organizations need now which include:

• Health and Wellness, and Software Bill of Materials (SBOM)
• Malicious Package Detection
• Contributor Reputation
• Behavior Analysis
• Continuous Results Processing

In addition to our white paper on supply chain attacks, Checkmarx released another white paper today, Don’t Take Code from Strangers – An Introduction to Checkmarx Supply Chain Security. This paper goes into detail about topics like SLSA, traditional code analysis, and pushing boundaries in secure software supply chain innovation.

Checkmarx SCA with Supply Chain Security (SCS) offers a more comprehensive approach to preventing supply chain attacks and securing open source usage by enabling developers to perform vulnerability, behavioral, and reputational analysis from a single, integrated platform. By natively integrating advanced behavioral analysis into SCA, Checkmarx provides developers with a streamlined, frictionless user experience to enhance their organization’s supply chain security.

To learn more about Checkmarx SCA with Supply Chain Security, you can request a demo here.

But modern applications also present some steep challenges, not least in the realm of security. In order to thrive in the modern development landscape, developers and AppSec pros alike must be sure that their security skills can address the variety of threats that teams face today – a time when cyberattacks are growing steadily in frequency and scope.

Here’s a list of four essential security skills that anyone involved in modern application development should possess.

IaC Security

Infrastructure-as-Code (or IaC) tools have become an essential part of many modern application development workflows. Using IaC, teams can automatically provision large-scale software environments, which maximizes scalability and minimizes the risk of configuration mistakes due to human error.

But the downside of IaC is that, if the configurations applied using IaC templates contain security issues, those issues will be proliferated across your entire environment. And in most cases, the IaC tools themselves do nothing to alert you to potential security issues.

That’s why developers and AppSec teams must learn to follow security best practices when configuring IaC templates, such as:

• Secure your secrets: Don’t hard-code passwords or other secrets into IaC templates. Store them in an external secrets manager instead.
• Modularity: Keep IaC templates short and modular. Trying to cram too much configuration into a single template increases the risk of making a mistake.
• Use default settings with care: Don’t blindly trust default IaC settings. Make sure you tailor templates to your environment.

Just as important, teams should use IaC scanning tools to validate their IaC configurations prior to applying them. IaC scanners automatically check IaC templates for misconfigurations that could create security issues.

Open Source Security Risks

There are many excellent reasons for modern development teams to leverage third-party open source code. Open source saves time because it allows you to reuse code that someone already wrote rather than having to write it yourself from scratch. It is also often easy to customize. And it’s usually free of cost, which is never a bad thing.

Yet open source also poses some significant security risks when you incorporate it into your applications. You can’t guarantee that third-party open source developers adhere to the same security standards that you do when they write their code.

For that reason, it’s critical to know where in your application you incorporate open source code, and also to scan that code to identify known vulnerabilities within it.

Container Security

Modern applications are often deployed using containers. Because containers – and the orchestration platforms used to manage them (like Kubernetes) – add another layer of infrastructure and complexity to your software stack, they create a variety of potential security risks that would not be present if you were deploying applications directly on a host OS, without having a container runtime and orchestrator in the equation.

Modern developers and AppSec teams need to know what these risks are and take steps to address them. A full discussion of container security is beyond the scope of this article, but basic concepts include:

• Image security: Securing container images by ensuring that any external components on which they depend are secure, as well as using a container image scanner to check for vulnerabilities.
• Configuration security: Scanning the configuration files that are used to deploy and orchestrate containers. Like IaC templates, these files can contain configuration mistakes that enable security breaches.
• Runtime security monitoring: Using monitoring tools that can collect and analyze data from across complex containerized environments (which means collecting data from various containers, from all of the operating systems running within the cluster of servers that hosts your containers, and from the orchestration platform) to detect signs of breaches at runtime.

Microservices Security Risks

Microservices have become massively popular because they make it easy to build agile, scalable applications that lack a single point of failure, among other benefits.

But microservices also significantly increase the complexity of application architectures, which in turn increases the risks of security issues. Because microservices rely on the network to communicate with each other, there is a higher risk of sensitive data exposure. Insecure authentication and authorization controls between microservices could enable a breach to spread from one microservice to an entire app. Security problems with the tools used to help manage microservices (like service meshes) create another set of security risks to manage.

As with container security (which, by the way, is a closely related topic, because microservices are often deployed using containers), there is more to say about microservices security than we can fit into this article. But some core microservices security best practices for developers and AppSec teams to follow include:

• Microservices isolation: When designing your microservices architecture, strive to isolate each microservice as much as possible. Allow interactions between services only where strictly necessary.
• Authentication and authorization: Always require authentication and authorization for microservices to communicate with each other.
• Network isolation: Isolate the internal networks that microservices use from the public Internet, and never expose a microservice directly to the Internet unless it needs to be.

Conclusion: Modern Application Development Requires Modern Application Security

Most of the security challenges discussed above simply didn’t exist ten years ago. Back then, no one was provisioning hundreds of servers using IaC templates or deploying applications with highly complex architectures based on microservices and containers.

But those practices are the norm for modern application development. Developers and AppSec teams must respond by ensuring that they are able to leverage the tools and skills necessary to meet the modern security risks that go hand-in-hand with modern application development.

Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure, and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO. His latest book, For Fun and Profit: A History of the Free and Open Source Software Revolution, was published in 2017.

Click here to learn more about security in the context of Modern Application Development

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.

Third-Party Extensions Are the Answer

To increase productivity and save a great deal of time, developers often use code written by third parties rather than rebuilding the same generic functionality across multiple applications. While there has always been a market for commercially licensed and supported extensions (including modules, packages, libraries, and frameworks), the vast majority of the third-party code used today is open source. This means that there is no marketplace and no purchase order; rather, a few extra lines of someone else’s code are simply imported into the software.

This can cause problems with licensing and disclosure if it is not accurately tracked and monitored. That is why software composition analysis (SCA) products are worth their weight in gold. These solutions find all of the third-party packages that are in use, then identify the corresponding licenses. They can even show if they are out of date or if known security vulnerabilities have been reported against them.

It’s All Based on Open Source

Even the lowest level of an application stack (the language and runtime engine) is often open source. The most popular languages in use these days are all open source, or at least have open source distributions. Go, Python, PHP, Ruby, and JavaScript are all open source by default, and even languages that are traditionally commercially supported have open source distributions like OpenJDK (for Java) and gcc (for C/C++).

After you’ve chosen your language, you’ll likely want to ensure that you have some structure in place so that you won’t need to declare all the basic functionality like dependency management and data management. Well over half of all Java applications use the Spring framework as their starting point. PHP uses Laravel, while JavaScript uses React and Bootstrap, among others.

Frameworks and languages form a solid foundation for any application, but the bulk of open source influence can be found in the staggering number of modules that are available as packages and libraries which can be easily integrated into applications.

How Easy Is It to Find Open Source Modules and Libraries?

Any web search for any type of functionality will often return results that link to places like GitHub, GitLab, PyPI, and many other sites. So how do you find what you need?

Let’s say that you want to make a particular form a little more secure by including a CAPTCHA. If you don’t know where to start, just head over to your favorite search engine and enter, “captcha library for Python.” In our case, the first result is an open source library that can be installed via pip (pip is the standard utility used in the Python ecosystem to install modules).

Installing this module is as simple as typing, “pip install captcha.”

Now, with just a couple lines of code, a whole new set of tested and proven functionality is added to the application in minutes.

from captcha.image import ImageCaptcha
image = ImageCaptcha(fonts=['/path/A.ttf', '/path/B.ttf'])
data = image.generate('1234')
image.write('1234', 'out.png')

For another, more real-world example, let’s say that you have a web application that needs to be able to pick a date from a calendar. To show you how to do this, we will use the jQuery library, which has a great deal of functionality and is easy to use.

The first step is to add the jQuery modules to the web page in question. There are two stylesheets and two script files that need to be imported. These are added between the head tags. The next step is to define the datapicker function, which activates the appropriate pieces of the jQuery library. The final step is to define where to put it on the page using an input field.

The code looks like this:

<!doctype html>
<html lang="en">
<head>
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1">
 <title>jQuery UI Datepicker - Default functionality</title>
 <link rel="stylesheet" href="//code.jquery.com/ui/1.12.1/themes/base/jquery-ui.css">
 <link rel="stylesheet" href="/resources/demos/style.css">
 <script src="https://code.jquery.com/jquery-1.12.4.js"></script>
 <script src="https://code.jquery.com/ui/1.12.1/jquery-ui.js"></script>
 <script>
 $( function() {
   $( "#datepicker" ).datepicker();
 } );
 </script>
</head>
<body>
<p>Date: <input type="text" id="datepicker"></p>
</body>
</html>

The finished web page looks like this:

When you select the date input, it will present a calendar. You can stylize it, of course, but this example shows the simplicity that open source libraries can provide:

Conclusion

Without intentional effort, you will not find a single modern microservice or web site that doesn’t have open source somewhere in the components that it relies on or ships. The question isn’t whether you can use open source, but whether it provides a full view. Different open source licenses have different restrictions around distribution. GPL requires the disclosure of all source code, whereas Apache and BSD licenses simply require proper copyright attribution. This can determine which open source libraries and modules you are able to include in a given application.

In any case, rather than just trusting the development team to document everything they do (and we all know how much developers love to document things), a better and more viable long-term solution would be to build a pipeline to catch all of the open source code early, before it could introduce known security vulnerabilities or licensing complications. Better yet, you could integrate SCA into your source code repository and let tools like Checkmarx Software Composition Analysis do the heavy lifting for you.

Vince Power is an Enterprise Architect with a focus on digital transformation built with cloud enabled technologies. He has extensive experience working with Agile development organizations delivering their applications and services using DevOps principles including security controls, identity management, and test automation. You can find @vincepower on Twitter.

Download our Ultimate Guide to SCA Here.