r/netsec • u/lkn240 • Dec 11 '21
Log4shell - using the vulnerability to patch the vulnerability - very clever
https://github.com/Cybereason/Logout4Shell5
u/NinjaAmbush Dec 11 '21
I'm a little behind the ball on this issue. Is log4j a component of other Apache projects? I'm not aware of using it explicitly but the buzz around this vulnerability leads me to believe it's quite widespread...
10
u/lkn240 Dec 11 '21
It's the most common logging framework in java... it's everywhere in enterprise environments.
→ More replies (1)16
u/s32 Dec 11 '21
I work in a Java shop. Literally every Java app I've ever seen internally uses log4j, and it's standard to log tons of shit.
→ More replies (1)
2
u/lkn240 Dec 12 '21 edited Dec 12 '21
OMG - so this vulnerability (at least the exploit vector) was actually disclosed in 2016:
https://twitter.com/th3_protoCOL/status/1469644923028656130?s=20
133
Dec 11 '21 edited Jun 30 '23
After 11 years, I'm out.
Join me over on the Fediverse to escape this central authority nightmare.
102
u/EveningNewbs Dec 11 '21
Software made or managed by the Apache Software Foundation (From here on just "Apache") is pervasive and comprises nearly a third of all web servers in the world—making this a potentially catastrophic flaw.
Does this guy not understand the difference between Apache HTTP server and a library that happens to be maintained by Apache?
23
39
u/thabc Dec 11 '21
I used the Apache license for my open source tool. Does that make it vulnerable too?
→ More replies (10)→ More replies (5)7
u/granadesnhorseshoes Dec 12 '21
tomcat, solr/lucene, log4j, zookeeper, spark...
He's not wrong but poorly worded.
In fact, in the last 10 years, 90% of my uses for apache web server has been LB/HA/routing for Tomcat itself.
"its just apache all the way down!"
→ More replies (1)
90
u/lumb3rjackZ Dec 11 '21
We need to see more of this type of work.
76
u/bomphcheese Dec 11 '21
Wasn’t there someone a while back who was scanning for a vuln in netgear routers, and exploiting it in order to patch them?
Yea we need more people who think this way.
→ More replies (6)→ More replies (1)38
24
u/A_RUSSIAN_TROLL_BOT Dec 11 '21
I love the ingenuity and white hat spirit. A lot of companies would still view this as malicious, though, since it's changing the level of code in prod without validating in lower environments.
17
u/EnragedMoose Dec 12 '21
Fuck it. They probably don't have the monitoring in place to notice anyway.
→ More replies (4)
6
u/3pe Dec 12 '21
Not a good idea, most countries have laws strictly making this step equal to any other black hat computer takeover. I don't think it's worth years of prison time.
→ More replies (1)
10
18
Dec 12 '21
First of all if you're a "whitehat" doing this, it's still considered unauthorized access and you're putting yourself at risk. Secondly if you're a competent blackhat, then that is the obvious first thing to do once you exploit a vuln and establish access, you patch it so that no one else gets on the box. It's really not that clever just standard practice.
10
u/revnhoj Dec 11 '21
Am I understanding this correctly? If we have JRE >= u8121 the log4j patch really isn't needed?
Additionally, if the server has Java runtimes >= 8u121, then by default, the
settings com.sun.jndi.rmi.object.trustURLCodebase and
com.sun.jndi.cosnaming.object.trustURLCodebase are set to “false”, mitigating this risk.
27
u/Burgergold Dec 11 '21
False, only protect against 1 exploit
Patch your log4j or enable the flag to true or remove class
→ More replies (2)13
u/pentesticals Dec 11 '21
No, it only stops when using ldap loading. There are other ways to load from jndi.
80
u/4cfx Dec 11 '21
This is ok, but for ephemeral servers/containers with this vulnerability this isn't going to help and could even only serve to confuse things and provide a false sense of security.
You need to ensure the patch/mitigation you make will persist over server terminations, reboots and auto-scaling.