Ian came across this:

NCC has a good write-up on how to mitigate beyond patches.


"None of these solutions are ideal because they all presume that everyone has a 100% handle on their dependency chains and that you won’t end up with a mix of log4j versions strewn across the subcomponents of apps segmented across multiple classloaders (looking at you, WAR files). The reality is that the node_modules-style of dependency embedding is not completely alien to the Java ecosystem (and Java has a host of left-pad type issues due to how its build systems resolve dependencies across multiple repositories). In addition to this, many apps and proprietary libraries and app servers possibly vendor-in log4j in weird ways that end up preferring their own versions over any shared version that might actually be updated by your ops team. All told, tracking down and updating every instance of a library like this in your application stack is a nontrivial process and potentially error prone as any one rogue log4j copy can potentially keep a service vulnerable." (NCC Group)

A tool to mitigate Log4Shell by disabling log4j JNDI​

To try to make the situation a little bit more manageable in the meantime, we are releasing log4j-jndi-be-gone, a dead simple Java agent that disables the log4j JNDI handler outright. log4j-jndi-be-gone uses the Byte Buddy bytecode manipulation library to modify the at-issue log4j class’s method code and short circuit the JNDI interpolation handler. It works by effectively hooking the at-issue JndiLookup class’ lookup() method that Log4Shell exploits to load remote code, and forces it to stop early without actually loading the Log4Shell payload URL. It also supports Java 6 through 17, covering older versions of log4j that support Java 6 (2.0-2.3) and 7 (2.4-2.12.1), and works on read-only filesystems (once installed or mounted) such as in read-only containers.
 
All Log4j Logback Bugs We Know So Far and Why You MUST Ditch 2.15


CVE-2021-44228 [Critical]
: The original 'Log4Shell' or 'logjam' vulnerability is an untrusted deserialization flaw. Rated critical in severity, this one scores a 10 on the CVSS scale and grants remote code execution (RCE) abilities to unauthenticated attackers, allowing complete system takeover.

Reported by Chen Zhaojun of Alibaba Cloud Security Team to Apache on November 24th, CVE-2021-44228 impacts the default configurations of multiple Apache frameworks, including Apache Struts2, Apache Solr, Apache Druid, Apache Flink, and others.

Being the most dangerous of them all, this vulnerability lurks in the log4j-core component, limited to 2.x versions: from 2.0-beta9 up to and including 2.14.1. A fix for Log4Shell was rolled out in version 2.15.0 but deemed incomplete (keep reading).

--

CVE-2021-45046 [Critical, previously Low]: Rated low in severity, this one is a Denial of Service (DoS) flaw scoring a mere 3.7. The flaw arose as a result of an incomplete fix that went into 2.15.0 for CVE-2021-44228. While the fix applied to 2.15.0 did largely resolve the flaw, that wasn't quite the case for certain non-default configurations.

Log4j 2.15.0 makes "a best-effort attempt" to restrict JNDI LDAP lookups to localhost by default. But, attackers who have control over the Thread Context Map (MDC) input data can craft malicious payloads via the JNDI Lookup patterns to cause DoS attacsk. This applies to non-default configurations in which a non-default Pattern Layout using either a Context Lookup, e.g. $${ctx:loginId}, or a Thread Context Map pattern (%X, %mdc, or %MDC).

"Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default," states the NVD advisory. For those on 2.12.1 branch, a fix was backported into 2.12.2.

--

CVE-2021-4104 [High]: Did we say Log4j 2.x versions were vulnerable? What about Log4j 1.x?

While previously thought to be safe, Log4Shell found a way to lurk in the older Log4j too. Essentially, non-default configuration of Log4j 1.x instances using the JMSAppender class also become susceptible to the untrusted deserialization flaw.

Although a less severe variant of CVE-2021-44228, nonetheless, this CVE impacts all versions of the log4j:log4j and org.apache.log4j:log4j components for which only 1.x releases exist. Because these are end-of-life versions, a fix for 1.x branch does not exist anywhere, and one should upgrade to log4j-core 2.16.0.

--

CVE-2021-42550 [Moderate]: This is a vulnerability in the Logback logging framework. A successor to the Log4j 1.x library, Logback claims to pick up "where log4j 1.x leaves off."

Up until last week, Logback also bragged that being "unrelated to log4j 2.x, [logback] does not share its vulnerabilities."

That assumption quickly faded when CVE-2021-4104 was discovered to impact Log4j 1.x as well, and the possibility of potential impact to Logback was assessed. Newer Logback versions, 1.3.0-alpha11 and 1.2.9 addressing this less severe vulnerability have now been released.

--

BleepingComputer came across multiple security researchers claiming that it is possible to achieve full-on RCE, even with 2.15.0.

"The worst possible scenario resulting from Log4j 2.15.0 is yet to be fully determined, but suffice to say, it doesn't seem like it's just limited to DoS."

"As the situation continues to evolve, organizations and developers are encouraged to upgrade to version 2.16.0, and to continue to monitor Apache's Log4j advisory page for updates."

"The action required by defenders is clear cut in all cases: moving to 2.16.0 where jndi is disabled by default is the safest course of action, and is the approach we're recommending for our customers."
 

Severity: High TLP: Green Public Facing Protocols Allow Exploitation of Log4j in vCenter Servers​

Tags
  1. Cybercriminal Attack
Conti Ransomware Leverages log4j Bug to Exploit VMware vCenter Servers

Summary:

The Conti ransomware operation uses the critical Log4 Shell exploit to gain rapid access to internal VMware vCenter Server instances and encrypt virtual machines. The group did not waste much time adopting the new attack vector and is the first "top-tier" operation known to weaponize the Log4j vulnerability.

Timeline:
  • A proof-of-concept (PoC) exploit for CVE-2021-44228 - otherwise known as Log4Shell and LogJam - emerged in the public space on December 9.
  • A day later, mass scanning of the internet started, with multiple actors looking for vulnerable systems. Among the first to leverage the big were cryptocurrency miners, botnets, and a new ransomware strain called Khonsari.
  • By December 15, the list of threat actors using Log4J Shell expanded to state-backed hackers and initial access brokers that typically sell network access to ransomware gangs.
  • Conti, one of the largest and most prolific ransomware gangs today with tens of active full-time members, appears to have taken interest in Log4J Shell early on, seeing it as a possible attack avenue on Sunday, December 12.
Analyst Comments:
The researchers confirmed that Conti ransomware affiliates had already compromised the target networks and exploited vulnerable Log4j machines to gain access to vCenter servers. This means that Conti ransomware members relied on a different initial access vector (RDP, VPN, email phishing) to compromise a network and are currently using Log4Shell to move laterally on the network.

Mitigation:
It is essential that companies identify and apply security measures to systems accessible over the internet. Protocols used for connectivity to and from internal corporate assets should have as many security controls as possible. Multifactor authentication should be enabled in systems that are accessed remotely - RDP should not be used over the WAN - VPN connections are more secure. After initial access, according to the report from BleepingComputer, Log4j was used to leverage vCenter servers in attacks. VMWare uses a Linux-Based kernel, so it is safe to assume that VMWare is vulnerable to Log4j based-attacks. Companies may want to identify servers using VMware or 'anything Linux' and apply hardening measures accordingly - whether making adjustments and network isolation/segmentation at Layer 3 of the OSI model or removing access directly at the NIC responsible for facilitating host access.

Source:
https://www.bleepingcomputer.com/ne...ses-log4j-bug-to-hack-vmware-vcenter-servers/
 
INTENDED FOR WIDEST DISTRIBUTION
Critical Infrastructure Colleagues and Partners,
***For widest distribution amongst CISA partners--- Not for media representatives***
The Cybersecurity and Infrastructure Security Agency (CISA) invites you to participate in a Broad Sector stakeholder call Monday, December 20, 2021, at 2 pm Eastern to discuss the Apache Log4J Vulnerability (CVE-2021-44228) (CVE-2021-44228). Subject Matter Experts from CISA will provide updates about the vulnerability and mitigation strategies.
CISA strongly urges users and administrators to review Apache Log4j Vulnerability Guidance for updates and guidance.
Date/Time: Monday, December 20, 2021 (2 pm EST)
Participant Toll Free Dial in Number:
800-857-6546 (passcode 1002279)
 

CISA Issues ED 22-02 Directing Federal Agencies to Mitigate Apache Log4j Vulnerabilities​

Original release date: December 17, 2021

CISA has issued Emergency Directive (ED) 22-02: Mitigate Apache Log4j Vulnerability], directing federal civilian executive branch (FCEB) agencies to address Log4j vulnerabilities—most notably, CVE-2021-44228.

Although ED 22-02 applies to FCEB agencies, CISA strongly recommends that all organizations review ED 22-02 for mitigation guidance. For additional details, see CISA’s webpage Apache Log4j Vulnerability Guidance.

This product is provided subject to this Notification and this Privacy & Use policy.

Continue reading...
 
Log4Shell Update
12-17-2021

Our operations team will continue to monitor the situation over the weekend and will update here as needed.

Mitigation Status:

Apache released Log4j version 2.16.0 in a security update to address the CVE-2021-45046 vulnerability. A remote attacker can exploit this second Log4j vulnerability to cause a denial-of-service (DOS) condition in certain non-default configurations.

Note: Affected organizations that have already upgraded to Log4j 2.15.0 will need to upgrade to Log4j 2.16.0 to be protected against both CVE-2021-44228 and CVE-2021-45046.

Per reporting today, patch 2.16.0 appears to mitigate known vulnerabilities sufficiently. It is possible more bypasses and vulnerabilities could emerge as security researchers and cybercriminal continue to investigate. We will update as necessary.

Patching a plethora of devices one by one may not be feasible, especially after companies spent countless hours already upgrading to 2.15. So using tools to disable JDNI to LDAP so that they cannot be exploited remotely could be a beneficial effort. A combination of both patching and disabling JDNI may be a viable safeguard. We have a resources section listed below.

Currently Known Vulnerabilities:

https://www.bleepingcomputer.com/ne...gs-we-know-so-far-and-why-you-must-ditch-215/

CVE-2021-44228 [Critical]: The original 'Log4Shell' or 'logjam' vulnerability is an untrusted deserialization flaw. Rated critical in severity, this one scores a 10 on the CVSS scale and grants remote code execution (RCE) abilities to unauthenticated attackers, allowing complete system takeover.

Reported by Chen Zhaojun of Alibaba Cloud Security Team to Apache on November 24th, CVE-2021-44228 impacts the default configurations of multiple Apache frameworks, including Apache Struts2, Apache Solr, Apache Druid, Apache Flink, and others.

Being the most dangerous of them all, this vulnerability lurks in the log4j-core component, limited to 2.x versions: from 2.0-beta9 up to and including 2.14.1. A fix for Log4Shell was rolled out in version 2.15.0 but deemed incomplete (keep reading).

--

CVE-2021-45046 [Critical, previously Low]: Rated low in severity, this one is a Denial of Service (DoS) flaw scoring a mere 3.7. The flaw arose as a result of an incomplete fix that went into 2.15.0 for CVE-2021-44228. While the fix applied to 2.15.0 did largely resolve the flaw, that wasn't quite the case for certain non-default configurations.

Log4j 2.15.0 makes "a best-effort attempt" to restrict JNDI LDAP lookups to localhost by default. But, attackers who have control over the Thread Context Map (MDC) input data can craft malicious payloads via the JNDI Lookup patterns to cause DoS attacsk. This applies to non-default configurations in which a non-default Pattern Layout using either a Context Lookup, e.g. $${ctx:loginId}, or a Thread Context Map pattern (%X, %mdc, or %MDC).

"Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default," states the NVD advisory. For those on 2.12.1 branch, a fix was backported into 2.12.2.

--

CVE-2021-4104 [High]: Log4j 1.x and 2.x

While previously thought to be safe, Log4Shell found a way to lurk in the older Log4j too. Essentially, non-default configuration of Log4j 1.x instances using the JMSAppender class also become susceptible to the untrusted deserialization flaw.

Although a less severe variant of CVE-2021-44228, nonetheless, this CVE impacts all versions of the log4j:log4j and org.apache.log4j:log4j components for which only 1.x releases exist. Because these are end-of-life versions, a fix for 1.x branch does not exist anywhere, and one should upgrade to log4j-core 2.16.0.

--

CVE-2021-42550 [Moderate]: This is a vulnerability in the Logback logging framework. A successor to the Log4j 1.x library, Logback claims to pick up "where log4j 1.x leaves off."

CVE-2021-4104 was discovered to impact Log4j 1.x as well, and the possibility of potential impact to Logback was assessed. Newer Logback versions, 1.3.0-alpha11 and 1.2.9 addressing this less severe vulnerability have now been released.

--

BleepingComputer came across multiple security researchers claiming that it is possible to achieve full-on RCE, even with 2.15.0.

"The worst possible scenario resulting from Log4j 2.15.0 is yet to be fully determined, but suffice to say, it doesn't seem like it's just limited to DoS. As the situation continues to evolve, organizations and developers are encouraged to upgrade to version 2.16.0, and to continue to monitor Apache's Log4j advisory page for updates."

"The action required by defenders is clear cut in all cases: moving to 2.16.0 where jndi is disabled by default is the safest course of action, and is the approach we're recommending for our customers."

Analyst Comments:

It is essential that companies identify and apply security measures to systems accessible over the internet. Protocols used for connectivity to and from internal corporate assets should have as many security controls as possible. Multifactor authentication should be enabled in systems that are accessed remotely - RDP should not be used over the WAN - VPN connections are more secure.

After initial access, according to the report from BleepingComputer, Log4j was used to leverage vCenter servers in attacks. VMWare uses a Linux-Based kernel, so it is safe to assume that VMWare is vulnerable to Log4j attacks. Companies may want to identify servers using VMware or 'anything Linux' and apply hardening measures accordingly - whether making adjustments and network isolation/segmentation at Layer 3 of the OSI model or removing access directly at NIC responsible for facilitating host access.

Resources:

Indicators of Compromise:

Vulnerable product List from NCSC:

Scanning Tools and Resources:


NCC Group JNDI Disabling Tool

Cybereason Log4Shell Vaccine Offers Permanent Mitigation Option for Log4j Vulnerabilities (CVE-2021-44228 and CVE-2021-45046)
Take action now to implement this vaccine and protect your Apache servers from this critical vulnerability.

You should still update your Apache systems to permanently remediate the vulnerability, but patching takes time, and some systems may not be able to be updated immediately—or at all. This Vaccine will disable the vulnerability and allow you to remain protected while you assess and update your servers.

The latest version is pushed to our github at https://github.com/Cybereason/Logout4Shell
 

Severity: High TLP: Green Apache Releases 2.17 the Third Patch to Address a New log4j Flaw​

Tags
  1. Critical CVE
  2. Cybercriminal Attack
  3. Ransomware Attack
Apache Releases 2.17 the Third Patch to Address a New log4j Flaw

Summary:

The Apache Software Foundation (ASF) was forced to release the third version in a week (version 2.17.0) to fix a ‘High’ severity Denial of Service (DoS) vulnerability in the log4j 2.16 tracked as CVE-2021-45105.

https://nvd.nist.gov/vuln/detail/CVE-2021-45105

“Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3) did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted. This issue was fixed in Log4j 2.17.0 and 2.12.3.”
State-sponsored actors continue to leverage the Log4j vulnerabilities for various malicious purposes, including the deployment of ransomware. Conti ransomware operators were observed exploiting public-facing protocols and services for initial access and then leveraging the vulnerability to bypass access controls/restrictions to deploy final payloads. Companies rushed to patch the plethora of devices using the Log4j service to find out that they were incomplete.

“Immediately after the disclosure of the exploit, Microsoft researchers reported that Nation-state actors from China, Iran, North Korea, and Turkey are now abusing the Log4Shell (CVE-2021-44228) in the Log4J library in their campaigns. Some of the groups exploiting the vulnerability are China-linked Hafnium and Iran-linked Phosphorus, the former group is using the flaw to attack virtualization infrastructure, the latter to deploy ransomware, (SecurityAffairs, 2021).”

Analyst Comments:
The CVE-2021-45105 vulnerability received a CVSS score of 7.5, it is a DoS flaw that impacts log4j 2.16. The experts pointed out that even if JNDI lookups were disabled in version 2.16, self-referential lookups remained a possibility under certain circumstances.

The Apache Software Foundation (ASF) fixed the CVE-2021-45105 flaw with the release of log4j version 2.17.0 (for Java 8).

Source:
https://securityaffairs.co/wordpress/125760/hacking/log4j-third-flaw.html
https://logging.apache.org/log4j/2.x/security.html
https://nvd.nist.gov/vuln/detail/CVE-2021-45105
 

Log4Shell Response and Mitigation Recommendations from Sophos​

Last updated 2021-12-18 UTC 02:31 Update: Added new open source scanning tool, adjusted open sockets query Summary and Background Log4j is an open-source logging framework developed by the Apache Foundation which is incorporated into many Java-based applications on both servers and end-user systems. Initially released, on December 9, 2021, Log4Shell (the nickname given to this […]

Continue reading...
 

Severity: Low TLP: Green A New Attack Vector Exploits the Log4Shell Vulnerability on Servers Locally​

Tags
  1. Critical CVE
Summary:
“Researchers from cybersecurity firm Blumira devised a new attack vector that relies on a Javascript WebSocket connection to exploit the Log4Shell vulnerability on internal and locally exposed unpatched Log4j applications. Experts pointed out that this new attack vector significantly expands the attack surface and can impact services even running as localhost which were not exposed to any network” (Security Affairs, 2021).

There is currently no known active exploitation occurring on this new attack vector. The WebSockets involved in this vulnerability are used for applications like chat and alerts on websites. WebSockets are not restricted by same-origin policies like normal cross-domain HTTP, so they come with inherent security risks.

“The researchers published a proof-of-concept attack that uses a Java Naming and Directory Interface (JNDI) exploit that is triggered via a file path URL using a WebSocket connection to a machine with an installed vulnerable Log4j library. WebSockets allow for connections to any IP enlarging the surface of attack of vulnerable systems” (Security Affairs, 2021).

Analyst Comments:
Using an open port to a local service or service accessible to the host, attackers can use the JNDI exploit string to contact the exploit server and load the attackers class. The payload executes with java.exe as the parent process.

Mitigation:
To mitigate the risk, experts recommend updating all local development efforts, internal applications and internet-facing environments to the latest Log4j 2.17 as soon as possible.

Admins should also look closely at your network firewall and egress filtering to restrict the callback required for the actual exploit to land.

Make sure that only certain machines can send out traffic over 53, 389, 636, and 1099 ports. All other ports should be blocked.

Source:
https://securityaffairs.co/wordpress/125800/hacking/log4shell-vulnerability-attack-vector.html
 

Severity: High TLP: Green Third Log4J Bug Can Trigger DoS; Apache Issues Patch​

Tags
  1. Critical CVE
  2. Cybercriminal Attack
Third Log4J Bug Can Trigger DoS; Apache Issues Patch

Summary:

“No, you’re not seeing triple: On Friday, Apache released yet another patch – version 2.17 – for yet another flaw in the ubiquitous log4j logging library, this time for a DoS bug.

Trouble comes in threes, and this is the third one for log4j. The latest bug isn’t a variant of the Log4Shell remote-code execution (RCE) bug that’s plagued IT teams since Dec. 10, coming under active attack worldwide within hours of its public disclosure, spawning even nastier mutations and leading to the potential for denial-of-service (DoS) in Apache’s initial patch.

It does have similarities, though: The new bug affects the same component as the Log4Shell bug. Both the Log4Shell, tracked as CVE-2021-44228 (criticality rating of CVSS 10.0) and the new bug, tracked as CVE-2021-45105 (CVSS score: 7.5) abuse attacker-controlled lookups in logged data, (Threatpost, 2021).”

Analyst Comments:
It was safe to assume that an additional patch would be released after the announcement of version 2.16. Researchers disclosed various vulnerabilities that could result in data exfiltration and denial service after its release, so it was likely that the bugs were not addressed. Apache is now urging organizations to patch to version 2.17 to mitigate the possibility of a DOS attack targeting servers using log4j. Given the current state of things, additional vulnerabilities and patches may be released soon. Companies should implement as many technical safeguards available as possible in addition to patching products.

Source:
https://threatpost.com/third-log4j-bug-dos-apache-patch/177159/
 
I wrote a PowerShell and Kaseya script to run the Qualys Log4j scanner on my endpoints and generate tickets for vulnerabilities that are found. Sharing this to use or modify as you wish.

This is definitely 1.0 code and built for my environment so it won't run on yours as-is but might be quickly tweaked to yours.

Short summary:
  • Log4jScanner.exe is the Qualys scan utility. More details and source code on Github here: https://github.com/Qualys/log4jscanwin
  • Procedure Log4j Scan.xml is the Kaseya script that pushes out the PS script and the scanner, runs it, and generates tickets
  • Log4jScan.ps1 is the PS script that runs the scanner utility and parses the results
  • If vulnerabilities are found, the Json output from the scanner is renamed by the PS script and then picked up by the Kaseya script and put in the body of the ticket it generates
  • If the PS script gets an error, the error text is written to a file that the Kaseya script finds and puts in the body of a different ticket
I'll do my best to answer questions but it will be best effort and you should test everything thoroughly. No warranty. :cool:
 

Attachments

  • Log4jScan scripts.zip
    167.3 KB · Views: 1,314
  • Like
Reactions: MJ Shoer
I wrote a PowerShell and Kaseya script to run the Qualys Log4j scanner on my endpoints and generate tickets for vulnerabilities that are found. Sharing this to use or modify as you wish.

This is definitely 1.0 code and built for my environment so it won't run on yours as-is but might be quickly tweaked to yours.

Short summary:
  • Log4jScanner.exe is the Qualys scan utility. More details and source code on Github here: https://github.com/Qualys/log4jscanwin
  • Procedure Log4j Scan.xml is the Kaseya script that pushes out the PS script and the scanner, runs it, and generates tickets
  • Log4jScan.ps1 is the PS script that runs the scanner utility and parses the results
  • If vulnerabilities are found, the Json output from the scanner is renamed by the PS script and then picked up by the Kaseya script and put in the body of the ticket it generates
  • If the PS script gets an error, the error text is written to a file that the Kaseya script finds and puts in the body of a different ticket
I'll do my best to answer questions but it will be best effort and you should test everything thoroughly. No warranty. :cool:
Thank you for so generously sharing your work @Tom Strickland! This is what an engaged community is all about, member helping member. Thank you again.

MJ
 

TLP: Green Notes from Log4J CISA Call December 20, 2021​

Tags
  1. Critical CVE
Notes from Log4J CISA Call December 20, 2021 Part 1
Opening:
House Keeping Items:
  • Sensitive period holidays -
  • Threat actors exploit networks during the holidays; security posture is weaker.
  • Next few weeks, as a staff is off, actors will likely attempt to disrupt organizations with malware.
  • Which is why CISA has been flooding the zone with messaging.
  • CISA has released best practices and mitigation measures available on their website, IT-ISAC has shared this information with constituents.
  • Ensure that incident response plans and playbooks are updated
  • Open information-sharing channels have been made available to companies.
  • Focus on continuity of operations
  • A variety of actors are exploiting vulnerabilities in log4j, guidance such as providing information to reduce risk and exposure at cisa[.]gov
  • Catalogs are constantly being updated by vendors and companies that share information.
  • Eric Goldstein - Log4j
  • Points, what the vulnerability is, why it is concerning, walkthrough emergency directive
  • Log4j is a Java-based logging library, fairly ubiquitous across various industries and infrastructure.
  • Any vulnerability in this library is concerning; reporting suggests that the vulnerability can be triggered with a very tiny string remotely for a variety of malicious purposes,
  • Ransomware
  • Crypto Miners,
  • Backdoors
  • CISA is attempting to provide a single source of information for best defense as well as priorities guidance
  • Low-level cyber actors are exploiting> lots of crypto miners
  • Ransomware gangs as well APT are now abusing the vulnerability to achieve their goals.
  • APT activity means that network defenders need to react to prevent exploitation and prevent lateral movement
  • CIO and CISO need to make sure the correct steps are being taken
  • CISA has a single webpage with the latest information regarding the vulnerability, including steps for mitigation.
  • Guidance on the website is aggregated from various sources.
  • A repository of known vulnerable products is available so that companies can check and see if they are using vulnerable products.
  • Visit cisa.gov and check out the repository for vulnerable products; if vulnerable, pivot over to the emergency directive.
  • What is the directive?
  • All organizations focus on risk reduction prioritization.
  • Companies need somewhere to start prioritizing.
  • Internet-facing devices, first. The vulnerability is exploitable over the internet by pinging an internal device that is processing java inquiries even if the devices exposed to the device are not.
  • Once your organization has determined which solution stacks are using log4j, there are a few critical mitigation steps.
  • Update assets where patches are available
  • Many products are still receiving patches.
  • Which products have patches? Deploy them right away
  • Mitigate the risk of exploitation
  • Link in the directive for mitigation measures
  • Example; update WAF with updated rules.
  • Implement one more where applicable
  • Patching not possible? Remove the asset from the network.
  • The vulnerability has been in the wild for 11 days. It is reasonably likely for all organizations that these assets accepting input from the internet are being scanned, and adversaries have found them.
  • Assuming some compromise, look for abnormal network traffic if vulnerable assets were exposed to the internet or have not been remediated.
  • Network defenders are overwhelmed; we need to focus on immediate, most severe threats first = RCE vulnerability, and prevent remote code execution.
Q/A
Q1: Challenge > Software suppliers using vulnerable versions refusing to patch or take action, what are partner companies doing to dictate their response?
A: Concerning hearing that, we are expecting vendors to do the right thing and work with urgency. We want to drive the correct behavior. If you are a member of an ISAC, use information-sharing companies to share the message. Remove the third-party assets or vendor applications from the network.
Q2: Do we have any knowledge or reports of actors bypassing WAFs while exploiting this vulnerability?
A: Yes, CISA has mitigation measures for deploying a WAF, but it is considered an incomplete solution and is not sufficient. Companies must deploy a WAF, move down the mitigation lists, and apply security measures.
Q3: Does CISA have any tools that can be used to scan environments and identify vulnerable instances:
A: Carnegie Mellon tools linked to CISA.gov. They also have a cyber hygiene program that can scan participating entities for vulnerable assets.
Q4: 1. Github list and checking it, authoritative source, a few libraries, and sub-libraries have not made it to the list. The CERTCC tool works but should use a definite scanner in addition. 2. With log4j changing so much, vendors are having a hard time keeping up; what do you recommend for folks in keeping up with vendor patches, and what is your expectation concerning the directive for December 24 when there is so much going on in the patch cycle? We also have seen actors scanning and attempting to exploit WAFs.
A: Github repo is not a 100% accurate source; it's community-based and is considered the best available for where organizations are looking to start. Look at the list; drop in a request and let us know if something is missing. The list will grow and become more accurate but is an ongoing, crowdsourced project. Use our list with a variety of scanning tools and various products. There has been rolling of CVEs and patches over the last day. The immediate focus is driving companies to update to 2.15, especially if they are exposed to the internet. Initial CVE is not trivial to exploit. The initial CVE should be a priority and be mitigated.
Q5: Quick Question: Overwhelming to dive through information on CISA's website, asking you to drive a little bit and tell us where these scanning tools are so we can get things going on our end? What's the best way to start diving into this information?
A: Carnegimellon tools on CISA.gov. Check your assets inventory and compare them with known vulnerable products on CISA's repo. If a weak effect is on that list, Assume compromise and follow the mitigation steps. Complete the same steps for internal devices after those exposed to the WAN have been mitigated.
Q6: CISA public repository Github, will CISA join efforts with other organizations?
A: CISA maintains to be the authoritative source and is working with entities nationally for a better outcome.
Q7: Work with several providers/vendors/ etc.… One of the other challenges is transparency that lets us know what kind of data may have been compromised. Is there any insight back to working with vendors who can also talk about what kind of data has been compromised?
A: What can we do? How do we build from this situation for improvement? One of the most important things we can do is figure out if the organization knows if they are running log4j. They need to look at the product repo for visibility if they don't know. We need to drive the adoption of software build materials lists. We need to push vendors to adopt and work with CISA and partners, so we do not have the same convo years from now.
Q8: Are there efforts on the way to look into other standard software that is widely used and put into software like log4j?
A: Vulnerabilities in software are ubiquitous. When a vulnerability is found, we need to mitigate it quickly.
Q9: This meeting is recorded. Will it be available after the call?
A: It is recorded and pasted on the HSIN page. If you need access, email [email protected] for access.
Q10: The Cyber-Hygiene report, it's great. The question is, we just received a report this morning from a Sunday scan and came back clean for log4j. Has Cyber-Hygiene been updated with all of the necessary plugins to identify if log4j can be identified on vulnerable systems?
A: Yes, but do not stop checking your reports and use additional tools. CH only covers externally-facing IPs; companies must check internal assets, especially those that capture data from the internet.
Q11: What misinformation have you seen about this?
How are we working with other countries, and how have they been affected?
A: There's a lot of info out there; Twitter feed has been 95 percent log4j is good information, some great, and some are not. We are not tracking specific people may be used to obfuscate legitimate information
A: CISA is working with various countries and counterparts around the world. This is a global challenge; companies around the world have been compromised. We are working very closely with the Netherlands.
Q12: What do we do if we cannot meet the directive deadline?
A: Point that question to CISA.gov so we can assist your team in meeting that directive.
Q13: One quick question; How different is it from a Microsoft server patch?
A: One of the fundamental challenges compared to others is dealing with a software library embedded in hundreds and thousands of products. The hard part is pinpointing what devices and software are using the vulnerable library. The first place to start is to enumerate products within your environment that may be using log4j.
Q14: Around embedded devices, things with java code baked in > Firmware. What's the guidance for devices like these? It can be difficult and time-consuming to update.
A: Huge concern at CISA, especially for critical infrastructure. We know it is prevalent in embedded devices and poses risks. CISA is happy to work with vendors in the control system space.
Q15: 2.16 completes the 2.15 fix, which addresses the original cve. How important it is to address a DOS effort in 2.16.
A: Mission-critical Products should be updated to the latest version. From an enterprise risk reduction standpoint, enterprises that are still working to mitigate internet-facing devices using 2.15 should mitigate to some degree instead of moving to and from. However, moving to the latest version is the correct approach.
Q16: What specific response action could organizations be considering at this time? How can we be more proactive when assuming compromise?
A: We are not at the point where every organization needs to assume that they have been compromised. Organizations should be monitored for strange traffic patterns coming from vulnerable products.
Notes from Log4J CISA Call December 20, 2021 Part 2
Q17: Are references to CISA slack channel updates shared there? Can you share that with this group or provide clarification?
A: We have several channels open with various companies and vendors. The goal is to make sure that we can abstract anything they see across the network and share the information back out. Our goal is to collaborate with as many entities as possible; please use our website to find more ways to collaborate.
Q18: Version 2.17, the latest and greatest? Is this the actual fix? Or still vulnerable.
A: There are no residual vulnerabilities after implementing 2.17, but that could change.
Q19: Version 1.x vulnerable?
Q20: They are EOL and unsupported. Actors could compromise 1.x if any EOL products are used and raise vulnerability concerns.
Q20: How do you get software added to CISA's list?
A: Open the github repository from CISA's webpage and drop in a poll request.
Q21: Are cloud-based applications being more targeted/vulnerable to this? Are there specific sectors being targeted more than others?
A: We are still seeing reasonably widespread scanning and targeting across sectors; we may see more targeted attempts over time.
A: Data suggests intimate target access sectors. We have not seen specific targets for cloud infrastructure or applications specifically.
Q22: Systems inside a secure environment (internally, not internet facing). Single click exploits possible?
A: Yes, absolutely concerned. Given the current threat landscape, we should first focus on external public-facing assets for risk prioritization.
A: Focus on the perimeter move inward.
Q23: There have been reports that botnet operators are attempting to make this wormable?
A: Possible and deeply concerning. But I have not seen it manifest in the wild, but it does reiterate the criticality.
Q24: Red team notices vendors are releasing scanning tools/processes. When they come back and report within the tools, there may be false negatives. Often, services and applications require authentication before exposing input fields and headers and only exposing a required function's payload. Is one of the CIA's initiatives to vet some of these tools for credential testing and validity? What do you guys think about some of the vettings of scripts and credential scanning?
A: Tools have been evolving; we have linked on our webpage to a few. Third-Party sites have scripts that can be considered valid and updated continuously - the work is ongoing. We will not endorse a tool and say it is the best one, but we can provide guidance and trusted resources from our key partners.
Q25: What is the challenge around sharing intel?
A: We are updating our website continuously and will keep updating as long as possible.
 

Severity: High TLP: Green Threat Actors Continue to Leverage Log4J​

Tags
  1. Critical CVE
  2. Cybercriminal Attack
  3. Nation State Attack
  4. Phishing Campaign
  5. Ransomware Attack
Conti Ransomware Gang Has Full Log4Shell Attack Chain

Summary:

"The Conti ransomware gang, which became the first professional crimeware outfit to adopt and weaponize the Log4J Shell vulnerability last week, has built up a holistic attack chain.

The sophisticated Russia-based Conti group – which Palo Alto Networks has called "one of the most ruthless" of dozens of ransomware groups currently known to be active – was in the right place at the right time with the right tools when Log4 Shell hit the scene 10 days ago, security firm Advanced Intelligence (AdvIntel) said in a report shared with Threatpost on Thursday.

As of today, Monday, Dec. 20, the attack chain has taken the following form, AdvIntel’s Yelisey Boguslavskiy told Threatpost: Emotet -> Cobalt Strike -> Human Exploitation -> (no ADMIN$ share) -> Kerberoast -> brute -> vCenter ESXi with log4j shell scan for vCenter, (ThreatPost, 2021).”

Analyst Comments:
The threat actors that fall under Contis umbrella appear to be using various methods and tools to pivot to and from internal resources. They're using commodity tools and malware that have reportedly been used in attacks against multiple organizations and industries over the past few months.

Emotet was delivered via obfuscated fake installation packages, such as Adobe Reader, and disguised as legitimate .XLS files containing malicious macros. Actors are still using cobalt strike to access target systems and then leveraging LogJ4 vulnerabilities on devices attached to local network segments, "As of Wednesday, Dec. 15, Conti was looking for vulnerable VMWare networks for initial access and lateral movement. The VMware servers are on a dismayingly long list of affected components and vendors whose products have been found to be vulnerable to Log4Shell, (ThreatPost, 2021)."

The motivation for obtaining initial access is high; threat actors know that there is likely an internal asset somewhere that may be running a vulnerable version of Log4j that could be leveraged to bypass any access control placed on mission-critical systems. If they can compromise or encrypt systems that contain crown jewels, which are often hypervisors, a payout is likely due to their efforts.

Mitigation:
On CISA's call yesterday, emphasis was placed on how companies should mitigate systems utilizing vulnerable instances of Log4j. It was recommended that organizations scan and mitigate assets directly exposed to the internet first and foremost and then move inward to ones located on internal network segments. If a vulnerable server was exposed to the internet at any point time, assume compromise.

Source:
https://threatpost.com/conti-ransomware-gang-has-full-log4shell-attack-chain/177173/
 

Severity: High TLP: Green New joint advisory from CISA, FBI, NSA, and the other Five Eyes (Australia, Canada, New Zealand, UK)​

Tags
  1. Critical CVE
  2. Cybercriminal Attack
  3. Nation State Attack
  4. Ransomware Attack

https://www.cisa.gov/uscert/ncas/alerts/aa21-356a

Please see in the link above and copied below, a new joint advisory from CISA, FBI, NSA, and the other Five Eyes (Australia, Canada, New Zealand, UK) on the Log4Shell vulnerability.

Please distribute as appropriate.
--
Alert (AA21-356A) Mitigating Log4Shell and Other Log4j-Related Vulnerabilities

Summary​

The Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI), National Security Agency (NSA), Australian Cyber Security Centre (ACSC), Canadian Centre for Cyber Security (CCCS), the Computer Emergency Response Team New Zealand (CERT NZ), the New Zealand National Cyber Security Centre (NZ NCSC), and the United Kingdom’s National Cyber Security Centre (NCSC-UK) are releasing this joint Cybersecurity Advisory (CSA) to provide mitigation guidance on addressing vulnerabilities in Apache’s Log4j software library: CVE-2021-44228 (known as “Log4Shell”), CVE-2021-45046, and CVE-2021-45105. Sophisticated cyber threat actors are actively scanning networks to potentially exploit Log4Shell, CVE-2021-45046, and CVE-2021-45105 in vulnerable systems. According to public reporting, Log4Shell and CVE-2021-45046 are being actively exploited.
CISA, in collaboration with industry members of CISA’s Joint Cyber Defense Collaborative (JCDC), previously published guidance on Log4Shell for vendors and affected organizations in which CISA recommended that affected organizations immediately apply appropriate patches (or apply workarounds if unable to upgrade), conduct a security review, and report compromises to CISA or the FBI. CISA also issued an Emergency Directive directing U.S. federal civilian executive branch (FCEB) agencies to immediately mitigate Log4j vulnerabilities in solution stacks that accept data from the internet. This joint CSA expands on the previously published guidance by detailing steps that vendors and organizations with IT and/or cloud assets should take to reduce the risk posed by these vulnerabilities.
These steps include:
  • Identifying assets affected by Log4Shell and other Log4j-related vulnerabilities,
  • Upgrading Log4j assets and affected products to the latest version as soon as patches are available and remaining alert to vendor software updates, and
  • Initiating hunt and incident response procedures to detect possible Log4Shell exploitation.
This CSA also provides guidance for affected organizations with operational technology (OT)/industrial control systems (ICS) assets.
Log4j is a Java-based logging library used in a variety of consumer and enterprise services, websites, applications, and OT products. These vulnerabilities, especially Log4Shell, are severe—Apache has rated Log4Shell and CVE-2021-45046 as critical and CVE-2021-45105 as high on the Common Vulnerability Scoring System (CVSS). These vulnerabilities are likely to be exploited over an extended period. CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK strongly urge all organizations to apply the recommendations in the Mitigations section.
CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK encourage leaders of organizations to review NCSC-UK’s blog post, Log4j vulnerability: what should boards be asking?, for information on Log4Shell’s possible impact on their organization as well as response recommendations.
Note: this is an evolving situation, and new vulnerabilities are being discovered. CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK will update this CSA as we learn more about this exploitation and have further guidance to impart.
Click here for a PDF version of this report.

Disclaimer​

The information in this report is being provided “as is” for informational purposes only. CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, or NCSC-UK.

Technical Details​

Log4Shell

Log4Shell, disclosed on December 10, 2021, is a remote code execution (RCE) vulnerability affecting Apache’s Log4j library, versions 2.0-beta9 to 2.14.1. The vulnerability exists in the action the Java Naming and Directory Interface (JNDI) takes to resolve variables. Affected versions of Log4j contain JNDI features—such as message lookup substitution—that do not protect against adversary-controlled Lightweight Directory Access Protocol (LDAP), Domain Name System (DNS), and other JNDI-related endpoints.
An adversary can exploit Log4Shell by submitting a specially crafted request to a vulnerable system that causes that system to execute arbitrary code. The request allows the adversary to take full control over the system. The adversary can then steal information, launch ransomware, or conduct other malicious activity.

CVE-2021-45046

CVE-2021-45046, disclosed on December 13, 2021, enables a remote attacker to cause RCE, a denial-of-service (DoS) condition, or other effects in certain non-default configurations. This vulnerability affects all versions of Log4j from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0. In response, Apache released Log4j version 2.16.0 (Java 8).

CVE-2021- 45105

CVE-2021-45105, disclosed on December 16, 2021, enables a remote attacker to cause a DoS condition or other effects in certain non-default configurations. According to Apache, when the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. In response, Apache released Log4j version 2.17.0 (Java 8).

Impact

Log4Shell and CVE-2021-45046—rated as critical vulnerabilities by Apache—are severe because Java is used extensively across IT and OT platforms, they are easy to exploit, and applying mitigations is resource intensive. Log4Shell is especially critical because it allows malicious actors to remotely run code on vulnerable networks and take full control of systems.
According to public reporting, exploitation of Log4Shell began on or around December 1, 2021, and a proof-of-concept exploit is publicly available for this vulnerability. The FBI has observed attempted exploitation and widespread scanning of the Log4j vulnerability to gain access to networks to deploy cryptomining and botnet malware. The FBI assesses this vulnerability may be exploited by sophisticated cyber threat actors and incorporated into existing cyber criminal schemes that are looking to adopt increasingly sophisticated obfuscation techniques. According to public reporting, CVE-2021-45046 is being actively exploited as well.
CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK assess that exploitation of these vulnerabilities, especially Log4Shell, is likely to increase and continue over an extended period. Given the severity of the vulnerabilities and likely increased exploitation, CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK strongly urge all organizations to apply the recommendations in the Mitigations section to identify, mitigate, and update affected assets.
For more information on these vulnerabilities, see the Apache Log4j Security Vulnerabilities webpage.

Mitigations​

Vendors

CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK encourage vendors to:
  1. Immediately identify, mitigate, and update affected productsthat use Log4j to the latest patched version.
    1. For environments using Java 8 or later, upgrade to Log4j version 2.17.0 (released December 17, 2021) or newer.
    2. For environments using Java 7, upgrade to Log4j version 2.12.2 (released December 21, 2021). Note: Java 7 is currently end of life and organizations should upgrade to Java 8.
  2. Inform your end users of products that contain these vulnerabilities and strongly urge them to prioritize software updates. CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK strongly recommend vendors take steps to ensure messaging on software updates reaches the widest possible audience (for example, avoid placing relevant information behind paywalls). Note: CISA is actively maintaining a GitHub page and repository with patch information for products known to be affected by Log4Shell. CISA has also notified ICS vendors that may be affected and has asked them to confirm any assets affected by Log4Shell and to apply available mitigations.

Affected Organizations with IT and Cloud Assets

CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK recommend that affected organizations take the following steps to patch these vulnerabilities in their IT and cloud assets and initiate threat hunting to detect possible compromise. Organizations with OT/ICS environments should review the Organizations with OT/ICS Assets section for additional guidance. Note: this guidance includes resources that may or may not be possible for all organizations. CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK recommend that organizations apply the mitigations listed in this advisory to the extent allowed by their environments.
1. Identify vulnerable assets in your environment.
Knowing where Log4j and other affected products exist in your environment is key for protecting your networks.
  1. Inventory all assets that make use of the Log4j Java library. According to public reporting, adversaries are patching and mitigating assets they compromise to retain control of assets. To avoid missing such defense evasion, organizations should carefully track assets under investigation.
    1. Assume all versions of Java and Log4j are vulnerable and include them in the inventory.
    2. Ensure the inventory includes all assets, including cloud assets, regardless of function, operating system, or make. Ensure the inventory includes the following information about each asset
      1. Software versions
      2. Timestamps of when last updated and by whom
      3. User accounts on the asset with their privilege level
      4. Location of asset in your enterprise topology
  2. Identify the inventoried assets that are likely vulnerable.
    1. Use CISA's GitHub repository and CERT/CC's CVE-2021-44228_scanner to identify assets vulnerable to Log4Shell.
Additional resources for detecting vulnerable instances of Log4j are identified below. CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK will update the sources for detection rules as we obtain them. Note: due to the urgency to share this information, CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK have not yet validated this content.
2. Mitigate known and suspected vulnerable assets in your environment.
A. Treat known and suspected vulnerable assets as compromised. These assets should be isolated until they are mitigated and verified (step 2.D). The method of isolation that you should use depends on the criticality of the asset. Possible isolation methods include:
  • Physically removing the asset from the network (e.g., unplug the network cable);
  • Moving the asset to a “jail VLAN” with heightened monitoring and security;
  • Blocking at the network layer (a switch or some other device);
  • Implementing a firewall (including web application firewall) with strict port control and logging; or
  • Restricting the asset’s communication, especially to the internet and the rest of the enterprise network.
B. Patch Log4j and other affected products to the latest version.
  • See the Apache Log4j Security Vulnerabilities webpage (as of December 22, 2021, the latest Log4j version is 2.17.0 for Java 8 and 2.12.3 for Java 7). Note: patching or updating Java is not enough, you must upgrade the Log4j library itself.
  • For other affected products, see CISA’s GitHub page.
Note: if your organization is unable to immediately identify and patch vulnerable instances of Log4j, apply appropriate workarounds. CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK recommend using vendor-provided mitigations when available. Due to the rapidly evolving situation, these workarounds should not be considered permanent fixes and organizations should apply the appropriate patch as soon as it is made available. Additional mitigations are identified below; however, organizations should use these mitigations at their own risk as they may be incomplete, temporary, or cause harmful effects, such as application instability, a DoS condition, or log evasion.
  • Remove the Jndilookup.class from the class path. [1]
  • Ensure that older versions unable or waiting to be upgraded are configured so that the library configuration log4j2.formatMsgNoLookups is set to TRUE. Note: this mitigation is a quick response for initially identified vulnerable configurations along with patch deployment.
  • Delete or rename Jndilookup.class. Note: removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function). [2]
  • Apply a hot patch.
C. Keep an inventory of known and suspected vulnerable assets and what is done with them throughout this process. It is important to track patching because malicious cyber actors may compromise an asset and then patch it to protect their operations. Organizations should keep a meticulous record of vulnerable assets they have patched to identify whether a threat actor may have patched an asset.
D. Verify the mitigation has worked, if possible.
  1. Scan the patched/mitigated asset with the tools and methods listed in step 1.B. Use more than one method to verify the mitigation was successfully applied.
  2. Monitor the asset closely.
  3. Remain alert to changes from vendors for the software on the asset. Additionally, see CISA's GitHub page for known affected products and patch information. CISA will continually update the repository as vendors release patches.
3. Initiate hunt and incident response procedures. Given the widespread exploitation of this vulnerability, CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK encourage all organizations to assume their assets that use Log4j may have been compromised and initiate hunt procedures.
A. Hunt for signs of exploitation and compromise.
  1. Treat assets that use Log4j as suspect and conduct vigorous forensic investigation of those assets.
  2. Inspect and monitor accounts across your enterprise that exist on or connect to assets that use Log4j.
  3. Inspect changes to configurations made since December 1, 2021, and verify they were intended, especially on assets that use Log4j.
  4. Use CISA’s GitHub page to detect possible exploitation or compromise.
Additional resources to detect possible exploitation or compromise are identified below. Note: due to the urgency to share this information, CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK have not yet validated this content.
B. If compromise is detected, organizations should:
  1. Initiate incident response procedures. See the joint advisory from ACSC, CCCS, NZ NCSC, CERT NZ, NCSC-UK, and CISA on Technical Approaches to Uncovering and Remediating Malicious Activity for guidance on hunting or investigating a network, and for common mistakes in incident handling. CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK encourage organizations to see CISA’s Federal Government Cybersecurity Incident and Vulnerability Response Playbooks. Although tailored to U.S. FCEB agencies, these playbooks provide operational procedures for planning and conducting cybersecurity incident and vulnerability response activities and detail each step for both incident and vulnerability response.
  2. Consider reporting compromises immediately to applicable cybersecurity authorities. Organizations are encouraged to be as thorough as possible by including information such as IP addresses/domains used to exploit your infrastructure, exploited applications/servers, administrators contact information, and the start and end dates of the attack.
  • U.S. organizations should report compromises to CISA and the FBI.
  • Australian organizations can visit cyber.gov.au or call 1300 292 371 (1300 CYBER 1) to report cybersecurity incidents.
  • Canadian organizations can report incidents by emailing CCCS at [email protected].
  • New Zealand organizations can visit NCSC.govt.nz to report incidents.
  • UK organizations can report a significant cyber security incident at ncsc.gov.uk/report-an-incident (monitored 24 hrs) or, for urgent assistance, call 03000 200 973.
4. Evaluate and apply other mitigations.
A. Remain alert to changes from vendors for the software on the asset, and immediately apply updates to assets when notified by a vendor that their product has a patch for this vulnerability. Additionally, see CISA's GitHub repository for known affected products and patch information. CISA will continually update the repository as vendors release patches.
B. Continue to monitor Log4J assets closely. Continually use signatures and indicators of compromise that may indicate exploitation.
  1. See the exploitation and detection resources listed in step 3.A.(4).
  2. Be aware that there are many ways to obfuscate the exploit string. Do not depend on one detection method to work all the time.
C. Continue to monitor the Apache Log4j Security Vulnerabilities webpage for new updates. Note: as this is an evolving situation and new vulnerabilities in Log4J are being discovered, organizations should ensure their Apache Log4j is up to date. Identify the software your enterprise uses and stay on top of updates as these may be superseded by other updates and fixes.
D. Block specific outbound Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) network traffic.
  1. Outbound LDAP: for most networks, LDAP is used internally, but it is rare for LDAP requests to be routed outside a network. Organizations should block outbound LDAP or use an allowlist for outbound LDAP to known good destinations. Note: this may be difficult to detect on certain ports without a firewall that does application layer filtering.
  2. Remote Method Invocation (RMI): for most networks, RMI is either unused or used for internal sources. Organizations should block outbound RMI or use an allowlist for outbound RMI to known good destinations.
  3. Outbound DNS: organizations using enterprise DNS resolution can block outbound DNS from sources other than identified DNS resolvers. At a minimum, blocking direct outbound DNS from web application servers configured to use enterprise DNS resolution will mitigate the risks to those systems.
Note: blocking attacker internet IP addresses during this event is difficult due to the high volume of scanning from non-malicious researchers and vendors. The false positives on IP addresses are high. Organizations should focus on looking for signs of successful exploitation and not scans.
Affected Organizations with OT/ICS Assets
Due to the pervasiveness of the Apache Log4j software library—and the integration of the library in operational products—CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK strongly recommend that OT asset owners and operators review their operational architecture and enumerate the vulnerability status against current product alerts and advisories. If a product does not have a security advisory specifically addressing the status of the vulnerability, treat it with additional protections. CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK urge patching or deployment of mitigations to reduce the risk of the threat of these vulnerabilities.
Note: CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK recommend prioritizing patching IT devices, especially those with internet connectivity. Affected internet-facing devices as well as laptops, desktops, and tablets are especially susceptible to exploitation of these vulnerabilities. OT/ICS devices—if segmented appropriately from the IT environment—do not face the internet and, as such, have a smaller attack surface to this vulnerability. Exploitation of IT devices may affect OT/ICS devices if there is insufficient network segmentation that prevents lateral movement.
CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK recommend that OT/ICS asset owner/operators take the following guidance into consideration:
  1. Review operational architecture and enumerate the vulnerability against current product alerts and advisories. If products do not have a security advisory specifically addressing their status of the vulnerability, it is recommended to treat these devices with additional protections.
  2. Implement the steps listed in the previous section to identify and isolate vulnerable assets in the OT/ICS environment. Understand what type of products in the OT environment would be affected. Many OT/ICS-specific products incorporate vulnerable versions of the Log4j library.
  3. Use a risk-informed decision-making process to apply the latest version of hotfixes or patches to affected devices as soon as is operationally feasible. If patches cannot be applied, mitigations provided by the product’s manufacturer or reseller should be deployed. Note: CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK recommend, as quality assurance, that users test the update in a test development environment that reflects their production environment prior to installation.
  4. Minimize network exposure for all control system devices and/or systems, and ensure they are not accessible from the internet.
  5. Locate control system networks and remote devices behind firewalls and isolate them from the business network.
When remote access is required, use secure methods such as virtual private networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize that a VPN is only as secure as its connected devices.
CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK also remind organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.
CISA also provides a section for control systems security recommended practices on the ICS webpage on cisa.gov. Several recommended practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.
Additional mitigation guidance and recommended practices are publicly available on the ICS webpage on cisa.gov in the Technical Information Paper, ICS-TIP-12-146-01B--Targeted Cyber Intrusion Detection and Mitigation Strategies.
Organizations observing any suspected malicious activity should follow their established internal procedures and consider reporting compromises immediately.
  • U.S. organizations should report compromises to CISA and the FBI.
  • Australian organizations can visit cyber.gov.au or call 1300 292 371 (1300 CYBER 1) to report cybersecurity incidents.
  • Canadian organizations can report incidents by emailing CCCS at [email protected].
  • New Zealand organizations can visit NCSC.govt.nz to report incidents.
  • UK organizations can report a significant cyber security incident at ncsc.gov.uk/report-an-incident (monitored 24 hrs) or, for urgent assistance, call 03000 200 973.

Resources​

For more information, resources, and general guidance, including resources and mitigation guidance from industry members of JCDC, see CISA’s webpage Apache Log4j Vulnerability Guidance. Note: due to the prominent and ever evolving nature of this vulnerability, there are multiple unverified published guidance documents that are geared towards Log4j vulnerabilities. CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, and NCSC-UK encourage all organizations to verify information with trusted sources, such CISA, the FBI, NSA, ACSC, CCCS, CERT NZ, NZ NCSC, NCSC-UK vendors.

References​

[1] Reddit: Log4j 0day being exploited
[2] Tech Solvency: The Story So Far

Revisions​

December 22, 2021: Initial Version
 
New CISA Notification:

Subject: CISA Publishes Joint Cybersecurity Advisory to Mitigate Apache Log4J Vulnerability

INTENDED FOR WIDEST DISTRIBUTION


Critical Infrastructure Colleagues and Partners,

Today, CISA, the FBI, and NSA have been joined by their cybersecurity authority counterparts from Australia, Canada, New Zealand, and the United Kingdom to release a joint cybersecurity advisory (CSA) on Mitigating Log4Shell and Other Log4j-Related Vulnerabilities. The joint CSA includes technical details, mitigations, and resources detailing voluntary steps that vendors and organizations with information technology (IT), operational technology (OT), and cloud assets should take to respond to the Apache Log4j vulnerabilities.

CISA, the Federal Bureau of Investigation (FBI), National Security Agency (NSA), Australian Cyber Security Centre (ACSC), Canadian Centre for Cyber Security (CCCS), Computer Emergency Response Team New Zealand (CERT-NZ), New Zealand National Cyber Secure Centre (NZ NCSC), and the United Kingdom’s National Cyber Security Centre (NCSC-UK), as well as CISA’s industry partners through the Joint Cyber Defense Collaborative (JCDC), are responding to multiple vulnerabilities in Apache’s Log4j software library: CVE-2021-44228 (known as "Log4Shell"), CVE-2021-45046, and CVE-2021-45105. Malicious cyber threat actors are actively scanning networks to potentially exploit Log4Shell, CVE-2021-45046, and CVE-2021-45105 in vulnerable systems. According to public reporting, Log4Shell and CVE-2021-45046 are being actively exploited.

For vendors and organizations with IT and/or cloud assets, this joint CSA expands on the previously published CISA guidance with recommended, detailed steps to respond to these vulnerabilities, which are:
· Identify assets affected by Log4Shell and other Log4j-related vulnerabilities;
· Upgrade Log4j assets and affected products to the latest version as soon as patches are available and remaining alert to vendor software updates; and
· Initiate hunt and incident response procedures to detect possible Log4Shell exploitation.
Given the widespread exploitation of this vulnerability, organizations are encouraged to assume their assets that use Log4j may have been compromised and initiate hunt procedures. If a compromise is detected, organizations are encouraged to report it to CISA and/or the FBI.

A dedicated webpage with Log4j mitigation guidance and resources for network defenders is available on cisa.gov, as well as a community-sourced GitHub (CISAgov) repository of affected devices and services. (Note: due to the urgency to share this information, CISA has not yet validated this content.)

We encourage you to share this information broadly.

Cybersecurity and Infrastructure Security Agency
 
Log4j 2.17.1 out now, fixes new remote code execution bug

https://www.bleepingcomputer.com/ne...-now-fixes-new-remote-code-execution-bug/amp/

Summary:

Apache has released another Log4j version, 2.17.1 fixing a newly discovered remote code execution (RCE) vulnerability in 2.17.0, tracked as CVE-2021-44832.

Rated 'Moderate' in severity and assigned a 6.6 score on the CVSS scale, the vulnerability stems from the lack of additional controls on JDNI access in log4j.

"JDBC Appender should use JndiManager when accessing JNDI. JNDI access should be controlled via a system property," states the issue description seen by BleepingComputer.

"Related to CVE-2021-44832 where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code."

Impact:

Up until now, log4j vulnerabilities have been exploited by all kinds of threat actors from state-backed hackers to ransomware gangs and others to inject Monero miners on vulnerable systems.

Mitigation:

Log4j users should immediately upgrade to the latest release 2.17.1 (for Java 8). Backported versions 2.12.4 (Java 7) and 2.3.2 (Java 6) containing the fix are also expected to be released shortly.

Vulnerability Write Up:

 

Severity: Medium TLP: Green Aquatic Panda Infiltrated Academic Institution Through Log4j Vulnerability, Says CrowdStrike

Summary:
“Cybersecurity company CrowdStrike has discovered an attempt by a China-based group to infiltrate an academic institution through the Log4j vulnerability. CrowdStrike called the group "Aquatic Panda" and said it is an "intrusion adversary with a dual mission of intelligence collection and industrial espionage" that has operated since at least May 2020” (ZDNet, 2022).
The group's attack was disrupted by the institution, so their motives are still unclear. The group is known to maintain persistence in networks to steal intellectual property and other industrial trade secrets. They typically focus on entities in telecommunications, technology, and the government sector.

Analyst Comments:
CrowdStrike saw suspicious activity coming from Tomcat processes running under a vulnerable VMWare Horizon instance at a large academic institution. They believe the group was using a modified version of the Log4j exploit. Aquatic Panda used a public GitHub project from December 13th to gain access to the vulnerable VMWare Horizon instance.

Using native OS binaries, the group attempted to elevate privileges and tried to stop a third party endpoint detection and response device. The victim organization was able to quickly implement their incident response protocol, eventually patching the vulnerable application and preventing further threat actor activity on the host.

“CrowdStrike officials told ZDNet that they are seeing various threat actors both inside and outside of China leveraging the Log4J vulnerability, with adversaries ranging from advanced threat actors to eCrime actors. In the end, the viability of this exploit is well-proven with a substantial attack surface still present. We will continue to see threat actors making use of this vulnerability until all recommended mitigations are put into place” (ZDNet, 2022).

Mitigation:
Numerous groups from North Korea, Iran, Turkey and China have been seen exploiting the vulnerability alongside a slate of ransomware groups and cybercriminal organizations. CISA Director Jen Easterly said Log4j vulnerabilities present a severe and ongoing threat to organizations and governments around the world.

Log4Shell Scanning Software:
https://github.com/NCSC-NL/log4shell/blob/main/scanning/README.md

Known Vulnerable Software:
https://github.com/NCSC-NL/log4shell/blob/main/software/software_list_c.md

Source:
https://www.zdnet.com/article/apt-g...tion-through-log4j-vulnerability-crowdstrike/