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

[Gaurav_Pandya]

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.

[Simon_T]

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

[Ethan_Schorer]

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

[_Val_]

Thanks, @Ethan_Schorer 

[Bjoern_K]

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

[PhoneBoy]

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.

[Bjoern_K]

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.

[tavi0906]

found an vulnerability WWW Service Information Disclosure over HTTPS on port 18265. is this an expected behavior ?

[Danny]

You may want to report it here.

[G_W_Albrecht]

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

[Bjoern_K]

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.

[PhoneBoy]

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.

[Bjoern_K]

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?

[Ethan_Schorer]

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

[Bjoern_K]

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.

[Lukas_Sosnovec]

Hi guys, just FYI - I am facing the same problem as it was found by an external firewall audit. Exactkly as @Bjoern_K noted, the issue is not CRL distibution but CA cert accessible on http. In fact, the auditor proposed exactly the same attack vector.

I suppose we will see simmilar pentest result more often now...

[Ethan_Schorer]

Hi @Bjoern_K ,

Let me look into that.

Ethan

[Bjoern_K]

Hi @Ethan_Schorer,

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

Thanks!

[x13]

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!

[Bjoern_K]

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

[Ethan_Schorer]

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

[Bjoern_K]

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

[_Val_]

@Bjoern_K let's try to be civil here, please. @Ethan_Schorer is referring to CRL distribution point, which:

1. is pure HTTP,
2. has to be publicly available for VPN certificates to work

The rest of the functionality, as Ethan mentions, will be addressed shortly. 

[Bjoern_K]

Hello @_Val_ , Hello @Ethan_Schorer,

sorry if my comment seemed uncivil, that was not my intention. I will try to explain once more, although I have written all of this (multiple times even) in previous posts already.

The situation is as follows. There's an HTTP port that does two things at once:

1. It offers a CRL distribution point, and

2. It offers a web page that is used for downloading certificate files.

Now, to be absolutely and 100% clear, I am not talking about point 1. Spreading the CRL info over HTTP is okay and RFC conform, this was never my point. I am getting the feeling that you are thinking that this is also something I am having problems with. But it is not, I am NOT talking about this.

The problem that I have been talking about from the start is point 2. The web page is used to distribute CA certificate files over an unencrypted and unauthenticated channel. Once the CA file is installed in the users browser, the browser will accept all certificates signed by this CA. A possible attack scenario would be:

1. Get the user/victim to surf to the webpage to download and reinstall the CA certificate file with some sort of social engineering technique. For example, tell him that the certificate needs to be renewed for organizational reasons or whatever else you can think of. It is a well known fact that users easily fall for such social engineering techniques. Alternatively, time your attack such that a user will use this portal anyway (more difficult/less chance of success, of course, since you would need precisely time your attack.
2. Mount a man-in-the-middle attack on the victim, i.e. the attacker is able to read and manipulate all the traffic between the webpage and the victim. Note that this is only possible because the webpage and certificate files are being distributed over HTTP.
3. During the MitM attack, change the CA certificate in transit to a CA certificate file to which you as the attacker know the secret keys. Since you're a MitM and the channel is not authenticated, the victim will not notice this change.
4. The victim will now install a malicious CA certificate in his browser.
5. Since the attacker knows the secret keys of the CA certificate, he can now easily fake certificates and mount MitM attacks on arbitrary websites and completely read and manipulate the whole internet traffic of the victim.
6. Note that in this whole scenario the user/victim probably puts a high level of trust on this page, since it is in the internal network on a company server. Since its original purpose is also to distribue CA certificate files, the user/victim will not be be "surprised" that he needs to download and install a CA certificate from there.

I have described other attacks above, like faking the webpage to look like some login page (since everything is transported over HTTP, attackers can completely change the look and feel of the site) to steal credentials and so on. This is however not really the central problem. The central problem is that users trust this website to distribute CA files.

While the risk might not be extremly high/critical (as I have also stated from the start), it is still an unnecessary risk. Simply offer an option to remove the CA certificate file download from this port and only use it for CRL. Done. That is literally all you need to do and to offer to your users to remove this risk.

"I do not recall a single case of it is being abused or exploited" - I could clearly demonstrate the above attack path to my clients and if this would have been a red team assignment, I would have easily been able to exploit it. Note that this argument can also be used for every type of vulnerability and that it is also notoriously difficult to pinpoint the origin of an attack.

[_Val_]

Thank you @Bjoern_K 

Your scenario assumes the certificate contains private keys, which is not the case. Only public keys are exposed.

[Bjoern_K]

Hello again, @_Val_ ,

no, I do not assume and have never written this. Of course certificates do not contain private keys, that would make no sense at all. Certificates are signed using a private key and verified using a public key. If you know the corresponding secret key to the public key of the CA, you can sign certificates in the name of the CA. Hence, if the attacker controls the CA, he can issue new certificates, since he knows the secret key and can therefore sign certificates in the name of this CA.

[_Val_]

@Ethan_Schorer & @Bjoern_K, please help me out here. Scenario 2 starts with exposing public keys (which is part of certificate infrastructure) and then leads to MitM somehow. What I am struggling is, to mount MitM, you need to generate new certificates and sign them with CA private keys. In this scenario, how do you get private keys?

Or, do I miss something in the line of argument?

[Ethan_Schorer]

@_Val_ ,

Since the site is in clear, the MiTM can send the end-user whatever they want. What they will send is a different public key than the one that is actually used by the GW/MGMT. Then, the end-user who thinks he got the correct public key will install it on his system, and from that point the MiTM can mount TLS attacks as well and see encrypted traffic too.

Ethan

[Bjoern_K]

Hello again @_Val_ ,

no, to mount the MitM attack, you do not need to generate new certificates and sign them. You can mount the MitM attack because the web portal is available over HTTP. I will try to describe the scenario in more detail:

1. The attacker mounts a Man-in-the-Middle attack on the victim and the web portal. This is possible because the web portal is being delivered over HTTP. This has nothing to do with certificates yet.
2. Since the attacker is in a MitM position now and the communication between the victim and the webportal is unencrypted and unauthenticated, the attacker can read and manipulate the complete communication between the attacker and the web portal.
3. The attacker creates his own CA certificate file. The procedures and algorithms on how to create CA files are public, no secret information is necessary. To be more precise, the attacker creates his own private keys. This is not a problem. Everbody can create key pairs, since the algorithms are publicly known. The problem now comes in the next steps:
4. The attacker manipulates the victim to navigate to the web portal. For example, by using social engineering techniques as explained above.
5. Since the web portal is used to distribute CA certificates, it will probably be easy to lure the victim into downloading a CA file from there and install it.
6. Once the victim starts the CA download, the MitM attacker now swaps the legitimate Checkpoint CA file with his maliciously generated file.
7. The victim does not notice this, since the connection to the web portal is not authenticated.
8. The victim now installs the malicious CA certificate file.
9. Since this is a CA certificate, the browser of the victim now inherently trusts all certificates issued by this "CA".
10. This means the attacker can now use his private key to issue illegitimate certificates for arbitrary websites. Normally, browsers would recognize this and display appropriate warnings, but since the browser of the victim has installed the malicious CA certificate file, the victim's browser will accept these as legitimate.
11. This gives the attacker the possiblitity to mount Man-in-the-Middle attacks on arbitrary websites.

Please let me know if anything is still unclear.