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

CISA Director on Log4j Vulnerability

cisa.gov

Post reply on HN
Print view View original

71–80 of 85 posts

Re: CISA Director on Log4j Vulnerability

#71

Post by tomrod »

asjfj9 wrote: post #27
ygjb wrote: post #17

Earlier quoted context omitted.

No. The stakeholders are busy patching their shit. Pulling folks into meetings shouldn't be the priority when teams around the world in virtually every tech organizations are in firefighting mode. This type of a call would likely be focused on assessing current state at that point.

Could you share links to any threads or accounts people are sharing regarding tech organisations in firefighting mode against this? I work for a large non-US based tech company and have not heard anything about this beyond HN.

I'm sure many folks here spent their Friday, Saturday, and possibly even Sunday patching, and won't speak up in case their profile connects to their company.

Friday mid-afternoon a Google search for the exploit showed there were many websites in several languages giving instruction on how to exploit the vulnerability. This is hitting hard and fast.

Re: CISA Director on Log4j Vulnerability

#72

Post by bob1029 »

mclarke wrote: post #2

I’m sure this is the only community that might pay attention to a software BOM as mentioned in the article, but this is a great idea and makes a lot of sense (to me as a consumer at least).

We do something along this axis with our products. We have to be able to provide B2B software that will be stable on timelines measured in half-decades (per contractual requirements), so the specific vendors we decide to depend upon are a huge part of our decision making process. I will happily admit we probably wrote a little bit too much stuff in-house, but the number of clear wins easily outweighs the "no DIY allowed" concerns.

Getting us to vendor out something like logging/tracing/telemetry would take an act of god at this point. We explicitly spent a week ripping out Microsoft's byzantine logging from AspNetCore in favor of something we could trust and understand. Our entire logging framework now lives in 1 class file and consists of maybe 30 useful lines of source code. None of them have the capability to reach out to a remote host, download a DLL and then execute it in the current context. This sort of problem we are seeing with Log4j today is precisely the sort of experience we hope to avoid by doing a lot of our tooling in-house.

I think those who parroted "don't reinvent the wheel" over and over like it's some doomsday cult should accept some shame for the situation many developer ecosystems find themselves in today.

Re: CISA Director on Log4j Vulnerability

#73

Post by eitland »

beebeepka wrote: post #47
eitland wrote: post #32

Earlier quoted context omitted.

I'll start with the question: Deno solves this by making you specify on the command line or in a config file what an application should have access to, for instance for a simple web application you can specify that it only has read acesss to one folder of static files, write access to the log folder and can only connect to the postgres server. It is also very simple, see: https://deno.land/manual@v1.16.4/getting_star…

Thanks for your time. I am about to start a new personal project and your post, combined with some curiosity, is all I needed to hear. I've reached a point where doing the same thing with the same tech is making me feel uneasy.

Full disclosure: I've only toyed with it so far.

That said: What I have seen seems extremely interesting, both the audited standard library and the permission model, the built in support for TypeScript, single binary runtime and the avoidance of a single package repo.

Good luck with your next personal project. I guess now might be a perfect time to invest in learning Deno. It might not take of, but if it doesn't it will probably make me a little sad when I realize it, and I am a Java man (although I enjoy a number of other languages as well).

Re: CISA Director on Log4j Vulnerability

#74

Post by webmaven »

ByThyGrace wrote: post #64
flyinghamster wrote: post #62

Earlier quoted context omitted.

This reminds me a lot of audiophile woo as well. It seems like this sort of grift could be applied to just about anything where the technology is indistinguishable from magic.

Got any examples of audiophile scams?

Gold plated audio cables come to mind.

Re: CISA Director on Log4j Vulnerability

#75

Post by carapace »

ByThyGrace wrote: post #64
flyinghamster wrote: post #62

Earlier quoted context omitted.

This reminds me a lot of audiophile woo as well. It seems like this sort of grift could be applied to just about anything where the technology is indistinguishable from magic.

Got any examples of audiophile scams?

I once saw a spray for CDs that would "absorb stray laser light" or something like that. The bit that gets me is that according to the instructions you're supposed to spray it only on the label side of the disc.

Re: CISA Director on Log4j Vulnerability

#76

Post by technion »

SCHiM wrote: post #48
naltun wrote: post #45

Earlier quoted context omitted.

I work as a software engineer in cybersecurity. > embarrassed... for some of the offerings Welcome to the club.

I am half convinced you can build a successful cyber security business putting a box in a network that does absolutely nothing. I think there's a requirement to at least show a blinking led and have a, not necessarily patched, cable plugged in. But that's about it. My thinking is, that if you show a cool enough interface (not connected to the box), with lots of widgets and stats, and they don't detect a hack in the t…

That's pretty much what I've experienced myself at one point.

We had a client sending extremely sensitive data around by email. One day I was told we should all relax, the problem had been solved. You see he'd been sold a PGP hardware appliance.

As the person running the mail system, I could attest that mail wasn't flowing through it. It was literally in a rack. I don't even think it was given an IP address on their actual network. Multiple auditors came in to review the safety of the sensitive data that we had. They were all shown pictures of the rack with the PGP appliance in it, and that always was considered sufficient.

Re: CISA Director on Log4j Vulnerability

#77

Post by debug-desperado »

Spring Boot apps aren't affected by this unless you switched logging frameworks. Nor any JBoss frameworks. How many people actually use Log4j2? It's probably in 4th or 5th place among Java logging frameworks, and likely still has less uptake than the original Log4j.

Re: CISA Director on Log4j Vulnerability

#78

Post by notthathardbro »

ygjb wrote: post #17
rlt wrote: post #7

“we are also convening a national call with critical infrastructure stakeholders on Monday afternoon” Shouldn’t this be happening, like, yesterday?

No. The stakeholders are busy patching their shit. Pulling folks into meetings shouldn't be the priority when teams around the world in virtually every tech organizations are in firefighting mode. This type of a call would likely be focused on assessing current state at that point.

The people that would be in that meeting are not the individuals actually patching servers.

Re: CISA Director on Log4j Vulnerability

#79

Post by Thorrez »

PeterisP wrote: post #61
Thorrez wrote: post #16

Earlier quoted context omitted.

If the WAF blocks any request containing "{", that would be fairly safe, right? Yes, some attacks could still get through (e.g. a backend that receives requests base64-encoded), but that's the case generally with WAFs I think.

The devil is in the details. As a random example, you might have a process where all the pre-WAF requests (or explicitly the requests blocked by WAF) get forwarded to a log analysis system that itself uses log4j and is vulnerable, allowing the attacker to gain RCE in your monitoring infrastructure. Also, blocking any request containing "{" is tricky - like, that's so generic that it's time-consuming to verify that it…

You could also have a log analysis system that displays logs in the browser and has an XSS vulnerability. So that bypass isn't unique to log4j.

> JSON

You could probably write a more advanced check than just "{" that would let most JSON through while still blocking the attack.

Re: CISA Director on Log4j Vulnerability

#80

Post by Thorrez »

simcop2387 wrote: post #19
Thorrez wrote: post #16

Earlier quoted context omitted.

If the WAF blocks any request containing "{", that would be fairly safe, right? Yes, some attacks could still get through (e.g. a backend that receives requests base64-encoded), but that's the case generally with WAFs I think.

Thag would also mean blocking any apis that use json. This would not end well in the short term, or long term.

You could probably write a more advanced check than just "{" that would let most JSON through while still blocking the attack.
Post reply on HN