Checkpoint Firewall remote security assessment

 In today's blog I will outline some steps aimed toward the inspection of the information Checkpoint Firewall exposes to an unauthenticated access. This remote gathering therefore assumes no internal information about the firewall - blackbox approach with only the IP address of the firewall known.

In this particular case I had an IP address assigned to the firewall management interface (which will be exposed only internally in most of the cases). 

Below is the description of the steps, tools and approach I used in the assessment.

I started the assessment by looking at the publicly available tools for either information gathering or exploiting the Checkpoint. Not much was found, but one of the tools that attracted my attention was a metasploit module found in auxiliary/gather/checkpoint_hostname.

This module retrieves the names of the firewall enforcement module and its management server. One only needs to specify the IP address and the port of the Checkpoint. I found that several ports on the Checkpoint can be used to retrieve this information - the original tool documents refers to is the tcp 256 which is FW1 (fwd) policy install port FWD_SVC_PORT. I used port 18183 in my case (which is used for suspicious monitoring FW1_sam Check Point OPSEC Suspicious Activity monitoring Proto (SAM API).

Observe the "Firewall host" and "SmartCenter host" names obtained. The original research and article are available under https://www.osi.security/checkpoint-firewall---securemote-hostname-and-smartcenter-information-disclosure.html. Checkpoint issued their advisory claiming that this is actually not a vulnerability as the names are part of the internal certificate that Checkpoint components use to establish trust relationship between their components (i.e. firewall executive node and its management server).

Checkpoint's explanation makes sense to me, after all, this is what you verify every time when https web server shows its digital certificate - you simply verify its name and the name of the CA (and intermediate server authorities, if in the chain) to make sure you're not connecting to a rogue server.

The interesting difference here is that neither tcp port 256 or 18183 is not SSL port equipped with certificate, but rather uses a plaintext communication to retrieve these attributes.

To illustrate the mechanics of the protocol, let us look at the network capture of this communication below. First, there is no TLS1.x in the protocol dissector, only TCP which goes in plaintext. You can see that 34 bytes of data are in cleartext.

This response is provoked by metasploit module injecting specific byte sequences as shown below.

So, first \x51\x00\x00\x00 followed by \x00\x00\x00\x21 is sent and then if server replies with "Y\x00\x00\x00", another string is sent : \x00\x00\x00\x0bsecuremote\x00. I tried injecting random bytes instead of \x51... and x21 and I still got the "Y\x00\x00\x00" response, however not the response that contained hostnames. So, it must be a hard-coded sequence that Checkpoint recognised.

Then I followed another test which was simply connecting to the various Checkpoint open ports (above 30000 in my case) which were not documented in Checkpoint knowledge base.

There was one interesting behaviour I observed , but was not able to reproduce the next day. Not sure why, though.

As you can see, the firewall issued "no policy is installed" message. I did confirm with the client the policy WAS INSTALLED on the firewall. So, my guess is that those ports might have informed me that my "client" (telnet client application) did not have a proper policy installed to allow me communication with Checkpoint firewall. If those ports are some kind of dynamically open ports on the firewall itself following the successful client authentication, then it would make sense to me. First, the client would authenticate via telnet-based access to tcp 256 or tcp 900 (web based) and upon successful authentication Checkpoint would open a port dedicated to the authenticated client. Then this authenticated client would use some Checkpoint client application to utilise this service.

I want to emphasize here that the above is only an assumption what might be behind this "no policy is installed" - I have no sufficient evidence to claim my hypothesis is correct.

I found nothing specially interesting in the traffic trace of these sessions. The text is issued via Data section of the TCP transmission as a PSH-ACK to a 3 way handshake -no particular application payload was required to generate this message.

After this I tried to inject some random data after a 3 way handshake, but nothing changed in the response- the same reply.

The next thing I inspected was the telnet-based client authentication over tcp port 259. The client authentication is used to authenticate the IP address for various network services through the Checkpoint firewall. There are two ways to perform client authentication:

a) telnet-based access via tcp port 259

b) web based access via tcp port 900

Below is an example where I tried some trivial credentials versus port 259. 

These attempts all failed, however, the network capture of the session did reveal the password and username were sent in clear text. So, these sessions are indeed run via plaintext telnet protocol (although password is spread across multiple packets, so one needs to gather multiple packets in sequence to collect the whole password). I guess a man-in-the-middle attack might provide some insights into the sensitive info.

Another test was inspection of the web based client authentication via tcp port 900.  Note that in my particular case the http was used instead of https. Not sure if this is the implementation error on my client’s side (most likely) rather than the design flaw on Checkpoint’s side. Some indication it’s the implementation procedure flaw is given in the following link: 

https://www.cpug.org/forums/archive/index.php/t-13437.html

This is how it looks like when implemented with no SSL over http. (note http never gets redirected to https).

Next test was checking the cipher algorithms used for its ssh port (22). It seems R80.20 version of Gaia (Checkpoint's operating system running on recent products) had a weak Diffie-Hellman group.

While group14-sha1 is still considered strong, group-sha1 should definitely be removed according to recent research. https://tools.ietf.org/id/draft-ietf-curdle-ssh-kex-sha2-09.html#:~:text=A%20key%20exchange%20method%20may,from%20MUST%20to%20MUST%20NOT.

The last test performed was a scan against crypto ciphers running on the Checkpoint https interface. (tcp port 443). Even though not critical, I was surprised to find TLS1.0 was still there by default.

All in all, I did not find anything serious, but some details were unexpected such as weak ciphers on ssh and https ports, especially given Checkpoint is very serious about security and R80.20 is a relatively fresh software version at the time of the writing.