Home › Forums › Chat Forum › Log4Shell
- This topic has 44 replies, 20 voices, and was last updated 2 years ago by julians.
-
Log4Shell
-
GEDAFree Member
Sooo. Exactly how much of a panic should we be in to fix this? :()
willardFull MemberWell, it depends.
It’s an unauthenticated remote code ex3cution bug that do3s not need the vulnerable component exposed to the internet to be exploited, which means that, for attackers at least, you can automate the exploit and just spray the internet. If you get vulnerable systems, you win with minimal effort, so in that way it is really quite serious.
With that in mind, there is reported to be a log4j config mitigation and attack traffic should be visible with something like Yara or with a decent firewall, and (assuming you have a software inventory) it should be a relatively straightforward job to upgrade log4j to the version that contains the fix.
For me, I’d be checking all systems that have a footprint on any untrusted network to see if they use an impacted version of Log4j and then either patching or configuring them with the mitigation and I would be doing it quickly.
leffeboyFull MemberExactly how much of a panic should we be in to fix this? :()
I would be looking at how much stuff I had that is likely to be vulnerable. I always get twitchy when looking at our weblogs just how many attacks are going on as background noise all the time. I took a little too long after the last big Drupal vulnerability and sure enough we got hacked. It’s not that we are a target, just that the exploit tools spray everywhere looking for people who are vulnerable 🙁
If you have a website hosted by someone else then they will look after it as you won’t have access to the appropriate bits. If you are hosting it yourself then you probably already know this stuff. If you have something at work/home that you can remotely connect to by a web interface e.g. a NAS box, web cams, UniFi wireless network, that sort of thing then I would be checking to see if there are any updates being released
mogrimFull Memberit should be a relatively straightforward job to upgrade log4j to the version that contains the fix.
lol yeah right. Pretty much any Java-based enterprise application will be using log4j, good luck upgrading log4j on a product you’ve bought without messing with the support guarantee etc. This looks like a real **** for the big companies (and government departments etc).
multi21Free MemberMy god that looks like a nightmare.
Whats the reason for the feature existing? It sounds insane.
mogrimFull MemberWhats the reason for the feature existing? It sounds insane.
I’m guessing it’s for getting user information to add to the log, but they didn’t realise the jndi part allowed the remote server to inject code into the calling process.
jwrayFull MemberOn the positive side a lot of modern Java development does not use log4j but rather slf4j+logback. I went over all our internally developed apps, and all third party, this morning. Maybe 30-40 different runtimes. Not one was a problem.
I’m guessing still a big issue but I’m curious about the stats when it’s all over
mogrimFull MemberThis is worth a quick read if you’re interested on how we got to this point: https://www.reddit.com/r/java/comments/rdv98z/have_you_ever_wondered_how_javas_logging/
Over time, that has accreted (as libraries are wont to do), with more and more features, like interpolation of variables looked up in JNDI – that being a decent mechanism of abstracting configuration, popular in the mid 2000s when applications got deployed to app servers.
Seems like my guess was wrong: the JNDI lookup was to sort out configuration issues. Still not sure why that lets you inject a class into the process, though!
FuzzyWuzzyFull MemberFor me, I’d be checking all systems that have a footprint on any untrusted network to see if they use an impacted version of Log4j and then either patching or configuring them with the mitigation and I would be doing it quickly
This is part of the issue though – it’s used ‘underneath the hood’ on huge numbers of enterprise apps. Take VMware stuff for example – they’ve now published a list of their products that are impacted and it’s a long list. You also can’t just directly patch Log4j in many cases, you have to wait for the enterprise app vendor to release a fix
I’m just glad I work in secure environments with no Internet connectivity :p
willardFull MemberAh, I never said non-internet, I said untrusted networks. Non-privileged malicious users _could_ use a packaged exploit to execute code on those servers from, for example, internal untrusted networks, thereby gaining access on impacted servers.
I completely agree with you about the enterprise software though, should have made that clearer in my post. Any good software provider will have hopefully notified its customers of the vulnerability, any potential mitigations and a fix timescale.
CougarFull MemberI couldn’t see how this could be turned into RCE. Seems I was wrong.
#log4j storm is coming, cryptominers in the first wave.
checked multiple (non-java 😉 ) webservers i run and the logs are getting filled with the ${jndi:ldap://…} payloads.
THREAD: let's see a weaponized one. pic.twitter.com/vQWchHdiGJ
— an0n (@an0n_r0) December 10, 2021
That’s deeply disturbing.
FuzzyWuzzyFull MemberYeah – we’re urgently reviewing all gateway devices (firewalls, content inspection, email protection devices etc.) for any environment that has external connectivity, those are our main concern rather than apps right now (not that internal hosted apps aren’t at risk to, especially if the gateways are compromised)
rossburtonFree MemberI couldn’t see how this could be turned into RCE. Seems I was wrong.
Yeah, thanks Java. The result from the lookup can be a class, which gets instantiated. Not at all terrifying.
rossburtonFree MemberIn other news, it’s great to have a real world example why bundling components is a terrible idea for security.
mickyfinnFree MemberSo you all allow outgoing LDAP on your firewalls to any up address? #shakeshead #thankheavensforpacketinspection 😉
CougarFull MemberThis is not good.
https://www.vmware.com/security/advisories/VMSA-2021-0028.html
CougarFull MemberIn other news,
Is it not time that Java followed Flash and died in a fire?
swedishmattFree MemberI guess this is why my MS platform manager, who happens to be my manager, has been on DND all day. And the technical security guy too.
I’ve reached Nirvana where I’m not in ops.
HAHAHAHA.
(As you were).
swedishmattFree MemberHoly smokes the amount of apps (many custom) at my place of work is insane (and my former role would have been two custom apps for me to fix,). Hundreds in total…..wow.
This is huge.
willardFull MemberYes. Heart bleed was bad, this is the same sort of thing. I’m mentally classifying everything into “things visible from the Internet”, “things available internally to people that I don’t trust”, “everything else”.
Even that is a bastard
tafFree MemberAnyone successfully exploited this? Spent most of the day looking at many systems and only able to exploit one which was a development system and required authentication first with debugging enabled.
rossburtonFree MemberThe PoC was effective albeit harmless, and there’s an exploit in the wild where the LDAP response is a generic execution class, which then runs a coin miner.
leffeboyFull MemberI’m not liking the concept of someone changing their phone name and then going onto a managed wifi network that might be logging. The possibilities with this are really horrible although it will be interesting to see how it plays out in reality.
CountZeroFull MemberI’ve read through this thread, and in large parts of it, I recognise the letters/characters being used, but the order they’re in makes no sense whatsoever!
I think I have a migraine coming on…
GreybeardFree MemberThis is the kind of thread where I realise I don’t know as much as I thought I did about computers.
I can see this requires a action from system managers, but how much at risk are domestic users? Things like cat flap and CCTV that use an external server to link to your phone might be at risk? Router firmware? Apart from updating OS and apps, when updates are available, is there anything else? Turn the devices off until there’s a fix?
juliansFree MemberThis is the kind of thread where I realise I don’t know as much as I thought I did about computers.
I can see this requires a action from system managers, but how much at risk are domestic users? Things like cat flap and CCTV that use an external server to link to your phone might be at risk? Router firmware? Apart from updating OS and apps, when updates are available, is there anything else? Turn the devices off until there’s a fix?
its unlikely that thing like a catflap itself will be using log4j, but if the flap connects to a cloud service to do its thing, then that might well use log4j and hence be vulnerable to attack. The question is what can an attacker do if they compromise the cloud service – and that depends, maybe they could get some personal data ( customer names, addresses, payment details etc etc), maybe they could cause an outage of everyones cat flaps. Turning off your flap is not going to prevent this attack though.
The router is an interesting one, its more likely it uses log4j than say the cat flap , but who knows whether its configured in a way as to be vulnerable, you could turn it off to be on the safe side, but I think unless your isp/router manufacturer says to do that, you’re probably ok leaving it on.
IN summary – for home users – dont worry about it unless told to worry about it by someone who makes the kit in your home – if there is a software update then get it applied asap.
mogrimFull MemberIs it not time that Java followed Flash and died in a fire?
And what do you propose replacing it with? I’m finding it hard to imagine a language that would stop the issues you get from allowing remote configuration the way log4j did. Java is a great language for server-side application programming – it’s fast, stable, great tooling, plays nicely with version control systems, etc.
FuzzyWuzzyFull MemberBy default the firewall on your router should be dropping inbound requests so unless you’re hosting an application you have people on the Internet connecting to (which could include running a Minecraft server…) you shouldn’t have much to worry about (it’s far more likely you’ll have unpatched router vulnerabilities or misconfiguration than being exposed to this vulnerability).
Ofc you could get malware in via email/file download /dodgy web-sites that could exploit the vulnerability but there’s thousands of other vulnerabilities that could be exploited that way. It’s still probably worth looking at vendor statements on it for any apps you suspect might run Java virtual machines (or just aren’t sure about) but I wouldn’t lose any sleep over it.
Personally I’m not planning to do anything on my home network, professionally we’re pretty calm about it but are still going to evaluate workarounds and patches for all apps we discover are impacted as although pretty much none would have a route out to the Internet (in order to call home and download malware) there’s still the insider threat issue to address. For a ‘normal’ business I’d be a bit more concerned as internal systems will have a much greater likelihood of having a route out to the Internet (and much easier routes in for malware even if your external gateway protected against crude network scanning attempts to exploit the vulnerability).
rossburtonFree MemberBy default the firewall on your router should be dropping inbound requests so unless you’re hosting an application you have people on the Internet connecting to (which could include running a Minecraft server…) you shouldn’t have much to worry about (it’s far more likely you’ll have unpatched router vulnerabilities or misconfiguration than being exposed to this vulnerability).
Not sure I agree with this. A home NAS that has log4j on (which isn’t unlikely at all, considering some common media servers are written in Java) may do something like log connected device names, or wifi networks it can see. Connections are then *outgoing* to fetch exploit code, nothing is initiated externally.
scuttlerFull Member@rossburton how would the call to fetch the malware be initiated? I know it’s technically possible but only from the inside if the exploitable device isn’t internet facing. I’ll rule out insider threat on home networks 😉
rossburtonFree MemberSay you have a media server with a vulnerable log4j which for vague reasons logs the names of all wifi networks it can see. I walk past with a phone exposing a wifi network with a network called “${jndi:ldap…}”. The server logs that, log4j does the LDAP lookup, and this is an outgoing request so the response back won’t be filtered by a firewall. Considering the hostile LDAP server could be sitting on port 80 to avoid trivial filtering the only way to block that with a firewall would be deep packet inspection to detect any outgoing LDAP.
Alternative scenario: a router which uses log4j and logs usernames that fail authentication.
rossburtonFree MemberOh and the famous concrete example was Minecraft. The ‘classic’ build is in Java and uses log4j, so if you join a server other users can exploit you.
scuttlerFull MemberNot saying it’s not possible, just non-trivial ‘vague reasons’ vs internet facing web / application server where you can just spray requests. We’re trying to alleviate the concerns of home users here to whom I’d say there’s little to worry about if you’re not exposing anything to the internet.
Still – patch and configure…
molgripsFree MemberIs it not time that Java followed Flash and died in a fire?
Not remotely the same thing.
scuttlerFull MemberAs an aside I caught Ep1 ‘Phreaks’ on the unhackable?? FM radio yesterday – https://www.bbc.co.uk/programmes/m0012fjk/episodes/guide
willardFull MemberIf you have been patching already, well done, but there is now a DoS that impacts the fix version: CVE-2021-45046
I have not looked at this yet, today’s fun I guess, but this is likely to be less of a priority than an RCE, depending on how available you want your services. Friends have suggested that the easiest mitigation for people that cannot upgrade easily again is to remove the JNDI lookup class from the jar file.
The topic ‘Log4Shell’ is closed to new replies.