topic Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell in General Topics

CVE-2021-44228 - Log4j vulnerability - Log4Shell

Tobias_Moritz — Fri, 10 Dec 2021 12:54:12 GMT

Hello CheckMates,

I guess most of you have already seen the fresh CVE-2021-44228 - Log4j vulnerability - Log4Shell and thought about the impact it will have in the enterprise application landscape.

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

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

Maybe we can use this thread to get a first statement from Check Point regarding their products (and later links to SKs) as well as discuss (probably IPS) mitigations.

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

_Val_ — Fri, 10 Dec 2021 12:57:01 GMT

Checking

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

warheart6 — Fri, 10 Dec 2021 16:57:03 GMT

Is there any update on this ? I have already seen the exploit being used in the wild. When an attack does try to use the exploit inside a http header the ips blade of checkpoint does flag this as a "http headers remote code execution" protection so it might be a good idea to enable this.
There are a lot of reports of high profile companies that are vulnerable for this exploit

https://github.com/YfryTchsGD/Log4jAttackSurface

i hope we will get good news from checkpoint asap.

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

_Val_ — Fri, 10 Dec 2021 17:09:28 GMT

It does take time to investigate and come up with a comprehensive response. Please be patient, thanks

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

Alex_Lewis — Fri, 10 Dec 2021 17:13:17 GMT

I would assume priority will be looking at patching requirements since log4j is used on Management/Gateways by Solr and postgresql

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

_Jelle — Sat, 11 Dec 2021 11:37:39 GMT

I doubt log4j is used on the gateway side (except for standalone deployments)..., but I could be wrong there.

edit: sk176865 confirms this doubt... It's only used on the management side by management processes. And not vulnerable.

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

Alex_Lewis — Fri, 10 Dec 2021 17:49:39 GMT

I also doubt it is used on gateway, but the log4j jar files do exist there.

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

XavierBens — Fri, 10 Dec 2021 21:36:40 GMT

1. The IPS signature is available right NOW!

2. sk176865 is the Check Point response to Apache Log4j Remote Code Execution (CVE-2021-44228) accessible here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk176865&partition=General&product=IPS

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

Kevin_Tobin — Fri, 10 Dec 2021 21:44:37 GMT

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk176865&partition=General&product=IPS

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

Ewald_Beekman — Fri, 10 Dec 2021 21:46:44 GMT

Thanks for getting the protection out so soon. Will this also work for HTTPS connections when there is no HTTPS inspection active on the firewall for this incoming traffic?

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

haakonr — Fri, 10 Dec 2021 21:50:15 GMT

Does the Apache mitigation (patch and command line option) apply to Checkpoint Software as well?

Is checkpoint sofware itself vounrable?

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

Axel_Engeland — Fri, 10 Dec 2021 23:44:15 GMT

For me, the most important part is still missing. Starting from R80.40, Endpoint Management seems to use log4j 2.12, which is vulnerable. Depending on your setup (or if you have an EPM as MaaS) that may be vulnerable. Starting with R81 SOLR also uses log4j 2. What's the impact on Check Point's own products?

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

PhoneBoy — Sat, 11 Dec 2021 07:13:18 GMT

Before we update the SK with full details, we have to check a number of products/features to ensure they are not vulnerable.
At least management wise, we are not using log4j in a way that is vulnerable to this exploit.
That said, we'll upgrade log4j most likely as part of the JHF.

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

Martin_Seeger — Sat, 11 Dec 2021 08:23:20 GMT

This ain't going to be fun. Already at home I found 4 instances of log4j and I haven't even started analysing docker containers or appliances.

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

Axel_Engeland — Sat, 11 Dec 2021 10:42:30 GMT

As far as I see sk176865 is now fully updated and no vulnerabilities have been found. That's a relieve. Thanks for the hard work!

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

Ewald_Beekman — Sat, 11 Dec 2021 10:51:45 GMT

Hi, thanks for all the hard work. Can you confirm that the IPS protection will work even when the incoming traffic is HTTPS and there is no HTTPS traffic inspection active on the firewall? Or will it only help us with HTTP in that scenario?

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

Marcel_Gramalla — Sat, 11 Dec 2021 11:07:30 GMT

I think it doesn't work as I tested the example scripts that are on Github and the IPS didn't do anything (we don't have any HTTP hosts around). The question is if the protection applies on the incoming request itself or after the response of the vulnerable system. I couldn't validate that as we haven't found any system that seems to be vulnerable.

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

_Val_ — Tue, 14 Dec 2021 09:43:13 GMT

From sk176865:

Check Point Products Status

Product	Status
Quantum Security Gateway	Not vulnerable
Quantum Security Management	Not vulnerable
CloudGuard	Not vulnerable
Infinity Portal	Not vulnerable
Harmony Endpoint & Harmony Mobile	Not vulnerable
SMB	Not vulnerable
ThreatCloud	Not vulnerable

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

PatrickJ — Sat, 11 Dec 2021 15:11:11 GMT

I would also appreciate a response from Check Point to the question if the IPS signature will work when not using HTTPS traffic inspection.

Re: CVE-2021-44228 - Log4j vulnerability - Log4Shell

Timothy_Hall — Sat, 11 Dec 2021 22:51:48 GMT

Assuming I'm understanding the attack technique correctly, if the initial exploit is delivered inside an HTTPS connection, that delivery takes place well after the HTTPS negotiation and both sides have started encryption; pretty sure there is going to be no way to detect that stage via IPS unless HTTPS Inspection is enabled.

However when the vulnerable server is tricked into retrieving the Java class to be injected via JNDI using a ldap://1.2.3.4/ URL that will be in the clear, and perhaps can be detected by the IPS signature if it is configured to do so. Gets more murky if ldaps://1.2.3.4/ is used in the exploit, but I don't think that will work since JNDI will probably not trust the certificate of the attacker's system and the ldaps connection will fail to deliver the injected content.