Log4Shell Vulnerability

 

On December 9, 2021, a critical vulnerability in the popular Java logging library named Log4j was disclosed. The vulnerability, being tracked as CVE-2021-44228, was given the nickname Log4Shell.

The IT Security Office will continue to provide updates as additional information becomes available. Please contact the IT Security Office at [email protected] if you have any vulnerable systems or questions.

Updates

• December 28, 2021 - Apache released Log4j 2.17.1 to address a new vulnerability affecting the Log4j Library. This new vulnerability is being tracked as CVE-2021-44832, a bug that allows arbitrary code execution in compromised systems when the attacker has permissions to modify the logging configuration file. Apache Log4j2 versions 2.0-beta7 through 2.17.0 are vulnerable.
• December 17, 2021 - Apache released Log4j 2.17.0 for Java 8 users to address a denial-of-service (DOS) vulnerability - CVE-2021-45105. All versions from 2.0-beta9 to 2.16 are considered vulnerable.
• Since news first broke of the problem on December 9, 2021, Apache has released various patches to address three vulnerabilities identified in Log4j:

 

What is the Log4Shell vulnerability?

Log4Shell is a vulnerability in Log4j, a widely used open source logging library for Java. Log4j gives software developers a way to build a record of activity to be used for a variety of purposes, such as troubleshooting, auditing and data tracking. Because it is both open-source and free, the library essentially touches every part of the internet. The vulnerability is classed as severe (severity score of 10 out of 10).

Code within Log4j was found to be susceptible to a remote code-execution exploit technique. By employing a unique code string, an adversary may be able to gain full access to a target system running Log4j. This vulnerability has led the university to be alerted by the Cyber & Infrastructure Security Agency (CISA), the Department of Homeland Security, and the California State University system.

What Log4j versions are affected?

All versions from 2.0-beta9 to 2.17.0 are affected.

Please note that Log4j 1.x has reached end of life and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes.

What should you do immediately?

In general, the following actions are recommended to identify the systems needing updates and those that may need immediate attention:

• Coordinate with the IT Division. Reach out to your IT team for help determining if your systems and applications are vulnerable.
• Identify vulnerable systems and software. Systems using version 2.16 (as of December 20, 2021) and earlier of the Log4j library are considered vulnerable.
  
• Contact your vendor for specialized applications. Because Log4j is embedded in a large number of commercial software applications, contacting any software vendor you have for more information about addressing the vulnerability is strongly recommended. 
• Apply updates and/or recommended mitigations immediately. The latest version of Log4j can be found here.  For mitigations and workaround visit the CISA website at https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance.
• Monitor logs. Working with your IT team, review the logs of your systems for any indication of compromise. Search for exploitation and post-exploitation activities.

What software is vulnerable?

The IT Security Office in collaboration with campus-wide IT, including OneIT leaders, are working to detect and mitigate this critical vulnerability. Proactive scanning and searching is key to finding vulnerable instances of Log4j. These are recommended open-source scanning programs available to search servers and list out code versions of vulnerable code.

Source Code Scanning

• Grype (https://github.com/anchore/grype) – Searches libraries installed on a system and displays vulnerabilities present.
• Syft (https://github.com/anchore/syft) – Searches for installed code and libraries and displays their versions.
• CERT CC (Carnegie Mellon)
• Logpresso

Active/Dynamic Testing

• FullHunt (https://github.com/fullhunt/log4j-scan) – Open-sourcing an open detection and scanning tool for discovering and fuzzing.
• Huntress (https://log4shell.huntress.com/) – Web-based tool to help identify affected server applications.

What vendor products are affected?

Many vendors are releasing bulletins that state if their code or appliances are vulnerable and how to apply upgrades. The following reference lists provided below are being actively compiled by trusted sources.

• CISA Vendor DB
• BleepingComputer
• Github - Dutch NCSC List of affected Software
• GitHub - SwitHak

Please note that these are not definitive lists. Contacting vendors regarding their specific software is recommended to get their insight into affected products and their remediation recommendations.

What are prevention and mitigation recommendations?

The best way to prevent exploitation of vulnerable code is to upgrade vulnerable versions of Log4j to the latest version or apply vendor patches.

If it is not possible to upgrade, there are several mitigation tactics that can be performed. However, it is important to note that an additional vulnerability making systems vulnerable to denial-of-service (DoS) attacks, was linked to version 2.15.0 (CVE-2021-45046), which affects all versions of Log4j from from 2.0-beta9 to 2.16.0 . The best mitigation tactic is to upgrade to the latest version.

• For Log4j versions >= 2.10, set the log4j2.formatMsgNoLookups system property to true on both client- and server-side components.
  
  This can be done in multiple ways:
  • Add -Dlog4j2.formatMsgNoLookups=true to the startup scripts of Java programs.
  • Set the following environment variable: LOG4J_FORMAT_MSG_NO_LOOKUPS=”true”.

• For Log4j versions from 2.0-beta9 through 2.10.0, remove the JndiLookup class from the classpath. For example:
  
  
  
  • Isolate systems into their own restricted DMZs or VLANs.
  • Block all outbound network connections from servers or limit outbound network connections to trusted hosts and network ports.
  • Turn on any endpoint or network security signatures for Log4j exploitation.
  • Monitor networks and servers closely for suspicious or unexpected behavior.

Testing should occur after ALL mitigation steps above have been completed to ensure that vulnerabilities do not persist.

How can you detect and monitor for indicators of compromise?

Jazzing and Fuzzing Techniques

On December 16, 2021, the Google Security Team published an article on using fuzzing techniques for open source projects as a way to detect Log4Shell and other vulnerabilities. Use of tools, such as OSS-Fuzz and Jazzer, can detect this class of vulnerability so that they can be fixed before they become a problem in production code.

Check out Google's documentation to get started on using OSS-Fuzz.

Log4Shell Detectors

Exploitation attempts can be detected by searching through all log files on a server for vulnerable code strings. While straight searches can be performed, attack strings can be easily obfuscated. The following script takes the obfuscation into account when searching:

• Cybersecurity and Infrastructure Agency (CISA) Log4j Scanning Solution
• Log4Shell-detector (https://github.com/Neo23x0/log4shell-detector)
• Neo23x0 Log4j RCE Exploitation Detection

Manual searches can also be performed, but the following do not consider any obfuscation attempts. (Reference – https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b)

• Utilize the following Linux commands to search uncompressed log files in /var/log. Note that /var/log should be changed to include any additional application-specific directories.
  
  
• Utilize the following Linux commands to search compressed log files in /var/log.
  
  

Additional regular expressions that can be used to detect attacks can be found on https://gist.github.com/karanlyons/8635587fd4fa5ddb4071cc44bb497ab6.

How can you get support?

Please create a ServiceNow Ticket:

1. Please visit: https://servicenow.sdsu.edu
2. Click on “Get Help | Report a Problem”.
3. Click on the IT Help Desk for your College/Division.
4. Fill out the request form.

For a list of additional information for IT support for your area, please visit: https://it.sdsu.edu/help#colldiv

What additional resources are available?

The security community has quickly come together to gather information and provide guidance for this vulnerability. Following is a list of additional resources that may also be useful:

• CISA Apache Log4j Vulnerability Guidance – https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
• CISA Apache Log4j Vulnerability Response – https://www.cisecurity.org/log4j-zero-day-vulnerability-response/
• Log4j CVE-2021-44228 Advisory – https://github.com/advisories/GHSA-jfh8-c2jp-5v3q
• Log4j RCE Exploitation Detection – https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
• Log4j Apache Update Site – https://logging.apache.org/log4j/2.x/download.html
• Known Affected Applications – https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
• CrowdStrike Guidance – https://www.crowdstrike.com/blog/log4j2-vulnerability-analysis-and-mitigation-recommendations/
• Microsoft Guidance – https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
• Log4j Exploitation Demonstration – https://www.youtube.com/watch?v=7qoPDq41xhQ
• Binary Defense Guidance – https://www.binarydefense.com/advice-for-defenders-responding-to-the-log4j-vulnerability-cve-2021-44228/
• TrustedSec – https://www.trustedsec.com/blog/log4j-playbook/#_Exploitation_Detection
• Google Security Blog – https://security.googleblog.com/