Log4j vulnerability - CVE-2021-44228 | CVE-2021-45046
Current status: 16.12.2021 - 14:15 (CET)
Facts of the case
Log4j
is a popular logging library for Java applications. It is used for the high-performance aggregation of an application's log data.
The blog of an IT security service provider reports on the vulnerability CVE-2021-44228 in Log4j
in versions 2.0
to 2.14.1
, which may allow attackers to execute their own program code on the target system and thus compromise the server. This danger exists if Log4j
is used to log a character string controlled by the attacker, such as the HTTP user agent.
A proof of concept (PoC) of the vulnerability has been published on Github and shared on Twitter. In addition to the PoC, there are also examples of scripts that randomly check systems for vulnerabilities. Scripts of this kind cannot give administrators any certainty about the vulnerability, but they do allow attackers to perform rudimentary scans for vulnerable systems in the short term.
This critical vulnerability may therefore have an impact on all Java applications accessible from the Internet that log parts of user requests using Log4j
.
Update 12/15/2021:
The vulnerability CVE-2021-4428 was fixed in Apache Log4j
version 2.15.0
, but at the same time caused another vulnerability described in CVE-2021-45046. The vulnerability described in CVE-2021-45046 has been fixed in Log4j
version 2.16.0
. The additional vulnerability does not affect the necessary steps described below.
Affected Managed Elastichsearch Server
Elasticsearch is not vulnerable to remote code execution through this vulnerability as Elasticsearch uses the Java Security Manager. Elasticsearch in combination with JDK 8
or lower is only vulnerable to a DNS information leak, which can be fixed by simply changing the JVM properties.
The information leak does not allow access to data within the Elasticsearch cluster. Elasticsearch has already released versions 7.16.1
and 6.8.21
, which include the necessary JVM property by default and remove certain components of Log4j
for security reasons.
Necessary measures
Managed Elasticsearch Server
The creoline Managed Elasticsearch Servers are neither affected by the Log4j vulnerabilities CVE-2021-44228 and CVE-2021-45046 nor by the DNS vulnerability.
**No action is required if you are using a Managed Elasticsearch Server.
All Managed Elasticsearch Servers use the Java Security Manager and at least JDK version 16 and are therefore not vulnerable to the vulnerability or the DNS leak.
Standalone Elasticsearch installations
If you have installed Elasticsearch independently on your server, you must ensure that the JDK version used is at least version 9.
Check installed versions
The installed JDK version can be checked as follows:
/usr/share/elasticsearch/jdk/bin/java --version
openjdk 17.0.1 2021-10-19
OpenJDK Runtime Environment Temurin-17.0.1+12 (build 17.0.1+12)
OpenJDK 64-Bit Server VM Temurin-17.0.1+12 (build 17.0.1+12, mixed mode, sharing)
The installed Elasticsearch version can be checked as follows:
apt list elasticsearch
elasticsearch/stable,now 7.16.1 amd64 [installed]
The active Elasticsearch version can be checked as follows:
apt update && apt install curl
curl -XGET 'http://localhost:9200'
{
"name" : "s*****.creolineserver.com",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "*********",
"version" : {
"number" : "7.16.1",
"build_flavor" : "default",
"build_type" : "deb",
"build_hash" : "5b38441b16b1ebb16a27c107a4c3865776e20c53",
"build_date" : "2021-12-11T00:29:38.865893768Z",
"build_snapshot" : false,
"lucene_version" : "8.10.1",
"minimum_wire_compatibility_version" : "6.8.0",
"minimum_index_compatibility_version" : "6.0.0-beta1"
},
"tagline" : "You Know, for Search"
}
The installed Kibana version can be checked as follows
apt list kibana
kibana/stable,now 7.16.1 amd64 [installed]
Determine Java processes
If you are not sure whether a Java-based process is activated on your server, you can use the shell command ps aux | grep java
to check whether Java processes are activated in the background.
ps aux | grep java
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 12157 0.0 0.0 6088 892 pts/0 R+ 12:21 0:00 grep java
elastic+ 28739 3.7 63.8 6899160 2539176 ? Ssl 10:11 4:53 /usr/share/elasticsearch/jdk/bin/java -Xshare:auto [...]
In this example, an Elasticsearch process is executed. (/usr/share/elasticsearch/jdk/bin/java
)
Determine Java network services
If you are not sure whether a Java-based network service is activated on your server, you can use the shell command netstat -tulpn |grep java
to determine whether services are provided via Java-based applications.
netstat -tulpn |grep java
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp6 0 0 :::9200 :::* LISTEN 28739/java
tcp6 0 0 :::9300 :::* LISTEN 28739/java
In this example, the Elasticsearch ports 9200
and 9300
are opened via Java.
Further queries
If you are not sure whether your creoline server provides Java-based services that are affected by the vulnerability, please contact our support team immediately so that we can clarify what measures need to be taken specifically for your server.
Sources
Federal Office for Information Security | https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf |
Lunasec | https://www.lunasec.io/docs/blog/log4j-zero-day/ |
US Vulnerability Database | https://nvd.nist.gov/vuln/detail/CVE-2021-44228 | https://nvd.nist.gov/vuln/detail/CVE-2021-45046 |
Elasticsearch | https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476 |