Log4j RCE Found • Hacker News Board

Re: Log4j RCE Found

#461

Post by Too » Sat, Dec 11, 2021, 1:59 PM UTC

est wrote: post #44

testplzignore wrote: post #20

I don't get what the point of this feature even is. What is a legitimate reason for a logging library to make network requests based on the contents of what is being logged? And is this enabled out-of-the-box with log4j2?

> What is a legitimate reason for a logging library to make network requests based on the contents of what is being logged I encountered a similar problem recently, my own logger can get the current container/pod IP address, it's painful to tell which host from the IPs in logs, so I had to do a manual DNS lookup to include a hostname instead. I was hoping the logger could automatically do a lookup and cache it for me…

Pretty sure the original rationale for this clusterfuck must have been something similar: “we only have user id here, but want the logs to contain user name”. Send this requirement to the cheapest bidder and here we are.

Re: Log4j RCE Found

#462

Post by slimbods » Sat, Dec 11, 2021, 2:01 PM UTC

ievans wrote: post #15

If you'd like to detect whether you're affected by this dynamically, it looks like https://github.com/google/tsunami-security-scanner-plugins/i... will eventually make it into Google's dynamic scanner: https://github.com/google/tsunami-security-scanner (I bet it would be easy to write a plugin for https://github.com/projectdiscovery/nuclei as well.) To see if there are injection points statically, I work on a tool (…

The Activescan++ extension for burp has been updated, but you need to do a manual update to get it:

https://github.com/PortSwigger/active-scan-plus-plus/commit/...

Re: Log4j RCE Found

#463

Post by philipwhiuk » Sat, Dec 11, 2021, 2:32 PM UTC

reidrac wrote: post #206

When I started working with Scala, it really surprised me how the JVM world deals with dependencies (include an upstream jar directly in the project, as opposed to the Linux distro model where you use your distributor packages so you have security and bug fixes). I'm a big fan of Dependency Check[1]. There are hosted services that can give you security scans, but if you don't have access to that (some have a cost) or…

Worth saying that dependency-check I'm pretty sure hadn't picked it up as of Friday. It takes a while to get to the NVD lists and with this bug you don't have that kind of time.

It's good for preventing people adding known-insecure libraries though.

Re: Log4j RCE Found

#464

Post by philipwhiuk » Sat, Dec 11, 2021, 2:34 PM UTC

prdonahue wrote: post #366

trulyrandom wrote: post #286

Cloudflare has published an article with clear mitigation options: https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-m...

Given the severity, we've also rolled this out to our Free plan customers, who don't otherwise have access to the WAF.

Do you look and block for evasion attempts like:

${j${lower:n}${lower:d}i...}

?

Re: Log4j RCE Found

#465

Post by philipwhiuk » Sat, Dec 11, 2021, 2:34 PM UTC

simon04 wrote: post #203

To enable the mitigation for Apache Tomcat, set `JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true` For instance, when starting with systemd, add `Environment=JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true` to your service file. You should find `Command line argument: -Dlog4j2.formatMsgNoLookups=true` in catalina.out

Assuming you're running Log4J > 2.10.0 otherwise this won't be picked up and used.

Re: Log4j RCE Found

#466

Post by philipwhiuk » Sat, Dec 11, 2021, 2:35 PM UTC

twic wrote: post #339

_wldu wrote: post #324

A LSM in enforcing mode (such as SELinux or Tomoyo) on a Linux system would prevent this. I configure and run tomoyo on all my Internet facing servers. https://tomoyo.osdn.jp/

Or just a firewall rule to block outgoing connections. Basic security precautions prevent this attack against servers.

It's amazingly common for SecOps to only consider inbound traffic.

Re: Log4j RCE Found

#467

Post by philipwhiuk » Sat, Dec 11, 2021, 2:36 PM UTC

fomine3 wrote: post #134

It's horrible that the vuln is fixed in open PR, never assigned CVE, and never released fixed version unless 0day shown in wild.

1. I believe that the zero day was released before the fix 2. There's no practical way to responsibly disclose a bug in a core library

Re: Log4j RCE Found

#468

Post by philipwhiuk » Sat, Dec 11, 2021, 2:37 PM UTC

niea_11 wrote: post #219

You can find the motivation for looking up jndi resources on the ticket that introduced the behaviour : https://issues.apache.org/jira/browse/LOG4J2-313

It's abhorrently thin given it introduced a remote vector.

Re: Log4j RCE Found

#469

Post by philipwhiuk » Sat, Dec 11, 2021, 2:38 PM UTC

jsiepkes wrote: post #184

What adds to the confusion is that log4j2 rebrands itself as log4j. For example the Log4j2 artifact name is: `org.apache.logging.log4j:log4j-api` but it is actually Log4j2, not the original Log4j. There is plenty of stuff out there that still uses Log4j 1.7, 1.8, etc. I assume this is all about Log4j2? And not about the original Log4j? Or is the original Log4j also affected?

The original Log4J is EOL and unmaintained. It's not affected by this but it does have other known vulns.

Re: Log4j RCE Found

#470

Post by philipwhiuk » Sat, Dec 11, 2021, 2:39 PM UTC

tmd83 wrote: post #109

agwa wrote: post #66

Earlier quoted context omitted.

> the vulnerable feature is not in log4j The comment you cited is referring to the option to disable the vulnerable feature, not the vulnerable feature itself. Per https://github.com/apache/logging-log4j2/pull/608#issuecomme... even log4j 1.x is vulnerable.

Does that mean it's only vulnerable if JMSAppender is used otherwise not? Which should at least be a rarer use case.

Log4J 1 is only vulnerable for JMS Log4J 2 is vulnerable 2.10.0 and > 2.7.0