log4j-zero-day exploit - active attacks

[eneref]

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]

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.

[JDunphy]

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

[andreaswolske]

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

[maxxer]

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]

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

[maxxer]

Correct and sad, isn't it?

Tony replied!!

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

[barrydegraaff]

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.

[gabrieles]

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]

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