topic Re: HowTo: React on Check Point Information Disclosure in General Topics

HowTo: React on Check Point Information Disclosure

Danny — Wed, 30 Jul 2025 21:25:21 GMT

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: Check the implied rules part in sk132712.

Option 2: 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 3: Detect and prevent port scans via IPS and/or SmartEvent.

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

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

Re: HowTo: React on Check Point Information Disclosure

Gaurav_Pandya — Wed, 28 Nov 2018 12:18:17 GMT

Hi Danny,

This is great information. Recently we have faced this issue for one of our client.

In Pen test, it was flagged with issue 18265 port ICA services.

Re: HowTo: React on Check Point Information Disclosure

Simon_T — Wed, 31 Jul 2019 12:06:43 GMT

Great post. not sure if this is the correct area but I have a tricky question from our PCI DSS ASV process. They now have to check against OWASP and have detected 2 security misconfiguration items on our CP firewall running R77.30

1) This application does not enable X-XSS-Protection - X-XSS-Protection header missing on :18264

2) This application does not set X-Content-Type-Options - X-Content-Type-Options header missing on :18264

They say the JavaScript on this port is very 'dated' to be polite. The ASV advises remediation could be either:

a) Enable HTTP Strict Transport Security

b) Enable the following headers:

X-Frame-Options or Content-Security-Policy with the frame-ancestors directive.
X-XSS-Protection
X-Content-Type-Options

for both 1 and 2 above.

We will be upgrading this R77.30 to R88.20 in September, but in the mean time we are wondering if there are any configuration options variable to resolve this issue.

Thanks,

Simon

Re: HowTo: React on Check Point Information Disclosure

Ethan_Schorer — Mon, 05 Aug 2019 09:22:58 GMT

Hi,

The site in question is for downloading the CA certificate and path or for downloading the CRL for correct certificate behavior. While Check Point always strives to improve security and will look into adding the missing security headers, I would like to explain why it is not a vulnerability not having them in this case:

X-XSS-Protection: this one is to block XSS sent in the request to the site. Not relevant since there are no parameters sent on request to this site that can be the source of the XSS attack, and the default by the browsers is to enable anyway.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

X-Content-Type-Options: this is so that you don’t load a file of one type as another (i.e. loading plain-text as JavaScript). Not relevant since we only load our own local files and not some arbitrary file that may be misconfigured.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

Best regards,

Ethan

Re: HowTo: React on Check Point Information Disclosure

_Val_ — Mon, 05 Aug 2019 09:27:59 GMT

Thanks, @Ethan_Schorer

Re: HowTo: React on Check Point Information Disclosure

Bjoern_K — Thu, 17 Dec 2020 14:35:05 GMT

Hi,

A colleague of mine and me recently stumbled over this issue during a client assignment. We then also found this forum post, which seems misleading to us.

The descriptions reads like only CRL files are being offered for download. However, the discussed web portal actually offers a CA certificate for download and instructs the user to manually install it. The download files are not merely CRLs but certificates, as can for example be checked by trying to install them as certificates in a browser (for example in Firefox), which would not work with a .crl file.

Since the site and the CA certificate are transported insecurely over http, an attacker would be able to attack the data transfer in a man-in-the-middle-attack, swap the transfered certificate with a malicious one (i.e. one that the attacker knows the secret keys for) and thereby manipulate the user to install a malicious certificate. This could allow further man-in-the-middle attacks on the user who has now installed a malicious CA certificate.

Could you please clarify this issue? The connection to the linked article about the CRLs is not really obvious as well, since it does not mention the portal or the CA certificate at all. Even if the port is (also) used to distribute CRLs over http, it should not transport CA certificates over http as well.

Thank you,
Björn

Re: HowTo: React on Check Point Information Disclosure

PhoneBoy — Thu, 17 Dec 2020 19:09:52 GMT

The ICA portal runs on a different port (18265) than the CRL retrieval port (18264) and is not exposed to the Internet by any implied rules.
The ICA Portal should only be accessed from trusted networks.
Management Servers in general should be deployed on a segmented network with strict access controls in place as a best practice.

Re: HowTo: React on Check Point Information Disclosure

Bjoern_K — Fri, 18 Dec 2020 16:37:40 GMT

HI PhoneBoy,

I'm not talking about the ICA portal, I'm talking about the Certificate Services portal which is available on port 18264 (first screenshot in the initial post). This portal offers CA certificates for download over http and even instructs the user to install the certificate. While it might be the case that this port is also used for CRLs (I don't have detailed knowledge about the CheckPoint products), it also offers CA certificates.

Re: HowTo: React on Check Point Information Disclosure

G_W_Albrecht — Fri, 18 Dec 2020 16:47:56 GMT

Which kind of attack do you think is possible using this available CA cert ?

Re: HowTo: React on Check Point Information Disclosure

Bjoern_K — Fri, 18 Dec 2020 16:58:48 GMT

As described in my original comment, a man-in-the-middle attacker could switch this CA certificate during transport to a CA certificate that the attacker controls (i.e. knows the secret keys to). Since the website instructs the user to install the certificates, it would be easy to manipulate the user to install this malicious certificate or the user might do it on his own (since this is the use case for the original CA certificate anyway). This would enable the attacker to mount further MITM attacks on the victim, since the victim now has a CA certificate installed that the attacker controls.

On top of this there are also all attacks possible that are possible on any http page. For example spread malware, deface it, add a fake login form and steal credentials this way and so on.

Re: HowTo: React on Check Point Information Disclosure

PhoneBoy — Fri, 18 Dec 2020 17:51:10 GMT

The CRL in general should not be accessible to the world, only to the relevant gateways that need it (basically any gateway you manage and for any VPN gateways with where the ICA certificate is used).
And, for reasons discussed above, it has to be over HTTP.
Generally this access is permitted with implied rules but additional segmentation/access control rules for your management may be required.

Re: HowTo: React on Check Point Information Disclosure

Bjoern_K — Mon, 21 Dec 2020 07:36:52 GMT

Thanks for the answer, PhoneBoy, but that still does not answer my original question. While the CRL might need to be distributed over HTTP, this doesn't justify why a CA certficiate is distributed over HTTP and the associated security risks. Why not distribute the CA certificate over HTTPS on another port?

Re: HowTo: React on Check Point Information Disclosure

Ethan_Schorer — Mon, 21 Dec 2020 16:01:05 GMT

Hi @Bjoern_K ,

This will become a bootstrap issue. Which certificate should be used for the https site? The same as the one you're about to download? In that case - how can you trust it before downloading it. You need to start with something.

On the internet, you get a pre-installed package of trusted CAs; when it comes to your own private management - you don't have that privilege until you download that CA's certificate and install it.

Ethan

Re: HowTo: React on Check Point Information Disclosure

Bjoern_K — Mon, 21 Dec 2020 16:20:49 GMT

Hi @Ethan_Schorer,

good point. Of course you would need a certificate from a trusted CA and this is of course what I assumed . But I can see how this would not be practical here. However, this doesn't remedy the security issue that comes with distributing the CA certificate over HTTP. While I can see how this is a convenient solution in practice, the security risk remains. Could you please adress the issue I described?

Why not advocate for a more secure way of distributing the CA certificate? For example by letting the admins install them instead of distributing them over this insecure channel. This would mitigate the risk considerably - assuming that you trust your admins... but if you don't do that, you have bigger problems.

Is there a way of removing this web portal from this port without negatively effecting the functionality of your product? (again, I don't have detailed knowledge about the product)

While the attack vector might be arguably small (as long as the portal isn't available over the internet, which it was in the case of my client), users should be able to decide whether they want to take this risk or not in my opinion.

Thanks.

Re: HowTo: React on Check Point Information Disclosure

Ethan_Schorer — Mon, 21 Dec 2020 16:24:38 GMT

Hi @Bjoern_K ,

Let me look into that.

Ethan

Re: HowTo: React on Check Point Information Disclosure

Bjoern_K — Mon, 18 Jan 2021 11:32:20 GMT

Hi @Ethan_Schorer,

I'm still interested in the original question, did you find something out about this topic in the mean time?

Thanks!

Re: HowTo: React on Check Point Information Disclosure

x13 — Tue, 02 Feb 2021 14:37:38 GMT

Hello gentleman,

I also am very interested in the scenario here and did read your posts as I have the exact same situation with a client assessment. I also not have been sure how I should rate this finding and if it it indeed poses a security risk. My thoughts have been similar to @Bjoern_K's.
But I also am very interested in an update on the subject and what the best practice is to protect that Port/Webserver.

Thank you all very much for the clarifications!

Re: HowTo: React on Check Point Information Disclosure

Bjoern_K — Mon, 08 Feb 2021 07:02:42 GMT

Great to see that someone else is interested in this issue as well! I would also still appreciate an update on this.

Re: HowTo: React on Check Point Information Disclosure

Ethan_Schorer — Mon, 08 Feb 2021 13:26:21 GMT

Hi,
Sorry for not replying earlier on this.

I understand the issue and we plan to attend it.

This "web site" is there mainly for CRL fetching which is why it is accessible externally and in clear HTTP. That will remain this way.

With time, we added the Internal CAs public key for downloading in order to make it easier for administrators to distribute it to their end-users - this we plan to move to an internal-only port.

In the meantime, until the fix is out, if you don't want your end-users to download the public key from there - then supply it to them some other way. End-users won't access this page unless they're directed to it.

Best regards,

Ethan

Re: HowTo: React on Check Point Information Disclosure

Bjoern_K — Mon, 08 Feb 2021 14:37:27 GMT

Hi Ethan,

sorry to be so blunt, but the statement "this "web site" is there mainly for CRL fetching which is why it is accessible externally and in clear HTTP." is clearly false. Maybe the port is used for this as well, but the website itself is only used to distribute the certificates.

Moving this portal to an internal-only port only mitigates the risk from an outside attacker. An inside attacker would still be able to exploit it.

"End users won't acces this page unless they're directed to it" - exactly this is the problem. This page could easily be used in a Social Engineering scenario.

Why not add a possiblity to completely turn off this page? (I actually think it should be the other way around - the page should be deactivated on default and if you want to activate it, the users should be warned about the security risk involved)

Best regards,

Björn