Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Tobias_Moritz
Advisor
Jump to solution

CVE-2021-44228 - Log4j vulnerability - Log4Shell

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.

1 Solution

Accepted Solutions
_Val_
Admin
Admin

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

View solution in original post

52 Replies
_Val_
Admin
Admin

Checking

warheart6
Explorer

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_
Admin
Admin

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

Alex_Lewis
Contributor

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

0 Kudos
Jelle_Hazenberg
Collaborator
Collaborator

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.

0 Kudos
Alex_Lewis
Contributor

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

0 Kudos
_Val_
Admin
Admin

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
Contributor

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

0 Kudos
_Val_
Admin
Admin

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
Contributor

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

0 Kudos
_Val_
Admin
Admin

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
Collaborator

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.

XBensemhoun
Employee
Employee

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...

Information Security enthusiast, CISSP, CCSP
Ewald_Beekman
Participant

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?

 

0 Kudos
(2)
haakonr
Explorer

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

Is checkpoint sofware itself vounrable?

0 Kudos
Axel_Engeland
Participant

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?

(2)
PhoneBoy
Admin
Admin

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
Participant

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?

0 Kudos
Marcel_Gramalla
Advisor

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
Explorer

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

0 Kudos
Timothy_Hall
Champion
Champion

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
Slavko_Kojic
Participant

Blocking outbound ldap/ldaps traffic, as workaround?

 

 

 

0 Kudos
warheart6
Explorer

@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
Admin
Admin

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
Contributor

Hi,

Will https explicit proxy enable ips to inspect encrypted packets ?

 

 

0 Kudos
Axel_Engeland
Participant

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!

0 Kudos
Gaurav_Pandya
Advisor

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...

0 Kudos
Martin_Seeger
Collaborator

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events