CISA Director on Log4j Vulnerability
cisa.gov
cisa.gov
Not only "user facing" systems. Not even a WAF can protect these.
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.
https://blog.cloudflare.com/how-cloudflare-security-responde...
Also, blocking any request containing "{" is tricky - like, that's so generic that it's time-consuming to verify that it won't break anything, and it's very likely that JSON is used somewhere in that application traffic, so you can't simply do that.
> JSON
You could probably write a more advanced check than just "{" that would let most JSON through while still blocking the attack.
The further I get into security the more embarrassed I am for some of the offerings.
> embarrassed... for some of the offerings
Welcome to the club.
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 time span of 2 years, you can probably walk away with pretty penny! If they do get hacked, just pretend you technically _did_ see the alert, but a junior employee on your side failed to act on it. Sack them, and then re-hire them later. They are the 'fall' person whose job is basically getting fired. Give your customer a discount and try to stay on for 2 more years!
> Case in point: the Air Gap. Levy set up a website showcasing a magic amulet of his own creation. Like many cyber defences, his piece of hardware promised to defend against all known and unknown viruses, and stop zero day exploits. His product? An empty box with a blue blinking light on it. Levy had to take his website offline when he started getting sales enquiries by email.
https://www.wired.co.uk/article/ian-levy-national-centre-cyb...
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.
Shouldn’t this be happening, like, yesterday?
> We have established a JCDC senior leadership group to coordinate collective action and ensure shared visibility into both the prevalence of this vulnerability and threat activity
Very clearly they know what they will be doing.
This type of a call would likely be focused on assessing current state at that point.
I work for a large non-US based tech company and have not heard anything about this beyond HN.
Edit: upon checking, we're safe, it doesn't impact log4j1, only the second version. We're not cowboys using versions as young as 2012 lol.
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.
If the stakeholders participating in the call on Monday are not the people working on patching, managing, or prioritizing, then having the call earlier than that is pointless, because those stakeholders are too removed from the situation, and getting that information will detract from getting work done.
It's pretty simple really, having a status or coordination call while the work is being done is roughly analogous to a photo-op by a politician during an emergency. It looks good for the voters, but it takes away resources from the folks who are actually doing the work.
I’d like to say the scanners were fast but not fast enough because the first wave of attacks was nearly instant. This was definitely a nightmare scenario where a simple unauthenticated GET could pull in a kit that was already live and ready to go.
Making people look at a BOM would also discourage the mess that is npm.
Reviewing a stack of BOMs is going to be a challenge for any organization. Say your production Linux has 1000 packages. Each of those might have hundreds or thousands of deps in varying versions, in their respective package managers (BOMs).
Business needs to step up its process game. How are BOMS (dep lists) reviewed? Do we expect zero CVEs? How do you filter out false positives, or irrelevant ones? Do you dump everything with that dep or help the maintainer fix it? Many questions.
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.
Is it correct?
1. Step up and shoulder part of the finding for maintainers 2. Close their double quotes on press releases
Germany for now, but plans are to expand "up" to Europe as far as I know (we are all in the same boat, aren't we)
However, the thing that I wonder is why we still are in a position where every single application and every single dependency can attempt to load dlls (ref npm hacks lately) or reach out to the network?
Why is Deno the only one who seems to have a good solution for this, and why doesn't Deno have more traction?
I know one can do a lot more using outbound firewalls and selinux but after seeing how brilliantly Deno solves this I wonder why not every program lets me do this.
Anyway, how does Deno solve this?
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_started/permissions
As for the first part, I'm in the lucky position where nobody can just rewrite everything to todays flavor of js, but where we can decide in the team to test out new technology when we have a chance to, for example on a new small project. There's another guy on the team that is enthusiastic about it too and I guess he'll throw together a demo soon, then we'll discuss it.
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).
It's pretty rarely done though.
Exactly. That is why I like the Deno solution even as a long time Java user: it is on by default and so simple that there is no reason to disable it.
The Java Security Manager is an API that allows to intercept and run codes, so devs use it as a Trojan Horse to patch code instead of fixing the root of the issue.
The Java Security Manager should die.
But.. it is?
The JVM tracks where bytecode was loaded from, and then you can define a policy to limit what that code can do.
Here's an example giving read-only access to /etc
https://access.redhat.com/documentation/en-us/red_hat_jboss_...
If there’s no java, then there’s no log4j and you may worry about other issues.
Edit: I haven’t tested or checked whether ES is vulnerable or not - but given the severity of this issue I’d default to the pessimistic stance of assuming it is, until proven otherwise.
A frontend web developer doesn't manage nginx, nor ES.
The backend should be patched. It is not safe to just mitigate the bug by using code in the frontend.