DevOps represents the fundamental cultural shift in software engineering towards performance: high performing teams, and high performance code.

In DevOps, security was never a primary consideration.

DevSecOps represents the reality that DevOps must grow to encompass security. Eventually, performant code will mean secure code by default – but we’re not there yet. How do we get there?

Let’s start with where we are now. Earlier this year, Checkmarx ran a survey asking CISOs about their current AppSec programs. One of our questions specifically asked: “Where are you on your DevSecOps journey?” You can see the answers below:

On the surface, this doesn’t look too bad… until you consider the details. Based on our scaling, “medium” only represents the “definition and strategy” phase. The actual process of integration and automation is where companies actually start “doing” DevSecOps, and only 1 in 5 companies surveyed have reached that stage in some form.

And let’s be clear – integration and automation are the goals of DevSecOps. DevSecOps is about taking the needs and outcomes of application security and integrating them with the processes and culture of DevOps. In 10 years, there should be no difference between “DevOps” and “DevSecOps.” DevSecOps is just what DevOps needs to be when it grows up.

DevSecOps: The Path to Maturity

OK – how do we get there? If I were to create a rough sketch of DevSecOps maturity, it would look like this:

Let’s start on the bottom. This is traditionally where AppSec finds vulnerabilities, and essentially throws them over the wall to developers and says “here, fix these.” I have some bad news for you, this is actually “Shift Left” in action. Maybe that’s flippant and a bit unfair; but it is the base level of maturity that puts organizations on the road to DevSecOps.

The next level focuses on the developer experience. Here, AppSec teams and developers alike realize that “Shift Left” isn’t really working. Not because anyone is bad, uncaring, or unintelligent, but because it is only intended to be the first step. In that stage, AppSec got tools to find and triage vulnerabilities. Now developers need tools to manage those vulnerabilities themselves without breaking their workflow. The “developer experience” stage of maturity focuses on IDE-integrations, remediation guidance, and other ways to keep developers focused without greatly disrupting their flow.

But like “Shift Left”, focusing on the developer experience eventually hits diminishing returns. Organizations will get stuck, and then they will need to begin to move towards the third step of maturity. This is where you take the foundational understandings of the first two steps, and work to define a DevSecOps culture.

DevSecOps: Worth the Effort

Culture is hard to change, but luckily, DevOps people have done it before. If you go back to the early days of Agile and Scrum, teams would hold daily standups, and then go back to working exactly the way

they had before. But, as modern DevOps organizations can confirm, it’s worth the effort. For DevSecOps, it’s also worth the effort. Here is an example of a Checkmarx customer’s journey, and you can see them go through the stages and the results:

This is a chart showing the number of vulnerabilities remediated by a Fortune 100 company, and it’s a powerful representation of what things look like when teams integrate.

If you’re curious about the types of things this customer did to get from the left to right side of the graph above, here we’ve got some examples ready based on where you are from a maturity standpoint:

Shift Left: If you just need to get something in place to start getting vulnerabilities over to developers, the easiest way is to integrate your AppSec tools with your feedback tool (be careful here, you don’t want to suddenly shunt 10,000 JIRA tickets over to the devs, so set some policies around it). Click here to see a video showing how easy that the integration is to do with Checkmarx.

Developer Experience: The easiest way to start improving your developer experience is by integrating with their IDE of choice. This is also simple to do with Checkmarx, and here is a video showing how: Watch Now!

DevSecOps: We’ll explore the keys to DevSecOps in detail in the next blog, particularly culture, automation, and speed, but we mentioned the importance of policy management in our first bullet point. While designing policy is difficult – it relies on great communication between development teams and security teams – creating and implementing policy with Checkmarx is easy. Here’s a video showing how it’s done: Watch Now!

This blog is just our first in a series on DevSecOps. Our next blog will focus on how to change culture, the need for automation, and the true meaning of “speed” within the context of DevSecOps. In the meantime, the videos I just listed are only some a few of those you can check out over on YouTube showing how easy it is for platform engineers and developers to integrate and work with Checkmarx One. Check them out here!

Embracing code to cloud is now much easier

There are three pillars leading this approach:

• Streamlined security posture management – Integrate security into every stage of the development lifecycle, offering unified view, automated risk analysis, and remediation guidance.
• Enhanced efficiency for teams – Achieve clear communication through integrated workflows, streamlined processes, and meeting development teams right where they work with the information they need.
• Actionable insights & prioritized remediation– Identify Kubernetes clusters, container images, code repositories and map them to Checkmarx One applications and projects with runtime data, for better risk management and to prioritize critical vulnerabilities effectively.

Understanding the Integration

The integration between Checkmarx and Wiz helps deliver actionable insights and prioritizes vulnerability remediation to our mutual customers. Checkmarx One correlates Wiz’s cloud asset inventory and network exposure with vulnerabilities and application security results, such as code repositories. This gives organizations the context needed to prioritize vulnerability remediation based on what is exploitable in the running application. This approach reduces the noise generated by non-critical vulnerability alerts by up to 90% and enables customers to focus their resources on addressing high-impact security issues.

This integration brings to life the “Shift Left, Shield Right” strategy, extending our Checkmarx One offering by adding runtime information to secure every stage of the Software Development Life Cycle (SDLC). This helps encourage collaboration between different teams and stakeholders throughout the entire process. Developers then gain access to actionable security insights directly within their IDE, which allows them to address vulnerabilities early in the development process. Then security teams can leverage runtime context and cloud asset inventory in order to provide developers with the most relevant security information and guidance. Ultimately, it accelerates the delivery of secure applications in a cloud-native environment.

As part of this partnership, we have also integrated our SAST scan results with the Wiz platform to correlate them with cloud security insights. This supports our combined vision of code to cloud and back – enabling greater security posture across an organization’s SDLC. With this new capability, our mutual customers can prioritize and address the most significant risks on the most business-critical assets. This partnership aims to streamline vulnerability detection and mitigation, transforming how enterprises secure their applications and cloud environments.

How Checkmarx enriches AppSec findings with Wiz runtime insights

Let’s see this in action.

In the Risk Management tab, we correlate all the Checkmarx scanner information and runtime data. We tie them back to their project, and their associated user. Adding the runtime context, and internet-facing information from the Wiz integration enables us to add another piece of the puzzle and modify the risk level to reflect what we know and prioritize them more effectively.

Runtime context allows us to understand whether vulnerabilities are exposed to the internet, which increases the risk of exploitation. Vulnerabilities that are exposed to the internet are prioritized due to their increased risk level

Let’s now look at the project level, where Checkmarx One connects all the dots. We can see all the building blocks of the project, code repos, and packages used within the project, including when they were scanned, how many vulnerabilities they have, the risk level and the runtime context.  This allows us to better prioritize the risk and escalate it as needed.

How Wiz enriches CNAPP with Checkmarx SAST findings

The integration of Checkmarx SAST scan results with the Wiz platform enhances application security directly on Wiz’s platform. Combining application security findings with Wiz’s own cloud security scan data, helps organizations identify, prioritize, and address the most significant risks to critical assets, at the development stage. This correlation provides a unified and actionable security visibility, improving the detection and mitigation of vulnerabilities across the entire software lifecycle.

Organizations then can navigate the complexities of modern cloud environments securely, with streamlined security posture management, actionable insights, and enhanced collaboration, can effectively mitigate risks and accelerate their cloud journey with confidence.

If you wish to start gathering runtime insights and see the magic happen Request a Demo, to get started.

• Widespread Malware Distribution on GitHub: Recent discoveries, including Apiiro’s report on over 100,000 infected GitHub repositories, highlight a growing trend of using GitHub for malicious purposes.
• Diverse Attack Methods: GitHub-based cyber threats employ various sophisticated strategies, including attacks on legitimate repos, social engineering, and exploiting GitHub actions. This variety in attack vectors signifies the adaptability and ingenuity of cyber attackers in exploiting GitHub’s functionalities.
• Critical Role of Continuous Monitoring in Cybersecurity: The evolving nature of threats on platforms like GitHub underscores the imperative for robust, continuous monitoring solutions.
• Checkmarx’s Proactive Defense Against Supply Chain Cyber Threats: Checkmarx’s Supply Chain Security solution vigilantly monitors malicious activities, swiftly identifying and alerting on suspicious actions in the open source ecosystem to effectively counteract these cyber threats.

Malicious Repo Confusion Campaign

In light of a recent blog released by Apiiro, the cybersecurity landscape is yet again reminded of the innovative ways attackers exploit platforms like GitHub to host and spread malware. Apiiro’s findings reveal a large-scale malicious repo confusion campaign impacting over 100,000 GitHub repositories, shedding light on the evolving tactics of cybercriminals. Interestingly, part of the attackers’ strategy involved creating fake forks to make their repositories seem legitimate, a tactic we have discussed extensively in relation to repository spoofing.

The attacker took the following steps: they first cloned existing repos and infected them with malware loaders. Next, they uploaded them back to GitHub under identical names, automatically forking each one thousands of times. Finally, they covertly promoted them across the web via forums, discord, etc.

This is not an isolated case. The use of GitHub for malicious purposes has been a recurring theme, as evidenced by several incidents in the past.

Attacks on Legitimate Repos

A notable method of exploiting GitHub involves attacking legitimate repos. A prime example is an incident in mid-2023where attackers, leveraging stolen GitHub personal access tokens, impersonated Dependabot, a well-known dependency update helper tool. These tokens bypassed two-factor authentication, allowing malicious code to be committed under the guise of Dependabot. This code aimed to extract sensitive information and inject malware into JavaScript files.

Nation-State Social Engineering Using GitHub

Another tactic is the use of social engineering. In contrast to the scrutiny typically given to public open-source repositories, GitHub’s private repositories provide a more concealed avenue for attackers. A recent discoveryrevealed how North Korean state actors were using these malicious repos to then integrate into software through social engineering, targeting specific organizations or individuals.

Attacking GitHub Actions for Public Repos

In mid-2023, GitHub user account, pastramahodu, forked nearly 2,000 repositories, with 319,191 total stars combined, as part of a widespread bug bounty hunt attempt for finding misconfigurations in popular project’s CI pipelines. The procedure was most likely automated and created Pull Requests which in some projects triggered the project’s CI pipeline and executed the custom commands. This highlighted the increasing focus on pipeline security as an entry point for supply chain attacks.

Conclusion

The recurring theme across these examples is clear: GitHub, a platform integral to the development community, has become a focal point for cybercriminals looking to exploit the software supply chain. The sophistication and variety of these attacks demonstrate the evolving and persistent nature of these threats. As part of the Checkmarx Supply Chain Security solution, we continuously monitor and detect suspicious activities in the open-source software ecosystem, such as these. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them. In the face of these sophisticated attacks, it is more important than ever for developers and organizations to stay alert, regularly review code sources, even from trusted platforms like GitHub, and implement robust security measures.

The Future of AppSec

The million-dollar question: what’s next?

2023 saw the rise in AI, with excitement and a rush to release AI-driven solutions. Consequently, AI experienced substantial adoption in a short time, with over 50% of respondents saying that they use it.

Applications mean something quite different than what they did even just a few years ago. Applications used to be simply made up of proprietary source code. Today, even source code may come from multiple sources, such as open-source code or be AI-generated, which introduces both security and legal risks. Developers can’t keep up with all of this, hence the push into secure code training and DevSecOps.

Applications have also extended from a local system or closed on-premises data center into the cloud or even multiple cloud environments. We’ve been migrating to the cloud for years, but as more of our apps are in the cloud and cloud-native development goes mainstream, this pushes interests in API Security, AppSec Posture Management (ASPM), and Cloud Native Application Protection Platforms (CNAPP).

It’s also important for all stakeholders to be able to unify and consolidate on a single platform that has something for everyone. CISOs need executive, high-level dashboards, to provide a holistic view of the entire application security posture. Developers need tools that integrate seamlessly into their existing workflow, and don’t slow them down. 

Read the report to learn more.

The Importance of Developer Experience

Security must not impede development. 61% of developers are concerned about security getting in the way of development and 38% of AppSec managers claim “improving the developer experience” is a key reason for selecting their recent AppSec solution.  What does developer experience really mean?  Ultimately, it means that developers can spend their time focusing on developing innovative applications rather than getting bogged down by security minutia – developers are software experts, not security experts. This means making it easy for them to know exactly what to fix first – prioritizing for the greatest business impact, seamlessly integrating into their workflow and existing toolchain, not interrupting the development workflow – meeting developers where they live and providing them the education and training needed to write secure applications – equipping developers with the tools and knowledge to fix critical vulnerabilities.

How does this work? Automation so scans happen automatically through integration with Source Code Management (SCM) and CI/CD tools. It means providing security findings back into the IDE and development tools, so developers don’t have to use different tools. 

Read the report to see the full list of what developers are looking for.

Start Planning For 2025

It’s a cliché but true: application security is constantly changing. It’s important to slow down and look at the current state of application security, understand where you stand compared to your peers, and consider whether you are considering the roles and responsibilities of all your core stakeholders: AppSec managers, CISOs, and developers.

The result is The Future of AppSec. Get it now and see where you stack up.

Cloud-native applications have gained popularity over traditional monolithic applications in recent years due to their scalability, flexibility, and efficiency. In contrast to monolithic applications, cloud-native applications use microservices architecture and containers and are specifically designed to be modular, lightweight, and highly adaptable. Cloud-native applications enable organizations to adapt seamlessly to evolving business needs, facilitating faster time-to-market.

While this offers unparalleled opportunities for business growth and innovation, it also poses a major security challenge. The dynamic nature of the cloud-native paradigm widens the attack surface, leaving organizations vulnerable. Traditional application security tools can’t properly secure the borderless landscape of cloud-native architecture. 

So, what is the most effective way to secure cloud-native development?

Shift From Monolithic to Cloud-Native 

Originally considered the technological cornerstone for enterprises, monolithic applications feature tightly integrated components that operate on dedicated servers, with their entire codebase residing in one place. Since monolithic applications are so contained, their attack surface is much smaller and straightforward to secure.

While initially fostering business success, the technological inflexibility and complicated scalability of monolithic applications began stifling business development and growth. Each feature change or update required extensive architectural overhauls, demanding coordination across all teams. A single point of failure could lead to a system-wide crash.

Organizations became increasingly frustrated with these limitations, and the need for a better alternative became evident. 

Enter cloud-native applications.

Cloud-Native Applications

Triggered by these shortcomings, organizations began shifting to cloud-native environments. 

When we talk about “cloud-native” we are referring to applications, or services, that run on cloud environments from the ground up. These applications take full advantage of cloud computing frameworks.

The shift to cloud-native development revolutionized how applications are created. These new capabilities help facilitate more agile software that could adapt to shifting demands, enabling faster innovation, smoother deployments, and better communication.

However, this model has its drawbacks, including shared responsibility model, openness of default settings, lack of visibility, and availability over security focused.

The dynamic nature of cloud-native environments demands a more comprehensive security solution. 

Protecting Cloud-Native Applications

The traditional security methods simply cannot keep up with the dynamic nature of cloud-native development, leading to gaping holes in their application protection. 

The flexibility of cloud-native development fosters innovation but can make it difficult for traditional AppSec solutions to provide a comprehensive view of vulnerabilities. As a result, organizations are faced with either prioritizing infrastructure security or maintaining a balanced security approach, potentially leaving vulnerabilities unaddressed. In addition, there is very little communication between AppSec and developers, leading to solution silos.

Protecting cloud-native applications demands a holistic security approach that fosters communication between all stakeholders to ensure that every part of the software development lifecycle (SDLC) is protected, from code to cloud. 

How can this be achieved?

What About The “Shift Left” Approach?

Let’s first take a step back.

To combat the speed and agility of cloud-native development, many initially called for “shifting left” in application security. This approach emphasized integrating security testing earlier in the development cycle, literally moving security testing from the right (deployment) to the left (development) of the SDLC. The idea here was to proactively catch vulnerabilities and misconfigurations at the beginning of the development process to prevent them from persisting into later stages. 

This aimed to shorten feedback loops and foster a proactive security mindset. 

And it helped – in the beginning. While effective in catching issues earlier in the pipeline, the overemphasis on early-stage protection may have given a false sense of security leaving crucial applications vulnerable. 

This gap highlighted the need for a balanced and holistic AppSec approach: code to cloud.

Code to Cloud Protection

Shifting left isn’t enough anymore. Prioritizing security measures at every phase of the SLDC – and not just the beginning – has become crucial. According to Aqua Nautilus research, in the past year alone there was a 300% surge in attacks targeting the code, infrastructure, and development tools. This emphasizes the need for balanced and comprehensive security measures across the SDLC. To protect from code to cloud, instead of just shifting.

What Does “Securing From Code” to Cloud Actually Mean?

Securing applications from code to cloud means applying security controls in every stage of the SLDC, including during: 

• Training: Initiate security with developer education on secure coding best practices. 
• Coding: Adopt tools like Static Application Security Testing (SAST) and API security during code creation to help pinpoint potential risks within the codebase before deployment.  
• Building: Utilize testing tools such as Continuous Integration (CI), Software Composition Analysis (SCA), and Software Supply Chain Security (SSCS) for seamless development workflows, third-party vulnerability detection, and visibility into the application components.
• Testing: Use Dynamic Application Security Testing (DAST) to simulate real-world cyber threats, ensuring a comprehensive security assessment. 
• Deploying: Implement Infrastructure as Code (IaC) security to narrow down potential attack points and ensure a safe application rollout. 
• Go-live: Implement real-time monitoring and dynamic threat detection during the runtime phase. 

Only a comprehensive code to cloud AppSec approach can secure the entire SDLC, create a resilient business environment, and reduce costs in the face of evolving cyber threats.

Checkmarx’ Code to Cloud Approach

So, does such a comprehensive code to cloud solution exist? It does!

Checkmarx takes a unique approach to securing applications from code to cloud. While most solutions approach cloud security from an infrastructure, network, or workload perspective and then shift left, Checkmarx starts securing from the very first line of code. Our industry leading Checkmarx One platform offers a full breadth of security capabilities to protect every stage of the SDLC, correlate security findings, and prioritize remediations so you can make the biggest impact on reducing risk.

Here are some of the Checkmarx One benefits: 

Unified AppSec platform 

Correlates all security data to prioritize remediation and identify risk across your entire footprint – including cloud-native and traditional non-cloud applications. 

Comprehensive AppSec capabilities 

Provides the full suite of capabilities required to secure cloud-native applications all on a unified, consolidated application security platform. 

Seamless integration across the SDLC  

Offers the broadest set of SDLC integrations, including IDEs, SCM tools, CI/CD tools, and feedback tools. This enables automatic security scans as applications progress from code to build to deploy in the cloud.

Visibility from code to cloud 

Correlates security data across every stage in the SDLC – including runtime insights – to provide true visibility into the vulnerability lifecycle from code to cloud.

If you’re interested in how Checkmarx One can secure your organization from code to cloud, feel free to schedule a personal demo here.

Conclusion:

The evolution from monolithic to cloud-native applications presents opportunities and challenges. While cloud-native applications offer more scalability and flexibility, they also bring new security complexities. The need for a comprehensive AppSec solution that protects from code to cloud is imperative, especially considering the gaps in the shift left security.

Checkmarx One was created to protect your applications from code to cloud, so that they are secured throughout the entire SDLC. 

Don’t leave even one line of code exposed – make sure your applications are secured from code to cloud today!

There has been a recent uptick in leaks, most notably Mercedes-Benz and Football Australia, who found themselves as victims in incidents that highlight the need for robust data protection strategies. 

The Mercedes-Benz Source Code Exposure

Mercedes-Benz faced a significant breach when an employee inadvertently published a private authentication token on a public GitHub repository, granting unfettered access to the company’s source code. This error was discovered by RedHunt Labs during a routine scan in January, revealing that the exposed token provided complete access to Mercedes’s GitHub Enterprise Server. This access level meant that anyone with the token could download private repositories containing sensitive data, including intellectual property, cloud access keys for Microsoft Azure and Amazon Web Services (AWS), database connection strings, and other critical internal information.

The Incident at Football Australia

Cybernews researchers reported a significant data leak at Football Australia, where personal information of Australian soccer players (including passports and contracts), as well as customer purchase details, were exposed online. The security breach lasted for at least 681 days and could potentially impact many local customers, with over 100 buckets of data exposed. The exposed data poses a severe threat, with potential for identity theft and fraud.

This cybersecurity incident, attributed to human error, resulted from a leak of secrets from plain-text Amazon Web Services (AWS) keys. This allowed public access to 127 digital storage containers containing sensitive data. 

Sample of the exposed data. Image by Cybernews.

Lessons Learned

These incidents serve as potent reminders of the vulnerabilities inherent in digital infrastructures across all sectors. They highlight the need for:

• Enhanced Secret Management: Employing tools and practices that ensure the secure handling of keys and tokens is non-negotiable.
• Regular Security Audits: Proactively scanning for vulnerabilities and exposures can prevent potential breaches.
• Education and Awareness: Human error being a common factor in both cases, underscores the importance of continuous education on best practices for all personnel involved in handling sensitive information.
• Incident Response Planning: Both organizations acted swiftly upon discovery, a testament to the importance of having an effective incident response strategy in place.

The cybersecurity incidents faced by Football Australia and Mercedes-Benz illuminate the critical need for heightened security measures and vigilant management of digital assets. Let these stories be a rallying cry for a unified approach to protecting our digital world—from the pitch to the pavement.

Maintaining the Sanctity of Secrets

To avert the leakage of secrets, consider implementing these strategies:

1. Environment Variables for Secrets: Store secrets in environment variables rather than embedding them directly in code to facilitate easier management and prevent their accidental inclusion in version control.
2. .gitignore for Sensitive Files: Utilize a .gitignore file to exclude files containing secrets from Git tracking. This ensures that these details do not inadvertently enter version control systems. If using environment variables for secrets, ensure their associated files are also ignored.
3. Secrets Management Tools: Employ secrets management tools for the secure handling and storage of system or application secrets. This guarantees encryption and access solely to authorized individuals.
4. Encryption of Secrets: Encrypt secrets prior to their storage in code repositories to add a security layer, making it challenging for attackers to obtain sensitive information.
5. Two-Factor Authentication (2FA): Activate 2FA for access to code repositories, enhancing security and complicating unauthorized repository access efforts.

These practices can significantly mitigate the risk of inadvertently exposing sensitive information across various platforms, including code repositories, content management systems, emails, and other digital assets not contained within a repository.

Preventing secrets from leaking on external tools with Secrets Detection by Checkmarx

Secrets Detection integrates and expands deeper scanning capabilities of Too many secrets 2MS, a command line tool written in Go language and built over gitleaks, directly into Checkmarx One. 2MS is one of the most popular open-source tools for secret detection, with over 2 million downloads. Secrets Detection in Checkmarx One finds secrets such as login credentials, API keys, SSH keys and more hidden in code, content systems, chat applications and more.

• Supported tools include Confluence, Discord, filesystem, git, paligo, Slack, Git Hooks, GitHub Actions
• Scan history to ensure secrets are not leaked in any previous versions   
• Detect secrets that are specific to your company with secret customization 

Learn more about reducing the risk of leaked secrets across the supply chain

It is no longer possible to protect code solely with perimeter security and firewalls. Attack surfaces have grown and the once protected is now vulnerable. Open source has proved an invaluable resource to developers but can also be a backdoor for hackers. Enterprises are now releasing new versions of their code two or three times a day, making stringent security even more difficult. 

The constantly changing nature of development means organizations ranging from hospitals to the world’s largest tech providers are under threat. We need to rebuild our virtual city walls to keep pace with the modern threat landscape. 

Expanded armories 

Oak shields have been replaced by SAST scans in this new world of security. The armory of enterprises has expanded rapidly with a myriad set of tools available to tackle vulnerabilities. However, this has led to the issue of how best to manage all these tools. And how to consolidate the data and results of each to provide complete visibility across the SDLC. 

Each of these tools will produce alerts. Already overworked devs need to prioritize and focus on the ones that really matter. It’s no wonder so many vulnerabilities are ignored when bug reports are flying in from all sides. 

From code to cloud 

The rapid pace of innovation has resulted in the concept of “code to cloud” security. This centers around the proactive philosophy that security needs to be integrated from the very beginning of the software development lifecycle (SDLC), all the way to deployment and runtime.  

The drawbridge has been replaced by dev experience. This means a culture of secure coding practices, static code analysis, and threat modeling to help identify and address vulnerabilities early on and at every stage of the SDLC. From the start it is crucial to guide developers with actionable remediation guidance. As the code progresses through the SDLC), cloud adoption introduces complexities, especially in deployment and the integration with continuous integration/continuous deployment (CI/CD).  

A successful code to cloud program requires buy-in and integration with developers, AppSec, and leadership teams. That means:   

• Continuous security monitoring in the cloud to detect and respond to threats in real-time. 
• The need for incident response planning and procedures to effectively mitigate security breaches. 
• Understanding the challenges of managing diverse security tools. 

Environmental awareness 

Castle building has been replaced by coding. Another factor that needs to be considered in secure development is the move towards Infrastructure as Code (IaC) – the process of provisioning and configuring an environment through code instead of devices and systems.    

IaC is both a security opportunity and potential liability. Templates can enforce security best practices and ensure consistent security across cloud environments. But they can also introduce vulnerabilities. Errors in Code or misconfigurations of cloud resources may leave you open to serious compliance and security risks.   

Protect your enterprise   

It’s fair to say that your code will be a target for malicious actors for the foreseeable future. The invaders will continue to find new ways to breach the walls. You and your enterprise can’t afford to stand still.  

Emerging technologies such as artificial intelligence (AI) and machine learning (ML) will play a role in automating security tasks and improving threat detection. It’s also crucial to stay informed about new security threats and vulnerabilities and adopt a proactive approach to cloud security.    

Don’t let innovation overtake your security. Embrace a security culture centered on code to cloud with the help of Checkmarx.    

Secure your apps from code to cloud 

CVSS Score

CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
CVS Score: 9.9 (Critical)

Impact Summary

If the vulnerability is exploited, an attacker could write files to any location on the affected computer. This could be elevated to an RCE in a variety of ways depending on the environment and the operating system. This will be demonstrated later in this write-up.

Description

Impacket’s smbserver is vulnerable to Path Traversal Attacks. An attacker that connects to a running smbserver instance can list and write arbitrary files to any location on the attacked host (not just the chosen workdir for the server).
The reason for that is that while there is validation against relative paths in filenames in smbclient (and of course Windows Client), the Impacket SMB server implementation, smbserver does not validate it, which allows an attacker with an edited version of smbclient to exploit anyone who deploys an instance of smbserver.

Vulnerability Analysis

The following 2 lines take the filename path from the received SMB request and try to list its directory without making sure that the path is inside the intended working directory. This could enable an attacker to read the contents of the file system:

• https://github.com/SecureAuthCorp/impacket/blob/cb6d43a677c338db930bc4e9161620832c1ec624/impacket/smbserver.py#L3485
• https://github.com/SecureAuthCorp/impacket/blob/cb6d43a677c338db930bc4e9161620832c1ec624/impacket/smbserver.py#L876

The following 2 lines take the filename path and contents from the received SMB request and try write the contents to the received path without making sure that the path is inside the intended working directory. This could enable an attacker to arbitrarily write files:

• https://github.com/SecureAuthCorp/impacket/blob/cb6d43a677c338db930bc4e9161620832c1ec624/impacket/smbserver.py#L2008
• https://github.com/SecureAuthCorp/impacket/blob/cb6d43a677c338db930bc4e9161620832c1ec624/impacket/smbserver.py#L2958

Proof-of-Concept

To exploit this vulnerability, we have edited Impacket’s own smbclient.py to exploit its server implementation with 2 extra functions: do_ls_exploit and do_put_exploit. The functions do the exact same thing as do_ls and do_put (which is list directory and put file), only they do not sanitize the file paths on the client.
Since this is not enforced on the server, when combined with a path containing Path Traversal strings (../), these customized functions allow an attacker to read directories and write files anywhere on the file system.
Below are the differences between the two smbclient functions and their original counterparts:

Below is a Proof-of-Concept flow of the attack:

Creating a file for injection, connecting to a running smbserver instance (run locally for demonstration purposes) using the edited smbclient.py script and connecting to WORKDIR

Listing the directory contents (empty directory)

Listing /tmp using Path Traversal exploit

Injecting poc.txt and confirming using the exploit again.

CrackMapExec

Another tool that we found containing the same vulnerability is CrackMapExec. CrackMapExec (or CME for short) is a post-exploitation tool used primarily for offensive purposes and is heavily based on the Impacket library. We have found three attack modules that use the vulnerable smbserver which are: netripper, get_timedscreenshot and get_keystrokes. When an attacker attacks a victim with one of these modules, CME opens an smbserver instance in order to collect the results. As we’ve seen before, this could be exploited by a third party.

Proof-of-Concept

Exploitation of the get_timedscreenshot module of CrackMapExec using an injected PHP Webshell in /var/www/html.

cme

Honeypots and Chameleon

Finally, we found two honeypot-based tools (used for creating intentionally vulnerable environments that act as tripwires for incoming attacks) called “honeypots” and “Chameleon,” which again contain the same vulnerability. “Honeypots” is a python library which contains 16 different honeypots (including Impacket’s smbserver) in a single PyPI package for monitoring network traffic.
Chameleon is a project from the same creators which features a GUI for handling multiple honeypots (imported from the “honeypots” library), which again contains the same vulnerability.

Proof-of-Concept

Exploitation of the “honeypots” smbserver using an injected SSH Key.

honeypots

Recommendations

To avoid issues like this, update the Impacket package to the latest version.

Summary of Disclosure and Events

After notifying SecureAuthCorp, they informed us that they were aware that there might be possible vulnerabilities in the implementation, as can be seen by this 10 year old comment. Nevertheless, they did acknowledge the vulnerability and promptly accepted our fix. We would like to thank SecureAuthCorp for their fast response and continuous contribution to the security and research community.

Timeline of Disclosure

• Apr 20, 2021 – Disclosure
• Apr 20, 2021 – Issue acknowledged by SecureAuthCorp
• Apr 26, 2021 – Fix committed
• Apr 26, 2021 – CVE-2021-31800 assigned
• May 3, 2021 – Fixed version released
• June 16, 2021 – Public disclosure

Final Words

The research and resulting findings with Impacket serve as a valuable reminder that almost any piece of code that could be deployed in an organization must be tested regularly and made compliant, even if it does something as benign as serve some files via an SMB share. In this case, multiple tools that can be deployed by security experts in the company, either for testing or entrapment (honeypots), would actually be leaving themselves vulnerable.
Impacket is very popular amongst security professionals, and so are the derivatives uses of the vulnerable code within it. The Checkmarx Security Research Team is dedicated to performing investigations of this nature to better improve the security posture of tools and organizations more broadly.

Copyright Notices

Impacket

Copyright (c) 2000 The Apache Software Foundation.  All rights reserved.
This product includes software developed by SecureAuth Corporation (https://www.secureauth.com/)

CrackMapExec

Copyright (c) 2020, byt3bl33d3r All rights reserved.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Chameleon

Copyright (C) 2007 Free Software Foundation, Inc. https://fsf.org/  Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

Honeypots

Copyright (C) 2007 Free Software Foundation, Inc. https://fsf.org/  Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

Impact Summary

CKEditor 4 is commonly used and may affect a variety of environments, such as blogs, content management systems, and other websites that accept rich text content from users. Successful exploitation of the vulnerability leads to arbitrary web script injection. The impact depends on where the plugin is used. It may lead to account takeover, credential stealing, sensitive data exposure, etc.
When we found the vulnerability in CKEditor 4, we informed the maintainers. They didn’t initially consider our finding as a security issue, but released a new version with the fix (4.16.1). We continued our research and found that Drupal and django-ckeditor are vulnerable to XSS because of the issue we found. We informed both, and they pulled the CKEditor 4 version 4.16.1.
From here, we asked MITRE to issue a CVE because we strive to inform all CKEditor 4 dependents to get the CKEditor 4 latest version. Later on, CKEditor 4 realized the significance of our finding took the responsibility to issue CVE-2021-33829.

CVSS Score

CVSS: 3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
Score: 6.1 (Medium)

Description

In June 2020, CVE-2020-9281 was published due to a cross-site scripting CKEditor 4. The cause for this issue is in the HTML data processor that doesn’t sanitize a payload that contains the reserved ck_protected keyword.
The reserved  “cke_protected” keyword is used internally by CKEditor 4 developers. It is an HTML comment that’s content is encoded. For simplicity, we’ll use the term ‘protected ‘comment’ in this blog.
The CKEditor 4 developers’ solution was to ensure there are no externally injected protected comments before parsing by removing instances of the protected comment. Since the keyword is only removed once, nesting the keyword yields the keyword (e.g., keykeywordword -> keyword). This allows an attacker to bypass this protection mechanism and exploit the XSS vulnerability, which was assumed to be fixed.

Original Proof-of-Concept for CVE-2020-9281

1. Click the source button in CKEditor 4
2. Paste the following payload:

Xss<!--{cke_protected} --!><img src=1 onerror=alert(`XSS`)> -->Attack

3. Click the source button again to return to the regular editor.

CVE-2020-9281 Fix With the Payload Above

1. Click the source button in CKEditor 4
2. Paste the following payload:

Xss<!--{cke_protected} --!><img src=1 onerror=alert(`XSS`)>-->Attack

3. Click the source button again to return to the regular editor

Proof-of-Concept of the Flawed Fix of CVE-2020-9281

1. Click the source button in CKEditor 4
2. Paste the following payload:

Xss<!--{cke{cke_protected}_protected} --!><img src=1 onerror=alert(`XSS`)> Attack

3. Click the source button again to return to the regular editor.

Proof-of-Concept of the Flawed Fix of CVE-2020-9281 in Drupal

1. Edit a basic page
2. Click the source button in CKEditor4
3. Paste the following payload:

Xss<!--{cke{cke_protected}_protected} --!><img src=1 onerror=alert(`XSS`)> Attack

4. Save the page
5. The following user that edits the same page is exposed, as demonstrated in the screenshot below:

Proof-of-Concept of the Flawed Fix of CVE-2020-9281 in django-ckeditor

1. Click the source button in CKEditor4
2. Paste the following payload:

Xss<!--{cke{cke_protected}_protected} --!><img src=1 onerror=alert(`XSS`)> Attack

3. Click the source button again to return to the regular editor or click the save button

Vulnerability Analysis

The htmldataprocessor’s removeReserveKeywords function aims to ensure there are no externally injected protected comment keywords before parsing.  However, it fails to remove instances of the protected comment recursively.

1. The removeReserveKeywords removes instances of the protected comment keyword.
2. The parse method splits to elements array what is left from the payload using a regular expression.
3. The regular expression identifies comments with the following structure

<!--Comment -->.
If the input contains a comment with an extra exclamation mark, like this
<!--comment --!>,
the regular expression does not consider the – -!> suffix as a closing tag of the comment and treats the rest of the input as a comment until a proper closing suffix appears, like this “- ->”.

4. The third element of the array that resulted from the regular expression processing is a comment.
5. The protectRealComments encodes the third element of the array if it considers it as a real comment. In a case of a nested protected comment, the protectedRealComments input contains a protected comment. For that reason, the protectedRealComments doesn’t encode it.
6. The browser identifies the suffix of the following input <- -comment – -!> as an error and mutates the input into proper html comment: <!- -comment – ->. The remainder of the payload stays out of the html comment unencoded.

When the algorithm processes the new Proof-of-Concept, the following occurs:

1. An attacker injects this payload

Xss<!--{cke_{cke_protected}protected}--!><img src=1 onerror=alert(`xss`)> -->Attack

2. The removeReserveKeywords removes the {cke_protected} and what is left from the payload is:

Xss<!--{cke_protected}--!><img src=1 onerror=alert(`xss`)> -->Attack

3. Since –!> is not treated as a comment end tag , the CKEditor4 parse method considers the whole highlighted text as a protected comment

Xss<!--{cke_protected}--!><img src=1 onerror=alert(`xss`)> -->Attack

4. The protectRealComments identifies the comment as protected comment and doesn’t  encode its content.
5. The browser mutates the payload, and the exclamation mark is removed. Because of that, the comment is closed, and the rest of the payload remains unsanitized, with the ineffectual closing comment at the end.

Xss<!--{cke_protected}--><img src=1 onerror=alert(`xss`)> -->Attack

6. The browser runs the unsanitized img onerror event

Recommendations:

The fix for this issue has been released, and it is highly recommended to update CKEditor 4 and Drupal to the latest available version. Regarding CKEditor, moving to CKEditor 5 is also an option.
While CKEditor 5 exists, CKEditor 4 is still maintained because they are not entirely alike. CKEditor 5 doesn’t have an out-of-the-box source button for freestyle HTML coding. It’s possible to achieve the source button functionality by developing a plugin or consuming a plugin of third parties.

Timeline of Disclosure:

April 28, 2021 – Disclosure to CKSource

May 18, 2021 – Disclosure to Drupal

May 20, 2021 – CKEditor4.16.1 release, mitigating the vulnerability

May 26, 2021 – Drupal 9.2 release and security advisory mitigating the vulnerability

May 26, 2021 – Backdrop CMS (a fork of Drupal) 1.19.1 release and security advisory mitigating the vulnerability

May 29, 2021 – django-ckeditor 6.1.0 release, mitigating the vulnerability

June 03, 2021 – CVE-2021-33829 assigned

June 14, 2021 – Public disclosure

Conclusion

This type of activity is part of the Checkmarx Security Research Team’s ongoing efforts to protect the software supply chain. Once the Checkmarx Security Team reveals a vulnerability in a package or a component, we immediately inform and help the maintainers mitigate the vulnerability. We also warn CxSCA customers if they use the vulnerable solution. Once the maintainer releases a fix, Checkmarx customers are the first to know.
No matter how a code is secured, using third party components exposes websites, services, and other software solutions. Therefore, it’s extremely important to mitigate vulnerabilities in widely used components and protect the supply chain.

Typical software applications are comprised of two types of code: custom code created by your internal development teams, and third-party code – often open source – created outside the organization. Until about 10 to 15 years ago, almost all software was custom code, and every line of software was created and tested by in-house software teams. Third-party code from vendors, and in particular open-source software, wasn’t trusted. Regardless of the source, there are vulnerabilities in nearly every piece of code – which we at Checkmarx call, code exposure.
Software security solutions that include application security testing (AST) manage and measure your overall Software Exposure, which helps you accurately understand and significantly reduce your organization’s business risk. One component of software exposure includes the concept of code exposure as shown in the graphic below. This concept raises the question of, “Have we identified critical vulnerabilities in our software – both custom code & open source?”

What Are Vulnerabilities?

Vulnerabilities are weaknesses in software that can often be exploited by threat actors. Most vulnerabilities occur during the design and coding phase of the Software Development Life Cycle (SDLC). These vulnerabilities are the result of several factors to include design errors, coding errors, and the use of open-source components with known vulnerabilities. Another significant contributing factor to developers introducing vulnerabilities is due to code complexity.
Organizations with very large software applications typically do not have one person on staff that understands the entire code base, which can contribute to the propagation of security issues throughout a code base.

Vulnerabilities Due to Coding Errors

Software developers work from a specification describing what the software is intended to do (for example, when button A is pressed, display Account Information). Developers use functional requirements as the blueprint for their work. If a functional requirement doesn’t perform as specified, a functional “bug” is recorded.
Security bugs or defects can occur when features aren’t implemented properly. For example, when button A is pressed, information on all accounts is displayed. Or the feature works, but it can be manipulated by threat actors to gain access to privileged information. Security must account for unforeseen misuse cases that cause the application to “break”, or otherwise perform in unintended ways.
The security of software is usually not part of the functional specification, and just having a requirement that the software be “secure” doesn’t count. Software developers have traditionally been measured on a functional basis. If they delivered features on time, they were doing their jobs right. Security was never considered until about 20 years ago, and secure coding is still rarely taught in computer science programs.

Lack of Focus on Security, Leads to Code Exposure

One source of code exposure is mistakes or weaknesses created by developers in custom software when they’re writing code. These weaknesses are often derived from poor coding behaviors, habits, and policies, or they are due to an ever-changing threat landscape or characteristics of various coding languages. Threat actors focus their efforts on finding these weaknesses and exploiting them, often to their financial benefit. The most common weaknesses (or software errors) are enumerated in the OWASP Top 10 and the SANS Top 25.

Vulnerabilities from Third-Party Components

The adoption of open-source components by software development teams dramatically changed the software industry. Instead of building all software “from scratch”, organizations use open-source components to provide common or repetitive features and functionalities. This limits the use of custom code to proprietary features and functionality.
As a result, developers spend their time on key differentiators, rather than recreating common features. The adoption of open source by nearly all industries has fueled increases in open-source development. Many large organizations, such as Microsoft, have embraced open source, and millions of open-source projects are available to developers to both use, and contribute to.
Open-source software is still software and it’s exposed to coding errors that can result in security vulnerabilities. Large numbers of newly discovered vulnerabilities are disclosed in open-source software every year. These vulnerabilities are typically reported in a responsible manner, accompanied by a patch or updated version that fixes the vulnerability, making remediation of vulnerable components relatively easy.

Remediating Vulnerable Components

It’s not always simple to remediate “the usage” of a vulnerable open-source component, however. First, you must have visibility of where open-source components are used. Unfortunately, many organizations don’t track their usage of open source – or they track them in a static, outdated spreadsheet. The average application includes hundreds of unique open-source components, and developers download and keep those components in their workspaces for years.
As these components age, the chance that vulnerabilities have already been discovered and disclosed in them increases. With hundreds of poorly tracked components, and lots of new vulnerabilities each year, many organizations are exposed to potential exploitation. Attackers are well aware that these open-source components are often poorly tracked and maintained.

Identifying Code Exposure for Custom Code

Fortunately, there are solutions that help identify code exposure. Start by analyzing the software your organization creates internally, and choose a complete application security testing solution that integrates with Continuous Integration (CI) servers as well as the developers’ integrated development environment (IDE). Static Application Security Testing (SAST) and Integrated Application Security Testing (IAST) solutions are a must have. These solutions help you identify coding errors in custom code so you can find vulnerabilities early in the SDLC. It’s also important to configure your security solution to test for specific types of weaknesses or errors, such as those listed in the OWASP Top 10 or SANS Top 25. Of course, those aren’t the only vulnerabilities to worry about, so it’s helpful to be able to test more broadly in all cases.

Identify Code Exposure in Third-Party Code

Today, the average application is mostly open source. Software composition analysis demonstrates that today’s applications are comprised of more than 80% of open-source components within the code base. The adoption of Linux as an enterprise-class operating system, Java as primary development language, and Apache Struts as an MVC framework have increased confidence in open-source components.
Since open-source components have become the building blocks for modern applications, identifying code exposure in third-party components has become an essential part of any software security program. You need a solution that mitigates code exposure from third-party components by scanning builds to identify all open-source components used. Look for solutions that provides a list of any publicly reported vulnerabilities in those components, accompanied by remediation advice for using updated versions or patches for those vulnerabilities. It’s essential that your software security solutions are integrated into build processes, then reviewed and acted upon with every build.

Resolve Code Exposure

Incorporate application security testing (AST) solutions throughout your SDLC to manage risks inherent to code exposure. Here are some key software security solutions that can help your team resolve code exposure:

Static Application Security Testing

What to look for: ability to automatically scan uncompiled/unbuilt code and identify security vulnerabilities in the most prevalent coding languages.

Interactive Application Security Testing

What to look for: ability to continuously monitor application behavior and find vulnerabilities that can only be detected on a running application.

Open Source Analysis

What to look for: ability to enforce open source analysis as part of the SDLC and manage open-source components while being able to ensure that vulnerable components are removed or replaced before they become a problem.

Developer Software Security Education

What to look for: an interactive, engaging software security training platform integrated into the development environment, sharpening the skills developers need to avoid security issues, fix vulnerabilities, and write secure code.

Professional & Managed Services

What to look for:  a trusted team of advisors who can help development organizations transform their DevOps initiatives by adding security throughout their SDLC.
With the information these software security solutions provide, your team can prioritize issues properly and resolve them in a timely manner.
Unify your software security into a single, holistic platform to manage your software exposure. Learn how here.