Security Firm Blumira Discovers Major New Log4j Attack Vector (zdnet.com) 91
Previously, one assumption about the 10 out of 10 Log4j security vulnerability was that it was limited to exposed vulnerable servers. We were wrong. The security company Blumira claims to have found a new, exciting Log4j attack vector. ZDNet reports: According to Blumira, this newly-discovered Javascript WebSocket attack vector can be exploited through the path of a listening server on their machine or local network. An attacker can simply navigate to a website and trigger the vulnerability. Adding insult to injury, WebSocket connections within the host can be difficult to gain deep visibility into. That means it's even harder to detect this vulnerability and attacks using it. This vector significantly expands the attack surface. How much so? It can be used on services running as localhost, which are not exposed to a network. This is what we like to call a "Shoot me now" kind of problem. Oh, and did I mention? The client itself has no direct control over WebSocket connections. They can silently start when a webpage loads. Don't you love the word "silently" in this context? I know I do.
In their proof-of-concept attack, Blumira found that by using one of the many Java Naming and Directory Interface (JNDI) exploits that they could trigger via a file path URL using a WebSocket connection to machines with an installed vulnerable Log4j2 library. All that was needed to trigger success was a path request that was started on the web page load. Simple, but deadly. Making matters worse, it doesn't need to be localhost. WebSockets allow for connections to any IP. Let me repeat, "Any IP" and that includes private IP space.
Next, as the page loads, it will initiate a local WebSocket connection, hit the vulnerable listening server, and connect out over the identified type of connection based on the JNDI connection string. The researchers saw the most success utilizing Java Remote Method Invocation (RMI). default port 1099., although we are often seeing custom ports used. Simply port scanning, a technique already in the WebSocket hacker handbook, was the easiest path to a successful attack. Making detecting such attacks even harder, the company found "specific patterns should not be expected as it is easy to trigger traffic passively in the background." Then, an open port to a local service or a service accessible to the host is found, it can then drop the JNDI exploit string in path or parameters. "When this happens, the vulnerable host calls out to the exploit server, loads the attacker's class, and executes it with java.exe as the parent process." Then the attacker can run whatever he wants. Blumira suggests users "update all local development efforts, internal applications, and internet-facing environments to Log4j 2.16 as soon as possible, before threat actors can weaponize this exploit further," reports ZDNet.
"You should also look closely at your network firewall and egress filtering. [...] In particular, make sure that only certain machines can send out traffic over 53, 389, 636, and 1099 ports. All other ports should be blocked." The report continues: "Finally, since weaponized Log4j applications often attempt to call back home to their masters over random high ports, you should block their access to such ports. "
In their proof-of-concept attack, Blumira found that by using one of the many Java Naming and Directory Interface (JNDI) exploits that they could trigger via a file path URL using a WebSocket connection to machines with an installed vulnerable Log4j2 library. All that was needed to trigger success was a path request that was started on the web page load. Simple, but deadly. Making matters worse, it doesn't need to be localhost. WebSockets allow for connections to any IP. Let me repeat, "Any IP" and that includes private IP space.
Next, as the page loads, it will initiate a local WebSocket connection, hit the vulnerable listening server, and connect out over the identified type of connection based on the JNDI connection string. The researchers saw the most success utilizing Java Remote Method Invocation (RMI). default port 1099., although we are often seeing custom ports used. Simply port scanning, a technique already in the WebSocket hacker handbook, was the easiest path to a successful attack. Making detecting such attacks even harder, the company found "specific patterns should not be expected as it is easy to trigger traffic passively in the background." Then, an open port to a local service or a service accessible to the host is found, it can then drop the JNDI exploit string in path or parameters. "When this happens, the vulnerable host calls out to the exploit server, loads the attacker's class, and executes it with java.exe as the parent process." Then the attacker can run whatever he wants. Blumira suggests users "update all local development efforts, internal applications, and internet-facing environments to Log4j 2.16 as soon as possible, before threat actors can weaponize this exploit further," reports ZDNet.
"You should also look closely at your network firewall and egress filtering. [...] In particular, make sure that only certain machines can send out traffic over 53, 389, 636, and 1099 ports. All other ports should be blocked." The report continues: "Finally, since weaponized Log4j applications often attempt to call back home to their masters over random high ports, you should block their access to such ports. "
stop, relax, think (Score:1)
Re: stop, relax, think (Score:2)
Re: stop, relax, think (Score:5, Interesting)
Don't blame the module, it's a tiny tool made as a hobby by a few developers on their spare time. Blame the huge multi-billionaire corporations who grab it, see the permissive license, think "cool! we can spare a few cents!", and never bother, you know, paying someone to do security audits and hardening of the free tools they came to so desperately and thoroughly depend upon.
Re: stop, relax, think (Score:5, Funny)
I blame Randall Munroe for foreseeing this: https://xkcd.com/2347/ [xkcd.com]
Re: (Score:3)
In my experience, many bottom-of-the-totem-pole developers are just as quick to grab free tools whenever they can. I have found the attitude to be pervasive, and in fact it seems like blind faith in free code is more the norm.
Don't get me wrong. I am a Linux user myself. I think open source is awesome! But when it comes to my professional work, I tend to think that we should code things ourselves whenever we can, and only rely on others (paid or free) when the nature of the task is outside of our skills
Re: stop, relax, think (Score:3)
I think this comes from unit tests. In house devs don't want to write unit tests, and they don't have to write any tests after adding 200,000 lines of code of open source software to the project.
Devs don't want to admit they just don't want to write tests, so they come up with sophistry to convince themselves it's not their own failures.
Re: stop, relax, think (Score:4, Insightful)
A couple of things. For a modern backend enterprise server web application that might have to parse html, xml, json, and maybe a few other domain specific languages, speak ldap, some SQL dialect, https, websockets and who knows what else - if you have to code all that baseline functionality yourself, you will never get to the point of making it do anything useful before you are out of business. Instead you build on top of something like Spring Framework, which might pull in a couple of dozen of free libraries, you build in a dependency vulnerability checker into your build process, and you cross your fingers.
As far as logging goes. Yes it is an easy thing to build yourself. What is trickier is orchestrating the log output of all the libraries you pull in so they are all logging to the same place and in the same format. That is why most projects link in a logging lib. Then you just provide a config file for that lib and you've configured the logging for all your modules. These days most projects target slf4j which is a meta logging lib. It provides a common API and you can plug in whatever logging library you want at compile time by linking in that log lib and the appropriate slf4j bridge.
Re: (Score:2)
log4j is an Apache foundation managed project. Those usually come with some minimum expectation of quality. Now given that, this bug was out there for a really long time and no one found it before, so I can't really blame them.
Re: (Score:3, Interesting)
I think it's safe to say that this log4j module is a steaming piece of garbage and all software devs who use it should remove it. At this point things are getting absurd on the verge of ridiculous. How much more time are people going to have to waste on this (during the start of the holidays no less)
Actually the steaming pile here is Java and its broken design. The problem is that with the stupid paradigms pushed, JNDI needs to try really hard to find a class now. Of course, it tries hard for an attacker as well and that is something that the morons behind the whole approach obviously never considered.
Re: (Score:2)
Re: (Score:3, Interesting)
There is also a meta-problem: Why did this functionality get into JNDI in the first place and why was it so easy to activate or on by default?
This rather strongly points to designers that have no clue about security and that will have screwed up in other places as well and that will screw up again. KISS is king when you need security. JNDI is the very anti-thesis to KISS, even if this particular instance of "too helpful complexity" is hopefully now fixed.
Re: (Score:2)
Re: (Score:2)
By today's standards, any design from ten or twenty (or twenty five in the case of Java) is broken.
Not at all. UNIX for example is not. X11 is not even if it is a close thing. OpenSSH (22 years old) is not. Incidentally, C is not. (C++ is, but that is a different discussion.) And a lot of other things are not. Yes, all of these received fixes on implementation level. There may even have been some design changes. But the designs were sound right from the start, because they were done by people with a clue.
The actual reality is that the Java design is shoddy right from the start and cannot be fixed. It is
Re: (Score:2)
The design of the Linux kernel is anything but ideal from a security standpoint. You should go back and read some of the back-and-forth between Linux and Tannenbaum.
OpenSSH has had plenty of pretty serious exploits as well. https://cve.mitre.org/cgi-bin/... [mitre.org]
This is a case where preconceived ideas are impacting the response to data. Java was leaps and bounds
Re: (Score:2)
You do not understand what you are talking about. Counting CVEs is not a useful metric in any way. For the Linux kernel, it is mostly divers and there are a lot of drivers in it. Also, have you actually _read_ the CVEs for OpenSSH? They concern obscure border cases, non-standard uses and the like. OpenSSH has not had a serious vulnerability in ages.
As to why Java became popular: Despite being an utter crappy language, it allowed low-skill people to get something to actually run. C will nicely block the utte
Java's monolithic design (Score:2)
Was a bit unfortunate. Things like JNDI should have been put in standard libraries that can be replaced. That was one of the few good things about C.
But the Log4j evilness was to be looking stuff up in the first place, and to do it on the full log text.
I use my own shim in front of Java logging. It can then go to either SLF4J or Apache Commons that my users may want, which in turn goes into a base logging system. Complexity plus! But it means that I can sanitize the log messages, kill all "${" and so s
Fuckers! (Score:2)
It's getting near XMas!!! Couldn't they wait and talk about this in January. I pity the foo who's gonna have to spend XMas eve on VPN patching shit ... And I'm that foo, too.
C++, dont care (Score:1, Troll)
I was too busy ignoring all the time and advice and wrote my stuff with C++.
Oatpp running my sites just fine using my own logging mechanism.
Re: (Score:2)
Re: (Score:3, Informative)
Ask yourself why that is, and what predictions you can make about the future of this company. Can you tell us where this was so that we can sell the stock?
Re:C++, dont care (Score:5, Interesting)
Maybe. Maybe not. Depends on the parameters. Are there any closed source libraries that they have to use in order to work with some legacy system that some finicky asshole in a high place refuses to let go of? If so, good luck getting rid of it until said asshole either quits or is fired. I guess you could reverse engineer it, but that might get expensive, and add that cost on top of whatever it costs to either train or replace your aging and soon to be obsoleted java developers.
Java as a language is a shitshow to competent developers that know that most other languages beat the hell out of it when it comes to its crappy tooling and even crappier needlessly verbose syntax. The JRE is an even bigger shitshow for system admins that have to put up with its constantly breaking shit for no obvious reason, or needing to run two pieces of legacy software that require two different versions of the JRE on the same server.
If you've had the misfortune of wearing both of those hats, you'll hate Java even more. Oh and how about the newer versions of log4j breaking older stuff and the fixes won't be backported? Yeah, that's always fun.
Re: C++, dont care (Score:2)
Re: (Score:2)
add that cost on top of whatever it costs to either train or replace your aging and soon to be obsoleted java developers.
COBOL just saying "Hi" to Java.
Re: (Score:3)
For the purposes of this exercise I'm going to assume that you're advocating for using Haskell as the development language for high-level information processing and a little bit of C and/or assembler for low-level bit or I/O manipulation, because any other assumption would lead me to believe you're an assistant junior test developer.
Re: (Score:2)
No, I've never actually used Haskell. Now Kotlin, there's a good Java replacement, though it still needs the JRE sadly, unless circumstances permit you to build native binaries. C# does a lot of things a lot better than Java does as well, and the tooling and the framework are so much easier to work with for everybody involved on any platform (linux, windows, and mac all work well), though it's not necessarily the right language (like say, needing to interact with other Java code.) C# improved upon Java, and
Re: (Score:2)
The Java developers got away with lying.
Lying about what?
Sure you can rewrite software in any language.
But considering that your software might be only 100k lines, it might pull in a few million lines of libraries. You have to rewrite those, too.
People with your ignorant comments, usually lack the expertise to write such libraries ...
Hmmm (Score:5, Funny)
I'm not sure this is specifically what they had in mind back when they penned the slogan "Write once, run anywhere!"
Re:Hmmm (Score:4, Insightful)
Log4j has a plugin system, and that alone should give pause w.r.t. security since now plugins are also a vector.
Log4j supports 3 different configuration formats (xml, json, yaml) because why not take the opportunity to complicate things.
Log4j is many api's rolled into one as it presents multiple different apis as desired to be a replacement for other logging libraries, such as the original java.util.logging api. Having many different interaction methods rooted in other peoples libraries of differing capabilities, doesnt complicate things either, right?
All these monoliths are disasters waiting to happen. Even if you yourself vet every line of code, thats just one version, what about the next? The monolith grows.
Re:Hmmm (Score:4, Insightful)
such as the original java.util.logging api.
That is not the "original"
Log4J is the original.
On top of all those logging stuff is JEP 158, perhaps you are mixing that up with Log4J.
Re:All these monoliths are disasters... (Score:1)
SystemD joins the room
*ducks*
Re: (Score:1)
Re: (Score:2)
Maybe every interaction between separate packages introduces lots of room for attack, as there are edge conditions and underlying assumptions which are not well understood nor tested.
In any case, the origin of log4j woes seem to have very little in common with the above.
- parsing of json or yaml or xml config files is not an issue here
- having jndi turned on by default in the jvm is just brain-dead. Barring removing it altogether from java, it sho
Re: (Score:1)
Re: (Score:1)
It works on anything. So does anal sex. You might not like it though. Idiots need to remember that we did everything before Java was invented, including e-commerce and streaming media, on-demand, etc etc. where the *SERVER* did the heavy computing and not the client.
Oh hurray (Score:3)
I look forward to another round of emergency meetings where my group is again drilled by a bunch of review teams and we again mention that we don't actually have java runtimes in any of our services, and probably get told to run a new suite of scanners for log4j vulnerabilities anyway, 'just in case'. Now not only during off hours but while everyone is supposed to be on vacation.
Re:Oh hurray (Score:5, Insightful)
Re: (Score:2)
Eh, I'm being a touch melodramatic about what might amount to 30 minutes of time, annoying spread across 4 independent groups requesting. I'm generally able to hold 40 hour work weeks and take plenty of my vacation without incident, with maybe 3 or 4 interruptions a year. The nature of the log4j interruptions annoyed me more as it was panic over not applicable and this sort of BS interruption has happened twice that I can recall over the years I've worked there.
Re: (Score:3)
But when they need to check "just in case" a Java runtime was magically installed by accident, and can't determine that with a quick check based on their existing processes, then that tells me the existing auditing process are also just plain shit.
I'm not saying they shouldn't be checking, but they have a lot more problems if they can't verify such a simple thing with an equally simple audit
Re: (Score:2)
The visibility into the IT estate varies a lot from company to company. However, I’ve found that in most cases, IT and security will have a pretty good visibility into what’s installed on servers and where. Usage, on the other hand, can be more problematic - some companies struggled to understand where print queues were used this summer, making it difficult to tell whether PrintNightmare was exposing them or not. Same with log4j in some cases.
But where the real challenge comes in is with contain
Re: (Score:3)
Re: (Score:2)
The contents of a container is written in plain english, ASCII or Unicode, in an Kybernetes, Ansible, Muppet etc. p.p. description file. You pretty well know what is inside of the container. Worst case you SSH into it and use your bash fu.
Re: (Score:2)
The issue is a panicked bureaucracy does weird things.
In our case, there are 4 interested parties: corporate IT, a wholly independent IT group of our division that basiccally was our executives making their own because corp IT wouldn't support a lot of what we wanted to do, a security auditing team independent of both of those that usually supervises groups security practices, but largely lets them self manage, and my own team, which develops software for customers and frankly does a little 'shadow IT' of o
Re: (Score:2)
It's not just Websockets, there are a million other Internet protocols that can have the client (victim) send traffic to arbitrary addresses and ports on behalf of an attacker. My favourite one is certificates, you can use those to probe internal networks if you can convince a victim to connect to your server, so just starting the SSL handshake gets you (admittedly somewhat constrained) access to the internal network they're coming from.
So "firewall off your Java crap" doesn't work. It stops the direct,
Re: (Score:2)
In the case of log4j, we aren't "firewalling off our java crap", we don't even have a JRE in anything we are responsible for. It happens to be that none of our software nor our dependencies happened to require java. This panicked auditing is narrowly focused on log4j, there's a background level of security processes intended to generally handle the myriad of industry wide security risks that don't land on news sites the executives read.
Re: Oh hurray (Score:1)
Re: (Score:2)
PKI standards are written to be flexible enough to allow almost anything. In particular, the 7 million hacks that exist for revocation checking allow the cert to specify which address and port it wants a victim to visit for the revocation check, sort of a "go to this host/address and poke this port for the revocation check". So if the victim's network is 192.168.1.x you issue a cert that directs the victim to 192.168.1.1, then 192.168.1.2, etc until they've scanned their entire subnet for you. Once you k
I did this last week (Score:2)
apt remove liblog4j1.2-java
This is fine for this server because it isn't serving anything via Java, lucky me.
Re: I did this last week (Score:2)
Unless it's embedded into some other Java app...
Re: I did this last week (Score:4, Insightful)
Re: I did this last week (Score:4, Funny)
That's the one.
Re: I did this last week (Score:1)
Re: (Score:2)
Re: (Score:3)
Of course not, proper 'enterprise' server software ships with /opt/vendornamehere/jre-ancientversion/bin/java.
Re: (Score:1)
That's the big problem with Java. Products often ship with their own version of java because their stuff only runs on one version of java at a time. The system may not have java, yet their product tree does and is vulnerable.
I used to hate it when I had to watch 3500+ machines. Guess which ones have a vulnerable piece of java software on them. Answer - almost all of them.
Re: (Score:2)
Don't use apt, do you.
Re: (Score:2)
> apt remove liblog4j1.2-java
Not a bad idea if you are not using it anyway but you have removed version 1.2 which is not affected by these recent issues. They really need to make it properly clear that this affects log4j2.
Re: (Score:3)
A dormant file, even if it is a dreaded java library, hardly is a security risk on your comp. Facepalm.
Re: (Score:2)
Now we're sure it's dormant, aren't we. Patched your own systems yet genius?
Re: (Score:1)
I don't have a system with Java running :P ...
But plenty of log4j libraries in my maven repository
Now we're sure it's dormant, aren't we.
Yes we are.
$ sudo ps axu | grep java
Ooops, no Java running.
Dumbass.
Re: (Score:2)
Heh, apparently the concept of network services is too advanced for you. Why am I not surprised?
Stepped in it you did.
Re: (Score:2)
No it is not.
No idea why you are surprised.
Point is: on my machine there is no networked service.
Ooops.
Why I'm surprised that you do not know that.
Do you have any networked services on your PC or laptop? I don't think so.
Re: (Score:2)
You have sshd running on your laptop and your PC or else you are a complete chump poser. I'd put money on the latter.
Re: (Score:2)
And what has sshd to do with log4j or Java?
Actually, I don't have sshd running, why would I?
To have sshd running I have to change a config file - which I did not do, as I do not need it.
Re: (Score:2)
You claimed you had no network software running on your PC or laptop. Blowhard.
Re: (Score:2)
You claimed you had no network software running on your PC or laptop.
Exactly.
And what is your stupid post supposed to mean?
Re: (Score:2)
You cosplay a technologist. Nobody is fooled.
Re: (Score:2)
And you cosplay as an insulting idiot.
Not really sure if that is called "cosplay".
Idunn2:~ angelos$ sudo ps axu | grep sshd
Password:
Sorry, try again.
Password:
angelos 13384 0,0 0,0 4287496 836 s000 S+ 2:30pm 0:00.01 grep sshd
Idunn2:~ angelos$
Does not look like there is an sshd running, or do you see one?
Re: (Score:2)
Exactly. You're not running sshd because you wouldn't know what to do with it.
Re: (Score:2)
No idea why you want to talk about sshd ...
Go back to your favourite computer game.
Re: (Score:2)
You said you weren't running any network services, not realizing why you outs you as a fake.
Re: (Score:2)
You said you weren't running any network services, not realizing why that outs you as a fake.
Re: (Score:2)
I'm on a laptop, moron.
I'm not running any network services on this laptop.
So: what is fake about this? You do not knwo what a network service is?
Why do you try to harrass me when you not even have the simplest clue about computers?
Or do you think a web browser is a "network service"?
On my computer is not a single open port, dumbass.
Re: (Score:2)
apt remove liblog4j1.2-java
This is fine for this server because it isn't serving anything via Java, lucky me.
You removed the wrong version.
Re: (Score:2)
*removed the only version.
Stop,relax,think (Score:1)
Re: Stop,relax,think (Score:2)
Re: (Score:1)
Not a new exploit (Score:4, Informative)
It depends on the `${jndi:...}` issue.
Re: (Score:2)
Indeed.
The article does not make it clear (Score:5, Informative)
Update Java (Score:2, Informative)
J8u181 have disabled the JNDI/LDAP functionality required by this exploit. If your Java has been updated in the past three years, you should be ok. Of course, you still need to update log4j.
Re: (Score:1)
Sadly this isn't 100% true, the RCE has been replicated in supposedly secure versions of Java in conjunction with the insecure version of log4j2.
"No client control" is misleading. (Score:2)
> The client itself has no direct control over WebSocket connections. They can silently start when a webpage loads.
"No client control" is misleading. A client that blocks JavaScript will not issue a JavaScript WebSocket request in the first place, and hence the connection can NOT "silently start" when a web page loads.
(this may stop some functions of the web page from working, which -- in this case -- may be a good thing)
Re: "No client control" is misleading. (Score:1)
Re: "No client control" is misleading. (Score:1)
Re: "No client control" is misleading. (Score:2)
+17 Insightful.
Re: (Score:1)
I doubt the attacking client is going to disable the mechanism that their attack vector depends upon.
Huh (Score:1)