The high risk associated with newly discovered vulnerabilities in the highly popular Apache Log4j library – CVE-2021-44228 (also known as Log4Shell) and CVE-2021-45046 – has led to a security frenzy of unusual scale and urgency. Developers and security teams are pressed to investigate the impact of Log4j vulnerabilities on their software, revealing multiple technical challenges in the process.

Following the Dec. 9, 2021, announcement of the Log4j vulnerability, CVE 2021-44228, CrowdStrike Falcon OverWatch™ has provided customers with unrivaled protection and 24/7/365 vigilance in the face of heightened uncertainty. To OverWatch, Log4Shell is simply the latest vulnerability to exploit — a new access vector among a sea of many others.

Another — though unlikely — vulnerability was discovered in Log4j’s latest versions: CVE-2021-44832. This is an Arbitrary Code Execution exploit using, yet again, the now infamous JNDI functionality. The vulnerability lets an attacker with control over the Log4j configuration set a malicious datasource for the JDBC (Java DataBase Connectivity API) appender. The datasource refers to an attacker-controlled JNDI URI that will execute arbitrary code on the application using Log4j.

A new vulnerability was discovered in the Apache Log4j library. Tracked as CVE-2021-44832, this bug may allow arbitrary code execution in compromised systems when the attacker has permissions to modify the logging configuration file. CVE-2021-44832 has received a CVSS score of 6.6 out of 10, and it affects all versions of Log4j from 2.0-alpha7 to 2.17.0, excluding 2.3.2 and 2.12.4. This is the fourth Log4j vulnerability addressed by Apache in December 2021.

As previously predicted to unfold, at approximately 7:35 PM GMT, 28th of December 2021, another security vulnerability impacting the Log4j logging library was published as CVE-2021-44832. This new CVE-2021-44832 security vulnerability is affecting versions up to 2.17.0, which was previously thought to be fixed. This vulnerability is similar in nature to CVE-2021-4104 which affected the 1.x branch of Log4j.

The discovery of the Log4Shell vulnerability in the ubiquitous Apache Log4j package is a singular event in terms of both its impact and severity. Over 1 million attack attempts exploiting the Log4Shell vulnerability were detected within days after it was exposed, and it may take years before we see its full impact.

The Log4J library is one of the most widely-used logging libraries for Java code. On the 24th of November 2021, Alibaba’s Cloud Security Team found a vulnerability in the Log4J, also known as log4shell, framework that provides attackers with a simple way to run arbitrary code on any machine that uses a vulnerable version of the Log4J. This vulnerability was publicly disclosed on the 9th of December 2021.

The announcement of Log4j vulnerability cve-2021-44228 sent security and development teams into a tailspin and highlights the one of biggest challenges of open source security: dependency management. The open source libraries that make up up to 80% of our applications are often a tangled web of dependencies.

As the threat landscape changes and advances with time, being able to address the most common types of cyber security vulnerabilities has gained the utmost importance. In this article, we will consider various types of cyber security vulnerabilities and how you can mitigate them. As information becomes an organization’s most important asset, cyber security gains increasingly more priority.

The notorious Log4Shell vulnerability CVE-2021-45046, has put Log4j in the spotlight, and grabbed the entire Java community’s attention over the last couple of weeks. Maintainers of Java projects that use Log4j have most probably addressed the issue. Meanwhile, non-java developers are enjoying relative peace of mind, knowing that they are unaffected by one of the major vulnerabilities found in recent years. Unfortunately, this is an incorrect assumption.

If you have access to the internet, it’s likely that you have already heard of the critical vulnerability in the Log4j library. A zero-day vulnerability in the Java library Log4j, with the assigned CVE code of CVE-2021-44228, has been disclosed by Chen Zhaojun, a security researcher in the Alibaba Cloud Security team. It’s got people worried—and with good reason.

At many organizations, the surprise discovery that the widely used Apache log4j open source software has harbored a longtime critical vulnerability was as if Scrooge and the Grinch had teamed up for the biggest holiday heist of all. Incident response teams across the globe have scrambled to remediate thousands, if not millions of applications. “For cybercriminals this is Christmas come early,” explained Theresa Payton, former White House CIO and current CEO of Fortalice Solutions.

Note: This post first appeared in r/CrowdStrike. First and foremost: if you’re reading this post, I hope you’re doing well and have been able to achieve some semblance of balance between life and work. It has been, I think we can all agree, a wild December in cybersecurity (again). At this time, it’s very likely that you and your team are in the throes of hunting, assessing and patching implementations of Log4j2 in your environment.

The last week has been a wild ride for just about everyone in the technology world due to the public disclosure of the Log4Shell vulnerability. As a developer security company, Snyk has built our business around proactive automation to identify and fix security issues in applications. To say we’ve been busy this week would be an understatement.

With great automation, comes great risk. The advent of infrastructure as code brought about automation for the tedium of deploying, provisioning, and managing resources in public clouds with declarative scripts. However, this automation increased the importance of creating secure IaC scripts or configurations with cloud infrastructure misconfigurations being cited as the biggest area of increased concern (58%) from 2020 to 2021 in the 2021 Snyk Cloud Native Application Security report.

The recently discovered Log4j vulnerability has serious potential to expose organizations across the globe to a new wave of cybersecurity risks as threat actors look to exploit this latest vulnerability to execute their malicious payloads using remote code execution (RCE). An immediate challenge that every organization faces is simply trying to understand exactly where you have applications that are using this very popular Java library — but you are not facing this challenge alone.

Last week I had the privilege to be in Washington, DC talking to a group of defenders. I heard a clear pattern of words: “data-driven,” “telemetry-first,” and “visibility”.

Ever since the public exploit of the Log4Shell remote code execution (RCE) vulnerability became known on December 10, 2021, security teams have been scrambling to understand the risk to their environments. Part of that scramble has been to ascertain which tools are best positioned to help detect the vulnerability. Which approaches are most effective and where do they fall short?

The world of cybersecurity has been constantly challenged since the pandemic started. With the dust still settling, a new concern has taken the entire cyber landscape by storm. A flaw in Log4j, a widely used Java-based logging library, allows hackers unbridled access to computer systems. The vulnerability (CVE-2021-44228) affects everything from the cloud to security devices. Attackers have come up with worms that can spread independently from one vulnerable system to another.

The situation involving the log4j ( log4shell ) vulnerability has been rapidly evolving since its release a little over a week ago. A new exploit, CVE-2021-45046, was found which was not covered by the initial 2.15.0 patch. Not long after the 2.16.0 patch was released, another issue was found, CVE-2021-45105, which resulted in the release of 2.17.0. There is clearly a lot going on in the log4j library.

The Log4j vulnerability burst onto the scene just a few weeks ago, but to many defenders it already feels like a lifetime. It has rapidly become one of the top concerns for security teams in 2021, and seems set to remain so for the foreseeable future. The critical details of this threat evolve almost daily, making it a formidable challenge for defenders to keep tabs on the threat and their organizations’ exposure.

In our recent webinar, Log4j Log4Shell Vulnerability Explained: All You Need To Know, our Senior Director Security Research expert Shachar Menashe shared information on the security issue and how to detect and remediate it. We are happy to share additional information in the following Q&A, based on the questions raised during the webinar.

Just when the Microsoft Exchange exploit CVE-2021-26855 thought it would win the “Exploit of the year” award, it got unseated by the – still evolving – Log4J exploit just weeks before the end of the year! Had somebody asked Sysadmins in November what Log4J was then I suspect that the majority would have had no idea. It seems that the biggest challenge the Log4J exploit poses for Sysadmins is simply the fact that nobody knows all the places where Log4J is being used.

Due to the recently discovered Log4Shell vulnerability, and to support the tremendous effort being mounted by the community to address it, we are happy to announce that we are increasing the free test limit in Snyk Open Source! This means that any developer, no matter the company or project, can now use Snyk Open Source to find and fix Log4Shell with double the number of free tests, whether it’s within your IDE, your Git repositories, CI environments, or using the Snyk CLI.

Just a few days after CVE-2021-45046 was released and fixed, a third zero-day vulnerability was discovered in Apache Log4j, tracked as CVE-2021-45105. The bug was reported on December 15, 2021, and disclosed on December 18, 2021. This third vulnerability has received a CVSS score of 7.5 out of 10, whereas the first one known as Log4Shell (CVE-2021-44228) received the maximum CVSS score of 10 due to its criticality.

Welcome to Elastic’s Log4j2 vulnerability information hub. Here we will explain what the specific Log4j2 vulnerability is, why it matters, and what tools and resources Elastic is providing to help negate the opportunity for malware exploits, cyberattacks, and other cybersecurity risks stemming from Log4j2.

A third Log4j2 vulnerability was disclosed the night between Dec 17 and 18 by the Apache security team, and was given the ID of CVE-2021-45105. According to the security advisory, 2.16.0, which fixed the two previous vulnerabilities, is susceptible to a DoS attack caused by a Stack-Overflow in Context Lookups in the configuration file’s layout patterns. What is this CVE about? What can you do to fix it? How does it differ from the previous CVEs?

Log4j, Log4j, Log4j. Let’s see you say that 10 times fast. If you can’t, then you may need to learn because Log4j is on the tips of everyone’s tongues right now. In fact, people are calling Log4j the biggest security breach since Tutar, Borat’s movie daughter, sneaked into The White House and had a lively face-to-face conversation with President Trump.

Log4j, Log4j, Log4j. Let’s see you say that 10 times fast. If you can’t, then you may need to learn because Log4j is on the tips of everyone’s tongues right now. In fact, people are calling Log4j the biggest security breach since Tutar, Borat’s movie daughter, sneaked into The White House and had a lively face-to-face conversation with President Trump.

Overnight, it was disclosed by Apache that Log4j version 2.16 is also vulnerable by way of a Denial of Service attack with the impact being a full application crash, the severity for this is classified as High (7.5). Snyk is currently not aware of any fully-fledged PoCs or exploits in circulation. CVE-2021-45105 has been issued, and a new fixed version (2.17) has been published by Apache which we recommend upgrading to.

We have published an initial blog on the Log4j exploit and a followup blog with a second detection method for detecting the first stage of exploits occurring over LDAP. Today, we will discuss a third detection method, this one focused on the second-stage download that happens after the first stage completes. In this case, the JVM will download additional Java code payloads over HTTP.

Last week, a researcher from the Alibaba Cloud Security Team dropped a zero-day remote code execution exploit on Twitter, targeting the extremely popular log4j logging framework for Java (specifically, the 2.x branch called Log4j2). The vulnerability was originally discovered and reported to Apache by the Alibaba cloud security team on November 24th. MITRE assigned CVE-2021-44228 to this vulnerability, which has since been dubbed Log4Shell by security researchers.

It’s the last Patch Tuesday update of 2021, and as with many other updates this year, this month’s list includes important ones — among them a zero-day (CVE-2021-43890 in AppX installer), multiple critical vulnerabilities and a variety of attack types utilized in several Microsoft product families — highlighting once again that patching and prioritization are prominent programs SecOps staff must regularly implement to keep adversaries from infiltrating their organizations’

For more information on how to respond to the Log4j vulnerabilities using Splunk products, please see our Log4Shell response overview page. Like most cybersecurity teams, the Splunk Threat Research Team (STRT) has been heads-down attempting to understand, simulate, and detect the Log4j attack vector. This post shares detection opportunities STRT found in different stages of successful Log4Shell exploitation.

A critical vulnerability has been recently discovered in the Apache Log4j Java logging library (CVE-2021-44228), a library used in many client and server applications. The Log4j library is commonly included in Java based software including multiple Apache frameworks such as Struts2, Solr, Druid and Fink. The library provides enhanced logging functionality for Java applications and is commonly used in business system development.

There's little question that you've already heard about the recently discovered security flaw related to Log4j, a widely used Java library for logging error messages in applications. The vulnerability enables a threat actor to remotely execute commands via remote code execution (RCE) on nearly any machine using Log4j. But it's also important to cut through all of the noise to truly understand the implications of the Log4j and what organizations can do to combat it.

Since 2019, Snyk and Dynatrace have partnered with a shared mission of securing the entire software development lifecycle (SDLC) and accelerating digital transformation. As many agile organizations migrate their workloads to the cloud, it’s tempting for teams to let security take a back-seat until all the pieces of the infrastructure puzzle are in place.

While many organizations are patching the two recent Apache Log4j vulnerabilities (CVE-2021-44228 and CVE-2021-45046), attackers have been racing to exploit them to deliver malware, such as botnets, backdoors, and cryptominers. Among the threats delivered using Log4Shell exploits, a new ransomware family was found by Bitdefender: Khonsari.

The Apache Log4j vulnerability has been assigned the most critical cyber threat rating of CVSS 10. For a concise overview of the zero-day, and to learn how to secure your systems against its exploitation, all of the popular FAQs concerning this vulnerability have been conveniently compiled in this post.

Is it just me or is the announcement of a significant CVE becoming a holiday tradition? Discovered on December 9, 2021 by Minecraft players, the Apache Log4Shell vulnerability is a uniquely insidious because it infects servers which are traditionally well insulated from attacks and perceived as unreachable by an intruder and not at risk for CVEs. Log4Shell is an entirely different can of works that proves this assumption wrong.

We recently discussed some methods for detecting the Log4j exploit, and we’ve now developed another method that everyone running Zeek® or a Corelight sensor can use. Our new approach is based on the rarity of legitimate downloads of Java via LDAP. Zeek does not currently have a native LDAP protocol analyzer (though one is available if you are running Spicy). This will not stop you from detecting this exploit downloading Java over LDAP, though. To see how, read on.

In quick succession in December, The Apache Software Foundation released information on two critical vulnerabilities in its Log4j Java-based library. The first vulnerability CVE-2021-44228, also known as Log4Shell or LogJam, was reported as an unauthenticated remote code execution (RCE) vulnerability. By exploiting how the library logs error messages, it could lead to a complete system takeover.

The United States Department of Homeland Security (DHS) is inviting security researchers to uncover vulnerabilities and hack into its systems, in an attempt to better protect itself from malicious attacks.

Log4Shell is a high severity vulnerability (CVE-2021-44228) impacting Apache Log4j versions 2.0 to 2.14.1. It was discovered by Chen Zhaojun of Alibaba Cloud Security Team and disclosed via the project´s GitHub repository on December 9, 2021.

Rubrik customers have an advantage when it comes to mitigating the log4j crisis. Utilizing our API-first architecture, Rubrik customers can make a single API call to find instances of log4j across their protected systems.

At Snyk we have some general points of principle that we use to help guide our security thinking and decision making. Firstly, it is always important to understand from whom we are protecting, as it has implications for how we need to act. As an example of this, if our artefact is a web server, then we need to protect it against untrusted users. Whilst if our artefact is encryption software, then we clearly need to protect it even from users with physical access to the system.

As security and development teams rushed to assess the now-notorious Log4Shell vulnerability published December 10 (CVE-2021-44228), another, more minor vulnerability was discovered in Log4j — CVE-2021-45046. To understand the newly-discovered vulnerability, it is important to get the full picture and background on the original Log4j issue.

Dec. 29: Updated to cover three additional CVEs: CVE-2021-4104, CVE-2021-44832, and CVE-2021-42550 (in logback as opposed to log4j). Dec. 22: A joint Cybersecurity Advisory was issued by multiple national cybersecurity agencies providing mitigation guidance on addressing vulnerabilities in Apache’s Log4j software library: CVE-2021-44228 (known as “Log4Shell”), CVE-2021-45046, and CVE-2021-45105. Dec. 17: Please note the emergency directive from CISA on Log4j.

Dec. 29: Updated to cover three additional CVEs: CVE-2021-4104, CVE-2021-44832, and CVE-2021-42550 (in logback as opposed to log4j). Dec. 22: A joint Cybersecurity Advisory was issued by multiple national cybersecurity agencies providing mitigation guidance on addressing vulnerabilities in Apache’s Log4j software library: CVE-2021-44228 (known as “Log4Shell”), CVE-2021-45046, and CVE-2021-45105. Dec. 17: Please note the emergency directive from CISA on Log4j.

Shortly after the Apache Software Foundation (ASF) released the bug fix for the vulnerability known as Log4Shell or LogJam (CVE-2021-44228), a new vulnerability was discovered in Log4j Java-based logging library, tracked as CVE-2021-45046. While Log4Shell had the maximum CVSS score of 10, this new vulnerability is rated as 3.7, affecting all versions of Log4j between 2.0-beta9 and 2.12.1, as well as between 2.13.0 and 2.15.0.

On December 9, 2021, a zero-day vulnerability in Log4j 2.x was discovered. This vulnerability is of great concern because if it’s successfully exploited, attackers are able to perform a RCE (Remote Code Execution) attack and compromise the affected server. Since we are a cloud-based Software Composition Analysis (SCA) provider, we have useful customer data that gives insight into the scope of the Log4j vulnerability.

On December 9th 2021, Apache published a zero-day vulnerability (CVE-2021-44228) for Apache Log4j being referred to as “Log4Shell.” This vulnerability has been classified as “Critical” with a CVSS score of 10, allowing for Remote Code Execution with system-level privileges. If you are currently working to identify instances of this vulnerability, Tripwire can help.

If you’re in tech at all, you’ve likely heard of the Log4Shell exploit taking over the Intertubes. If you’re not a Java developer (or developer of any sort), you may be left scratching your head as to just what’s going on. This post is split into two parts: an explanation of Log4Shell for non-developers and an overview of the Log4Shell vulnerability for non-Java developers.

A new critical vulnerability has been found in log4j, a widely-used open-source utility used to generate logs inside java applications. The vulnerability CVE-2021-44228, also known as Log4Shell, permits a Remote Code Execution (RCE) allowing the attackers to execute arbitrary code on the host. The log4j utility is popular and used by a huge number of applications and companies, including the famous game Minecraft.

The vulnerability, dubbed CVE-2021-43798 impacted the Grafana dashboard, which is used by companies around the world to monitor and aggregate logs and other parameters from across their local or remote networks. The privately reported bug became a leaked zero-day but was first spotted by Detectify Crowdsource hacker Jordy Versmissen on December 2, after which Grafana was notified by Detectify about the bug.

Recent CrowdStrike Intelligence team findings regarding the Log4Shell (CVE-2021-44228, CVE-2021-45046) vulnerabilities indicate wide-ranging impact. CrowdStrike helps protect customers from threats delivered via this vulnerability using both machine learning and indicators of attack (IOAs).

On December 9, 2021, a critical vulnerability in the popular Log4j Java logging library was disclosed and nicknamed Log4Shell. The vulnerability is tracked as CVE-2021-44228 and is a remote code execution vulnerability that can give an attacker full control of any impacted system. In this blog post, we will: We will also look at how to leverage Datadog to protect your infrastructure and applications.

Security workers across the world have been busy since last Friday dealing with CVE-2021-44228, the log4j 0-day known as Log4Shell, that is already being heavily exploited across the Internet. Given the huge number of systems that embed the vulnerable library, the myriad ways that attackers can exploit the vulnerability, and the fact that automated exploitation has already begun, defenders should expect to be dealing with it for the foreseeable future.

CVE-2021-44228 (Log4Shell or LogJam) is a recently discovered zero-day vulnerability in the ubiquitous Apache Log4j Java-based logging library. It was reported by the Alibaba Cloud Security team as an unauthenticated RCE vulnerability in Log4j 2.0-beta9 up to 2.14.1 and could allow a complete system takeover on vulnerable systems. The bug has received the maximum CVSS score of 10, reflecting its importance and ease of exploitation.

Last Thursday, a researcher from the Alibaba Cloud Security Team dropped a zero-day remote code execution exploit on Twitter, targeting the extremely popular log4j logging framework for Java (specifically, the 2.x branch called Log4j2). The vulnerability was originally discovered and reported to Apache by the Alibaba cloud security team on November 24th. MITRE assigned CVE-2021-44228 to this vulnerability, which has since been dubbed Log4Shell by security researchers.

On Thursday, December 9, a zero-day vulnerability CVE-2021-44228 (a.k.a. Log4Shell, LogJam, and Log4j) was made public. This vulnerability impacts Apache Log4j versions 2.0-beta9 to 2.14.1, and it has the highest possible CVSS score of 10.0. As of today, it is widely regarded as one of the most dangerous and widespread vulnerabilities to date.

Even if you tried VERY hard to enjoy a quiet weekend, chances are that this plan was interrupted at least once by the new Log4Shell zero-day vulnerability that was disclosed on Friday (December 10, 2021). The new vulnerability was found in the open source Java library log4j-core which is a component of one of the most popular Java logging frameworks, Log4J.

Styra Declarative Authorization Service (DAS), both SaaS and self-hosted, as well as Open Policy Agent (OPA), are not affected by the Log4j security vulnerability. The newest Apache Log4j Java-based logging utility vulnerability (CVE-2021-44228) was disclosed to Apache by Alibaba's Cloud Security Team on November, 24 2021 by Chen Zhaojun and published on December, 9 2021.

A critical vulnerability, CVE-2021-44228 known as “log4shell,” in Apache’s log4j was revealed on December 10th, 2021, and has already seen wide exploitation around the Internet. Previously, we discussed the vulnerability and how to find it in your images using Sysdig Scanning reports. In a perfect world, patching would be quick, easy, and completed without any issues.

By now, you already know of — and are probably in the midst of remediating — the vulnerability that has come to be known as Log4Shell and identified as CVE-2021-44228. This is the vulnerability which security researchers disclosed on Friday (10 December 2021) for Apache’s Log4j logging framework. In this article, we’ll explore a few key Log4j facts as well as actions you can take to protect yourself and your company.

Thanks to Detectify Crowdsource hackers, Detectify quickly developed a security test to detect Critical vulnerability CVE-2021-44228 Apache log4j RCE. This vulnerability has set the internet alight over the past few days. Right now, exploit developers and security researchers are still understanding the potential capabilities provided by the vulnerability. Detectify received a working POC for this critical 0-day vulnerability from the Crowdsource community on Friday.

A newly published critical vulnerability in Apache’s widely popular Log4j Java library, CVE-2021-44228 (CVSS score 10) was published over the weekend, causing a lot of concern.

Updated 12/20/21 On December 9, 2021, Apache published a zero-day vulnerability (CVE-2021-44228) for Apache Log4j being referred to as “Log4Shell”. This “critical” vulnerability (CVSS score: 10) allows a remote attacker to take control of an affected system. When exploited, this vulnerability allows an attacker to run arbitrary code on the device, giving full control over to the attacker.

On Dec 9th, a critical zero-day vulnerability - CVE-2021-44228 - was announced concerning the Java logging framework - Log4j All current versions of log4j2 up to 2.14.1 are vulnerable. To remediate this vulnerability, please update to version 2.15.0 or later.

A critical vulnerability in the popular log4j library is currently being actively targeted on a broad global scale and possibly exploited based on advisories from multiple CERTs and vendors: CISA, Apache, etc. This Java library is integrated into many IT and DevOps tooling and workflows. On Dec 10, 2021, Apache released version 2.15.0, fixing CVE-2021-44228 (dubbed Log4Shell) an RCE with a maximum CVSSv3 score of 10.

A previously unknown zero-day vulnerability in Log4j 2.x has been reported on December 9, 2021. If your organization deploys or uses Java applications or hardware running Log4j 2.x your organization is likely affected.

To understand how Elastic is currently assessing internal risk of this vulnerability in our products please see the advisory here.

Authors and Contributors: As always, security at Splunk is a family business. Credit to authors and collaborators: Ryan Kovar, Shannon Davis, Marcus LaFerrera, John Stoner, James Brodsky, Dave Herrald, Audra Streetman, Johan Bjerke, Drew Church, Mick Baccio, Lily Lee, Tamara Chacon, Ryan Becwar. If you want just to see how to find detections for the Log4j 2 RCE, skip down to the “detections” sections.

Today (Dec.10, 2021), a new, critical Log4j vulnerability was disclosed: Log4Shell. This vulnerability within the popular Java logging framework was published as CVE-2021-44228, categorized as Critical with a CVSS score of 10 (the highest score possible). The vulnerability was discovered by Chen Zhaojun from Alibaba’s Cloud Security team. All current versions of log4j2 up to 2.14.1 are vulnerable. You can remediate this vulnerability by updating to version 2.15.0 or later.

Security researchers recently disclosed the vulnerability CVE-2021-44228 in Apache’s log4j, which is a common Java-based library used for logging purposes. Popular projects, such as Struts2, Kafka, and Solr make use of log4j. The vulnerability was announced on Twitter, with a link to a github commit which shows the issue being fixed. Proof-of-concept code was also released to github which shows that the vulnerability is trivial to exploit.

Earlier today, a serious flaw was discovered in the widely used Java logging library Apache Log4j. The vulnerability, ‘Log4Shell,’ was first identified by users of a popular Minecraft forum and was apparently disclosed to the Apache Foundation by Alibaba Cloud security researchers on Nov. 24, 2021. The vulnerability has the potential to allow unauthenticated remote code execution (RCE) on nearly any machine using Log4j.

Log4j zero-day vulnerability is flooding the security updates/news everywhere. This issue has been named Log4shell and assigned CVE-2021-44228 (still awaiting analysis at the time of writing).

Apache has released version 2.16.0, which completely removes support for Message Lookups and disables JNDI by default. CrowdStrike has identified a malicious Java class file hosted on infrastructure associated with a nation-state adversary. The Java code is used to download known instances of adversary-specific tooling and is likely to be used in conjunction with the recently disclosed Log4Shell exploit (CVE-2021-44228).

Software development organizations are investing more and more resources in their vulnerability management programs. According to Gartner’s forecast, in 2021 enterprise security spending was expected to break records and grow 12.4% to reach 150.4 billion. But how do organizations know if they’re spending their security resources wisely? The answer can only be found by crunching the numbers.

The Metasploit Framework is a Ruby-based, open-source framework that is used by information security professionals and cybercriminals to find, exploit, and validate system vulnerabilities. The framework consists of various exploitation tools and penetration testing tools. Information security teams most commonly use Metasploit for penetration testing (or “ethical hacking”) to identify and remediate any existing vulnerabilities across an organization’s networks.

There are almost 165,000 known CVEs (Common Vulnerabilities and Exposures) listed in the NIST Database. In October of 2020, the NSA published a list of the 25 CVEs most likely to be exploited by Nation-State attackers in China; Checkpoint software found over 3 million attempts to penetrate networks or steal files using these known vulnerabilities.

The JFrog Security research team continuously monitors popular open source software (OSS) repositories with our automated tooling, and reports any vulnerabilities or malicious packages discovered to repository maintainers and the wider community. Most recently we disclosed 11 malicious packages in the PyPI repository, a discovery that shows attacks are getting more sophisticated in their approach.

In 2020, I published an AT&T blog called “Top Cybersecurity Trends & Predictions for 2020’”. In the article I had forecasted that cybersecurity would become even more of a strategic priority for companies as the cost, sophistication, and lethality of breaches would continue to rise.

As we look ahead to 2022, we should pause to reflect on the trends of the past year. Ransomware and supply chain attacks have become two of the top concerns for organizations following a series of high-profile attacks, such as those conducted against Colonial Pipeline, SolarWinds and Kaseya. In 2021, our Project Memoria revealed close to 100 different vulnerabilities in common TCP/IP stacks, affecting hundreds of operational technology (OT) vendors.

On November 10, 2021, Palo Alto Networks released advisories for eight different vulnerabilities affecting the company’s VPN firewall products. The vulnerabilities’ criticality ranges from ‘medium’ to ‘critical,’ with the most severe vulnerability, CVE-2021-3064 (CVSSv3.1 of 9.8), allowing for unauthenticated remote code execution, or RCE.

Trustwave has been accredited by the internationally-recognized professional certification board CREST for its world-class vulnerability assessment services. Trustwave is now uniquely accredited with multiple CREST accreditations across Vulnerability Assessment (VA), Intelligence-Led Penetration Testing (STAR), Penetration Testing (PEN TEST) and STAR-FS Intelligence-Led Penetration Testing.

Over the last two weeks, many have had flashbacks to 2012 when Heartbleed was released and everyone scrambled to fix broadly used OpenSSL. Due to their nature, some applications and services are so prolific that when a vulnerability is identified it causes massive issues for vendors and customers alike. The latest of this kind of issue is the Log4j vulnerability that has been dominating the press.

2021 was the year businesses continued to adapt to new working patterns, digital transformation and battle the increasing threats from ransomware attacks. Here our panel of security experts share their predictions for the key security challenges and trends to look out for in 2022 ensuring you can beat the hackers at their own game.

This is the second in a two-part series discussing a still-unpatched userland Windows privilege escalation. The exploit enables attackers to perform highly privileged actions that typically require a kernel driver. Part 1 of this blog series showed how to block these attacks via ACL hardening. If you haven’t already, please read the first part of this series, because it lays an important foundation for this article. Interested readers can also check out the excellent Unknown Known DLLs...

Vulnerability management is becoming increasingly important to companies due to the rising threat of cyber security attacks and regulations like PCI DSS, HIPAA, NIST 800-731 and more. Vulnerability management is a comprehensive process implemented to continuously identify, evaluate, classify, remediate, and report on security vulnerabilities.

Owners and operators of Operational Technology (OT) environments are being increasingly tasked with providing more information and security controls for their OT Environments, whether those demands are driven by the board, executive orders, or new regulations. One of the biggest fallacies that we encounter when our customers begin monitoring their OT environment is the idea that OT systems are air gapped and completely isolated from IT systems.

This is part 2 of Trustwave’s 2022 Cybersecurity Predictions blog series. In 2021, the cybersecurity industry was truly tested. Most notably, we uncovered the deeper fallout from the SolarWinds attacks, combatted the proliferation of advanced ransomware gangs and a surge in vulnerability exploitation, and saw fragile supply chain and critical infrastructure more targeted by attackers than ever.