HowTo: React on Check Point Information Disclosure

[Danny]

Every now and then auditors reviewing and penetrating Check Point firewalls are often criticizing a http web portal being accessible on tcp-port 18264 of the firewall's external interface providing a so called Internal_CA for download.
Don't be fooled, this is not the Internal CA Management Tool, which runs on tcp-port 18265 on your SmartCenter once you enabled it. See:

What's it then?

Your Check Point Firewall just allows obtaining CRLs via an HTTP request on ICA port 18264/tcp.
See: sk32682, sk99076

Check Point writes:

Is this a vulnerability? No. All CAs have to do this.
This is a security feature, not a security problem. Without publishing the CRL, you lose security.

Auditors also like to criticize port 264 TCP being open disclosing the firewall's hostname and ICA name.

This can simply be verified on your own with the one-liner below (replace x.x.x.x with the IP of your Check Point).

printf '\x51\x00\x00\x00\x00\x00\x00\x21\x00\x00\x00\x0bsecuremote\x00' | nc -q 1 x.x.x.x 264 | grep -a CN | cut -c 2-

Check Point considers this public information (sk69360).

Also read this interesting thread about the hostname disclosure.

You can still improve security!

Option 1: Exclude FW1_ica_services on port 18264 (sk35292) from the implied rules and explicitly define a rule allowing access to this port from specific IP addresses. This only works if RemoteAccess VPN users don't connect from dynamic IPs.

Option 2: Detect and prevent port scans via IPS and/or SmartEvent.

Option 3: Block known scanners, such as Shodan, Censys, Shadowserver and others.

Option 4: Configure a Geo Policy and follow this HowTo: Protections against a Cyber War

[_Val_]

Okay, that makes sense. I will let @Ethan_Schorer and R&D handle this from now.

[Lukas_Sosnovec]

Hello,

I am wondering if there is any progress with this problem? It's been 8 month now when we all (even CheckPoint engineers) agreed that this is a security issue. Do we have some offcial statement? Or maybe I just didn't notice any solution provided?

[PhoneBoy]

Looks like the official response to this issue (released back in July 2021) is: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
Basically, it's fixed in R81.10 and will be backported to the JHFs.

[Bjoern_K]

Interesting news! I'd like to learn more. Unfortunately, the link you provided only leads me to a general support page?

[PhoneBoy]

Not sure what happened with the link above, but I corrected it.

[Ethan_Schorer]

Hi @Bjoern_K ,

It was very clear from the start that you're discussing what you called case 2. Since we agree with you that this is a potential issue - we are in the process of fixing this and appreciate you bringing this up.

Regards,

Ethan

[Bjoern_K]

Hi @Ethan_Schorer,

thanks for clarifying. I was honestly a bit confused if I was explaining my point clearly enough, since the discussion always seemed to gravitate towards the CRL distribution point (see Val's first comment from yesterday, for example).

[_Val_]

@Bjoern_K 

I am also not sure about exploitation. ICA is out there for ages, and I do not recall a single case of it is being abused or exploited. Would you please specify a particular scenario of such exploitation? 

[Ethan_Schorer]

Hi @Bjoern_K ,

That is what I meant, that the HTTP server at the port is there mainly for the CRL.

Of course there will be a way to completely disable it, the problem today is that this is required for CRL and so it cannot be disabled.

Ethan

[Jeffrey_Fogel]

I noticed that @Bjoern_K concern about users installing the CA certificate into a browser that the user would then use to trust some malicious web site from the MitM attacker.

Maybe I am missing something, but isn't our CA for communication between management and GWs,  endpoint, and VPN clients/endpoints? Mostly, isn't it Check Point software that would need this cert? That would be connecting back to the same systems managed by the issuing CA? 

So if you were to intercept the CA download, you'd need to clone or have your own Check Point infrastructure.

If you were attempting to establish SIC with a gateway, you would know immediately if it didn't work.
If you were a remote access client, you would not be able to connect to the remote access gateway
If you were an endpoint client, you would be unable to retrieve your endpoint policy or configure yourself.
Then you have S2S tunnels, and likely the same issues.

Thoughts?

Jeffrey Fogel

[Bjoern_K]

Hello Jeffrey,

the problem is that once the attacker was able to trick the user into installing the fake Certificate Authority certificate, the attacker can use this to create fake certificates for whatever URl/website that they wish. After the installation, the browser will completely trust this CA.

The original purpose of the CA plays no role here. The browser does not know about this purpose nor does it check it. It simply checks whether it trusts the CA if it sees a certificate which was issued by it. Since the user installed the CA manually, this will be the case, enabling the attacker to fake certificates.

While you are probably right that only Check Point software needs this cert. But the browser doesn't care. Once the CA is installed, it trusts it blindly.

Of course you are right that there needs to be a Check Point infrastructure available to abuse this vulnerability. However, the attacker wouldn't need to set it up themselves. They only need to be on the same network as the victim and act as a man-in-the-middle between the victim and the cert installation portal.

Also, yeah, the user would probably notice that they can't access the Check Point products after installing this fake CA (I guess, I don't have detailed knowledge of the products). But even if this would be the case, a normal user without a security/technological background will probably not think twice about it, try again and download the correct CA certificate, without removing the malicious one. And even if they do remove the malicious CA, the damage might have already been done.

Furthermore, the installation of a malicious CA cert is just one type of attack that is possible here. The attacker could also use this vulnerability to spread whatever malware they want, as I've also explained in pervious posts.

[Danny]

Check Point is still using TLS 1.0.
Should this be improved?

[Tobias_Moritz]

@Danny : Where did you see forced usage of TLS 1.0 in modern CP versions? Or are you referring to the defaults?

I'm not sure if this is really new to you, as you are well-known checkmate :), but: sk147272 for non-multi-portal and sk126613 for multiportal. There is also some setting available in SmartConsole, but when you remove legacy ciphers from multi-portal, TLS 1.0/1.1 is unusable anyway.

Regarding CPM, I got this from TAC a while ago referring to sk122073:

"We support TLS version 1.2 and above, and reject TLS versions below 1.2 (etc. TLS1.1 and TLS1.0).
On CPM server port 19009.
The TLS fix has been integrated into the Jumbo hotfixes of certain versions:
•    R80.10 Take 278 and on
•    R80.20 Take 149 and on
•    R80.30 Take 195 and on
And exists in versions:
•    R80.40 (and above)"

Regarding FWM, I got this from TAC a while ago:

Summarized and no full quote, because I'm not sure if I am allowed to:

Generally not possible to harden this to TLS 1.2. There is a special procedure available to TAC, but they do not want to offer it because "we cannot calculate the entire impact for the specific use of the customer". I was told to refer to a known RFE at local Check Point office.