Log4j Sicherheitslücke - CVE-2021-44228 | CVE-2021-45046

Aktueller Stand: 16.12.2021 - 14:15 Uhr (MEZ)

Sachverhalt

Log4j ist eine beliebte Protokollierungsbibliothek für Java-Anwendungen. Sie dient der performanten Aggregation von Protokolldaten einer Anwendung.

Der Blog eines Dienstleisters für IT-Sicherheit berichtet über die Schwachstelle CVE-2021-44228 in Log4j in den Versionen 2.0 bis 2.14.1, die es Angreifern gegebenenfalls ermöglicht, auf dem Zielsystem eigenen Programmcode auszuführen und so den Server zu kompromittieren. Diese Gefahr besteht dann, wenn Log4j verwendet wird, um eine vom Angreifer kontrollierte Zeichenkette wie beispielsweise den HTTP User Agent zu protokollieren.

Ein Proof of Concept (PoC) der Schwachstelle wurde auf Github veröffentlicht und auf Twitter geteilt. Neben dem PoC existieren auch Beispiele für Skripte, die Systeme stichprobenartig auf Verwundbarkeit hin untersuchen. Skripte solcher Art können zwar Administratoren keine Sicherheit über die Verwundbarkeit geben, aber erlauben Angreifern kurzfristig rudimentäre Scans nach verwundbaren Systemen.

Diese kritische Schwachstelle hat demnach möglicherweise Auswirkungen auf alle aus dem Internet erreichbaren Java-Anwendungen, die mithilfe von Log4j Teile der Nutzeranfragen protokollieren.

Update 15.12.2021:

Die Schwachstelle CVE-2021-4428 wurde in der Apache Log4j Version 2.15.0 behoben, verursachte aber gleichzeitig eine weitere Sicherheitslücke, beschrieben in CVE-2021-45046. Die in CVE-2021-45046 beschriebene Sicherheitslücke wurde in der Log4j Version 2.16.0 behoben. Die zusätzliche aufgetretene Schwachstelle nimmt keinen Einfluss auf die im Folgenden beschriebenen notwendigen Schritte.

Betroffene Managed Elastichsearch Server

Elasticsearch ist durch diese Schwachstelle nicht anfällig für Remotecode-Execution, da Elasticsearch den Java Security Manager verwendet. Elasticsearch in Kombination mit JDK 8 oder niedriger ist lediglich anfällig für ein DNS-Informationsleck, welches durch eine einfache Änderung der JVM-Eigenschaften behoben werden kann.

Das Informationsleck erlaubt keinen Zugriff auf Daten innerhalb des Elasticsearch-Clusters. Elasticsearch hat hierzu bereits die Versionen 7.16.1 und 6.8.21 veröffentlicht, die die notwendige JVM-Eigenschaft standardmäßig enthält und bestimmte Komponenten von Log4j aus Sicherheitsgründen entfernt.

Erforderliche Maßnahmen

Managed Elasticsearch Server

Es sind keine Maßnahmen erforderlich, sofern Sie einen Managed Elasticsearch Server einsetzen.

Alle Managed Elasticsearch Server setzen den Java Security Manager sowie mindestens JDK Version 16 ein und sind daher nicht anfällig für die Sicherheitslücke oder den DNS-Leak.

Eigenständige Elasticsearch Installationen

Sofern Sie Elasticsearch eigenständig auf Ihrem Server installiert haben, muss sichergestellt werden, dass die verwendete JDK Version mindestens der Versionsnummer 9 entspricht.

Installierte Versionen überprüfen

Die installierte JDK Version kann wie folgt überprüft werden:

/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)

Die installierte Elasticsearch Version kann wie folgt überprüft werden:

apt list elasticsearch

elasticsearch/stable,now 7.16.1 amd64  [installiert]

Die aktive Elasticsearch Version kann wie folgt überprüft werden:

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"
}

Die installierte Kibana Version kann wie folgt überprüft werden:

apt list kibana

kibana/stable,now 7.16.1 amd64  [installiert]

Java-Prozesse ermitteln

Sofern Sie nicht sicher sind, ob auf Ihrem Server ein Java-basierter Prozess aktiviert ist, können Sie über den Shell-Befehl ps aux | grep java prüfen, ob Java-Prozesse im Hintergrund aktiviert sind.

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 diesem Beispiel wird ein Elasticsearch-Prozess ausgeführt. (/usr/share/elasticsearch/jdk/bin/java)

Java-Netzwerkdienste ermitteln

Sofern Sie nicht sicher sind, ob auf Ihrem Server ein Java-basierter Netzwerkdienst aktiviert ist, können Sie mithilfe des Shell-Befehls netstat -tulpn |grep java ermitteln, ob Dienste über Java-basierte Anwendungen bereitgestellt werden.

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 diesem Beispiel sind die Elasticsearch Ports 9200 und 9300 über Java geöffnet.

Weitere Rückfragen

Sofern Sie nicht sicher sind, ob Ihr creoline Server Java-basierete Dienste bereitstellt, die von der Sicherheitslücke betroffen sind, melden Sie sich umgehend bei unserem Support, damit wir abklären können, welche Maßnahmen speziell für Ihren Server getroffen werden müssen.

Quellen