【CVE Link】 https://github.com/advisories/GHSA-jfh8-c2jp-5v3q

【Vulnerability Description】 Apache Log4j is a widely used open-source logging library for Java applications. Many Java frameworks, including the latest versions of Elasticsearch, utilize this component, making the impact of this vulnerability widespread.

Recently, details about a remote code execution vulnerability in Apache Log4j have been disclosed. Attackers can exploit this vulnerability by constructing malicious requests, allowing them to execute arbitrary code on the target server. This can lead to server compromise and various malicious activities such as website defacement, data theft, mining, and ransomware attacks. Users who utilize this component are advised to take immediate action to remediate the vulnerability.

In summary, the vulnerability exists in Log4j where, if the logs contain the ${ keyword, the contents within are treated as variables to be replaced and executed. This allows attackers to execute arbitrary commands by constructing malicious log entries, resulting in successful attacks.

【Vulnerability Severity】: Critical

This vulnerability is caused by the lookup feature provided by Log4j2, which allows developers to read configurations from various protocols within the environment. However, during implementation, proper input validation was not performed, leading to the occurrence of this vulnerability.

【Affected Range】: Java-based products: Apache Log4j 2.x < 2.15.0-rc2

【Attack Detection】 Potential attack behavior can be detected by checking if the logs contain characters such as jndi:ldap:// or jndi:rmi.

Mitigation Measures #

If it is not possible to modify the Elasticsearch configuration or replace the Log4j jar file and restart the cluster, INFINI Gateway can be used for interception, parameter substitution, or even blocking requests.

By uniformly inspecting requests sent to Elasticsearch at the gateway level and replacing or directly rejecting requests containing the sensitive keyword ${, it is possible to prevent malicious requests from reaching the Elasticsearch server and triggering Log4j to log related entries executing malicious commands, thus avoiding attacks.

Reference Configuration #

Download the latest version 1.5.0-SNAPSHOT from http://release.elasticsearch.cn/gateway/snapshot/

Use the INFINI Gateway’s context_filter filter to inspect the request context _ctx.request.to_string for keyword detection, filtering out malicious traffic, and blocking attacks.

path.data: data
path.logs: log

entry:
  - name: es_entrypoint
    enabled: true
    router: default
    max_concurrency: 20000
    network:
      binding: 0.0.0.0:8000

router:
  - name: default
    default_flow: main_flow

flow:
  - name: main_flow
    filter:
      - context_filter:
          context: _ctx.request.to_string
          action: redirect_flow
          status: 403
          flow: log4j_matched_flow
          must_not: # any match will be filtered
            regex:
              - \$\{.*?\}
              -

 "%24%7B.*?%7D" #urlencode
            contain:
              - "jndi:"
              - "jndi:ldap:"
              - "jndi:rmi:"
              - "jndi%3A" #urlencode
              - "jndi%3Aldap%3A" #urlencode
              - "jndi%3Armi%3A" #urlencode
      - elasticsearch:
          elasticsearch: es-server
  - name: log4j_matched_flow
    filter:
      - echo:
          message: 'Apache Log4j 2, Boom!'

elasticsearch:
  - name: es-server
    enabled: true
    endpoints:
      - http://localhost:9200

Test the command ${java:os} by URL encoding it as %24%7Bjava%3Aos%7D.

Without using the gateway:

~%  curl 'http://localhost:9200/index1/_search?q=%24%7Bjava%3Aos%7D'
{"error":{"root_cause":[{"type":"index_not_found_exception","reason":"no such index","resource.type":"index_or_alias","resource.id":"index1","index_uuid":"_na_","index":"index1"}],"type":"index_not_found_exception","reason":"no such index","resource.type":"index_or_alias","resource.id":"index1","index_uuid":"_na_","index":"index1"},"status":404}%

The Elasticsearch server responds with an index not found error.

In the Elasticsearch server logs, you can see that the query parameter q=${java:os} was executed and translated to q=Mac OS X 10.13.4 unknown, architecture: x86_64-64, index=index1.

Using the gateway:

medcl@Medcl:~%  curl 'http://localhost:8000/index1/_search?q=%24%7Bjava%3Aos%7D'
Apache Log4j 2, Boom!%

The request is blocked by the gateway.

You can test other commands as well:

#{java:vm}
~%  curl 'http://localhost:9200/index/_search?q=%24%7Bjava%3Avm%7D'
[2021-12-11T02:36:04,764][DEBUG][r.suppressed             ] [Medcl-2.local] path: /index/_search, params: {q=OpenJDK 64-Bit Server VM (build 25.72-b15, mixed mode), index=index}

~%  curl 'http://localhost:8000/index/_search?q=%24%7Bjava%3Avm%7D'
Apache Log4j 2, Boom!%

#{jndi:rmi://localhost:1099/api}
~%  curl 'http://localhost:9200/index/_search?q=%24%7Bjndi%3Armi%3A%2F%2Flocalhost%3A1099%2Fapi%7D'
2021-12-11 03:35:06,493 elasticsearch[YOmFJsW][search][T#3] ERROR An exception occurred processing Appender console java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object

~%  curl 'http://localhost:8000/index/_search?q=%24%7Bjndi%3Armi%3A%2F%2Flocalhost%3A1099%2Fapi%7D'
Apache Log4j 2, Boom!%
``

`

Using the Infini Gateway to handle security incidents has several advantages. It does not require any modifications to the Elasticsearch server, especially in large-scale cluster scenarios. This approach saves a lot of work, improves efficiency, and shortens the time for security incident handling while reducing enterprise risk.