CVE-2021-44228 - Log4j vulnerability - Log4Shell

[Tobias_Moritz]

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.

[_Val_]

Checking

[warheart6]

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.

[_Val_]

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

[Alex_Lewis]

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

[_Jelle]

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.

[Alex_Lewis]

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

[_Val_ · Accepted solution]

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

[marki]

Ehm... concerning https://www.checkpoint.com/defense/advisories/public/2021/cpai-2021-0936.html

What does that even mean? I mean this is not only about the firewall protecting other devices but about how affected the security gateway itself could be...

What about 5000-Series gateways (thus not "Quantum") running say R80.10?

Thanks,

Marki

[_Val_]

The advisory is about Threat Prevention protection for a third party. Concerning Check Point own products, see above👆🏻 the quote from sk176865.

Spoiler: not vulnerable. 

[marki]

Just to be sure: Is "Quantum" just a marketing thing? Meaning our 5000-Series gateways running R80.x qualify as "not vulnerable"?

[_Val_]

Quantum is a family name for Network Security products. We use it since beginning of 2021, along with others.

Now, do you really want me to answer the same question three times in a row? 🙂 Sure, I can do that.

Still, not vulnerable.

[Martin_Seeger]

Very bad news: the exploit now works with any Java version: https://twitter.com/wdormann/status/1470409556303958017#m 

I am unsure if this will affect the statement of Check Point, but 90% of all work of customers has just been rendered useless.

[Kevin_Tobin]

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[XavierBens]

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=&solut...

[Ewald_Beekman]

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?

[haakonr]

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

Is checkpoint sofware itself vounrable?

[Axel_Engeland]

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?

[PhoneBoy]

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.

[Ewald_Beekman]

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?

[Marcel_Gramalla]

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.

[PatrickJ]

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

[Timothy_Hall]

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.

[Slavko_Kojic]

Blocking outbound ldap/ldaps traffic, as workaround?

[warheart6]

@Slavko_Kojic I do not think that is going to work. The exploit does not only us the ldap protocol but also rmi for instance. What I understand from the exploit is that does not matter which protocol is used since the attacker can just define on which port it wants the return traffic to happen. `

[PhoneBoy]

For HTTPS traffic, you will need to have HTTPS Inspection active to see if this is being exploited.
This is because we have to see the User-Agent string, which we can't see if the traffic is encrypted.
More details: https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/ 

[Durin]

Hi,

Will https explicit proxy enable ips to inspect encrypted packets ?

[Axel_Engeland]

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!

[Gaurav_Pandya]

Hi,

One more thing.

Checkpoint Harmony protects below stuff which is related to log4j? 

• Trojan:Win32/Capfetox.AA – detects attempted exploitation on the attacker machine
• Trojan:Win64/DisguiseXMRigMiner – detection for coin mining post exploitation payloads
• HackTool:Win32/Capfetox.A!dha – detects attempted exploitation on the attacker machine
• VirTool:Win64/CobaltSrike.A, TrojanDropper:PowerShell/Cobacis.A – detects Cobalt Strike Beacon loaders

https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for...

[Martin_Seeger]

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.