Under what circumstances can log4j be used to exploit Logstash?

Elastic Stack Logstash
1

Hi,

Under what circumstances can the log4j bug be exploited in Logstash? Is it as simple as sending the exploit string an open port Logstash is listening on regardless of whatever input is configured in your Logstash configuration?

As for mitigations, apart from updating to a newer version or removing the class file, would disabling logging inside the Logstash configuration file also be sufficient?

2

A carefully-crafted payload that is processed by Logstash and results in a message being sent to the logger containing that payload, is sufficient to trigger the issue. The payload does not have to be transmitted directly by an attacker, but could be fetched by any one of a pipeline's input plugins so long as doing so resulted in the exploit string being included in a log message.

The only validated mitigations remain the removal of the class file or upgrading to a patched release.

1 Like
3

If you are asking for an exploit, nobody here will give you one.

But in short, no, it is not. The CVE says

One vector that allowed exposure to this vulnerability was Log4j’s allowance of Lookups to appear in log messages. This meant that when user input is logged, and that user input contained a JNDI Lookup pointing to a malicious server, then Log4j would resolve that JNDI Lookup, connect to that server, and potentially download serialized Java code from that remote server. This in turn could execute any code during deserialization.

Note first that this says "one vector". If there are other known vectors the following statements may not apply.

"when user input is logged". I cannot think of anything in logstash that logs user input (i.e. event data) unless log.level debug is enabled, and for some inputs it requires trace. If the data never goes to log4j2 then I cannot see that log4j2 is directly exploitable.

"This in turn could execute any code during deserialization". I am familiar with deserialization attacks (I studied the 2015 Lawrence/Frohoff "Pickles" attack) and this feels like an understatement. The attack surface is not "any code that the app calls". It is "any code in the class path".

image
image766×493 37.6 KB

When an application is built upon a framework built upon frameworks built upon frameworks "any code in the class path" is a ridiculously large attack surface, much of which is unused and some of which has not been maintained for years.

Do not try to develop your own mitigations unless you are a very experienced Java security engineer.

4

Clear, thank you.

Also, which versions of OpenJDK are only affected by DOS and information leakage?

5

Does this effectively mean that while Logstash is affected, there isn't really any (known) chance of actually being able to exploit Logstash by sending a modified log or whatever to it when you have to log level set to the default info?

The reason I'm asking is because I have a lot of boxes in remote locations that I cannot easily update. They are on locked down networks though. So I'm just trying to figure out how much of a risk there is in my case so I can plan accordingly.

6

I think that is probably true. However, I don't recommend you bet the security of your installation on my intuition.

7

Carefully-crafted messages, with knowledge or assumptions about how the message was to be processed in the pipeline, could cause event data to be logged, typically at ERROR level.

8

I hadn't thought of that. Certainly json and xml filters will log text from the message field when they are unable to parse it. I expect there are others that do so too.

9

Hi,

Just yesterday we had an incident (attack) against our logstash 7.16.1 where there was an intrusion with an encryption attempt by ransomware, the incident is still under investigation but I believe that the task of fixing the vulnerability in logstash has not been done correctly.

Best regards

10

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.