staging-devopsy.kinsta.cloud

Tag: application vulnerability

  • Critical Vulnerability Discovered in Open Source Backstage Platform

    Critical Vulnerability Discovered in Open Source Backstage Platform

    Oxeye today disclosed that it has discovered a critical vulnerability in the open source Backstage software used to build developer portals. Backstage was originally created by Spotify.

    A 1.5.1 update to the Backstage platform remediated a sandbox escape vulnerability that can occur via a third-party Scaffolder plug-in that could be used to conduct unauthenticated remote code execution (RCE).

    Oxeye CTO Ron Vider said Oxeye worked with Spotify to responsibly disclose the issue and enabled a patch to be created prior to the disclosure of the vulnerability, which Spotify gave a 9.8 out of 10 severity rating.

    Backstage is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF), but is already widely used by organizations such as American Airlines, Netflix, Splunk, Fidelity Investments, Epic Games and Palo Alto Networks, as well as by Spotify.

    The vulnerability is another example of a potential template-based attack through which run shell commands can be manipulated to inject malware into an application development environment.

    In general, separating the logic from the presentation layer as much as possible can greatly reduce exposure to the most dangerous template-based attacks.

    Vider said Oxyeye is focusing its vulnerability research on cloud-native platforms such as Backstage that are generally being used to build modern applications based on a microservices architecture. It’s not clear to what degree organizations have transitioned away from more monolithic approaches to building applications, but it’s clear that a much larger percentage of applications are now being constructed using microservices.

    Cybercriminals, of course, are targeting these platforms as part of a sustained effort to compromise software supply chains in the hope that the malware they inject will find its way into multiple downstream applications. Those attacks, in turn, are convincing more organizations to embrace DevSecOps best practices to better ensure the integrity of their software supply chains. The challenge is many of those attacks are being aimed at open source software projects that don’t always have enough resources to quickly develop a patch in the event a zero-day vulnerability is disclosed.

    While it’s impossible to know the extent to which cybercriminals are already exploiting vulnerabilities in DevOps platforms, the level of cybersecurity scrutiny being applied has dramatically increased in the wake of a series of high-profile breaches. The Biden administration has even gone so far as to issue an executive order requiring federal agencies to better secure their software supply chains. As a result, DevOps teams should expect there to be a lot more DevOps platform vulnerability disclosures in the months ahead, and that those vulnerabilities will require immediate patching.

    Like it or not, software supply chains are going to become more secure. The only thing left to be determined is the level of pain that will be experienced as more vulnerabilities are discovered in the DevOps platforms that were used to construct them.

  • ShiftLeft Report Reveals State of Application Security

    ShiftLeft Report Reveals State of Application Security

    A report published today by automated application security testing platform ShiftLeft found only one in three applications has an attackable vulnerability. The report also found organizations that prioritized their remediation efforts based on the level of actual threat are fixing 76% of those vulnerabilities within two sprints lasting 12 days, on average.

    Based on millions of scans performed in the last year using the ShiftLeft platform to identify vulnerabilities, organizations have reduced the number of vulnerabilities they need to address by 97% on a year-over-year basis, the report found.

    In addition, the report noted that the average median scan time is only 90 seconds, which helped drive an overall 68% increase in daily scans year-over-year. Overall mean-time-to-remediate (MTTR) has dropped by 37%, the report also found.

    ShiftLeft CEO Manish Gupta said given the increased number of vulnerabilities, it’s more critical than ever for organizations to focus their remediation efforts on those that can be exploited within their IT environment. For example, the report found that only 4% of all Log4j instances discovered in the IT environments analyzed were vulnerable. Rather than spending weeks looking for every instance, Gupta said IT teams would be much better off focusing their efforts on the instances that might actually be exploited.

    The challenge is that not enough organizations have a way to score vulnerabilities based on the risk they represent to the business, Gupta added.

    While there is a lot more focus on adopting DevSecOps best practices in the wake of a series of high-profile breaches of software supply chains, the ShiftLeft report made it clear that presenting developers with a long list of potential vulnerabilities is counterproductive. The bulk of vulnerabilities that are being discovered are not actually attackable, noted Gupta.

    That doesn’t mean application security doesn’t need to improve, but it is clear that a lot of time and effort is being wasted, added Gupta.

    In theory, at least, as the cultural divide been application development teams and cybersecurity teams continues to narrow, the overall ability to prioritize remediation efforts should improve. The first step toward achieving that goal is making it easier to identify what percentage of the application attack surface is really vulnerable. Otherwise, developers presented with a long list of theoretical vulnerabilities will continue to prioritize developing new features and capabilities versus remediating vulnerabilities.

    One way or another, vulnerability remediation issues will soon come to a head. In the wake of an executive order from the Biden administration to improve overall application security within federal IT environments, many organizations will adopt similar policies and processes. Developers, naturally, will inevitably either push back or do an end-run around processes they deem too onerous. Rather than allowing a stalemate to occur, Gupta said savvy DevOps teams will invest more time in identifying the critical vulnerabilities that need to be addressed before cybercriminals exploit them.

    The issue, of course, is that cybercriminals are getting more adept at discovering and exploiting those very same vulnerabilities.

  • WhiteSource Offers Free Spring4Shell Vulnerability Tool

    WhiteSource Offers Free Spring4Shell Vulnerability Tool

    WhiteSource has launched a free command-line interface (CLI) tool that detects vulnerable open source Spring4Shell vulnerabilities (CVE-2022-22965) that are impacting Java applications built using the Spring development framework.

    Susan St. Clair, director of product management for WhiteSource, said the WhiteSource Spring4Shell Detect tool is similar to the tool the company made available earlier this year to detect Log4Shell vulnerabilities in Java applications. It provides an exact path to direct and indirect dependencies along with how to find a fixed version of the Spring framework to accelerate remediation efforts.

    Spring4Shell is yet another zero-day vulnerability that has been given a 9.8 severity score. As a result, DevOps and cybersecurity teams are now racing to update applications impacted by this vulnerability before cybercriminals can exploit it. The Spring4Shell vulnerability enables remote code execution (RCE), and the Java applications impacted employ versions 5.3.17 or 5.2.19 of the Spring framework and version 9 or higher of the Java Development Kit (JDK).

    The vulnerability allows an attacker to remotely execute arbitrary code on the target server. It allows attackers to abuse a RequestMapping annotation that maps incoming HTTP requests into their appropriate handler functions. The vulnerable condition occurs when RequestMapping is used in conjunction with traditional Java objects as the handler parameter. Such an attack might allow access to all website internal data, including any database. It might also allow access to additional internal resources to gain more permissions or to pivot to other parts of the internal network.

    It’s not clear how pervasively Spring4Shell might impact Java applications compared to Log4Shell vulnerability that affected a logging tool, but more security researchers are looking for RCE vulnerabilities within Java application environments. Organizations now will need to determine whether to maintain legacy applications that might be subject to more zero-day vulnerability discoveries or replace them with newer applications that are developed in a programming language that might be more secure. There is, of course, no guarantee a new application will be more secure than a legacy application, but the chances are good a modern application will have fewer vulnerabilities than a legacy application simply because the underlying programming tools and platforms are more advanced from a security perspective.

    In the meantime, DevOps teams likely will be looking for instances of Spring4Shell vulnerabilities for months to come. DevOps teams that have access to a software bill of materials (SBOM) naturally will be able to find those instances more easily than organizations that don’t. However, the percentage of organizations that have SBOMs is still comparatively low. However, as zero-day vulnerabilities become a larger security issue, SBOMs are being implemented more widely as organizations review their software supply chains.

    Whatever the path toward ensuring application security ends up being the level of scrutiny being applied to application development and deployment, processes will in the months ahead accelerate the adoption of best DevSecOps practices across organizations large and small, whether they like it or not.