Update on June 2022 Zimbra Patch release
https://blog.zimbra.com/2022/06/update-on-june-2022-zimbra-patch-release/ (June 20th 2022)

log4j-zero-day exploit - active attacks

Discuss your pilot or production implementation with other Zimbra admins or our engineers.
eneref
Posts: 2
Joined: Mon Dec 13, 2021 2:52 pm

Re: log4j-zero-day exploit - active attacks

Postby eneref » Mon Dec 13, 2021 5:28 pm

darkfader wrote:
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


But that's WORK....

Seriously, I'm happy to at least have gotten SOMEthing. But yeah. It's kind of a plus minus minus situation.


danielfarrelly
Advanced member
Advanced member
Posts: 145
Joined: Fri Sep 12, 2014 10:32 pm

Re: log4j-zero-day exploit - active attacks

Postby danielfarrelly » Mon Dec 13, 2021 10:12 pm

Have a hard time agreeing with Zimbra's assertions that the EOL version of log4j is unaffected. Would it be too much to ask them to update asap? This has the potential to be devastating, from a host point of view and for the Zimbra brand. Think it would be in Zimbra's best interest to update the lib(s) as quickly as possible.
User avatar
JDunphy
Outstanding Member
Outstanding Member
Posts: 721
Joined: Fri Sep 12, 2014 11:18 pm
Location: Victoria, BC
ZCS/ZD Version: 8.8.15_P32 RHEL8 Network Edition

Re: log4j-zero-day exploit - active attacks

Postby JDunphy » Tue Dec 14, 2021 1:14 am

This is starting to look like a gong show. log4j 2.15 has been replaced by an updated fix (2.16) today as they already found a bypass to the fix on Friday.

Worse ... lunasec just released a tool and mitigation guide at: https://www.lunasec.io/docs/blog/log4j- ... ion-guide/

Code: Select all

mkdir log4shell
cd log4shell
wget https://github.com/lunasec-io/lunasec/releases/download/v1.0.0-log4shell/lunasec_1.0.0-log4shell_Linux_x86_64.tar.gz
tar xvf lunasec_1.0.0-log4shell_Linux_x86_64.tar.gz
# as root
# ./log4shell scan /opt/zimbra
12:41AM INF identified vulnerable path fileName=org/apache/log4j/net/SocketNode.class path=/opt/zimbra/jetty_base/common/lib/log4j-1.2.16.jar versionInfo="log4j 1.2.16"
12:41AM INF identified vulnerable path fileName=org/apache/log4j/net/SocketNode.class path=/opt/zimbra/lib/jars/log4j-1.2.16.jar versionInfo="log4j 1.2.16"

This is because of CVE-2019-17571 which has recently been revised. see: https://nvd.nist.gov/vuln/detail/CVE-2019-17571
The exact problem is: "For Apache log4j versions from 1.2 (up to 1.2.17), the SocketServer class is vulnerable to deserialization of untrusted data, which leads to remote code execution if combined with a deserialization gadget.".

Ref: https://unit42.paloaltonetworks.com/apa ... 021-44228/

I guess we are too take them at their word that they looked into their code because it kind of looks like CVE-2019-17571 is a problem. It could also be that lunasec has included this hash when it should not have been but more than likely they feel that CVE-2019-17571 is a concern with so many eyes on CVE-2021-44228.

Note: in this thread khawkins and michnovka have already mentioned CVE-2019-17571 but something feels off that I can't rationalize myself. Maybe its the trusting of a software module that would execute any binary sent by an untrusted client is the cause. ;-) I opened a ticket because if anything detailing pathways for a RCE only leads to more problems so I'll end it here.

Jim
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

Postby andreaswolske » Tue Dec 14, 2021 6:24 am

Just to be on the safe side we added "log4j2.formatMsgNoLookups=true" to zimbra_zmjava_options.

Code: Select all

zmlocalconfig zimbra_zmjava_options
zimbra_zmjava_options = -Xmx256m -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -Djdk.tls.client.protocols=TLSv1,TLSv1.1,TLSv1.2 -Djava.net.preferIPv4Stack=true


Add log4j2.formatMsgNoLookups=true

Code: Select all

zmlocalconfig -e zimbra_zmjava_options="-Xmx256m -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -Djdk.tls.client.protocols=TLSv1,TLSv1.1,TLSv1.2 -Djava.net.preferIPv4Stack=true -Dlog4j2.formatMsgNoLookups=true"
zmcontrol restart
User avatar
maxxer
Outstanding Member
Outstanding Member
Posts: 208
Joined: Fri Oct 04, 2013 2:12 am
Contact:

Re: log4j-zero-day exploit - active attacks

Postby maxxer » Tue Dec 14, 2021 7:00 am

JDunphy wrote:I guess we are too take them at their word that they looked into their code because it kind of looks like CVE-2019-17571 is a problem. It could also be that lunasec has included this hash when it should not have been but more than likely they feel that CVE-2019-17571 is a concern with so many eyes on CVE-2021-44228.


This CVE can be exploited if log4j is listening to a network port, this is why it's probably not impacting as much as last Friday one.
rokoyato
Posts: 45
Joined: Mon Jun 29, 2020 9:12 am

Re: log4j-zero-day exploit - active attacks

Postby rokoyato » Tue Dec 14, 2021 8:55 am

Hi,

Does anyone has a good regex to ban every ip trying this attack ?

For now I use :

<HOST> - - .*(jndi)

On access-log files but the scope is very large, while that might be enoughsince jndi should not be called from outside maybe someone as a better solution.

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

Re: log4j-zero-day exploit - active attacks

Postby maxxer » Tue Dec 14, 2021 9:00 am

phoenix wrote:Correct and sad, isn't it?


Tony replied!!

https://bugzilla.zimbra.com/show_bug.cgi?id=109428
User avatar
barrydegraaff
Zimbra Employee
Zimbra Employee
Posts: 158
Joined: Tue Jun 17, 2014 3:31 am
Contact:

Re: log4j-zero-day exploit - active attacks

Postby barrydegraaff » Tue Dec 14, 2021 10:31 am

After intensive review and testing, Zimbra Development 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).

Zimbra Collaboration Server currently uses log4j1 version 1.2.16 which doesn't contain the lookup expression feature that is found within versions 2.0 to 2.17, which is the cause of the vulnerability.

Also, Redhat (CVE-2021-4104) vulnerability does not affect the Zimbra Collaboration Server version (8.8.15 & 9.0.0). For this vulnerability to affect the server, it needs JMSAppender, which the ZCS Server does not use, and the ability to append configuration files.
--
Barry de Graaff
Admin of Zimbra-Community Github: https://github.com/orgs/Zimbra-Community/
Developer of Zimbra OpenPGP Zimlet, Zimbra ownCloud Zimlet and more.
A Zetalliance Founder http://www.zetalliance.org/
User avatar
gabrieles
Advanced member
Advanced member
Posts: 175
Joined: Tue Feb 14, 2017 9:40 am

Re: log4j-zero-day exploit - active attacks

Postby gabrieles » Tue Dec 14, 2021 11:32 am

barrydegraaff wrote:After intensive review and testing, Zimbra Development 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).

Zimbra Collaboration Server currently uses log4j1 version 1.2.16 which doesn't contain the lookup expression feature that is found within versions 2.0 to 2.17, which is the cause of the vulnerability.

Also, Redhat (CVE-2021-4104) vulnerability does not affect the Zimbra Collaboration Server version (8.8.15 & 9.0.0). For this vulnerability to affect the server, it needs JMSAppender, which the ZCS Server does not use, and the ability to append configuration files.


many thanks for these details, Barry!
meghtitan
Posts: 1
Joined: Tue Dec 14, 2021 1:53 pm

Re: log4j-zero-day exploit - active attacks

Postby meghtitan » Tue Dec 14, 2021 2:05 pm

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. shareme for pc jiofilocalhtml.run
Last edited by meghtitan on Sat Jan 01, 2022 9:03 am, edited 1 time in total.

Return to “Administrators”

Who is online

Users browsing this forum: andras0602 and 31 guests