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