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

81–90 of 531 posts

Re: Log4j RCE Found

#81

Post by morpheuskafka »

jffry wrote: post #77
morpheuskafka wrote: post #57

Anyone know of a quick way to test this just to see if it will hit the URL without setting up any exploit server to actually send any code? I guess you'd need something that reports when the DNS name gets hit (like how a DNS leak test works) but I can't find any services to do that.

Looks like https://requestbin.net/dns is what you want, no? I set one up (free, no account) and then when I did an nslookup or curl I saw the DNS hits coming in

Yep, that's exactly what I was after. Tried a few google searches but it was just bringing up tools to test DNS propagation.

Re: Log4j RCE Found

#82

Post by peterkelly »

a-dub wrote: post #50

so the question is, is it safe to log unsanitized inputs? i've argued no given the complexity of today's logging pipelines and caught a lot of flak for it in the past... now i feel vindicated.

In a properly designed system, it should be perfectly safe. The problems come from how the log input is processed. If all you're doing is appending it to a file or adding a row to a database table, that should be no problem.

In the database case it's no different to adding any other record supplied by the user. In the case of a file, consideration has to be given about what assumptions other tools that process that file may make - e.g. if they assume one record per line, then the data should be escaped appropriately (simple approach is to use JSON string escaping, or just make the whole log entry a JSON object).

If the logging system is built by someone who thought it was a good idea to parse the string, use the result to make network requests, and then executing arbitrary code based on the data received over the network, then all bets are off.

Re: Log4j RCE Found

#83

Post by jpomykala »

qdot76367 wrote: post #3

Good twitter thread summarizing the situation: https://twitter.com/dzikoysk/status/1469091718867951618

„ Also, we can't be sure about whole scenario. There're reports that indicates this RCE is still possible in 2.15+ RCs builds, so there is a chance there are also other gateways to achieve the same effect.”

Re: Log4j RCE Found

#84

Post by a-dub »

lvh wrote: post #73
dylan604 wrote: post #54

Earlier quoted context omitted.

Why would you ever trust user provided input? Like seriously, ever? I don't trust my own input. I tend to copy&paste, and I've messed up from pasting something that was previously in the clipboard because I didn't actually hit the right keyboard shortcut when I was copying the data I thought I was. I wasn't even attempting to be malicious, but I accidentally tried a SQL Inject attack on myself because of it. DON'T EV…

Eh. I think it's pretty reasonable that people assume their logging library doesn't have random RCE, and I think it's pretty reasonable people aren't going to be able to filter every parameter based on Log4J having a relatively obscure bug.

think about the complexity involved in a modern backend. those log messages are flowing through logging libraries and a local syslog at an absolute minimum. more exotic setups involve consolidators, indexing/searching, user interfaces that may be controlled by any number of operators. moreover, those who use these tools typically have the keys to the kingdom for their respective environments.

Re: Log4j RCE Found

#85

Post by nostoc »

jimrandomh wrote: post #64

I try to follow a rule with libraries: if a library causes more trouble than the implementation effort it would take to recreate its functionality from scratch (or rather, the portion of its funcitonality that is used in practice), then it's time to purge that library from projects and never use it again. The part of log4j functionality that gets used in practice, most of the time, is just a wrapper around printf whi…

> just a wrapper around printf which adds a timestamp and a log-level

That's a pretty naive view of what's needed in an enterprise logging solution.

logging to files, separate logging, remote logging, log rotation, logging 3rd party code...

Of course if you're simply sending lines to the terminal in a simple program you don't need log4j.

But once you scale, you'd be spending 3 weeks implementing what you get for free in log4j.

Re: Log4j RCE Found

#86

Post by jpomykala »

xyst wrote: post #16

This should be something that static code analyzers should pick up. If a dependency log4j dependency is Just in time to ruin all of the reports project managers present to executives

“Also, we can't be sure about whole scenario. There're reports that indicates this RCE is still possible in 2.15+ RCs builds, so there is a chance there are also other gateways to achieve the same effect.”

Re: Log4j RCE Found

#87

Post by throw_nbvc1234 »

BeefWellington wrote: post #25
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?

> I don't get what the point of this feature even is. This is basically the response to every type of vulnerability that is based on some spec nobody's read. Same deal with XML entity parsing. Why should it make web requests, FTP requests, etc.? At some point someone had it as a requirement and everyone else gets to live with it.

Which is why they removed the functionality in the latest version (per comments below) right?

Re: Log4j RCE Found

#88

Post by nostoc »

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 and deserialization vulnerabilities are one of the most iconic duos of infosec.

Re: Log4j RCE Found

#89

Post by a-dub »

peterkelly wrote: post #82
a-dub wrote: post #50

so the question is, is it safe to log unsanitized inputs? i've argued no given the complexity of today's logging pipelines and caught a lot of flak for it in the past... now i feel vindicated.

In a properly designed system, it should be perfectly safe. The problems come from how the log input is processed. If all you're doing is appending it to a file or adding a row to a database table, that should be no problem. In the database case it's no different to adding any other record supplied by the user. In the case of a file, consideration has to be given about what assumptions other tools that process that f…

imagine you're using stackdriver: how many thousands or millions of lines of code will those log messages touch before they're rendered in browser for someone with sysadmin privileges? how many libraries are just in the web front end they're using?

Re: Log4j RCE Found

#90

Post by im3w1l »

hinkley wrote: post #67
spuz wrote: post #36

Earlier quoted context omitted.

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…

Get yer pointin' finger ready: https://github.com/apache/logging-log4j2/blame/master/log4j-...

People should really have known better than to use (unexpected!) in-band signalling. Even 8 years ago.
Post reply on HN