DEV Community: ShiftLeft

Spring4Shell: Spring Remote Code Execution Vulnerability

Vickie Li — Sat, 02 Apr 2022 05:45:04 +0000

Spring unauthenticated RCE via classLoader manipulation

Photo by Emile Perron on Unsplash

A critical zero-day vulnerability in the Spring framework was recently reported to Spring’s maintainer, VMWare. The vulnerability is an unauthenticated remote code execution vulnerability that affects Spring MVC and Spring WebFlux applications. You can find the CVE here: https://tanzu.vmware.com/security/cve-2022-22965.

What is affected?

The Spring4Shell RCE vulnerability allows attackers to execute code on applications using the Spring framework before 5.3.18or 5.2.20, with JDK 9+. In addition, applications need to be mapping request parameters into Plain Old Java Objects (POJO) to be vulnerable. Finally, currently available POCs only work on WAR deployments on the Apache Tomcat server.

Because of these mitigating factors, the Spring4Shell vulnerability is not expected to have the wide-ranging impact of the Log4Shell vulnerability we encountered back in December. However, things can change, and more ways to exploit the vulnerability might be found in the future. And although this vulnerability might not affect the majority of Spring applications, its impact is devastating for vulnerable applications.

How does the attack work?

Web applications often need a way to take in user data from requests, and map them into formats that the application can operate on. Spring’s RequestMapping functionality gives developers an easy way to map request parameters. There are different ways of mapping request parameters into Java data types, and one of them is to map request parameters into Java objects.

@Controller 
public class ExampleController {

    @RequestMapping("/signin")
    public String accountHandler(Account account) {
        return "You have signed in!";
    }

}

This code specifies that we have a controller named ExampleController. It will handle requests to the endpoint /signin and the endpoint should take in a parameter called account as the request parameter. The account request parameter will be mapped to an Account object. Now if we send a request to the web service:

http://example.com/signin?name=test

The service will map the request parameter into an Account object with the name field set to test. This is a convenient functionality, but it also introduces security issues. Because if an attacker sends a request parameter containing another Java object, Spring would attempt to map to the appropriate object type. When a request parameter is bound to a Java object like this, the attacker can use the request handler to access the class object. And from there, the attacker can access other valuable object types via the properties of class.

An attacker can achieve RCE by accessing objects of the right classes that can lead to the execution of arbitrary commands. From there, the exploit potential is endless. For example, the attacker can write a web shell onto the server and achieve RCE on the machine. I originally thought that the vulnerability was insecure deserialization, but it is instead a class injection issue similar to this Apache Struts vulnerability: https://nvd.nist.gov/vuln/detail/cve-2014-0094.

How do I remediate this issue?

Spring now has new versions that are not susceptible to the issue. You can find the releases here: https://spring.io/blog/category/releases. If you can upgrade, your application will be safe from the vulnerability. Users of the Spring framework 5.3.x should upgrade to 5.3.18+, and users of 5.2.x should upgrade to 5.2.20+. If you use Spring Boot, versions 2.5.12 and 2.6.6 depend on the safe Spring versions.

If you are not able to upgrade Spring, you can make use of one of these workarounds, both of which will close the attack vector:

Tomcat has released new versions that shut down the attack vector, so you can also upgrade to Tomcat versions 10.0.20, 9.0.62, or 8.5.78.
Since the exploit requires JDK 9+, downgrading to Java 8 is also an option.

However, since additional ways of exploiting this vulnerability may be found, upgrading Spring is the best course of action. Keep an eye on your application logs and review them for any unusual activity.

Please see Spring’s official announcement (https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement) for a more detailed discussion of the mitigation options and their tradeoffs.

Zero-days found in common dependencies like this one highlights the need to keep your dependencies updated and your software supply chain safe. You can use ShiftLeft CORE (https://www.shiftleft.io/) to help you identify the parts of your code where you’re using vulnerable versions of dependencies, and see whether the affected library is reachable from an untrusted source using Intelligent SCA.

Okta’s Breach Highlights Risk of Putting Crown Jewels in the Cloud

Vickie Li — Thu, 24 Mar 2022 19:10:24 +0000

By Arun Balakrishnan, Sr. Director Product Management

Photo by Markus Spiske on Unsplash

Identity credentials and source code are critical assets that can create major risks for your organization when exposed by breaches of third-party cloud service companies that provide identity management and software composition analysis. Know the risks of pushing your crown jewels into other services running in the cloud.

When allegations appeared on Twitter on March 22 that cloud identity services provider Okta had been breached, the tech world held its breath. CEO Todd McKinnon tweeted, “In late January 2022, Okta detected an attempt to compromise the account of a third-party customer support engineer working for one of our subprocessors. The matter was investigated and contained by the subprocessor.” Speculation continued to run wild on Twitter that the breach may have affected other companies, leading them to instruct employees to reset their passwords and identity information.

The caution is understandable. Okta is used by thousands of companies, including some of the world’s largest enterprises, for identity and access management of employee credentials used to log into and stay logged into all types of systems. Okta stores user identities, passwords, and other data for numerous critical systems including SaaS (CRM, finance, HR), PaaS (developer platforms, serverless computing, etc.) and IaaS (cloud servers, cloud networking systems, cloud databases).

As one of the world’s largest identity and access management (IAM) providers, Okta has always had a giant target on their back; any successful breach could yield a treasure trove of data that could be used to pivot to attacks on many other enterprises and their systems. Making matters worse, a known Ransomware group claimed credit for the breach. An IAM provider is a potential vector for Ransomware that would be particularly hard to address because IAM occupies such a position of trust in the technology stack and software supply chain.

Breaches happen, even to companies like Okta that put a priority on security. This breach could have happened to almost any company, and more of these types of breaches on key cloud-services companies are likely coming. Nation-state actors will target cloud-based providers of critical services like Okta in the future, and are likely already doing so now. The larger question that remains, however, is that of risk assumed by enterprises when pushing so much valuable information into a third-party cloud services providers environment.

Storing critically important identity data with a third-party vendor means that you are trusting that vendor with your crown jewels. But you may have limited visibility into risks facing your crown jewels. We don’t have a lot of details about the Okta breach. However, several security vulnerabilities recently disclosed would have allowed attackers to break out of supposedly secure containers and penetrate hosts in public compute clouds or major container orchestration platforms (Kubernetes). So even if the third-party vendor you trust with your crown jewels does everything right, your jewels still might not be safe — due to vulnerabilities in the cloud itself.

Okta claims that this breach resulted from problems with a third-party customer support engineering provider that appears to have had privileged access to some Okta systems. This is another potential risk faced by handing over crown jewels to a third-party; you don’t know who else has access to critical systems or to your sensitive information.

The source code of your applications hosted in your cloud is another crown jewel, and constitutes an added potential vector for supply chain attacks or serious breaches. Pushing your source code into multiple third-party services beyond your code repository provider increases the risks of compromise and expands the potential attack surface on both your source code and on your organization. Most CISOs and security practitioners do not realize that their software composition analysis tool or other cloud-based security scanners suck in all source code and process scans in the cloud before shipping results back.

There is an alternative approach that safeguards your source code. At ShiftLeft we elected to use an agent-based architecture that does not require us to upload all your source code into our systems. Instead of the code itself, we upload a graph representation of your code (we call it a code graph) with all sensitive information removed. (You can read more about how this works in this blog post — Why your code is a graph.)

By abstracting away your code and only pulling a graph that we can analyze, we ensure that attackers cannot steal your code via our tool or use our system to implant malicious unauthorized code into your applications and repositories. This is both more efficient and more secure. It minimizes the attack surface and exposure to supply chain attacks, breaches and other malicious activity.

Cloud computing has revolutionized the ways we build and run applications. It has enabled microservices and radically reduced costs of creating companies and technology stacks. Reverting to the old world where everything critical runs on your premises on servers and on hardware controlled directly by your team would be an absolute non-starter. That said, we need to acknowledge the potential risks of storing our most sensitive information in services we do not control. Then, we must make intelligent choices about how much risk we wish to undertake based on the potential impact of a breach. Every additional exposure of your crown jewels in a third-party service in the cloud is an expansion of your attack surface and should only occur after a conscious decision based on risks and benefits.

To get a demo of static analysis of custom code, open-source dependencies, and secrets, visit shiftleft.io/request-demo/.

Importance of Securing Software with a Zero Trust Mindset

Vickie Li — Tue, 22 Mar 2022 18:54:04 +0000

By Shinesa Cambric, Microsoft

This article is part of a series showcasing learnings from the Secure Software Summit.

Photo by Morgane Perraud on Unsplash

With the increase of supply chain attacks on everything from logging software like Log4J to takeovers of important JavaScript packages to compromises of network utility tools like SolarWinds, more and more organizations are recognizing the need to adopt a Zero Trust mindset. Zero Trust can improve security, reduce risks, and give organizations greater confidence in the integrity of their IT infrastructure and applications. To correctly set up a Zero Trust architecture, you need to understand what it actually takes to make systems Zero Trust.

Zero Trust Definition and Guiding Principles

Due to the rise of interest in Zero Trust, many misconceptions have built up that bear correcting.

Zero Trust is not a product or tool. In fact, there is no single tool you can apply to an environment to configure a full-stack Zero Trust implementation. Rather, Zero Trust is more about creating and refining an architecture and applying a consistent mindset.
Zero Trust is a never-ending journey. It is not a destination. You are never done and finished setting up Zero Trust, because software applications and IT environments continuously evolve. As your environment evolves, part of applying Zero Trust is going back and reassessing everything you are doing on a regular basis to ensure it complies with the principles of Zero Trust and covers all your software and technology assets.
Zero Trust does not mean your environment cannot be hacked or breached. On the contrary, under Zero Trust you constantly assume your environment has been breached. Zero Trust emphasizes building defensive layers that reduce the potential impact of any hack or breach and protect your assets and data.

So then what is Zero Trust?

Zero Trust is a framework and approach to security that assumes an organization’s IT assets — software, networks, data — are constantly at risk and must be secured through continuous verification of the identity, and the application of “least privilege” principles against any identity — human or machine — operating inside the IT environment. The core of Zero Trust is the lack of inherent trust for any identity as a managing approach to building more resilient applications and segmented risk.

Zero Trust has several key guiding principles:

Verify all identities all the time using a strong form of authentication — not just username and password. Specifically, use strong forms of authentication, such as multi-factor authentication. This principle applies not only to human users but also to all devices, bots, services, APIs, and partner systems accessing your environments. They must be verified every time they seek access and continuously while they are active inside your environment.
Always assume your environment has been breached. From this starting point, design your systems to reduce the blast radius and protect your assets as if an attacker is continuously present and moving within your environment to perform malicious acts — data exfiltration, system takeover, or other forms of abuse.
Always enforce least privilege for everyone and everything operating in your environment. Least privilege means limiting access only to systems, applications, data and services required for each task or interaction. To properly apply least privilege requires an understanding of expected behavior for applications and services, what they should and should not be doing, and also creating a sense of context. Applying least privilege with context is also dependent on assessing the security posture of any device, service, application, API or identity seeking access. Your Zero Trust policy enforcement engines should always interrogate inbound and ongoing connections to understand where an identity is coming from, what it is trying to connect to, and what is the current security posture of that identity. The answers to these questions should inform and shape least privilege permissions and provide additional insight into the risk of providing access.
Segment your environment to limit horizontal traversals or pass-through attacks. This is closely related to least privilege. The bottom line is, do not award any identities carte blanche access to your network, applications data, or infrastructure. Only allow identities access to the portions they truly need to perform their task, and only while they are performing that task.

How to Use Zero Trust to Secure Your Software and Software Supply Chain

The conceptual language of Zero Trust makes it sounds like an identity architecture and network security approach, floating above developers. For building and deploying secure applications, developers and DevOps teams must also adopt a Zero Trust mindset. In fact, there are clear synergies between Zero Trust and application security — and particularly with regard to Open Source Software (OSS). OSS developers may not spend sufficient time and energy on securing their code, because it is not what they like about writing software. For this reason, if you are including OSS code (and nested OSS libraries) in your applications and environments, then you have even more reason to apply Zero Trust frameworks.

A useful framing is to think about Zero Trust as applicable from the inside out, from the outside in, and to everything in between linking internal and external, applications and APIs, code and integration/deployment pipelines, and partner environments. Properly executed, Zero Trust allows your developers to go faster but also be safer. Additionally, it is useful to view Zero Trust through the CIA (Confidentiality, Integrity, Availability) lens. You should design your Zero Trust architecture to deliver these elements in priority that map to your business needs and there are a few ways to implement Zero Trust principles to the software supply chain.

Assume Your Code Has Been Breached And Is Insecure

Conduct a software asset inventory, looking at and categorizing all code running in your environment. This makes it easier for you to identify unauthorized changes and build more resilient applications. Set up mechanisms to detect unauthorized changes or anomalous software behaviors. You may want to apply these guidelines to close partners and their software and supply chain, as well. Remember that attacks may be from you, through you, or at you.

Manage Identities Carefully

Analyze and categorize user entitlements to set a baseline for “least privilege”. Conduct an inventory of all identities active in your environment to identify known identities (and quickly recognize unknown identities). Set up mechanisms to analyze behavior of identities to spot anomalies and create a baseline for context and behavioral privilege and access policy decisions. Include partner identities in this inventory: your greatest risk may come from unsecure partners that attackers use to gain access to your environment. The inventory should also include service and admin accounts. The inclination is to set their privileges and forget about them, often awarding broad access so as not to slow them down, and also potentially providing an unmonitored backdoor to attackers.

Inventory + Lock Down Integrations

Inventory your external and internal supply chain. This includes all dependencies in the code, services called, APIs exposed or accessed, and tooling for developing, hosting, integrating and building applications. For example, you may want to analyze your CI/CD pipeline and deployment environments through the lens of segmentation and least privilege to limit access depending on the pipeline stage. Put in place measures to segment the software environment and prevent lateral movement, like application sandboxing (but make sure to also tightly secure your sandboxes).

Code Assessment

Developers need to apply threat models to their code and adopt the mindset of considering what an attacker might access and what they might do should they compromise an application or the surrounding supply chain. Obviously, for all code — and especially OSS code — developers will need to continuously look for vulnerabilities and scan code using tools like Static Code Analysis and Dynamic Application Security Testing. Zero Trust means continuous verification of your own code, not just the entities using the code.

Zero Trust Takeaways

As we continue towards a future of more complex and integrated application environments and more usage of OSS code for core application functionality, the Zero Trust future becomes Zero Trust forever. It will simply become a way of life in application development. That said, we should keep in mind four key guiding principles.

Know Your Current State — Be aware of where your environment stands and your security posture, and direct and indirect impacts of security vulnerabilities.

Assume Breach — Be able to identify anomalous behavior and continuously consider what could be done by an attacker if your app was used maliciously?

Assess — Continuously assess the status and changes in the environment. Ask questions like: Who has what, when and where? Where do your integrated partners and vendors stand in terms of security?

Continuous Improvement — Periodically assess and compare your Zero Trust efforts against desired security posture and make improvements that align with objectives around confidentiality, integrity, and availability. Constantly guard against risk.

These four principles map over to five key takeaways that any developer, application security team, DevSecOps team or platform team can apply today and forever.

Review your environment with a Zero Trust lens
Recertify all identities continuously
Establish baseline app and identity behavior
Focus on detection and prevention of attacks
Design applications for resilience

Following these guiding principles and basic framings will ensure your Zero Trust journey creates strong defenses that help protect your development supply chain from the outside in, inside out, and with integrated partners.

To view this and other recorded sessions from the Secure Software Summit, visit: https://www.techstrongevents.com/Secure-Software-Summit.

To get a demo of static analysis of custom code, open-source dependencies, and secrets, visit shiftleft.io/request-demo/.

Secure Software Summit: The State of OSS Supply Chain Security

Vickie Li — Thu, 17 Mar 2022 13:02:54 +0000

By Dan Lorenc, Chainguard

This article is part of a series showcasing learnings from the Secure Software Summit

Photo by Reproductive Health Supplies Coalition on Unsplash

The Open Source Software (OSS) Supply Chain is under attack. As evidenced by the recent Log4Shell vulnerability, the OSS supply chain is increasingly a focus for attackers seeking to exploit weak links in security. A number of research reports have recorded a significant increase in so-called “next-gen software supply chain attacks” over the past decade. These attacks look to compromise key links in the software supply chain including source code, build systems, CI/CD tools, and code testing tools, among others. Next-gen attacks are happening across all languages, all types of software and are increasing with frequency. Common forms include typosquatting, malicious code injection and tool tampering (like the CodeCov incident). In 2021, 64% of organizations reported they were affected by software supply chain attacks, according to container security company Anchore.

The increasing wave of next-gen attacks has driven new regulations mandating specific steps to inventory and make more transparent the content of software applications and the software supply chain. Specifically, Executive Order 14082, issued by United States President Joseph Biden, mandates a long list of security practices, including the inclusion of a Software Bill of Materials (SBOM) with every application run by the U.S. Federal Government. The National Institute of Standards and Technology (NIST) is creating reference architectures and templates for application security as a result of the Executive Order. In other words, regulation on software security will likely impact every company that produces code or sells products running on code (including SaaS products).

To be clear, some of the problems experienced by the OSS software supply chain are not exclusive to open source. The recent supply chain attacks on Microsoft Exchange Server and the SunBurst attack on the SolarWinds network management tool targeted proprietary code bases. That said, OSS is produced and maintained very differently than proprietary software. This does result in some unique risks. In this chapter, we will cover those risks as well as some promising initiatives underway to address those risks.

Why Is the OSS Supply Chain A Juicy Target?

There are two primary reasons. One is omnipresence and the other is weakness. It is not an exaggeration to say that OSS is omnipresent. According to Sonatype, 98% of all code bases contain OSS. This is likely an underrepresentation. You simply cannot build code from scratch today without using OSS components. It is too labor intensive and expensive.The ubiquity of OSS makes the supply chain that creates, distributed and manages OSS an obvious target. At the same time, the widespread use of OSS translates into an increasing burden on companies to maintain, update and patch all OSS dependencies in their applications.

This is an impossible task; it is far easier to insert OSS code to solve an immediate problem than to, over time, make sure that code is updated and not vulnerable. For this reason, Sonatype estimated that 92% of all applications contain outdated or vulnerable code. We have seen the impact of this inability of organizations to maintain their OSS code through attacks like the one perpetrated against Apache Struts software run by credit reporting company Equifax, a breach that exposed the sensitive personal and financial information of hundreds of millions of Americans.

In recognizing that OSS is a fruitful channel for attacks, attackers have focused more specifically on the supply chain because it is often the weakest link. Elements of the supply chain reside in the gap between responsible organizations and may be less strictly policed or less actively secured. Continuous Integration / Continuous Deployment tools, OSS libraries that can easily access other systems, package managers and open source developer tooling are all components of the supply chain that are widely used but often the responsibility of many or of part-time maintainers who write and maintain code as an unpaid avocation.

OSS-Specific Challenges

The three key benefits of OSS each create unique security and supply chain challenges. Specifically, OSS is open, free and transparent.

The Two Sides of Open

Linus Torvalds said that many eyeballs make all bugs shallow. To a degree this is true. But what if those same eyes are looking for bugs to exploit rather than fix? Not everyone on the Internet is nice and many seek to exploit the fact that anyone with a GitHub account can contribute code to critical libraries. This attracts a lot of great contributors but also a lot of bad actors and bad behavior.

The behavior is often hidden or delayed. For example, we often see bad actors ask to contribute to projects or libraries run by single maintainers that are relatively popular and used by big applications. Often maintainers struggle to keep up with the demands of these projects. A bad actor will offer to help, submit a handful of good PRs and gain commit privileges to the repository. At this point, the bad actor will then stealthily insert malware, such as a cryptojacking script.

Free Puppy. Not Free Beer.

Free is a good price. There are no purchase orders. This makes it super easy to use. Free also serves as a great distribution strategy. However, sometimes free is not worth it. If an organization depends on an application and it becomes critical, they might require fast patching, better compliance and official support relationships. Free OSS comes with no guarantee and this can be a major liability. An application’s maintainers might be writing the code and applying fixes in their spare time on weekends because they have a full-time job. In fact, research has shown that a significant percentage of the critical software powering the Internet is maintained by volunteers; this was the source of the Heartbleed vulnerability in the OpenSSH encryption libraries.

Free code also may not be updated for years. If a vulnerability is disclosed, you may not be able to get permission to merge fixes you write. If the code is abandoned and the author no longer checks comments or requests, then you are stuck and may have no choice but to fork the project. A hard fork on short notice can cause chaos and its own problems. This is what happened with a popular Golang library called JWT Go, which made its way into dependency trees across the Golang ecosystem. JWT Go was even included in Kubernetes, one of the most popular and important open source projects. When a vulnerability to JWT Go emerged, everyone realized the maintainer had abandoned it. Multiple forked versions emerged with different patches for the same bug. Chaos ensued.

It is a common refrain to ask companies to fund volunteer maintainers. There are numerous programs for this, including GitHub Sponsors, Open Collective and Tidelift. These programs are helpful but not sufficient. You can’t just hand people a small amount of money and get more secure code and professional grade maintenance. Even if you offered full-time salaries, it might not translate into well supported, secure code.

The Illusory Benefit of Transparency

Transparency of OSS is real but the idea that this code is getting audited and reviewed constantly is an illusion. Yes, the source code is distributed and open. But the sheer quantity makes it impossible to review all the code you use. If you are using millions and tens of millions of lines of code, you don’t have time or sufficient eyeballs. Even if you are spending considerable resources on code review, it is still easy to miss problems and vulnerabilities and relatively simple for malicious contributors to projects to hide malware or other bad inclusions. Reviewing the source code also does eliminate all risks. When most OSS code is consumed, it is running as a package compiled by another entity or developer.

Further, there is no guarantee that the contents of the package comes from the same source code you audited. We have actually seen this attack often with package repositories like npm and Maven, where malicious actors insert tampered builds or take over packages and insert code that is not listed as part of the package.

The CodeCov incident is one of the more recent and egregious examples. This free service for checking the code coverage of unit tests used BASH script running inside of a CI server for installation. The script. Was compromised and attackers inserted malware that could steal code secrets and export them. Those secrets might be tokens used to publish packages in npm or Maven and exposing those secrets allowed attackers to then compromise those packages. In another example, a PHP server managing source code distribution for the PHP project was compromised and multiple commits injected malicious code into the source code repository. The incident was caught quickly but it demonstrated how attacker could tamper with source code directly, bypassing code review and security processes.

All Is Not Lost

Innovative efforts to better secure open source and its supply chain are gaining momentum. The SBOM is gaining acceptance and it is getting easier to automatically generate SBOMs from CI/CD pipelines or build systems. A new initiative to make it easy to cryptographically sign code, called Sigsource, aims to remove barriers to code signing; ubiquitous code signing would make it much harder to compromise the supply chain by attacking the source code provenance problem at its root. Lastly, the Open Source Security Foundation has garnered tens of millions of dollars in funding from major technology companies and it is in the process of spinning up mechanisms to issue grants and otherwise provide a more robust financial support mechanism for OSS. These developments point to a brighter future where the OSS Supply Chain is far more robust and companies can more easily audit, track and trust all the OSS dependencies in their applications and the full supply chain that moves OSS code from developer boxes up into production environments.

To view this and other recorded sessions from the Secure Software Summit, visit: https://www.techstrongevents.com/Secure-Software-Summit.

To get a demo of static analysis of custom code, open-source dependencies, and secreets, visit shiftleft.io/request-demo/.

Secure Software Summit Series: Focus on Preventative Readiness

Vickie Li — Tue, 08 Mar 2022 15:46:39 +0000

By Chetan Conikee

This article is part of a series showcasing learnings from the Secure Software Summit

Photo by Towfiqu barbhuiya on Unsplash

The connected world economy and the COVID-19 pandemic forced companies to accelerate digital transformation. Sophisticated cybercriminals have seized this forced acceleration to lay the groundwork for cyberwarfare. In reaction to recent attacks ranging from the SolarWinds breach to the recent Log4Shell exploits, many companies have quickly isolated and patched their systems. However, these reactive fixes do not work all the time; nor does the watch-and-wait approach. We must focus on re-engineering our organizational operations and culture to build and maintain preventative readiness. Companies and infrastructures need to be more resilient and secure from the start by building secure coding practices into the development process.

Secure Software Summit

At the beginning of 2022, ShiftLeft hosted the Secure Software Summit to provide industry experts and practitioners in the software development world a platform to discuss the latest methods and breakthroughs in secure coding and development practices — securing code earlier and better has become a discipline unto itself!

Some of the main takeaways from the event were:

SBOMs are in Your Future

In the very near future, organizations will need to better account for all the software and components of their applications, most likely via a software bill of materials (SBOM). The U.S. government has mandated barebones SBOMs, and we will soon see private industry start to mandate them, too, as part of procurement processes and auditing. This will enforce greater transparency and automate discovery of all dependencies and components in a way that, until now, was not common. Software composition analysis (SCA) will make this process easier and will become a standard part of the build process and the application development life cycle.

Securing Open Source is Critical

With Log4Shell and other open source software (OSS) supply chain attacks, application security teams must learn how to more intelligently update and secure the most critical OSS components and infrastructure. The average AppSec team needs to sift through massive piles of vulnerabilities and suggested security fixes — far more than they can possibly fix. We have seen record numbers of new vulnerability disclosures in each of the past four years. Proper prioritization based on whether a vulnerability can significantly impact an organization’s own applications and infrastructure is now essential amidst the blizzard of OSS dependencies that make up the modern application.

Digital Threats Impact the Real World

For many organizations in non-tech verticals such as health care that consume a lot of software, application security is at a crisis point — software vulnerabilities can literally put lives and our economy at risk. Researchers have correlated increases in mortality with hospitals running at higher levels of stress and capacity. When ransomware or other attacks impact health care institutions, the effect is the same as a massive pandemic flooding the ER: Doctors can’t use systems or equipment, care is rationed, patients are turned away and everything becomes more time-consuming. The net result is more deaths. Securing these systems against attacks becomes a matter of life or death — literally.

Culture Change Must Come First

Organizations will deploy new security architectures such as zero-trust, but these attempts will only be successful if AppSec and development teams change the culture around security. Organizations must recognize that the new normal is a state of constant renewal of trust. This will be challenging; constant renewal of trust requires entirely new infrastructure and a new mindset that can be hard on humans. It means implementing multifactor authentication in many more places and removing conveniences like administrative accounts that have blanket access to systems; it requires implementing least privilege practices. Software development will need to bake this constant renewal of trust into workflows and tooling to make it the new normal.

Shift From Reactive to Proactive

AppSec and development teams must shift from reactive approaches that tend to mobilize most resources during a breach or an incident and emphasize more proactive approaches such as better software security analysis and security chaos engineering. Knowing the unknown unknowns before they become a problem is key here. Netflix, which pioneered chaos engineering, recognized that stressing systems frequently and constantly to see how they behave under adverse conditions often yielded surprising insights that could improve security (and resilience, more broadly). As mentioned above, creating better ways to prioritize vulnerabilities and focus on the ones that are actually attackable shifts the task from a hopeless burndown to a targeted and proactive tactical exercise that is manageable.

To view this and other recorded sessions from the Secure Software Summit, visit: https://www.techstrongevents.com/Secure-Software-Summit.

To sign up for a free account for static analysis of custom code, open-source dependencies, and secreets, visit shiftleft.io/register.

Secure Software Summit Findings

Vickie Li — Thu, 03 Mar 2022 15:32:16 +0000

Shifting Security Left is a Work In Progress

What are the biggest concerns on the minds of application security and developers?

As part of the inaugural Secure Software Summit event, ShiftLeft polled conference participants on a wide range of topics related to application security, supply chain security, and the current cybersecurity threat environment. The poll included responses from a diverse array of hundreds of attendees, covering large technology and non-technology companies, government, academia, and industry experts. In this post, we’ll cover a few of the questions and comment on the findings. Overall, we found that the movement to shift security left to developers remained a work in progress, with some encouraging results and some room for improvement.

One-Third of Dev Teams Don’t Follow Secure Coding Practices

Securing coding practices are the foundation of any effort to write more secure applications. We asked, “How often does your dev team use secure software practices?” The good news? 65% of respondents indicated their teams use secure coding practices most or all of the time. That still leaves a hefty minority of teams that either uses secure coding practices only some of the time or almost never. Incomplete adoption of secure coding practices is concerning but understandable — AppSec and development teams require sufficient support, training, and budgets to implement secure coding practices and those are not always available.

DevSecOps Adoption Is Work in Progress

While DevSecOps may be widely discussed, it remains in the early stages of adoption. We asked, “How mature is your DevSecOps practice?” Over half have at least basic DevSecOps, but 41.7% are still in the learn-research phase or have no DevSecOps. The upshot? Lots of noise around DevSecOps but it’s still not widespread or a top priority for development teams.

Developer Education Remains the Biggest Barrier to Secure Code

Nearly one-third of respondents reported that all their developers have received training in secure software development. That said, lack of developer education is named the biggest obstacle to writing secure software by over 41% of poll respondents, and developers’ lack of security education was the most cited (67%) barrier to effectiveness. In other words, developer education is an area where the majority of software development teams could improve and the provision of training and education could go a long way towards more effective application security practices.

AppSec and Developer Mostly Collaborate — But Not Always

Collaboration prevails between AppSec and Developer teams, but often they still operate independently. We asked attendees about the relationship between AppSec and development teams in their organizations and how they worked together on security issues. The largest percentage of respondents — 45% — said the two teams collaborate. But 23% said security sets the rules and 26% said developers are free to act independently. When AppSec and developer teams are not collaborating and one team or the other sets the rules or determines policies and practices, this often drives gaps between the teams. The gap results in less effective application security practice, policy, and applications and makes it more difficult to effectively shift application security left.

Ransomware the Most Feared Attack

We wanted to take a pulse of what types of cyberattacks were the most feared by conference attendees. Not surprisingly, given the widespread ransomware attacks of the past year, this form of attack ranked as the most worrisome at over 38% of responses. Supply chain attacks like Log4Shell and SolarWinds — which are often closely related to, or are used as pivot points to launch ransomware attacks — came in second, at over 23%.

SCA is the favored Technology to Boost AppSec

With the rise in open source code to become the dominant player in application development, security pros view software composition analysis (SCA) tools as the most important arrow in their quiver against insecure code. We asked, “Which tools are most effective in reducing risk and helping you write more secure software?” and allowed respondents to rank SCA, static application security testing (SAST), dynamic application security testing (DAST), penetration testing, and code review in order. More than 50% of respondents ranked SCA as either the first or second most effective tool.

While the results are interesting, the question remains, if two-thirds use secure coding practices, and over half have at least basic DevSecOps why are attackers still so easily getting in?

We are grateful to all participants and can’t wait to see what they have to say at the next Secure Software Summit. Secure Software Summit brings together the world’s leading innovators, practitioners, and academics of secure software development to share and teach the latest methods and breakthroughs on secure coding and deployment practices designed to entertain, teach and enlighten. View the recordings of the event here: https://www.techstrongevents.com/Secure-Software-Summit.

Angular + React: Vulnerability Cheatsheet

Vickie Li — Tue, 01 Mar 2022 21:51:45 +0000

The most common vulnerabilities to look out for in Angular and React applications: template injection, XSSI, authentication bypass, and more.

Photo by Lautaro Andreani on Unsplash

Securing applications is not the easiest thing to do. An application has many components: server-side logic, client-side logic, data storage, data transportation, API, and more. With all these components to secure, building a secure application can seem really daunting.

Thankfully, most real-life vulnerabilities share the same root causes. And by studying these common vulnerability types, why they happen, and how to spot them, you can learn to prevent them and secure your application.

The use of every language, framework, or environment exposes the application to a unique set of vulnerabilities. The first step to fixing vulnerabilities in your application is to know what to look for.

Today, let’s take a look at six of the most common vulnerabilities that affect Angular and React applications, and how you can find and prevent them. The vulnerabilities I will cover in this post are:

Authentication bypass
Improper access control
Open redirects
Cross-site request forgery (CSRF)
Template injection
Cross-site script inclusion (XSSI)

Authentication Bypass

Authentication refers to proving one’s identity before executing sensitive actions or accessing sensitive data. If authentication is not implemented correctly on an application, attackers can exploit these misconfigurations to gain access to functionalities they should not be able to.

For instance, routing in Angular is usually done with the AppRoutingModule. Before directing users to sensitive routes in the application, you should check whether the user has been authenticated and authorized to access that resource.

https://medium.com/media/3118c0931f2696ee250275303952447d/href

For more details about how you can configure authentication properly in Angular and React, read this tutorial.

Take me back to the top.

Improper Access Control

Improper access control occurs anytime when access control in an application is improperly implemented and can be bypassed by an attacker. Authentication bypass issues are essentially a type of improper access control. However, access control comprises of more than authentication. While authentication asks a user to prove their identity: “Who are you?”, authorization asks the application “What is this user allowed to do?”. Proper authentication and authorization together ensure that users cannot access functionalities outside of their permissions.

There are several ways of configuring authorization for users: role-based access control, ownership-based access control, access control lists, and more. A good post to reference for implementing access control in Angular and React is here.

One common mistake that developers make is to perform authorization checks on the client side. This is not secure since client-side checks can be overridden by an attacker. These authorization checks must be performed using server-side code instead:

https://medium.com/media/ff07abdce53c65f86324428bcb1a461b/href

Take me back to the top.

Open Redirects

Websites often need to automatically redirect their users. For example, this

scenario happens when unauthenticated users try to access a page

that requires logging in. The website will usually redirect those users to the

login page, and then return them to their original location after they are authenticated.

During an open-redirect attack, an attacker tricks the user into visiting

an external site by providing them with a URL from the legitimate site that

redirects somewhere else. This can lead users to believe that they are still on the original site, and help scammers build a more believable phishing campaign.

https://medium.com/media/e65fe81e5a652928961f59a288cb38c6/href

There are many other ways of preventing open redirects, like checking the referrer of requests, or using page indexes for redirects. But because it’s difficult to validate URLs, open redirects remain a prevalent issue in modern web applications.

Take me back to the top.

Cross-Site Request Forgery

Cross-site request forgery (CSRF) is a client-side technique used to attack other users of a web application. Using CSRF, attackers can send HTTP requests that pretend to come from the victim, carrying out unwanted actions on a victim’s behalf. For example, an attacker could change your password or transfer money from your bank account without your permission.

Unlike open redirects, there is a surefire way of preventing CSRF: using a combination of CSRF tokens and SameSite cookies, and avoiding using GET requests for state-changing actions. As an example, Angular allows you to add anti-forgery tokens to HTTP requests using the HttpClientXsrfModule module:

https://medium.com/media/e14b6d09fb81c3b28cd9081681bcd1b3/href

Take me back to the top.

Template Injection

Web templates are HTML-like files that provide developers with a way to specify how a page should be rendered by combining application data with static templates. This functionality allows developers to insert dynamic content retrieved from a database or from an HTTP request into web pages.

Template injection refers to injection into web templates. Depending on the permissions of the compromised application, attackers might be able to use the template injection vulnerability to read sensitive files, execute code, or escalate their privileges on the system. For instance, here is an unsafe usage of an Angular template that allows attackers to inject code via URL hashes:

https://medium.com/media/a789db884d44dcc90494fa73203590d7/href

You should never directly concatenate user-provided input into templates. Instead, use the template engine’s built-in substitution mechanism to safely embed dynamic input:

https://medium.com/media/032940d81a02319a1d1e0f31cdf31cf5/href

Learn more about how template injection work and how to prevent them in Angular and React in this post.

Take me back to the top.

Cross-Site Script Inclusion

Cross-site script inclusion attacks are also referred to as XSSI. These attacks happen when a malicious site includes Javascript from a victim site to extract sensitive info from the script.

The same-origin policy (SOP) usually controls data access cross-origins. But the SOP does not limit javascript code, and the HTML tag is allowed to load Javascript code from any origin. This is an extremely convenient feature that allows JavaScript files to be reused across domains. But this feature also poses a security risk: attackers might be able to steal data written in JavaScript files by loading the JS files of their victims.

For example, imagine that a website stores and transports sensitive data for logged-in users via Javascript files. If a user visits a malicious site in the same browser, the malicious site can import that JavaScript file and gain access to sensitive information associated with the user’s session, all thanks to the user’s cookies stored in the browser. See an example of this vulnerability and learn how to prevent them in Angular and React here.

To avoid XSSI attacks, don’t transport sensitive data within JavaScript files. Here’s an example of how to safely load an API token in Angular using JSON files (which are limited by SOP):

https://medium.com/media/b308a0bb61f5c945b47685624b4c40c3/href

Take me back to the top.

What other security concepts do you want to learn about? I’d love to know. Feel free to connect on Twitter @vickieli7.

Now that you know how to fix these vulnerabilities, secure your Javascript application by scanning for these vulnerabilities! ShiftLeft CORE (https://www.shiftleft.io/shiftleft-core/) can find these vulnerabilities in your application, show you how to fix these bugs, and protect you from Javascript security issues.

Announcing the AppSec Ambassador Program

Vickie Li — Wed, 23 Feb 2022 19:10:37 +0000

Passionate about securing software? Become an AppSec Ambassador!

Photo by Emmanuel Ikwuegbu on Unsplash

Interested in helping developers write secure code from the start? ShiftLeft has launched a program to support you in the mission of helping your community write secure code.

We will be financially supporting conference speakers, content creators, and infosec influencers. Read on to find out more!

The ShiftLeft conference scholarship

Want to share your knowledge about SAST, SCA, and the secure development processes at a conference? Here at ShiftLeft, we are committed to helping developers improve code security and show developers how they can stay secure while continuously shipping cool products.

If you’d like to share your knowledge at a conference, we’ll help you with your conference abstract submission and fund your travels to an in-person event. Apply here for the scholarship: https://go.shiftleft.io/ambassador-conference-scholarship-program.

Your content, our support

We believe that security is a team effort between developers and security professionals, and a big part of securing the Internet is to share knowledge about security.

Create blog posts, videos, or live streams about topics related to application security and share them with your network! We will help promote your content on ShiftLeft’s accounts. Best pieces of educational content will also win a cash prize and exclusive ShiftLeft swag! Submit your content here: https://go.shiftleft.io/ambassador-content-program-fund-program.

Social competitions

Want to spread the word about the SAST and ShiftLeft? Post about @shiftleftInc, or #shiftleft to be entered into our social competition for a cash prize or exclusive swag. Start posting on Twitter and LinkedIn!

Join our ambassador network

Join the people defending applications on the frontlines, and stay in touch with the latest best practices in cybersecurity from your ambassador community. Join us here: https://discord.com/invite/5vj9YACAK3.

Node.js Vulnerability Cheatsheet

Vickie Li — Thu, 17 Feb 2022 22:11:10 +0000

25 vulnerabilities to look out for in Node JS applications: Directory traversal, prototype pollution, XSSI, and more…

Photo by Greg Rakozy on Unsplash

Today, let’s take a look at 25 of the most common vulnerabilities that affect Node.js applications, and how you can find and prevent them. The vulnerabilities I will cover in this post are:

Prototype pollution
Cross-site script inclusion (XSSI)
Insecure puppeteer settings
Security misconfiguration
Remote code execution (RCE)
SQL injection
Log injection
Mail injection
Template injection (SSTI)
Regex injection
Header injection
Session injection
Host header poisoning
Sensitive data leaks or information leaks
Authentication bypass
Improper access control
Directory traversal or path traversal
Arbitrary file writes
Denial of service attacks (DoS)
Encryption vulnerabilities
Mass assignment
Open redirects
Cross-site request forgery (CSRF)
Server-side request forgery (SSRF)
Trust boundary violations

Prototype Pollution

JavaScript is a unique language with many idiosyncrasies. One of these characteristics that set it apart from other mainstream languages is how objects are created in Javascript. Rather than being instantiated from classes, objects in Javascript inherit their properties from an existing object, or a “prototype”.

From a security perspective, this means that if an attacker can modify the prototype object and its properties, the prototype object can then affect the properties of all objects created from that prototype. This can lead to anything from cross-site scripting (XSS) attacks in the browser, to remote code execution (RCE) attacks in Node.js applications. Learn how these attacks work and how to prevent them here.

Take me back to the top.

Cross-Site Script Inclusion

Cross-site script inclusion attacks are also referred to as XSSI. These attacks happen when a malicious site includes Javascript from a victim site to extract sensitive info from the script.

Take me back to the top.

Insecure Puppeteer Settings

Insecure Puppeteer settings are another concern for Node applications. Puppeteer is a Node library that allows applications to control a headless build of Chrome or Chromium programmatically. Puppeteer helps automate user testing by mimicking activities that users can do in the browser. For example, you can automate the testing of form submissions, keyboard input, and many other user actions.

It’s important to sandbox the browser that Puppeteer runs, since the headless browser may have access to the disk or the internal network. Read how to do that in this post.

Take me back to the top.

Security Misconfiguration

Insecure Puppeteer settings are essentially a type of security misconfiguration. There are many other types of security misconfigurations that can compromise the security of Node applications. These can include using default credentials, using the wrong HTTP security headers, exposing sensitive system information via error messages, or disabling built-in safety measures. Learn about some of the most common security misconfigurations in Node applications here.

Take me back to the top.

Remote Code Execution

Remote code execution vulnerabilities, or RCE, are a class of vulnerabilities that happen when attackers can execute their code on your machine. One of the ways this can happen is through code injection vulnerabilities. They are a type of remote code execution that happens when user input is concatenated directly into executed code. The application cannot distinguish between where the user input is and where the executable code is, so the application executes the user input as code. The attacker will be able to execute arbitrary Javascript code through the application.

One of the easiest ways to prevent code injection is to implement robust input validation in the form of an allowlist. Read about how to implement allowlists and which Javascript methods you should avoid to prevent RCE here.

Take me back to the top.

Injection

Code injection is also a type of injection issue. Injection happens when an application cannot properly distinguish between untrusted user data and code. When injection happens in Javascript code, it leads to code injection. But injection vulnerabilities manifest in other ways too.

SQL Injection

In an SQL injection attack, for example, the attacker injects data to manipulate SQL commands. When the application does not validate user input properly, attackers can insert characters special to the SQL language to mess with the query’s logic, thereby executing arbitrary SQL code. Learn more about how these SQL injection attacks work here.

SQL injections allow attacker code to change the structure of your application’s SQL queries to steal data, modify data, or potentially execute arbitrary commands in the underlying operating system. The best way to prevent SQL injections is to use parameterized statements, which makes SQL injection virtually impossible. Learn about how to use parameterized statements in this article.

Take me back to the top.

Log Injection

You probably conduct system logging to monitor for malicious activities going on in your network. But have you ever considered that your log file entries could be lying to you? Log files, like other system files, could be tampered with by malicious actors. Attackers often modify log files to cover up their tracks during an attack. Log injection is one of the ways attackers can change your log files. It happens when the attacker tricks the application into writing fake entries in your log files.

Log injection often happens when the application does not sanitize newline characters “\n” in input written to logs. Attackers can make use of the new line character to insert new entries into application logs. Another way attackers can exploit user input in logs is that they can inject malicious HTML into log entries to attempt to trigger an XSS on the browser of the admin who views the logs.

To prevent log injection attacks, you need a way to distinguish between real log entries, and fake log entries injected by the attacker. One way to do this is by prefixing each log entry with extra meta-data like a timestamp, process ID, and hostname. You should also treat the contents of log files as untrusted input and validate it before accessing or operating on it.

Take me back to the top.

Mail Injection

Many web applications send emails to users based on their actions. For instance, if you subscribed to a feed on a news outlet, the website might send you a confirmation with the name of the feed.

Mail injection happens when the application employs user input to determine which addresses to send emails to. This can allow spammers to use your server to send bulk emails to users or enable scammers to conduct social engineering campaigns via your email address. Learn how attackers can achieve mail injection and how you can prevent it here.

Take me back to the top.

Template Injection

Template engines are a type of software used to determine the appearance of a web page. These web templates, written in template languages such as Jinja, provide developers with a way to specify how a page should be rendered by combining application data with web templates. Together, web templates and template engines allow developers to separate server-side application logic from client-side presentation code during web development.

Template injection refers to injection into web templates. Depending on the permissions of the compromised application, attackers might be able to use the template injection vulnerability to read sensitive files, execute code, or escalate their privileges on the system. Learn how template injection work and how to prevent them in this post.

Take me back to the top.

Regex Injection

A regular expression, or regex, is a special string that describes a search pattern in text. Sometimes, applications let users provide their own regex patterns for the server to execute or build a regex with user input. A regex injection attack, or a regular expression denial of service attack (ReDoS), happens when an attacker provides a regex engine with a pattern that takes a long time to evaluate. You can find examples of these patterns in my post here.

Thankfully, regex injection can be reliably prevented by not generating regex patterns from user input, and by constructing well-designed regex patterns whose required computing time does not grow exponentially as the text string grows. You can find some examples of these preemptive measures here.

Take me back to the top.

Header Injection

Header injection happens when HTTP response headers are dynamically constructed from untrusted input. Depending on which response header the vulnerability affects, header injection can lead to cross-site scripting, open redirect, and session fixation.

For instance, if the Location header can be controlled by a URL parameter, attackers can cause an open redirect by specifying their malicious site in the parameter. Attackers might even be able to execute malicious scripts on the victim’s browser, or force victims to download malware by sending completely controlled HTTP responses to the victim via header injection. More about how these attacks work here.

You can prevent header injections by avoiding writing user input into response headers, stripping new-line characters from user input (newline characters are used to create new HTTP response headers), and using an allowlist to validate header values.

Take me back to the top.

Session Injection

Session injection is a type of header injection. If an attacker can manipulate the contents of their session cookie, or steal someone else’s cookies, they can trick the application into thinking that they are someone else. There are three main ways that an attacker can obtain someone else’s session: session hijacking, session tampering, and session spoofing.

Session hijacking refers to the attacker stealing someone else session cookie and using it as their own. Attackers often steal session cookies with XSS or MITM (man-in-the-middle) attacks. Session tampering refers to when attackers can change their session cookie to change how the server interprets their identity. This happens when the session state is communicated in the cookie and the cookie is not properly signed or encrypted. Finally, attackers can “spoof” sessions when session IDs are predictable. If that’s the case, attackers can forge valid session cookies and log in as someone else. Preventing these session management pitfalls requires multiple layers of defense.

Take me back to the top.

Host Header Poisoning

Web servers often host multiple different websites on the same IP address. After an HTTP request arrives at an IP address, the server will forward the request to the host specified in the Host header. Although Host headers are typically set by a user’s browser, it’s still user-provided input and thus should not be trusted.

If a web application does not validate the Host header before using it to construct addresses, attackers can launch a range of attacks, like XSS, server-side request forgery _(_SSRF), and web cache poisoning attacks via the Host header. For instance, if the application uses the Host header to determine the location of scripts, the attacker could submit a malicious Host header to make the application execute a malicious script:

scriptURL = "https://" + properties.getProperty("host") + "/script.js";

Learn more about how Host header attacks work here.

Take me back to the top.

Sensitive Data Leaks

Sensitive data leak occurs when an application fails to properly protect sensitive information, giving users access to information they shouldn’t have available to them. This sensitive information can include technical details that aid an attack, like software version numbers, internal IP addresses, sensitive filenames, and file paths. It could also include source code that allows attackers to conduct a source code review on the application. Sometimes, the application leaks private information of users, such as their bank account numbers, email addresses, and mailing addresses.

Some common ways that an application can leak sensitive technical details are through descriptive response headers, descriptive error messages with stack traces or database error messages, open directory listings on the system’s file system, and revealing comments in HTML and template files. You can learn how to prevent data leaks in Node applications here.

Take me back to the top.

Authentication Bypass

Take me back to the top.

Improper Access Control

Authentication bypass issues are essentially improper access control. Improper access control occurs anytime when access control in an application is improperly implemented and can be bypassed by an attacker. However, access control comprises of more than authentication. While authentication asks a user to prove their identity: “Who are you?”, authorization asks the application “What is this user allowed to do?”. Proper authentication and authorization together ensure that users cannot access functionalities outside of their permissions.

Take me back to the top.

Directory Traversal

Directory traversal vulnerabilities are another type of improper access control. They happen when attackers can view, modify, or execute files they shouldn’t have access to by manipulating file paths in user-input fields. This process involves manipulating file path variables the application uses to reference files by adding the ../ characters or other special characters to the file path. The ../ sequence refers to the parent directory of the current directory in Unix systems, so by adding it to a file path, you can often reach system files outside the web directory.

Attackers can often use directory traversals to access sensitive files like configuration files, log files, and source code. To prevent directory traversals, you should validate user input that is inserted into file paths, or avoid direct references to file names and use indirect identifiers instead, read this tutorial for more information.

Take me back to the top.

Arbitrary File Writes

Arbitrary file write vulnerabilities work similarly to directory traversals. If an application writes files to the underlying machine and determines the output file name via user input, attackers might be able to create arbitrary files on any path they want, or overwrite existing system files. Attackers might be able to alter critical system files like password files or log files, or add their own executables into script directories.

The best way to mitigate this risk is by not creating file names based on any user input, including session information, HTTP input, or anything that the user controls. You should control the file name, path, and extension for every created file. For instance, you can generate a random alphanumeric filename every time the user needs to generate a unique file. You can also strip user input of special characters before creating the file. Learn about these techniques in this post.

Take me back to the top.

Denial of Service Attacks

Denial of service attacks, or DoS attacks, disrupts the target machine so that legitimate users cannot access its services. Attackers can launch DoS attacks by exhausting all the server’s resources, crashing processes, or making too many time-consuming HTTP requests at once.

Denial of service attacks are hard to defend against. But there are ways to minimize your risk by making it as difficult as possible for attackers. For instance, you can deploy a firewall that offers DoS protection, and prevent logic-based DoS attacks by setting limits on file sizes and disallowing certain file types. You can find more detailed steps on preventing denial of service attacks here.

Take me back to the top.

Encryption Vulnerabilities

Encryption issues are probably one of the most severe vulnerabilities that can happen in an application. Encryption vulnerabilities refer to when encryption and hashing are not properly implemented. This can lead to widespread data leaks and authentication bypass through session spoofing.

Some common mistakes developers make when implementing encryption on a site are:

Using weak algorithms
Using the wrong algorithm for the purpose
Creating custom algorithms
Generating weak random numbers
Mistaking encoding for encryption

A guide to encryption security can be found here.

Take me back to the top.

Mass Assignment

“Mass assignment” refers to the practice of assigning values to multiple variables or object properties all at once. Mass assignment vulnerabilities happen when the application automatically assigns user input to multiple program variables or objects. This is a feature in many application frameworks designed to simplify application development.

However, this feature sometimes allows attackers to overwrite, modify, or create new program variables or object properties at will. This can lead to authentication bypass, and manipulation of program logic. To prevent mass assignments, you can disable the mass assignment feature with the framework you are using, or use a whitelist to only allow assignment on certain properties or variables.

Take me back to the top.

Open Redirects

To prevent open redirects, you need to make sure the application doesn’t redirect users to malicious locations. For instance, you can disallow offsite redirects completely by validating redirect URLs. There are many other ways of preventing open redirects, like checking the referrer of requests, or using page indexes for redirects. But because it’s difficult to validate URLs, open redirects remain a prevalent issue in modern web applications.

Take me back to the top.

Cross-Site Request Forgery

Unlike open redirects, there is a surefire way of preventing CSRF: using a combination of CSRF tokens and SameSite cookies, and avoid using GET requests for state-changing actions.

Take me back to the top.

Server-Side Request Forgery

SSRF, or Server Side Request Forgery, is a vulnerability that happens when an attacker is able to send requests on behalf of a server. It allows attackers to “forge” the request signatures of the vulnerable server, therefore assuming a privileged position on a network, bypassing firewall controls, and gaining access to internal services.

Depending on the permissions given to the vulnerable server, an attacker might be able to read sensitive files, make internal API calls, and access internal services like hidden admin panels. The easiest way to prevent SSRF vulnerabilities is to never make outbound requests based on user input. But if you do need to make outbound requests based on user input, you’ll need to validate those addresses before initiating the request.

Take me back to the top.

Trust Boundary Violations

“Trust boundaries” refer to where untrusted user input enters a controlled environment. For instance, an HTTP request is considered untrusted input until it has been validated by the server.

There should be a clear distinction between how you store, transport, and process trusted and untrusted input. Trust boundary violations happen when this distinction is not respected, and trusted and untrusted data are confused with each other. For instance, if trusted and untrusted data are stored in the same data structure or database, the application will start confusing the two. In this case, untrusted data might be mistakenly seen as validated.

A good way to prevent trust boundary violation is to never write untrusted input into session stores until it is verified. See an example of this mitigation implemented here.

Take me back to the top.

What other security concepts do you want to learn about? I’d love to know. Feel free to connect on Twitter @vickieli7.

Now that you know how to fix these vulnerabilities, secure your Node.js application by scanning for these vulnerabilities! ShiftLeft CORE (https://www.shiftleft.io/shiftleft-core/) can find these vulnerabilities in your application, show you how to fix these bugs, and protect you from Node.js security issues.

Networking and growing your career in infosec with Vandana Verma

Vickie Li — Tue, 15 Feb 2022 16:02:06 +0000

OWASP leader Vandana’s tips for navigating your career in infosec

Our guest today, Vandana, holds a lot of impressive titles. She is the Chair of the OWASP Global Board of Directors, and she also leads multiple infosec Diversity Initiatives like InfosecGirls.

But how did she get from an infosec newbie to the leader of OWASP and the keynote speaker at multiple conferences? Why does she encourage people to get into cybersecurity regardless of their background and qualifications? And how did she overcome the fear of public speaking and networking in tech? Tune into this episode to hear her story!

https://medium.com/media/80170ca33a92a64e763a88ecba434ba7/href

Vandana is Security Solutions Architect at Snyk. She is the chair of the OWASP Global Board of Directors and leads multiple diversity initiatives like InfosecGirls, WoSec, and InfosecKids. She has been a speaker at numerous security conferences including Global OWASP AppSec, BlackHat, BSides, OWASP, and more.

Source and Sinks is a technology-focused podcast. We talk about the business, people, products, and culture of technology — with a security twist. Listen to more Sources and Sinks here:

‎Sources and Sinks on Apple Podcasts

Malware Evolves to Present New Threats to Developers

Vickie Li — Thu, 10 Feb 2022 21:58:37 +0000

Malware, or code written for malicious purposes, is evolving.

Photo by Cécile Brasseur on Unsplash

Software developers face new threats from malicious code as their tools and processes have proven to be an effective and lucrative threat vector. Traditionally, software developers have protected themselves from malicious code like everyone else — by securing their devices, keeping programs updated, and following good security practices. However, recent attacks by advanced persistent threat (APT) groups have shown these longstanding security practices are no longer sufficient. To understand the new dangers malicious code poses to developers, it helps to take a brief look back at the history of malware.

Malicious Code: Origins

Malicious code, or malware, is intentionally written to disrupt, damage, or otherwise inflict undesirable effects on a target system. Often, like in the case of ransomware, malicious code both benefits the attacker and harms the victim. In other cases, like wipers, malicious code simply destroys data or inflicts other harm upon the target system. It is important to mention that intent drives the creation of malicious code for a specific purpose. This distinguishes it from software vulnerabilities which leave a system open for exploitation unintentionally.

The first known instance of malware was the relatively benign Creeper Worm created by Robert H. Thomas in 1971. The worm could move between hosts via the ARPANET but did not self-replicate until a later update by Ray Tomlinson. Creeper Worm laid the intellectual groundwork for larger experiments in self-replicating software, like the infamous Morris Worm of 1988. The Morris Worm, ostensibly created to map the internet, ultimately brought down roughly 6000 systems. The author, Robert Morris, became the first person convicted under the Computer Fraud and Abuse Act of 1986. He was fined over $10,000 and sentenced to three years of probation.

Early Internet

As the ARPANET evolved into the internet, connecting exponentially more computers throughout the world, malicious code likewise made advances. The simple worms of the earlier era paved the way for threats more familiar to modern-day users, including:

Adware
Ransomware
Backdoors
Trojans/Spyware
Logic bombs

As new forms of malicious code appeared, an antivirus (AV) industry arose to tackle the challenge of detecting and responding to cyber threats. These early companies innovated various strategies to identify and stop attacks. One effective method involved generating unique file hashes, or signatures, of malicious code that could be cataloged for rapid identification. Unfortunately, making changes to malicious code could likewise change its signature — creating an indefinite cat-and-mouse game between attackers and defenders.

Other cybersecurity measures attempted to prevent the travel of malicious code or nullify its effects. Network control measures like firewalls, secure socket layer (SSL), and data loss prevention (DLP) tools sought to outmaneuver malicious code rather than directly combat it. While software developers faced no additional risk from malware during this time, trouble was lurking just around the corner.

The Cloud Era

In the mid-2000s, Amazon Web Services (AWS) launched a suite of business infrastructure services hosted in the cloud. Their lead was soon followed by Google, Microsoft, and others, who collectively ushered in the era of cloud-based services. Businesses and organizations adopted cloud computing for a number of reasons including cost savings, increased collaboration, loss prevention, and automatic software updates. However, the shift to cloud computing was not entirely without drawbacks. The practice of using remote resources and storage introduced a level of ambiguity to security responsibilities.

Ultimately, security responsibilities related to infrastructure were largely assumed by cloud providers while customers remained in charge of protecting their own data and on-prem resources. However, this arrangement left other responsibilities ill-defined, including endpoint protection, application-level controls, and identity and access management. Threat actors quickly realized the shared-responsibility model used by cloud services presented ample opportunities for exploitation. In areas where security responsibilities overlap, it only required one mistake by the cloud provider or the customer to facilitate a breach.

As more organizations migrated to the cloud, threat actors followed close behind. In 2019 attacks on cloud services doubled, demonstrating a significant shift in the focus of APT groups. More concerning, threat groups adopted the successful service model of the cloud and leveraged it to their benefit through offerings like Ransomware-as-a-Service (RaaS). Cloud-based ransomware services offer threat groups and their customers several advantages over traditional cyber attacks. For example, they provide a way for non-technical people to launch ransomware campaigns. They also provide cover for malicious actions from governments and organizations by introducing a layer of separation between the attackers and the attack source.

Modern Malicious Code Sets Sights on Supply Chain

RaaS offers one example of threat actors successfully adopting technology to spread malicious code, but the shift to cloud services introduced other dangers. Organizations that rely on cloud services explicitly trust their service providers. This trust allows managed service providers (MSPs) to push software updates to numerous customers without going through stringent security processes. Thus, an attacker who injects malicious code into an update pushed by an MSP can effectively compromise each client receiving the update.

This style of attack on the software supply chain is exactly what the world witnessed during the Solar Winds breach in 2019. Attackers gained access to the software repository for Orion, a monitoring and management tool for Solar Winds. The threat actors embedded malicious code into an Orion update, which Solar Winds then released to tens of thousands of customers. This technique lets attackers deliver malicious code to thousands of systems through a vector that security measures routinely ignore — a trusted vendor.

Similarly, Kaseya suffered a supply chain attack from the REvil threat group in July 2021. Kaseya provides Virtual System Administration (VSA) software to MSPs, who in turn offer cloud services to multiple customers. REvil compromised the VSA software and used it as a vehicle to launch ransomware attacks against approximately 1500 businesses. These attacks, like those affecting Solar Winds, relied on abusing the automatic software update system to spread malicious code.

Supply chain attacks are not limited to global IT service providers. The open-source community has fallen victim to these attacks as well. Open-source code is used in perhaps 96% of apps, and has long been known to be a source of vulnerabilities. In October 2021 the popular UA-parser.js project was subverted by a threat actor who managed to publish three versions containing malicious code. In this case the attacker spent time infiltrating the open-source organization and slipping test code into various builds before ultimately inserting malicious code.

Takeaway for Developers

Software developers are no longer facing the same threats from malicious code as everyone else. The nature of their work makes them targets for contemporary threat actors who seek to corrupt their tools, systems, and trustworthiness. Fortunately, there are some effective steps devs and organizations can take to protect themselves from propagating supply chain attacks:

Developers cannot assume any code remains secure without testing. Consider running next-gen static application security testing as can be found in ShiftLeft CORE, and intelligent software composition analysis (I-SCA) on all code, including updates and open-source components.
Teams creating applications for enterprise customers can be prime targets for supply chain attacks. If they have any concern that their code has been inadvertently exposed to outsiders either through a repo misconfiguration or an encounter with an untrusted party, they should consider an automation-enabled audit by AppSec experts like ShiftLeft Illuminate or if they have in-house experts should consider purchasing an advanced tool like ShiftLeft Ocular.
Organizations should follow the principles of least privilege, restricting accounts to only being able to use necessary resources.
Organizations should consider adopting a Zero Trust framework, which reduces threat vectors by ensuring interactions only occur between trusted entities.

Simply put, developers not only have to guard themselves against being attacked by malicious code, but also ensure they are not unknowingly spreading malware. For more information on effective ways to keep your code secure, visit shiftleft.io.

What is insecure deserialization?

Vickie Li — Tue, 08 Feb 2022 17:39:19 +0000

Getting to know a critical vulnerability that affects Java, Python, and other common programming languages.

Photo by Jiawei Zhao on Unsplash

As a penetration tester, there are few vulnerabilities that fascinate me more than insecure deserialization.

Insecure deserialization bugs are very critical vulnerabilities: an insecure deserialization bug will often result in remote code execution, granting attackers a wide range of capabilities on the application.

Defending against deserialization vulnerabilities is also extremely difficult. How an application can defend against these vulnerabilities varies and depends greatly on the programming language, libraries, and serialization formats used. Because of this, there is no one-size-fits-all solution. Today, let’s dive into the ins and outs of insecure deserialization vulnerabilities.

What is object serialization?

In order to understand why “deserialization” can be insecure, you’ll need to first understand how applications serialize and deserialize objects.

Serialization is a process during which an object in a programming language (say, a Java or Python object) is converted into a format that can be saved to the database or transferred over a network. Whereas deserialization refers to the opposite: it’s when the serialized object is read from a file or the network and converted back into an object.

Basically, when you need to store an object or transfer it over the network, you serialize it to pack it up.

object ---serialization---> transportable format of the object

When you need to use that data again, you deserialize and get the data that you want.

transportable format of the object ---deserialization--> object

Many programming languages support the serialization and deserialization of objects, including Java, PHP, Python, and Ruby.

How deserialization becomes “insecure”

Insecure deserialization is a type of vulnerability that arises when an attacker can manipulate the serialized object and cause unintended consequences in the program’s flow.

Object value manipulation

For example, if a serialized object is used as a cookie for access control, you can try changing the usernames, role names, and other identity markers that are present in the object and re-serialize it and relay it back to the application.

Take a look at this PHP serialized object. It represents a “User” object and contains properties such as “username” and “status”. If the application assumes that serialized objects are safe and used them without verification, attackers might be able to tamper with the serialized object to manipulate object properties.

O:4:"User":2:{s:8:"username";s:6:"vickie";s:6:"status";s:9:"not admin";}

In this serialized string, you can try to change the value of “status” to “admin”, and see if the application grants you admin privileges.

O:4:"User":2:{s:8:"username";s:6:"vickie";s:6:"status";s:5:"admin";}

Serialization does not provide any form of data integrity protection. It is simply a way of packaging data for transmission.

Remote code execution (RCE)

If the application does not handle deserialization safely, an attacker might even be able to execute malicious code!

In Python, serialization is done through “Pickles”. The following code snippet will print the pickled representation of the Person object “new_person” (this process is called pickling):

class Person:
  def __init__ (self, name):
    self.name = name

new_person = Person("Vickie")
print(pickle.dumps(new_person))

The pickled object would look like this:

b'\x80\x03c __main__ \nPerson\nq\x00)\x81q\x01}q\x02X\x04\x00\x00\x00nameq\x03X\x06\x00\x00\x00Vickieq\x04sb.'

Python allows objects to declare how they should be pickled via the reduce method. This method takes no argument and returns either a string or a tuple. When returning a tuple, the tuple will dictate how the object will be reconstructed during unpickling:

(callable object that will be called to instantiate the new object, a tuple of arguments for that callable object)

This means that if you define a reduce method in an object, the pickled object could be instantiated as something else during unpickling. Now if the attacker constructs a malicious object like this:

class Malicious:
  def __reduce__ (self):
    return (os.system, ('cat /etc/shadow',))

fake_object = Malicious()
session_cookie = base64.b64encode(pickle.dumps(fake_object))

They can make the victim application execute arbitrary code after unpickling the fake object:

os.system('cat /etc/shadow')

You can learn in detail how attackers exploit Java deserialization vulnerabilities here, insecure deserialization vulnerabilities in Python here, and PHP unserialize vulnerabilities here.

Preventing insecure deserialization vulnerabilities

To prevent insecure deserialization, you need to first keep an eye out for patches and keep dependencies up to date. Many insecure deserialization vulnerabilities are introduced via dependencies, so make sure that your third-party code is secure. You can automate this process by employing a software composition analysis (SCA) tool.

If you are implementing the deserialization functionality yourself, make sure not to deserialize any data tainted by user input without proper checks. If deserialization is absolutely necessary, restrict deserialization to a small list of allowed classes (use a whitelist). You can learn how to deserialize objects safely to prevent insecure deserialization here. ShiftLeft’s vulnerability fix database contains detailed code samples for safely implementing deserialization in Java, Python, C#, Go, JavaScript, and Scala.

It also helps to utilize simple data types, like strings and arrays instead of objects that need to be serialized on transport. To prevent the tampering of serialized cookies, keep the session state on the server instead of relying on user input for session information.

What other security concepts do you want to learn about? I’d love to know. Feel free to connect on Twitter @vickieli7.

Continuously scanning your codebase for insecure deserialization issues is the best way to prevent them. ShiftLeft CORE can find insecure deserialization vulnerabilities in your application and protect you from malicious attacks.