Log4j Vulnerability Information

[Ian Andriechack]

Hey everyone, I just jumped off CISA's call; here are my notes in case you were unable to attend:

The general census, regardless of versions utilized, includes 1, upgrade to versions 2.15.

Introduction:

• Experts note that it is one of the most serious they've ever seen throughout their career
• CISA is focusing on identifying vulnerable assets and assisting in applying mitigation measures
• APT Groups will exploit, limited time to correct vulnerabilities
• Holiday season, so it is likely threat actors will exploit this vulnerability over the holiday season. Geopolitical tension could also significantly increase the likelihood of impact
• Make sure cybersecurity staff, and IT are heightened over the holiday
• Check public-facing appliances, make sure they are secure
• Share information with your constituents and groups
• Please share with CISA so they can distribute and help others
• Twitter is being used to distribute various pieces of information regarding the vulnerability

Mitigation for network defenders and operators:
What is log4j?

• Open-source java-based logging utility – 300 billion devices, enterprise software (on-prem/cloud) to IoT
• Open source, maintained by Apache. Released in 2021 originally (Birthday January)
• September 2013 to release of last week are vulnerable
• Exploit has been shared on Twitter; unauthenticated, remote code execution vulnerability-- it's 12 characters long as is considered trivial
• Does not require permissions, worst type of vulnerability
• Result, an attacker could take control of the system if exploited
• POCs are making exploit very easy
• No network access or privileges restrictions
• Approximately 100's of millions of devices are vulnerable
• CISA is working with vendors to make sure they know they are vulnerable and may no longer receive support from manufacturers.
• Network defenders look back to the first of the month for externally facing devices where the software is installed for indicators of compromise.
• External devices, actors may patch behind companies. Implement change control

Mitigation:

• Scan applications for vulnerable versions 2.0 beta 1 to 2.14.1
• Upgrade 2.15 as soon as possible, not feasible?
• Work with vendors on hardening devices that cannot be upgraded
• Security operations center
• Action every single alert on a device that is running log4j
• When there is a vulnerability in a logging system, it's likely that it may not be logged if exploited, so every alert needs to be reviewed.
• If you do not know where it's not installed
• Upgrade WAF's with the latest rules. They are using mask scanning techniques which WAFs stop

Q/A

• Q1: Ransomware, vulnerability be leveraged to deploy ransomware?
  • Absolutely, they may deploy crypto miners first. Safe to assume actors will leverage it for various malicious activities, including ransomware.
• Q2: Applying defense in depth - other than what was mentioned, should we/be doing or looking for anything else?
  • Threat activity is changing; new IOCs will be released and published. Multi-week process, new actors will leverage the vulnerability. We should expect this picture to change rapidly.
• Q3: Are there indicators that this may have intentionally been placed into the repository.
  • Currently, there is no evidence that this is a supply-chain attack
• Q4: Vulnerability is not exposed if you use the newer versions of Java runtime?
  • Not able to validate whether running updating version provides authoritative protection.
• Q5: If people do update 2.15, we are good?
  • Yes, but it does not mean that an actor could have already leveraged it before deploying the patch.
• Q6: Can you repeat which versions are at risk?
  • 2.0 – beta 9 to 2.1.4.1
  • 21st of September 2013 to the 6th of December 2021 are vulnerable to exploitation
• Q7: Will CISA have tools that companies can use to scan networks, are a customer at the Albert network seeing an activity?
  • Cyber Hygiene service (learn more at cisa.gov)
  • Notifying entities that are part of the service if they are vulnerable
  • Limited signatures at this point to scan for
• Q8: Version 2.0 beta and versions one isn't supported anymore? Version 1 vulnerable?
  • Negative
• Q9: Weblink, can you share it so we can use it to do a comparison between organizations?
  • Website = going live shortly
  • Will be shared through CISA.gov, ISACS, and other online profiles
• Q10: Standing up a website? When will it be online? Log4j version 1 is speculation that this version is good, but if you are using JMS class, it's not true, correct?
  • Shooting for the next day
  • We are glad to look more deeply into that point.
• Q11: Is CISA going to have specific guidance for version 1?
  • Not an immediate focus, we are focusing on the recently released CVE
• Q12: Should we enable MFA?
  • Always enable MFA and any other additional layers of security that are available.
  • These are all good practices to implement outside of the context of the actual vulnerability.
• Q13: On the website, will there be a list of "bad-actor" Ip addresses exploiting available ports? So, you know, we can get a block list going on firewalls and things like that?
  • We include effective measures and mitigations that network defenders can deploy
  • Not feasible, tracking IPs would be changing and will grow, and grow due to the how many devices are vulnerable and how many actors are likely to exploit the vulnerability.
• Q14: IBMs, IDRAC, and stuff administrators are using. Is there a way to exploit systems and devices like these?
  • The logging component is a wide variety of devices.
  • There is no evidence of KVMs or iDRAC being exploited
  • But these devices are highly susceptible to attack due to the information stored on them.
  • Update these devices.
• Q15: Scope of mitigation, the primary one of course update. Many organizations can't. Is there a combination of mitigations?
  • We want to provide a single place where companies can view a list of mitigation measures and aggregate information if companies are unable to patch.
• Q16: (Points) We discovered hundreds of devices running the software; a lot of them are internal no internet access. However, a lot are cloud, so they are communicating with an external vendor. Unfortunately, we do not have control through these devices because they are on a vendor's private network; we are the middleman – we have no management. So, it will take more than our mitigation; most of our prominent, well-known vendors are right on top of the vulnerability and have resources for review. Work with your vendors to make sure you are good-to-go companies with which you may do business.
  • Thank you for the points; there are risks associated with utilizing the cloud if they are vulnerable.
  • CISA's goal is to provide information for entities of different maturity.
• Q17: Dish network organization admits to seeing scan attempts on their vulnerable equipment
  • Great, that is what we are observing too.
• Q18: DDoS and KinSing are being deployed as a final payload, as well as cobalt strike beacons. What's going on with them cobalt strike beacons?
  
  • Nothing categorically different than we just outlined.

 

[MJ Shoer]

Hey everyone, just jumped off CISA's call, here are my notes incase you were unable to attend:

Log4J

General census, regardless of versions utilized, including 1 is to upgrade to versions 2.15.

Introduction:

· Experts note that it is one of the most serious they’ve ever seen throughout their career

· CISA is focusing on identify vulnerable assets and assisting in applying mitigation measures

· APT Groups will exploit, limited time to correct vulnerabilities

· Holiday season so it is likely threat actors will exploit this vulnerable over the holiday season. Geopolitical tension could also greatly increase the likelihood of impact

· Make sure cybersecurity staff and IT are heightened over the holiday

· Check public facing appliances, make sure they are secure

· Share information with your constituents and groups

· Please share with CISA so they can distribute and help others

· Twitter is being used distribute various pieces of information regarding the vulnerability

Mitigation for network defenders and operators:

Details:

Ø High-level

What is log4j?

· Open-source java-based logging utility – 300 billion devices, enterprise software (on prem/cloud) to IOT

· Open source, maintained by Apache. Released in 2021 originally (Birthday January)

· September 2013 to release of last week are vulnerable

· Exploit has been shared on twitter; unauthenticated remote code execution vulnerability-- its 12 characters long as is considered trivial

· Does not require permissions, worst type of vulnerability

· Result, an attacker could take control of the system if exploited

· POCs are making exploit very easy

· No network access or privileges restrictions

· Approximately 100’s of millions of devices vulnerable

· CISA is working with vendors to make sure they know they are vulnerable as well as ones that may no longer receiving support from manufacturers.

· Network defenders look back to the first of the month for externally facing devices where the software is installed for indicators of compromise.

· External devices, actors may patch behind companies. Implement change control

Mitigation:

o Scan applications for vulnerable versions 2.0 beta 1 to 2.14.1

o Upgrade 2.15 as soon as possible, not feasible?

§ Work with vendors on hardening devices that cannot be upgraded

o Security operations center

§ Action every single alert on a device that are running log4j

· When there is a vulnerability in a logging system, its likely that it may not be logged if exploit, so every alert needs to be reviewed.

§ If you do not know where it’s not installed

· Upgrade WAF’s with the latest rules. They are using mask scanning techniques which are stopped by WAFs

Q/A

Q1: Ransomware, vulnerability be leveraged to deploy ransomware?

· Absolutely, they may deploy crypto miners first. Safe to assume actors will leverage it for a variety of malicious activity, including ransomware.

Q2: Applying defense in depth - other than what was mentioned, should we/be doing or looking for anything else?

· Threat activity is changing, there will be new IOCs released and published. Multi week process, new actors will leverage the vulnerability. We should expect this picture to change rapidly.

Q3: Is there indicators yet, that this may have intentionally been placed into the repository purposely.

· Currently there is no evidence that this is a supply-chain attack

Q4: Vulnerability is not exposed if you are using the newer versions of Java runtime?

· Not able to validate whether running updating version provides authoritative protection.

Q5: If people do update 2.15, were good?

· Yes, but does not mean that an actor could have already leveraged it before the patch was deployed.

Q6: Can you repeat again which versions are at risk?

2.0 – beta 9 to 2.1.4.1

21st of September 2013 to the 6th of December 2021 are vulnerable to exploitation

Q7: Will CISA have tools that companies can use to scan networks, are customer at the albert network seeing an activity?

· Cyber Hygiene service (learn more at cisa.gov)

· Notifying entities that are part of the service if they are vulnerable

· Limited signatures at this point to scan for

Q8: Version 2.0 beta and versions 1 isn’t support anymore? Version 1 vulnerable?

· Negative

Q9: Weblink can you share it so we can use it to do a compare between organizations?

· Website = going live shortly

· Will be share through CISA.gov, ISACS, and other online profiles

Q10: Standing up a website? When will it be online? Log4j version 1, there speculation saying that this version is good but if you are using JMS class, it’s not true, correct?

· Shooting for the next day

· We are glad to look more deeply into that point.

Q11: Is CISA going to have specific guidance for version 1?

· Not an immediate focus, we are focusing on the recently released CVE

Q12: Should we enable MFA?

· Always enable MFA and any other additional layers of security that are available.

· These are all good practices to implement outside of the context of the actual vulnerability.

Q13: On the website, is there going to be a list of “bad-actor” Ip addresses exploiting known ports? So, you know, we can get a block list going on firewalls and things like that?

· We are including effective measures and mitigations that network defenders can deploy

· Not feasible, tracking Ips would be changing and will grow, and grow due to the how many devices are vulnerable and how many actors are likely to exploit the vulnerability.

Q14: IBMs, IDRAC, and stuff administrators are using, is there way to exploit systems and devices like these?

· The logging component is a wide variety of devices.

· There is no evidence of KVMs or iDRAC being exploited

· But these devices are highly susceptible to attack due to the type of information stored on them.

· Update these devices.

Q15: Scope of mitigation, primary one of course update. Many organizations can’t, is there a combination of mitigations?

· We want to provide a single place where companies can go to view a list of mitigation measures and aggregate information if companies are unable to patch.

Q16: (Points) We discovered hundreds of devices running the software, a lot of them are internal no internet access, however a lot are cloud, so they are communicating with an external vendor. Unfortunately, we do not have control through these devises because they are on a vendor’s private network, we are the middleman – we have no management. So, it will take more than our mitigation, most of our large well-known vendors are right on top of the vulnerability and have resources for review. Work with your vendors to make sure you are good to go companies that you may do business with.

· Thank you for the points, there are risks associated with utilizing the cloud if they are vulnerable.

· CISA’s goal is to provide information for entities of different maturity.

Q17: Dish network organization admits to seeing scan attempts on their vulnerable equipment

· Great, that is what we are observing too.

Q18: DDoS and KinSing are being deployed as a final payload, as well as cobalt strike beacons. What’s going on them cobalt strike beacons?

· Nothing categorically different than we just outlined.

Excellent recap Ian, thank you. There was a lot covered on this call.

 

[Ian Andriechack]

Critical Infrastructure partners,

On December 10, 2021, the Apache Software Foundation released a security advisory to address a remote code execution vulnerability (CVE-2021-44228) affecting Log4j versions 2.0-beta9 to 2.14.1. A remote adversary could exploit this vulnerability to take control of an affected system. Log4j is an open-source, Java-based logging utility widely used by enterprise applications and cloud services.

The Cybersecurity and Infrastructure Security Agency (CISA) is working closely with its public and private sector partners to proactively address a critical vulnerability affecting products containing the log4j software library. This vulnerability, which is being widely exploited by a growing set of threat actors, presents an urgent challenge to network defenders given its broad use.

End users will be reliant on their vendors, and the vendor community must immediately identify, mitigate, and patch the wide array of products using this software. Vendors should also be communicating with their customers to ensure end users know that their product contains this vulnerability and should prioritize software updates.

To help those efforts, CISA added a page to its CISA.gov website today, listing the mitigation actions critical infrastructure partners and stakeholders should take immediately to address the Apache Log4j vulnerability.

Working closely with our interagency and critical infrastructure partners, CISA is focused on sharing timely cyber threat information with the intent to disrupt malicious cyber activity and help our critical infrastructure partners protect their networks.

 

[Ian Andriechack]

Additional Resources:

RCE in Log4j / Log4Shell or how things can get bad quickly

InfoSec Handlers Diary Blog - SANS Internet Storm Center

RCE in log4j, Log4Shell, or how things can get bad quickly, Author: Bojan Zdrnja

isc.sans.edu

Log4Shell Exploited to Implant Coin Miners

InfoSec Handlers Diary Blog - SANS Internet Storm Center

Log4Shell exploited to implant coin miners, Author: Renato Marinho

isc.sans.edu

Log4Shell Live Stream

Log4Shell Followup: What we see and how to defend, and how to access our data

Log4j / Log4Shell Followup: What we see and how to defend (and how to access our data) - SANS Internet Storm Center

SANS Internet Storm Center - A global cooperative cyber threat / internet security monitor and alert system. Featuring daily handler diaries with summarizing and analyzing new threats to networks and internet security events.

isc.sans.edu

Log4j Zero-Day

Log4Shell: RCE 0-day exploit found in log4j, a popular Java logging package | LunaTrace

Given how ubiquitous log4j is, the impact of this vulnerability is quite severe. Learn how to fix Log4Shell, why it's bad, and what a working exploit requires in this post.

www.lunasec.io

List of Vendor Bulletins

https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

List of Vulnerable Software

log4shell/software at main · NCSC-NL/log4shell

Operational information regarding the log4shell vulnerabilities in the Log4j logging library. - NCSC-NL/log4shell

github.com

Official log4j Website

Apache Log4j :: Apache Log4j

logging.apache.org

log4j 2.16 Update which fixes some remaining JNDI related issues

- ASF JIRA

issues.apache.org

 

[Ian Andriechack]

Ransomware Deployed:

• https://businessinsights.bitdefende...vulnerability-in-log4j2-exploited-in-the-wild

I am also curious if the attack on Kronos may be associated... According to reporting, their third-party cloud provider was hit, with MFA and standard security protocols implemented.

 

[Jonathan Braley]

Log4Shell IoCs 12-14-2021 Pt1: https://station.trustar.co/constellation/reports/93c0a479-9e3f-4b3f-b126-156b2b5fe01e
Log4Shell IoCs 12-14-2021 Pt2: https://station.trustar.co/constellation/reports/265ff465-7eb1-410f-ad36-1833fcf16eca

 

[Ian Andriechack]

Additional tools for detection:

• incidentresponse/Get-Log4shellVuln.ps1
  • https://github.com/sp4ir/incidentresponse/blob/main/Get-Log4shellVuln.ps1
• Check-log4j/check-log4j.ps1
  • https://github.com/devotech/Check-log4j/blob/main/check-log4j.ps1
• Log4j overview Scanning software
  • https://github.com/NCSC-NL/log4shell/blob/main/scanning/README.md

I have not used any of these myself, but they were shared with us via a reliable source. As with any piece of software acquired from the internet, I would recommend running them in an isolated environment, separate from your production networks.

 

[MJ Shoer]

Severity: High TLP: Green Hackers Exploit Log4j Vulnerability to Infect Computers with Khonsari Ransomware​

Tags

1. Cybercriminal Attack
2. Ransomware Attack

Hackers Exploit Log4j Vulnerability to Infect Computers with Khonsari Ransomware

Summary:
“Romanian cybersecurity technology company Bitdefender on Monday revealed that attempts are being made to target Windows machines with a novel ransomware family called Khonsari as well as a remote access Trojan named Orcus by exploiting the recently disclosed critical Log4j vulnerability. The attack leverages the remote code execution flaw to download an additional payload, a .NET binary, from a remote server that encrypts all the files with the extension ".khonsari" and displays a ransom note that urges the victims to make a Bitcoin payment in exchange for recovering access to the files, (TheHackerNews, 2021).”

Analyst Comments:
It was only a matter of time before a ransomware attack would be confirmed after the log4j vulnerability was disclosed. Initially, some were unsure how the vulnerability could be leveraged in an actual cuber-attack. This report from Bitdefender confirms that ransomware operators will more than likely continue to leverage the vulnerability for some time.

Mitigation:
CISA released its website, which is dedicated to assisting companies in remediating vulnerabilities associated with CVE-2021-44228.

• https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
• Microsoft blog: Guidance for Preventing, Detecting, and Hunting for CVE-2021-44228 Log4j 2 Exploitation
• Cisco Talos Intelligence Group - Comprehensive Threat Intelligence: Threat Advisory: Critical Apache Log4j vulnerability being exploited in the wild
• Palo Alto Networks blog: Apache log4j Vulnerability CVE-2021-4428: Analysis and Mitigations
• CrowdStrike blog: Log4j2 Vulnerability Analysis and Mitigation Recommendations
• IBM Security Intelligence blog: How Log4j Vulnerability Could Impact You
• Tenable blog: CVE-2021-44228: Proof-of-Concept for Critical Apache Log4j Remote Code Execution Vulnerability Available (Log4Shell)
• Broadcom's Symantec Enterprise blog: Apache Log4j Zero-Day Being Exploited in the Wild content
• Splunk's blog: Log4Shell - Detecting Log4j Vulnerability (CVE-2021-44228) Continued
• VMware Blog: Log4j Vulnerability Security Advisory: What You Need to Know
• Investigating CVE-2021-44228 Log4Shell Vulnerability: VMWare Threat Research

Source:
https://businessinsights.bitdefende...vulnerability-in-log4j2-exploited-in-the-wild
https://thehackernews.com/2021/12/hackers-exploit-log4j-vulnerability-to.html

 

[Ian Andriechack]

According to a new Apache Log4j security bulletin, version 2.15.0 and the initially suggested mitigation measures do not completely address the Log4Shell in certain custom configurations.

It was discovered that version 2.15.0 would still be vulnerable when the configuration has a pattern layout containing a Context Lookup (for example, $${ctx:loginId}), or a Thread Context Map pattern %X, %mdc, or %MDC. In these cases, when the attacker manages to control the Thread Context values, JNDI lookup injections may be possible, resulting in JNDI connections. Version 2.15.0 limited JNDI connections to 'localhost’' but this possibility could result in a denial of service (DoS) or worse.

Therefore, a new version (2.16.0) has been made available to completely fix the issue (so far at least) associated with CVE-2021–45046 along with more effective mitigation measures for versions to 2.x versions:

• Java 8 (or later) users should upgrade to release 2.16.0.
• Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
• Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

The mitigation measures previously reported, such as setting the log4j2.formatMsgNoLookups variable to ‘true’, is not considered fully effective. The advisory says:

"The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.".

So, if you could not upgrade to versions 2.15.0 or 2.16.0 and followed previous mitigations, you are advised to remove JndiLookup class from the log4j-core jar to mitigate the vulnerability.

The advisory is available at: https://logging.apache.org/log4j/2.x/security.html

Source: https://isc.sans.edu/diary/rss/28134

 

[Ian Andriechack]

We have seen this before, passing along ?

Second Log4j vulnerability discovered, patch already released
Apparently the patch for the first vulnerability was "incomplete."

A second vulnerability involving Apache Log4j was found on Tuesday after cybersecurity experts spent days attempting to patch or mitigate CVE-2021-44228.

The description of the new vulnerability, CVE 2021-45046, says the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was "incomplete in certain non-default configurations."

"This could allow attackers... to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack," the CVE description says.

Apache has already released a patch, Log4j 2.16.0, for this issue. The CVE says Log4j 2.16.0 fixes the problem by removing support for message lookup patterns and disabling JNDI functionality by default. It notes that the issue can be mitigated in prior releases by removing the JndiLookup class from the classpath.

John Bambenek, principal threat hunter at Netenrich, told ZDNet the solution is to disable JNDI functionality entirely (which is the default behavior in the latest version).

"At least a dozen groups are using these vulnerabilities so immediate action should be taken to either patch, remove JNDI, or take it out of the classpath (preferably all of the above)," Bambenek said.

The original flaw in Log4j, a Java library for logging error messages in applications, has dominated headlines since last week. Exploits started on December 1, according to Cloudflare, and an initial alert by CERT New Zealand sparked others by CISA and the UK's National Cyber Security Centre.

The Dutch National Cyber Security Center released a lengthy list of software that is affected by the vulnerability.

International security company ESET released a map showing where Log4j exploitation attempts have been made, with the highest volume occurring in the US, UK, Turkey, Germany, and the Netherlands.A second vulnerability involving Apache Log4j was found on Tuesday after cybersecurity experts spent days attempting to patch or mitigate CVE-2021-44228.
The description of the new vulnerability, CVE 2021-45046, says the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was "incomplete in certain non-default configurations."

"This could allow attackers... to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack," the CVE description says.

Apache has already released a patch, Log4j 2.16.0, for this issue. The CVE says Log4j 2.16.0 fixes the problem by removing support for message lookup patterns and disabling JNDI functionality by default. It notes that the issue can be mitigated in prior releases by removing the JndiLookup class from the classpath.

John Bambenek, principal threat hunter at Netenrich, told ZDNet the solution is to disable JNDI functionality entirely (which is the default behavior in the latest version).

"At least a dozen groups are using these vulnerabilities so immediate action should be taken to either patch, remove JNDI, or take it out of the classpath (preferably all of the above)," Bambenek said.

The original flaw in Log4j, a Java library for logging error messages in applications, has dominated headlines since last week. Exploits started on December 1, according to Cloudflare, and an initial alert by CERT New Zealand sparked others by CISA and the UK's National Cyber Security Centre.

The Dutch National Cyber Security Center released a lengthy list of software that is affected by the vulnerability.

International security company ESET released a map showing where Log4j exploitation attempts have been made, with the highest volume occurring in the US, UK, Turkey, Germany, and the Netherlands.

Sources:

Second Log4j vulnerability discovered, patch already released

Apparently, the patch for the first vulnerability was "incomplete."

www.zdnet.com

 

[MJ Shoer]

Severity: High TLP: Green Second log4j Vulnerability Discovered, Patch to version 2.16​

Tags

1. Cybercriminal Attack

Summary:
A second vulnerability involving Apache Log4j was found on Tuesday after cybersecurity experts spent days attempting to patch or mitigate CVE-2021-44228.

The description of the new vulnerability, CVE 2021-45046, says the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was "incomplete in certain non-default configurations."

"This could allow attackers... to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack," the CVE description says.

Analyst Comments:
This is not the first time an incomplete patch has been released for a critical vulnerability. This can be a headache for patching because the swath of devices and systems that may using this particular piece of software. Teams will have backtrack and patch again, after the previous recommendation was to upgrade versions to 2.15, this is unfortunate news.

"Apache has already released a patch, Log4j 2.16.0. The CVE says Log4j 2.16.0 fixes the problem by removing support for message lookup patterns and disabling JNDI functionality by default. It notes that the issue can be mitigated in prior releases by removing the JndiLookup class from the classpath, (ICSSANS, 2021)."

Since the release of the original vulnerability researchers have said that they have observed "At least a dozen groups are using the vulnerabilities so immediate action should be taken to either patch, remove JNDI, or take it out of the classpath, (Apache, 2021)."

MItigation:
Apache has released another update, version 2.16, available here:

• https://logging.apache.org/log4j/2.x/download.html

Sources:
Log4j – Download Apache Log4j 2

Second Log4j vulnerability discovered, patch already released | ZDNet​

Apparently the patch for the first vulnerability was "incomplete."

www.zdnet.com
Debian -- Security Information -- DSA-5020-1 apache-log4j2

 

[Jonathan Braley]

Microsoft has publicly stated that they have seen Log4J exploitation activity from China, Iran, North Korea, and Turkey. Mandiant has seen Chinese and Iranian activity and plans to release a report to customers today on the activity. Please check out Microsoft's post under the "Nation-state activity" section for more details.

https://www.microsoft.com/security/...ting-for-cve-2021-44228-log4j-2-exploitation/

 

[Jonathan Braley]

Large list of impacted organizations tracked by CISA - https://github.com/cisagov/log4j-affected-db

 

[MJ Shoer]

Severity: High TLP: Green Log4j Flaw: Now State-Backed Hackers Are Using Bugs as Part of Attacks, Warns Microsoft​

Tags

1. Critical CVE
2. Cybercriminal Attack

Log4j Flaw: Now State-Backed Hackers Are Using Bugs as Part of Attacks, Warns Microsoft

Summary:
“State-sponsored hackers from China, Iran, North Korea and Turkey have started testing, exploiting and using the Log4j bug to deploy malware, including ransomware, according to Microsoft.

As predicted by officials at the US Cybersecurity and Infrastructure Security Agency (CISA), more sophisticated attackers have now started exploiting the so-called Log4Shell bug (CVE-2021-44228), which affects devices and applications running vulnerable versions of the Log4j Java library. It's a potent flaw that allows remote attackers to take over a device after compromise.

CISA officials on Tuesday warned that hundreds of millions of enterprise and consumer devices are at risk until the bug is patched, (ZDNet, 2021).”

Analyst Comments:
Analysts from Microsoft observed scanning and post-exploitation activities, “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. Microsoft has observed activities including installing coin miners, Cobalt Strike to enable credential theft and lateral movement, and exfiltrating data from compromised systems, (Microsoft, 2021).”

Mitigation:
Actors will continue to exploit this vulnerability for extended periods of time. Apache released yet another update 2.16, the previous patch 2.15 was determined to be incomplete, "Apache has already released a patch, Log4j 2.16.0. The CVE says Log4j 2.16.0 fixes the problem by removing support for message lookup patterns and disabling JNDI functionality by default. It notes that the issue can be mitigated in prior releases by removing the JndiLookup class from the classpath, (ICSSANS, 2021)."

Source:
https://isc.sans.edu/diary/rss/28134
https://www.zdnet.com/article/log4j...using-bug-as-part-of-attacks-warns-microsoft/

 

[Jonathan Braley]

NCSC - Log4j Overview Scanning Software

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

DISCLAIMER: We do not endorse any products or services. Please use these tools at your own risk. These have been provided by the UK’s NCSC.

--


Checks if the application is vulnerable to CVE-2021-44228:

Source	Notes	Links
Canary Tokens	Log4Shell Vulnerability Tester	https://canarytokens.org/generate
crypt0jan	Perform a scan of a single host (using Powershell) to see if it's vulnerable	https://github.com/crypt0jan/log4j-powershell-checker
Diverto	Nmap NSE scripts to check against log4shell	https://github.com/Diverto/nse-log4shell
Dtact	DIVD-2021-00038 log4j scanner Scan paths including archives for vulnerable log4	https://github.com/dtact/divd-2021-00038--log4j-scanner
Deepfence ThreatMapper	Apache v2, powerful runtime vulnerability scanner for kubernetes, virtual machines and serverless	https://github.com/deepfence/ThreatMapper
FullHunt	Open detection and scanning tool (Python) for discovering and fuzzing for Log4J vulnerability	https://github.com/fullhunt/log4j-scan
Fox-IT	A script to scan the filesystem to find Log4j2 that is vulnerable to Log4Shell (CVE-2021-44228) (Python)	https://github.com/fox-it/log4j-finder
Grype	Open source vulnerability scanner (docker), picks up nested JARs containing log4j	https://github.com/anchore/grype
Huntress	Online Log4Shell Vulnerability Tester	https://log4shell.huntress.com/
logpresso	Scans for java files that are vulnerable and may rename it for mitigation	https://github.com/logpresso/CVE-2021-44228-Scanner
Northwave Security	Northwave Log4j CVE-2021-44228 checker (python)	https://github.com/NorthwaveSecurity/log4jcheck
Northwave Security	Northwave Log4j CVE-2021-44228 checker Powershell version	https://github.com/crypt0jan/log4j-powershell-checker
OlafHaalstra	Scans a list of URLs with GET or POST request with user defined parameters (python)	https://github.com/OlafHaalstra/log4jcheck
righel	Nmap NSE script to inject jndi payloads with customizable templates into HTTP targets	https://github.com/righel/log4shell_nse
silentsignal	Log4Shell scanner for Burp Suite	https://github.com/silentsignal/burp-log4shell

Log4j2 Detection​

Checks if the application or system is using Log4j2.

Source	Notes	Links
1lann	Scans a file or folder recursively for jar files that may be vulnerable	https://github.com/1lann/log4shelldetect
Devotech	Powershell: Queries domain servers and scans for log4j-core files. (slow)	https://github.com/devotech/check-log4j
NCCgroup	Version hashes (MD5, SHA1 and SHA256) for log4j2 versions	https://github.com/nccgroup/Cyber-Defence/tree/master/Intelligence/CVE-2021-44228
Neo23x0	Florian Roth Log4j2 detection script	https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
sp4ir	Powershell script to detect Log4Shell	https://github.com/sp4ir/incidentre...d753f0de3fa1adc6ec326ed/Get-Log4shellVuln.ps1
Syft	Open source SBOM scanner, can detect all dependencies including log4j	https://github.com/anchore/syft/
Kelvin Tegelaar	Open sourced(MIT license) PowerShell log4j detection. Uses "Everything" to prevent high system load	https://www.cyberdrain.com/monitoring-with-powershell-detecting-log4j-files/

 

[MJ Shoer]

Severity: High TLP: Green Hackers Begin Exploiting Second Log4j Vulnerability as a Third Flaw Emerges​

Tags

1. Critical CVE
2. Cybercriminal Attack
3. Nation State Attack

Hackers Begin Exploiting Second Log4j Vulnerability as a Third Flaw Emerges

Summary:
Microsoft and Cloudflare on Wednesday revealed that threat actors are actively attempting to exploit the Log4j vulnerabilities, "MSTIC has observed PHOSPHORUS, an Iranian actor that has been deploying ransomware, acquiring and making modifications of the Log4j exploit. We assess that PHOSPHORUS has operationalized these modifications. In addition, HAFNIUM, a threat actor group operating out of China, has been observed utilizing the vulnerability to attack virtualization infrastructure to extend their specific targeting. In these attacks, HAFNIUM-associated systems were observed using a DNS service typically associated with the testing activity to fingerprint systems, (Microsoft, 2021)."

Analyst Comments:
It was disclosed that a second vulnerability could result in a DOS attack on systems/software where the logging tool may be used. IT Teams scrambled to apply version 2.15 across as many vulnerable devices as possible, only to find out the patch was incomplete. Apache released version 2.16; it was thought that the only additional vulnerability would result in a denial of service attack – essentially causing a targeted system to become unresponsive. However, researchers warn of a third separate security weakness in Log4j version 2.15.0 that can "allow for exfiltration of sensitive data in certain circumstances." Technical details of the flaw have been withheld to prevent further exploitation, but it's not immediately clear if this has been already addressed in version 2.16.0.

Mitigation:
We have shared various tools, indicators of compromise, and APT we have come across due to this recently disclosed bug. CISA has a website that contains a plethora of resources companies can use to assess risk and apply mitigation measures as necessary. Additional vulnerabilities will likely be disclosed with due time; companies should continue to monitor inbound and outbound traffic from resources that may utilize log4j.

Apache Log4j Vulnerability Guidance

• https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance

Mitigation Guidance from JCDC Partners

• Broadcom's Symantec Enterprise blog: Apache Log4j Zero-Day Being Exploited in the Wild content
• Cisco Talos Intelligence Group - Comprehensive Threat Intelligence: Threat Advisory: Critical Apache Log4j vulnerability being exploited in the wild
• Cloudflare Blog: CVE-2021-44228 - Log4j RCE 0-day mitigation
• CrowdStrike blog: Log4j2 Vulnerability Analysis and Mitigation Recommendations
• IBM Security Intelligence blog: How Log4j Vulnerability Could Impact You
• Investigating CVE-2021-44228 Log4Shell Vulnerability: VMWare Threat Research
• Mandiant blog: Log4Shell Initial Exploitation and Mitigation Recommendations
• Microsoft blog: Guidance for Preventing, Detecting, and Hunting for CVE-2021-44228 Log4j 2 Exploitation
• Palo Alto Networks blog: Apache log4j Vulnerability CVE-2021-4428: Analysis and Mitigations
• Splunk's blog: Log4Shell - Detecting Log4j Vulnerability (CVE-2021-44228) Continued
• Tenable blog: CVE-2021-44228: Proof-of-Concept for Critical Apache Log4j Remote Code Execution Vulnerability Available (Log4Shell)
• VMware Blog: Log4j Vulnerability Security Advisory: What You Need to Know

Source:
https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
https://thehackernews.com/2021/12/hackers-begin-exploiting-second-log4j.html
https://www.microsoft.com/security/...ting-for-cve-2021-44228-log4j-2-exploitation/

 

[MJ Shoer]

Sharing this important list of vulnerable and safe software. Will pin this to the top of this thread as well. It's also embedded in the resource list further up/down (depending where you are reading this in the list) in this thread.

log4shell/software at main · NCSC-NL/log4shell

Operational information regarding the log4shell vulnerabilities in the Log4j logging library. - NCSC-NL/log4shell

github.com

 

[MJ Shoer]

Severity: High TLP: Green Holiday White House Letter Emphasizes the Importance of Heightened Security Awareness​

Tags

1. Untagged

Holiday White House Letter Emphasizes the Importance of Heightened Security Awareness

Summary:
The holidays are an opportunity to spend time with our loved ones and enjoy some well-earned rest. Unfortunately, malicious cyber actors are not taking a holiday – and they can ruin ours if we’re not prepared and protected. Historically we have seen breaches around national holidays because criminals know that security operations centers are often short-staffed, delaying the discovery of intrusions.

Beyond the holidays, though, we’ve experienced numerous recent events that highlight the strategic risks we all face because of the fragility of digital infrastructure and the ever- present threat of those who would use it for malicious purposes.

Analyst Comments:
This is a lovely letter from the Whitehouse. Given the recently disclosed vulnerabilities, IT teams will unfortunately and more than likely be busy over the Holidays. Hopefully, companies and leadership are working and able to provide security staff much-needed time away from computer screens while ensuring enterprise security throughout the upcoming weeks. This can be challenging; IT shortages have been reported worldwide, while threats have risen. Employees working overtime are more likely to become complacent due to fatigue and stress. Unfortunately, staffing challenges like these will continue to be a problem for companies when a heightened sense of security and urgency may be required. We want to take the opportunity to thank employees who fill these roles, who are usually required to step up and maintain the security and functionality of critical infrastructure during the holiday season.

Mitigation:
In many cases criminals plan and actually begin an intrusion before the holiday itself – they infiltrate a network and lie in wait for the optimal time to launch an attack. It is therefore essential that you convene your leadership team now to make your organization a harder target
for criminals.

Here are some best practices that can be implemented immediately.

• Updated Patching. Criminals count on victims failing to patch their systems and usually take advantage of long-known and fixable vulnerabilities. Patching should be up-to-date, against all known vulnerabilities.
• Change Passwords and Mandate Multi-Factor Authentication (MFA).
• Manage Schedules. Review staffing plans for your IT and security teams to ensure you have sufficient holiday coverage.
• Employee Awareness. Conduct spear phishing and other exercises to raise employee awareness of common attacks. Reinforce the imperative to report computers or phones exhibiting any unusual behavior.
• Exercise Makes an Organization Healthy. Exercise your incident response plan now, so that if the worst happens you can respond quickly to minimize the impact.
• Backup your Data. Confirm that you are backing up key data. Ask your IT staff to test the backup system, and verify that these backups are offline and COMPLETELY out of the reach of criminals.

 

[Jonathan Braley]

Update from IT-ISAC Operations Team

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 both 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 1000's 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 may be a viable safeguard.

--

Log4j Overview Scanning Software - TLP: WHITE

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

DISCLAIMER: We do not endorse any products or services. Please use these tools at your own risk. These have been provided by the UK’s NCSC.

--

Known Vulnerable Products and Versions - TLP: WHITE

• NCSC Vulnerable product list - best in my opinion:
  • https://github.com/NCSC-NL/log4shell/blob/main/software/README.md
• Vulnerable Products:
  • https://github.com/YfryTchsGD/Log4jAttackSurface
• CISA list of vulnerable products:
  • https://github.com/cisagov/log4j-affected-db

 

[Jonathan Braley]

CISA recommends affected entities:

• Review Apache’s Log4j Security Vulnerabilities page for additional information and, if appropriate, apply the provided workaround:

• 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 from 2.7 through 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.7, the only mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

• Apply available patches immediately. See CISA's GitHub repository for known affected products and patch information.

• Prioritize patching, starting with mission critical systems, internet-facing systems, and networked servers. Then prioritize patching other affected information technology and operational technology assets.
• Until patches are applied, set log4j2.formatMsgNoLookups to true by adding -Dlog4j2.formatMsgNoLookups=True to the Java Virtual Machine command for starting your application. Note: this may impact the behavior of a system’s logging if it relies on Lookups for message formatting. Additionally, this mitigation will only work for versions 2.10 and above.
• As stated above, BOD 22-01 directs federal civilian agencies to mitigate CVE-2021-44228 by December 24, 2021, as part of the Known Exploited Vulnerabilities Catalog.